- Development - lists.drupal.org

[drupal-devel] [bug] NOTICES silenced
by hlslaughter 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/30633 Post a follow up: http://drupal.org/project/comments/add/30633 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: hlslaughter Updated by: hlslaughter Status: patch (code needs review) Attachment: http://drupal.org/files/issues/common.inc_hlslaughter_200509071421.patch (1.88 KB) this does not necessarily silence all NOTICEs, just the most obvious ones that are generated by using a pretty generic HEAD drupal install. i'm not sure if i've followed coding standards correctly, so i'd appreciate feedback on even the slightest thing :) again, attaching a patch crashed mozilla, so will try to attach with followup post hlslaughter

1 1

[drupal-devel] [task] Performance: fix all include paths
by m3avrck 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/30122 Post a follow up: http://drupal.org/project/comments/add/30122 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal_2.patch (9.68 KB) This patch fixes all of the outstanding Drupal include paths by placing the './' in front of the include path. This brings all of the Drupal core files up to date with the boostrap.inc which made first use of this performance gain. In simple testing, I've have noticed much faster load times with Drupal on my slow machine. Definetly makes a big difference! m3avrck

2 4

[drupal-devel] drupal site on forwarded server
by openwereld.net 07 Sep '05

07 Sep '05

Hi list, I entered this first as an issue on the drupal site at http://drupal.org/node/30173, but got no reaction there. It's probably more suitable for a developer's discussion. If a drupal site is situated on an intranet and external requests are forwarded to it, the function 'conf_init' in bootstrap.inc uses the 'wrong' host name. It always uses $_SERVER['HTTP_HOST'], while in case of request forwarding it could use $_SERVER['HTTP_X_FORWARDED_SERVER']. The following code fragment (in conf_init() ) should improve this: if( isset( $_SERVER['HTTP_X_FORWARDED_SERVER'] ) ) $server = explode('.', rtrim($_SERVER['HTTP_X_FORWARDED_SERVER'], '.')); else $server = explode('.', rtrim($_SERVER['HTTP_HOST'], '.')); john.

1 0

[drupal-devel] [bug] Correct progress bar height
by drumm 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/30629 Post a follow up: http://drupal.org/project/comments/add/30629 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: minor Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/drupal.css_2.diff (525 bytes) The height of the progress bar changed from 2em to 1.5 em at some point and the filled section is still taking up 2em. Steven agreed this fix is correct in IRC yesterday. drumm

1 0

[drupal-devel] [bug] new revision of content node fails to update node_revisions.type
by killes 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/30622 Post a follow up: http://drupal.org/project/comments/add/30622 -Project: API +Project: Drupal -Version: cvs +Version: cvs -Component: Code +Component: node system Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: hlslaughter Updated by: killes(a)www.drop.org -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/update_5.patch (992 bytes) Indeed, the update produces a type field in node_revisions which shouldn't be there. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Wed, 07 Sep 2005 19:49:05 +0000 : hlslaughter Attachment: http://drupal.org/files/issues/node.module_hlslaughter_200509071333.patch (1.95 KB) i have a custom content module. when i create a node of this type, the node.type field is correctly initialized. but when i create a revision of that same node, the node_revisions.type field remains empty. since a user cannot modify the content type from the gui, i don't understand why the 'type' field even exists in node_revisions, but because it does, i assume it's meant to be the authoritative value of 'type'. so that's the field i grab for my custom module, and when it's not kept up to date, stuff doesn't work. i'm going to try to attach a patch, but last time i tried it crashed my browser and i lost my post, so there may not be a patch file here. ------------------------------------------------------------------------ Wed, 07 Sep 2005 19:52:21 +0000 : hlslaughter Attachment: http://drupal.org/files/issues/node.module_hlslaughter_200509071333_0.patch (1.95 KB) attempting to attach patch. patch also includes a fix for the notices node.module generates and doesn't need to. if anything comes of this post, i'll be more precise with my patch files in the future :)

1 0

[drupal-devel] [bug] Blocks showing up when module disabled
by tostinni 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor Assigned to: drumm Reported by: Jose A Reyero Updated by: tostinni Status: patch (code needs work) Sorry I didn't understood "This patch is now fubar." ? This patch has been abandonned ? tostinni Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module. ------------------------------------------------------------------------ Thu, 11 Aug 2005 20:49:44 +0000 : tostinni This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?> ------------------------------------------------------------------------ Thu, 11 Aug 2005 22:17:26 +0000 : drumm I can work on this. ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:20:14 +0000 : drumm Attachment: http://drupal.org/files/issues/system.module_5.diff (3.54 KB) I decided to implement a hook system for this. As a side effect: - system_listing_save() only does database things. The UI things such as drupal_set_message() are now separated into the calling function. - The status message for saving module is now: * The aggregator module has been disabled. * The archive module has been enabled. instead of "The configuration options have been saved." - The theme-specific things in system_listing_save() are not there anymore. - There is also a hook called when modules are enabled. I think I'll go write some documentation for the two new hooks now. ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:48:40 +0000 : drumm Here is some hook documentation: <?php /** * This hook is called on every module for when each new module is enabled. The * module will be loaded at this point so the module's own hook will be called * and other modules may use module_invoke() to call functions in the module. * * @param $module * The name of the module which has just been enabled. */ hook_module_enabled($module) { } /** * This hook is called on every module for when each new module is disabled. * The module will still be loaded at this point so the module's own hook will * be called and other modules may use module_invoke() to call functions in the * module. * * @param $module * The name of the module which has just been disabled. T */ hook_module_disabled($module) { } ?> ------------------------------------------------------------------------ Wed, 07 Sep 2005 19:18:22 +0000 : drumm This patch is now fubar. Please feel free to resubmit the concept in update #2 by tostinni in patch form.

1 0

[drupal-devel] [feature] Put all throttle settings in the same place
by drumm 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/27818 Post a follow up: http://drupal.org/project/comments/add/27818 Project: Drupal Version: cvs Component: throttle.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm -Status: patch (code needs review) +Status: patch (code needs work) Doesn't apply anymore drumm Previous comments: ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:21:16 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_12.png (37.86 KB) Screenshot 1/2. The modules admin page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:24:10 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_13.png (15.81 KB) Screenshot 2/2. The throttle modules page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:29:32 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules.patch (9.73 KB) This patch needs http://drupal.org/node/27804. The throttle configuration is currently spread out on the modules page and the block configuration page. This patch moves the module throttling to a local task next to the throttle settings page. I have not worked on moving block throttling yet since I want to see what the reaction to this first part is. If this is comitted I plan to move the block throttle checkboxes and continue improving the modules page. With less interface elements the modules page can be made even simpler that is it now. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:48:47 +0000 : drumm forgot to label it as a patch ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:21:27 +0000 : factoryjoe +1 for moving throttle/performance settings to it's own page/tab -1 for showing disabled modules; only list those that can be disabled Issues: * "turning on" throttling seems counter intuitive... like, all the modules should be checked as given priority... then you DESELECT in order to take it off the priority list. I guess the current UI is opposite of most conventions... where you start with everything enabled and then take things /off/ the list. * The list is not a scalable UI. If I have 60 modules (*cough cough*) I'll see the first 10-15 and ignore the rest. If you could sort by processing weight ("these modules suck up tonnes of memory! disable these first!") or by functionality, the list would be much more manageable. * I still think "throttle" is a terrible name. Like "taxonomy" people don't readily know what it means and avoid it like the plague. From a marketing perspective, this is bad news for Drupal since it may appears that Drupal is slow when it really just needs to have its *performance* settings tweaked. ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:52:00 +0000 : killes(a)www.drop.org -1 for adding yet another config page. teh throttle setting is fine where it is. ------------------------------------------------------------------------ Wed, 03 Aug 2005 23:05:03 +0000 : drumm Here is an updated patch which has all of the modules checked and may be unchecked to disable them while throttled. It removes all disabled modules and required modules from the list. The page name 'throttle' is generated directly from the module's name. Changing the module name or changing the mechanism which sets that title is out of the scope of this patch. Ordering by processing time or functionality can be done given a decent algorithm to do that. Figuring out such an algorithm would be out of the scope of this patch too since it would need some sort of monitoring functionality as well. I think alphabetical is fine. Does anyone have more feedback on creation of this local task page or keeping it in the modules page? ------------------------------------------------------------------------ Wed, 03 Aug 2005 23:05:30 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules_0.patch (9.54 KB)

1 0

[drupal-devel] [bug] "blog entry" vs. "personal blog entry" is confusing
by Geary 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/30620 Post a follow up: http://drupal.org/project/comments/add/30620 Project: Drupal Version: 4.6.0 Component: blog.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Geary Updated by: Geary -Status: active +Status: patch (code needs review) (forgot to mark status: patch) Geary Previous comments: ------------------------------------------------------------------------ Wed, 07 Sep 2005 19:42:46 +0000 : Geary Attachment: http://drupal.org/files/issues/geary-2005-09-07.blog.module.patch (256 bytes) When you click "create content", you get two lists of available content types, a summary list in the menu block and a list with explanations of each type in the body. For the blog module, the menu block lists "blog entry" and the list in the body says "personal blog entry". This discrepancy is confusing, especially because it changes the alphabetization of the list, so the two lists do not match up. For example, if you have the blog, page, and story modules enabled, the menu block reads: blog entry page story and the body with the longer explanations reads: page personal blog entry story The fix for this is trivial: change "personal blog entry" to "blog entry", as in the attached patch.

1 0

[drupal-devel] [bug] Blocks showing up when module disabled
by drumm 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor Assigned to: drumm Reported by: Jose A Reyero Updated by: drumm -Status: patch (code needs review) +Status: patch (code needs work) This patch is now fubar. Please feel free to resubmit the concept in update #2 by tostinni in patch form. drumm Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module. ------------------------------------------------------------------------ Thu, 11 Aug 2005 20:49:44 +0000 : tostinni This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?> ------------------------------------------------------------------------ Thu, 11 Aug 2005 22:17:26 +0000 : drumm I can work on this. ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:20:14 +0000 : drumm Attachment: http://drupal.org/files/issues/system.module_5.diff (3.54 KB) I decided to implement a hook system for this. As a side effect: - system_listing_save() only does database things. The UI things such as drupal_set_message() are now separated into the calling function. - The status message for saving module is now: * The aggregator module has been disabled. * The archive module has been enabled. instead of "The configuration options have been saved." - The theme-specific things in system_listing_save() are not there anymore. - There is also a hook called when modules are enabled. I think I'll go write some documentation for the two new hooks now. ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:48:40 +0000 : drumm Here is some hook documentation: <?php /** * This hook is called on every module for when each new module is enabled. The * module will be loaded at this point so the module's own hook will be called * and other modules may use module_invoke() to call functions in the module. * * @param $module * The name of the module which has just been enabled. */ hook_module_enabled($module) { } /** * This hook is called on every module for when each new module is disabled. * The module will still be loaded at this point so the module's own hook will * be called and other modules may use module_invoke() to call functions in the * module. * * @param $module * The name of the module which has just been disabled. T */ hook_module_disabled($module) { } ?>

1 0

[drupal-devel] [bug] Can't delete subjects with '&' in title
by m3avrck 07 Sep '05

07 Sep '05

Issue status update for http://drupal.org/node/27140 Post a follow up: http://drupal.org/project/comments/add/27140 Project: Drupal Version: cvs Component: contact.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (code needs review) +1 patch works great! Latest HEAD version applied with update.php works great, modifies database correctly for MySQL (and PostgreSQL looks correct as well) and contacts can now be deleted if they have '&' in the subject. Also, dumped entire database and created from modified database.mysql and everything works great. I'd say this patch is ready to be committed! m3avrck Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 14:57:03 +0000 : m3avrck Using the site-wide contact forms, any subjects with an '&' cannot be deleted. Clicking delete for these subjects brings up the expected action flow, however, confirming the delete does nothing. Subject still exists. ------------------------------------------------------------------------ Mon, 25 Jul 2005 13:45:38 +0000 : m3avrck It appears this issue might be linked with this one: http://drupal.org/node/23685 A problem with mod_rewrite and not the actual contact module. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:51:56 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_6.patch (4.7 KB) Redid how contacts work. It now references contacts by ID instead of their category as the unique identifier. It also allows for contacts to have weights, so that one may control where the contact will appear in the listing. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:53:01 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc (27.23 KB) This is the update.inc for the database cahnges that goes along with this patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:37 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_7.patch (4.5 KB) Updated patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc_4.patch (1.29 KB) Updated database patch. ------------------------------------------------------------------------ Sat, 03 Sep 2005 16:17:21 +0000 : Cvbge Hi, 0. You should keep all changes in one file, i.e. pake one patch, not patch for every file 1. You should include changes for database/database.{mysql,pgsql} 2. IIRC auto_increment was depreciated, you should use db_next_id() (but I see auto_increment in cvs...) 3. You use "WHERE cid = '%s'", but cid is integer so this should probably be %d (although this probably would not break anything..) ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:31:21 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full.patch (6.38 KB) Ok, I've taken your suggestions in, and i think I have it this time. Let me know if this is a correct format for a patch. This only fixes the bug of not being able to delete special characters. ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:37:30 +0000 : m3avrck Check your database updates, the UNIQUE fields don't look right syntactically. ------------------------------------------------------------------------ Wed, 07 Sep 2005 18:23:07 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full_0.patch (6.25 KB) Ok, i apologize for the last upload. Pleasle ignore. I send the wrong file. :-[. Anyway, here's a tested, tried, and correct patch.

1 0