February 2005 - Development - lists.drupal.org

[drupal-devel] [feature] OPML Import for Aggregator
by arnabdotorg 10 Sep '05

10 Sep '05

Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: arnabdotorg Reported by: arnabdotorg Updated by: arnabdotorg Status: patch Attachment: http://drupal.org/files/issues/import_opml.patch (3.96 KB) The aggregator supports OPML export for all feeds, but not import. This patch enables import of OPML lists, allowing people to import lists of RSS feeds they've already assembled in another RSS app. Demo: http://arnab.drupaldevs.org/aggregator Patch: http://arnab.drupaldevs.org/tmp/import_opml.patch arnabdotorg -- View: http://drupal.org/node/16282 Edit: http://drupal.org/project/comments/add/16282

5 6

[drupal-devel] [feature] Taxonomy rewrite
by chx 21 Aug '05

21 Aug '05

Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/taxonomy_db_rewrite.patch (6.71 KB) I'd like to present a use for db_rewrite_sql: taxonomy rewrites. If this goes through, it will be possible to create an access mechanism, languages and whatever for taxonomy. This is a very small change, I think, much smaller than the node_rewrite_sql megpatch was 'cos at the moment nothing changes. There are no DISTINCTs deleted. But this opens a door for future things. Also, this only affects taxonomy.module, 'cos no other module deals with term_data and vocabulary tables (well, forum.module does, but those queries does not need a rewrite). chx -- View: http://drupal.org/node/16452 Edit: http://drupal.org/project/comments/add/16452

8 21

[drupal-devel] [task] Make local tasks more themeable
by drumm 13 Aug '05

13 Aug '05

Project: Drupal Version: cvs Component: menu system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch There is currently a lot of code that does some heavy lifting in the local task themeable functions. This is a bit of a simplification. No HTML is changed by this refactoring. To test this I tried making the local tasks hierarchical instead of two unordered lists. This was a easy change to do, with about 3 lines of changes. drumm -- View: http://drupal.org/node/17869 Edit: http://drupal.org/project/comments/add/17869

3 8

[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] [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] [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] [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] [bug] Remove PHP warnings.
by killes 20 May '05

20 May '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/tablesort-notices.patch (3.42 KB) Drupal emits an annoying number of PHP notices. The attached patch fixes a few of them in tablesort.inc. killes(a)www.drop.org -- View: http://drupal.org/node/16303 Edit: http://drupal.org/project/comments/add/16303

3 8