March 2005 - Development - lists.drupal.org

[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] [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

[drupal-devel] [feature] Recent nodes/comments block (patch attached)
by hba 15 May '05

15 May '05

Issue status update for http://drupal.org/node/19387 Project: Drupal Version: 4.5.2 Component: tracker.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: hba Updated by: hba Status: patch Attachment: http://drupal.org/files/issues/tracker.module.recent.posts.block.patch (1.59 KB) This patch adds a recents posts/nodes/comments block to tracker.module. It is better than the 'recent comments' block in comment.module in my opinion: this block includes recent nodes/images/events/etc. as well, and it uses less space. The patch is for 4.5.2, but I guess it would work with few adjustments (if any) on 4.6.x. hba

2 2

[drupal-devel] [bug] cache_set sometimes fails
by wiz 10 May '05

10 May '05

Issue status update for http://drupal.org/node/19442 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: wiz Updated by: wiz Status: active When cache_set is called for a cache entry which already exists in that very form (including the timestamp), the first UPDATE will change no rows (db_affected_rows() == 0), and the subsequent INSERT will fail because the row (i.e., the primary key) already exists. This can happen only if calling cache_set with the same parameters twice in one second -- but this can happen. Example: locale_refresh_cache() may be called often from locale() when no rows exist in the translation_* tables (which is a bug by itself). The error message then is: user error: Duplicate entry 'locale:de' for key 1 query: INSERT INTO cache (cid, data, created, expire, headers) VALUES ('locale:de', 'N;', 1111769323, 0, '') in /var/www/drupal-cvs/includes/database.mysql.inc on line 66. I can think of no obvious general fix, except to add another column to cache that is updated with a random number, or to use a SELECT to check for the existence of the row. The function locale_refresh_cache in locale.module seems to have a bug too (separate post). wiz

3 9

[drupal-devel] [bug] Book printer friendly version does not recall filter_nodeapi, so many filters are broken
by matteo 05 May '05

05 May '05

Issue status update for http://drupal.org/node/19377 Project: Drupal Version: 4.5.2 Component: book.module Category: bug reports Priority: normal Assigned to: matteo Reported by: matteo Updated by: matteo Status: patch Attachment: http://drupal.org/files/issues/book_nodeapi_1.patch (1.11 KB) Filter_nodeapi is not recalled when printing a book. Here is a patch that solves the problem. You can easiliy reproduce the problem by installing inline.module, where images are regularly printed when viewing the pages, while [inline] tag is not rendered when printing a printer-friendly page. Matteo matteo

2 4

[drupal-devel] [feature] Themeable Search Form
by mathias 16 Apr '05

16 Apr '05

Issue status update for http://drupal.org/node/19336 Project: Drupal Version: cvs Component: search.module Category: feature requests Priority: normal Assigned to: mathias Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/themeable-search-form.patch (3.47 KB) It'd be nice if the search form was themeable. mathias

3 3

[drupal-devel] [bug] Create forum topic not inserting in forum
by joe 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/19562 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: joe(a)www.joepilot.net Reported by: joe(a)www.joepilot.net Updated by: joe(a)www.joepilot.net Status: active This is a problem I've been trying to figure out for a while, but have gotten almost nowhere. For starters, I am using PostgreSQL in case that is an issue. In any case, when I create a forum topic using the link in that forum, the tid is not recorded when the topic is created. Thus, the topic is created with a tid of 0 and doesn't appear in any forum. I fixed this issue by adding the following code to the top of the "forum_validate" function. if (!$node->nid) { // new topic $node->taxonomy[] = arg(3); } else { $node->taxonomy = array($node->tid); } This takes care of adding topics to forums using the link on the forum page. It is just a little hack for now and is not meant to fix the core issue. Unfortunately, the taxonomy selector is still not shown and if the user selects "forum topic" from the "create content" menu, they may create a forum topic that isn't in a forum. This may stem from a PostgreSQL issue with the taxonomy module. This seems to be an issue with any module that deals with it's own "private" taxonomy, as in the forum module and the new image module. joe(a)www.joepilot.net

4 5

[drupal-devel] [bug] Fix a serious bug and clean up teaser generation
by Goba 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/18836 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal.teaser-bugfix-and-cleanup.patch (4.48 KB) The node teaser generator keeps the whole body as the teaser, if there is indication that PHP code is included in the body (since it is unkown, what is going to come out of the PHP parser). The only serious problem is that it does not check if the PHP filter is included in the input format, so it does keep the complete body even if there is no PHP parsing on the code. This breaks PHP code examples in articles or blog posts, which are not supposed to be parsed, but which require proper teasers. The solution is to make the teaser generation code aware of the input format (pass the whole node), and let it provide the teaser that way, depending on the input format. The attached patch also cleans up that very unprofessionaly looking sequence of copy-pasted stuff in the node_teaser function. Goba

5 25