April 2005 - Development - lists.drupal.org

[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] [feature] 'View terms' for vocabularies with > 25 terms
by Morbus Iff 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and 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. Morbus Iff

7 23

[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

[drupal-devel] [bug] PROFILE_HIDDEN updates
by pyromanfo 20 Jun '05

20 Jun '05

Issue status update for http://drupal.org/node/21219 Project: Drupal Version: cvs Component: profile.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: pyromanfo Updated by: pyromanfo Status: patch Attachment: http://drupal.org/files/issues/profile_hidden_update.patch (3.28 KB) Here are some updates to the PROFILE_HIDDEN functionality. Basically now if you have 'administer users' access, you can edit these fields and they show up for you in the user's profile when editing. If you don't then they don't show up for editing at all. They still should show up when simply viewing though. pyromanfo

9 12

[drupal-devel] [feature] Form groups should be collapsible
by tangent 09 Jun '05

09 Jun '05

Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/collapsible_formgroups.patch (2.8 KB) With all the talk of form reorganization and with the latest attempts at coding a solution, I thought I'd step up and contribute my solution. It is a quick development that I just threw together and it will probably need to be expanded to support more options, but it works and it has zero impact on existing code other than a small change to form_groups(). I've added an optional boolean parameter called "collapsed" so that modules can specify if the group should be initially collapsed or not. Known issues: 1. Styling the collapsed forms to look the same or even just good in every browser may prove troublesome. It looks fine in Mozilla/Firefox but the legend jumps around a bit in IE. I'm not terribly concerned about that at the moment though. 2. Required fields are not handled so a collapsed fieldset *could* contain a required field. This will need to be dealt with before this is a real solution, in my opinion. The difficulty lies in the fact that required fields are not labeled (in the markup) as such, other than by adding an extran span. Maybe we should think about adding a "required" attribute to required fields. I'm attaching the patch (against HEAD) now and will attach the javascript file shortly as well as a test page so you can see the functionality. As an aside, I'm setting this issue to patch status since that seems to be the process used around here. However, I think that generally an issue should ONLY be set to patch status if the attached file is worthy of being commited. Please correct me if I have misunderstood. tangent -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204

21 80

[drupal-devel] [task] Sensical status messages for forum admin
by drumm 26 May '05

26 May '05

Issue status update for http://drupal.org/node/19621 Project: Drupal Version: cvs Component: forum.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/forum.module_3.diff (6.73 KB) We are making forums and forum containers here, not terms. This patch returns a status so the calling code can set the appropriate message (or no message at all). This has the happy side effect of preventing any potential problems with calling this from when cron is running and other similar situations. The define()s are done in common.inc to encourage similarly architected code; separate UI from DB manipulation. drumm

7 9

[drupal-devel] [bug] "Create content" menu displays extraneous links
by JonBob 26 May '05

26 May '05

Issue status update for http://drupal.org/node/18275 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: JonBob Updated by: JonBob Status: patch Attachment: http://drupal.org/files/issues/node_30.patch (509 bytes) In the case where a node module defines no node types, like Flexinode or CCK when no types have yet been defined, the node/add menu displays links that do not work. One-line fix attached. JonBob

4 3

[drupal-devel] [feature] favicon patch for themes
by nysus 25 May '05

25 May '05

Issue status update for http://drupal.org/node/20809 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: nysus Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/favicon.patch (4.57 KB) Here is a patch that allows a user to manually set the path to the "favicon.ico" file. It makes a single change to the user interface: it adds a text field to the "Logo image setting" section of the "themes/settings" page. This is especially useful for sites sharing a single code base as you no longer need to create a new theme just so you can have a distinct favicon.ico. nysus

9 17

[drupal-devel] Where to put contact.module
by neil＠civicspacelabs.org 25 May '05

25 May '05

I used to keep the contact module on Drupal CVS. Approximately November of last year, CivicSpace decided to stop development on the contact module in favor of waiting for CivicCRM. Its code is written for Drupal 4.4 and it still doesn't have full support for the node permissions system and is not compatible with the latest version of the forms module. To get it fully working with the features of Drupal 4.6 would probably be equivalent to a full rewrite and testing. Probably a solid week of coding and testing which I don't have. I'd like to move this back to Drupal CVS since the volunteer module requires it and I'd like for all CivicSpace modules to have Drupal.org projects. However I need some way of dealing with the forked forms module and I do not plan on considering any feature requests at this point. Any objections or other comments? -Neil

2 4