March 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Menu system requires a local task to have more than 1 child in order to create secondary local tasks
by andremolnar 10 Aug '05

10 Aug '05

Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: andremolnar Updated by: andremolnar Status: patch Attachment: http://drupal.org/files/issues/menu_inc_1a.patch (826 bytes) This is a minor bug. The menu system requires a local task to have more than 1 child in order to create secondary local tasks. In other words if a local task only had 1 child, menu system would not create a secondary local task menu item. This patch fixes that with the addition of 1 character in the code. andre andremolnar -- View: http://drupal.org/node/17022 Edit: http://drupal.org/project/comments/add/17022

4 5

[drupal-devel] [task] GD2-specific functions should be moved to image.gd2.inc
by Junyor 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/19611 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Junyor Reported by: Junyor Updated by: Junyor Status: patch Attachment: http://drupal.org/files/issues/system-image.patch (6.8 KB) The new image handling tools in core have a lot of GD2-specific logic, making image.inc overly cluttered and complicated. If gd2 were just treated like another toolkit (though the only one included by default), then the image.inc code would be much cleaner and more easily maintained. This patch removes all the GD2 stuff from image.inc and puts it into image.gd2.inc. The _settings hook is now doing what it sounds like it should, return settings for the toolkit. I've added a _check hook which will tell if the PHP functions needed are available. If _check fails, then the toolkit will not be listed on admin > settings and an error will be logged in watchdog. I've also update image.gd1.inc, image.imlib.inc, and image.imagick.inc with the same logic. Junyor

6 14

[drupal-devel] [bug] Various bugs in filter tip display
by Goba 31 Jul '05

31 Jul '05

Project: Drupal Version: cvs Component: filter.module Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal-various-bug-in-filter-tips.patch (1.79 KB) The theme_filter_tips() function has a $long attribute, which might have been inserted between the two attributes around it, since some of the function calls are not ready for passing that attribute. Therefor sometimes $long gets the $extra parameter value, and sometimes $long is missing (especially when long filter tips are displayed). Calling with the proper parameters fixes this issue. Also the $tip['id'] is directly used as a HTML id. But $tip['id'] contains things like 'bbcode/0' and 'glossary/0' and therefore is not capable to being used as a HTML id. I prefixed the HTML id with 'filter-', as it used to be and converted the / to -, so the ids become 'filter-bbcode-0' and 'filter-glossary-0' respectively. Patch attached. Might also be relevant for 4.5.x. Goba -- View: http://drupal.org/node/16016 Edit: http://drupal.org/project/comments/add/16016

3 4

[drupal-devel] [task] Usability tweaks: INSTALL.txt, .htaccess, settings.php.
by Morbus Iff 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/18641 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch The following patches clear up a number of minor inconsistencies during a Drupal installation. Largely, this is related to internal documentation and "where things go", but should help organize, clearup, and ease the installation. These aren't features, so they're eligible for a 4.6 commit. The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is /always/ on [1], and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong. These patches were made during the exploration and customization of Drupal by NHPR.org. In loving support of open source software, NHPR.org will continue to contribute patches they feel the community will benefit from. [1] http://us3.php.net/session Morbus Iff

10 30

[drupal-devel] [bug] Forums vocabulary title not localizable
by calanya 29 Jul '05

29 Jul '05

Issue status update for http://drupal.org/node/19534 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: calanya Updated by: calanya Status: active The forums vocabulary title ('Forums') is not localizable. Workaround is to directly edit the vocabulary table. calanya

4 9

[drupal-devel] [feature] Submission queue menu item should have count
by hba 27 Jul '05

27 Jul '05

Issue status update for http://drupal.org/node/19370 Project: Drupal Version: cvs Component: queue.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: hba Updated by: hba Status: active Attachment: http://drupal.org/files/issues/queue.module_0.patch (512 bytes) The 'submission queue' item in the menu block should have a count, so that users easily can see if there are new articles to vote for. Working patch attached. hba

2 2

[drupal-devel] [feature] Node module should provide node object to theme search hook
by Eric Scouten 27 Jul '05

27 Jul '05

Project: Drupal Version: 4.5.0 Component: page.module Category: feature requests Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: Eric Scouten Status: patch Attachment: http://drupal.org/files/issues/node_search_hook.patch (719 bytes) As currently defined node.module's search hook doesn't provide enough information to allow a rich rendering of search results. For instance, in a photographic web site, I'd like the search results to show a thumbnail of each matched image. I can't do this without access to the node object. The attached one-line patch provides access to the node object in the search results. Eric Scouten -- View: http://drupal.org/node/16056 Edit: http://drupal.org/project/comments/add/16056

3 6

[drupal-devel] [feature] i18n - Move drupal_goto to bootstrap.inc and some related features
by Jose A Reyero 22 Jul '05

22 Jul '05

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Jose A Reyero Reported by: Jose A Reyero Updated by: Jose A Reyero Status: patch Attachment: http://drupal.org/files/issues/i18n_drupal_goto_01.patch (8.41 KB) This is firs of a serie of patches adding support for some i18n related features. This patch: - moves drupal_goto to bootstrap.inc, making it possible to use it from the module_init, even for cached pages - moves url() to bootstrap.inc, as it is needed by drupal_goto, and includes a check for not to resolve path aliases when called from bootstrap (it is not needed and would require including lot more stuff from common.inc) - adds a simple hook to call 'i18n_url_rewrite' from the function 'url()' , which allows outgoing urls to be rewrited, so some additional info can be placed in the path. Jose A Reyero -- View: http://drupal.org/node/16069 Edit: http://drupal.org/project/comments/add/16069

3 7

[drupal-devel] [feature] i18n - Support for language-dependent variables
by Jose A Reyero 22 Jul '05

22 Jul '05

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Jose A Reyero Reported by: Jose A Reyero Updated by: Jose A Reyero Status: patch Attachment: http://drupal.org/files/issues/i18n_language_variables_01.patch (1.16 KB) This is a simple patch for bootstrap.inc, which adds a function call for all the variable functions (variable_get, variable_set, variable_del). This adds support for language-dependent variables, and does nothing when i18n.module is disabled. The idea is to add a language prefix to the variable name, depending on current language, thus allowing to easily translate some variables to different languages. Jose A Reyero -- View: http://drupal.org/node/16071 Edit: http://drupal.org/project/comments/add/16071

5 10

[drupal-devel] [bug] Consistent return values of comment post(), and much more
by moshe weitzman 18 Jul '05

18 Jul '05

Issue status update for http://drupal.org/node/18656 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: moshe weitzman Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/comment_post.patch (15.33 KB) This function which actually posts comments is comment_post(). This function is currently pretty messy, and not suitable for use by other modules. This patch assures that this function returns the comment ID if the submission was successful, or else returns FALSE. This is consistent with node_save(). In fact, I've renamed this function comment_save() for consistency. The old comment_save() was merged with comment_post(). I renamed comment_validate_form() to comment_validate() for consistency with node as well. To do this, I had to clean up quite more of the module. This patch unifies the admin comment form and the usual comment form, similar to what we did for nodes. This resulted lots of duplicate code removal. I was able give Admins the ability to change the author and timestamp of a comment. Thats been a feature request of mine since Jan 2003: http://drupal.org/node/983 I removed comment links from the bottom of the comment preview box (as we did for nodes) I hope this is considered for commit early in the 4.7 cycle. moshe weitzman

6 13