July 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Allow for more integers in node_access grant_x columns
by moshe weitzman 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/25395 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: moshe weitzman Reported by: moshe weitzman Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/node_access_0.patch (620 bytes) It is useful for modules to store more information in the grant_view, grant_update, Grant_delete columns than just 1 or 0. This patch treats 0 and 1 just as before, and any value greater than 1 is assumed TRUE (just like PHP). Organic groups already has 2 needs for this. One would be to store the 'group role' of a member in this table. Total characters changed: 1 moshe weitzman

2 2

[drupal-devel] [feature] Sort logs by ID instead of timestamp
by njivy 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/23560 Project: Drupal Version: cvs Component: watchdog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: njivy Updated by: njivy Status: patch In watchdog.module I propose changing the key used to sort logs chronologically. Instead of using the timestamp, which is accurate only to the nearest second, we could use the log entry id ("wid" in the database). As I understand it, the IDs are assigned sequentially, so this is a good approximation to the correct order in which the events are recorded. Also, I don't know of any events that are recorded after a delay. The problem with the current sorting key arises when logged events come within 1 second of each other. The order of events is not always preserved when viewing the log because the timestamp is identical for several events. In "modules/watchdog.module" neard line 91, the word "timestamp" is replaced with "wid": $header = array( ' ', array('data' => t('Type'), 'field' => 'w.type'), array('data' => t('Date'), 'field' => 'w.wid', 'sort' => 'desc'), array('data' => t('Message'), 'field' => 'w.message'), array('data' => t('User'), 'field' => 'u.name'), array('data' => t('Operations'), 'colspan' => '2') ); Preliminary testing suggests this is a good tweak. njivy

7 7

[drupal-devel] [feature] Trigger debug mode on-the-fly
by mathias 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/21379 Project: Drupal Version: cvs Component: other Category: feature requests Priority: normal Assigned to: Anonymous Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/devel_GET_params_core.patch (2.38 KB) This patch allows admins who are using devel.module to optionally toggle the page timer, query logger and page redirection for each request using GET parameters rather than navigating to admin/settings/devel and flipping the global settings back and forth. I added this since I usually don't need to print out this information for every page. Now I just use: http://example.com/index.php?q=node&dev_query=1 for the request I'm interested in. Two other params can also be toggled: dev_timer and dev_redirect. mathias

4 5

[drupal-devel] [bug] Always resizing user pictures breaks transparency?
by leafish_paul 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/24946 Project: Drupal Version: 4.6.1 Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: leafish_paul Updated by: leafish_paul Status: patch Attachment: http://drupal.org/files/issues/user.module_tweaked_picture_resizing.patch (1.47 KB) I recently noticed that when uploading transparent user pictures to a Drupal site, the transparent colour is lost (replaced with black). I think its to do with image_size()... but I noticed the slightly odd logic in user.module: <?php if (!$info || !$info['extension']) { form_set_error('picture', t('The uploaded file was not an image.')); } else if (image_get_toolkit()) { image_scale($file->filepath, $file->filepath, $maxwidth, $maxheight); } else if (filesize($file->filepath) > (variable_get('user_picture_file_size', '30') * 1000)) { form_set_error('picture', t('The uploaded image is too large; the maximum file size is %size kB.', array('%size' => variable_get('user_picture_file_size', '30')))); } else if ($info['width'] > $maxwidth || $info['height'] > $maxheight) { form_set_error('picture', t('The uploaded image is too large; the maximum dimensions are %dimensions pixels.', array('%dimensions' => variable_get('user_picture_dimensions', '85x85')))); } ?> So, the image is always scaled if an image toolkit is found. The attached patch /only/ scales user pictures if they are too large, and will still show an error if a toolkit is not found. I'm aware that there may be a better patch for image.inc to retain scaled image transparency? leafish_paul

2 2

[drupal-devel] [task] Small improvement in settings.php to make it clearer for noobs
by Bèr Kessels 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/24563 Project: Drupal Version: 4.6.0 Component: other Category: tasks Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/settings_clarify.patch (814 bytes) I was just following a complete newbie when he installed Drupal. I will skip the database-import part, it was hell :) But more important, IMO is that he could not really read the documentation in settings.php correctly. He assumed the part localhost/database in mysql://username:password@localhost/database referred to his database directory. Since he was working on localhost, and knew nothing of the concept of a SQL server, this is not too odd. So I chnaged this into mysql://username:password@databaseserver/databasename in the attached patch. The filled out example reamins the same, with localhost in the url (since 99% has localhost as sql server) Note: I purposely did not user database_name, sinxce that will be confused with the prefix documentation, which uses the _ in its examples. And I hate (or well... dislike) CamelCase. Bèr Kessels

3 4

[drupal-devel] more core comitters
by Bèr Kessels 02 Aug '05

02 Aug '05

Hello, Steven already pointed out that the patch queue is growing fast. nearly ten pages, now. Yes, closing them helps, but I found that a lot of issues are actually very good. Some are old, some can indeed be closed, some wont apply, but the average sits there with one or two +1s in em. I think tha that indicates tha two core comitters is just too little to handle the flow of incoming patches. So hereby I wuold like to ask the following people if they wuold be interested in becoming core committers. And -off course- what everyone, specially Dries, thinks of more/these people as potential core contributors? Gerhard, Moshe and John vanDyk. Please do not feel offenced if i did not mention you :) I think these people are good candidates, because they have a lot of available time, and because they, IMHO, are very carefull and precise in reviewing patches. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

15 30

[drupal-devel] [bug] cvs node.module incorrectly assumes 404 when access denied
by willmoy 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27873 Post a follow up: http://drupal.org/project/comments/add/27873 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: willmoy Status: patch (code needs review) Later cousin of http://drupal.org/node/27864 for 4.6.2 To reproduce: - Take a page which is denied to anonymous users by node_privacy_byrole - Go to it as an anonymous user - Receive 404 error cvs shares the same code for both the view and edit ops, so a slightly larger patch willmoy

2 3

[drupal-devel] RFC: drupalversions.module
by eric Farris 01 Aug '05

01 Aug '05

A common request in Drupalspace is a way to keep track of which version of Drupal is running on a Drupal site. While the CHANGELOG.txt file will show the current version, that's not entirely accurate, as pieces of the code could be patched, contributed modules could be installed, or the site could be some version of Drupal HEAD (where the changelog version is moot). What is needed is a single, agreed-upon method of discovering and reporting the versions of the various code used in a Drupal installation. What I propose is a drupalversions.module to handle this task. The features of such a module should be: * discovery of the CVS $Id$ tags of every .module, .inc, .theme, .css .xtmpl, etc. storing of these version numbers * comparison of these versions to official Drupal releases, and reporting of variations from the standard release numbers reporting of all non-core files and their version numbers * a good report that could be requested by drupal-support to assist in bug tracking and problem solving. Advanced features could be: * versions of contributed modules that correspond to official Drupal core releases. For example, the author of image.module could specify that version 1.220 is the first version to be used with Drupal 4.6.0, and that it is compatible with 4.6.1 and 4.6.2, but image.module 1.224 should be used with Drupal 4.6.3, and 1.230 is for Drupal HEAD only. So the drupalversions schema would have to store the filenames of all files in the Drupal core and the version numbers of the official releases. This would have to be easily extendable/accessible by contributed modules through a hook or api. We should support problems like this (examples only): * "node.module 1.410.2.6 is the official version for Drupal 4.6.0." * "For Drupal 4.6.2, Image.module should be 1.224 or higher." * "weblink.module 1.30 requires common.inc version 1.401.2.3 or higher." * This installation is a 4.6.2 version of Drupal, except that the node.module and search.module appear to be newer, and the following contrib modules are installed..." What I'm not addressing is the question of patches. It would be simple enough, I think, to store MD5 hashes from the 'official' module and have hook_cron periodically compute the hashes and compare them with the db, which would then appear on the admin report which files weren't in sync with their official versions. How would all of this fit in to the install system? I am in no position to start contributing code to this at present, but I plan on doing so if there is such a need. I still don't know what the hook would look like or what the schema would be. So... what do you think, sirs? -- e one inch frame: http://eafarris.al.umces.edu/

10 12

[drupal-devel] [feature] Per-User Input-Format Preferences
by jchris 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/26036 Project: Drupal Version: 4.6.1 Component: filter.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jchris Updated by: jchris Status: patch Attachment: http://drupal.org/files/issues/filter.module_9.patch (1.61 KB) Here's a patch to filter.module that allows users to set their preferred input format, when multiple formats are available. A selection of available formats is added to the user-account editing page. The user's selection is persistent and is used to initialize the input-format selector on the node-editing pages. This patch requires an addition of an 'input_format' field to the {users} table: alter table users add input_format int(4) NOT NULL default '0'; I'm not 100% sure I did this correctly. I'm no PHP coder. Anyway, it seems to work. Patch file is attached. Enjoy. jchris

3 4

[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