March 2005 - Development - lists.drupal.org

[drupal-devel] by project commit message view is bogus
by Gabor Hojtsy 18 Mar '05

18 Mar '05

Hi, I used to check the Drupal project cvs commit messages on the project specific CVS message view, but this stopped recording messages weeks ago... http://drupal.org/project/cvs/3060 It would be nice to fix, but I have no idea, what might be the problem, since the CVS messages show up in the aggregated drupal.org/cvs list quite fine. Goba

1 0

[drupal-devel] remote auth and required email/password fields
by Mark 18 Mar '05

18 Mar '05

Greetings, I've been working on the livejournal authentication module, and I've noticed some odd things in the process. Most of this would apply to any remote auth configuration. When a user joins a site using remote authentication, their email address and password are not collected when the account is created. When such a user edits their profile information, though, they are forced to enter an email address, and password fields are presented to them. I'm wondering what the consequences would be if the email address were no longer required for these users. Additionally, it doesn't make sense for them to enter a password since they are authenticated using a remote server. I can see one problem arising from the profile edit page's current design. What happens when a user changes their name from "user@authserver" to be just plain "user" (or vice/versa)? Will that same account no longer be authenticated against the remote server? If I require that any username that they choose have a remote authentication server, would there be problems with this? What happens to normal, locally authenticated users who change their username from "someuser" to "someuser@someotherauthserver"? How would they ever get logged back in if they changed their username to, say, their email address? (I'm sure this has happened before) Some ideas to consider: Many auth servers provide full name, email address, etc., but there's currently no way of attriibuting these values to a local account. What about changing the hook_auth mechanism so that profile data collected at the time of signup can be applied to a new user's account. Consider altering the profile edit page so that if username contains the '@' character (i.e. remotely authenticated), then email address is no longer required and local password fields don't appear. This sounds oversimplified, but I cannot see any reason that these fields would be required/needed for remotely authenticated users. The password field would be especially confusing, since the new password is typically not applied to the authentication server (though I suppose it could be on some servers via hook_user). Any thoughts on this? Your ideas would be greatly appreciated. -Mark

7 14

[drupal-devel] [bug] node.module is dependant on taxonomy.module
by Kjartan 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/19089 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Kjartan Updated by: Kjartan Status: patch Attachment: http://drupal.org/files/issues/drupal-node-taxonomy.patch (2.77 KB) The admin/node page filters rely on taxonomy module being enabled, and gives errors when its not. Patch attached. Kjartan

1 0

[drupal-devel] [bug] incorrect topics/replies count
by menesis 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/19059 Project: Drupal Version: 4.5.2 Component: forum.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: menesis Updated by: menesis Status: patch Attachment: http://drupal.org/files/issues/forum_fix_counts_with_node_access.patch (2.47 KB) Similar problems with forum.module, when some node access module is used, were already reported and fixed - see http://drupal.org/node/11871 When using forum.module with taxonomy_access.module and multiple roles, I've encountered two more places which need DISTINCT() in queries - topic counts in forums listing, and new comments count in topic listing. Here's a patch which fixes them. menesis

1 1

[drupal-devel] [bug] Prevent browser page caching of dynamic content
by Steven 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/5900 Project: Drupal Version: cvs Component: other Category: bug reports Priority: critical Assigned to: mathias Reported by: christianlong(a)christianlong.com Updated by: Steven Status: patch That explanation makes perfect sense ;). Thanks for figuring this one out, I applied it to HEAD. Will this patch fix the problem that some people have experienced of seeing a stale page after logging in (making it seem as if the log in failed)? This sounds like a case where the browser is confused about which cache copy to pick. (PS: November 17 1978? Birthday? ;) ) Steven Previous comments: ------------------------------------------------------------------------ February 16, 2004 - 21:44 : christianlong(a)christianlong.com Attachment: http://drupal.org/files/issues/f_040214_01.txt (6.33 KB) This bug has been discussed before, but not resolved. http://drupal.org/node/view/1740 http://drupal.org/node/view/5686 One suggestion was to change the browser settings. That means I have to tell all my users to change their browser cache settings. Not a great way to run a site. Instead, the login should just work with default browser settings. Currently, login does not work, as described below. I log in to my drupal site, feingold.christianlong.com, and the logged-in home page appears, with my user name. OK. The address bar shows http://feingold.christianlong.com/node?PHPSESSID=867c4e2d57d290a3f59e138524… In the site menu, the "Home" link links to http://feingold.christianlong.com/ Here's the problem: when I click on the "Home" link, the browser takes me to the un-logged-in version of http://feingold.christianlong.com/, which was cached when I was not logged in. When I hit refresh, I do get the logged-in version of the page. So, to restate Start at home page of site, not logged in Log in - this works, and brings up a logged-in version of the page Click "Home" - this is where the problem is. I get the cached version of the home page (from when I was not logged in) Refresh browser - now I see the correct, logged-in version of the home page. It looks like I am logging in OK, but that Drupal is not telling my browser that there is a new version of the home page that it needs to check for Maybe the original (non-logged-in) version of the page is not marked for no-cache, and so when I click on the "Home" link, I get the cached (non-logged-in) version Browsers: MSIE 6 (happens a lot) and Firebird (happens sometimes). Also happens with christianlong.com Attached, find an annotated record of the HTTP header traffic. Thanks Christian ------------------------------------------------------------------------ February 16, 2004 - 21:48 : christianlong(a)christianlong.com Forum discussion is here http://drupal.org/node/view/5669 ------------------------------------------------------------------------ March 4, 2004 - 18:49 : moshe weitzman I am seing this same behavior at http://www.nshp.org [1]. To see for yourself, login using the box on the home page while using IE (Firefox doesn't have a problem). user: mwtest8 pass: testpass Here is the php config of the server [2]. Note that IE is set to "Check for newer pages: automatically" in Options -> Temporary Internet Files -> Settings Thoughts on how to resolve this are welcome. [1] http://www.nshp.org/phpinfo.php [2] http://www.nshp.org/phpinfo.php ------------------------------------------------------------------------ June 16, 2004 - 03:38 : duztin I had this problem, fix the date on your pc, mine was a month ahead and my cookies were expiring too soon. ------------------------------------------------------------------------ July 27, 2004 - 21:18 : killes(a)www.drop.org Setting to cvs. Is the fix proposed by duztin a real fix? if not: what else could we do? ------------------------------------------------------------------------ October 16, 2004 - 22:45 : mathias Attachment: http://drupal.org/files/issues/browser_caching.patch (644 bytes) I'm moving this to critical because in some cases this bug causes the hidden $edit['destination'] value of the login form to be set to 'logout', and to the user it appears they can't login since they are immediately logged out again. Very frustrating. The other side effect of this browser caching bug are, as stated above, the authenticated user will receive stale pages and if you have the login block enabled it will look as though they're were unexplicably logged out. It all depends on your browser and its settings, but to attempt to reproduce: 1. Login to your site. 2. Next, Click the homepage link. If you are served a stale copy of the page, you've hit the bug. This seems to happen more with IE and Safari than Firefox. A potential patch is to have Drupal issue the following header: header('Cache-Control: no-store, no-cache, must-revalidate'); It works, but I don't know the implications this has on other Drupal components such as RSS conditional GETS and gzip page serving. ------------------------------------------------------------------------ October 21, 2004 - 19:30 : mathias Attachment: http://drupal.org/files/issues/browser_caching_0.patch (593 bytes) Thanks to Ethereal [3] and LiveHTTPHeaders [4], I was able to trace this problem to the Cache-Control header being sent by Mac OS X server. On this OS, mod_expires [5] is enabled by default for Apache which sets the Cache-Control time to 60 seconds for dynamically rendered pages. The implications of this action are that once you login, re-visiting any page on the site will result in stale, locally-cached versions if you viewed that page within 60 seconds of logging in. Since you weren't logged in on those pages, the system will have appeared to logged you out. It will keep doing this unless you wait 60 seconds to login. Thus, users perceive this as a failure to successfully log in. This new patch doesn't tweak bootstrap.inc. Instead it uses .htaccess to test if mod_expires is enabled and resets the caching time to 1 second for dynamically rendered content. The benefit of this approach is that it doesn't interfere with other types of caching that may be in place for images, pdf files, etc. # Overload mod_expires variables. <IfModule mod_expires.c> # Reduce the time dynamically generated HTML pages are cache-able. ExpiresDefault A1 </IfModule> Down the road it may also be wise to consider sending our own caching headers to maintain control of our caching environment. I reviewed the following pieces of software, all of which intentionally disable caching by the client browser or proxy caches. I just grabbed the ones I thought were most popular. Plone (Cache-Control parameter is configurable) Wordpress (except for RSS feeds) eZpublish Mambo phpBB And if you're so inclined, here's the relevent code snippets [6] for each piece of software. [3] http://www.ethereal.com/ [4] http://livehttpheaders.mozdev.org/ [5] http://httpd.apache.org/docs/mod/mod_expires.html [6] http://asitis.org/tmp/cms_cache_review.txt ------------------------------------------------------------------------ October 21, 2004 - 19:39 : moshe weitzman I'v seen this bug on drupal.org, so this impacts more than OSX server ... Looks like a nice clean patch to me. ------------------------------------------------------------------------ October 26, 2004 - 17:21 : jvandyk +1 from me. This reduces confusion among end users while retaining caching ability for other mime types. ------------------------------------------------------------------------ October 27, 2004 - 09:05 : wazdog Does this end up having any effect on the RSS conditional GETS? If not, then +1 from me. (The WordPress code does check for RSS, so I'm thinking this may set them to expire too?) ------------------------------------------------------------------------ October 28, 2004 - 02:58 : jvandyk Attachment: http://drupal.org/files/issues/htaccess_0.patch (792 bytes) Regarding the concern about RSS caching: this patch is identical to the previous one except instead of targetting the default we target the text/html MIME type. <IfModule mod_expires.c> # Reduce the time dynamically generated HTML pages are cache-able. ExpiresByType text/html A1 </IfModule> This means that RSS feeds, which are MIME type text/xml, are not affected. ------------------------------------------------------------------------ February 11, 2005 - 02:47 : moshe weitzman i think this is a small, worthwhile patch. this bug plagues drupal.org as well. ------------------------------------------------------------------------ February 11, 2005 - 14:45 : Junyor @jvandyk: Is it just me or is there some junk before the meat of that patch? Better cache header handling would be a welcome addition here[1], but I'm not sure if the suggested patch will solve the problem efficiently. Isn't this change saying that all pages must always be redownloaded if mod_expires is enabled? Won't that cause unnecessary bandwidth and performance overhead? [1] I'm constantly seeing stale pages throughout all authenticated pages with Opera. ------------------------------------------------------------------------ February 11, 2005 - 15:42 : moshe weitzman "Isn't this change saying that all pages must always be redownloaded if mod_expires is enabled?" Correct. And that is desired behavior. A dynamic application like ours has no choice but to redownload every page (excluding RSS feeds). ------------------------------------------------------------------------ February 19, 2005 - 19:52 : killes(a)www.drop.org This patch only affects users of mod_expires and harms nobody else. +1 ------------------------------------------------------------------------ February 21, 2005 - 05:01 : Steven Applied to CVS. Do we still need our own Cache Control mechanism? I'm included to let the server handle this. ------------------------------------------------------------------------ March 9, 2005 - 07:27 : mathias Attachment: http://drupal.org/files/issues/control-browser-caching.patch (713 bytes) Browsers are sometimes pulling files from their cache and serving stale pages when instead they should be asking the server for a new copy. This is because Drupal doesn't issue its own Cache-Control headers like most other CMS's [7]. Instead those details are currently left up to each server, which users on shared hosting aren't authorized to configure. This bug rears it's ugly head when site admins use Drupal's caching mechanism. If a user clicks on the homepage after logging in, they're very likely to see a stale unauthenticated view. Or if they log out and returns to the homepage, it'll appear that they're still logged in. But perhaps the most confusing of these caching issues is when you click the login button and are once again presented with the same login form. These cached views are occurring because the browser still thinks those pages are valid in it's cache. In otherwards, it's sending if-Modified-Since headers and receiving a valid HTTP 304 response. Now this doesn't happen 100% of the time in all cases. It very much depends on the browser (usually Firefox or Safari but never Konqueror) and how the server is configured (Mac OS X server can be quite troublesome for example while a default FreeBSD install of apache usually sends the proper headers). The most elegant solution I've come up with is to issue our own Cache-Control headers after a request has been cached by Drupal's caching mechanism. The header workflow then becomes: // User requests a page that isn't in the Drupal cache table HTTP 200 (server issues it's own caching headers) // User requests the same page (now in the cache table) HTTP 200 (Drupal issues it's own caching headers explicitly stating not to cache the page) // User requests the same page (now in the cache table) HTTP 304 (server issues it's own caching headers) If I'm understanding how things work, this lets the browser use the cached page only as long as we're sending 304 responses. When the user logs in, the browser cache is invalidated since a different set of headers are emitted, causing the stale copies to expire. The end result is that browsers are still allowed to do caching of requests (including XML feeds) but only hold on to those copies until Drupal says otherwise. [7] http://asitis.org/tmp/cms_cache_review.txt ------------------------------------------------------------------------ March 9, 2005 - 07:37 : chx +1 ------------------------------------------------------------------------ March 9, 2005 - 09:25 : Bèr Kessels +1 from me. Nice clean patch. Works in FF and konq, cannot test in IE, which has very aggressive caching, AFAIK. ------------------------------------------------------------------------ March 9, 2005 - 19:43 : mathias Setting this to active at the moment since Safari users are still experiencing caching issues, albeit less in frequency. ------------------------------------------------------------------------ March 10, 2005 - 05:12 : mathias Attachment: http://drupal.org/files/issues/control-browser-caching_0.patch (1.14 KB) I think this is the elegant catch-all case. The most problematic page with stale caching is the frontpage. Not variable_get('site_frontpage'), but when $_GET['q'] is NULL. The solution that works is to make sure this request is never cached by the browser (Drupal can still cache it of course). So in summary. This patch should resolve all browser caching problems while still gracefully emitting HTTP 304 headers in all cases but the / request. ------------------------------------------------------------------------ March 10, 2005 - 07:21 : Dries -1 for the $_GET['q'] addition. While it might be the most problematic page, it is also the most popular page. The $_GET['q'] scenario merely hides the fact that the headers/caching are not working like they should. After a POST operation (eg. log in), Drupal should never send a cached page. This is checked for in page_get_cache() and page_get_cache(). Maybe those checks are bogus. ------------------------------------------------------------------------ March 11, 2005 - 05:52 : mathias Attachment: http://drupal.org/files/issues/control-browser-caching_1.patch (698 bytes) I figured it out. Let's assume for a moment that we're using Drupal caching and the cache table is empty. A page is requested and the browser and Drupal both cache it. On the next request Drupal pulls the page from its cache and all of a sudden the browser sees a different set of headers sent for the same page (such as an etag and gzip header), so another HTTP 200 response is invoked. Finally on the third request for the same page, everything lines up and a HTTP 304 is emitted, saving valuable bandwidth. This is true for subsequent requests until the Drupal cache is cleared. The caching problem is a result of some browsers getting confused between the first and second requests for the same page. Sending 304s for a page that has multiple cached copies confuses the heck out of some browsers. In the case of Safari, it tries to resolve this by displaying the most recent copy it has (even if the server told it not to cache that copy). Other browsers just show their last known cacheable copy which is still wrong. The solution is to explicitly tell the browser when to cache a page that will be 304'd later on. In Drupal talk, this means the browser shouldn't cache a request that isn't also in the Drupal cache table. In the above example this would be the first request.

1 0

[drupal-devel] [bug] [pgsql] location field in locales_source is the wrong field type.,
by Steven 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/11689 Project: Drupal Version: cvs Component: locale.module Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: adrian Updated by: Steven Status: patch The first patch was apparently applied to CVS already. But it seems that in the pgsql code, the temporary column "old_location" is not dropped? Still, we should decide on this... either we: - Remove the substring checking completely and change "location" to text in both pgsql and mysql. or - We go back to a 128-char location, change the db columns back, and implement killes' improved checker. By the way killes, I think the strlen($comm) < 128 in the while() condition is unnecessary with your later check in place. Steven Previous comments: ------------------------------------------------------------------------ October 18, 2004 - 17:13 : adrian Attachment: http://drupal.org/files/issues/pgsql_locales_fix.diff (2.09 KB) here's the patch ------------------------------------------------------------------------ October 18, 2004 - 17:39 : killes(a)www.drop.org The patch should not be neccessary becuase the location field is pruned to contain 128 chars. But - at least for pgsql- it doesn#t hurt either. ------------------------------------------------------------------------ October 18, 2004 - 17:57 : adrian here is an updated patch, which fixes the problem with too many unique restraints on locales_target. ------------------------------------------------------------------------ October 18, 2004 - 17:59 : adrian Attachment: http://drupal.org/files/issues/pgsql_taxo_bug_0.diff (1.96 KB) err. here is the patch. ------------------------------------------------------------------------ October 18, 2004 - 19:17 : adrian Attachment: http://drupal.org/files/issues/pgsql_locales_fix_0.diff (2.64 KB) here is a corrected patch, it contained some cruft fromt he taxonomy patch i made earlier ------------------------------------------------------------------------ October 18, 2004 - 20:53 : Goba Killes, the 128 char check is improperly implemented (the length is checked before a new substring of unknown length is added), so that check needs to be fixed in the first place. ------------------------------------------------------------------------ October 18, 2004 - 20:55 : Goba Killes, the 128 char check is improperly implemented (the length is checked before a new substring of unknown length is added), so that check needs to be fixed in the first place. ------------------------------------------------------------------------ March 13, 2005 - 21:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/locale-inc.patch (739 bytes) How about this?

1 0

[drupal-devel] [feature] Localize date formats
by Steven 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/11623 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: pancho Reported by: Goba Updated by: Steven Status: patch Firstly: "Even it may be not yet ready to be adopted in the core, it is good for individual use. " The patch queue is really part of the Drupal development process. It does not help us much to work on patches that are not intended for core. "It's not about adding more and more date formats. You will agree that the German web is a big enough market which should not be left aside anymore. Therefore the feature request is critical from my perspective at least. And the solution I presented doesn't blow up the date format lists, in the contrary it makes them easier to use. " I'm just saying, that solutions like the German date format (which has a special notation for the day numbers) or Asian formats (which have no spaces and reversed order) should really be handled through locale IMO, where date formats are picked per language, and can be added manually or through .po files. "How can you complain about the tiny version not to be used. If it doesn't exist it can't be used. " I imagine you introduced this format for a reason, no? Adding new features without knowing exactly where they should be used is silly. If you add a new feature in a patch, you should put in the work to see that this feature is actually used. I didn't really talk about splitting date/time formats for now, as it is mostly a usability thing. I'd much rather wait for a solution integrated with locale before I comment on it. Steven Previous comments: ------------------------------------------------------------------------ October 15, 2004 - 19:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats.patch (1.99 KB) Currently if I set a date format for the site, then it will be used with all interface translations. Different languages however have different needs when presenting dates. The Hungarian date format does not allow the day name to be the first and it calls for a dot between the hour and minute (yes, a dot not a colon). This means that Drupal ships with no suitable date format for Hungarians. Also none of the Hungarian date formats will be suitable on an English interface, while none of the English date formats are acceptable on a Hungarian interface on a bilingual site. The only option is to make date formats translateable. Since these are dynamic t() calls, extractor.php needs to be extended to include the date formats shipped with drupal in the pot output, so translators will get them (much like we do for some numbers and day names). I will take care of extending extractor.php, once this patch gets applied. ------------------------------------------------------------------------ October 15, 2004 - 20:00 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats_0.patch (1.99 KB) Well, the t() needs to be called on the date format set by the admin, so I needed to fix three t() calls. Updated patch attached. ------------------------------------------------------------------------ October 15, 2004 - 20:01 : killes(a)www.drop.org *g* I recall that there was a time when you didn't like this approach. Anyway, I fully endorse it and would like to see it in 4.5. There is also no suitable data format for German in core. And yes, that's a bug not a feature request. ------------------------------------------------------------------------ October 15, 2004 - 20:05 : Goba Yes, I didn't like it, because these are dynamic t()s. But since the selected format always needs to be presented in the actual language, it needs to be dynamic by nature. We have some of these dynamic t()s already, handled specially in extractor.php. ------------------------------------------------------------------------ October 16, 2004 - 00:07 : Steven I like this idea a lot, but I don't like the simplistic "wrap it all in t" feature. There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI (for example the way a node date is specified and parsed). Only those strings that are intended for user consumption should be translated. That's why I think we need a more specialized date handling component. It would deal with stuff like variations ('show hour/hide hour'), long/short variations (we need to review the usage of small/medium/long), as well as localizing them. We would need to revise the formats shipped with Drupal, but this gets tricky. For example would we only ship US-style AM/PM date formats with core? Should we only have M/D/Y ordering, or also D/M/Y ordering? If we move the time format settings to locale (where they do below, in principle) we might get a drop in usability: moving from a simple selection box, to requiring the whole localisation framework 'just to switch from 12 hours to 24 hours'. In some parts of the world, there is only one format for dates (e.g. chinese/japanese 2004年10月16日 1時00分). For them, the only variations are long vs short (whether to show the year, the time, etc), in other parts of the world all bets are off and people use what they like. This would mean that if we provide a default set of formats, and let them be translated through PO files, some languages might require more items than provided and some languages would have to use duplicates to fill all available options. On top of that, there is no guarantee that format #3 in French matches format #3 in German, so you'd need to be able to specify this per language. Ideally, we would let a language define any number of date formats, and let the user choose one of those per language. We could also provide a custom option where you enter your own date format, for the realy picky ones. The question remains: what do we do for sites without locale enabled? We can't go to requiring locale just to switch the date on a non-localized site. In that case, perhaps we could do this: - Have locale.module deal with date formats when it is enabled. Have a per-language format setting, selected from a language-specific, po-defined date format list. - Have system.module implement a 'localization' admin menu item if locale.module is /not/ enabled. This page carries the old selector, which acts like a simplified version of locale's format selector, with the list we current have in Drupal (i.e. variations of 24/12hours, d/m/y, y/m/d, m/d/y, ...). To prevent confusion, we add a link to system.module's version of the localization page, which instructs users to enable locale.module for full localization abilities). I know it sounds a bit weird (we certainly don't do this anywhere else), but it would be consistent in terms of UI (the date format is "localization" no matter how you look at it) and keep both non-localized site admins and localized site admins happy, without sacrificing too much ease of set up. ------------------------------------------------------------------------ October 16, 2004 - 10:34 : Goba Steven, you say: "/There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI/ " But the current approach is to translate the month and day names in every case, so format_date **already** assumes that the date it outputs is for human consumption and not for machines. So changing the order of the fields in user date formats should not hurt. Sure it might not be a useability dream, but it does not hurt. By the way, adjusting date formats based on user language is only a small piece of localisation not covered by Drupal core yet. I need to use one mission statement and site name in all languages, and even my primary and secondary links need to have the same text in all site languages, since they are not translateable. If we are about to find a generic solution for locale covered settings, we need to take these into account too. ------------------------------------------------------------------------ October 29, 2004 - 01:10 : Steven ""so format_date *already* assumes that the date it outputs is for human consumption and not for machines." " What I mean is changing the placement of the date components (day, month, year). For numerical dates which are parsed by a program, this will introduce bugs. I'd much rather have a cleaner date format selection method integrated with locale. ------------------------------------------------------------------------ October 29, 2004 - 14:19 : Goba Steven, the custom date formats are not translated, only those selected by the admin. And the admin can select date types with spelled out month/day names at any level, so they are not machine parsable anyway in the current Drupal version. **This patch does not introduce bugs.** I admit it does not look good, but there is no system for locale dependant admin settings yet. ------------------------------------------------------------------------ October 29, 2004 - 16:05 : Steven I'm saying we do need such a system. With your patch, the format that the admin selects in language A will not necessarily match the one in language B. We should go for locale-defined formats with a locale-neutral list to fallback on. ------------------------------------------------------------------------ March 13, 2005 - 15:55 : pancho Attachment: http://drupal.org/files/issues/dateformat.patch.zip (14.91 KB) ************************ DATEFORMAT-PATCH PACKAGE ************************ by pancho(a)suenderhauf.net 2005-03-13 03:07 This 'DateFormat' patch package only works with the latest CVS version of Drupal 4.60 RC. This 'DateFormat' patch package applies the following changes: 1. It introduces a more flexible system of standard date and time formats which helps both users and developers while staying backwards-compatible. We often see special date formats be used in modules, which is only second best, as these can neither be adapted by the user nor localized. More flexibility allows the developers to use the built-in format functions wherever possible. Changes in detail: - The standard date formats used to be combined date&time-formats. This is now split into separate date formats and time formats, to allow dates and times to be rendered in a more flexible way. - Still it's backward compatible: the combined formats - while deprecated - still exist. - A "Tiny" format is added to the "Small", "Medium" and "Large" formats. 2. It enables Drupal to show e.g. German and Hungarian date formats (with a colon as separator), which was _not_ possible before. 3. It prepares both the Drupal system and module developers for the upcoming locale_dateformat module. This module will fully localize date and time formats according to the localization of the current user. The locale_dateformat module will be available within the next weeks. I'm always happy about suggestions and criticism, if constructive. You can either write a comment on www.cvs.net or an email to pancho(a)suenderhauf.net. Bye, Pancho ------------- INSTALLATION: ------------- The package contains two patches for the latest CVS versions of Drupal 4.60 RC, both of which should be applied: 1. common.inc (patch for v.1.429) 2. system.module (patch for v.1.197) There are no changes in database structure. ------------------------------------------------------------------------ March 13, 2005 - 15:59 : pancho P.S. What the hell did I write about www.cvs.net? No, what I meant was of course www.drupal.org (here), where you can write a comment! ------------------------------------------------------------------------ March 13, 2005 - 16:08 : pancho I feel better if I refile the thread as a feature request. The only thing you could describe as a bug was that German & Hungarian date formats were not supported. The rest are definitely feature improvements. ------------------------------------------------------------------------ March 13, 2005 - 17:38 : Steven - Localizing date formats seems like something that should be solved properly in core once and tied into locale.module. We need a solution which does not pose problems with mixing languages, and which does not require us to keep adding more and more date formats to the list (e.g. what about asian date formats? They don't have spaces.) Your "if (!module_exist('locale_dateformat'))" solution is unacceptable for core. - What's the point of the 'tiny' date format if it's not used anywhere? Where would it be used? - Please don't post patches as zips, this is annoying. Just make one global patch file instead of separate ones. Multiple files can be posted with multiple follow ups. - You need to see how this affects the date usage around Drupal, e.g. the profile date field formatting, which depends on the date format being in a specific format. - Code style: check spaces around quotes. Also, avoid trailing spaces on lines, this is untidy. - This issue is not "critical" IMO. It is a new feature request, and as such should probably wait until after 4.6, as 4.6 is in feature freeze. - The apostrophes around the separator item seem a bit unnecessary. ------------------------------------------------------------------------ March 14, 2005 - 18:08 : pancho */First of all: This patch works! Even it may be not yet ready to be adopted in the core, it is good for individual use./* To Steven: Okay, Steven, I was asking for criticism... :) With some of the points you make I can agree: - This feature should be completely and properly rewritten and not just fixed to have a good solution for a longer period and not only for now. - The "if (!module_exist('locale_dateformat'))" solution is not good code style at least for core, as well as the spaces. I didn't take enough care about that, as I wanted to present a solution now, before the release of 4.6. - Sorry about the zipped patches. I didn't expect it to bother anyone. But on the other hand: - It's not about adding more and more date formats. You will agree that the German web is a big enough market which should not be left aside anymore. Therefore the feature request /is critical/ from my perspective at least. And the solution I presented doesn't blow up the date format lists, in the contrary it makes them easier to use. - How can you complain about the tiny version not to be used. If it doesn't exist it /can't be used/. - The apostrophees do make sense, because the separator can also be a single space. Nobody would identify that in the menu without apostrophees. So you were critizising some points which I will fix in a new version of the patch as soon as possible. But you didn't say anything about the split of date and time formats. To me it makes sense, as there have already been more people asking for "just date" or "just time". While I already started the development of a "locale_dateformat.module", I will put this on hold, until we figured out a good solution altogether. Anyway, I'm ready to help developing this feature within "locale.module" if I'm being asked. Otherwise developing a separate module would at least offer the so needed functionality /within this century/ ;-) Pancho

1 0

[drupal-devel] [feature] Improve functionality of block generation for book module
by Steven 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/14120 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: andremolnar Reported by: nysus Updated by: Steven Status: patch Your visibility 'fix' requires that the entire handbook has clean, hierarchical URL aliasing. This is often not the case. I understand that for sites where the book is used to organise the main structure, you might want the block visible everywhere. But it is not good for sites where this isn't the case, like Drupal.org itself. Steven Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 07: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 - 13: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 - 14: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 - 14: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 - 16: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 - 19: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 - 19: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 - 20: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 - 23: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 - 03: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 - 06: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 - 08: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 - 09: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 - 15: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 - 16: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 - 19: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 - 20: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 - 21: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 - 10: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 - 14: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 - 18: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 - 19: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 - 20: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 - 20: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 - 21: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 - 21: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 - 22:13 : nysus Can you be more specific? Why it works like what? ------------------------------------------------------------------------ December 11, 2004 - 22: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 - 22: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 - 13: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 - 13:12 : Bèr Kessels ^^--- That was me (bèr kessels) forgot to log in..... ------------------------------------------------------------------------ December 12, 2004 - 13: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 - 14: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 - 14: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 - 14: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 - 14: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 - 15: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 - 14: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 - 15: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 - 23: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 - 17: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 - 07: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 - 11: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 - 11: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 - 15: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 - 10: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 - 19: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 - 23: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 - 22: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 - 11: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 - 12:11 : Dries Just a wild guess: maybe it doesn't work because the book module's URI scheme is not hierarchical? ------------------------------------------------------------------------ January 7, 2005 - 11: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 - 11: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 - 17: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 - 03: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 - 03: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 - 20: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 - 20: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 - 21: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 - 03: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 - 19: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 - 19: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 - 22: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 - 23: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. ------------------------------------------------------------------------ January 26, 2005 - 06:45 : andremolnar 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 ------------------------------------------------------------------------ January 31, 2005 - 20:12 : Boris Mann You got me, Dries... I have since spent time testing the module on andre's site, and it does everything I can foresee needing at this point, with no functional errors. This functionality alone will make creating standalone sites that are composed of mainly static pages very, very simple. ------------------------------------------------------------------------ February 3, 2005 - 09:58 : Dries The demo-site appears to be down. Bummer. ------------------------------------------------------------------------ February 3, 2005 - 23:59 : andremolnar Attachment: http://drupal.org/files/issues/book_module_9.patch (7.58 KB) Sorry - demo site was down while database was being cleaned and latest CVS modules were being installed (general site maintenence for testing). The site is up now with a fresh database and install of Drupal CVS. UN drupaldev PW drupaldev (has access to manage blocks, books, and menus to see this patch in action) Attached is an updated patch to make use of db_rewrite_sql (instead of node_rewrite_sql). Also fixes a minor bug that appeared if you were creating the first book in the site. andre ------------------------------------------------------------------------ February 4, 2005 - 00:13 : Anonymous This patch seems to modify the blocks and menu tables directly from within book.module. (in the new book_build_menu_module_menu function) This sets a terrible precedent for other modules. IMO, these tables should be modified by functions defined within the block module or menu module (or menu.inc). Modifying the tables randomly throughout many other points in the code makes changes to these tables difficult and makes troubleshooting problems much trickier. Let's not sacrafice code organization for the sake of making the patch as small as possible. ------------------------------------------------------------------------ February 4, 2005 - 07:25 : andremolnar With regard to the blocks - the block module is doing all the block building (with the call to _block_rehash) - the only thing that this code does is preserve block settings (the select sql) before the menu is updated - and then restores those block settings (with the update sql). "Modifying the tables randomly throughout... " While I appreciate the point you are making, I would hesitate to call this random. After all the menu items being added to the menu table 'belong' to book module. There is a little bit of a discussion about the best way to go about doing this sort of thing (i.e. allowing modules to build their own menus) over at http://drupal.org/node/15198 - which includes the patch required to make this patch work. Right now there is no existing hook or method of doing this. hook_menu does not have anything in place as of yet. I have suggested the introduction of a new hook (name yet to be determined) that would be in charge of these menu_module_menu type inserts. But, I haven't heard any feedback on whether that is a good idea - or if anyone has a better idea. Anyone else have thoughts on the approach taken here or suggestions for a different/better approach? I'm willing to write the code, I would just like a little bit of input. andre ------------------------------------------------------------------------ February 4, 2005 - 07:46 : Dries I added a test page and all book blocks dissapeared? I also got an SQL error (check your watchdog messages) upon pressing the 'Submit' button. ------------------------------------------------------------------------ February 5, 2005 - 08:31 : Steven Doesn't this patch still suffer from the inability to show the menu block only on the relevant book(s)? I know we can now restrict blocks per node type, but that still doesn't help with multiple books. By the way, big code style violation: $menu_block_settings[$menu_block->path][weight] "weight" should be surrounded by quotes. Right now it is being treated as an undefined constant. This is not a good idea. Other than that there's a bunch of missing spaces... if the code looks cramped, it usually violates the coding style. + $menu_block_settings[$result->path] = array('status'=>$result->status, 'weight'=>$result->weight, 'region'=>$result->region, 'throttle'=>$result->throttle, 'visibility'=>$result->visibility, 'pages'=>$result->pages, 'types'=>$result->types); + db_query('DELETE FROM {menu} WHERE type=%d OR type=%d', MENU_MODULE_MENU | MENU_MODIFIED_BY_MODULE, MENU_MODULE_ITEM | MENU_MODIFIED_BY_MODULE); //restore menu_module_menu block settings There are several more examples. Please pay attention to this. It's incredibly annoying to have to fix it later, and it makes the code harder to read as you cannot make certain assumptions about how it is layed out. ------------------------------------------------------------------------ February 5, 2005 - 23:56 : andremolnar I am fixing up the code as we speak. I actually made a bigger faux pas by not escaping my INSERT sql string properly - (There is a quick fix, but I understand 'addslashes' is not good enough for drupal ;-). (Thank you to Dries for catching this right away on his test of the demo site). As for multiple books - you actually have more flexibility to enable as many book menus as you like - not only based on type but also by path. e.g. Could allow for: drupal.org/handbook (with some general book menu blocks enabled) drupal.org/handbook/developer (with developer book menu blocks enabled) drupal.org/handbook/developer/theme (with theme developer book menu blocks enabled) etc. (the sky is the limit). I will resubmit a patch with all of the coding style fixes requested - and I will be more careful with the coding style in the future. andre ------------------------------------------------------------------------ February 6, 2005 - 01:05 : andremolnar Attachment: http://drupal.org/files/issues/book_module_10.patch (7.7 KB) Updated Patch, Implemented code style improvements as per Steven. Fixed unescaped sql INSERT string (turns out that addslashes is more than enough in this situation, because the 'title' string has already been valided and properly inserted into the database before any of this code ever runs - i.e. this isn't coming directly from user input, but rather from the drupal database). Demo site is once again live and welcomes all testers (Thank you again to those that have already tested this out). andre ------------------------------------------------------------------------ March 13, 2005 - 23:11 : killes(a)www.drop.org Still applies. Andre: Please create patches from the Drupal root directory. ------------------------------------------------------------------------ March 15, 2005 - 11:42 : Paul Iliano This is exactly the functionality I have been waiting for. As I can see many uses for showing a book menu on all pages, I never really understood why book menus could only be shown on book pages. I'm still at DP 4.5, but as soon as 4.6 is out I will install and try it out. I'd love to see this kind of functionality in core!

1 0

[drupal-devel] [bug] Using in helptext is inconsistent
by stefan nagtegaal 18 Mar '05

18 Mar '05

Issue status update for http://drupal.org/node/18939 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: stefan nagtegaal Status: patch Attachment: http://drupal.org/files/issues/block-module.patch (1.26 KB) See attached patch... I did this a while back, but unfortunatly there was a chunk not applied. Here are updated baptches against current head/4.6 RC.. While it is currently not possible to patch whole directories at once I post the patches one by one attached in this issue.. My excuse for the inconvenience... First patch: block.module stefan nagtegaal

2 8

[drupal-devel] Why is there no designation between hooks and private functions in a module?
by Carl McDade 18 Mar '05

18 Mar '05

Maybe gotten spoiled from working with Macromedia products where everything in the core API is set with MM, but why is there no designation between drupal hook functions and private functions? Checking the docs is not useful especially given that the api changes so often. Frequent changes are also the reason that memorization does not work. Marking core hooks and other would not cost anything and would help in the creation and maintenance of contributed modules. Changing: function mymodule_validate(&$node) { To: function mymodule_dh_validate(&$node) { Or: function mymodule_validate_dh(&$node) { _dh being the core designation would make th process of updating a module easier also. This might be a solution to a naming problem also in that all core code must start with the designation. So anything after that can be used including the underscore character. Changing the hook invoke code has to be done but from the looks of it this is not a big change. Carl McDade

9 19