- Development - lists.drupal.org

Re: [drupal-devel] PHPTemplate hits core ... finally
by K B 06 May '05

06 May '05

On 5/6/05, Matthew Hildebrand <drupal.org(a)gosherm.org> wrote: > Some of the developers at the company that I work at swear by Perforce, > which is available for free to open source projects. While this is a good thing, you cannot guarantee this will continue. Anyone following the Linux kernel is familiar with the Bitkeeper fiasco. Basically, Bitkeeper provided a free thing for Linus and other kernel developers, but eventually, they backed off this deal for various reasons. The end result is that kernel development is switching to GIT. You can read on this at kerneltrap.org and slashdot.org. > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Ber Kessels > Sent: Friday, May 06, 2005 11:54 AM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] PHPTemplate hits core ... finally > > Hello, > > I have been debating this with darix a few times already, but: > 1) moving from CVS to SVN must be done when the majority is ready for > that. We > should thus > 1.1) investigate if there are people not at all ready for a move > 1.2) investigat who will help with the move. it should never be only on > the shoulders of those few who already have a lot on their shoulders > (i.e. Dries, kjartan and Steven). > > 2) If ever we move, we should do it good. Thus look for ALL alternatives, > not just look at SVN, because its the closest at hand. > > IMO SVN is nothing more then a revised CVS. The real problems are not > solved, only made a little easier to deal with. > SVN continues on a road that, IMO, is not the perfect road for Open source > collaboration. The fact that Drupal developement is very much > decentralised, non hierarchical and above all voluntary, should be > reflected by the > RCS we choose to use. SVN gets closer then CVS, but IMO (by far) not close > enough. Again, i see it as a slightly improved CVS. but nothing more. > > I have been looking around, and read about DARCS > (http://abridgegame.org/darcs/) A system that is build purely with > decentralized, vuluntary, non-hierarchical communities in mind. IMO it > gets much closer to our ideal workflow then SVN will ever get us. > > And yes, I know its easy to sort-of emulate darcs at the client side, > while using SVN on the server, but that does not solve the whole idea of > SVN simply not being suited enough for Drupals structure and comm. (/. > http://it.slashdot.org/it/04/11/25/0136249.shtml?tid=156&tid=218) > > O, and afaik darcs is about the easiest to learn from the oss RCSs. > (http://zooko.com/revision_control_quick_ref.html) > > But that does not mean we should go for darcs, just now. I simply try to > point out we should look at all options, not just choose one, 'cause its > been chosen a lot, and thus is the first at hand. We should research, and > then choose the best for our system. > > Ber > >

1 0

[drupal-devel] [bug] Problems with using relative path names
by kbahey 06 May '05

06 May '05

Issue status update for http://drupal.org/node/13148 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: kbahey Status: patch "If we cannot use accepted standards in Drupal, then what are good is it to adhere to them in the first place? " By using paths beginning with slashes, we are not breaking any standards that I know of. "Does this patch really affect the experience of end users of Drupal? Unless I am missing something, normal people never see these errors. " The clutter in the logs is very annoying, and makes makes it harder for the site admin to find the info he needs. It also consumes bandwidth. "Google is a search engine, it is not a user. " The user here is the site admin, not the end user. "But changing Drupal to adhere to preferences of a broken crawler is not going to encourage anyone to fix their poorly implemented software either ... But I don't think appeasement is the answer to "fixing" this problem, because with this option enabled there is no impetus for the crawler programmers to fix anything. " By the same token, we can ignore MS IE's broken CSS handling and a bunch of other things, and claim that they should fix themselves. Meanwhile 80% of users are facing these issues. That is not the way to look at things. If we can implement something that does not break standards but avoid many of us the grief that this causes, then why not? A solution that allows this to be turned on or off, via an option or a settings.php flag would make everyone happy. kbahey Previous comments: ------------------------------------------------------------------------ November 18, 2004 - 22:29 : kbahey Looking at my site's logs, there seem to be several problems that are caused by Drupal's use of relative path names. If Drupal causes all the site's urls to be absolute, then none of this would be an issue. A. Search Engine Crawlers Getting lots of 404s on things like: linux/index.html/robots.txt Where 'linux' is an alias to a taxonomy, and 'index.html' is an alias to a node within that taxonomy. Another example, is recursing unnecessarily. I see 404s on things like: /linux/index.html/linux/index.html Where 'linux' is a path alias for a taxonomy term, and 'index.html' is an alias to the main node within it. This does not seem to happen when Google crawls my sites, but Yahoo's Slurp suffers from this problem, and keeps recursing. MSNBot also suffers from this. Another crawler/harvester called Blinkx/DFS-Fetch keeps adding the .css file to the relative path, getting a 404 on things like: /linux/themes/xtemplate/pushbutton/logo.gif And Fast Search Engine also attempts to access: /linux/contact/tracker/tracker/user/password The same goes for grub.org, another crawler. B. Google Cache / Archive Way Back Machine Pages in Google cache and archive.org Way Back Machine suffer form a similar problem: the .css files cannot be found, and hence rendering of the pages is not correct. Examples: Compare this: http://www.drupal.org/node/4647 To this: http://www.google.ca/search?q=cache:www.drupal.org/node/view/4647 Notice the following: How there is no formatting at all, because of the lack of a .css file The httpd log on Drupal will show errors for: linux/themes/pushbutton/style.css and linux/misc/drupal.css Also see: http://web.archive.org/web/20031016184902/http://www.drupal.org/ C. Proxy Caches: When someone is browsing my site from behind a proxy cache, the web site is hit with a rapid succession of requests, and many of it is just for bogus pages. Examples: 2004/11/17 - 17:47 404 error: linux/user/1 not found. 2004/11/17 - 17:47 404 error: linux/feedback not found. 2004/11/17 - 17:47 404 error: linux/tracker not found. 2004/11/17 - 17:47 404 error: linux/sitemap not found. 2004/11/17 - 17:47 404 error: linux/search not found. 2004/11/17 - 17:47 404 error: linux/misc not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/linux not found. 2004/11/17 - 17:47 404 error: linux/technology not found. 2004/11/17 - 17:47 404 error: linux/writings not found. 2004/11/17 - 17:47 404 error: linux/family not found. And also: 2004/11/17 - 07:23 404 error: history/user/1 not found. 2004/11/17 - 07:23 404 error: history/tracker not found. 2004/11/17 - 07:23 404 error: history/feedback not found. 2004/11/17 - 07:23 404 error: history/sitemap not found. 2004/11/17 - 07:23 404 error: history/search not found. 2004/11/17 - 07:23 404 error: history/misc not found. 2004/11/17 - 07:23 404 error: history/technology not found. 2004/11/17 - 07:23 404 error: history/science not found. 2004/11/17 - 07:22 404 error: history/history not found. 2004/11/17 - 07:22 404 error: history/writings not found. 2004/11/17 - 07:22 404 error: history/family not found. As you can tell, history and linux are aliases to taxonomy terms, and so is misc, technology, writings, family, ...etc. The user agent is appending the taxonomy term alias to the url and forming a new URL. D. Regular Browsing: There is even at least one extreme case where the following URL was accessed (the result was 404 of course) /book/view/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/logo.gif It seems it was a normal user, because the user agent is: "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)" Proposed Solution: As a proposed solution, all URLs in Drupal can be made into absolute path names. This can be done by the following: The variable $base_url in the conf.php file is broken down into two components: $base_host (the 'http://whatever-host.example.com' part WITHOUT the trailing slash) $base_path (the '/path-to-drupal' part, WITH the leading slash. If this is the DocumentRoot, then it is just a '/' character) $base_url is now $base_host concatenated with $base_path A simple filter can be written to preceed every href="path" with the $base_path variable, so it becomes "/path" This option can be turned on and off for a site. The default is to have it off so current behavior is maintained. A similar scheme applies for style sheets as well. So, did I miss something obvious? Am I seriously off the mark? Your thoughts! ------------------------------------------------------------------------ November 19, 2004 - 23:10 : chrisada I am getting similar 404 errors, mainly from rss feed link that looks like /blog/blog/feed and many manual links that are relative to drupal root. It was not a problem before Drupal 4.5, so I think there might not be a need to change all URIs to absolute. I can't see where the problem is coming from though. ------------------------------------------------------------------------ November 19, 2004 - 23:35 : kbahey I am pretty sure that these problems were happening for at least the past 10 months (ever since I moved to Drupal in January 2004). The main issue here is that crawlers and other user agents get confused by the relative path names. Using absolute paths will definitely solve this. However, is this the only solution? I am looking for a discussion of this. ------------------------------------------------------------------------ November 20, 2004 - 04:55 : Goba No absolute paths please. Having the path start with '/' solves all the mentioned problems, and is not absolute, it is relative to the domain. Sadly some crawlers and even the Google Cache does not obey to the base href. I have reported this cache problem in April to Google, and they promised they will keep it in mind... Hehe... What we need is to have the printed relative path values relative to the domain name, and not relative to the Drupal installation path. Note that this issue will appear on the drupal devel mailing list if someone finally provides a patch we can talk about :) ------------------------------------------------------------------------ November 20, 2004 - 05:19 : Dries Goba is right. We need paths relative to the domain name to fix this 'problem'. ------------------------------------------------------------------------ November 20, 2004 - 15:19 : kbahey Sorry for not making my self clear. When I said absolute, I meant that they start with just a /. I did NOT mean that they start with http://host.example.com. That would be a very bad idea. In any case, what do people think about the proposed solution (breaking down $base_url into two parts?) Also, does this address the style sheets as well, or more is needed? ------------------------------------------------------------------------ November 21, 2004 - 11:24 : chx Attachment: http://drupal.org/files/issues/common_inc_patch.txt (471 bytes) I have implemented what Goba suggested. ------------------------------------------------------------------------ November 21, 2004 - 11:43 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_0.txt (825 bytes) Maybe this one is faster? ------------------------------------------------------------------------ November 21, 2004 - 12:34 : kbahey Man! You are fast! I tried the second version. It works fine for things that are not inside the node body, I mean they have a / in front of them, as we want it to be. Two comments/issues: - If there is a URL that is already "/" representing the home page, it gets set to "//". Perhaps it should check for that case? - URLs in nodes that do not start with / do not get changed to have a / prepended to them. Do we need a filter for this? - Do we need to do something for the style sheets in the page header? I mean the "misc/drupal.css" and "themes/themename/style.css"? Thanks ------------------------------------------------------------------------ November 21, 2004 - 19:28 : kbahey Hi chx Here is a fix for the case where you have a url that is just "/". In your patch, instead of: <?php $base = $parts['path'] . '/' ; ?> Replace that by: <?php $base = ( $path == '/' ? $base : $parts['path'] . '/' ); ?> ------------------------------------------------------------------------ November 27, 2004 - 23:08 : kbahey Did this patch make it into CVS yet? If there are any objections to it, can someone please explain what they are? Thanks ------------------------------------------------------------------------ November 28, 2004 - 04:33 : Dries Shouldn't your changes be included in the patch? Also, it's better to cache $base rather than $parts. Lastly, it this patch makes it to HEAD, we should probably remove some 'base url' cruft from the themes. ------------------------------------------------------------------------ November 28, 2004 - 13:54 : kbahey Attachment: http://drupal.org/files/issues/x.diff (1 KB) Here is the patch including my fix. I am asking chx to comment on caching $base instead of $parts. Will this make it faster? ------------------------------------------------------------------------ November 28, 2004 - 14:26 : chx Hm. $base = ( $path == '/' ? $base : $parts['path'] . '/' ); this depends on path which is a parameter. Thus I fail to see how could we cache $base. I'd correct this code however $base = ( $path == '/' ? '' : $parts['path'] . '/' ); 'cos I think $base is not defined before, but this is not a problem, PHP will be happy to replace NULL with NULL... Maybe instead of all parts, only $parts['path'] is enough to be cached, yes, but the performance and memory usage difference -- I guess -- would not be noticable... ------------------------------------------------------------------------ November 28, 2004 - 18:06 : kbahey Attachment: http://drupal.org/files/issues/common-inc-patch.txt (1 KB) OK. I put in chx suggested change. This patch can go in CVS then, to rid us of the problems with paths not beginning with slash. This is not an ultimate solution still. We need to address the problem with .css files. Although the header contains a: <base href="http://example.com" /> it does not seem that major search engines and archiving sites obey it anyway. ------------------------------------------------------------------------ December 2, 2004 - 15:31 : Dries Your coding style needs work. Also, I'm not going to commit this unless the themes get fixed up: we'd end up with invalid URLs all over the place. Lastly, I wonder how portable the themes will be when Drupal is run from within a subdirectory. ------------------------------------------------------------------------ December 2, 2004 - 16:15 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_1.txt (849 bytes) Well, my patch worked from a subdirectory very well, as fact, I have not tested it from the root dir. And I think that it adheres to coding standards. So I resubmit it with the root path fix. However, my Drupal work is focused on i18n these days, and I was never into themeing so it won't be me who fixes those. ------------------------------------------------------------------------ December 2, 2004 - 17:07 : kbahey I have tested the previous patch (including my fix) with drupal installed in the DocumentRoot of the server. So, in effect, it is tested with both Drupal in / and Drupal in a subdirectory. This change fixes the problem for the crawlers and other browsers from getting confused. While it is true that there is no fix for the .css files in the HTML head section yet, this fix deals with a major part of the problem, and rids us of a major pain. Check your web server's logs some time to see what I mean. Someone who is familiar with the themes can contribute a patch later. This patch and the future fix for themes are not mutually exclusive, so let it go in CVS. ------------------------------------------------------------------------ December 9, 2004 - 10:31 : Goba Please commit this into Drupal core, this fix is badly needed. ------------------------------------------------------------------------ January 17, 2005 - 08:00 : chx Attachment: http://drupal.org/files/issues/base_url_kill.patch (4.34 KB) Well as noone have stepped in to fix this problem, I have tried to fix the themes also. themes.inc , xtemplate.engine and the bluemarine template is patched besides common.inc. Of course, more templates could follow, but first I'd like to see your opinions. ------------------------------------------------------------------------ January 17, 2005 - 08:09 : Goba I don't think that removing <base> from the themes is a good idea, using $parts['path'] should be encouraged though before the files, which would fix the google cache problem, and would still keep the HTML size low. It would also help those, who save the file to find the originating site easier, since clicking on a non-pagelocal link would lead to the online version. ------------------------------------------------------------------------ January 17, 2005 - 11:03 : Steven Definitely -1 on removing the <base&gt tag or using absolute or root-relative URLs. This tag has been around for ages, and it is the only way to make clean URLs work without bloating in the code. FYI, "base" is (first?) mentioned in Berners-Lee's HTML 1.0 draft [1]. That's June 1993. As the amount of clean URL-using sites grows, the crawlers will have to be updated. Perhaps we could prevent crawlers from going too insane by 404ing for URLs with more than say 10 components? That would prevent the really crappy ones from hammering your site. I'm all for making the <base> tag easier to handle for the user (say, by including a filter to allow simple anchor links to work as most people expect them to), but we should keep Drupal-generated URLs clean and completely relative. [1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt ------------------------------------------------------------------------ January 17, 2005 - 11:57 : kbahey The problem with css is this: The @import argument does not start with a /. This is simple to fix. We keep the "base" as it is today, but add the new variable: $base before it. So for a site where Drupal is installed in the DocumentRoot, all that will change is that /misc/drupal.css and /themes/themename/style.css will be preceded by a slash. For sites that use another path, that path will be prepended to the css file name. How about that? ------------------------------------------------------------------------ January 17, 2005 - 12:38 : Steven What exactly is the problem with the @import? As far as I know: - url() in stylesheets is interpreted relative to the base of the stylesheet, not the source document. - However, if the styles are inside an HTML document, through a style tag or style attribute, then the stylesheet's location is the same as the HTML document. - Thus, the stylesheet's base is the same as the base of the HTML document (which can be altered through the <base> tag). I just don't see why it is necessary. As far as I know, the only browser that has had problems resolving CSS urls properly was Netscape 4, which does not support @import at all, and which Drupal does not support either, because of its CSS usage. ------------------------------------------------------------------------ January 17, 2005 - 13:35 : kbahey The problem for stylesheets is as follows. I think it mainly affect crawlers and Google's cache. Say you have an installtion of Drupal in DocumentRoot. You then use url aliases, and put slashes in them. For example, you use news/general/2004-12-15.html for a node. That node still has misc/drupal.css and themes/pushbutton/style.css in the head section if the document. Crawlers get fooled by that and try to look for /news/general/misc/drupal.css and /news/general/themes/pushbutton/style.css, which don't exist. So, just prepending the new $base variable (in chx's patch) before the stylesheet @import argument would fix this issue. Assuming you are in DocumentRoot, then /misc and /themes would be used instead of just misc and themes. It would still be compliant with standards, be relative to the web site, and no ambiguous to anyone, be they crawler or browser. I hope it is clearer now. I think chx can change the patch to use the $base instead of $base_url everywhere, so as to avoid the host/domain name in the urls. ------------------------------------------------------------------------ January 17, 2005 - 16:36 : Steven But typical crawlers don't even pay attention to stylesheets, hence it wouldn't have much use for them. I just don't see why we should adjust to rare cases of buggy software. Reading out a base URL from an HTML document is dead easy, and on top of that it doesn't add more complexity as without the base tag, the document's URL is already an implicit base which has to be parsed anyway. I did not like it when we altered the <link&gt tag to accomodate buggy RSS readers and I certainly don't like it now, as this is even rarer. In both cases, it is not Drupal which is at fault. ------------------------------------------------------------------------ January 17, 2005 - 16:48 : kbahey Steven While I agree with most of what you said, the 404s show up in the logs enough to be a bother. Perhaps the original design of Drupal did not forsee that people will use url aliases to mimic directory/file hierarchies. Whether this was intended or not, it is the way many use Drupal today. It does not matter where the bug is (Drupal or the external world), as long as we can stop it ourselves, by adjusting our end of it. The fix is simple enough and does not break standards (if implemented as described with a leading / before the css). ------------------------------------------------------------------------ January 17, 2005 - 16:54 : Steven It does not break standards, but it does bloat the code in an ugly way. Why not send an e-mail to the owners of the crawlers and tell them to implement a standard that is nearly 10 years old [2] (RFC 1808)? Note that Google Cache now seems to correctly interpret base URLs [3] and even adds a <base> tag of its own. By the way, this problem has nothing to do with people using URL aliases or not, as for a browser the regular nested paths that Drupal uses (e.g. "node/1" is no different from aliases mimicking files "foo/bar.html"). [2] http://www.faqs.org/rfcs/rfc1808.html [3] http://www.google.be/search?q=cache%3Awww.drupal.org&sourceid=mozilla-searc… ------------------------------------------------------------------------ January 17, 2005 - 17:34 : Goba Steven, part of the problem is that Google cache does add a base href even if there is a base href in the document. Eg adds a <BASE HREF="http://drupal.org/node/13733"> on the plone comparision page cached. Now that since HTML does not allow more than one base tag [4] to be present, it is up to the browsers, to use the first or the last base value, or any of the base values on the page for that matter as the used base. So even pages displayed from the google cache will be buggy if a full relative path to the domain root is not specified, due to this problem. [4] http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#head.content ------------------------------------------------------------------------ January 18, 2005 - 02:14 : chx Attachment: http://drupal.org/files/issues/base_url_kill_0.patch (4.75 KB) This one does not use the whole base_url only the path part of it. HTML bloat is kept at minimal. ------------------------------------------------------------------------ February 1, 2005 - 18:33 : clairem Please please can this be done? It's a good idea in itself, but if using fully-qualified paths means we can get rid of the BASE HREF, then page anchors will work without having the overhead of a filter. That's be a huge bonus for those creating larger nodes, or who just want to be able to put a "skip navigation" link in their theme without having to abandon Xtemplate or PHPtemplate ------------------------------------------------------------------------ February 1, 2005 - 18:37 : Goba Well, speaking of skip navigation links, phptemplate and xtemplate should expose the REQUEST_URI to the templates, so when a link to an anchor on the same page is needed, the link can be formatted with the complete request URI in mind. ------------------------------------------------------------------------ February 2, 2005 - 18:40 : clairem "hptemplate and xtemplate should expose the REQUEST_URI to the templates " Should, but don't :( If BASE HREF isn't removed, surely it wouldn't be a big job to implement this tweak? ------------------------------------------------------------------------ February 17, 2005 - 09:50 : kbahey This patch is badly needed. The lack of a leading / in many paths is causing lots of problems. ------------------------------------------------------------------------ March 12, 2005 - 15:32 : kbahey Can this patch be applied for 4.6? it is really badly needed. ------------------------------------------------------------------------ March 22, 2005 - 15:50 : Dries I don't see why this is badly needed. We generate perfectly valid URLs which are supposed to be short and crispy. This patch has some advantages though, yet it is unclear which patch to go with. ------------------------------------------------------------------------ March 22, 2005 - 16:00 : chx The second patch is better. ------------------------------------------------------------------------ March 22, 2005 - 16:46 : grohk Forgive me for saying so, but since the way Drupal is generating hyperlinks is completely valid, why are you suggesting Drupal should move away from an accepted standard when the problem lies with the search engines? At the very least, this needs to be optional -- which it appears to be -- I hate the 404s too, but I hate to hear that a change in Drupal is needed to fix a Google problem. ------------------------------------------------------------------------ March 22, 2005 - 17:03 : jhriggs I have to agree with the last comment from grohk. ------------------------------------------------------------------------ March 22, 2005 - 17:39 : mathias I also agree with the two previous Drupaleers, but I wouldn't mind enabling a 'quirks mode' via my conf file to stop the flood of 404 messages. ------------------------------------------------------------------------ March 22, 2005 - 19:37 : kbahey I really can't fathom why some of us cannot deal with with the realities out there in the world. These problems are not because Drupal is broken. It is because crawlers are. We cannot just bury our collective heads in the sand and say that we are standards compliant and forget about what is out there. As an analogy, people who design themes or write CSS have to deal with the ugliness of Microsoft Internet Explorer and its intentional going against standards. You cannot tell a client or your boss that you are not modifying a theme that works perfectly on Konqueror and Firefox because MS IE is broken. Similarly, we cannot ignore that crawlers from major search engine companies are broken or confused, and keep recursing through site using Drupal causing countless errors in the logs. We cannot tell our users to ask Google and Yahoo et al to fix their software. Remember that we are not breaking any standards by implementing this patch. All we are doing is putting the entire path out (from the first / down) and thus eliminating ambiguity for everyone. Sorry if I am a bit blunt in this post, but I am tired of what may be seen as isolationist thinking. I do not mind if this is implemented in an advanced mode or via a settings.php thing. All I care about is getting it fixed somehow. ------------------------------------------------------------------------ April 29, 2005 - 18:29 : kbahey Circular log errors reported here too http://drupal.org/node/9499 ------------------------------------------------------------------------ April 30, 2005 - 14:35 : shane I agree with KBAHEY. Burrying our head in the sand and saying "it ain't our problem" is not going to fix the issue. I despise companies that break standards - and I applaud Drupal for working hard to keep within those confines. But the reality is money grubbing, lazy ass programmers exist the world over, and the consequence is things like MSIE breaking everything wantonly and intentionally, Google, Yahoo, et al implementing poor bot code, etc... I believe this desperately needs to get fixed. Ever since I started hand writing HTML code in 1992 I have always insured that my URL paths are absolute to the base html document root (eg, preceeded with "/" and the full path). It avoids confusion, problems, or issues. It seems odd that the debate over this would rage as it has in this thread. ...and I don't get the "bloat" discussion. How is this bloating things? Are we talking a few dozen extra characters? I hope I'm missing something more obvious and insidious than that!? I've been a loyal Drupaler for ages now, and I love it. But this new problem is causing me a lot of grief, I see frequent munging of the URLs, and it worries me; particularly when I see that there are end users getting 404s. They don't give a rats ba-tu-tey that Drupal is "standards compliant" ... they just know they got an error when they supposedely did exactly what they should have, click on a URL. That reflects poorly on the site owner and ultimately on the software itself. Please reconsider this issue, and let a patch go into core to fix it. It doesn't make sense to let it rage on as an issue that is causing lots of people obvious grief. I'm betting it's a bigger issue than most admins think - most don't spend the anal-retentitive time that I and others do grubbing through our logs, trying to insure a "perfect" surfing experience for our end-users... ------------------------------------------------------------------------ May 1, 2005 - 17:09 : clydefrog This is truly not a problem with Drupal, but it may be reasonable to change Drupal's behavior anyway. The base href tag has been in the W3C standards since /1997/ [5]. Failing to observe this tag isn't about being slow on the uptake (as with MSIE and CSS2). It's about deliberately breaking existing compatibility. Has anyone contacted Yahoo, MSN, etc. and told them of this problem? If and when they fix their crawlers, we need to be able to turn off this kludge to discourage other more marginal crawlers to observe the standards. [5] http://www.w3.org/TR/REC-html32#base ------------------------------------------------------------------------ May 1, 2005 - 17:11 : clydefrog That should be "encourage other more marginal crawlers to observe the standards." ------------------------------------------------------------------------ May 6, 2005 - 14:00 : kbahey Here are examples from drupal.org itself: As you can see, if the paths started with a slash, none of this would have happened. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/style.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/print.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/misc/drupal.css not found. warning page not found 06/05/2005 - 10:33 about/tracker not found. warning page not found 06/05/2005 - 10:33 about/support not found. warning page not found 06/05/2005 - 10:33 about/project not found. warning page not found 06/05/2005 - 10:33 about/services not found. warning page not found 06/05/2005 - 10:33 about/handbook not found. warning page not found 06/05/2005 - 10:33 about/features not found. warning page not found 06/05/2005 - 10:33 about/forum not found. warning page not found 06/05/2005 - 10:33 about/drupal-sites not found. warning page not found 06/05/2005 - 10:33 about/druplicon not found. warning page not found 06/05/2005 - 10:33 about/download not found. warning page not found 06/05/2005 - 10:33 about/donate not found. warning page not found 06/05/2005 - 10:33 about/documentation-writers-guide not found. warning page not found 06/05/2005 - 10:33 about/contributors-guide not found. warning page not found 06/05/2005 - 10:33 about/cvs not found. warning page not found 06/05/2005 - 10:33 about/contact not found. warning page not found 06/05/2005 - 10:33 about/contribute not found. warning page not found 06/05/2005 - 10:33 about/aggregator not found. warning page not found 06/05/2005 - 10:33 about/cases not found. warning page not found 06/05/2005 - 10:33 about/about not found. ------------------------------------------------------------------------ May 6, 2005 - 14:14 : grohk Just because some of us disagree with this solution to the perceived problem does not mean we are not fond of reality, it just mean we have a different way of seeing this issue. If we cannot use accepted standards in Drupal, then what are good is it to adhere to them in the first place? Does this patch really affect the experience of end users of Drupal? Unless I am missing something, normal people never see these errors. Google is a search engine, it is not a user. In my experience, users remain unaware of this "problem". But changing Drupal to adhere to preferences of a broken crawler is not going to encourage anyone to fix their poorly implemented software either. As someone who appreciates the elegance of Drupal and uses it just as much as anyone, all this is fine with me -- as long as it is optional. But I don't think appeasement is the answer to "fixing" this problem, because with this option enabled there is no impetus for the crawler programmers to fix anything. And for the record, Google has been caching my pages correctly with CSS for months now and it has not entered into a loop either.

1 0

[drupal-devel] [bug] Problems with using relative path names
by grohk 06 May '05

06 May '05

Issue status update for http://drupal.org/node/13148 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: grohk Status: patch Just because some of us disagree with this solution to the perceived problem does not mean we are not fond of reality, it just mean we have a different way of seeing this issue. If we cannot use accepted standards in Drupal, then what are good is it to adhere to them in the first place? Does this patch really affect the experience of end users of Drupal? Unless I am missing something, normal people never see these errors. Google is a search engine, it is not a user. In my experience, users remain unaware of this "problem". But changing Drupal to adhere to preferences of a broken crawler is not going to encourage anyone to fix their poorly implemented software either. As someone who appreciates the elegance of Drupal and uses it just as much as anyone, all this is fine with me -- as long as it is optional. But I don't think appeasement is the answer to "fixing" this problem, because with this option enabled there is no impetus for the crawler programmers to fix anything. And for the record, Google has been caching my pages correctly with CSS for months now and it has not entered into a loop either. grohk Previous comments: ------------------------------------------------------------------------ November 18, 2004 - 23:29 : kbahey Looking at my site's logs, there seem to be several problems that are caused by Drupal's use of relative path names. If Drupal causes all the site's urls to be absolute, then none of this would be an issue. A. Search Engine Crawlers Getting lots of 404s on things like: linux/index.html/robots.txt Where 'linux' is an alias to a taxonomy, and 'index.html' is an alias to a node within that taxonomy. Another example, is recursing unnecessarily. I see 404s on things like: /linux/index.html/linux/index.html Where 'linux' is a path alias for a taxonomy term, and 'index.html' is an alias to the main node within it. This does not seem to happen when Google crawls my sites, but Yahoo's Slurp suffers from this problem, and keeps recursing. MSNBot also suffers from this. Another crawler/harvester called Blinkx/DFS-Fetch keeps adding the .css file to the relative path, getting a 404 on things like: /linux/themes/xtemplate/pushbutton/logo.gif And Fast Search Engine also attempts to access: /linux/contact/tracker/tracker/user/password The same goes for grub.org, another crawler. B. Google Cache / Archive Way Back Machine Pages in Google cache and archive.org Way Back Machine suffer form a similar problem: the .css files cannot be found, and hence rendering of the pages is not correct. Examples: Compare this: http://www.drupal.org/node/4647 To this: http://www.google.ca/search?q=cache:www.drupal.org/node/view/4647 Notice the following: How there is no formatting at all, because of the lack of a .css file The httpd log on Drupal will show errors for: linux/themes/pushbutton/style.css and linux/misc/drupal.css Also see: http://web.archive.org/web/20031016184902/http://www.drupal.org/ C. Proxy Caches: When someone is browsing my site from behind a proxy cache, the web site is hit with a rapid succession of requests, and many of it is just for bogus pages. Examples: 2004/11/17 - 17:47 404 error: linux/user/1 not found. 2004/11/17 - 17:47 404 error: linux/feedback not found. 2004/11/17 - 17:47 404 error: linux/tracker not found. 2004/11/17 - 17:47 404 error: linux/sitemap not found. 2004/11/17 - 17:47 404 error: linux/search not found. 2004/11/17 - 17:47 404 error: linux/misc not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/linux not found. 2004/11/17 - 17:47 404 error: linux/technology not found. 2004/11/17 - 17:47 404 error: linux/writings not found. 2004/11/17 - 17:47 404 error: linux/family not found. And also: 2004/11/17 - 07:23 404 error: history/user/1 not found. 2004/11/17 - 07:23 404 error: history/tracker not found. 2004/11/17 - 07:23 404 error: history/feedback not found. 2004/11/17 - 07:23 404 error: history/sitemap not found. 2004/11/17 - 07:23 404 error: history/search not found. 2004/11/17 - 07:23 404 error: history/misc not found. 2004/11/17 - 07:23 404 error: history/technology not found. 2004/11/17 - 07:23 404 error: history/science not found. 2004/11/17 - 07:22 404 error: history/history not found. 2004/11/17 - 07:22 404 error: history/writings not found. 2004/11/17 - 07:22 404 error: history/family not found. As you can tell, history and linux are aliases to taxonomy terms, and so is misc, technology, writings, family, ...etc. The user agent is appending the taxonomy term alias to the url and forming a new URL. D. Regular Browsing: There is even at least one extreme case where the following URL was accessed (the result was 404 of course) /book/view/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/logo.gif It seems it was a normal user, because the user agent is: "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)" Proposed Solution: As a proposed solution, all URLs in Drupal can be made into absolute path names. This can be done by the following: The variable $base_url in the conf.php file is broken down into two components: $base_host (the 'http://whatever-host.example.com' part WITHOUT the trailing slash) $base_path (the '/path-to-drupal' part, WITH the leading slash. If this is the DocumentRoot, then it is just a '/' character) $base_url is now $base_host concatenated with $base_path A simple filter can be written to preceed every href="path" with the $base_path variable, so it becomes "/path" This option can be turned on and off for a site. The default is to have it off so current behavior is maintained. A similar scheme applies for style sheets as well. So, did I miss something obvious? Am I seriously off the mark? Your thoughts! ------------------------------------------------------------------------ November 20, 2004 - 00:10 : chrisada I am getting similar 404 errors, mainly from rss feed link that looks like /blog/blog/feed and many manual links that are relative to drupal root. It was not a problem before Drupal 4.5, so I think there might not be a need to change all URIs to absolute. I can't see where the problem is coming from though. ------------------------------------------------------------------------ November 20, 2004 - 00:35 : kbahey I am pretty sure that these problems were happening for at least the past 10 months (ever since I moved to Drupal in January 2004). The main issue here is that crawlers and other user agents get confused by the relative path names. Using absolute paths will definitely solve this. However, is this the only solution? I am looking for a discussion of this. ------------------------------------------------------------------------ November 20, 2004 - 05:55 : Goba No absolute paths please. Having the path start with '/' solves all the mentioned problems, and is not absolute, it is relative to the domain. Sadly some crawlers and even the Google Cache does not obey to the base href. I have reported this cache problem in April to Google, and they promised they will keep it in mind... Hehe... What we need is to have the printed relative path values relative to the domain name, and not relative to the Drupal installation path. Note that this issue will appear on the drupal devel mailing list if someone finally provides a patch we can talk about :) ------------------------------------------------------------------------ November 20, 2004 - 06:19 : Dries Goba is right. We need paths relative to the domain name to fix this 'problem'. ------------------------------------------------------------------------ November 20, 2004 - 16:19 : kbahey Sorry for not making my self clear. When I said absolute, I meant that they start with just a /. I did NOT mean that they start with http://host.example.com. That would be a very bad idea. In any case, what do people think about the proposed solution (breaking down $base_url into two parts?) Also, does this address the style sheets as well, or more is needed? ------------------------------------------------------------------------ November 21, 2004 - 12:24 : chx Attachment: http://drupal.org/files/issues/common_inc_patch.txt (471 bytes) I have implemented what Goba suggested. ------------------------------------------------------------------------ November 21, 2004 - 12:43 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_0.txt (825 bytes) Maybe this one is faster? ------------------------------------------------------------------------ November 21, 2004 - 13:34 : kbahey Man! You are fast! I tried the second version. It works fine for things that are not inside the node body, I mean they have a / in front of them, as we want it to be. Two comments/issues: - If there is a URL that is already "/" representing the home page, it gets set to "//". Perhaps it should check for that case? - URLs in nodes that do not start with / do not get changed to have a / prepended to them. Do we need a filter for this? - Do we need to do something for the style sheets in the page header? I mean the "misc/drupal.css" and "themes/themename/style.css"? Thanks ------------------------------------------------------------------------ November 21, 2004 - 20:28 : kbahey Hi chx Here is a fix for the case where you have a url that is just "/". In your patch, instead of: <?php $base = $parts['path'] . '/' ; ?> Replace that by: <?php $base = ( $path == '/' ? $base : $parts['path'] . '/' ); ?> ------------------------------------------------------------------------ November 28, 2004 - 00:08 : kbahey Did this patch make it into CVS yet? If there are any objections to it, can someone please explain what they are? Thanks ------------------------------------------------------------------------ November 28, 2004 - 05:33 : Dries Shouldn't your changes be included in the patch? Also, it's better to cache $base rather than $parts. Lastly, it this patch makes it to HEAD, we should probably remove some 'base url' cruft from the themes. ------------------------------------------------------------------------ November 28, 2004 - 14:54 : kbahey Attachment: http://drupal.org/files/issues/x.diff (1 KB) Here is the patch including my fix. I am asking chx to comment on caching $base instead of $parts. Will this make it faster? ------------------------------------------------------------------------ November 28, 2004 - 15:26 : chx Hm. $base = ( $path == '/' ? $base : $parts['path'] . '/' ); this depends on path which is a parameter. Thus I fail to see how could we cache $base. I'd correct this code however $base = ( $path == '/' ? '' : $parts['path'] . '/' ); 'cos I think $base is not defined before, but this is not a problem, PHP will be happy to replace NULL with NULL... Maybe instead of all parts, only $parts['path'] is enough to be cached, yes, but the performance and memory usage difference -- I guess -- would not be noticable... ------------------------------------------------------------------------ November 28, 2004 - 19:06 : kbahey Attachment: http://drupal.org/files/issues/common-inc-patch.txt (1 KB) OK. I put in chx suggested change. This patch can go in CVS then, to rid us of the problems with paths not beginning with slash. This is not an ultimate solution still. We need to address the problem with .css files. Although the header contains a: <base href="http://example.com" /> it does not seem that major search engines and archiving sites obey it anyway. ------------------------------------------------------------------------ December 2, 2004 - 16:31 : Dries Your coding style needs work. Also, I'm not going to commit this unless the themes get fixed up: we'd end up with invalid URLs all over the place. Lastly, I wonder how portable the themes will be when Drupal is run from within a subdirectory. ------------------------------------------------------------------------ December 2, 2004 - 17:15 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_1.txt (849 bytes) Well, my patch worked from a subdirectory very well, as fact, I have not tested it from the root dir. And I think that it adheres to coding standards. So I resubmit it with the root path fix. However, my Drupal work is focused on i18n these days, and I was never into themeing so it won't be me who fixes those. ------------------------------------------------------------------------ December 2, 2004 - 18:07 : kbahey I have tested the previous patch (including my fix) with drupal installed in the DocumentRoot of the server. So, in effect, it is tested with both Drupal in / and Drupal in a subdirectory. This change fixes the problem for the crawlers and other browsers from getting confused. While it is true that there is no fix for the .css files in the HTML head section yet, this fix deals with a major part of the problem, and rids us of a major pain. Check your web server's logs some time to see what I mean. Someone who is familiar with the themes can contribute a patch later. This patch and the future fix for themes are not mutually exclusive, so let it go in CVS. ------------------------------------------------------------------------ December 9, 2004 - 11:31 : Goba Please commit this into Drupal core, this fix is badly needed. ------------------------------------------------------------------------ January 17, 2005 - 09:00 : chx Attachment: http://drupal.org/files/issues/base_url_kill.patch (4.34 KB) Well as noone have stepped in to fix this problem, I have tried to fix the themes also. themes.inc , xtemplate.engine and the bluemarine template is patched besides common.inc. Of course, more templates could follow, but first I'd like to see your opinions. ------------------------------------------------------------------------ January 17, 2005 - 09:09 : Goba I don't think that removing <base> from the themes is a good idea, using $parts['path'] should be encouraged though before the files, which would fix the google cache problem, and would still keep the HTML size low. It would also help those, who save the file to find the originating site easier, since clicking on a non-pagelocal link would lead to the online version. ------------------------------------------------------------------------ January 17, 2005 - 12:03 : Steven Definitely -1 on removing the <base&gt tag or using absolute or root-relative URLs. This tag has been around for ages, and it is the only way to make clean URLs work without bloating in the code. FYI, "base" is (first?) mentioned in Berners-Lee's HTML 1.0 draft [1]. That's June 1993. As the amount of clean URL-using sites grows, the crawlers will have to be updated. Perhaps we could prevent crawlers from going too insane by 404ing for URLs with more than say 10 components? That would prevent the really crappy ones from hammering your site. I'm all for making the <base> tag easier to handle for the user (say, by including a filter to allow simple anchor links to work as most people expect them to), but we should keep Drupal-generated URLs clean and completely relative. [1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt ------------------------------------------------------------------------ January 17, 2005 - 12:57 : kbahey The problem with css is this: The @import argument does not start with a /. This is simple to fix. We keep the "base" as it is today, but add the new variable: $base before it. So for a site where Drupal is installed in the DocumentRoot, all that will change is that /misc/drupal.css and /themes/themename/style.css will be preceded by a slash. For sites that use another path, that path will be prepended to the css file name. How about that? ------------------------------------------------------------------------ January 17, 2005 - 13:38 : Steven What exactly is the problem with the @import? As far as I know: - url() in stylesheets is interpreted relative to the base of the stylesheet, not the source document. - However, if the styles are inside an HTML document, through a style tag or style attribute, then the stylesheet's location is the same as the HTML document. - Thus, the stylesheet's base is the same as the base of the HTML document (which can be altered through the <base> tag). I just don't see why it is necessary. As far as I know, the only browser that has had problems resolving CSS urls properly was Netscape 4, which does not support @import at all, and which Drupal does not support either, because of its CSS usage. ------------------------------------------------------------------------ January 17, 2005 - 14:35 : kbahey The problem for stylesheets is as follows. I think it mainly affect crawlers and Google's cache. Say you have an installtion of Drupal in DocumentRoot. You then use url aliases, and put slashes in them. For example, you use news/general/2004-12-15.html for a node. That node still has misc/drupal.css and themes/pushbutton/style.css in the head section if the document. Crawlers get fooled by that and try to look for /news/general/misc/drupal.css and /news/general/themes/pushbutton/style.css, which don't exist. So, just prepending the new $base variable (in chx's patch) before the stylesheet @import argument would fix this issue. Assuming you are in DocumentRoot, then /misc and /themes would be used instead of just misc and themes. It would still be compliant with standards, be relative to the web site, and no ambiguous to anyone, be they crawler or browser. I hope it is clearer now. I think chx can change the patch to use the $base instead of $base_url everywhere, so as to avoid the host/domain name in the urls. ------------------------------------------------------------------------ January 17, 2005 - 17:36 : Steven But typical crawlers don't even pay attention to stylesheets, hence it wouldn't have much use for them. I just don't see why we should adjust to rare cases of buggy software. Reading out a base URL from an HTML document is dead easy, and on top of that it doesn't add more complexity as without the base tag, the document's URL is already an implicit base which has to be parsed anyway. I did not like it when we altered the <link&gt tag to accomodate buggy RSS readers and I certainly don't like it now, as this is even rarer. In both cases, it is not Drupal which is at fault. ------------------------------------------------------------------------ January 17, 2005 - 17:48 : kbahey Steven While I agree with most of what you said, the 404s show up in the logs enough to be a bother. Perhaps the original design of Drupal did not forsee that people will use url aliases to mimic directory/file hierarchies. Whether this was intended or not, it is the way many use Drupal today. It does not matter where the bug is (Drupal or the external world), as long as we can stop it ourselves, by adjusting our end of it. The fix is simple enough and does not break standards (if implemented as described with a leading / before the css). ------------------------------------------------------------------------ January 17, 2005 - 17:54 : Steven It does not break standards, but it does bloat the code in an ugly way. Why not send an e-mail to the owners of the crawlers and tell them to implement a standard that is nearly 10 years old [2] (RFC 1808)? Note that Google Cache now seems to correctly interpret base URLs [3] and even adds a <base> tag of its own. By the way, this problem has nothing to do with people using URL aliases or not, as for a browser the regular nested paths that Drupal uses (e.g. "node/1" is no different from aliases mimicking files "foo/bar.html"). [2] http://www.faqs.org/rfcs/rfc1808.html [3] http://www.google.be/search?q=cache%3Awww.drupal.org&sourceid=mozilla-searc… ------------------------------------------------------------------------ January 17, 2005 - 18:34 : Goba Steven, part of the problem is that Google cache does add a base href even if there is a base href in the document. Eg adds a <BASE HREF="http://drupal.org/node/13733"> on the plone comparision page cached. Now that since HTML does not allow more than one base tag [4] to be present, it is up to the browsers, to use the first or the last base value, or any of the base values on the page for that matter as the used base. So even pages displayed from the google cache will be buggy if a full relative path to the domain root is not specified, due to this problem. [4] http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#head.content ------------------------------------------------------------------------ January 18, 2005 - 03:14 : chx Attachment: http://drupal.org/files/issues/base_url_kill_0.patch (4.75 KB) This one does not use the whole base_url only the path part of it. HTML bloat is kept at minimal. ------------------------------------------------------------------------ February 1, 2005 - 19:33 : clairem Please please can this be done? It's a good idea in itself, but if using fully-qualified paths means we can get rid of the BASE HREF, then page anchors will work without having the overhead of a filter. That's be a huge bonus for those creating larger nodes, or who just want to be able to put a "skip navigation" link in their theme without having to abandon Xtemplate or PHPtemplate ------------------------------------------------------------------------ February 1, 2005 - 19:37 : Goba Well, speaking of skip navigation links, phptemplate and xtemplate should expose the REQUEST_URI to the templates, so when a link to an anchor on the same page is needed, the link can be formatted with the complete request URI in mind. ------------------------------------------------------------------------ February 2, 2005 - 19:40 : clairem "hptemplate and xtemplate should expose the REQUEST_URI to the templates " Should, but don't :( If BASE HREF isn't removed, surely it wouldn't be a big job to implement this tweak? ------------------------------------------------------------------------ February 17, 2005 - 10:50 : kbahey This patch is badly needed. The lack of a leading / in many paths is causing lots of problems. ------------------------------------------------------------------------ March 12, 2005 - 16:32 : kbahey Can this patch be applied for 4.6? it is really badly needed. ------------------------------------------------------------------------ March 22, 2005 - 16:50 : Dries I don't see why this is badly needed. We generate perfectly valid URLs which are supposed to be short and crispy. This patch has some advantages though, yet it is unclear which patch to go with. ------------------------------------------------------------------------ March 22, 2005 - 17:00 : chx The second patch is better. ------------------------------------------------------------------------ March 22, 2005 - 17:46 : grohk Forgive me for saying so, but since the way Drupal is generating hyperlinks is completely valid, why are you suggesting Drupal should move away from an accepted standard when the problem lies with the search engines? At the very least, this needs to be optional -- which it appears to be -- I hate the 404s too, but I hate to hear that a change in Drupal is needed to fix a Google problem. ------------------------------------------------------------------------ March 22, 2005 - 18:03 : jhriggs I have to agree with the last comment from grohk. ------------------------------------------------------------------------ March 22, 2005 - 18:39 : mathias I also agree with the two previous Drupaleers, but I wouldn't mind enabling a 'quirks mode' via my conf file to stop the flood of 404 messages. ------------------------------------------------------------------------ March 22, 2005 - 20:37 : kbahey I really can't fathom why some of us cannot deal with with the realities out there in the world. These problems are not because Drupal is broken. It is because crawlers are. We cannot just bury our collective heads in the sand and say that we are standards compliant and forget about what is out there. As an analogy, people who design themes or write CSS have to deal with the ugliness of Microsoft Internet Explorer and its intentional going against standards. You cannot tell a client or your boss that you are not modifying a theme that works perfectly on Konqueror and Firefox because MS IE is broken. Similarly, we cannot ignore that crawlers from major search engine companies are broken or confused, and keep recursing through site using Drupal causing countless errors in the logs. We cannot tell our users to ask Google and Yahoo et al to fix their software. Remember that we are not breaking any standards by implementing this patch. All we are doing is putting the entire path out (from the first / down) and thus eliminating ambiguity for everyone. Sorry if I am a bit blunt in this post, but I am tired of what may be seen as isolationist thinking. I do not mind if this is implemented in an advanced mode or via a settings.php thing. All I care about is getting it fixed somehow. ------------------------------------------------------------------------ April 29, 2005 - 19:29 : kbahey Circular log errors reported here too http://drupal.org/node/9499 ------------------------------------------------------------------------ April 30, 2005 - 15:35 : shane I agree with KBAHEY. Burrying our head in the sand and saying "it ain't our problem" is not going to fix the issue. I despise companies that break standards - and I applaud Drupal for working hard to keep within those confines. But the reality is money grubbing, lazy ass programmers exist the world over, and the consequence is things like MSIE breaking everything wantonly and intentionally, Google, Yahoo, et al implementing poor bot code, etc... I believe this desperately needs to get fixed. Ever since I started hand writing HTML code in 1992 I have always insured that my URL paths are absolute to the base html document root (eg, preceeded with "/" and the full path). It avoids confusion, problems, or issues. It seems odd that the debate over this would rage as it has in this thread. ...and I don't get the "bloat" discussion. How is this bloating things? Are we talking a few dozen extra characters? I hope I'm missing something more obvious and insidious than that!? I've been a loyal Drupaler for ages now, and I love it. But this new problem is causing me a lot of grief, I see frequent munging of the URLs, and it worries me; particularly when I see that there are end users getting 404s. They don't give a rats ba-tu-tey that Drupal is "standards compliant" ... they just know they got an error when they supposedely did exactly what they should have, click on a URL. That reflects poorly on the site owner and ultimately on the software itself. Please reconsider this issue, and let a patch go into core to fix it. It doesn't make sense to let it rage on as an issue that is causing lots of people obvious grief. I'm betting it's a bigger issue than most admins think - most don't spend the anal-retentitive time that I and others do grubbing through our logs, trying to insure a "perfect" surfing experience for our end-users... ------------------------------------------------------------------------ May 1, 2005 - 18:09 : clydefrog This is truly not a problem with Drupal, but it may be reasonable to change Drupal's behavior anyway. The base href tag has been in the W3C standards since /1997/ [5]. Failing to observe this tag isn't about being slow on the uptake (as with MSIE and CSS2). It's about deliberately breaking existing compatibility. Has anyone contacted Yahoo, MSN, etc. and told them of this problem? If and when they fix their crawlers, we need to be able to turn off this kludge to discourage other more marginal crawlers to observe the standards. [5] http://www.w3.org/TR/REC-html32#base ------------------------------------------------------------------------ May 1, 2005 - 18:11 : clydefrog That should be "encourage other more marginal crawlers to observe the standards." ------------------------------------------------------------------------ May 6, 2005 - 15:00 : kbahey Here are examples from drupal.org itself: As you can see, if the paths started with a slash, none of this would have happened. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/style.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/print.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/misc/drupal.css not found. warning page not found 06/05/2005 - 10:33 about/tracker not found. warning page not found 06/05/2005 - 10:33 about/support not found. warning page not found 06/05/2005 - 10:33 about/project not found. warning page not found 06/05/2005 - 10:33 about/services not found. warning page not found 06/05/2005 - 10:33 about/handbook not found. warning page not found 06/05/2005 - 10:33 about/features not found. warning page not found 06/05/2005 - 10:33 about/forum not found. warning page not found 06/05/2005 - 10:33 about/drupal-sites not found. warning page not found 06/05/2005 - 10:33 about/druplicon not found. warning page not found 06/05/2005 - 10:33 about/download not found. warning page not found 06/05/2005 - 10:33 about/donate not found. warning page not found 06/05/2005 - 10:33 about/documentation-writers-guide not found. warning page not found 06/05/2005 - 10:33 about/contributors-guide not found. warning page not found 06/05/2005 - 10:33 about/cvs not found. warning page not found 06/05/2005 - 10:33 about/contact not found. warning page not found 06/05/2005 - 10:33 about/contribute not found. warning page not found 06/05/2005 - 10:33 about/aggregator not found. warning page not found 06/05/2005 - 10:33 about/cases not found. warning page not found 06/05/2005 - 10:33 about/about not found.

1 0

[drupal-devel] [bug] Problems with using relative path names
by kbahey 06 May '05

06 May '05

Issue status update for http://drupal.org/node/13148 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: kbahey Status: patch Here are examples from drupal.org itself: As you can see, if the paths started with a slash, none of this would have happened. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/style.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/themes/bluebeach/print.css not found. warning page not found 06/05/2005 - 10:36 drupal-sites/misc/drupal.css not found. warning page not found 06/05/2005 - 10:33 about/tracker not found. warning page not found 06/05/2005 - 10:33 about/support not found. warning page not found 06/05/2005 - 10:33 about/project not found. warning page not found 06/05/2005 - 10:33 about/services not found. warning page not found 06/05/2005 - 10:33 about/handbook not found. warning page not found 06/05/2005 - 10:33 about/features not found. warning page not found 06/05/2005 - 10:33 about/forum not found. warning page not found 06/05/2005 - 10:33 about/drupal-sites not found. warning page not found 06/05/2005 - 10:33 about/druplicon not found. warning page not found 06/05/2005 - 10:33 about/download not found. warning page not found 06/05/2005 - 10:33 about/donate not found. warning page not found 06/05/2005 - 10:33 about/documentation-writers-guide not found. warning page not found 06/05/2005 - 10:33 about/contributors-guide not found. warning page not found 06/05/2005 - 10:33 about/cvs not found. warning page not found 06/05/2005 - 10:33 about/contact not found. warning page not found 06/05/2005 - 10:33 about/contribute not found. warning page not found 06/05/2005 - 10:33 about/aggregator not found. warning page not found 06/05/2005 - 10:33 about/cases not found. warning page not found 06/05/2005 - 10:33 about/about not found. kbahey Previous comments: ------------------------------------------------------------------------ November 18, 2004 - 22:29 : kbahey Looking at my site's logs, there seem to be several problems that are caused by Drupal's use of relative path names. If Drupal causes all the site's urls to be absolute, then none of this would be an issue. A. Search Engine Crawlers Getting lots of 404s on things like: linux/index.html/robots.txt Where 'linux' is an alias to a taxonomy, and 'index.html' is an alias to a node within that taxonomy. Another example, is recursing unnecessarily. I see 404s on things like: /linux/index.html/linux/index.html Where 'linux' is a path alias for a taxonomy term, and 'index.html' is an alias to the main node within it. This does not seem to happen when Google crawls my sites, but Yahoo's Slurp suffers from this problem, and keeps recursing. MSNBot also suffers from this. Another crawler/harvester called Blinkx/DFS-Fetch keeps adding the .css file to the relative path, getting a 404 on things like: /linux/themes/xtemplate/pushbutton/logo.gif And Fast Search Engine also attempts to access: /linux/contact/tracker/tracker/user/password The same goes for grub.org, another crawler. B. Google Cache / Archive Way Back Machine Pages in Google cache and archive.org Way Back Machine suffer form a similar problem: the .css files cannot be found, and hence rendering of the pages is not correct. Examples: Compare this: http://www.drupal.org/node/4647 To this: http://www.google.ca/search?q=cache:www.drupal.org/node/view/4647 Notice the following: How there is no formatting at all, because of the lack of a .css file The httpd log on Drupal will show errors for: linux/themes/pushbutton/style.css and linux/misc/drupal.css Also see: http://web.archive.org/web/20031016184902/http://www.drupal.org/ C. Proxy Caches: When someone is browsing my site from behind a proxy cache, the web site is hit with a rapid succession of requests, and many of it is just for bogus pages. Examples: 2004/11/17 - 17:47 404 error: linux/user/1 not found. 2004/11/17 - 17:47 404 error: linux/feedback not found. 2004/11/17 - 17:47 404 error: linux/tracker not found. 2004/11/17 - 17:47 404 error: linux/sitemap not found. 2004/11/17 - 17:47 404 error: linux/search not found. 2004/11/17 - 17:47 404 error: linux/misc not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/programming not found. 2004/11/17 - 17:47 404 error: linux/linux not found. 2004/11/17 - 17:47 404 error: linux/technology not found. 2004/11/17 - 17:47 404 error: linux/writings not found. 2004/11/17 - 17:47 404 error: linux/family not found. And also: 2004/11/17 - 07:23 404 error: history/user/1 not found. 2004/11/17 - 07:23 404 error: history/tracker not found. 2004/11/17 - 07:23 404 error: history/feedback not found. 2004/11/17 - 07:23 404 error: history/sitemap not found. 2004/11/17 - 07:23 404 error: history/search not found. 2004/11/17 - 07:23 404 error: history/misc not found. 2004/11/17 - 07:23 404 error: history/technology not found. 2004/11/17 - 07:23 404 error: history/science not found. 2004/11/17 - 07:22 404 error: history/history not found. 2004/11/17 - 07:22 404 error: history/writings not found. 2004/11/17 - 07:22 404 error: history/family not found. As you can tell, history and linux are aliases to taxonomy terms, and so is misc, technology, writings, family, ...etc. The user agent is appending the taxonomy term alias to the url and forming a new URL. D. Regular Browsing: There is even at least one extreme case where the following URL was accessed (the result was 404 of course) /book/view/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/logo.gif It seems it was a normal user, because the user agent is: "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)" Proposed Solution: As a proposed solution, all URLs in Drupal can be made into absolute path names. This can be done by the following: The variable $base_url in the conf.php file is broken down into two components: $base_host (the 'http://whatever-host.example.com' part WITHOUT the trailing slash) $base_path (the '/path-to-drupal' part, WITH the leading slash. If this is the DocumentRoot, then it is just a '/' character) $base_url is now $base_host concatenated with $base_path A simple filter can be written to preceed every href="path" with the $base_path variable, so it becomes "/path" This option can be turned on and off for a site. The default is to have it off so current behavior is maintained. A similar scheme applies for style sheets as well. So, did I miss something obvious? Am I seriously off the mark? Your thoughts! ------------------------------------------------------------------------ November 19, 2004 - 23:10 : chrisada I am getting similar 404 errors, mainly from rss feed link that looks like /blog/blog/feed and many manual links that are relative to drupal root. It was not a problem before Drupal 4.5, so I think there might not be a need to change all URIs to absolute. I can't see where the problem is coming from though. ------------------------------------------------------------------------ November 19, 2004 - 23:35 : kbahey I am pretty sure that these problems were happening for at least the past 10 months (ever since I moved to Drupal in January 2004). The main issue here is that crawlers and other user agents get confused by the relative path names. Using absolute paths will definitely solve this. However, is this the only solution? I am looking for a discussion of this. ------------------------------------------------------------------------ November 20, 2004 - 04:55 : Goba No absolute paths please. Having the path start with '/' solves all the mentioned problems, and is not absolute, it is relative to the domain. Sadly some crawlers and even the Google Cache does not obey to the base href. I have reported this cache problem in April to Google, and they promised they will keep it in mind... Hehe... What we need is to have the printed relative path values relative to the domain name, and not relative to the Drupal installation path. Note that this issue will appear on the drupal devel mailing list if someone finally provides a patch we can talk about :) ------------------------------------------------------------------------ November 20, 2004 - 05:19 : Dries Goba is right. We need paths relative to the domain name to fix this 'problem'. ------------------------------------------------------------------------ November 20, 2004 - 15:19 : kbahey Sorry for not making my self clear. When I said absolute, I meant that they start with just a /. I did NOT mean that they start with http://host.example.com. That would be a very bad idea. In any case, what do people think about the proposed solution (breaking down $base_url into two parts?) Also, does this address the style sheets as well, or more is needed? ------------------------------------------------------------------------ November 21, 2004 - 11:24 : chx Attachment: http://drupal.org/files/issues/common_inc_patch.txt (471 bytes) I have implemented what Goba suggested. ------------------------------------------------------------------------ November 21, 2004 - 11:43 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_0.txt (825 bytes) Maybe this one is faster? ------------------------------------------------------------------------ November 21, 2004 - 12:34 : kbahey Man! You are fast! I tried the second version. It works fine for things that are not inside the node body, I mean they have a / in front of them, as we want it to be. Two comments/issues: - If there is a URL that is already "/" representing the home page, it gets set to "//". Perhaps it should check for that case? - URLs in nodes that do not start with / do not get changed to have a / prepended to them. Do we need a filter for this? - Do we need to do something for the style sheets in the page header? I mean the "misc/drupal.css" and "themes/themename/style.css"? Thanks ------------------------------------------------------------------------ November 21, 2004 - 19:28 : kbahey Hi chx Here is a fix for the case where you have a url that is just "/". In your patch, instead of: <?php $base = $parts['path'] . '/' ; ?> Replace that by: <?php $base = ( $path == '/' ? $base : $parts['path'] . '/' ); ?> ------------------------------------------------------------------------ November 27, 2004 - 23:08 : kbahey Did this patch make it into CVS yet? If there are any objections to it, can someone please explain what they are? Thanks ------------------------------------------------------------------------ November 28, 2004 - 04:33 : Dries Shouldn't your changes be included in the patch? Also, it's better to cache $base rather than $parts. Lastly, it this patch makes it to HEAD, we should probably remove some 'base url' cruft from the themes. ------------------------------------------------------------------------ November 28, 2004 - 13:54 : kbahey Attachment: http://drupal.org/files/issues/x.diff (1 KB) Here is the patch including my fix. I am asking chx to comment on caching $base instead of $parts. Will this make it faster? ------------------------------------------------------------------------ November 28, 2004 - 14:26 : chx Hm. $base = ( $path == '/' ? $base : $parts['path'] . '/' ); this depends on path which is a parameter. Thus I fail to see how could we cache $base. I'd correct this code however $base = ( $path == '/' ? '' : $parts['path'] . '/' ); 'cos I think $base is not defined before, but this is not a problem, PHP will be happy to replace NULL with NULL... Maybe instead of all parts, only $parts['path'] is enough to be cached, yes, but the performance and memory usage difference -- I guess -- would not be noticable... ------------------------------------------------------------------------ November 28, 2004 - 18:06 : kbahey Attachment: http://drupal.org/files/issues/common-inc-patch.txt (1 KB) OK. I put in chx suggested change. This patch can go in CVS then, to rid us of the problems with paths not beginning with slash. This is not an ultimate solution still. We need to address the problem with .css files. Although the header contains a: <base href="http://example.com" /> it does not seem that major search engines and archiving sites obey it anyway. ------------------------------------------------------------------------ December 2, 2004 - 15:31 : Dries Your coding style needs work. Also, I'm not going to commit this unless the themes get fixed up: we'd end up with invalid URLs all over the place. Lastly, I wonder how portable the themes will be when Drupal is run from within a subdirectory. ------------------------------------------------------------------------ December 2, 2004 - 16:15 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_1.txt (849 bytes) Well, my patch worked from a subdirectory very well, as fact, I have not tested it from the root dir. And I think that it adheres to coding standards. So I resubmit it with the root path fix. However, my Drupal work is focused on i18n these days, and I was never into themeing so it won't be me who fixes those. ------------------------------------------------------------------------ December 2, 2004 - 17:07 : kbahey I have tested the previous patch (including my fix) with drupal installed in the DocumentRoot of the server. So, in effect, it is tested with both Drupal in / and Drupal in a subdirectory. This change fixes the problem for the crawlers and other browsers from getting confused. While it is true that there is no fix for the .css files in the HTML head section yet, this fix deals with a major part of the problem, and rids us of a major pain. Check your web server's logs some time to see what I mean. Someone who is familiar with the themes can contribute a patch later. This patch and the future fix for themes are not mutually exclusive, so let it go in CVS. ------------------------------------------------------------------------ December 9, 2004 - 10:31 : Goba Please commit this into Drupal core, this fix is badly needed. ------------------------------------------------------------------------ January 17, 2005 - 08:00 : chx Attachment: http://drupal.org/files/issues/base_url_kill.patch (4.34 KB) Well as noone have stepped in to fix this problem, I have tried to fix the themes also. themes.inc , xtemplate.engine and the bluemarine template is patched besides common.inc. Of course, more templates could follow, but first I'd like to see your opinions. ------------------------------------------------------------------------ January 17, 2005 - 08:09 : Goba I don't think that removing <base> from the themes is a good idea, using $parts['path'] should be encouraged though before the files, which would fix the google cache problem, and would still keep the HTML size low. It would also help those, who save the file to find the originating site easier, since clicking on a non-pagelocal link would lead to the online version. ------------------------------------------------------------------------ January 17, 2005 - 11:03 : Steven Definitely -1 on removing the <base&gt tag or using absolute or root-relative URLs. This tag has been around for ages, and it is the only way to make clean URLs work without bloating in the code. FYI, "base" is (first?) mentioned in Berners-Lee's HTML 1.0 draft [1]. That's June 1993. As the amount of clean URL-using sites grows, the crawlers will have to be updated. Perhaps we could prevent crawlers from going too insane by 404ing for URLs with more than say 10 components? That would prevent the really crappy ones from hammering your site. I'm all for making the <base> tag easier to handle for the user (say, by including a filter to allow simple anchor links to work as most people expect them to), but we should keep Drupal-generated URLs clean and completely relative. [1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt ------------------------------------------------------------------------ January 17, 2005 - 11:57 : kbahey The problem with css is this: The @import argument does not start with a /. This is simple to fix. We keep the "base" as it is today, but add the new variable: $base before it. So for a site where Drupal is installed in the DocumentRoot, all that will change is that /misc/drupal.css and /themes/themename/style.css will be preceded by a slash. For sites that use another path, that path will be prepended to the css file name. How about that? ------------------------------------------------------------------------ January 17, 2005 - 12:38 : Steven What exactly is the problem with the @import? As far as I know: - url() in stylesheets is interpreted relative to the base of the stylesheet, not the source document. - However, if the styles are inside an HTML document, through a style tag or style attribute, then the stylesheet's location is the same as the HTML document. - Thus, the stylesheet's base is the same as the base of the HTML document (which can be altered through the <base> tag). I just don't see why it is necessary. As far as I know, the only browser that has had problems resolving CSS urls properly was Netscape 4, which does not support @import at all, and which Drupal does not support either, because of its CSS usage. ------------------------------------------------------------------------ January 17, 2005 - 13:35 : kbahey The problem for stylesheets is as follows. I think it mainly affect crawlers and Google's cache. Say you have an installtion of Drupal in DocumentRoot. You then use url aliases, and put slashes in them. For example, you use news/general/2004-12-15.html for a node. That node still has misc/drupal.css and themes/pushbutton/style.css in the head section if the document. Crawlers get fooled by that and try to look for /news/general/misc/drupal.css and /news/general/themes/pushbutton/style.css, which don't exist. So, just prepending the new $base variable (in chx's patch) before the stylesheet @import argument would fix this issue. Assuming you are in DocumentRoot, then /misc and /themes would be used instead of just misc and themes. It would still be compliant with standards, be relative to the web site, and no ambiguous to anyone, be they crawler or browser. I hope it is clearer now. I think chx can change the patch to use the $base instead of $base_url everywhere, so as to avoid the host/domain name in the urls. ------------------------------------------------------------------------ January 17, 2005 - 16:36 : Steven But typical crawlers don't even pay attention to stylesheets, hence it wouldn't have much use for them. I just don't see why we should adjust to rare cases of buggy software. Reading out a base URL from an HTML document is dead easy, and on top of that it doesn't add more complexity as without the base tag, the document's URL is already an implicit base which has to be parsed anyway. I did not like it when we altered the <link&gt tag to accomodate buggy RSS readers and I certainly don't like it now, as this is even rarer. In both cases, it is not Drupal which is at fault. ------------------------------------------------------------------------ January 17, 2005 - 16:48 : kbahey Steven While I agree with most of what you said, the 404s show up in the logs enough to be a bother. Perhaps the original design of Drupal did not forsee that people will use url aliases to mimic directory/file hierarchies. Whether this was intended or not, it is the way many use Drupal today. It does not matter where the bug is (Drupal or the external world), as long as we can stop it ourselves, by adjusting our end of it. The fix is simple enough and does not break standards (if implemented as described with a leading / before the css). ------------------------------------------------------------------------ January 17, 2005 - 16:54 : Steven It does not break standards, but it does bloat the code in an ugly way. Why not send an e-mail to the owners of the crawlers and tell them to implement a standard that is nearly 10 years old [2] (RFC 1808)? Note that Google Cache now seems to correctly interpret base URLs [3] and even adds a <base> tag of its own. By the way, this problem has nothing to do with people using URL aliases or not, as for a browser the regular nested paths that Drupal uses (e.g. "node/1" is no different from aliases mimicking files "foo/bar.html"). [2] http://www.faqs.org/rfcs/rfc1808.html [3] http://www.google.be/search?q=cache%3Awww.drupal.org&sourceid=mozilla-searc… ------------------------------------------------------------------------ January 17, 2005 - 17:34 : Goba Steven, part of the problem is that Google cache does add a base href even if there is a base href in the document. Eg adds a <BASE HREF="http://drupal.org/node/13733"> on the plone comparision page cached. Now that since HTML does not allow more than one base tag [4] to be present, it is up to the browsers, to use the first or the last base value, or any of the base values on the page for that matter as the used base. So even pages displayed from the google cache will be buggy if a full relative path to the domain root is not specified, due to this problem. [4] http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#head.content ------------------------------------------------------------------------ January 18, 2005 - 02:14 : chx Attachment: http://drupal.org/files/issues/base_url_kill_0.patch (4.75 KB) This one does not use the whole base_url only the path part of it. HTML bloat is kept at minimal. ------------------------------------------------------------------------ February 1, 2005 - 18:33 : clairem Please please can this be done? It's a good idea in itself, but if using fully-qualified paths means we can get rid of the BASE HREF, then page anchors will work without having the overhead of a filter. That's be a huge bonus for those creating larger nodes, or who just want to be able to put a "skip navigation" link in their theme without having to abandon Xtemplate or PHPtemplate ------------------------------------------------------------------------ February 1, 2005 - 18:37 : Goba Well, speaking of skip navigation links, phptemplate and xtemplate should expose the REQUEST_URI to the templates, so when a link to an anchor on the same page is needed, the link can be formatted with the complete request URI in mind. ------------------------------------------------------------------------ February 2, 2005 - 18:40 : clairem "hptemplate and xtemplate should expose the REQUEST_URI to the templates " Should, but don't :( If BASE HREF isn't removed, surely it wouldn't be a big job to implement this tweak? ------------------------------------------------------------------------ February 17, 2005 - 09:50 : kbahey This patch is badly needed. The lack of a leading / in many paths is causing lots of problems. ------------------------------------------------------------------------ March 12, 2005 - 15:32 : kbahey Can this patch be applied for 4.6? it is really badly needed. ------------------------------------------------------------------------ March 22, 2005 - 15:50 : Dries I don't see why this is badly needed. We generate perfectly valid URLs which are supposed to be short and crispy. This patch has some advantages though, yet it is unclear which patch to go with. ------------------------------------------------------------------------ March 22, 2005 - 16:00 : chx The second patch is better. ------------------------------------------------------------------------ March 22, 2005 - 16:46 : grohk Forgive me for saying so, but since the way Drupal is generating hyperlinks is completely valid, why are you suggesting Drupal should move away from an accepted standard when the problem lies with the search engines? At the very least, this needs to be optional -- which it appears to be -- I hate the 404s too, but I hate to hear that a change in Drupal is needed to fix a Google problem. ------------------------------------------------------------------------ March 22, 2005 - 17:03 : jhriggs I have to agree with the last comment from grohk. ------------------------------------------------------------------------ March 22, 2005 - 17:39 : mathias I also agree with the two previous Drupaleers, but I wouldn't mind enabling a 'quirks mode' via my conf file to stop the flood of 404 messages. ------------------------------------------------------------------------ March 22, 2005 - 19:37 : kbahey I really can't fathom why some of us cannot deal with with the realities out there in the world. These problems are not because Drupal is broken. It is because crawlers are. We cannot just bury our collective heads in the sand and say that we are standards compliant and forget about what is out there. As an analogy, people who design themes or write CSS have to deal with the ugliness of Microsoft Internet Explorer and its intentional going against standards. You cannot tell a client or your boss that you are not modifying a theme that works perfectly on Konqueror and Firefox because MS IE is broken. Similarly, we cannot ignore that crawlers from major search engine companies are broken or confused, and keep recursing through site using Drupal causing countless errors in the logs. We cannot tell our users to ask Google and Yahoo et al to fix their software. Remember that we are not breaking any standards by implementing this patch. All we are doing is putting the entire path out (from the first / down) and thus eliminating ambiguity for everyone. Sorry if I am a bit blunt in this post, but I am tired of what may be seen as isolationist thinking. I do not mind if this is implemented in an advanced mode or via a settings.php thing. All I care about is getting it fixed somehow. ------------------------------------------------------------------------ April 29, 2005 - 18:29 : kbahey Circular log errors reported here too http://drupal.org/node/9499 ------------------------------------------------------------------------ April 30, 2005 - 14:35 : shane I agree with KBAHEY. Burrying our head in the sand and saying "it ain't our problem" is not going to fix the issue. I despise companies that break standards - and I applaud Drupal for working hard to keep within those confines. But the reality is money grubbing, lazy ass programmers exist the world over, and the consequence is things like MSIE breaking everything wantonly and intentionally, Google, Yahoo, et al implementing poor bot code, etc... I believe this desperately needs to get fixed. Ever since I started hand writing HTML code in 1992 I have always insured that my URL paths are absolute to the base html document root (eg, preceeded with "/" and the full path). It avoids confusion, problems, or issues. It seems odd that the debate over this would rage as it has in this thread. ...and I don't get the "bloat" discussion. How is this bloating things? Are we talking a few dozen extra characters? I hope I'm missing something more obvious and insidious than that!? I've been a loyal Drupaler for ages now, and I love it. But this new problem is causing me a lot of grief, I see frequent munging of the URLs, and it worries me; particularly when I see that there are end users getting 404s. They don't give a rats ba-tu-tey that Drupal is "standards compliant" ... they just know they got an error when they supposedely did exactly what they should have, click on a URL. That reflects poorly on the site owner and ultimately on the software itself. Please reconsider this issue, and let a patch go into core to fix it. It doesn't make sense to let it rage on as an issue that is causing lots of people obvious grief. I'm betting it's a bigger issue than most admins think - most don't spend the anal-retentitive time that I and others do grubbing through our logs, trying to insure a "perfect" surfing experience for our end-users... ------------------------------------------------------------------------ May 1, 2005 - 17:09 : clydefrog This is truly not a problem with Drupal, but it may be reasonable to change Drupal's behavior anyway. The base href tag has been in the W3C standards since /1997/ [5]. Failing to observe this tag isn't about being slow on the uptake (as with MSIE and CSS2). It's about deliberately breaking existing compatibility. Has anyone contacted Yahoo, MSN, etc. and told them of this problem? If and when they fix their crawlers, we need to be able to turn off this kludge to discourage other more marginal crawlers to observe the standards. [5] http://www.w3.org/TR/REC-html32#base ------------------------------------------------------------------------ May 1, 2005 - 17:11 : clydefrog That should be "encourage other more marginal crawlers to observe the standards."

1 0

[drupal-devel] [bug] Syntax error in Block help
by tostinni 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22192 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: tostinni Updated by: tostinni Status: patch Attachment: http://drupal.org/files/issues/block_help.patch (686 bytes) There's a misplaced tag in block_help. tostinni

1 0

Re: [drupal-devel] Community density
by Kobus Myburgh 06 May '05

06 May '05

Hi! Interesting statistics indeed, however, there are some things that you do not consider. Me, and many others, for example, moderate nodes often and fixes spelling mistakes and so on. Some of us, like me, have a whole translation of Drupal Core under our belts, but haven't a single node posted on the Drupal site. I am also involved with themes.drupal.org, and attend to forum questions whenever I get a chance. As far as I am concerned, I fall within that 300-user group, even though I have not a single node. We can not necessarily be "thrown away" or labeled as "inactive". Maybe there is another way to come to a more realistic conclusion? Kobus >>> karoly(a)negyesi.net 5/6/2005 12:57:11 PM >>> Hi! Last night I asked Steven to send me data about how many users have 1 node, 2 nodes and so on. Of the 22695 users, 18219 have zero nodes. This means that most of the users are just commenting or not contributing at all. If we want to size the "hard core" of the community, there are 66 users who have written 25% of all nodes, they have at least 39 nodes and 78 nodes in average. A bigger circle is the 302 user who have written 50% of the nodes. They have written at least 12 nodes, the average is 32 nodes. Given that the definition of "belongs to the community" is a very subjective one, I say we have a 300 user community which is real amazing. 22K, of course sounds better, but those are not active. Regards NK

3 2

[drupal-devel] [bug] race condition in variable_set in bootstrap.inc
by Dries 06 May '05

06 May '05

Issue status update for http://drupal.org/node/20114 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Ricetons Reported by: Ricetons Updated by: Dries Status: patch The proper fix is table/column locking. Dries Previous comments: ------------------------------------------------------------------------ April 7, 2005 - 05:53 : Ricetons This bug was exposed by the poormancron module. We can see that the module itself contains no bug. But in the function variable_get(), the function just execute SQL like this: DELETE bar WHERE key="foo" INSERT INTO bar VALUES(foo, bar2ooo) but suppose this: thread A and thread B has executed the DELETE sentence. And they do INSERT at the same time. then an SQL error like this occured: duplicated key 'foo' in table "variables" It's a critical bug. It should be fixed before the time that drupal 4.6.0 released. ------------------------------------------------------------------------ April 8, 2005 - 10:01 : robertDouglass I also experience this on a site that has many different cron cycles ranging from 2 minutes to 6 hours. The query errors which arise (as noted above) are impossible to reproduce through normal testing yet occur fairly (surprisingly) often in the logs. This doesn't just apply to cron jobs but rather to all code that calls variable_set. Setting to CVS since this hasn't been addressed since the issue was opened. ------------------------------------------------------------------------ April 8, 2005 - 15:10 : jhriggs Attachment: http://drupal.org/files/issues/variable_set_update.patch (922 bytes) I'm not sure that there is a "right" way to fix this. In mysql, we could use a REPLACE rather than DELETE/INSERT, but that wouldn't work for pgsql. And, if we are really seeing this type of race, there is no telling which REPLACE would actually make it last and be saved. Instead, we could do a check to see if the row exists and do an UPDATE if it does and an INSERT otherwise; however, this would be prone to the same problem if we are seeing such a race. That is, they may both see that the row does not exist and both attempt to do an INSERT. This will only happen the first time a variable is created, though, which may be more acceptable than what we are seeing now. If the row does already exist, they would both do UPDATES and would "succeed" in the sense that there is no duplicate key error. There is still no telling which one actually sticks, though. The attached patch takes the second approach. ------------------------------------------------------------------------ April 8, 2005 - 15:37 : Jeremy(a)kerneltrap.org What keeps another session from doing a DELETE after your session does its SELECT COUNT but before it does its UPDATE? Or, what keeps another session from doing an INSERT after your session does its SELECT COUNT but before it does its INSERT? All you've done is add another query... I think you'll need to use locking to fix this right. ------------------------------------------------------------------------ April 8, 2005 - 16:46 : jhriggs 1. Assuming that all we are talking about is variable_set() calls, DELETE is not an issue, because the patch removes deletes. It only does updates and inserts. Now if you throw in variable_del() calls, that's another story, but it's also outside the scope of this issue. It would likely be much more rare than the delete/insert problems we see now. 2. Your second example is the only lingering downfall. As I mentioned in my post: "...they may both see that the row does not exist and both attempt to do an INSERT. This will only happen the first time a variable is created, though, which may be more acceptable than what we are seeing now." 3. This doesn't add any queries. Right now it does DELETE and INSERT. With the patch it does SELECT and UPDATE/INSERT. Two queries either way. As I alluded, this may not be a true fix -- I don't think there is one for race conditions like this, even with table-locking -- but it addresses the problem in a way that makes sense and eliminates an error in the majority of cases. ------------------------------------------------------------------------ April 8, 2005 - 17:42 : killes(a)www.drop.org @Jeremy: db locking will become available with the revisios patch. I don't advise to use it too mch because it is very slow... I actually do not see why this needs a fix. All it is going to produce is a message in the error log... ------------------------------------------------------------------------ April 9, 2005 - 00:06 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/variable_set.patch (708 bytes) The attached patch makes more sense to me. The same method is used by cache_set() and statistics_exit(). Once a variable already exists in the variable table, we only need to do one db_query to update it... ------------------------------------------------------------------------ April 9, 2005 - 05:39 : Ricetons variable_set() is a function being used almost everywhere in drupal. INSERT/DELETE caused a serious performance problem. Maybe we should come to a soultion which uses a miminum number of queries. In my opinion, it seems that the third patch can solve the problem, but it's not good enough. By the way, table locking costs too much. I don't agree to use that method to solve this case. ------------------------------------------------------------------------ April 9, 2005 - 10:37 : Steven Jeremy: cache_set(), and thus this patch, suffer from an annoying bug: db_affected_rows() only returns which rows were changed, not which rows matched the WHERE clause. This means that if you set a variable to exactly the same value as it already is, that a db error will be generated. This is rarely the case with cache and only occurs in a race condition there, but with variables this problem is quite important. ------------------------------------------------------------------------ April 9, 2005 - 16:07 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/variable_set_0.patch (978 bytes) Okay, here's a fix for variable_set. It has the added advantage of not requiring any db_queries if we're trying to set the variable to a value it's already equal to. (Granted, without using locks there's always a tiny race window... But this will always be true.) Costs: - if the variable is not previously set: two db queries - if the variable is previously set, and changes: one db query - if the variable is previously set, and not changing: no db query ------------------------------------------------------------------------ April 9, 2005 - 17:12 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/variable_set_1.patch (1.04 KB) Just because it's possible, here's an alternative patch that never costs more than 1 db_query. Costs: - if the variable is not previously set: one db query - if the variable is previously set, and changes: one db query - if the variable is previously set, and not changing: no db queries

1 0

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

06 May '05

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

2 1

[drupal-devel] [bug] menu error line 974 with MBstring
by Dries 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22026 Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: hendler Updated by: Dries Status: patch I wonder how I can reproduce this problem. Maybe we are fixing the symptom, not the cause. Dries Previous comments: ------------------------------------------------------------------------ May 5, 2005 - 02:15 : hendler Menu.inc on line 974 the do {}while() causes an error if $parent is empty because strrpos, (I have mbstring enabled) may be null to fix my problem I have this if statement wrapping it, which I understand is logically equivlent to just doing a while loop. if ($parent){ do { $parent = substr($parent, 0, strrpos($parent, '/')); } while ($parent && !array_key_exists($parent, $_menu['path index'])); } This happens just after a new install. ------------------------------------------------------------------------ May 6, 2005 - 01:43 : Robin Monks Attachment: http://drupal.org/files/issues/menu.inc_0.patch (908 bytes) We apparently don't check if the object exists before we work on it. Robin

1 0

[drupal-devel] [bug] Strange markup in book render functions
by Dries 06 May '05

06 May '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: kika Updated by: Dries Status: patch Let's not abbreviate 'section' to 'sect'. Also, we use '-' to separate words in CSS names. - If the section ID uses the node ID, maybe we should use 'node-' instead of 'sect-'? - If the class uses depth, maybe we should use 'depth-' instead of 'sect'? The same is true for your other patch where you suggest to use 'n'. Better to make that 'node-'. (Feel free to merge both patches.) Looks like the book.module generates a _lot_ of CSS IDs/classes. If the introduction of these new IDs/classes allows us to remove some of the existing IDs/classes, please do. Dries Previous comments: ------------------------------------------------------------------------ June 10, 2003 - 00:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 11, 2003 - 02:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 11, 2003 - 08:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 16:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 5, 2005 - 09:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section. ------------------------------------------------------------------------ May 6, 2005 - 00:58 : puregin Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun

1 0