August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] phptemplate.engine: is_int/is_numeric confusion
by wiz 09 Sep '05

09 Sep '05

Issue status update for http://drupal.org/node/27781 Post a follow up: http://drupal.org/project/comments/add/27781 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: wiz Updated by: wiz Status: patch Attachment: http://drupal.org/files/issues/phptemplate_node.patch (720 bytes) I've wondered why $node is not defined anymore in my theme's page.tpl.php. The reason is a modified expression in phptemplate.engine, which now reads: if ((arg(0) == 'node') && is_int(arg(1))) { arg(1) may be the node number, but it is a string variable, and therefore this check is always false. is_int should be replaced with the code given in the patch. wiz

3 2

[drupal-devel] [bug] Bugfix (?) to search_data function (hook_search_item not working)
by adixon 09 Sep '05

09 Sep '05

Issue status update for http://drupal.org/node/28767 Post a follow up: http://drupal.org/project/comments/add/28767 Project: Drupal Version: cvs Component: search.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adixon Updated by: adixon Status: patch (code needs review) I think that line 678: $output .= theme('search_item', $entry, $type); should be $output .= theme('search_item', $entry, $entry['type']); so that hook_search_item is in fact invoked for the particular entry's module type. adixon

2 1

[drupal-devel] [bug] Multiple node types are broken
by chx 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/29785 Post a follow up: http://drupal.org/project/comments/add/29785 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node_basename.patch (3.92 KB) People come and tell me that I have broken node_get_module_name. I tell them I fixed it. This leads nowhere. Yesterday Kjartan, jakeg and me had finally a conversation during which we have arrived to the conclusion that there is no need for two hooks and hook_node_name could return either a string or an array in the form of: <?php array('type-a' => array('node type a', 'base')), 'type-b' => 'node type b', 'node type c'); ?> Which would define a 'type-a' , with a human readable name 'node type a' and base_load would be called for hook_load and so forth. for 'type-b' , the difference is that modulename_load would be called. For 'node type c', the node type would be modulename. chx

5 18

[drupal-devel] [bug] Taxonomy_save_* return values
by chx 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/29102 Post a follow up: http://drupal.org/project/comments/add/29102 Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch (code needs review) Attachment: http://drupal.org/files/issues/taxonomy_save_return.patch (4.08 KB) What is described on http://drupal.org/node/22218 is nice. What is in the core is super ugly. I surely was not paying attention when did slipped in. chx

6 9

[drupal-devel] [feature] Flat out $node in phptemplate_node vars
by chx 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/24862 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/nodevarsflat.patch (907 bytes) I'd like to write $whatever in node.tpl.php instead of $node->whatever . Hence the patch. chx

6 9

[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] [bug] speed up "Top pages in past n days" page
by Jeremy 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/28924 Post a follow up: http://drupal.org/project/comments/add/28924 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: minor Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org Status: patch (code needs review) Attachment: http://drupal.org/files/issues/statistics.module-cvs_0.patch (615 bytes) Displaying statistics pages can be slow. The attached patch removes one of the "GROUP BY" columns to increase the speed of generating the "Top pages in the past n days" page. (Grouping by 'title' does not work, as there are many different paths that can have the same title. Instead, 'path' is unique for each page, so it is a more logical column to group by. I tested this on my active webpage to verify that the resulting page was what I expected.) Jeremy(a)kerneltrap.org

3 3

[drupal-devel] [feature] Make user count in user block optional
by legoscia 05 Sep '05

05 Sep '05

Issue status update for http://drupal.org/node/29145 Post a follow up: http://drupal.org/project/comments/add/29145 Project: Drupal Version: 4.6.3 Component: user.module Category: feature requests Priority: minor Assigned to: Anonymous Reported by: legoscia Updated by: legoscia Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal-user-count.patch (3.4 KB) The normal look of the user block was too big for my site, and the count of online users was not deemed important enough. Thus here is a patch that makes the display of the user count optional, leaving only the list of online users. legoscia

8 15

[drupal-devel] [task] Administrator configurable defaults and overriding variables.
by adrian 05 Sep '05

05 Sep '05

Issue status update for http://drupal.org/node/25745 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: adrian Status: patch Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes) When running a mass hosting environment, it is often required to shield users from the ability to break the sites hosted on your system and there are very often also good security reasons to remove the ability to configure certain variables. This patch does two things : 1) Introduces an optional sites/global.php file, that will be loaded after the sites/default/settings.php file and provide a set of global settings for all sites hosted on a server. This means the administrator only needs to configure the variables once. 2) Modifies variable_get and variable_set to check optional 'variable_default($name)' and 'variable_override($name)' functions, that an administrator can define in the above global.php file. There already exists the ability to set variables using $conf[varname] in your settings.php file, but there is no distinction made against variables that have been set this way, and normal variables, apart from the fact that trying to change them in the admin section fails silently. A good example of this would be the need to set up the files dir, and not allow it to be modified, as a user modifying the files dir to another site's files directory could be catastrophic. <?php function variable_override($name) { $conf['file_directory_path'] = conf_init() . '/files'; $conf['file_directory_temp'] = conf_init() . '/files/tmp'; $conf['file_downloads'] = 2; return $conf[$name]; } ?> These values will now be the only accepted and used values to the variables. If the user tries to modify them, they will revert to these values and there will be a message stating that the variable has been locked. Another common requirement is to provide sensible defaults for an install, but not take away the configurability of the option. A common example of this would be the theme setting. <?php function variable_default($name) { $conf['theme_default'] = 'chameleon'; return $conf[$name]; } ?> This will change the default that variable_get falls back on, from the one provided in the parameter list, to the administrator configured default. This is a much cleaner method of setting the defaults, than global search replacing the defaults provided in the code. This patch is one of the changes we have made to the drupal code base for our hosting platform @ bryght. adrian

3 7

[drupal-devel] [feature] Enabling access control on selfmade blocks for menu.module
by damnsure 05 Sep '05

05 Sep '05

Issue status update for http://drupal.org/node/30054 Post a follow up: http://drupal.org/project/comments/add/30054 Project: Drupal Version: 4.6.3 Component: menu system Category: feature requests Priority: normal Assigned to: damnsure Reported by: damnsure Updated by: damnsure Status: patch (code needs review) Attachment: http://drupal.org/files/issues/menu.module_1.patch (957 bytes) As I'm somehow new to drupal and not 100% sure if I'm doing the right thing please be indulgent. I wrote a patch to enable access control on selfmade blocks for menu.module. Till now it was possible to set blocks to certain pages but not depending on user roles. With this patch you will have an entry for each selfmade block under "access control -> menu modul", each starting with "show". damnsure

3 3