July 2005 - Development - lists.drupal.org

[drupal-devel] [bug] "Only variables can be passed by reference" to file_check_directory()
by danielc 09 Sep '05

09 Sep '05

Issue status update for http://drupal.org/node/26033 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/file_create_path.diff (2.4 KB) A client of mine just upgraded to the latest snapshot of PHP 5.0.5-dev and started getting errors when file_check_directory() is called: Fatal error: Only variables can be passed by reference in c:\drupal\modules\system.module on line 653 This patch fixes the problem by assigning the values to variables before passing them to file_check_directory(). Thanks. (BTW: I'm no longer on on drupal-devel due to time constraints.) danielc

4 7

[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] [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] 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] introduce filapi hook
by Bèr Kessels 02 Sep '05

02 Sep '05

Issue status update for http://drupal.org/node/18934 Project: Drupal Version: 4.5.2 Component: file system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch This simple patch by Robert Douglas introduces a fileapi hook. Nothing fancy, nothing difficult and most of all harldy any performance overhead. It simply allows modules to hook into the data of the file on: insert delete update load The reason why this should be here, and not in nodeapi, is because, for example media.module wants to "do stuff" with the file, like get id3 data and put that into a table on upload of a file. Another valid use case would be to be able to track and count downloads. Yet another case would be some file renaming, or organising in directories. Bèr Bèr Kessels

12 20

[drupal-devel] [bug] Menu.inc error when running on php5
by iraszl 01 Sep '05

01 Sep '05

Issue status update for http://drupal.org/node/27582 Post a follow up: http://drupal.org/project/comments/add/27582 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: iraszl Updated by: iraszl Status: patch In *menu.inc*, function menu_execute_active_handler() I changed: if (strlen($arg)) { To: if (strlen($arg) && is_array($arguments)) { That did the trick to get rid of the annoying error messages in the log. iraszl

3 2

[drupal-devel] [bug] (4.6.0RC) Node stats wrongly displayed
by jeancf 31 Aug '05

31 Aug '05

Issue status update for http://drupal.org/node/19780 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jeancf Updated by: jeancf Status: active I have the statistics module enabled but I want to see node counters only when I am logged in as super user. I don't want my users to see them. So I have "display counter values" set to enabled under administrer > settings > statistics and all roles unchecked under administer > access control > statistics module > access statistics. And still when I log out (anonymous user role) nodes display the node counter. I know this worked under 4.5.2. and was VERY convenient. Is this a feature or a bug in 4.6.0RC? Thanks, JC jeancf

3 2

[drupal-devel] [task] Removed plpgsql dependency for PostgreSQL users by updating (pg)SQL function definitions
by Smirnov 31 Aug '05

31 Aug '05

Issue status update for http://drupal.org/node/26091 Project: Drupal Version: cvs Component: postgresql database Category: tasks Priority: normal Assigned to: Anonymous Reported by: Smirnov Updated by: Smirnov Status: patch Attachment: http://drupal.org/files/issues/database.pgsql_4.patch (1.85 KB) In /database/database.pgsql/ many of the functions such as *greatest(integer, integer)* were defined with /plpgsql/. This patch simply changes the definitions a bit to use regular SQL (SELECT) -- so users won't have to load /plpgsql/ with /createlang/ anymore. In addition, I have updated the *IF(expr1,expr2,expr3)* function to reflect MySQL's definition of it [1]. Before *expr1* always had to be passed as a /boolean/, and now it is /anyelement/. Also now *expr1* is true if it's both NOT NULL and 0. Anyways, this means that if Drupal modules are passing integers when using the sql *IF()* function, the query will now work. NOTE: The IF() function is not ANSI SQL, perhaps in a later patch we can replace all usage of it with CASE? [1] http://dev.mysql.com/doc/mysql/en/control-flow-functions.html Smirnov

3 3

[drupal-devel] [bug] Consistency in form elements form_autocomplete(), form_textfield() and form_textarea()
by stefan nagtegaal 31 Aug '05

31 Aug '05

Issue status update for http://drupal.org/node/25603 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: stefan nagtegaal Status: patch Attachment: http://drupal.org/files/issues/form_size_consistency.patch (69.9 KB) Attached you'll find the patch for making the form element, form_field(), form_autocomplete() and form_textarea() consistent in size.. I used: form_autocomplete() and form_textfield(): for numbers: width of 5; for small textfields: width of 15 or 30; for textfields settings, titles etc: width of 60; form_textarea() small textarea's: width 60, height 5 rules; medium textarea's: width 60, height 15 rules; large textarea's (node submission body's): width 60, height 20 rules; please review and apply patch... I this is - for the sake of consistency - a very fine patch.. stefan nagtegaal

3 3

[drupal-devel] [feature] No obvious way to tell which release a site is running
by Chris Johnson 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/20439 Project: Drupal Version: cvs Component: other Category: feature requests Priority: normal Assigned to: Chris Johnson Reported by: Chris Johnson Updated by: Chris Johnson Status: patch Attachment: http://drupal.org/files/issues/releasename_core.patch (32.8 KB) There's no easy way for a site administrator to tell which version of Drupal software his site is running. This is particularly a problem when an administrator manages multiple sites at multiple hosts. The problem becomes even more exacerbated when the same admin only has limited time to update the software on sites, resulting in confusion as to just what version is running where. While there are a lot of technical solutions to this problem, some of which I'd like to implement, this patch is the simplest and least invasive. It simply adds the CVS release tag name to each file which can take such a tag. An admin can thus look in any file and see which release it is. This patch is for the core files. A similar one will be added to a separate issue for contrib files. Chris Johnson

6 7