April 2005 - Development - lists.drupal.org

[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] Order taxonomy_select_nodes
by tostinni 17 May '05

17 May '05

Issue status update for http://drupal.org/node/20963 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tostinni Updated by: tostinni Status: patch Attachment: http://drupal.org/files/issues/taxonomy_order-node.patch (2.36 KB) A very simple patch to provide an (too ?) easy way to configure how order selected nodes in a taxonomy_select_nodes call. I think we could provide such way for each module that make a call to this functions. tostinni

3 3

[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] Field location in table locales_source is too short in PostgreSQL
by patryk 08 May '05

08 May '05

Issue status update for http://drupal.org/node/21252 Project: Drupal Version: cvs Component: postgresql database Category: bug reports Priority: normal Assigned to: patryk Reported by: patryk Updated by: patryk Status: patch Attachment: http://drupal.org/files/issues/drupal-cvs-pgsql-locales_field_type-fix.diff (317 bytes) Field "location" in table "locales_source" is too short. The patch makes it limitless. patryk

5 12

[drupal-devel] [bug] htaccess - rewriteengine giving error 500
by JohnG 06 May '05

06 May '05

Issue status update for http://drupal.org/node/21385 Project: Drupal Version: 4.6.0 Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: JohnG Updated by: JohnG Status: patch problem: (I'm guessing this falls into the filesystem category ... please feel free to move it if appropriate) immediately following upgrade from 4.5.2 (2005.03.15) to 4.6.0 (on linux-apache-mysql-php server) getting error 500 reports everytime I click a link (from the admin or home page). The problem seems to lie about 3 or 4 lines from the end of the htaccess file: the ReWriteRule is missing a backslash preceding index.php. it did look like this RewriteRule ^(.*)$ index.php?q=$1 [L,QSA] it should look like this RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA] in context, this is the end of the htaccess file, with the correction: # Rewrite current-style URLs of the form 'index.php?q=x'. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA] </IfModule> # $Id: .htaccess,v 1.66 2005/03/20 19:15:00 dries Exp $ A number of other solutions have been put forward for this recurring problem. I found this solution from a 4.4 issue at http://drupal.org/node/7836. It seems to work just fine and is obviously preferable to disabling the Htaccess or ReWriteEngine and losing clean URLs. good luck to y'all JohnG JohnG

2 1

[drupal-devel] [feature] User ID shouldn't be displayed at User administration page
by stefan nagtegaal 05 May '05

05 May '05

Issue status update for http://drupal.org/node/21416 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: stefan nagtegaal Status: patch Attachment: http://drupal.org/files/issues/user-module_0.patch (989 bytes) While we do not display ID's anywhere inside drupal (even node id's not), this is imo a bug. The user overview tables displays the user ID, whic shouldn't be the case.. Simple patch attached, please comment and apply... stefan nagtegaal

3 4

[drupal-devel] [feature] Fast file-based locking
by Jeremy 05 May '05

05 May '05

Issue status update for http://drupal.org/node/21556 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org Status: patch Attachment: http://drupal.org/files/issues/lock_6.patch (13.74 KB) There are several race conditions in Drupal's core code. When these races happens, most of the time they simply show up as an error in the watchdog log. However, in some instances the errors can happen early enough in page generation to show up on the page, preventing the page from being displayed properly. The busier a site gets, the more likely this is to happen. The attached patch implements file-based locking to prevent race conditions. It utilizes PHP's flock() mechanism to provide locking. This will not work on NFS (and possibly other networking filesystems) or VFAT filesystems. Comments are very welcome. An alternative form of locking for NFS users could be implemented, using the creation of directories. However, this increases the complexity so I am not interested in even looking into such a solution until a basic solution (such as the attached) is first merged. I am using lock.inc on a 4.5 installation on KernelTrap.org to prevent the race in variable_set, and it seems to be working perfectly. ----- Some suggested discussion points: 1) Currently I use the names lock_rlock(), lock_rwlock(), and lock_unlock(). An rlock is a shared lock. A rwlock is an exclusive lock. Perhaps lock_shared_lock() and lock_exclusive_lock() would be more clear? Or, we could just have a lock_lock() function that accepted an additional flag for SHARED (READ) and EXCLUSIVE (READ/WRITE)? 2) Everything is in lock.inc. I had originally intended to put the generic api into lock.inc, and the specific locking implementation (lock_file_... in this case) in lock.module. However, locks are required in bootstrap.inc before modules are loaded. I did write some logic to check the system table to see if the lock module was enabled, and thus to determine if we should use locks, but as this added an extra db_query per page load I decided it wasn't worth it. An alternative idea is to create multiple lock include files. lock.inc, lock.file.inc, lock.dir.inc, lock.db.inc, etc. However, until there are actually multiple implementations, there is no point in this. 3) Some sites may not want to use locking, so I have added a configuration option in the system module to allow it to be disabled. Locking is disabled by default. (If you don't have a busy site, why bother with extra complexity?) Efficient file-based locking requires garbage collection, which is called from system_cron(). 4) A truly sanitized file name would be limited in length. Different filesystems have different length limitations. What is a sane choice? Too short, and locks won't be unique. Too long, and locks may not work properly on certain filesystems. (Or perhaps we can just rely on the filesystem to auto-truncate?) ----- The patch: - introduces lock.inc - adds lock.inc, and file.inc to bootstrap.inc - removes file.inc from common.inc - adds locks to bootstrap.inc, user.module, and statistics module - adds a configuration option and cron logic to the system.module Jeremy(a)kerneltrap.org

3 12

[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] node-associated image module--advice wanted
by Nedjo Rogers 05 May '05

05 May '05

I'm thinking of upgrading my old node_image module and looking for some advice. The basic aim: to have node-associated images in two sizes--full and thumbnail, to display in node lists and full displays. When I wrote the module, a thumbnail image could be displayed with the node 'teaser' (e.g., on a taxonomy term page) and a full size image with the full node display. The module also included inline image uploading and taxonomy term image association. I didn't upgrade node_image for 4.5, mainly because new modules had been produced replicating much of the functionality (image_assist for inline image uploading, taxonomy_image for term images), and doing a better job. But, to my knowledge, we don't have another way of associating images with nodes. What I'm wanting advice on is, what approach to take? We've come a long ways in image handling in Drupal, but we still have a number of somwehat incompatible approaches. We can now associate images with users, themes, taxonomy terms, and nodes, but in each case there's different logic and user interface. 1. The user atavars (images associated with users). This approach adds a field to the user create/edit form, uploads an image file, and stores the file reference in a "picture" field (in the user table). 2. The theme screenshots (images associated with themes). I haven't looked closely at the implementation logic. 3. The taxonomy_image module (images associated with taxonomy terms). This approach handles images separately from taxonomy term creation/editing and creates, storing image path information in a dedicated table. 4. The (new and improved) image.module (images as nodes). This includes support for multiple sizes (e.g., thumbnails) and handles each image as a node. The question: which of these approaches is the best model for node-associated images? Which one would be the best to follow in the interests of moving toward a uniform approach to image association?

6 9