January 2005 - Development - lists.drupal.org

[drupal-devel] [bug] files folder created with incorrect permissions
by arnabdotorg 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Anonymous Updated by: arnabdotorg Status: patch Here's one way: Define: MIN_FILE_PERMS, MID_FILE_PERMS, MIN_DIR_PERMS, MID_DIR_PERMS (e.g. 640, 666, 711, 771) In the "admin" page (where "files" is checked for writability) 1. Create a file 2. Set it to MIN_FILE_PERMS 3. Delete it 4. If 3 fails, Set it to MID_FILE_PERMS. If does not fail, Set variable for DRUPAL_FILE_PERMS to MIN_FILE_PERMS 5. Delete it 6. if 5 fails, throw error that files are not writable/deletable. 7. If 5 does not fail, Set variable for DRUPAL_FILE_PERMS to MID_FILE_PERMS Do the same thing for directories. Also, I wont mind 3x2 checkboxes for Directories and File perms for more detailed control _in addition_ to the above algo (the above algo can be the "validate" part of the 3x2. arnabdotorg Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 18:04 : Anonymous Hi,- > [rreading@tribal html]$ ls -l www/files > total 12 > drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures > drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp > drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload the problem is very strange, and might even be a nasty drupal bug: As of the CVS version we decided to let drupal generate the folders itself, so that Joe User needs not to use ssh or ftp to make /configure various folders. So these were generated by PHP and thus have the wrong permission. The user PHP is a differnet user in this case, and something that PHP created is inacessible to us. I am aware that this is sierverspecific, but its annoying enought for me (and probably others) not to ignore. Regards, Ber ------------------------------------------------------------------------ November 19, 2004 - 02:46 : dtan Any update on this. . ?? I recently installed the 4.5 Head and the problem still exists. Recommendations on how to actually change the permission on the folder? dtan ------------------------------------------------------------------------ November 28, 2004 - 15:53 : killes(a)www.drop.org The apache user did create this directories. So it is natural that they have the apache user "nobody" as owner. Drupal should be able to handle this just file. Can we close this report? ------------------------------------------------------------------------ November 28, 2004 - 15:58 : Bèr Kessels No, please do not close. Its a bug IMO. Because a lot of (v)hosts do not put apache in the same group as the FTP user. It will work, file uplaods etc will work for Drupal, but you, as user, cannot access the files anymore by FTP. But even worse, you cannot remove your drupal installation, without intervention of root (or the server maintainer). I had two "empty" domains with 30 MB of files taking up space for 3 months. Another domain will not let me mirror (backup) anything because of this. ------------------------------------------------------------------------ November 30, 2004 - 03:55 : svemir If PHP/apache can create these folders, it should be able to remove them as well. Perhaps an option somewhere to remove folders created by Drupal? Maybe a button next to the place in administration where the folder is specified. And also maybe the creation of the folders should be optional in the first place... ------------------------------------------------------------------------ January 20, 2005 - 01:52 : Morbus Iff This just bit me today too. Installed the banner.module, and ensured that my files/ directory was 777, with the owner as gangrene:user. Uploaded a new banner, and for various reasons, it didn't work. As I started to investigate, I found that the files/banner directory, which was "successfully" created (success determined by "I can access files uploaded in that folder via a URL) was not visible to my FTP server (at this point, proFTPd, though I've not yet tested on vsftpd). One of ProFTPds feature is to hide folders that do not have the executable bit set. The default permissions of Drupal is not to set these, per file_check_directory in includes/file.inc. So, my newly Drupal-created files/banners folder was given the permissions of (where wwwrun and nogroup are the Apache user/group). drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners Since there's no execute for everyone, and since the "gangrene" user is not part of "nogroup", I was not able to see, access, or modify the newly created folder. I had to manually issue chmod('files/banners', 0761) to even look at the blasted thing. My recommendation is to change the file_check_directory chmod to 0771, which should create drwxrwx--x permissions. The extra execute permission on the "nogroup" is harmless, and allows ProFTPd to display it (in this case to "nogroup", but also perhaps to the "users" group on other systems), and the execute permission for everyone is absolutely required for me to see it in under ProFTPD. These permissions are giving any extra (or damaging) permissions to anyone, but merely following the expectations of various FTP servers concerning "what a directory is". There's a similar bug related to uploaded files, but I've not yet found the code for that one. ------------------------------------------------------------------------ January 20, 2005 - 01:55 : Morbus Iff Grrrr... "these permissions are NOT giving any extra (or damaging) permissions". ------------------------------------------------------------------------ January 20, 2005 - 02:12 : Morbus Iff To revise my previous statement, it would be best to use perms 0765, which adds "read" access to the "everyone" group. The correction is simple: if we want to /see/ the folder in FTP, then we also want to see /inside/ the folder via FTP. Again, I don't believe this change really gives extra dangerous permissions to anyone, merely grants the same permission to an authenticated FTP user (if a file upload can be seen on the web by people who know its there, then the same access should be applied to FTP users with the right knowledge [ie., un/pw]). ------------------------------------------------------------------------ January 20, 2005 - 02:29 : Morbus Iff Alrighty, hunted down the file (not directory) related problem. Unlike directories, which require us to enter a mode, file uploads are not specified, thus they take on the default umask of the web server's user (in my case, wwwgroup:nogroup, 640). This further causes problems with FTP viewing because "everyone" has no permission (in my case, since I'm a part of the "users" group, I can not view, modify, delete, mirror, etc. files that have been uploaded through Drupal). This has been tracked down to file_copy() (includes/file.inc) and the following lines, which copy the uploaded file from the temp directory ($source) to the final destination ($dest). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } My proposal is to add an explicit chmod after the copy, granting read permission to "everyone", something to the effect of the following, which will give read and write to the webserver process, read to the webserver group, and read to everyone (ie., little old me, not of the webserver group). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } chmod($dest, 0644). ------------------------------------------------------------------------ January 20, 2005 - 02:40 : Morbus Iff Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes) Attached is a patch for Drupal 4.5.1 that implements these changes (directory is set for 764, not 765 - the mode in my previous comment was [another] error). Last time I contributed a patch, I created a bug so please review extra carefully. ------------------------------------------------------------------------ January 20, 2005 - 16:27 : Morbus Iff In chatting about this with #drupal, I'm thinking that something more than just "sane defaults" needs to be enabled. The patch I just submitted still has one "fatal" flaw: it doesn't allow write permissions for the FTP user. This was ultimately deliberate (more chance of accepting the patch with less dangerous permission, and the assumption that a Drupal-controlled upload also offered a Drupal-controlled deletion), but still isn't ideal. Unfortunately, with SuEXEC servers and various configurations, there is no SAFE default: on one hand you're giving 666 to everyone because you have to (wwwrun:nogroup) and on the other, 666 is too much (if you're running under SuEXEC, then gangrene:users/640 is right, and 666 is wrong). I think the only way this will be truly solved is with user intervention, which means umask settings for file/directory in the "Files" section of admin/setting. This is also the same solution that Movable Type uses, which allows two special settings in its mt.cfg: # When creating files and directories, Movable Type uses umask settings to # control the permissions set on the files. The default settings for file # creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for directory # creation (DirUmask), the default is 0000. You should not change these # settings unless you are running MT under cgiwrap or suexec, or some other # scenario where the MT application runs as you; in addition, you should not # change these settings unless you know what they mean, and what they do. # # DBUmask 0022 # HTMLUmask 0022 # UploadUmask 0022 # DirUmask 0022 # # In addition to controlling permissions via umask settings, you can also # use the HTMLPerms and UploadPerms settings to control the default # permissions for files created by the system (either as output files or # uploaded files). The only real use of this is to turn on the executable bit # of files created by the system--for example, if MT is generating PHP files # that need to have the executable bit turned on, you could set HTMLPerms # to 0777. The default is 0666. You should not change these settings unless # you know what they mean, and what they do. # # HTMLPerms 0777 # UploadPerms 0777 For our needs, we'd really only need a DirectoryUmask and a FileUmask option. Is this an amicable solution to anyone? If I get you a patch, will this be implemented in Drupal 4.6? ------------------------------------------------------------------------ January 21, 2005 - 16:58 : Morbus Iff After further reflection, I'm now leaning toward: * leave the current Drupal permissions as they are (ignore my previous patch). * add GUI options to change the directory/file mode (per last comment). The GUI would be two sets of dropdown boxes, one for files and one for directories. The automatically chosen option for Files would be "read/write for Drupal only" (umask: 0640), with another option of "read/write for everybody" (umask: 0666). The directory options would be the same with the following umasks 0771 or 0777. ------------------------------------------------------------------------ January 21, 2005 - 17:26 : Morbus Iff This is a list of known possibilities that the proposed patch/UI addresses. In each case, the proposed solution above will, BY DEFAULT, create directories as 771 and files as 640. These possibilities run through a number of ownership possibilities, and any solutions in regards to an FTP user. Possibility #1 (traditional): * Drupal runs as user wwwrun, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Pro: 777/666 is the only way this problem could be solved for FTP user. Possibility #2 (suexec/suPHP). * Drupal runs as user FTPuser, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. Possibility #3 (oddball configuration): * Drupal runs as user wwwrun, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directories. * FTP user WILL be able to view Drupal-created files. * FTP user WILL NOT be able to modify/delete Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Con: Gives "everybody" too many permissions. * Pro: This is an oddball config I've never seen. Possibility #4 (oddball configuration): * Drupal runs as user FTPuser, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. * Pro: This is an oddball config I've never seen. -- View: http://drupal.org/node/10658 Edit: http://drupal.org/project/comments/add/10658

1 0

[drupal-devel] Module for Review
by Michael Jervis 26 Jan '05

26 Jan '05

I've written another auth module. Contributions/modules/bloggerauth Could someone review it prior to me posting a project request. It's working here: http://www.fuckingbrit.com/other_sites/drupal/user/login It's about 1 degree more complex than the livejournal one. Cheers, Mike

1 0

[drupal-devel] cvs log messages
by no-reply＠zind.net 26 Jan '05

26 Jan '05

File: /sites/default/settings.php 1.5 Date: January 25, 2005 - 20:40 User: dries - Patch #16145 by adschar: replaced left-over 'conf.php' by 'settings.php'. ---------------------------------------------------------------------- File: /database/updates.inc 1.85 /modules/blog.module 1.210 /modules/legacy.module 1.4 Date: January 25, 2005 - 20:38 User: dries - Patch #16021 by tangent: changed the format "/blog/feed/52" to "/blog/52/feed". ---------------------------------------------------------------------- File: /modules/page.module 1.130 Date: January 25, 2005 - 20:29 User: dries - Patch #16181 by Ankur: fixed typo. ---------------------------------------------------------------------- File: /misc/drupal.css 1.93 /modules/user.module 1.433 Date: January 25, 2005 - 20:27 User: dries - Patch #16176 by Drumm based on mockup from Kika: improve access rules UI. ---------------------------------------------------------------------- File: /translations/ca/aggregator-module.po 1.3 /translations/ca/archive-module.po 1.3 /translations/ca/block-module.po 1.3 /translations/ca/blog-module.po 1.3 /translations/ca/blogapi-module.po 1.3 /translations/ca/book-module.po 1.3 /translations/ca/comment-module.po 1.3 /translations/ca/common-inc.po 1.3 /translations/ca/drupal-module.po 1.3 /translations/ca/file-inc.po 1.3 /translations/ca/filter-module.po 1.3 /translations/ca/forum-module.po 1.3 /translations/ca/general.po 1.3 /translations/ca/locale-inc.po 1.3 /translations/ca/locale-module.po 1.3 /translations/ca/menu-module.po 1.3 /translations/ca/node-module.po 1.3 /translations/ca/path-module.po 1.3 /translations/ca/ping-module.po 1.3 /translations/ca/poll-module.po 1.3 /translations/ca/profile-module.po 1.3 /translations/ca/queue-module.po 1.3 /translations/ca/search-module.po 1.3 /translations/ca/statistics-module.po 1.3 /translations/ca/story-module.po 1.3 /translations/ca/system-module.po 1.3 /translations/ca/taxonomy-module.po 1.3 /translations/ca/throttle-module.po 1.3 /translations/ca/upload-module.po 1.3 /translations/ca/user-module.po 1.4 /translations/ca/watchdog-module.po 1.3 Date: January 25, 2005 - 19:28 User: killes New PO files for 4.5 from Jordi. ---------------------------------------------------------------------- File: /modules/week/README.txt 1.1 /modules/week/WEEK.txt NONE Date: January 25, 2005 - 17:21 User: prometheus6 delete old readme file ---------------------------------------------------------------------- File: /modules/amazonsearch/amazon_search.readme.txt NONE /modules/amazonsearch/README.txt 1.1 Date: January 25, 2005 - 17:17 User: prometheus6 delete old readme file ---------------------------------------------------------------------- File: /modules/livediscussions/live_discussions.readme.txt NONE Date: January 25, 2005 - 17:15 User: prometheus6 delete old readme file ---------------------------------------------------------------------- File: /modules/livediscussions/README.txt 1.1 Date: January 25, 2005 - 17:10 User: prometheus6 Renaming the readme file ---------------------------------------------------------------------- File: Date: January 25, 2005 - 14:21 User: uwe Fixed typo. ---------------------------------------------------------------------- File: /translations/de/locale-inc.po 1.6 Date: January 25, 2005 - 14:20 User: uwe Proofreading of locale-inc.po, some minor corrections. ---------------------------------------------------------------------- File: /modules/print/print.tpl.php 1.4 Date: January 25, 2005 - 14:11 User: km km - honor themes' global settings for "Display post information" ---------------------------------------------------------------------- File: /modules/print/print.module 1.4 Date: January 25, 2005 - 13:52 User: km km - print_link() checks if page is a book ---------------------------------------------------------------------- File: /modules/print/MAINTAINERS.txt 1.2 Date: January 25, 2005 - 13:09 User: km km - changed maintainer ---------------------------------------------------------------------- File: /modules/news_page/news_page.module 1.3 /modules/news_page/README.txt 1.2 Date: January 25, 2005 - 11:54 User: MegaGrunt - input filter note in READ ME - Fixed bug in sql (thanks Budda) ---------------------------------------------------------------------- File: /modules/sitemap/INSTALL NONE /modules/sitemap/README.txt NONE /modules/sitemap/sitemap.module NONE Date: January 25, 2005 - 00:21 User: kbahey Removing this module from the repository, since it unintentionally revived an obsolete module on the project pages. ---------------------------------------------------------------------- File: Date: January 25, 2005 - 00:18 User: kbahey Initial commit to the Drupal contrib repository ---------------------------------------------------------------------- File: /modules/glossary/po/it.po 1.1 Date: January 24, 2005 - 23:59 User: matteo Mateo - Italian translation ---------------------------------------------------------------------- File: /translations/it/throttle-module.po 1.4 Date: January 24, 2005 - 23:58 User: matteo Mstteo - terminated translation ---------------------------------------------------------------------- File: Date: January 24, 2005 - 23:34 User: MegaGrunt send process flowchart ---------------------------------------------------------------------- File: Date: January 24, 2005 - 23:10 User: MegaGrunt Improved send que Addition of many UI elements ---------------------------------------------------------------------- File: /modules/front/po/it.po 1.1 Date: January 24, 2005 - 22:43 User: matteo Matteo - Italian translation ---------------------------------------------------------------------- File: /modules/profile.module 1.86 Date: January 24, 2005 - 21:39 User: dries - Patch #15937 by wulff: made it so that titles of profile fields only need to be unique within a single category. ---------------------------------------------------------------------- File: /modules/wiki/po/it.po 1.1 /modules/wiki/po/wiki.pot 1.1 Date: January 24, 2005 - 21:22 User: matteo Matteo - added Italian translation e .pot file ---------------------------------------------------------------------- File: /database/updates.inc 1.84 /includes/file.inc 1.35 /modules/comment.module 1.328 /modules/node.module 1.450 /modules/system.module 1.192 /modules/upload.module 1.20 Date: January 24, 2005 - 21:20 User: dries - Modified patch #14170 by Neil: improved default workflow (default node type) configuration page. Modified the patch to remove some redundant code, to translate strings, and to better use the menu system. ---------------------------------------------------------------------- File: /modules/event/po/it.po 1.1 Date: January 24, 2005 - 21:09 User: matteo Matteo - Italian translation ---------------------------------------------------------------------- File: /modules/forum.module 1.224 Date: January 24, 2005 - 21:01 User: dries - Patch #15977 by Neil: made the forum module suggest a menu item. ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:31 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:31 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:30 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:30 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:30 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:29 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:29 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:29 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:28 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:28 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:27 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:26 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:26 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:25 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:25 User: latpro ---------------------------------------------------------------------- File: Date: January 24, 2005 - 20:23 User: latpro ----------------------------------------------------------------------

3 2

[drupal-devel] [task] Remove dead code from page.module
by drumm 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: page.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/page.module_1.diff (2.18 KB) This page table database table doesn't seem to be doing a lot. Lets remove it. The page_view() function just does the default processing which node.module will do for us. Lets remove it. Hmm,,, page and story modules are functionally the exact same with this and http://drupal.org/node/16192. Wonder what we could do about that... :) drumm -- View: http://drupal.org/node/16237 Edit: http://drupal.org/project/comments/add/16237

1 0

[drupal-devel] Release critical bugs for January 26, 2005
by drupal-devel＠drupal.org 26 Jan '05

26 Jan '05

Bbcode / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 1 week 3 days url: http://drupal.org/node/15654 Chatbox / support requests Cron run kills Chat? age: 7 weeks 1 day url: http://drupal.org/node/14032 Drupal / bug reports Drupal adds extra items to body tag, doesn't line break output html after move to new server age: 4 days 2 hours url: http://drupal.org/node/16004 updates.inc deleting profile_data when updating age: 1 week 3 days url: http://drupal.org/node/15686 Change to sesssion.inc violates UID database constraint age: 1 week 3 days url: http://drupal.org/node/15666 problem with forum.module with postgresql v7.4.1 age: 2 weeks 2 days url: http://drupal.org/node/15412 forum.module problem with postgresql v7.4.1 age: 2 weeks 2 days url: http://drupal.org/node/15411 postgresql error age: 2 weeks 6 days url: http://drupal.org/node/15175 UID 0, anonymous user account deleted age: 7 weeks 3 days url: http://drupal.org/node/13915 Styles broken after multisite patch assigned: TDobes age: 8 weeks 9 hours url: http://drupal.org/node/13738 Entering an empty title broke drupal age: 10 weeks 1 day url: http://drupal.org/node/12974 Argument NOT must be type boolean age: 10 weeks 2 days url: http://drupal.org/node/12950 Need to clear caches after running update.php age: 12 weeks 3 days url: http://drupal.org/node/12350 Private downloads aren't working age: 12 weeks 5 days url: http://drupal.org/node/12267 Comments in approval queue still show up in tracker age: 14 weeks 4 days url: http://drupal.org/node/11647 Drupal / feature requests User info exposed to anonymous user age: 8 weeks 4 days url: http://drupal.org/node/13545 Allow named anchors to work without specifying full path to node age: 1 year 9 weeks url: http://drupal.org/node/4213 Drupal / support requests Problem with Forums age: 2 weeks 4 days url: http://drupal.org/node/15299 /?q=admin/modules doesnt work for me! age: 9 weeks 4 days url: http://drupal.org/node/13193 Drupal / tasks Display of blocks by zones instead of left-right assigned: Kiev1.org age: 6 days 23 hours url: http://drupal.org/node/15854 atom.module working version to 4.5.0 assigned: hugoromano age: 12 weeks 3 hours url: http://drupal.org/node/12496 Postgres Compatibility Update assigned: adrian age: 18 weeks 2 days url: http://drupal.org/node/10945 file.inc code review assigned: Stefan age: 40 weeks 2 days url: http://drupal.org/node/7235 Drupal.org maintenance / bug reports Do not use "fixed" as default status for issues on drupal.org! age: 13 weeks 6 days url: http://drupal.org/node/11817 I can not add a release of Chinese Simplified Translation. age: 14 weeks 7 hours url: http://drupal.org/node/11770 Event / bug reports search over fields.inc fields conceptual error age: 12 weeks 5 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 12 weeks 5 days url: http://drupal.org/node/12257 Still GMT/TZ issues with CVS age: 13 weeks 5 days url: http://drupal.org/node/11870 Time entry is GMT even when site default is not age: 14 weeks 4 days url: http://drupal.org/node/11630 Start Time of Event is NOT Preserved age: 31 weeks 6 days url: http://drupal.org/node/8565 Feature / bug reports Menu item not showing age: 16 weeks 5 days url: http://drupal.org/node/11210 File / bug reports segmentation fault related to filestore age: 1 year 17 weeks url: http://drupal.org/node/3001 Filestore / support requests File store module - Overwriting Filename....Help needed assigned: harishkm age: 43 weeks 8 hours url: http://drupal.org/node/6827 Unserialize error at line 104 age: 49 weeks 5 days url: http://drupal.org/node/5857 Filestore module- sql errors rectified assigned: harishkm age: 51 weeks 13 hours url: http://drupal.org/node/5619 Problems in Filestore2 module assigned: harishkm age: 52 weeks 8 hours url: http://drupal.org/node/5458 Filestore Module Problems unaddressed assigned: harishkm age: 1 year 4 days url: http://drupal.org/node/5365 Groups / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 45 weeks 5 days url: http://drupal.org/node/6392 Htmlarea / bug reports HTMLarea 4.5.0 doesn't work with themes using xtemplate.tmpl age: 1 day 4 hours url: http://drupal.org/node/16155 Image / bug reports Image.Module does not know the correct filename age: 10 weeks 1 day url: http://drupal.org/node/13032 SAFE MODE Restriction in effect... age: 13 weeks 6 days url: http://drupal.org/node/11843 Uploading jpeg makes Imagemagick do high compression age: 15 weeks 3 days url: http://drupal.org/node/11445 Image module failing on Preview because of a blank node id age: 17 weeks 4 days url: http://drupal.org/node/11069 Similar problem with Directory Upload Slow age: 17 weeks 4 days url: http://drupal.org/node/11064 Node Aggregator / bug reports Import doesn't like XML/RSS feeds with no Title element age: 34 weeks 4 days url: http://drupal.org/node/8128 Node Aggregator / feature requests RSS items overwriting edited items age: 32 weeks 4 days url: http://drupal.org/node/8455 Notify / feature requests Notify.module ignores the true submission queue age: 1 year 13 weeks url: http://drupal.org/node/3765 Pdfview / feature requests Internationalization support for PDF assigned: TheLibrarian age: 43 weeks 1 day url: http://drupal.org/node/6795 Project / bug reports "Page Not Found" when trying to view issues or add new release age: 7 weeks 5 days url: http://drupal.org/node/13815 Project pages display only title and description age: 9 weeks 6 days url: http://drupal.org/node/13082 Fatal error: Cannot use string offset as an array in includes/tablesort.inc on line 113 assigned: publian age: 16 weeks 6 days url: http://drupal.org/node/11187 Issued assigned to "unassigned" not being displayed. age: 19 weeks 3 days url: http://drupal.org/node/10744 Can't create new project with issue tracker age: 23 weeks 12 hours url: http://drupal.org/node/10148 Wrong URL after "Update Issue" age: 46 weeks 1 day url: http://drupal.org/node/6330 Project / support requests Help with everything - nothing seems to work in the latest build age: 9 weeks 2 days url: http://drupal.org/node/13310 Taxonomy Browser / support requests site overloading! age: 18 hours 7 min url: http://drupal.org/node/16193 TrackBack / bug reports Overly aggressive age: 7 weeks 4 days url: http://drupal.org/node/13865 trackback borks google and every other search engine age: 12 weeks 2 days url: http://drupal.org/node/12388

1 0

Re: [drupal-devel] Remove admin.module
by Boris Mann 26 Jan '05

26 Jan '05

On Tue, 25 Jan 2005 16:49:10 -0500, Todd Grimason <todd(a)slack.net> wrote: > Perhaps a suitable solution could be setting a CSS id attribute > ('is_admin'?) to be used in the HTML body tag so that those who want > to could format admin pages differently? Or some other sort of CSS > flag? > > I personally find having to squeeze/use all the admin forms and > layouts within the public site layout troublesome, but maybe this > would be a solution to allow both usages? I imagine the difficulty > occurs in deciding which actions are "admin" actions or just user or > contributor actions. Probably somewhat ambiguous. Thoughts? Ber's "sections" module lets you assign a completely different theme to different areas of the site. This is one existing way to have a completely separate theme for the "admin" part of the site. Admin.module doesn't do anything today. Let's get rid of it, and let (future) control panel solutions thrive on their own merits. -- Boris Mann http://www.bryght.com

5 8

[drupal-devel] [task] Introduce Daylight Saving Time for Drupal
by alliax 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: alliax Status: patch wouldn't hurt to have this feature in upcoming drupal. I would use it for sure, my users are from the same place, with dst alliax Previous comments: ------------------------------------------------------------------------ September 26, 2004 - 04:01 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst.patch (6.04 KB) Many people have wanted to have a Daylight Saving Time setting in the past. If we use the "server time" modell (all times are displayed the same around the world) this isn't all that hard to do. I found a lot of usefull information here: http://webexhibits.org/daylightsaving/g.html The patch introduces a new DST setting and uses it if the "Configurable time zones" setting is switched off. ------------------------------------------------------------------------ September 26, 2004 - 05:40 : gordon This is a lovely patch, but you do realise that you have opened a can of worms. Daylight saving is a messy business, I had to write the Contestable Electricity billing for a company here in Australia which had multiple installations in multpile timezones, all with different daylight savings rules, which impacted upon the bill. The way that dst is legistated is very messy and here is Australia it is very messy. Daylight savings don't follow state lines, as some towns that are very close to the border may choose to follow the only the daylight saving period of the next state, and when we had the olympics NSW went into daylight savings months before anyone else. There are other examples of weird things like even the 1 hour forward is not also true. I know that in the 1999 change to daylight savings there was a small set of islands north of New Zealand that went ahead by 2 hours as they wanted to be the first into 2000. >From what I can see of your patch it only allows for a single daylight savings period for the entire system. Their can be situations where there can be users from multiple countries and in different timezones/dst. I think that entire timezone system needs to looked at again, and maybe re-implement it so that it will allow for dst. Maybe make it a bit more user friendly so instead of setting up the timezone by name much like how operating systems do it, and then this will automatically work out the timezone. +1 for this is something that would be good, but it still needs work. ------------------------------------------------------------------------ September 26, 2004 - 15:13 : Anonymous The patch works as it is now. I had good reason to limit its capability to the setting where users cannot chose their own timezone. ;) I also assume that a server administrator knows if he has dst or not. I also didn't (yet) cater for all countries where dst is in use mainly because some insist on not giving a sensible rule for the change dates. ------------------------------------------------------------------------ September 26, 2004 - 23:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst_0.patch (6.04 KB) The last comment was mine. After a code review by Kjartan I provide a slightly improved patch. I want to stress that solving the DST issue in a "suits everybody" manner isn't the intention of this patch. It solves the problem for people who have chosen to let all times on their site be displayed in the server's time setting. By covering a large portion of the earth's landmass I hope to be able to help most site admins. It would be possible to extend the patch to allow users to chose their DST setting, too. In my experience, however, users tend to not care about time settings at all. This may be EUrocentric though, as we have only one time zone. Feedback is welcome. ------------------------------------------------------------------------ September 27, 2004 - 22:12 : drumm +1 >From a code review I think this is an excellent solution. Could use a little more comments in the section that sets $node->date to explain the (probably good) reasoning behind that chunk of code. I don't have anything resembling a good set of tests so I did not apply the patch and try it. ------------------------------------------------------------------------ January 25, 2005 - 21:38 : killes(a)www.drop.org I just want to point out that this patch still applies and would make for a fine feature for Drupal 4.6... -- View: http://drupal.org/node/11077 Edit: http://drupal.org/project/comments/add/11077

1 0

[drupal-devel] [feature] Move submission guidelines and minimum word count to node module.
by drumm 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/move_submission_things.diff (7.8 KB) Screenshot at http://foo.delocalizedham.com/tmp/1.png (rejected screenshot is http://foo.delocalizedham.com/tmp/2.png) This moves the submission guidelines found in forum, story, and blog and the minimum number of words found in story and blog (blog had a slight bug) into the node module. This makes a total of 2 less settings pages. I added a todo for counting words in languages which don't have the concept of spaces as the western languages. Here is what Steven said about that when I asked: 15:06 < UnConeD> drumm: word counting doesn't scale well though 15:06 < UnConeD> to different languages i mean 15:06 < UnConeD> there's just no good way to do it Also, the $type variable passed to node_types_configure wasn't being set so the whole content types admin actually wasn't working. That is fixed too. drumm -- View: http://drupal.org/node/16192 Edit: http://drupal.org/project/comments/add/16192

3 3

[drupal-devel] Double messages
by Chris Cook 26 Jan '05

26 Jan '05

I receive 2 messages for each issue post. One has [drupal-devel][feature] in the subject while the other has just [feature]. I get these double emails for all issue types. Is there a list setting I can change or is that a bug in the issue system?

2 1

[drupal-devel] [feature] Improve functionality of block generation for book module
by andremolnar 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: andremolnar Reported by: nysus Updated by: andremolnar Status: patch Yes - please - testers are welcome. Nysus (aka Steve) has already agreed to give this a test drive when he had a spare moment. I hope for some feedback in the near future. But if you have a moment Borris I would appreciate it. OR - If someone would just like to demo this: http://s92258948.onlinehome.us/greenbeach/ UN: drupaldev PW: drupaldev Don't mind the mess - it is my test environment and there is a lot of junk data and settings floating around - but this patch is running there along with the additional block configuration settings. andre andremolnar Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 06:12 : nysus Attachment: http://drupal.org/files/issues/book_19.patch (4.85 KB) Attached is a patch for the book module that does the following: 1) Allows book blocks to appear on any page at any time, not just when a node from the book is being viewed. 2) Allows multiple book blocks to appear on the same page. This functionality is achieved by the automatic creation of individual blocks for each book when the book is created. Simply enable the book's block to enjoy the benefits of 1 & 2 above. If the blocks are not enabled, the blocks will appear only when a node from that block is being viewed (the same way it works now). ------------------------------------------------------------------------ December 9, 2004 - 12:35 : andremolnar Attachment: http://drupal.org/files/issues/book_19_1.patch (4.84 KB) +1 This is great. A good many people have asked for something like this, and I think its a nice solution. But in the end this isn't up to me. One minor error in the patch... + $result = db_query('SELECT n.title, b.block, b.nid FROM {book} b INNER JOIN {node} n on n.nid = b.nid WHERE b.parent = 0'); b.block is not a valid field in this query. this updated patch removes reference to it. andre ------------------------------------------------------------------------ December 9, 2004 - 13:54 : nysus Glad you like it and thanks for fixing that up. It was left over from an older version of my patch. ------------------------------------------------------------------------ December 9, 2004 - 13:54 : andremolnar Steve, If I apply this patch, and I attempt to configure one of the newly created blocks. I noticed that for some reason the block.module is returning "true" at line 249 (of the block module)- and is creating a form for module-specific configuration. But all that shows up on the screen is the word "array". Can you trace this back to see why - and maybe update the patch. I can continue to test your changes - anything to help this patch make it into core. andre ------------------------------------------------------------------------ December 9, 2004 - 15:29 : nysus Hmmm...probably because I tested my patch on my version of Drupal, version 4.5.1. I'm having no problems. Are you using a cvs version of Drupal to test. If so, I'll set up cvs on my site and track this down. ------------------------------------------------------------------------ December 9, 2004 - 18:53 : drumm See http://drupal.org/node/12347 for information on how the block system has been updated. When I saw that the elseif ($op == 'view') was taken out I knew immedaitely that there was something weird about this patch. ------------------------------------------------------------------------ December 9, 2004 - 18:58 : nysus OK, thanks for the tip. Sorry for the confusion. Still kind of new to making open source contributions and it's easy for me to overlook some obvious stuff like this. I'll fix this up when I get a chance. ------------------------------------------------------------------------ December 9, 2004 - 19:06 : Dries Please do, because this being a new feature, it has no chance getting committed to the DRUPAL-4-5 branch. The DRUPAL-4-5 branch is in bugfix-mode. New features go into CVS HEAD. ------------------------------------------------------------------------ December 9, 2004 - 22:32 : Dries There is quite a bit of duplicated code in the patch. Maybe it can be simplified (using a function)? Either way, it is a little weird. I haven't tried the path, and I'm not sure I understood the description. It's somewhat vague. Is the book module exporting multiple blocks that are nearly identical, yet have different display behavior? If so, why not add a simple block configuration setting to the original book block? ------------------------------------------------------------------------ December 10, 2004 - 02:51 : nysus Dries, Yes, there is some code that can be factored out and some general cleaning up that can be done. It was a little tricky to write so I left it kind of ragged around the edges until I'm sure there are no bugs. It has worked very well on 4.5.1 but I obviously need to update it to work with cvs. I'll be on that soon. As far as what it does: 1) For every new book that a user creates, a new block is associated with it. So if you create "Book A", "Book B", "Book C", you will get three new blocks visible on the block administration page called "Book A", "Book B", "Book C". The original "Book Navigation" block is still there, too. The functionality of the "Book Navigation" block is not affected at all by this patch. 2) If Book A's block is enabled, the block containing its menu will appear not only when a node within Book A is viewed, but at all times (unless the user suppresses it on certain pages with the "path" feature). When any node is that is NOT in Book A is viewed, Book A's menu still appears but it is fully collapsed. When a node that DOES belong to Book A is viewed, Book A's Book menu expands accordingly. 3) The user can also enable Book B & C's block, and have their menus appear in a block at all times as well. 4) If none of the book's blocks are enabled by the user, the module will behave just as it did without the patch. That is, when the "Book Navigation" block is enabled, the only time any book menu will appear is when a book node is being viewed. 5) It's important to note (and this was the tricky part to write) that if both the "Book Navigation" block is enabled and "Book A" is enabled, they will play nice with each other and not do nasty things like create the same book menu twice. ------------------------------------------------------------------------ December 10, 2004 - 05:51 : nysus Attachment: http://drupal.org/files/issues/book_20.patch (5.37 KB) Andre, Attached is a new patch that will resolve the problem of the block-specific stuff showing on the block configuration form. Let me know if you spot any other bugs. If it looks good to you, I'll go to work making the code look leaner and prettier. ------------------------------------------------------------------------ December 10, 2004 - 07:26 : nysus Attachment: http://drupal.org/files/issues/book_21.patch (4 KB) Dries, Andre: Here is a new and improved streamlined version of the patch. Have a look if you get a chance. ------------------------------------------------------------------------ December 10, 2004 - 08:11 : nysus Attachment: http://drupal.org/files/issues/book_22.patch (4.15 KB) Found a bug in the last version that would cause the block to jump to a different location. I think this should do it. Everything appear to work well (famous last words). ------------------------------------------------------------------------ December 10, 2004 - 14:49 : andremolnar Steve: bugs appear to be gone, and I didn't run across any other errors. This is functioning exactly as described. everyone: I personally would encourage support for this functionality. Book is a powerful navigation building tool in a site, not only with its ability to move next and back through a hierarchy of pages - but also its ability to build the appropriate navigation block without further user intervention (unlike the admin features in the menu module or taxonomy). The most frequently cited complaint about the book module is its inflexibility when it comes to when and where the block shows up. I also frequently hear requests for the ability to show multiple book blocks at the same time. Up until now the best alternatives suggested required users to do a hack (e.g. build a custom block that calls such and such a hook). Most abandon their request at that point because its over their heads. With this patch all those requests are covered and more. Now all books can automatically have their own block and admins can easily decide when and where each of those individual blocks show up (left right, up down) and coupled with the new configuration features of the block module - its very easy for admins to decide on which individual pages a block will show up. I would be interested what other have to say about this feature. My only reservation (which is minor compared to the benefits of the functionality offered) is that there is no way to turn this functionality off. i.e. The default behaviour is to build individual blocks for each book. If there could be a way to toggle this feature on and off somewhere - it would be perfect. Still, AS IS - this is a major improvement and offers great flexibility to admins and site creators. andre ------------------------------------------------------------------------ December 10, 2004 - 15:04 : Anonymous Andre, Thanks for the feedback on the usefulness of this module. Glad I could pitch in and help. I agree about the inability to turn the feature on/off and I was thinking about that myself. I think it could easily be accomplished by creating a checkbox in the "book navigation" block individual configuration's settings. Call it "Enable individual book blocks." When enabled, the individual book blocks will appear on the block administration menu. One question: Where would the state of this checkbox get saved? Has Drupal moved away from serializing data in the data base? ------------------------------------------------------------------------ December 10, 2004 - 18:36 : Dries I'm afraid that 'Enable individual book blocks.' is not descriptive/clear at all. Are you suggesting a setting to toggle between 'show block on all pages' and 'show block on book pages only'? ------------------------------------------------------------------------ December 10, 2004 - 19:45 : nysus Dries, No. Andre and I suggest a setting within the "Book Navigation" cofiguration page, that would toggle whether or not individual books appear on the list of all blocks on the block administration page. Hence the name 'Enable individual book navigation blocks.' The help text for this checkbox might read something like: "By default, a book's navigation block is visible only when a page from that book is being viewed. Check this box if you want more control over where and when an book's navigation block is visible. You will then be able to control the book's navigation block location and visibility settings on the "admin/block" page." Hope this makes it pretty clear. ------------------------------------------------------------------------ December 10, 2004 - 20:08 : Dries I understand what you are trying to do, but not how you are trying to do it, or how the setting is supposed to work. I guess I'll have to try it when a new patch lands. ------------------------------------------------------------------------ December 11, 2004 - 09:52 : nysus Attachment: http://drupal.org/files/issues/book_23.patch (5.02 KB) Alright, fellas, I'm proud to unveil my crowning achievement in the open source development world (no big deal to most of you guys but pretty good for a hack like me). Thanks for all the input so far. It's been helpful. I've streamlined the heck out of it per Dries suggestion and I've created an option to turn this functionality on an off per Andre's suggestion. Does this look good to you guys? Anything else I have to fix or improve? Thanks. ------------------------------------------------------------------------ December 11, 2004 - 13:02 : Dries I tried the patch. It works great but to me, the 'Give books their own block' settings seems to be redundant. Why not export the current book navigation block, along with an additional block for each book? Looks a lot simpler to me. I think I spotted a bug: orphaned book pages (or possibly book pages that are unpublished) appear to be getting book navigation blocks. ------------------------------------------------------------------------ December 11, 2004 - 17:34 : nysus I'll see if I can fix the bug. Might be tricky. But I don't understand your recommendation to "export the current book navigation block, along with an additional block for each book". Can you expand on this thought? ------------------------------------------------------------------------ December 11, 2004 - 18:06 : nysus Dries, I am unable to duplicate the bug. I have three orphaned pages. I also tried unpublishing some pages. But as far as I can tell, the patch works as expected. ------------------------------------------------------------------------ December 11, 2004 - 19:00 : Dries If you can't reproduce the problem, chances are my node/book table is somewhat fubar. As for the configuration option. I suggest removing it and to always make these new blocks available on the /admin/block configuration screen. ------------------------------------------------------------------------ December 11, 2004 - 19:52 : moshe weitzman I am hoping that we maintain the option to keep the behavior where the appropriate book block only shows up when its book page viewed. this is a nice, tidy arrangement. ------------------------------------------------------------------------ December 11, 2004 - 20:03 : nysus Yes, if you don't enable any of the individual book blocks, the a book's block (i.e. navigation menu) will only appear when a page in a book is viewed. In other words, you have the option to have the book block act like this patch isn't even installed. ------------------------------------------------------------------------ December 11, 2004 - 20:54 : Dries I guess I'll have to try the patch again, because I don't understand why it works like this -- or at least, why it can't be made simpler. ------------------------------------------------------------------------ December 11, 2004 - 21:13 : nysus Can you be more specific? Why it works like what? ------------------------------------------------------------------------ December 11, 2004 - 21:24 : nysus Attachment: http://drupal.org/files/issues/book_24.patch (4.1 KB) This patch reverses a change made in the last patch which required a user to enable individual book block before they could enable any individual book blocks. ------------------------------------------------------------------------ December 11, 2004 - 21:41 : andremolnar As I mentioned earlier I am *fine* with either version of this patch as long as it makes it to core. But, as I said earlier, I clearly think the preference for admins would be to have the option to enable or disable this functionality. BTW - if this does make it in, I would be happy to create a Handbook page that describes the new features - something like "how to build robust site navigation using the book module". (on or after December 17th). andre ------------------------------------------------------------------------ December 12, 2004 - 12:11 : Anonymous I am not at all happy with these features. They are incosistant, confusing and should use exising methods and UIs. May main concern is the incosistancy: it is confusing, will require extra attention with each core code change, adds extra logic to the core, and is not re-useable. so here are my questions: 1) why do we not use the menu system and apis to build and adminster the trees? Saves code, does not add extra UIs, and gives users more power. 2) why do we need that extra showing logic? a book block should not get exeptional if clauses, it should use the existing path setting methods on block admin. extra logic is confusing for administrators (hey, i set the path so that the book-block should show up here, but it does not, why?) we should really not provide extra logic in the block hook, but should rather use default settings in block admin (the book could fill the bookblock sql cells with custom paths, for example) 3) we should avoid extra UIs. We already have far too much, and far too much different ones. Please rather improve the block admin, than add new separate interfaces. 4) why do book blocks need al these expeptions in the first place? If they are so exeptional, we could consider not using blocks, but something else, like in-line book layout (pages with the index etc) 5) why did you not choose for a general, standard, block gerneation API? that way modules, such as taxonomy, image gallery, weblinks, article, etc can reuse it and introduce block gernation. All that sayd, i like the idea of this functionality, but i fear for a great useability downfall if we start introducing all sorts of exeptions for all sorts of modules. Because now chances are very big that taxonomy, image gallery etc will need to introduce other UIs, other code, new methods and new documentation, if they too want some sort of better block handling. so a -1 from me. ------------------------------------------------------------------------ December 12, 2004 - 12:12 : Bèr Kessels ^^--- That was me (bèr kessels) forgot to log in..... ------------------------------------------------------------------------ December 12, 2004 - 12:34 : nysus I'm not going to pretend I can argue if my patch does or does not fit well into Drupal's larger architecture. My motivation for writing it is that I had an immediate need to create an easy way to make it easy for users to create menus. I'll let others decide whether or not the patch has merit from the big picture perspective. But if it doesn't, why not just use it for its immediate benefits and then throw it away when something better comes along? ------------------------------------------------------------------------ December 12, 2004 - 13:01 : Dries My summary is this: +1 on the functionality, -1 on the implementation. The code itself is good, but the usability/integration is not. ------------------------------------------------------------------------ December 12, 2004 - 13:13 : nysus When you say "usability" is that from the user's perspective or the code maintainers? I'm guessing it's the latter but I'm unsure. What about the idea of using the patch until a more permanent solution comes along? Yes, it's much better to live in a home with indoor plumbing but why not use the outhouse while you wait for a toilet to get installed? Or are there other considerations I'm overlooking that would make this a bad idea? ------------------------------------------------------------------------ December 12, 2004 - 13:20 : Goba nysus it is just generally against the Drupal philosophy to add improperly implemented functionality until something better comes along. There even used to be ocassions in Drupal releases, when some functionality was removed (not fixed) for a release, because its implementation was not adequate. ------------------------------------------------------------------------ December 12, 2004 - 13:55 : Dries Usability for the user. The extra setting on the block configuration page is both confusing and awkward. I don't understand why things must be configured/enabled that way (see my and Ber's previous comments on this issue). ------------------------------------------------------------------------ December 12, 2004 - 14:03 : nysus Well, just for the record, I reversed that functionality per your suggestion and uploaded the patch. The indiviudal book blocks now appear automatically. ------------------------------------------------------------------------ December 13, 2004 - 13:56 : Bèr Kessels Hi, I am sure you can make not only simpler, but better usefull for admins and users. All you need to do is use the menus for this. i.e. make a menu entry for each book page. For each book make a menu on level 0, without a parent. that way they become a seoprate menu, each with an own block. it saves code, makes things more consistent, and most important, uses drupal functionality where it should. ------------------------------------------------------------------------ December 13, 2004 - 14:50 : nysus Ber, Are you suggesting that for every single book page that a menu item be created? That's really not practical. That was my main motivation for writing this patch: to make it easy to put links, not necessarily related to one another, into a block. Any more pages than 10 and the sheer tedium of the job would prevent anyone from ever doing that. The menu.module is great, but adding new menu items is far from quick and painless. I just added about 10 to my menu for different taxonomies on my site and it wasn't fun. Plus, if you do as you suggest, there is also the problem of the book showing up twice. It will be generated by the menu and then it will be generated again by the book module which is programmed to design a block. You'd have to put some logic in the book.module _block hook to try to anticipate if a user has enabled a book in the menu. That wouldn't be pretty code. I'm all for putting automatic generation of book navigation blocks as part of the menu module. It does make more sense to have it there. But it forces me to ask the question: "Then why do we currently have code in the book module that generates a menu? Shouldn't that belong in the menu.module, too?" ------------------------------------------------------------------------ December 13, 2004 - 22:31 : killes(a)www.drop.org I think what Ber is trying to say is that you can write a contrib module that monitors the changes to the book table and creates menu items automatically. nodeapi is your friend. I would also prefer this solution. ------------------------------------------------------------------------ December 15, 2004 - 16:39 : Anonymous "Then why do we currently have code in the book module that generates a menu? Shouldn't that belong in the menu.module, too?" Because it's old code. It would be nice if book.module generated this block using its _menu hook, so that the admin would have a few options in terms of configuration. Plus, if you do as you suggest, there is also the problem of the book showing up twice. It will be generated by the menu and then it will be generated again by the book module which is programmed to design a block. No. The old code which manually builds a block in book.module would be removed. Book blocks would only be generated by the menu. This would also have the added benefit of allow the administrator to easily place a book in an appropriate spot in the menu tree, while still allowing the possibility of displaying it in a separate block. Because of menu caching, I don't expect a large performance hit for creating the menu items. That was my main motivation for writing this patch: to make it easy to put links, not necessarily related to one another, into a block. It sounds like instead of (mis)using book.module, your time would be better spent in a usability improvement to menu.module so it's easier to do this. ------------------------------------------------------------------------ December 16, 2004 - 06:55 : nysus Thanks for the feedback and input. I appreciate it. However, I would also appreciate if you took more care to avoid the condescending tone in your post: It sounds like instead of (mis)using book.module, your time would be better spent in a usability improvement to menu.module so it's easier to do this. It's really quite unnecessary and off-putting. Though it won't stop me from contributing to Drupal in the future, I'm sure others would be really turned off by such a patronizing comment and it could dissuade them. I'd like the Drupal community to be a welcoming and friendly place that will inspire people to contribute, not discourage them. Thanks. ------------------------------------------------------------------------ December 16, 2004 - 10:07 : Bèr Kessels nyesus, Please do not start /that/ discussion here. :) Drupal community is known fo being direct, maybe because of the big number of western-Europeans attending, maybe because of other reasons. No-one commented that you are wasting your time. But the commentor was telling you somthing likethis: "If you would follow the previous sugeestions, your added feature would be much better appreciated, and will probably work much better for you too". He/she was by no means telling you to stop your silly coding, or anything in that line. He/She only wanted to show you the obvious and better direction. We often deal with issues that add some feature, and a complete new UI, because the author does not like, or cannot use the existing UIs and features. This is nogt good, because if that same author would have spend his/her time on improving that existing functionality or UI (improving is not neccesarily the same as extending!!) that code and time would benefit all much better. Thats what the commentor tried to say. And so is it here: If you dislike the way the books handle the blocks, and if you do not want to use the menu, because you do not like its UI, then do not add another UI and more features, but rather merge these, and improve the parts (in the menu) you dislike. ------------------------------------------------------------------------ December 16, 2004 - 10:35 : Dries We can worry about the menu integration later. Let's focus on the new option's usability/interaction design first. ------------------------------------------------------------------------ December 16, 2004 - 14:51 : nysus I understand what the commenter was saying and like I said, I appreciate and understand it. I'm not upset and I'm not looking for an argument, I was just being direct as well. :) As part of the Drupal community (albeit a minor player), all I'm saying is that I would like to see folks not have a tin ear to the humanity in all of us. It will help make Drupal an even stronger community and attract even more talented developers. Human interaction is part of the development process. Whether we like it or not, we must cope and deal with it. ------------------------------------------------------------------------ December 18, 2004 - 09:54 : Dries I thought some more about this and am starting to believe that integration with the menu system should take priority. Here are common cool scenario's: I want to create a separate navigation block for the 'Drupal handbook'. I want to add a menu item called 'handbook' to the user block. That is, I want the book navigation to be part of the existing user navigation block. I want to add a menu item called 'handbook' to the top-level navigation menu. How would that work from a user's point of view? What do I have to click and where to configure this? ------------------------------------------------------------------------ December 21, 2004 - 18:47 : andremolnar I was actually thinking about the same thing last night (must have been something in the arctic air). 2. I want to add a menu item called 'handbook' to the user block. That is, I want the book navigation to be part of the existing user navigation block. 3. I want to add a menu item called 'handbook' to the top-level navigation menu. This is already possible (to a certain extent) with the current Book.module and Menu.module - A 'Books' menu item is created in the user navigation by having the Book.module enabled. Menu.module allows you to enable/disable this menu item. Menu.module also allows you to re-name this menu item. But, this only helps if you only intend to have 1 book (or else the name 'Handbook' is misleading if the user finds more than 1 book listed). - so this isn't good enough (or is it). 1. I want to create a separate navigation block for the 'Drupal handbook'. This is what I was trying to figure out. Not just this, but a different way to do what Nysus was attempting. i.e. create a menu block for each and every book that is created. There is a way to write code that would (re)build a 'custom menu' on every add/edit/update to a book page - or book outline update. Custom menu's automatically have a block created for them. But, this I think would be a misleading use of the 'custom' menu - as the menu would not be custom if they are a part of core. So, I would think that two new constants could be added to the menu.inc file - MENU_BOOK_MENU - and MENU_BOOK_ITEM - each would behave as custom menu's, but would be reserved for books. These menu types should NOT show up in the Menu.module administration - because the administration of the book_menu items would be done by administering the book itself (adding an item, removing an item, moving an item up/down in the hierarchy, assigning parents etc.). However, the blocks that the book_menus would create would show up in the block administration (so users could enable/disable each block - and decide where on the site they show up). The existing book block logic would be removed. So the logic would be: If a creates a book in the book administration page - the Book.module automatically creates a new MENU_BOOK_MENU Any time a user adds to or updates or delets a book page - the entire book menu is deleted and recreated based on the hierarchy defined by the book itself. The blocks for each book would show up in block administration. Any thoughts - I know that this doesn't exactly address points 1 and 2 - but it could act as a first step. Is this approach a bad idea? It would add special conditions for the proposed book menu's - but books would be a special case. Even if people don't like this solution, maybe it will give someone a better idea. I'd love to hear them. andre ------------------------------------------------------------------------ December 21, 2004 - 22:55 : Boris Mann +1 to this andre I had promised to put down my thoughts on this matter, as it relates to 1) primary and secondary links and how they are managed and 2) auto-generation of primary/secondary navigation based on book outlines So, for 1), we currently have functional-but-not-very-usable plain textfields to manage primary and secondary links. I would like to see menu.module used to control all navigation links, whether it is the navigation block or primary/secondary links. What is needed: a) default system menus labelled "primary" and "secondary" which would store; this is where modules could insert navigation b) support for full URLs (e.g. http://myexternaldomain.com) instead of just path 2) if we got 1 working, and andre does his book menus, this could get taken care of automatically. Basically, for brochureware/business/etc. sites that have static content, you could have a root book as one of the primary navigation links, and then the secondary links are generated automatically. ------------------------------------------------------------------------ December 22, 2004 - 21:02 : Dries I agree with Andre that the book module's integration with the menu system needs to be worked on. I support any effort that makes it easier to structure pages and that makes it easy to link pages/nodes from within a menu. However, I'm opposed to putting book module specific names in the menu system (eg. MENU_BOOK_MENU and MENU_BOOK_ITEM). I can imagine a handful of modules that want to maintain a menu tree (or part thereof) so I'm in favor of generic names. I'd have to read up on the menu system code, but last time I checked there was a MENU_MODIFIABLE_BY_ADMIN flag. You could choose not to set this flag for the menu items generated by the book module. Maybe it's already possible to implement to implement Andre's suggestion without having to modify/extend the menu system. Are you exploring this path? ------------------------------------------------------------------------ December 24, 2004 - 10:01 : andremolnar I've had a few spare hours to work on this. I've started to cobble together a solution - but in doing so I discovered a bug in the menu module (for which I will submit a seperate issue - if one doesn't already exist). The principal I suggested works. I added some code to the book module that creates custom menu's (MENU_CUSTOM_MENU with MENU_CUSTOM_ITEMs) for each Book that exists in a site. This is just as a proof of concept - I chose this menu type to start with because they automatically have a block created for them in admin/block (which is ultimatly the functionality we want). I ran a test and the menus are created as expected - the blocks are also created. But when I tested the menu blocks by enabling them I ran into a problem. It seems as though the menu system does not expand/explode sub menu items if the node type is book. I'm not sure why this is, and I haven't traced the source code yet - I thought I would ask if anyone has intimate knowledge of the menu system if they can point me in the right direction. No patch attached because until that problem is fixed this proposed change won't fly :( andre ------------------------------------------------------------------------ December 24, 2004 - 11:11 : Dries Just a wild guess: maybe it doesn't work because the book module's URI scheme is not hierarchical? ------------------------------------------------------------------------ January 7, 2005 - 10:45 : andremolnar Attachment: http://drupal.org/files/issues/book_module_1.patch (5.1 KB) I finally took some time out to do some work on this. As mentioned in a post to dev the problem I was having with menus not expanding/contracting properly was some crud in my database. Once that was cleared up my changes worked fine. I am attaching a patch for comments and for the brave willing to give it a test drive. History: This thread and http://drupal.org/node/15198 and http://drupal.org/node/15153 node/15198 has a patch that is required for this patch to work. What this does: Pretty straight forward. Any time a user adds/updates/deletes book or book pages (including via outline) - a function is called to create a new menu for each book. Any existing book menus are wiped out and then the new book menus are inserted - and the system menu is rebuilt to reflect the changes. The menus created consist of type MENU_MODULE_MENU and MENU_MODULE_ITEM. These menus show up in the menu/admin page so that admins can be aware of them, but the menu types are not editable via menu/admin (all changes are handled by the book module). Since the menus are in the menu table, the menu_block() hook handles the creation of the blocks for each of them. The blocks can then be administered in the usual ways via the block/admin interface. KNOWN ISSUE: (suggested solutions welcome) Since the menu table is updated on every change to books - the blocks associated with the menus are also recreated with default settings (i.e. disabled, and with no path or throttle settings) requiring a user to take an extra step and re-configure the book blocks for viewing on their site. I think this is unacceptable. For the casual user of the book module that only has a single book that doesn't change often, this would not be a big deal. But, if anyone wanted to make use of book module to handle dynamic site navigation this would create more work than it saves. Looking forward: If the block generation issue can be solved in a tidy way, this patch could allow users to use book to handle all their site navigation generation needs. Also, this patch could allow for the removal of a large chunk of code in the book module dedicated to building its own block via the block system. I left it there for now because I suppose there may be those out there that want to have book.module work the way book.module always worked (only show the book block when viewing a book page). Even so, since each book would have its own block, an admin could specify when and where the block shows via admin/block. I would appreciate feedback. If nothing else I hope this gives someone some new ideas. I'll continue to work on the block regeneration issue. andre ------------------------------------------------------------------------ January 7, 2005 - 10:47 : andremolnar Attachment: http://drupal.org/files/issues/book_module_2.patch (4.98 KB) sorry - here's a patch with prefered line breaks. andre ------------------------------------------------------------------------ January 7, 2005 - 16:47 : nysus Andre, I've been meaning to give this a throrough look when I get a chance. Hopefully this weekend. ---Steve ------------------------------------------------------------------------ January 20, 2005 - 02:02 : andremolnar Attachment: http://drupal.org/files/issues/book_module_3.patch (6.66 KB) Here is an updated patch. Same comments as followup 51 - except that the known issue has been resolved. This changes book module so that any action taken on a book, including adding new books or book pages will create a menu in the menu system for that book - and thus create blocks for those menus that can be administered in the usual ways. This is my first attempt at a major patch to core - comments are welcome I will be happy to update documentation once revisions to the code have been taken care of. andre ------------------------------------------------------------------------ January 20, 2005 - 02:53 : andremolnar Attachment: http://drupal.org/files/issues/book_module_4.patch (6.17 KB) Sorry - would be nice if I removed some debugging code - ;-) also previous patch also would have introduced a need for a change to the menu table that isn't required yet. This patch is a correct version andre ------------------------------------------------------------------------ January 20, 2005 - 19:16 : Dries The menu is recreated every time a book page is updated. I believe this is unwanted behavior because it requires the book block to be reconfigured upon every update. ------------------------------------------------------------------------ January 20, 2005 - 19:32 : andremolnar The menu is indeed re-created with every book page edit - because if the book page title changes the menu needs to reflect this change. The book block re-configuration is not required by the user. The code stores this information and re-sets the block settings. I will see if I can test for 'title change' before forcing the re-build of the menu - It would save a bit of processing power. andre ------------------------------------------------------------------------ January 20, 2005 - 20:21 : andremolnar Took another at this - and it turns out that I already have a check to see if title or weight change (rather - they already existed in the module and I used them). andre ------------------------------------------------------------------------ January 24, 2005 - 02:22 : andremolnar Attachment: http://drupal.org/files/issues/book_module_6.patch (7.42 KB) Feedback received indicated that the original block generation code in this module should be removed - since this patch hands block generation off to the menu and block system. This patch removes that code. BUT - It should be noted, that in order to have book blocks only show up on pages of node type book - an additional patch found at http://drupal.org/node/16074 is required. andre ------------------------------------------------------------------------ January 24, 2005 - 18:36 : andremolnar Attachment: http://drupal.org/files/issues/book_module_7.patch (7.43 KB) Yet another patch: Brings this patch in line with - http://drupal.org/node/16074 (i.e. the column name change in {block} table) andre ------------------------------------------------------------------------ January 25, 2005 - 18:56 : andremolnar Attachment: http://drupal.org/files/issues/book_module_8.patch (7.53 KB) And another minor patch to cover coding style and variable names. Just to bring everyone up to speed: 1) Each book and its children pages have a menu created for them (on any add, edit, delete to a book or book page). 2) Those book menus automatically have a block created for them via menu_block hook. 3) Block settings are preserved any time there is a change to a book that requires the menu and its associated block to be re-built. 4) book_block hook is removed because it is redundant. 5) With the addition of the configuration option in blocks to only show blocks on certain node types (see: http://drupal.org/node/16074) administrators have full control over when and where a book block shows up (including maintaining the status quo of only having book blocks show up on book pages). 6) This patch does require http://drupal.org/node/15198 andre ------------------------------------------------------------------------ January 25, 2005 - 21:49 : Boris Mann +1!! Book-based automatic navigation for corporate/brochureware sites! Fantastic! Chris Messina, get in here and add a +1 to this. ------------------------------------------------------------------------ January 25, 2005 - 22:26 : Dries Boris, have you tested this patch extensively, or are you just giving this +1 based on what you've read? If you want to see this committed, take the time to review/test it. -- View: http://drupal.org/node/14120 Edit: http://drupal.org/project/comments/add/14120

1 0