August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Handle full URLs in url() and l()
by moshe weitzman 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/10888 Post a follow up: http://drupal.org/project/comments/add/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: moshe weitzman -Status: patch (code needs review) +Status: patch (code needs work) hopefully adrian or someone else will chase down the remaining urls which should use this function. moshe weitzman Previous comments: ------------------------------------------------------------------------ Thu, 16 Sep 2004 15:01:24 +0000 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ Thu, 30 Sep 2004 11:09:30 +0000 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ Mon, 24 Jan 2005 20:06:26 +0000 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ Sun, 13 Mar 2005 22:36:34 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ Mon, 14 Mar 2005 00:05:17 +0000 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ Sat, 02 Apr 2005 06:23:10 +0000 : TDobes This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's? ------------------------------------------------------------------------ Sat, 02 Apr 2005 07:25:13 +0000 : asimmonds Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes) The &'s had been changed to & amp; , here's a valid patch ------------------------------------------------------------------------ Thu, 12 May 2005 14:57:07 +0000 : adrian This is a new patch against cvs that allows url() to create external links, with the side-effect that menu can now be used to make external links. Also closes http://drupal.org/node/10177 This will be even more important with the primary links menu integration. (This patch already cleans up a special case in phptemplate for that). Killes benchmarked this, and it turns out the difference is negligible. Requests per second: 1.33 [#/sec] (mean) = with patch Requests per second: 1.31 [#/sec] (mean) = without patch. ------------------------------------------------------------------------ Thu, 12 May 2005 14:59:57 +0000 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ Wed, 25 May 2005 04:50:08 +0000 : Steven +1 on the idea of this patch. It allows people to use l() for external links. However, I don't like the implementation. Running that complicated regexp for every url() call is simply wasteful. 95% or more of url() calls have a fixed string as parameter and point to Drupal's own paths. I suggest we create an url_external() wrapper around url() which allows external URLs. Any path which we want to allow external URLs in can use url_external() instead. The places where we use it will not be many anyway. ------------------------------------------------------------------------ Wed, 25 May 2005 05:05:55 +0000 : gordon splitting into url() url_external is not a good idea. The main reason for this patch that I see is for putting external urls into the navigation menu using the menu.module, and if all goes to plan, the primary and secondary menus. ------------------------------------------------------------------------ Wed, 25 May 2005 06:00:01 +0000 : Steven gordon: I still think this is a bit excessive. Perhaps instead of valid_url() we could use a simpler regexp !^[a-z]://!i or even strpos('://'). ------------------------------------------------------------------------ Wed, 25 May 2005 06:15:36 +0000 : gordon I am not says that it is or is not excessive. I was just saying that this is where it is going to be used, so creating url() and url_external() is not really an option ------------------------------------------------------------------------ Wed, 25 May 2005 06:57:53 +0000 : Bèr Kessels we /do/ need an external_url() thing. The links bundle (handling weblinks and the likes) willprovide this /and/ need this. People will get all sorts of tools to do /stuff/ with external links, like add permissions, track clicks etc. depending on the modules they have and the settings. All outgoing weblinks, should somehow respect those. Patches for core are coming, though. On top of that, a external_l() finction is simple. And if people want them in primary links they can do the regexping /before/ the function, not /in/ the function. The calling code can decide whether to call l() or external_l(), instead of putting logic in l() that is unneded 95% of the times. But i hereby promise to introduce such a function tbefore the end of this week :) ------------------------------------------------------------------------ Wed, 25 May 2005 07:17:47 +0000 : gordon The only thing I do not see in this plan is how with this work with the menu module and the navigation menu. ------------------------------------------------------------------------ Wed, 25 May 2005 10:04:12 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links.patch (1.75 KB) What happened to the patch i uploaded ? It doesn't use a complex regexp, but uses strpos($url, '://') < 5. ------------------------------------------------------------------------ Thu, 26 May 2005 06:19:32 +0000 : Bèr Kessels Allthough this works, is clean AND does what it should do, I still am in favour of a better nitegrated solution. So please do not yet commit this, untill I upload my patch. We can then discuss what solution to take. It will not differ a big lot though. ------------------------------------------------------------------------ Thu, 26 May 2005 08:39:32 +0000 : adrian is this the patch where you want to introduce an el() to allow for counting of external links ? That's a different patch altogether. This is primarily about stopping url() from not handling external links when there is no good reason for it to do so. Your el() has a very specific use in the weblinks api, and should probably be included with it. ------------------------------------------------------------------------ Thu, 26 May 2005 16:18:31 +0000 : Bèr Kessels Yes, that el() But let me explain why i am anxious for my solution: el(), by default will not do much, in fact it will just be an URL()-clone but one that allows outgoing links. But it has a hook-caller. Again: by default it does nothing much, for there will not be any hooks around in core. It will allow, for example, weblinks, to track clicks, or to look up a permission and allow or disallow users to follow a link. Now, the whole issue, IMO is, that we should *not* provide two ways for handling external URLS, but rather a single one, that is weblink-safe. If we would introduce URL() with outgoing links-capabilities, we can no longer track any outgoing URLs trough them. We will then have two ways for handling outgoing URLs, resulting in inconsistencies, and confused users. (hey, my anonymous users can follow link foo, while i have "follow outgig links" permission disabled for them). (BTW weblink will soon be renamed into links, just for reference) ------------------------------------------------------------------------ Thu, 30 Jun 2005 11:06:11 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links_0.patch (824 bytes) I've updated the patch. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:12:36 +0000 : adrian spoke to dries about this patch, and apart from the incomplete patch I uploaded, there are about a dozen instances where in-line html is used were l() would suffice. I will be cleaning them up and submitting a new patch soon.

1 0

[drupal-devel] [feature] Make $node->type a class in the main div of the default node.tpl.php
by moshe weitzman 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/22487 Post a follow up: http://drupal.org/project/comments/add/22487 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: moshe weitzman Status: patch (ready to be committed) looks useful to me. the properly named field for phptemplate can be overkill for small changes, and doesn't track well with core when new node fields are added. further, it is a phptemplate only solution. moshe weitzman Previous comments: ------------------------------------------------------------------------ Tue, 10 May 2005 01:36:10 +0000 : willmoy Attachment: http://drupal.org/files/issues/nodetype_theming.patch (716 bytes) This patch would change the main div of, for example, a sticky book node from: <div class="node sticky"> to: <div class="node node-book sticky"> This is to aid theming; motivated by trying to theme forums differently from pages etc. It uses the same convention as node type-specific blocks (e.g. class="block block-book") and it is should be completely backward compatible so long as people do not have very odd tastes in class names. ------------------------------------------------------------------------ Tue, 10 May 2005 11:30:24 +0000 : adrian You could also just copy node.tpl.php to your theme dir and modify it there to user $node->type, and if you only want to do something for forum nodes, you could copy the node.tpl.php to node-forum.tpl.php PHPTemplate has been moved to core for 4.7, so I will only accept this patch for the 4.6 branch if it is accepted into core. Otherwise your templates will just magically stop working. ------------------------------------------------------------------------ Tue, 10 May 2005 14:42:04 +0000 : stefan nagtegaal I do think this is nicer than the way of having multiple node.$type.tpl.php files as we have now... ------------------------------------------------------------------------ Tue, 10 May 2005 14:49:33 +0000 : willmoy Both are useful. This exposes options to CSS that wouldn't otherwise be there, but there are of course PHP things that you can only do in node-whatever.tpl.php. This patch augments current functionality, it doesn't replace it or make it redundant. ------------------------------------------------------------------------ Wed, 11 May 2005 18:33:36 +0000 : factoryjoe This will be in the upcoming versions of SpreadSpread (was SpreadFirefox), Lincoln's Revenge and Democratica. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:53:13 +0000 : willmoy Ready to be committed if accepted.

1 0

[drupal-devel] [feature] Improve functionality of block generation for book module
by spades 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/14120 Post a follow up: http://drupal.org/project/comments/add/14120 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: andremolnar Reported by: nysus Updated by: spades Status: patch (code needs review) Just wanted to add my name to the list that this would be a great feature to add to drupal core. I'm currently using the patch for my site which makes it difficult to do any updates to the latest release as it will break them. I use the site mainly as a documentation site so this is something that would be ideal. It is a very simple site that so far I've found to be very useful. Keep up the great work! spades Previous comments: ------------------------------------------------------------------------ Thu, 09 Dec 2004 06:12:37 +0000 : 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). ------------------------------------------------------------------------ Thu, 09 Dec 2004 12:35:23 +0000 : 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 ------------------------------------------------------------------------ Thu, 09 Dec 2004 13:54:00 +0000 : nysus Glad you like it and thanks for fixing that up. It was left over from an older version of my patch. ------------------------------------------------------------------------ Thu, 09 Dec 2004 13:54:54 +0000 : 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 ------------------------------------------------------------------------ Thu, 09 Dec 2004 15:29:53 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Dec 2004 18:53:35 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Dec 2004 18:58:24 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Dec 2004 19:06:27 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Dec 2004 22:32:04 +0000 : 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? ------------------------------------------------------------------------ Fri, 10 Dec 2004 02:51:58 +0000 : 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. ------------------------------------------------------------------------ Fri, 10 Dec 2004 05:51:35 +0000 : 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. ------------------------------------------------------------------------ Fri, 10 Dec 2004 07:26:10 +0000 : 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. ------------------------------------------------------------------------ Fri, 10 Dec 2004 08:11:55 +0000 : 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). ------------------------------------------------------------------------ Fri, 10 Dec 2004 14:49:10 +0000 : 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 ------------------------------------------------------------------------ Fri, 10 Dec 2004 15:04:01 +0000 : 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? ------------------------------------------------------------------------ Fri, 10 Dec 2004 18:36:01 +0000 : 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'? ------------------------------------------------------------------------ Fri, 10 Dec 2004 19:45:42 +0000 : 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. ------------------------------------------------------------------------ Fri, 10 Dec 2004 20:08:54 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 09:52:37 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 13:02:54 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 17:34:43 +0000 : 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? ------------------------------------------------------------------------ Sat, 11 Dec 2004 18:06:56 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 19:00:17 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 19:52:22 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 20:03:31 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 20:54:01 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 21:13:20 +0000 : nysus Can you be more specific? Why it works like what? ------------------------------------------------------------------------ Sat, 11 Dec 2004 21:24:12 +0000 : 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. ------------------------------------------------------------------------ Sat, 11 Dec 2004 21:41:25 +0000 : 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 ------------------------------------------------------------------------ Sun, 12 Dec 2004 12:11:11 +0000 : 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. ------------------------------------------------------------------------ Sun, 12 Dec 2004 12:12:14 +0000 : Bèr Kessels ^^--- That was me (bèr kessels) forgot to log in..... ------------------------------------------------------------------------ Sun, 12 Dec 2004 12:34:21 +0000 : 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? ------------------------------------------------------------------------ Sun, 12 Dec 2004 13:01:58 +0000 : Dries My summary is this: +1 on the functionality, -1 on the implementation. The code itself is good, but the usability/integration is not. ------------------------------------------------------------------------ Sun, 12 Dec 2004 13:13:08 +0000 : 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? ------------------------------------------------------------------------ Sun, 12 Dec 2004 13:20:39 +0000 : 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. ------------------------------------------------------------------------ Sun, 12 Dec 2004 13:55:56 +0000 : 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). ------------------------------------------------------------------------ Sun, 12 Dec 2004 14:03:41 +0000 : nysus Well, just for the record, I reversed that functionality per your suggestion and uploaded the patch. The indiviudal book blocks now appear automatically. ------------------------------------------------------------------------ Mon, 13 Dec 2004 13:56:53 +0000 : 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. ------------------------------------------------------------------------ Mon, 13 Dec 2004 14:50:00 +0000 : 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?" ------------------------------------------------------------------------ Mon, 13 Dec 2004 22:31:54 +0000 : 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. ------------------------------------------------------------------------ Wed, 15 Dec 2004 16:39:32 +0000 : 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. ------------------------------------------------------------------------ Thu, 16 Dec 2004 06:55:04 +0000 : 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. ------------------------------------------------------------------------ Thu, 16 Dec 2004 10:07:03 +0000 : 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. ------------------------------------------------------------------------ Thu, 16 Dec 2004 10:35:55 +0000 : Dries We can worry about the menu integration later. Let's focus on the new option's usability/interaction design first. ------------------------------------------------------------------------ Thu, 16 Dec 2004 14:51:23 +0000 : 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. ------------------------------------------------------------------------ Sat, 18 Dec 2004 09:54:19 +0000 : 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? ------------------------------------------------------------------------ Tue, 21 Dec 2004 18:47:22 +0000 : 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 ------------------------------------------------------------------------ Tue, 21 Dec 2004 22:55:08 +0000 : 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. ------------------------------------------------------------------------ Wed, 22 Dec 2004 21:02:14 +0000 : 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? ------------------------------------------------------------------------ Fri, 24 Dec 2004 10:01:13 +0000 : 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 ------------------------------------------------------------------------ Fri, 24 Dec 2004 11:11:34 +0000 : Dries Just a wild guess: maybe it doesn't work because the book module's URI scheme is not hierarchical? ------------------------------------------------------------------------ Fri, 07 Jan 2005 10:45:46 +0000 : 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 ------------------------------------------------------------------------ Fri, 07 Jan 2005 10:47:52 +0000 : andremolnar Attachment: http://drupal.org/files/issues/book_module_2.patch (4.98 KB) sorry - here's a patch with prefered line breaks. andre ------------------------------------------------------------------------ Fri, 07 Jan 2005 16:47:31 +0000 : nysus Andre, I've been meaning to give this a throrough look when I get a chance. Hopefully this weekend. ---Steve ------------------------------------------------------------------------ Thu, 20 Jan 2005 02:02:03 +0000 : 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 ------------------------------------------------------------------------ Thu, 20 Jan 2005 02:53:36 +0000 : 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 ------------------------------------------------------------------------ Thu, 20 Jan 2005 19:16:23 +0000 : 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. ------------------------------------------------------------------------ Thu, 20 Jan 2005 19:32:29 +0000 : 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 ------------------------------------------------------------------------ Thu, 20 Jan 2005 20:21:50 +0000 : 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 ------------------------------------------------------------------------ Mon, 24 Jan 2005 02:22:26 +0000 : 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 ------------------------------------------------------------------------ Mon, 24 Jan 2005 18:36:17 +0000 : 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 ------------------------------------------------------------------------ Tue, 25 Jan 2005 18:56:44 +0000 : 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 ------------------------------------------------------------------------ Tue, 25 Jan 2005 21:49:19 +0000 : Boris Mann +1!! Book-based automatic navigation for corporate/brochureware sites! Fantastic! Chris Messina, get in here and add a +1 to this. ------------------------------------------------------------------------ Tue, 25 Jan 2005 22:26:39 +0000 : 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. ------------------------------------------------------------------------ Wed, 26 Jan 2005 05:45:47 +0000 : 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 ------------------------------------------------------------------------ Mon, 31 Jan 2005 19:12:02 +0000 : 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. ------------------------------------------------------------------------ Thu, 03 Feb 2005 08:58:57 +0000 : Dries The demo-site appears to be down. Bummer. ------------------------------------------------------------------------ Thu, 03 Feb 2005 22:59:23 +0000 : 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 ------------------------------------------------------------------------ Thu, 03 Feb 2005 23:13:39 +0000 : 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. ------------------------------------------------------------------------ Fri, 04 Feb 2005 06:25:56 +0000 : 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 ------------------------------------------------------------------------ Fri, 04 Feb 2005 06:46:47 +0000 : 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. ------------------------------------------------------------------------ Sat, 05 Feb 2005 07:31:04 +0000 : 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. ------------------------------------------------------------------------ Sat, 05 Feb 2005 22:56:13 +0000 : 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 ------------------------------------------------------------------------ Sun, 06 Feb 2005 00:05:01 +0000 : 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 ------------------------------------------------------------------------ Sun, 13 Mar 2005 22:11:55 +0000 : killes(a)www.drop.org Still applies. Andre: Please create patches from the Drupal root directory. ------------------------------------------------------------------------ Tue, 15 Mar 2005 10:42:54 +0000 : 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! ------------------------------------------------------------------------ Fri, 18 Mar 2005 07:43:49 +0000 : Steven 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. ------------------------------------------------------------------------ Sun, 03 Apr 2005 17:12:39 +0000 : Paul Iliano As Steven says, for some type of sites (like perhaps drupal.org) it could not be desirable to show book menus on all pages. But for other sites it could be very much wanted. It seems to me a good solution would be to let administrators simply choose which node types they want book menus to appear on, like we currently can opt to switch off author/date info per node type. ------------------------------------------------------------------------ Sun, 03 Apr 2005 22:49:56 +0000 : factoryjoe In general, +1 on the auto-updating aspect of this. It does seem to be a welcome improvement to the book system, though I question Boris’ assertion that this is really a good solution for “brochure-ware” sites. For one thing, when I design a site, no matter who I am, I highly doubt that I would think “ah ha, make a book to contain the pages of my site... and the navigation will be generated from it!” While the functionality is pretty much spot-on, the name is not. So what we end up with is an overloaded book module or worse, a misnamed module. I also wonder about moving the book-generated menus around. For example, the way I would like this patch to work is for there to be top-level “chapters” (like sections of a website) and then book pages within each section, representing the individual pages. I would like to be able to put the “chapters” horizontally in the header of my site (like on OurMedia.org [1]) and then have the pages show up in the sidebar when you navigate to each section. I guess I just wonder about the flexibility of this approach and whether or not it will serve the functional needs that Boris thinks it might. What if I want the page titles to be different from the menu link titles? It doesn't seem that this is something I can control with the current partial menu integration. Anyway, with a specific eyes towards improving book navigation, I do agree that it functionally looks pretty good. I did find one serious bug and one major usability issue. It has to do with integration with the menu system. Andre will hate me for this, but I clicked through the “reset menus” command in the menu system. Doing so wiped out all the book navigation menus. If these menu items were really “locked”, then why were the book menu items wiped out? How do I restore them? As for the usability issue, it is unclear to me where I would go reorganize my book-generated navigation menus. I looked in menus, where it should logically exist, but everything was locked. Does this mean I have to go to each individual node to sort my content? [1] http://www.ourmedia.org/ ------------------------------------------------------------------------ Tue, 05 Apr 2005 23:24:19 +0000 : menesis >From what i see on demo site, there is no way to configure the site to act as it does now in case of multiple books - show book navigation block only for current book. I could only configure a block to show up on any book page, but it is shown while viewing other books, too. IMHO the preferred way to modify a module is to introduce new functionality while keeping it's behavior without any extra configuration. In this case, when creating a new book, a menu would be created, the block enabled, and configured to show up only on pages of that book. Visibility by path will not work, because all book pages have url like node/1653 by default, need a block setting for that (true="Show on any book's pages", false="Show only on current book's pages", false by default). The tricky part is that menu module, which provides the block and it's configuration, does not know which book is being displayed. ------------------------------------------------------------------------ Sun, 17 Apr 2005 21:38:07 +0000 : bobo For those of us without linux, can someone please add the latest patch to the Drupal 4.5 book.module. I would like to use it asap for a website I'm creating for an animal welfare group. This is really cool, I hope you guys find a way to get it put into the latest version of Drupal. It should be a core peice of code. It seems strange to me that an option to click wether or not you want a book to display on the main page doesn't exist... Bobo ------------------------------------------------------------------------ Mon, 18 Apr 2005 17:23:11 +0000 : bomarmonk This functionality seems crucial to completing the organizational website that I have developed with Drupal. Yet, I've applied the book.module and menu.inc patches to Drupal 4.6 and can't seem to get by book blocks to display on the front page. Why not? Is it because I'm using the front_page.module? I'm still using a themed drupal page for the front page. I definitely need help with this. ------------------------------------------------------------------------ Wed, 20 Apr 2005 17:45:56 +0000 : andremolnar It occurs to me, as I finally dive back into this, that the main issue is that people want BOTH the new way of handling blocks (because of greater flexibility of putting a book block anywhere they like) AND the old way (because people have sites where they only want to book block to show up in the current book's nodes - at the exclusion of all other books). At some point in the patch history, both options were available by simply leaving book.module's own block generation code intact AND implementing the new code that inserted items into the menu system and let menu.module handle block creation. This was deemed to be bad. (The argument being that there shouldn't be two sections of code generating blocks for one module. Essentially duplicating each other's efforts). The good news is that in an attempt to address the issue I added a welcome configuration option to the block.module - but it wasn't enough to REALLY solve the problem. As menesis pointed out, the problem is that when the block generation is handed off to the menu module, the menu module doesn't have any way of knowing that the blocks it is generating based on the menu structure are 'books' - and hence there is no way to know that a particular book's navigation block should only show up in a particular book - it simply becomes a block like any other block and must follow the same rules. Quite frankly I think people should just suck up the fact that in order to move forward and offer improved functionality some other functionality is deprecated. But, I suspect that that argument won't fly in this case - its just too big a paradigm shift *wink*. All kidding aside, I am going to try and find a solution. In the mean time a REAL issue was raised by factoryjoe when he noticed the blocks could be wiped out simply by 'resetting' menu's in the menu admin. This is NOT desired and should be reasonably easy to fix by telling menu module not to dump menu's generated by modules during a 'reset'. {And no joe I didn't mind you messing up the blocks on the demo site - it raised a very valid problem}. If anyone is interested I am going to be placing pre-patched files in my sandbox - so if people like the new functionality despite losing traditional book block functionality they can just download the pre-patched files. And if people want to monkey with the code and contribute solutions there is a place to do it. http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/andremolnar/book… More to come. andre ------------------------------------------------------------------------ Thu, 28 Apr 2005 15:43:58 +0000 : bomarmonk Andre, I really appreciate the work you and others have put into making the book module and menus/blocks better. I am fairly new to PHP, mySQL, Drupal etc., but I would like to offer some suggestions anyway (even if they are a bit naive). I have tested the patched versions of menu.inc and book module and would like to offer my support for the following added functionality: 1) Have support to allow or disallow the root page of the book in the navigation block (this would definitely be desireable for many using book blocks for hierarchal menus). a) However-- another desired (more useful?) behavior might be to not display the currently viewed book page whether it is the root page, second page, third page, etc. Food for thought. 2) Allow individual book blocks to behave in the traditional manner, or to enable certain book blocks to show up on every page (as site navigation). 3) This feature would also be complemented by the ability to show navigation blocks for sections or chapters within a larger book. This way, you could create a "master" book with a larger table of contents (providing an index of book titles) and still allow concise, focused navigation within the chapter nav blocks. Again, I am sorry If I've repeated anything I've already said in another post (a little double posting), but I felt this was the best place to sum up some of the functionality I feel is currently missing from the book module. Since I am a novice, feel free to correct me or give me verbal lashings. I can take it. ------------------------------------------------------------------------ Fri, 29 Apr 2005 15:29:30 +0000 : mcduarte2000 I also have one desire... I wanted an option to expand completly the menu block to the 2nd or 3rd level. Not only the section the user is currently in, but all the sections. This would be great to be able to use it as well as site navigation. And I believe is not difficult to implement. Regards, Miguel ------------------------------------------------------------------------ Sun, 01 May 2005 15:57:08 +0000 : Dries I committed a change to the block module that lets people use PHP to specify when a particular block should show up. So if you make it so that the book blocks show up on _every_ page (like all other blocks), administrators can still use PHP to limit their visibility. Showing the book block on every page (unless instructed otherwise) makes for improved consistency and is more likely to match the administrator's expectations. Mind to take a look at this to see how this would affect the proposed patch? Let us focus on getting the right blocks in core, and worry about their visibility later. ------------------------------------------------------------------------ Sun, 01 May 2005 18:23:28 +0000 : andremolnar The normal behaviour of these blocks is to show up everywhere by default. So we are on the right track. I am going to have to bake a new patch if there are changes to the block module (particularly new settings). More to come. andre ------------------------------------------------------------------------ Wed, 04 May 2005 16:01:46 +0000 : andremolnar Attachment: http://drupal.org/files/issues/book_module_11.patch (12.26 KB) Okay, I finally had a minute to update this patch. The latest patch - does everything that the previous patches did plus: The menu.module is modified slightly so that "reset menu" doesn't wipe out menu's generated by the book module. It only kills changes to the default navigation menu and other custom menu's defined in the menu.module admin interface. FactoryJoe (chris) found this bug in the last version - thank you for that. While I was at it in the menu.module: Since the book module menus are wiped and re-built with every change to a book I had to remove the option of adding 'custom' elements to these menus (or else people would loose those custom items with every change to a book). I did this simply by not including MENU_MODULE_MENUs in the option list that is generated. I've gone ahead and created a patch from the root which also includes the patch required to menu.inc I will be placing pre-patched files up in my sandbox if people want to test that way - or you can always take a look at the demo site and try this out. (I recently updated the demo site to the latest changes in CVS/HEAD). As dries pointed out there is a change to the block.module that will allow anyone to add some PHP logic to handle when/if a block shows up on a site. Hopefully that change is sufficient to address people's concerns about the way book blocks used to show up. Looking forward to people's comments. andre ------------------------------------------------------------------------ Wed, 04 May 2005 16:07:29 +0000 : andremolnar Attachment: http://drupal.org/files/issues/book_module_11_0.patch (12.26 KB) Okay, I finally had a minute to update this patch. The latest patch - does everything that the previous patches did plus: The menu.module is modified slightly so that "reset menu" doesn't wipe out menu's generated by the book module. It only kills changes to the default navigation menu and other custom menu's defined in the menu.module admin interface. FactoryJoe (chris) found this bug in the last version - thank you for that. While I was at it in the menu.module: Since the book module menus are wiped and re-built with every change to a book I had to remove the option of adding 'custom' elements to these menus (or else people would loose those custom items with every change to a book). I did this simply by not including MENU_MODULE_MENUs in the option list that is generated. I've gone ahead and created a patch from the root which also includes the patch required to menu.inc I will be placing pre-patched files up in my sandbox if people want to test that way - or you can always take a look at the demo site and try this out. (I recently updated the demo site to the latest changes in CVS/HEAD). As dries pointed out there is a change to the block.module that will allow anyone to add some PHP logic to handle when/if a block shows up on a site. Hopefully that change is sufficient to address people's concerns about the way book blocks used to show up. Looking forward to people's comments. andre ------------------------------------------------------------------------ Wed, 04 May 2005 16:13:14 +0000 : andremolnar Whoops sorry for the double post there - not sure what happened. Just wanted to correct myself - I'm not going to put the pre-patched files in my sandbox. I already decided that wasn't a good idea for CVS stuff anyway or else I would have to constantly update it. BUT - the demo site is live if you want to test it out there. andre ------------------------------------------------------------------------ Wed, 04 May 2005 19:00:22 +0000 : Steven Dries: while having a piece of PHP is certainly flexible enough, it is far from user-friendly. Ideally we could have each module define custom visibility options for its menus. Then book.module could have a toggle between "always show block" "only show on its book pages". ------------------------------------------------------------------------ Wed, 04 May 2005 20:11:23 +0000 : andremolnar Steven just reminded me of something - something which hasn't got much discussion (and I had completely forgotten about since this patch process started so long ago). The change to menu.inc to allow for a menu type of MENU_MODULE_MENU and MENU_MODULE_ITEM were generic name choices to offer future flexibility for other modules to define menu's in some way (not unlike what this book patch has done). Currently though, I have no code to check which module created the menu items. For now, that doesn't pose a problem because book module would be a first - but if other modules decide to do something similar (say contrib modules) - there needs to be a way to distinguish module_menus from one another so they don't step on each other's toes. This is simple enough to fix - just an extra field in a table - and an extra field check in the code. The question is 'where should the extra field be - and what should it be called'. I think a 'module' field in the menu table seems like the obvious choice - but I'd like to hear what everyone has to say. andre ------------------------------------------------------------------------ Thu, 05 May 2005 08:56:47 +0000 : Dries I had a look at this patch and ... 1. In the PHPDoc I read: /"Do not return from hook_menu() implementations."/ (two occurrences) but I have no idea what this means. 2. How about we rename book_build_menu_module_menu() to _book_rebuild_menu()? 3. IMO, it is slightly better to centralize all calls to book_build_menu_module_menu() in book_nodeapi. 4. I don't like book_build_menu_module_menu(). While it is good code, it fiddles with menu system internals, manipulates the {menu} table, etc. I can't think of a better solution though. 5. I don't think the use of addslashes() is appropriate here. Are you trying to prepare strings for use in a SQL query? 6. Are these /mega INSERTs/ ANSI SQL or are these an MySQL-ism? 7. It is better to populate an array, and to implode(', ', $inserts) it. Like that, you don't have to fix things up with rtrim($tree, ', '). 8. Is there a particular reason we can't use dynamic menus (eg. in the !$may_cache-clause in book_menu())? ------------------------------------------------------------------------ Thu, 05 May 2005 16:01:16 +0000 : andremolnar "1. In the PHPDoc I read: "Do not return from hook_menu() implementations." (two occurrences) but I have no idea what this means. " I took my cue from the PHPDocs for MENU_CUSTOM_ITEM and MENU_CUSTOM_MENU which say the same thing, and I understood to mean... "Don't try to make this kind of menu/item via the menu hook of your module." - Which is what I mean in this case. "2. How about we rename book_build_menu_module_menu() to _book_rebuild_menu()? " Sure thing "3. IMO, it is slightly better to centralize all calls to book_build_menu_module_menu() in book_nodeapi " I'm not sure that I follow (which does not mean that i'm not sure this is right). From the drupaldocs "...do not use [_nodeapi] to perform actions on your type of node alone. Instead, use the hooks set aside for node modules, such as hook_insert()..." Are you saying that its preferable to do: function book_nodeapi (&$node, $op, $teaser, $page) { switch ($op) { case 'insert': book_build_menu_module_menu(); //.. But, wouldn't that run the code on ALL node inserts (and updates and deletes)? I don't think we want to do that. But I am not a guru - can someone help me grasp this - I might be too thick to understand the nodeapi hook. "4. I don't like book_build_menu_module_menu(). While it is good code, it fiddles with menu system internals, manipulates the {menu} table, etc. I can't think of a better solution though. " I think the only other solution requires a whole new hook that handles this specific type of transaction in a standardized way. I agree that its a bit 'wrong' to be mucking with menu system and the block system willy nilly from a module - but without such a hook, I couldn't see another way to accomplish what needs to be accomplished here given the current drupal API. "5. I don't think the use of addslashes() is appropriate here. Are you trying to prepare strings for use in a SQL query? " All I need done with add slashes is to escape the 'title' strings for use in the SQL insert. These strings have already been validated (they are coming from straight from the DB - NOT from user input). Is there a preferred meathod? "6. Are these mega INSERTs ANSI SQL or are these an MySQL-ism? " I can't find anything that says this is ANSI 92/99/ or greater... BUT - it is supported in MySQL and Postgres (and possibly DB2 and some MS) (someone correct me if I am wrong). The reason I went with this syntax is because of the performance boost on MySQL: see http://dev.mysql.com/doc/mysql/en/insert-speed.html Clearly this can be turned into a series of inserts in a loop, but I was trying to be conscious of the impact of this code on a site with large books that are updated regularly. "7. It is better to populate an array, and to implode(', ', $inserts) it. Like that, you don't have to fix things up with rtrim($tree, ', ') " Both work - I'm not sure which is better. What is the overhead of an array and an implode call - vs. a string that has a single character stripped off the end? The first is potentially more flexible - but I think that latter is quicker (sorry can't back that up with a benchmark, but I'd be willing to bet $1CDN). Regardless, I'm okay with such a change if everyone thinks its better. "8. Is there a particular reason we can't use dynamic menus (eg. in the !$may_cache-clause in book_menu())? " This is a very good question. I will have to investigate. I quite frankly have no idea how the dynamic menu type works... If its the right tool for the job I'm happy to use it - Would that address Point #4? If it is the right tool and does address point #4 you will see it in the next patch. ------------------------------------------------------------------------ Thu, 05 May 2005 16:12:44 +0000 : Steven RE: addslashes, you should use the normal db_query() mechanism for this. Building queries like you do is a bad idea because, even if it is safe in one particular instance, it sends a very bad signal to others. Build the query string with placeholders in it (%d, %s), and put the arguments in an array. Pass the array as a single argument to db_query: db_query("UPDATE ....", $parameters); ------------------------------------------------------------------------ Tue, 05 Jul 2005 21:48:20 +0000 : shark What is the status of this? Is this patch going to go into the Drupal core? I'd really like to use it for my site to automatically create the site navigation for a simple site, unless there is a better way to do that. ------------------------------------------------------------------------ Wed, 13 Jul 2005 17:56:15 +0000 : theoa I agree with shark - a permanent book menu would really help normal users in creating and maintaining small sites. Normal users get scared when the UI changes - especially menus appear and disappear. I think it would be an even better thing if in: Home » administer » blocks >> configure >> Custom visibility settings - you could set a block to "always show this block" ------------------------------------------------------------------------ Wed, 20 Jul 2005 16:32:15 +0000 : eXce Hey guys, I didn't follow this discussion all the way and I just downloaded the last patch and now I am searching for a way to enable the blocks because there is nothing displayed and the patch removed the hook_block function ... So did I overread an important release comment? How can I make that work ? thanks.

1 0

[drupal-devel] restricting access to file downloads with flexinode
by David Cohen 05 Aug '05

05 Aug '05

Hey all, I'm using Drupal on a project where some content is available to all, but some content restricted to paid subscribers. To make uploading content easy for the site administrators, I've created a custom node type with the wonderful flexinode module. This allows the admins to upload several files (which belong together) in one easy step. This works great, but I wouldn't be writing if it didn't get more complicated, so please read on. My node type corresponds to a 'lesson'. Each lesson has some public information which everyone can see, such as a title, and a preview image. Other content is restricted to only paid users, this includes flash files and quicktime videos. I'm using templates and php code to ensure users see only the portions they're supposed to see. My problem is the uploaded files. By default, anyone can download the files uploaded via flexinode. I never show an anonymous user the link to a flash file, but if they type "system/files?file=private-file.swf" in the URL, they'll be able to download it anyway. My second problem is that lots of files will be uploaded, and eventually the files directory will be a real mess. So I want to control where each of these files goes. For instance, the previews could all go to 'files/preview_images' and the movies to 'files/videos'. I've address both of these problems in the attached patch to flexinode. I'd appreciate it if some experienced drupal coders would check my work. I'd like to see something like this checked into the code base. I hope this would be useful to others as well. I'm happy to keep working on it if that's what it takes. If you review the code, search for '???' and see if you can answer the questions I left in the comments. Also - yes, I'm aware much of flexinode's functionality will be replaced by CCK, but I need this functionality today. And, I'd hoped to isolate my changes by adding another field type to flexinode. But to make it work I had to change flexinode's file download hook. And since I had to do that, I figured I might as well make the changes to the existing field_file.inc. As far as I know, the changes do not affect behavior for existing flexinode files. Here's how it works.... When adding a file field to a flexinode, you now have the option of specifiying a permission with that file. User's can download only if they have that permission. Note that different files within a node can have different permissions. This allows me to keep the preview images public but restrict access to the other files. Also, you have the option of specifying a subdirectory of files/ where the file will be saved. I plan to make this more dynamic, so that the directory can be a function of the other fields in the node. For instance, instead of just typeing 'private-files', you could type 'private-files/%flexinode_2' and %flexinode_2 would be substituted with a value from the node. This might get a little tricky but it will really help me organize the files. Finally, while I have your attention (if you're still reading) a couple questions about drupal's file handling... How much overhead is involved in using drupal to restrict access to the files? That is, can I serve a lot of large files via the file_transfer method? Is there some better way through Apache? Also, the file.inc seems pretty heavy handed about forcing all files to be in a subdirectory of files/ (the 'file_directory_path' variable). It would be nice to have some public files in files/ but also be able to save some uploads elsewhere (say /var/private-files). file_save_upload currently makes this impossible. If it were possible, some files could be served up efficiently via urls like 'mysite.com/files/foo.swf' while others could be restricted 'mysite.com/system/file?file=/var/private-files/bar.swf'. I'd like to see something like that. This concludes my first post to drupal-devel. I hope I haven't offended anyone ;) Drupal is a really great product. Cheers, -Dave P.S. Also attaching a patch to file.inc. The call to drupal_access_denied when downloading a file should return immediately after that call.

3 3

[drupal-devel] [bug] if postgresql function
by plj 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/23499 Post a follow up: http://drupal.org/project/comments/add/23499 Project: Drupal -Version: 4.6.0 +Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: plj Status: patch (code needs review) I'm advocating it too. Just tested the fix in comment #13 against HEAD. Works well. I suggest that Dries would just commit it; at least the situation improves dramatically, because as now, the failure is certain. Perhaps there is something wrong in igric's setup, if the patch does not work? What is your Postgres version? plj Previous comments: ------------------------------------------------------------------------ Tue, 24 May 2005 04:32:18 +0000 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ Tue, 24 May 2005 22:07:49 +0000 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ Tue, 24 May 2005 22:28:20 +0000 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ Tue, 24 May 2005 22:32:56 +0000 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. ------------------------------------------------------------------------ Tue, 24 May 2005 22:43:22 +0000 : patrickslee So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. ------------------------------------------------------------------------ Tue, 24 May 2005 22:45:41 +0000 : patrickslee Oops... my <>s are stolen. IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ Wed, 25 May 2005 05:20:34 +0000 : cchamilt Yes that line works great. Thanks for your help! ------------------------------------------------------------------------ Wed, 25 May 2005 05:52:24 +0000 : patrickslee This patch shows another problem. The last post user will always show "Anonymous" or whatever you defined. Looking for solution... ------------------------------------------------------------------------ Wed, 25 May 2005 06:00:55 +0000 : patrickslee Use this line instead: IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) Don't forget there are two places in forum.module need to be changed. ------------------------------------------------------------------------ Wed, 25 May 2005 06:10:26 +0000 : patrickslee Oh what have I done! I changed nothing! IF(l.last_comment_uid <> 0 AND l.last_comment_uid IS NOT NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ Wed, 25 May 2005 10:12:14 +0000 : adrian perhaps we could also just add more wrapper functions for the specific types ? create or replace function IF (integer, anyelement, anyelement) returns anyelement as ' SELECT if (($1 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; Or something. ------------------------------------------------------------------------ Wed, 25 May 2005 10:41:18 +0000 : plj '' was missing. So what adrian actually means is this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT if (($1 <> 0) AND NOT nullvalue($1), $2, $3); ' LANGUAGE 'sql'; I applied that and now forums work -- no module patches. PostgreSQL 7.4.7. ------------------------------------------------------------------------ Wed, 25 May 2005 10:45:07 +0000 : plj Sheesh. I meant that '<>' was missing. Gotta learn to use that preview button... ------------------------------------------------------------------------ Wed, 25 May 2005 21:53:11 +0000 : patrickslee Is nullvalue() a function? I cannot find it in neither postgres manual nor mysql manual. Use "IS NOT NULL" would be better as it is more standard-compatible. SO we have this: CREATE OR REPLACE FUNCTION IF (integer, anyelement, anyelement) RETURNS anyelement AS ' SELECT IF(($1 <> 0) AND $1 IS NOT NULL, $2, $3); ' LANGUAGE 'sql'; Looks we have a satisfying fix here. Is this fix going to be committed in CVS for next release? ------------------------------------------------------------------------ Thu, 26 May 2005 00:26:58 +0000 : adrian hostmaster=# \df nullvalue List of functions Result data type | Schema | Name | Argument data types ------------------+------------+-----------+--------------------- boolean | pg_catalog | nullvalue | "any" But it doesn't matter to me =) ------------------------------------------------------------------------ Thu, 26 May 2005 19:21:57 +0000 : Dries Can you guys provide a patch? I don't have a PostgreSQL setup to test it against. Will commit to DRUPAL-4-6 and HEAD. ------------------------------------------------------------------------ Thu, 26 May 2005 20:29:38 +0000 : patrickslee Attachment: http://drupal.org/files/issues/database.pgsql_3.patch (363 bytes) Here you have it. ------------------------------------------------------------------------ Wed, 15 Jun 2005 10:18:32 +0000 : igrcic Dont know about you guys but that patch doesnt work for me in drupal 4.6.1!? Im using PostgreSQL. Instead im using following function that works just fine if(integer,text,text) BEGIN IF $1 THEN RETURN $2; END IF; IF NOT $1 THEN RETURN $3; END IF; END; ------------------------------------------------------------------------ Sun, 19 Jun 2005 08:55:54 +0000 : Dries Just so you know: I'm not committing this patch yet because one user commented that it didn't work. Waiting for a follow-up from the PostgreSQL front. ------------------------------------------------------------------------ Sun, 19 Jun 2005 11:28:04 +0000 : igrcic Ok, here how it is now. First of all, forget my previous if FUNCTION :) Currenty im using drupal 4.6.1 and I had that problems with forums. Now Im using two if functions, because one is required for forums and I forgot for another another one, but I know that it was called because of different function parameters (bool, int). So one for the forum is : CREATE OR REPLACE FUNCTION "if"(integer, text, text) RETURNS text AS ' BEGIN IF $1 IS NOT NULL AND $1 > 0 THEN RETURN $2; ELSE RETURN $3; END IF; END; ' LANGUAGE 'plpgsql'; The another one is standard function that comes with drupal database.inc.pgsql file CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; Im using it for a while and everything works nice! Before I posted this topic I replaced function with that one in patch and it worked nice with this one too. But I know that once I had some error with it (didn't write it down grrr), so im stickin with the first function, because it work perfectly for me! And we have to have 2 functions, one for boolean and one for integer! In mysql it isnt so. Hope everything's clear now! ------------------------------------------------------------------------ Sun, 19 Jun 2005 11:30:15 +0000 : igrcic Oops, maybe I screwed up something with formatting my post :( Hope you can fix it, sorry ------------------------------------------------------------------------ Thu, 23 Jun 2005 03:43:59 +0000 : Arto Drupal 4.6.1 on PostgreSQL 7.4.7: The patch (database.pgsql_3.patch) fixes the problem; igrcic's method would certainly fix it as well. Advocate committing the patch.

1 0

[drupal-devel] [bug] Bootstrap totally broken with PostgreSQL
by plj 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/28274 Post a follow up: http://drupal.org/project/comments/add/28274 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: plj Updated by: plj Status: patch (code needs work) Attachment: http://drupal.org/files/issues/bootstrap.inc_4.patch (986 bytes) Just cheked out today's HEAD, installed, and attempted to access main page. Results: [client 10.10.59.23] PHP Notice: Undefined variable: _SESSION in /var/www/drupal_HEAD/includes/bootstrap.inc on line 771 [client 10.10.59.23] PHP Notice: Undefined variable: _SESSION in /var/www/drupal_HEAD/includes/bootstrap.inc on line 771 [client 10.10.59.23] PHP Notice: Undefined variable: _SESSION in /var/www/drupal_HEAD/includes/bootstrap.inc on line 771 [client 10.10.59.23] PHP Warning: pg_query(): Query failed: ERROR: syntax error at or near "cache" at character 13 in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 69 [client 10.10.59.23] PHP Fatal error: ERROR: syntax error at or near "cache" at character 13\nquery: LOCK TABLES cache WRITE in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 86 [client 10.10.59.23] PHP Notice: Undefined property: cache in /var/www/drupal_HEAD/includes/session.inc on line 45 [client 10.10.59.23] PHP Warning: pg_query(): Query failed: ERROR: syntax error at or near "cache" at character 13 in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 69 [client 10.10.59.23] PHP Fatal error: ERROR: syntax error at or near "cache" at character 13\nquery: LOCK TABLES cache WRITE in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 86 [client 10.10.59.23] PHP Warning: pg_query(): Query failed: ERROR: syntax error at or near "cache" at character 13 in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 69 [client 10.10.59.23] PHP Fatal error: ERROR: syntax error at or near "cache" at character 13\nquery: LOCK TABLES cache WRITE in /var/www/drupal_HEAD/includes/database.pgsql.inc on line 86 This is because bootstap.inc uses LOCK/UNLOCK TABLES, but PostgreSQL does not support this syntax. I've attached a patch that fixes the problem on pgsql, but this probably still needs work as it most likely won't work on MySQL as such. plj

1 2

[drupal-devel] [bug] apache and drupal both compressing pages
by fago 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/13224 Post a follow up: http://drupal.org/project/comments/add/13224 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: killes(a)www.drop.org Reported by: bertboerland(a)www.drop.org Updated by: fago Status: patch (code needs review) i don't have this issue any more. since i'm using a new server running apache2 with deflate instead of apache1 with mod-gzip everything is fine. unfortunately, i've no access to the old server (for testing) any more. fago Previous comments: ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:22:55 +0000 : bertboerland(a)www.drop.org hi this weekend I went ahead and upgraded drupal from 4.4 to 4.5 on a machine, I dint have time/priority (in Dutch these words are almost the same :-) sooner. The core went fine and as usual lots of unpacking, configuring for all the modules I want to experiment with. After some time I tried to access the site in a -just-to-be-sure- moment from windows machine with an IE browser without being logged in. I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. I never got this from my firefox on both windows and Linux while being logged in. Later I could reproduce this on a firefox browser without being logged in. After some time / thinking I think I found out that both apache (my webserver) and drupal were compressing (gzipping) the page resulting in a browser that was able to uncompress the page once. But if it was a cached page and drupal was zipping this and Apache as well, the browser was just displaying a gzipped page. I have a rather old setup with an ancient version of apache but does this sound possible? Since I am hosting (some) other content outside the drupal dir, I would like to keep apache gzipping pages so is there an option to stop drupal from compressing pages? ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:32:16 +0000 : killes(a)www.drop.org Which method use your Apache to gzip the pages? Which version is it? I find it strange that we get this report only several weeks after the release. I suspect that your particualr set up is borken. ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:45:23 +0000 : bertboerland(a)www.drop.org The reason I waited so long was that I wanted others to find out this :-) Mind you, I *think* it is the fact that they are both compressing the cached pages. You might want to try it out for yourself by going to http://willy.boerland.com/myblog and in case a there is a cached page you will end up by downloading a binary that once renamed to a gz and unpacked, will give you the html file. drupal 4.5 apache: 1.3.26 (with *all* security patches) php: 4.2.3 Content-Encoding: gzip And yes, since I quess 100+ sites are already at 4.5 I think it is related to my setup. However, I understand correctly there i no way of having drupal stop sending out compressed pages? There is no configuration option? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:06:05 +0000 : killes(a)www.drop.org Yes, I get funny garbage, too. The apache version you run is the one Debian provides. It is still used very often, but still nobody but you seems to experience the problem, so I still think that somehow your setup is broken. Apache should recognize that the page is already gzipped. Do you use mod_gzip or libz? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:57:14 +0000 : bertboerland(a)www.drop.org Since this one is more or less critical for me but not for the RotW, re-setting priority to "nomal". I am using zlib btw. Did you try to save the file and unzip it? And I am correct that there is no option to disable cached paged from being zipped? ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:30:23 +0000 : bertboerland(a)www.drop.org I think I "solved" this for me by changing the bootstrap.inc setting this to postponed, if no-one else experiences this problem within 3 weeks I will close this issue. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:31:19 +0000 : killes(a)www.drop.org I tried to download it now, but you must have changed something, the page renders fine. You are right, there is no option to disable gzipped cache. I'd really like to discover the reason for this problem. Normally, zlib should check for gzipped content and do not gzip it again. Drupal sends the appropriate header. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:32:25 +0000 : killes(a)www.drop.org Locking could have prevented this. ;) ------------------------------------------------------------------------ Sun, 21 Nov 2004 12:36:23 +0000 : axel(a)drupal.ru > I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. Sometimes I got same thing in Mozilla Firefox with differrent sites (not sure, but not only with Drupal) when I work trough my local proxies (I use chain of two proxies on my Debian box - one for banner deleting (privoxy) and second for offline page caching (wwwoffle)). I don't dig to details of such behaviour, but simply switch off proxies and reload browser's page help to solve problem - then I again switch on proxies and page loaded ok. May be you also access site through proxy? Then you need to check this proxy settings, I think. ------------------------------------------------------------------------ Sun, 21 Nov 2004 21:13:26 +0000 : bertboerland(a)www.drop.org Axel, no it was not related to proxys or even the browser. It was related to cached pages being zipped by drupal and sent to apache that was ziping the page as well, resulting in a zipped zipped page for the client that only once unzipped the page and hence displayed a binary ------------------------------------------------------------------------ Tue, 21 Dec 2004 17:10:12 +0000 : bertboerland(a)www.drop.org It seems like I was not the only one [1]. There is not enough information about the others setup (/please post here!/) to find a generic cause, but it is sure that some setups will cause zipped pages to be zipped. [1] http://drupal.org/node/14569 ------------------------------------------------------------------------ Thu, 03 Feb 2005 15:03:17 +0000 : leafish_dylan Has anybody found a better way to fix this problem? Disabling the storage of compressed cache pages in bootstrap.inc works, but it's ugly. Is an uncompressed cache likely to take up a lot of space in the database? If not, perhaps a global "gzip/zlib compression" option for Drupal would be simpler. ------------------------------------------------------------------------ Sat, 05 Feb 2005 14:40:16 +0000 : Anonymous As author of the gzipped cache patch I'd really appreciate if the people who experience this problem could supply detailed(!) info on their setup and the headers sent both by the browser and the server. I'd like to fix the problem (if there is one on Drupal's side) or at least document correct server settings if the problem is there. ------------------------------------------------------------------------ Sat, 05 Feb 2005 16:54:42 +0000 : bertboerland(a)www.drop.org Here some info, please ask if you need more: apache 1.3.26 mmcache (version unknown) drupal 4.5.1 Note: I didnt post (and thought abaout!) the MMcache between drupal and apache. The configuration of mmcache is extension="mmcache.so" mmcache.shm_size="16" mmcache.cache_dir="/tmp/mmcache" mmcache.enable="1" mmcache.optimizer="1" mmcache.check_mtime="1" mmcache.debug="0" mmcache.filter="" mmcache.shm_max="0" mmcache.shm_ttl="0" mmcache.shm_prune_period="0" mmcache.shm_only="0" mmcache.compress="1" headers: http://willy.boerland.com/myblog/ GET /myblog/ HTTP/1.1 Host: willy.boerland.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=307f07c169e3bbcbe92d150026c97583 HTTP/1.x 200 OK Date: Sat, 05 Feb 2005 16:45:49 GMT Server: Apache-AdvancedExtranetServer/1.3.26 X-Powered-By: PHP/4.2.3 Content-Encoding: gzip Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 ---------------------------------------------------------- ------------------------------------------------------------------------ Mon, 21 Feb 2005 10:53:02 +0000 : coma I have exactly the same problem my setup it's currently apache 2.0.52, php 4.3.10 and drupal 4.5.2. The relevant info it's: from apache: <Location /> # Insert filter SetOutputFilter DEFLATE # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </Location> In php.ini: zlib.output_compression = On And I can assure you that my problem was that last element, changing zlib.output_compression to off solved the problem, and the output of all php scripts (not only drupal) it's compressed by either drupal or apache. You can test this things with wget: wget --header "Accept-Encoding: gzip,deflate" http://localhost/ The file wget drops should be a gzippped html, if you do a zcat and get a plain html it's all good, if you get another gzipped file it has been double compressed. ------------------------------------------------------------------------ Sat, 02 Apr 2005 19:38:42 +0000 : moshe weitzman i too am seeing strange behavior here. specifically, php is simply dieing after printing out the $cache->data in drupal_page_header(). truly, i don't think drupal should be storing gzipped cache, nor do i think it should perform gzip at all. these are better handled at php or apache layers. ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:06:14 +0000 : mjr Apparently i am observing a new variant of that problem in one of the subsites of my 4.6 test installation: after enebaling cacheing, lynx, w3m and the gecko based browsers display garbage. lynx tells me it wants to load a file named index.html.gz. wget http://beate/drupal46/ on that site gives a readable html page. w3m -dump_head tells me: Received cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c HTTP/1.1 200 OK Date: Sat, 23 Apr 2005 13:56:19 GMT Server: Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-10 mod_ssl/2.0.53 OpenSSL/0.9.7e mod_perl/1.999.20 Perl/v5.8.4 X-Powered-By: PHP/4.3.10-10 Set-Cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c; expires=Mon, 16 May 2005 17:29:39 GMT; path=/ Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Sat, 23 Apr 2005 13:56:19 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Content-Encoding: gzip Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Apparently, the site sends uncompressed pages but tells the browser it is compressed. BTW, links2 and dillo do disply the page but will not allow me to log in and disable cacheing. Any clues? Thanks Michael ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:08:42 +0000 : mjr Perhaps I should mention that zlib.output_compression = Off in my php.ini ------------------------------------------------------------------------ Sat, 23 Apr 2005 18:43:30 +0000 : bertboerland(a)www.drop.org /Apparently i am observing a new variant of that problem / Please open a new bug report, since your problem is likely unrelated to this problem, open an new problem and you might want to use a link to this problem, but dont use this problem for other than descibed. ------------------------------------------------------------------------ Sat, 04 Jun 2005 23:53:22 +0000 : mjr no, it is not unrelated. After some investigation, i found out that the garbage is being stored in drupals cache. This has been reported in this thread. My present workaround is to completly disable drupals caching (and to manually delete the compressed pages from the database.) Whats the use of letting drupal compress pages and store these int its cache table? Just saving a few cycles of CPU time? On the cost of letting the web server and its client decide wether to transfer compressed or uncompressed data - they have the protocol to do that, drupal has not. Michael ------------------------------------------------------------------------ Mon, 06 Jun 2005 16:48:30 +0000 : killes(a)www.drop.org We save cpu cycles and storage space. Apache only needs to check the Encoding header which will be easy. I do not know why zlib output compression doesn't check those headers for some (or all?) people. ------------------------------------------------------------------------ Fri, 10 Jun 2005 23:32:40 +0000 : bluec I have the same problem with Drupal 4.6.1: If the site delivers a cached page it is gziped twice and the result is garbage in my browser window. I tried two differnet browsers: Firefox and Opera and it's the same problem with both of them. I recorded the HTTP headers: - Cache turned on - zlib-compression turned on - Result: Garbage http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/fachschaft/ Cookie: PHPSESSID=6ddbf3d5a32d-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:16:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:49:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Content-Length: 5024 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Now I turned off compression by setting in my .htaccess php_flag zlib.output_compression On and the result is OK: http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/index.html Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:17:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d208-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:50:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 5054 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Turning off the cache is a solution as well. As soon as cache and zlib are operating the result is garbage. If you need any other information just let me know. I can turn on compression at any time and test other solutions. Chris ------------------------------------------------------------------------ Mon, 27 Jun 2005 18:10:12 +0000 : aries The same. Interesting, only one page doing this, all others are not. -- Aries http://aries.mindworks.hu ------------------------------------------------------------------------ Thu, 07 Jul 2005 14:46:34 +0000 : fago quite strange. i never had problems with this, then i upgraded from 4.6.1 to drupal 4.6.2... now i must turn off the cache, or i've the troubles mentioned here... (i haven't touched the apache or php config in the meanwhile) ------------------------------------------------------------------------ Thu, 14 Jul 2005 09:47:32 +0000 : bertboerland(a)www.drop.org yet another one [2], closed than one, raised importance here. [2] http://drupal.org/node/25326 ------------------------------------------------------------------------ Sat, 16 Jul 2005 19:52:26 +0000 : bertboerland(a)www.drop.org killes sigested that is want apache that compressed the page but drupal and php was the first one. after some testing, i found out he was correct! to solve this 1) either comment out the gzip lines in bootstrap.inc 2) put /etc/php.ini "zlib.output_compression = On" to OFF (real) Fix needed. Drupal should look if the page was zipped in the first place.... ------------------------------------------------------------------------ Fri, 29 Jul 2005 12:17:46 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip.patch (2.45 KB) Here's a patch that needs some testing. ------------------------------------------------------------------------ Fri, 29 Jul 2005 13:18:51 +0000 : Dries Why do we set $do_cache to TRUE in the nested if's? $do_cache is already set to TRUE higher up so we're just overwriting TRUE with TRUE? Also, can we rename $do_cache to $cache? That is more Drupal-ish. Does that solve all apache-Drupal-caching problems or only some? I vaguely remember we agreed to add a setting, because that was perceived the only True Solution. ------------------------------------------------------------------------ Fri, 29 Jul 2005 18:22:04 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip_0.patch (2.46 KB) I've updated the patch. The patch is intended to cure all the problems we had. It needs testing, though. I don't recall to agreeing that a setting would be needed. Just for the record: Steven measured the ratio of serving gzipped cached pages to re-unzipped pages on drupal.org to be about 5.1:1. That is from 6 page requests which we serve from the cache only one needs the cache to be unzipped. This is probably due to crawlers who only speak http 1.0. ------------------------------------------------------------------------ Sat, 30 Jul 2005 14:33:42 +0000 : bertboerland(a)www.drop.org people who expierenced this problem, please try the patch of killes and report here if successful or not. i will patch as well ------------------------------------------------------------------------ Mon, 01 Aug 2005 14:55:47 +0000 : moshe weitzman In my opinion, this is a case of misplaced optimization. Very little CPU is required to gzip a document. Why else would Apache and PHP provide an option to do this *for every page*. PHP knows that all its pages will be dynamic yet it still offers this option. My recommendation is this feature entirely, and take the win in simplicity/code reduction. Furthermore, we won't have any more issues like this one, which has lingered unfixed for 9 months. Admins who want gzip will elect to do so in their php.ini or .htaccess. ------------------------------------------------------------------------ Fri, 05 Aug 2005 13:46:03 +0000 : Arto If the caching mechanism is to be patched, that'd be a good time to also tackle the problem that it's currently unusable on PostgreSQL: http://drupal.org/node/26369

1 0

[drupal-devel] [bug] apache and drupal both compressing pages
by Arto 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/13224 Post a follow up: http://drupal.org/project/comments/add/13224 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: killes(a)www.drop.org Reported by: bertboerland(a)www.drop.org Updated by: Arto Status: patch (code needs review) If the caching mechanism is to be patched, that'd be a good time to also tackle the problem that it's currently unusable on PostgreSQL: http://drupal.org/node/26369 Arto Previous comments: ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:22:55 +0000 : bertboerland(a)www.drop.org hi this weekend I went ahead and upgraded drupal from 4.4 to 4.5 on a machine, I dint have time/priority (in Dutch these words are almost the same :-) sooner. The core went fine and as usual lots of unpacking, configuring for all the modules I want to experiment with. After some time I tried to access the site in a -just-to-be-sure- moment from windows machine with an IE browser without being logged in. I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. I never got this from my firefox on both windows and Linux while being logged in. Later I could reproduce this on a firefox browser without being logged in. After some time / thinking I think I found out that both apache (my webserver) and drupal were compressing (gzipping) the page resulting in a browser that was able to uncompress the page once. But if it was a cached page and drupal was zipping this and Apache as well, the browser was just displaying a gzipped page. I have a rather old setup with an ancient version of apache but does this sound possible? Since I am hosting (some) other content outside the drupal dir, I would like to keep apache gzipping pages so is there an option to stop drupal from compressing pages? ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:32:16 +0000 : killes(a)www.drop.org Which method use your Apache to gzip the pages? Which version is it? I find it strange that we get this report only several weeks after the release. I suspect that your particualr set up is borken. ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:45:23 +0000 : bertboerland(a)www.drop.org The reason I waited so long was that I wanted others to find out this :-) Mind you, I *think* it is the fact that they are both compressing the cached pages. You might want to try it out for yourself by going to http://willy.boerland.com/myblog and in case a there is a cached page you will end up by downloading a binary that once renamed to a gz and unpacked, will give you the html file. drupal 4.5 apache: 1.3.26 (with *all* security patches) php: 4.2.3 Content-Encoding: gzip And yes, since I quess 100+ sites are already at 4.5 I think it is related to my setup. However, I understand correctly there i no way of having drupal stop sending out compressed pages? There is no configuration option? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:06:05 +0000 : killes(a)www.drop.org Yes, I get funny garbage, too. The apache version you run is the one Debian provides. It is still used very often, but still nobody but you seems to experience the problem, so I still think that somehow your setup is broken. Apache should recognize that the page is already gzipped. Do you use mod_gzip or libz? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:57:14 +0000 : bertboerland(a)www.drop.org Since this one is more or less critical for me but not for the RotW, re-setting priority to "nomal". I am using zlib btw. Did you try to save the file and unzip it? And I am correct that there is no option to disable cached paged from being zipped? ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:30:23 +0000 : bertboerland(a)www.drop.org I think I "solved" this for me by changing the bootstrap.inc setting this to postponed, if no-one else experiences this problem within 3 weeks I will close this issue. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:31:19 +0000 : killes(a)www.drop.org I tried to download it now, but you must have changed something, the page renders fine. You are right, there is no option to disable gzipped cache. I'd really like to discover the reason for this problem. Normally, zlib should check for gzipped content and do not gzip it again. Drupal sends the appropriate header. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:32:25 +0000 : killes(a)www.drop.org Locking could have prevented this. ;) ------------------------------------------------------------------------ Sun, 21 Nov 2004 12:36:23 +0000 : axel(a)drupal.ru > I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. Sometimes I got same thing in Mozilla Firefox with differrent sites (not sure, but not only with Drupal) when I work trough my local proxies (I use chain of two proxies on my Debian box - one for banner deleting (privoxy) and second for offline page caching (wwwoffle)). I don't dig to details of such behaviour, but simply switch off proxies and reload browser's page help to solve problem - then I again switch on proxies and page loaded ok. May be you also access site through proxy? Then you need to check this proxy settings, I think. ------------------------------------------------------------------------ Sun, 21 Nov 2004 21:13:26 +0000 : bertboerland(a)www.drop.org Axel, no it was not related to proxys or even the browser. It was related to cached pages being zipped by drupal and sent to apache that was ziping the page as well, resulting in a zipped zipped page for the client that only once unzipped the page and hence displayed a binary ------------------------------------------------------------------------ Tue, 21 Dec 2004 17:10:12 +0000 : bertboerland(a)www.drop.org It seems like I was not the only one [1]. There is not enough information about the others setup (/please post here!/) to find a generic cause, but it is sure that some setups will cause zipped pages to be zipped. [1] http://drupal.org/node/14569 ------------------------------------------------------------------------ Thu, 03 Feb 2005 15:03:17 +0000 : leafish_dylan Has anybody found a better way to fix this problem? Disabling the storage of compressed cache pages in bootstrap.inc works, but it's ugly. Is an uncompressed cache likely to take up a lot of space in the database? If not, perhaps a global "gzip/zlib compression" option for Drupal would be simpler. ------------------------------------------------------------------------ Sat, 05 Feb 2005 14:40:16 +0000 : Anonymous As author of the gzipped cache patch I'd really appreciate if the people who experience this problem could supply detailed(!) info on their setup and the headers sent both by the browser and the server. I'd like to fix the problem (if there is one on Drupal's side) or at least document correct server settings if the problem is there. ------------------------------------------------------------------------ Sat, 05 Feb 2005 16:54:42 +0000 : bertboerland(a)www.drop.org Here some info, please ask if you need more: apache 1.3.26 mmcache (version unknown) drupal 4.5.1 Note: I didnt post (and thought abaout!) the MMcache between drupal and apache. The configuration of mmcache is extension="mmcache.so" mmcache.shm_size="16" mmcache.cache_dir="/tmp/mmcache" mmcache.enable="1" mmcache.optimizer="1" mmcache.check_mtime="1" mmcache.debug="0" mmcache.filter="" mmcache.shm_max="0" mmcache.shm_ttl="0" mmcache.shm_prune_period="0" mmcache.shm_only="0" mmcache.compress="1" headers: http://willy.boerland.com/myblog/ GET /myblog/ HTTP/1.1 Host: willy.boerland.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=307f07c169e3bbcbe92d150026c97583 HTTP/1.x 200 OK Date: Sat, 05 Feb 2005 16:45:49 GMT Server: Apache-AdvancedExtranetServer/1.3.26 X-Powered-By: PHP/4.2.3 Content-Encoding: gzip Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 ---------------------------------------------------------- ------------------------------------------------------------------------ Mon, 21 Feb 2005 10:53:02 +0000 : coma I have exactly the same problem my setup it's currently apache 2.0.52, php 4.3.10 and drupal 4.5.2. The relevant info it's: from apache: <Location /> # Insert filter SetOutputFilter DEFLATE # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </Location> In php.ini: zlib.output_compression = On And I can assure you that my problem was that last element, changing zlib.output_compression to off solved the problem, and the output of all php scripts (not only drupal) it's compressed by either drupal or apache. You can test this things with wget: wget --header "Accept-Encoding: gzip,deflate" http://localhost/ The file wget drops should be a gzippped html, if you do a zcat and get a plain html it's all good, if you get another gzipped file it has been double compressed. ------------------------------------------------------------------------ Sat, 02 Apr 2005 19:38:42 +0000 : moshe weitzman i too am seeing strange behavior here. specifically, php is simply dieing after printing out the $cache->data in drupal_page_header(). truly, i don't think drupal should be storing gzipped cache, nor do i think it should perform gzip at all. these are better handled at php or apache layers. ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:06:14 +0000 : mjr Apparently i am observing a new variant of that problem in one of the subsites of my 4.6 test installation: after enebaling cacheing, lynx, w3m and the gecko based browsers display garbage. lynx tells me it wants to load a file named index.html.gz. wget http://beate/drupal46/ on that site gives a readable html page. w3m -dump_head tells me: Received cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c HTTP/1.1 200 OK Date: Sat, 23 Apr 2005 13:56:19 GMT Server: Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-10 mod_ssl/2.0.53 OpenSSL/0.9.7e mod_perl/1.999.20 Perl/v5.8.4 X-Powered-By: PHP/4.3.10-10 Set-Cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c; expires=Mon, 16 May 2005 17:29:39 GMT; path=/ Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Sat, 23 Apr 2005 13:56:19 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Content-Encoding: gzip Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Apparently, the site sends uncompressed pages but tells the browser it is compressed. BTW, links2 and dillo do disply the page but will not allow me to log in and disable cacheing. Any clues? Thanks Michael ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:08:42 +0000 : mjr Perhaps I should mention that zlib.output_compression = Off in my php.ini ------------------------------------------------------------------------ Sat, 23 Apr 2005 18:43:30 +0000 : bertboerland(a)www.drop.org /Apparently i am observing a new variant of that problem / Please open a new bug report, since your problem is likely unrelated to this problem, open an new problem and you might want to use a link to this problem, but dont use this problem for other than descibed. ------------------------------------------------------------------------ Sat, 04 Jun 2005 23:53:22 +0000 : mjr no, it is not unrelated. After some investigation, i found out that the garbage is being stored in drupals cache. This has been reported in this thread. My present workaround is to completly disable drupals caching (and to manually delete the compressed pages from the database.) Whats the use of letting drupal compress pages and store these int its cache table? Just saving a few cycles of CPU time? On the cost of letting the web server and its client decide wether to transfer compressed or uncompressed data - they have the protocol to do that, drupal has not. Michael ------------------------------------------------------------------------ Mon, 06 Jun 2005 16:48:30 +0000 : killes(a)www.drop.org We save cpu cycles and storage space. Apache only needs to check the Encoding header which will be easy. I do not know why zlib output compression doesn't check those headers for some (or all?) people. ------------------------------------------------------------------------ Fri, 10 Jun 2005 23:32:40 +0000 : bluec I have the same problem with Drupal 4.6.1: If the site delivers a cached page it is gziped twice and the result is garbage in my browser window. I tried two differnet browsers: Firefox and Opera and it's the same problem with both of them. I recorded the HTTP headers: - Cache turned on - zlib-compression turned on - Result: Garbage http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/fachschaft/ Cookie: PHPSESSID=6ddbf3d5a32d-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:16:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:49:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Content-Length: 5024 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Now I turned off compression by setting in my .htaccess php_flag zlib.output_compression On and the result is OK: http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/index.html Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:17:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d208-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:50:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 5054 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Turning off the cache is a solution as well. As soon as cache and zlib are operating the result is garbage. If you need any other information just let me know. I can turn on compression at any time and test other solutions. Chris ------------------------------------------------------------------------ Mon, 27 Jun 2005 18:10:12 +0000 : aries The same. Interesting, only one page doing this, all others are not. -- Aries http://aries.mindworks.hu ------------------------------------------------------------------------ Thu, 07 Jul 2005 14:46:34 +0000 : fago quite strange. i never had problems with this, then i upgraded from 4.6.1 to drupal 4.6.2... now i must turn off the cache, or i've the troubles mentioned here... (i haven't touched the apache or php config in the meanwhile) ------------------------------------------------------------------------ Thu, 14 Jul 2005 09:47:32 +0000 : bertboerland(a)www.drop.org yet another one [2], closed than one, raised importance here. [2] http://drupal.org/node/25326 ------------------------------------------------------------------------ Sat, 16 Jul 2005 19:52:26 +0000 : bertboerland(a)www.drop.org killes sigested that is want apache that compressed the page but drupal and php was the first one. after some testing, i found out he was correct! to solve this 1) either comment out the gzip lines in bootstrap.inc 2) put /etc/php.ini "zlib.output_compression = On" to OFF (real) Fix needed. Drupal should look if the page was zipped in the first place.... ------------------------------------------------------------------------ Fri, 29 Jul 2005 12:17:46 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip.patch (2.45 KB) Here's a patch that needs some testing. ------------------------------------------------------------------------ Fri, 29 Jul 2005 13:18:51 +0000 : Dries Why do we set $do_cache to TRUE in the nested if's? $do_cache is already set to TRUE higher up so we're just overwriting TRUE with TRUE? Also, can we rename $do_cache to $cache? That is more Drupal-ish. Does that solve all apache-Drupal-caching problems or only some? I vaguely remember we agreed to add a setting, because that was perceived the only True Solution. ------------------------------------------------------------------------ Fri, 29 Jul 2005 18:22:04 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip_0.patch (2.46 KB) I've updated the patch. The patch is intended to cure all the problems we had. It needs testing, though. I don't recall to agreeing that a setting would be needed. Just for the record: Steven measured the ratio of serving gzipped cached pages to re-unzipped pages on drupal.org to be about 5.1:1. That is from 6 page requests which we serve from the cache only one needs the cache to be unzipped. This is probably due to crawlers who only speak http 1.0. ------------------------------------------------------------------------ Sat, 30 Jul 2005 14:33:42 +0000 : bertboerland(a)www.drop.org people who expierenced this problem, please try the patch of killes and report here if successful or not. i will patch as well ------------------------------------------------------------------------ Mon, 01 Aug 2005 14:55:47 +0000 : moshe weitzman In my opinion, this is a case of misplaced optimization. Very little CPU is required to gzip a document. Why else would Apache and PHP provide an option to do this *for every page*. PHP knows that all its pages will be dynamic yet it still offers this option. My recommendation is this feature entirely, and take the win in simplicity/code reduction. Furthermore, we won't have any more issues like this one, which has lingered unfixed for 9 months. Admins who want gzip will elect to do so in their php.ini or .htaccess.

1 0

[drupal-devel] Vanilla: the forum software to look for
by Kristjan Jansen 05 Aug '05

05 Aug '05

I posted this a week ago to this list but have not seen it since -- hope this is no dupe ------------------------------------------------------------------------------------------------------------------------- http://getvanilla.com/ http://lussumo.com/community/ Comparing their approach to Drupal's we do not fare bad at all. Some tiny details I like (to rip from them ;): Not logged in: * Overall look. yes, perhaps too Typepad but nice and smooth netherless (perhaps too low-contrast, I have missed many vital UI elements) * "edited" mark next to a comment * Informative login / register dialogs Logged in: http://lussumo.com/community/signin.php guest:guest * switchable small / big textarea (but ihmo it should work vice versa, small -> big) * ajax-based (un)bookmarking * ajax-based (un)blocking topics (taxonomy) * navigation history block * search history block

2 1

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

05 Aug '05

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

2 2