August 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Specifying separator in form_radios
by Uwe Hermann 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/9485 Post a follow up: http://drupal.org/project/comments/add/9485 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/form_radios_separator_0.patch (1.38 KB) I like it. Here's an updated patch for HEAD. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Fri, 23 Jul 2004 22:27:18 +0000 : Anonymous Attachment: http://drupal.org/files/issues/form_radios_separator.patch (1.38 KB) I just added one more attribute to form_radios function - separator. The default value is ' ', as before. I use it for example to layout the buttons in row instead in column. I thought this little change could be useful. The patch is working against HEAD right now. ------------------------------------------------------------------------ Sun, 25 Jul 2004 18:25:15 +0000 : Dries I wonder whether this should be a theme issue or not ... and with that in mind, whether this would be the proper solution. ------------------------------------------------------------------------ Sun, 25 Jul 2004 20:14:37 +0000 : Steven It might be useful to arrange list then horizontally yes... but then I'm wondering if it might not be best to style form_radios as a regular HTML list with list items. Then you can apply 'float: left;' or 'display: inline;' to them. ------------------------------------------------------------------------ Thu, 29 Jul 2004 09:29:36 +0000 : mph(a)private.prihoda.net I think that it's definitely not a theme issue - the decision how buttons should be laied out in larger forms should be up to the developer, theme knows usually nothing about usability (well, usually the dev doesn't know as well, but...) Making it a list seems as a good alternative to me - I'll explore it, I'm still not sure about good support for styling this elements in different browsers, but I like the idea. I'll submit new patch if it works. ------------------------------------------------------------------------ Sat, 05 Feb 2005 00:33:08 +0000 : Steven I don't think mph is around anymore. Still I think formatting radio/check lists as actual lists is a good idea. Setting back to active. ------------------------------------------------------------------------ Tue, 23 Aug 2005 10:53:02 +0000 : marceloverdijk Hi, I think the original proposed change was nice. At least better than the original code because a was printed for each button. I'm wondering about the status of this patch/proposed chaged, because it's not included in the current cvs version downloadable. Regards, Marcel ------------------------------------------------------------------------ Fri, 26 Aug 2005 05:03:31 +0000 : jimt I agree that having the ability to specify separators other than br would be very handy. A $separator argument defaulting to br looks like a painless way to achieve this while maintaining backwards compatibility.

1 0

[drupal-devel] Website moved, CVS
by Dries Buytaert 26 Aug '05

26 Aug '05

See http://drupal.org/node/29670. We still have to move mail, CVS and other services but we are waiting for the additional servers to arrive. Because of the move, existing CVS checkouts might no longer update (eg. you are prompted with a "Connection refused" message). If that happens, use cvs.drupal.org rather than drupal.org. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Fix link in upload.module settings page
by m3avrck 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29737 Post a follow up: http://drupal.org/project/comments/add/29737 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: m3avrck Reported by: m3avrck Updated by: m3avrck Status: patch (code needs review) Attachment: http://drupal.org/files/issues_1 (1.12 KB) Fix link in upload > settings page. Current HEAD version link takes you to a list of content for the website, not the actual content-type settings page. m3avrck

2 1

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Tobias Maier 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Tobias Maier Status: patch (code needs review) ok, thanks again :D Tobias Maier Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS.

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch (code needs review) The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Tobias Maier 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Tobias Maier Status: patch (code needs review) cant you provide a patch file? thanks for your work Tobias Maier Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in.

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff -Status: active +Status: patch (code needs review) Might as well start getting a review of it so I can fix 'em as they come in. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations.

1 0

[drupal-devel] [bug] Block regions not initiated for newly enabled theme, so theme unusable
by nedjo 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29506 Post a follow up: http://drupal.org/project/comments/add/29506 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: critical Assigned to: nedjo Reported by: nedjo Updated by: nedjo Status: patch (code needs work) Thanks for the tweaks, Stefan. "Can you please explain why something simple such as my attached patch is not enough?--Thox " It's a good question. My basic reasoning is that we shouldn't make upgrading themes optional, and shouldn't support non-complying themes. It's better to require upgrades, as we do for everything else, because failing to do so encourages lax coding and uneven support. Also, because the suggested workaround doesn't fix the bug, all themes would return simply left and right regions--and we'd be right back where we started! Overall, I'm thinking now I was mistaken to include error handling in this patch. Whether to allow non-complying code to be enabled is a worthy but separate issue. With modules, for example, we don't evaluate whether they work before enabling them--we rely on errors and the good sense of site admins to remove a non-complying module. I was thinking, "Themes are different, since setting a broken/nonupgraded theme as default could make a site unusable, since menus disappear, and novices don't know the right url to use to reset the theme to a supported one." But my approach was awkward and limited (e.g., it tested only one part of required theme functionality before disabling). If we're going to test for compliance before enabling (and I'm not convinced we should), we need to do so in a full, even way--which is to say, not in this patch! (The best, easiest thing would be simply to introduce a way for modules and themes to advertise their version support, as has been suggested and I believe begun elsewhere.) Updates *should* include better error handling; so I'll try to get in a separate update patch before the 4.7 code freeze. At any rate, the key point is to fix the bug introduced by issue #29002 [1]. I'll post a "bug-fix only" patch as soon as I can. [1] http://drupal.org/node/29002 nedjo Previous comments: ------------------------------------------------------------------------ Wed, 24 Aug 2005 03:10:30 +0000 : nedjo Following the introduction of extentendable regions, see this issue [2], several users have reported problems: "A fresh install of Drupal with bluemarine displays blocks correctly, but when I switch the default theme to pushbutton, all the blocks disappear. They do show up in ?q=admin/block, but just with the yellow helper boxes, no blocks are really displayed.--Goba " "Same problem as Goba. The "region" field in the blocks table is sometimes blank. This makes many themes almost unusable in a Drupal default install. I don't know how the fields are blank, but the following SQL helped me get back to theme development: UPDATE blocks SET region="left" WHERE region=""--Thox " "another confirmation. I found out about the exact same sql query as Thox to fix it:) We came across this in an update. The theme had the regions defined, but since it was a non-default theme the blocks dissapeared. A drupal site, without a navigation block is simply useless.--Ber " The issue suggests a bug in the initiation of theme blocks. When a new theme is enabled, it's supposed to be initiated with blocks based on the default theme's blocks. I'll post a fix ASAP. [2] http://www.drupal.org/node/16216 ------------------------------------------------------------------------ Wed, 24 Aug 2005 04:11:57 +0000 : nedjo I can't reproduce the reported issue with a clean install. Are the themes causing these problems "updated" (are they phptemplate-based or, if not, do they have _regions() functions)? The specific problem seems to be that the region field isn't being set when block regions are initiated. Here's the relevant portion of function system_initialize_theme_blocks(): <?php // If the region isn't supported by the theme, assign the block to the theme's default region. if (!array_key_exists($block['region'], $regions)) { $block['region'] = system_default_region($theme); } ?> This is executed if a newly-enabled theme doesn't have blocks already assigned to it. It gets the default region's settings--except the region. This code portion tests whether the default region's region is available in the newly-enabled theme, and, if not, substitutes the theme's default region. This would all fail if the theme wasn't returning any regions--but any phptemplate theme, or the core ones, should be.... Anyone see what's going wrong? ------------------------------------------------------------------------ Wed, 24 Aug 2005 18:02:44 +0000 : nedjo Attachment: http://drupal.org/files/issues/theme-region-error-catching.patch (5.73 KB) I'm still not quite sure what the issue is, but clearly better error handling is needed. A particular issue is the scenario where a site admin upgrades a Drupal install without removing non-upgraded themes, or, on a new install, tries to install non-upgraded themes. As things stand, either of these could lead to unusable themes being the default, and all blocks disappearing. The attached (initial, untested) patch adds error handling to both updates.inc and system.module. New for allinstalls: * theme region initiation return FALSE on failure TRUE on success. * on initiation failure, theme is disabled, and, if it was set to default theme, bluemarine is substituted, with message given Updating: * tests if current default theme has been upgraded, and if not sets bluemarine as the default, issuing a notice * tries to initialize blocks for each enabled theme and, on failure, disables the theme. This should help prevent upgrade problems. If anyone has a chance to review and test this, I'd appreciate it, as I don't at present have a test install to upgrade. ------------------------------------------------------------------------ Thu, 25 Aug 2005 14:07:38 +0000 : Thox The problem occurs with all of the core themes except Bluemarine. That means .theme (chameleon) and phptemplate (pushbutton) themes are both affected equally. ------------------------------------------------------------------------ Thu, 25 Aug 2005 15:33:37 +0000 : Thox When I enable a theme, it goes through system_initialize_theme_blocks(), which assigns the system_default_region() to the new theme. Unfortunately, that's blank. There's no themes loaded (disabled by system_listing_save()), so there's no regions available, so there's no default region to use. Your patch stops old themes from working, can we not simply set the default region (if not found) to "left"? This works fine for me to fix this problem. ------------------------------------------------------------------------ Thu, 25 Aug 2005 16:26:03 +0000 : nedjo Attachment: http://drupal.org/files/issues/theme-region.patch (6.2 KB) This bug came from a recent change to function list_themes(), which now lists only enabled themes. function system_listing_save() fetched available regions (using, indirectly, list_themes()) *before* a theme was enabled. As well as the error handling (discussed above), designed to prevent non-upgraded themes from being enabled and to give meaningful error messages, the attached patch moves theme region initiation to after themes are enabled. On my testing, this fixes the reported error. Please test and report back. I haven't yet tested the error handling changes to updates.inc. Anyone able to do that? To test it, try to upgrade a site that has some default (and therefore, with an upgrade, updated) themes, and some themes (already enabled) that are not upgraded. The expected behaviour is that the upgraded themes have their regions initiated, while any non-upgraded themes fail, are disabled (i.e., have their status reset to 0), with messages given. ------------------------------------------------------------------------ Thu, 25 Aug 2005 17:57:34 +0000 : nedjo Attachment: http://drupal.org/files/issues/theme_region2.patch (8.02 KB) Theme initiation was still broken for styles (unless the theme they are based on was already initialized). This is a perhaps unintended side-effect of limiting list_themes() to enabled themes--data for a theme on which a style is based are not available if that theme is not enabled. I've changed the code to load theme data directly rather than through list_themes(), so it's now I believe working. (Also fixed a minor bug in error reporting.) ------------------------------------------------------------------------ Thu, 25 Aug 2005 18:41:37 +0000 : stefan nagtegaal Nedjo, unfortunatly your patch isn't conform the drupal guidelines. See some comments here: <?php + if ($result) { + $ret[] = array('1', check_plain("UPDATE {blocks} SET theme = '$default_theme'") ."\nOK\n"); + } ?> Why is this?? If this is _really_ needed, please use something like: <?php + if ($result) { + $ret[] = array('1', check_plain("UPDATE {blocks} SET theme = '$default_theme'") ."\n". t("Success") ."\n"); + } ?> Secondly: <?php + $ret[] = array(0, t('The theme %theme failed to initialize its blocks and so has been disabled. The theme may need to be upgraded.' . "\nFAILED\n", array('%theme' => $theme))); ?> Should be something like: <?php + $ret[] = array(0, t('The theme %theme failed to initialize its blocks and so has been disabled. The theme may need to be updated.', array('%theme' => theme('placeholder', $theme)) . "\n". t('Failed') ."\n")); ?> The difference is "Failed" instead of "FAILED". We do not use UPPERCASE errors. And I think if we use sentences as "Failed", we should use "Success" either instead of "OK".. Then you didn't made these messages translatable, and lacked the use of theme('placeholder', $text). Same here: <?php + $ret[] = array(1, t('Blocks initiated for %theme theme.') . "\nOK\n", array('%theme' => $theme))); ?> Do it like this: <?php + $ret[] = array(1, t('Blocks initiated for theme %theme.', array('%theme' => theme('placeholder', $theme)) . "\n". t('Success') ."\n")); ?> So, in short: - Try to minimise HTML in user translatable strings; - Don't use CAPITAL ERRORS, we don't do that atm; - Use theme('placeholder', $string) where needed; Though, I did not test the functionality of the patch (yet).. ------------------------------------------------------------------------ Thu, 25 Aug 2005 19:22:20 +0000 : nedjo "unfortunatly your patch isn't conform the drupal guidelines. " Well, okay. I'm just following what updates.inc already does, see function update_sql(), so that messaging is consistent. Perhaps you'd like to submit a patch to fix the allcaps issue in updates.inc. I'm not going to do that now, as my aim is to get this particular (critical) problem fixed. ------------------------------------------------------------------------ Thu, 25 Aug 2005 22:25:32 +0000 : chx No, no, no! Fix core themes, write something to update.inc if need to be and document changes. Never ever put update code in the running part of Drupal. ------------------------------------------------------------------------ Thu, 25 Aug 2005 23:08:59 +0000 : nedjo I think there's some confusion here. The portion of my patch in question *is* to update.inc--not "the running part of Drupal". ------------------------------------------------------------------------ Thu, 25 Aug 2005 23:34:55 +0000 : chx I stand corrected -- sorry. But please provide a new update_XXX function instead of patching the current the one. Stefan, in update.inc we use FAILED yes and I can't see placeholder calls. ------------------------------------------------------------------------ Fri, 26 Aug 2005 00:01:36 +0000 : drumm Updates should not make the return value themselves. <?php + $result = db_query("UPDATE {blocks} SET theme = '%s'", $default_theme); + if ($result) { + $ret[] = array('1', check_plain("UPDATE {blocks} SET theme = '$default_theme'") ."\nOK\n"); + } + else { + $ret[] = array('0', check_plain("UPDATE {blocks} SET theme = '$default_theme'") ."\nFAILED\n"); + } ?> I can't see how this is different from using update_sql(). <?php + if (!system_initialize_theme_blocks($theme)) { + update_sql("UPDATE {system} SET status = 0, WHERE type = 'theme' AND name = '%s'", $theme); + $ret[] = array(0, t('The theme %theme failed to initialize its blocks and so has been disabled. The theme may need to be upgraded.' . "\nFAILED\n", array('%theme' => $theme))); + } + else { + $ret[] = array(1, t('Blocks initiated for %theme theme.' . "\nOK\n", array('%theme' => $theme))); + } ?> Use drupal_set_message(t(...), 'error') instead. Monor issue: sentences should not have double spaces between them. And another update should be written to patch up whatever the last update left behind since many developers have the broken code and should not be running the same update again. ------------------------------------------------------------------------ Fri, 26 Aug 2005 00:02:17 +0000 : drumm Updating the status. ------------------------------------------------------------------------ Fri, 26 Aug 2005 05:24:31 +0000 : nedjo Attachment: http://drupal.org/files/issues/theme-regions.patch (5.65 KB) Thanks for the tips, though they kinda miss the point. My inclusion of update enhancements is evidently distracting from the main issue--so I've deleted it from the patch. There is, in any case, no bug or broken code to fix in the past update. The issue here is that the "list_theme() improvements" patch has broken theme block initialization--before anyone had a chance to see the new region functionality in action. The attached patch fixes this. Please review and apply ASAP. Aside: my manual messaging in the updates was an admittedly crude workaround to two limitations: (1) update_sql doesn't allow additional arguments (i.e., string or number query parameters) beyond the sql, and (2) since updates may do more than simply issue queries, there's a need for more flexible reporting. I agree that drupal_set_message() *could* be used for this, but I think it makes more sense to have flexible inline messages. So I've roughed in a patch to do that (and also address some of stefan's requests), see http://drupal.org/node/29002 ------------------------------------------------------------------------ Fri, 26 Aug 2005 08:34:38 +0000 : Thox Attachment: http://drupal.org/files/issues/default-regions.patch (617 bytes) Your patch works, but I don't see why it needs to be so complicated. Can you please explain why something simple such as my attached patch is not enough? Note that it would allow allow all of the old themes to work as usual and fixes the troubles with new themes. ------------------------------------------------------------------------ Fri, 26 Aug 2005 09:23:47 +0000 : robertDouglass Nedjo, I tried your most recent patch and it worked well. I haven't compared approaches, but was happy to get my site up and running with this *awsome* new feature. I had fun popping the login box into the footer, or header or content area. This is a whole new dimension of Drupal excitement. ------------------------------------------------------------------------ Fri, 26 Aug 2005 09:30:15 +0000 : stefan nagtegaal Attachment: http://drupal.org/files/issues/theme-regions_0.patch (5.66 KB) Updated patch to use theme('placeholder', $string) and deleted the double space between a translatable sentence.. Functionality seems to work.. One thing I do not like is the wording you use, though I do not have a better idea (yet).. Can someone who's native language is English look at the drupal_set_messages()'s, please? Stefan

1 0

[drupal-devel] [task] Fix and enhance postgres and mysql support in updates.inc
by Cvbge 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/29082 Post a follow up: http://drupal.org/project/comments/add/29082 Project: Drupal Version: cvs -Component: postgresql database +Component: database system Category: tasks Priority: critical Assigned to: Cvbge Reported by: Cvbge Updated by: Cvbge Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal-head-db_add_column.2.diff (7.44 KB) A diffrent patch. Only adds 3 functions for adding and changing table columns, does not modifies any old updates. There are still some issues to be solved, for example: - when changing a column in mysql the PRIMARY KEY attribute is retained. In Postgres, due to the nature of changing process (i.e. dropping the column) this attribute is dropped. How to workaround it? Need to check other attributes too (e.g. NOT NULL, index etc). - add more attributes? Like primary key, key (mysql: synonim dla unique), unique, index, auto increment (mysql: must be indexed and must have a default) ? - in CHANGE when setting NOT NOLL, and DEFAULT is set, update the table to default WHERE column IS NULL ? Cvbge Previous comments: ------------------------------------------------------------------------ Wed, 17 Aug 2005 21:25:43 +0000 : Cvbge Postgres, since 6.4, has version() function so you can check db version from SQL. This can be used in updates.inc for example for conditional dropping of the column (which is available since 7.3, not 7.4 as stated in updates.inc). I need to check how the version string is returned in different versions before making changes. ------------------------------------------------------------------------ Thu, 18 Aug 2005 10:08:25 +0000 : Cvbge Attachment: http://drupal.org/files/issues/drupal_pg_version2.diff (1.01 KB) Here's a function returning postgres db version. I'm not sure if it fits in updates.inc, maybe it should be somewhere else. ------------------------------------------------------------------------ Fri, 19 Aug 2005 14:33:32 +0000 : Cvbge Attachment: http://drupal.org/files/issues/drupal_pg_version_and_other.diff (2.76 KB) Added 2 new functions to add or change column definition. The take care about mysql/pgsql. Code not tested, will test and update old code when I hear that this has a chanse to go in ;) ------------------------------------------------------------------------ Fri, 19 Aug 2005 17:03:39 +0000 : Cvbge Attachment: http://drupal.org/files/issues/updates.inc-pgsql_fix.diff (9.97 KB) Still more work needed. ------------------------------------------------------------------------ Sat, 20 Aug 2005 14:28:13 +0000 : Cvbge Attachment: http://drupal.org/files/issues/screenshot_3.jpg (119.33 KB) With attached patch I could make all updates without errors (my LOCKs patch was needed - http://drupal.org/node/22911) There are still some issues that should be addressed (see the patch). Also mysql update is not tested - please test. There are some problems when updating from 4.6 to cvs. Maybe the update should be made by 4.6 base itself? So I've started with fresh 4.6.3. After changing the base to cvs, patching with the LOCKs patch and simple debug helper patch, on update.php?op=update I get following errors: warning: pg_query(): Query failed: ERROR: column "cache" of relation "sessions" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71. Warning: pg_query(): Query failed: ERROR: column "referer" of relation "watchdog" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71 Bad query: Array ( [0] => SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = 'd5b1aa940eaeab37fe690ce9cc500396' AND u.status < 3 LIMIT 1 OFFSET 0 [1] => SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 1 [2] => SELECT * FROM access WHERE status = 1 AND type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) [3] => SELECT * FROM access WHERE status = 0 AND type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) [4] => SELECT data, created, headers, expire FROM cache WHERE cid = 'variables' [5] => SELECT COUNT(pid) FROM url_alias [6] => SELECT name, filename, throttle, bootstrap FROM system WHERE type = 'module' AND status = 1 [7] => UPDATE sessions SET uid = 1, cache = 0, hostname = '127.0.0.1', session = 'messages|a:0:{}', timestamp = 1124545039 WHERE sid = 'd5b1aa940eaeab37fe690ce9cc500396' [8] => INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', 'pg_query(): Query failed: ERROR: column "cache" of relation "sessions" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71.', 2, '', '/dt/d/update.php?op=update', 'http://localhost/dt/d/update.php', '127.0.0.1', 1124545039) ) Fatal error: ERROR: column "referer" of relation "watchdog" does not exist query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', 'pg_query(): Query failed: ERROR: column "cache" of relation "sessions" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71.', 2, '', '/dt/d/update.php?op=update', 'http://localhost/dt/d/update.php', '127.0.0.1', 1124545039) in /var/www/dt/d/includes/database.pgsql.inc on line 94 Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0 As we can see the problem is that there is no cache column is session table - that's update_130. Also there's no column 'referer' in watchdog table - that's update_142. So I've commented out update_130 and 142, added the columns by hand in the db and started again from the begining. After that I got another error: warning: pg_query(): Query failed: ERROR: column "access" of relation "users" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71. Bad query: Array ( [0] => SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = 'd5b1aa940eaeab37fe690ce9cc500396' AND u.status < 3 LIMIT 1 OFFSET 0 [1] => SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 1 [2] => SELECT * FROM access WHERE status = 1 AND type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) [3] => SELECT * FROM access WHERE status = 0 AND type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) [4] => SELECT data, created, headers, expire FROM cache WHERE cid = 'variables' [5] => SELECT COUNT(pid) FROM url_alias [6] => SELECT name, filename, throttle, bootstrap FROM system WHERE type = 'module' AND status = 1 [7] => UPDATE sessions SET uid = 1, cache = 0, hostname = '127.0.0.1', session = 'messages|a:0:{}', timestamp = 1124547147 WHERE sid = 'd5b1aa940eaeab37fe690ce9cc500396' [8] => UPDATE users SET access = 1124547147 WHERE uid = 1 [9] => INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', 'pg_query(): Query failed: ERROR: column "access" of relation "users" does not exist in /var/www/dt/d/includes/database.pgsql.inc on line 71.', 2, '', '/dt/d/update.php?op=update', 'http://localhost/dt/d/update.php', '127.0.0.1', 1124547147) ) user error: query: UPDATE users SET access = 1124547147 WHERE uid = 1 in /var/www/dt/d/includes/database.pgsql.inc on line 94. That's update_136. So, disable update_136 and do it by hand and start again. After all that, when accessing update.php?op=update I noticed no errors. After pressing Update all updates were applied without any errors. But when accessed main page I got a screen as on attached screenshot. ------------------------------------------------------------------------ Sat, 20 Aug 2005 14:32:27 +0000 : Cvbge Attachment: http://drupal.org/files/issues/updates.inc-pgsql_fix4.diff (12.86 KB) And the mentioned patch. Critical because otherwise upgrades (at least for postgres) are impossibile. ------------------------------------------------------------------------ Sat, 20 Aug 2005 14:36:40 +0000 : Cvbge I need people to test mysql updates, as I changed mysql part too.

1 0

[drupal-devel] [feature] Browse by entire month, not just day
by Junyor 26 Aug '05

26 Aug '05

Issue status update for http://drupal.org/node/9414 Post a follow up: http://drupal.org/project/comments/add/9414 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: ahoeben Updated by: Junyor Status: patch (code needs review) I'm all for it. Open up a new issue and you'll get my +1. :) Junyor Previous comments: ------------------------------------------------------------------------ Tue, 20 Jul 2004 12:00:51 +0000 : ahoeben Attachment: http://drupal.org/files/issues/archive_AH040720.patch (5.22 KB) I made a couple of changes to archive.module to facilitate browsing the archives by date. * Opening an archive URL without specifying a day will display the full month, eg www.example.com/archive/2004/07 * Selecting the 0th day of the month in the archive page drop down selects the full month * Using the previous/next raquo's in the calender block now uses full month browsing The attached patch is against 4.4.2 and is untested against CVS. ------------------------------------------------------------------------ Wed, 11 Aug 2004 12:15:46 +0000 : Anonymous Patch don't work with archive.module (drupal 4.4.2). Hunk #1 FAILED at 1. Hunk #2 FAILED at 26. Hunk #3 FAILED at 49. Hunk #4 FAILED at 64. Hunk #5 FAILED at 85. Hunk #6 FAILED at 131. Hunk #7 FAILED at 218. Hunk #8 FAILED at 236. Hunk #9 FAILED at 245. 9 out of 9 hunks FAILED ------------------------------------------------------------------------ Sat, 07 May 2005 23:02:45 +0000 : ahoeben Attachment: http://drupal.org/files/issues/archive_AH050508.patch (4.78 KB) Blast from the past... Not sure what I did wrong to have my original patch fail, but here is a new patch applying the same changes to Drupal 4.6 ------------------------------------------------------------------------ Sat, 07 May 2005 23:16:48 +0000 : Cvbge Hello, thanks for your patch, that's a feature I wanted :) But please change day "0" to "ANY" or similar. ------------------------------------------------------------------------ Sun, 08 May 2005 10:19:21 +0000 : ahoeben Attachment: http://drupal.org/files/issues/archive_AH050508b.patch (5.15 KB) New patch. Changed '0' in day dropdown to 'All days'. You should be able to change that string using a locale (but I have no experience with locales in Drupal). Also fixed a tiny bug that would cause the year dropdown to stop being useful on jan 1st 2006. ------------------------------------------------------------------------ Tue, 10 May 2005 13:50:13 +0000 : ahoeben Patch applies to cvs version as well... ------------------------------------------------------------------------ Thu, 25 Aug 2005 20:04:39 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_9414_archive.patch (5.09 KB) Attached updated patch for HEAD. I'll be fiddling with it some more too. ------------------------------------------------------------------------ Fri, 26 Aug 2005 11:19:06 +0000 : adrian I vote we completely ditch the legacy archive module and go with codemonkeyx' module (it's in contrib as archive) (example : http://codemonkeyx.net/archive) ------------------------------------------------------------------------ Fri, 26 Aug 2005 11:23:59 +0000 : adrian The module in contrib needs very little love actually .. The biggest thing is that there is no css in most themes for it, meaning it can be hard to browse. If we do use this module, it means we can remove most of the calendar css out of drupal.css , and perhaps move it to modules/event/event.css (provided event still uses it). The module is also a lot simpler =)

1 0