June 2005 - Development - lists.drupal.org

[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] settings.php change to prevent PHPSESSID in URL
by kbahey 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/21170 Project: Drupal Version: 4.6.0 Component: other Category: bug reports Priority: normal Assigned to: kbahey Reported by: kbahey Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/settings_0.patch (576 bytes) As per the workaround mentioned in discussion [1], the default settings.php file that is shipped does not always prevent PHP from adding the PHPSESSID in the URL. Although this is a hosting setting issue, a workaround exists for it: A patch is attached, and it just adds the following line to settings.php ini_set('url_rewriter.tags', ''); [1] http://drupal.org/node/17947#comment-36339 kbahey

3 3

[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] Search Watchdog Log
by pyromanfo 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/24957 Project: Drupal Version: 4.6.0 Component: watchdog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: pyromanfo Updated by: pyromanfo Status: patch Attachment: http://drupal.org/files/issues/watchdog_search.patch (2.75 KB) This patch allows you to search the watchdog log for some text in the hostname, user or the message itself. Also if you enter a severity, 'error','warning','notice' it'll filter by that. Works in tandem with the dropdown filter box. pyromanfo

3 4

[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