September 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Error with file api and open_basedir restriction
by Goba 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/5961 Post a follow up: http://drupal.org/project/comments/add/5961 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: Goba Status: patch (code needs review) This needs to get fixed for Drupal 4.7, or otherwise Drupal is not "hosted environment friendly". People cannot even start with importing a translation with open_basedir restrictions (which is quite common here in Hungary, because of security precautions). Goba Previous comments: ------------------------------------------------------------------------ Fri, 20 Feb 2004 19:45:36 +0000 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir.patch (1018 bytes) I get this error when uploading a file through the file api, and the upload fails: warning: open_basedir restriction in effect. File is in wrong directory in... This happens when open_basedir restriction is activated and the temporary directory is not in the allowed directories. There's a related bug in the profile.module: http://drupal.org/node/view/2648 [1] FIX: The solution is to upload files using php's 'move_uploaded_file' -which works even when open_basedir restriction is in effect. This patch checks for the error conditions in 'file.inc::file_check_upload', and then uses move_uploaded_file to upload the file to the temporary folder with a random name. Otherwise -if the error conditions are not met-, does nothing. RESTRICTIONS: This patch introduces one additional restriction for the file api: Once you have called 'file_check_upload', you have to use the returned object when calling later 'file.api::file_save_upload'. This shouldn't be a problem, as the right way to upload files should be -I think, please correct me if I'm wrong-: - $file=file_check_upload(); - (Perform validations with $file) - file_save_upload($file,.....) I will post also a very simple patch for profile.module to work with this one. Anyway, as mentioned above, if the error conditions are not met, the patch does nothing, so I think it should be applied first and then check for other modules (profile.module) to use the file api the right way and then be able to upload files when open_basedir restriction in effect. [1] http://drupal.org/node/view/2648 ------------------------------------------------------------------------ Sun, 28 Nov 2004 17:38:25 +0000 : Goba This seems to be an interesting alternate fix to my dump patch for locale.module [2], which is the very same issue... Moving the file out of the upload folder right away to the Drupal temp folder seems to be a good idea to me. The only caveat is that files in the upload folder get removed automatically, while one needs to remove the file from the Drupal temp folder, once it is not needed anymore! [2] http://drupal.org/node/13285 ------------------------------------------------------------------------ Wed, 08 Dec 2004 19:26:18 +0000 : Goba Please look at this stuff. We need to solve open_basedir problems at least in core before the next point release. There are quite a few users trying to use Drupal on shared hosting here, where open_basedir is in effect. ------------------------------------------------------------------------ Fri, 18 Feb 2005 01:55:21 +0000 : clydefrog This functionality gets a +1 from me, the user. We solved this problem by changing upload_tmp_dir in the server config, but a fix in Drupal would be more elegant. ------------------------------------------------------------------------ Sun, 13 Mar 2005 19:41:56 +0000 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ Mon, 14 Mar 2005 11:05:08 +0000 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir_02.patch (810 bytes) Just resubmitted the patch. The problem is, from the time I sent the first patch , I've moved all my sites, no shared webhosting anymore, so I don't have that upload trouble anymore, and also cannot test it myself. That's also why I'm unassigning this issue to me. So please, somebody else test it. ------------------------------------------------------------------------ Fri, 15 Apr 2005 20:49:50 +0000 : mpd Attachment: http://drupal.org/files/issues/file.inc-file_relocate.patch (3.87 KB) I gave your patch a try. It applies fine but doesn't address several issues, particularily with the image module. The attached patch makes attachments work, along with image (from cvs). I haven't seen any ill effects yet, but I believe that file_delete must be used to avoid getting a build-up of dead files in the local temporary directory (set to getcwd().'/tmp'). This isn't a problem with my install, but it might be a problem with other modules. In order for the patched code to work, $drupal/tmp must exist and be writable by the web server. ------------------------------------------------------------------------ Thu, 05 May 2005 17:33:15 +0000 : nedjo Attachment: http://drupal.org/files/issues/file_open_basedir_03.patch (817 bytes) +1 for Jose's patch (I've attached an updated version, which I've tested successfully. The new version uses $file->filepath rather than $file->path and cleans up the code a bit.) While the larger patch suggested may have merit, I don't fully follow it (not knowing what the image module issues are). I'd like to see the identified problem fixed first, and quickly. Later cleanup and further patches can follow. This is a significant issue, meaning many in hosted environments can't use Drupal's file uploading. This has come up at least twice in the help forums. Jose's solution is simple. Let's apply it! This same changes work for 4.6. ------------------------------------------------------------------------ Thu, 05 May 2005 19:07:35 +0000 : mpd I'll describe the issue that I found with file.inc concerning image.module. >From what I've seen, image.module calls file_copy() directly from _image_insert(). file_copy() doesn't call file_check_upload(), so the open_basedir problem remains because file_copy() attempts to access the file while it's still in the restricted directory. I'm sure that there's a cleaner way to do it, but the patch that I submitted does the trick for my purposes by addressing problems with both file_copy() and file_check_upload(). I'll have a go at making a smaller patch that only addresses the issue with file_copy(), since Nedjo's patch neatly fixes file_check_upload(). ------------------------------------------------------------------------ Thu, 05 May 2005 20:41:19 +0000 : nedjo It seems likely that the image module issue - with using file_copy() directly - can be addressed by adding a file_check_upload() call in the file_copy() function by changing <?php // Process a file upload object. if (is_object($source)) { $file = $source; ?> to <?php // Process a file upload object. if (is_object($source)) { $file = file_check_upload($source); ?> I can't immediately test this. Do you want to, mpd? ------------------------------------------------------------------------ Tue, 30 Aug 2005 11:57:09 +0000 : Jose A Reyero I wanted to forget about this but the patch bingo keeps bringing me here :-( , so... I've enabled open_basedir, tested nedjo's revised patch, which still applies and it actually fixes the problem. Sure there can be other solutions -like reworking the whole file api- but this one works and is simple enough and it only does something when the error conditions are met. On top of that, the current file api fails to produce an error when this problem occurs, it just doesnt work without any clue of what is happening, which is really bad. So please apply this one. + 1

1 0

[drupal-devel] [bug] Forum table: vid gone AWOL
by m3avrck 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31343 Post a follow up: http://drupal.org/project/comments/add/31343 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: critical Assigned to: Souvent22 Reported by: robertDouglass Updated by: m3avrck -Status: patch (code needs review) +Status: patch (ready to be committed) Code looks good to me. m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 21:02:54 +0000 : robertDouglass The function forum_load consists entirely of this query: function forum_load($node) { $forum = db_fetch_object(db_query('SELECT * FROM {forum} WHERE vid = %d', $node->vid)); return $forum; } The forum table, however, has no vid column. What should it be? WHERE nid = %d ? I haven't been following the changes to forum.module closely, so I don't know the rest of the issues involved, but the module doesn't work as is. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:20:49 +0000 : syllance There's also en error when simply adding forum topic : user error: Unknown column 'vid' in 'field list' query: INSERT INTO forum (nid, vid, tid) VALUES (6, 6, 2) in /drupal/head/database.mysql.inc on line 99. Sounds like the removed vid field in forum table is still used in forum.module queries. The forum topic node is inserted, but not linked with forum due to this error, so that's blocking the use of forums. I've quickly searched but could not find any patch for this. I'll double check and try to make one if needed. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:55:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/ref_error_0.patch (4.64 KB) Yes, vid should be the second column, just as the query says, INSERT INTO....(nid, vid,tid).... Seems you have the code for this, but you havne't updated your database with update.inc, i'm not sure if there is an update to the forum table in update.inc..... Well, nevermind, a quick check shows that in updates.inc, it does alter your tables for you and fix the problem, however, the current schema in database.mysql and database.pgsql does *not*. Here's a patch that fixes that. So in short, form.module has been updated to use revisions, however, you're missing a vid field in your table. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:58:04 +0000 : Souvent22 Update status; anyone wanna take a look? ------------------------------------------------------------------------ Fri, 16 Sep 2005 18:01:31 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/database_forum.patch (1.27 KB) Crap, wrong patch. :). Too many things at once, sheesh. Get stable already Drupal! :). Anyway, here's the right one....I aplogize, ignore the other ones. ------------------------------------------------------------------------ Fri, 16 Sep 2005 18:06:57 +0000 : Souvent22 Just to clairfy, update_146() in updates.inc does correctly update the forum table and add the vid column. However, the databaswe creation scripts (database.mysql, database.pgsql) do NOT have the correct new schema for the forum table. ------------------------------------------------------------------------ Sat, 17 Sep 2005 01:14:28 +0000 : syllance I was surprised to find such an issue, even in head :) And i was right. I've been reading the node revisions changes, and just thought the database script were not updated yet. I simply did not thought to check the update script. That will be in my check list now, as everything works fine after running the update. Thanks for your quick answer, and thanks again to everyone making drupal such a nice thing :) ------------------------------------------------------------------------ Sat, 17 Sep 2005 10:11:26 +0000 : robertDouglass If all that is missing is the vid column from the database creation scripts, this patch should be a no brainer. Here is the pertinent SQL patch for those on the list that don't want to look for the patch: CREATE TABLE forum ( nid integer NOT NULL default '0', + vid integer NOT NULL default '0', tid integer NOT NULL default '0', shadow integer NOT NULL default '0', PRIMARY KEY (nid) ); CREATE INDEX forum_tid_idx ON forum(tid); +CREATE INDEX forum_vid_idx ON forum(vid); CREATE TABLE forum ( nid int(10) unsigned NOT NULL default '0', + vid int(10) unsigned NOT NULL default '0', tid int(10) unsigned NOT NULL default '0', PRIMARY KEY (nid), + KEY vid (vid), KEY tid (tid) ) TYPE=MyISAM; It looks good to me. ------------------------------------------------------------------------ Sat, 17 Sep 2005 11:58:00 +0000 : syllance i've quickly checked on my test sandbox, and there's a "duplicate" entry error when creating a forum topic revision. the update is to add the vid field, create a primary key on it, and make nid a non-primary key. i'll try to provide updated patches later today, but mysql changes should something like : CREATE TABLE forum ( nid int(10) unsigned NOT NULL default '0', + vid int(10) unsigned NOT NULL default '0', tid int(10) unsigned NOT NULL default '0', - PRIMARY KEY (nid), + KEY (nid), + PRIMARY KEY vid (vid), KEY tid (tid) ) TYPE=MyISAM; (manual patch :p, i'll do the thing later) while talking database, do you know if there's any specific reason why all drupal tables are forced MyISAM type ?

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by der 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: der Status: patch (code needs review) If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? der Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users. I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids? Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance Nice job :) the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly. i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version. hope this will go into core soon, as it really makes the first admin pages contact better :) i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p thanks ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better.

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by chx 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: chx Status: patch (code needs review) Maybe just because I created it, I like my control panel module better. chx Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users. I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids? Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance Nice job :) the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly. i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version. hope this will go into core soon, as it really makes the first admin pages contact better :) i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p thanks ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons?

1 0

[drupal-devel] [feature] Bittorrent node type - v 0.2
by mathiaz 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31436 Post a follow up: http://drupal.org/project/comments/add/31436 Project: Drupal Version: 4.6.3 Component: other Category: feature requests Priority: normal Assigned to: Anonymous Reported by: mathiaz Updated by: mathiaz Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal-module-0.2.tgz (35.47 KB) This a bittorrent node type that integrates the bittorrent tracker (http://drupal.org/node/31435) with drupal. It is based on the bittorrent node type (http://drupal.org/node/29985) It handle bittorrents files with user statistics. It creates two blocks that display user and tracker statistics. Let me know what you think about it. Mathiaz mathiaz

2 1

[drupal-devel] [feature] Administration Control Panel suggestion
by der 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: der Status: patch (code needs review) I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? der Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users. I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids? Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance Nice job :) the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly. i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version. hope this will go into core soon, as it really makes the first admin pages contact better :) i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p thanks !

1 0

[drupal-devel] [feature] Auto-expand navigation menu options on mouseover
by nedjo 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/29551 Post a follow up: http://drupal.org/project/comments/add/29551 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: nedjo Status: patch (code needs review) Attachment: http://drupal.org/files/issues/expandable_menu.patch (2.16 KB) One or more unneeded page loads are often required to bring up the desired page through the navigation menu (e.g., administer > settings > content types). Using CSS, this patch introduces automatically expanding menu options. E.g., holding the mouse over "create content" will dynamically expand the menu, revealing the available options ("page", "story", etc.). Issues & questions: * Is this a desired behaviour? * Page loads are slightly larger, since they include hidden menu portions. * Not supported by, e.g., Internet Explorer due to CSS bugs. Downgrades cleanly, but means that functionality is not uniform across browsers. A js IE fix is available, see e.g., http://www.alistapart.com/articles/dropdowns/ but it's a big ugly. * Display is a bit jumpy. Slideouts or slowed transitions might be nice, but would I assume require javascript. * Introduced as the default behaviour, not as an option. Should this be a configuration option instead? The approach is based on suggestions and code [1] for the taxonomy_context module by eferraiuolo [2]. [1] http://drupal.org/node/29074 [2] http://drupal.org/user/24218\" title=\"View user profile. nedjo

9 21

[drupal-devel] [bug] node_invoke_nodeapi recursion
by Iluvatar 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31466 Post a follow up: http://drupal.org/project/comments/add/31466 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: Iluvatar Updated by: Iluvatar Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node.module_12.patch (696 bytes) I have had some weird problems, most of them involving hook_nodeapi. It is difficult to explain. For one of the problems see my comment at http://drupal.org/node/27007#comment-42637. Another problem was that I broke the upload module, by calling node_load in hook_nodeapi($op = 'validate') in some module. This caused node_invoke_nodeapi to be called recursively, which doesn't work as expected because of the caching that module_implements does. Sorry, I know all of this is kind of vague, but I can't explain it any better. You can take a look at my patch how I solved the problem. I think this patch does not have any impact on performance, and to prevent unexpected behavior involving hook_nodeapi this patch should be committed. If this patch is committed, a comment should be added to the code so that future developers will not change it back. Iluvatar

1 1

[drupal-devel] [feature] Administration Control Panel suggestion
by syllance 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: syllance Status: patch (code needs review) Nice job :) the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly. i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version. hope this will go into core soon, as it really makes the first admin pages contact better :) i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p thanks ! syllance Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users. I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids? Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) )

1 0

[drupal-devel] [bug] Forum table: vid gone AWOL
by syllance 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/31343 Post a follow up: http://drupal.org/project/comments/add/31343 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: critical Assigned to: Souvent22 Reported by: robertDouglass Updated by: syllance Status: patch (code needs review) i've quickly checked on my test sandbox, and there's a "duplicate" entry error when creating a forum topic revision. the update is to add the vid field, create a primary key on it, and make nid a non-primary key. i'll try to provide updated patches later today, but mysql changes should something like : CREATE TABLE forum ( nid int(10) unsigned NOT NULL default '0', + vid int(10) unsigned NOT NULL default '0', tid int(10) unsigned NOT NULL default '0', - PRIMARY KEY (nid), + KEY (nid), + PRIMARY KEY vid (vid), KEY tid (tid) ) TYPE=MyISAM; (manual patch :p, i'll do the thing later) while talking database, do you know if there's any specific reason why all drupal tables are forced MyISAM type ? syllance Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 21:02:54 +0000 : robertDouglass The function forum_load consists entirely of this query: function forum_load($node) { $forum = db_fetch_object(db_query('SELECT * FROM {forum} WHERE vid = %d', $node->vid)); return $forum; } The forum table, however, has no vid column. What should it be? WHERE nid = %d ? I haven't been following the changes to forum.module closely, so I don't know the rest of the issues involved, but the module doesn't work as is. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:20:49 +0000 : syllance There's also en error when simply adding forum topic : user error: Unknown column 'vid' in 'field list' query: INSERT INTO forum (nid, vid, tid) VALUES (6, 6, 2) in /drupal/head/database.mysql.inc on line 99. Sounds like the removed vid field in forum table is still used in forum.module queries. The forum topic node is inserted, but not linked with forum due to this error, so that's blocking the use of forums. I've quickly searched but could not find any patch for this. I'll double check and try to make one if needed. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:55:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/ref_error_0.patch (4.64 KB) Yes, vid should be the second column, just as the query says, INSERT INTO....(nid, vid,tid).... Seems you have the code for this, but you havne't updated your database with update.inc, i'm not sure if there is an update to the forum table in update.inc..... Well, nevermind, a quick check shows that in updates.inc, it does alter your tables for you and fix the problem, however, the current schema in database.mysql and database.pgsql does *not*. Here's a patch that fixes that. So in short, form.module has been updated to use revisions, however, you're missing a vid field in your table. ------------------------------------------------------------------------ Fri, 16 Sep 2005 17:58:04 +0000 : Souvent22 Update status; anyone wanna take a look? ------------------------------------------------------------------------ Fri, 16 Sep 2005 18:01:31 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/database_forum.patch (1.27 KB) Crap, wrong patch. :). Too many things at once, sheesh. Get stable already Drupal! :). Anyway, here's the right one....I aplogize, ignore the other ones. ------------------------------------------------------------------------ Fri, 16 Sep 2005 18:06:57 +0000 : Souvent22 Just to clairfy, update_146() in updates.inc does correctly update the forum table and add the vid column. However, the databaswe creation scripts (database.mysql, database.pgsql) do NOT have the correct new schema for the forum table. ------------------------------------------------------------------------ Sat, 17 Sep 2005 01:14:28 +0000 : syllance I was surprised to find such an issue, even in head :) And i was right. I've been reading the node revisions changes, and just thought the database script were not updated yet. I simply did not thought to check the update script. That will be in my check list now, as everything works fine after running the update. Thanks for your quick answer, and thanks again to everyone making drupal such a nice thing :) ------------------------------------------------------------------------ Sat, 17 Sep 2005 10:11:26 +0000 : robertDouglass If all that is missing is the vid column from the database creation scripts, this patch should be a no brainer. Here is the pertinent SQL patch for those on the list that don't want to look for the patch: CREATE TABLE forum ( nid integer NOT NULL default '0', + vid integer NOT NULL default '0', tid integer NOT NULL default '0', shadow integer NOT NULL default '0', PRIMARY KEY (nid) ); CREATE INDEX forum_tid_idx ON forum(tid); +CREATE INDEX forum_vid_idx ON forum(vid); CREATE TABLE forum ( nid int(10) unsigned NOT NULL default '0', + vid int(10) unsigned NOT NULL default '0', tid int(10) unsigned NOT NULL default '0', PRIMARY KEY (nid), + KEY vid (vid), KEY tid (tid) ) TYPE=MyISAM; It looks good to me.

1 0