April 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Bind IP to session
by chx 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/19845 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/bindip.patch (896 bytes) This would make session hijacking more than a bit harder. The code can be compacted even more, but I did not dare. chx

7 17

[drupal-devel] [feature] Flexiforum modifications
by pyromanfo 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/20295 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: pyromanfo Updated by: pyromanfo Status: patch Attachment: http://drupal.org/files/issues/flexiforum.patch (10.01 KB) When I saw what was planned for the 4.6.0 forum improvements I was intrigued and a little disappointed. On the one hand, it really did make things easier. On the other hand, it was moving the forum module further away from what I wanted to use it for, making it a little less useful for me. The main thing I wanted the forums for Drupal to do was allow me to use any node type in the forums, following the generic node-based design of Drupal itself. This actually pushed it further away from that goal, having a specific walled-off section of the site that only forum posts are allowed in, and now it's seperate from the other categories as well. So I got to looking at the forum.module code and realized how easy it would be to modify it to use any node type. That, combined with my Quickpost project would allow me the node-generic forum posting I wanted for my site. Enough rambling, here's the goods. Patch Description This patch takes the CVS forum.module and allows users to see any node types in the forums, such as stories, images, book pages, blog entries and flexinode types. It's a suprisingly simple little patch, and if you're like me wanted the forums to be a little more flexible, this patch helps in that regard. It's fairly simple, and I only did preliminary testing so let me know what you think. I don't think this'll get accepted into core, but I didn't know where else to put it. It's too simple to be it's own module and I don't know where else I'd put a patch. If this should be in the forums or something, I'll put it there. pyromanfo

6 8

[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] New API function: truncate_utf8_conc
by Bèr Kessels 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/21576 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/common_inc_truncate_utf8_conc.diff (1.63 KB) This function truncates the string, but adds a string to the end, when requested. For example to concenate three dots (...) to a long username. For example to turn the long username * johndoe(a)www.personalweblog.com into johndoe(a)www.johndo... Its possible with the current truncate_utf8(), but than you need to do string comparison and some more truncation afterwards, which is not optimal. And please mark this as wontfix if not appropriate. I do not have time to maintain this patch, so if its not up to standards or so, just close this issue. Bèr Kessels

4 10

[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] Roles should not be separated by a BR.
by Morbus Iff 27 Jul '05

27 Jul '05

Issue status update for http://drupal.org/node/20457 Project: Drupal Version: cvs Component: user.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/_patch_usermodulebr.patch (848 bytes) On admin/user, the user's roles are separated both by a comma and a [br /]. The comma is quite enough - the [br /] merely makes the page look retarded ("fat" rows) on screens that have plenty of width to accomodate the entire table without the BR. On smaller width'd browsers, the "fat" rows will return, but naturally wrapped, not forced with inline HTML. Likewise, [BR] and the comma are both delimiters: only one is needed (if we use [BR], the newline becomes the visual delimiter; if we use comma, then we don't need the newlines). The attached patch removes the [BR]. Morbus Iff

5 6

[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] Check All | None on Content List Page (admin/node)
by jjeff 26 Jul '05

26 Jul '05

Issue status update for http://drupal.org/node/20641 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: jjeff Status: patch Attachment: http://drupal.org/files/issues/node_module_check_all.patch (1.23 KB) >From the "what a great time-saver" department: Here is a short patch to node.module that adds a "Check all | none" javascript link to the bottom of the content listing table on admin/node. By clicking "all" or "none" you can select or deselect all of the check boxes in the table at once. The javascript is very non-invasive, should work older (non-DOM) browsers, and non-javascript browsers will simply lose this function. The patch also adds the attribute [name = "node-admin"] to the [form] tag. I don't know if there is a form naming convention, but this was the best guess I could come up with by looking at the page source. And incidentally, if Drupal is going to move toward javascript/ajax functioning, all forms are going to need 'name' and 'id' tags. Most don't have these now. -Jeff jjeff

8 12