September 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by m3avrck 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: m3avrck Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/archive_0.patch (20.72 KB) Rerolled patch against head. Also created one patch that fixes both archive.module and drupal.css so it's a clean and simple process now :) m3avrck Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead. ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:14:30 +0000 : adrian What is the progress on this morbus ? ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:29:13 +0000 : Morbus Iff Adrian - I'll be attaching a new version either later today or tomorrow, with a CHANGELOG. I'll also be running a live version of it over on NHPR.org for people to play with. The three major things I'm worried about right now are a) doxygen, b) variable/function naming, c) GMT considerations. After those, I'll be exploring a patch for my own needs: the ability to get archives for particular term. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:53:34 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive.module (9.93 KB) Here's the latest, with the following changelog: * reordered some routines to be a little more workflowish. * renamed archive_buildQuery to archive_build_query. * general whitespace and formatting cleanup. * HEADish update: returning $output, not page templating it. * removed the reference of &$ad in archive_build_query. * test for the existence of arg(#)'s before validating them. * archive_validSomething changed to archive_valid_something. * removed unused vars: cur_date, cur_date_end. * renamed archive_buildURL to archive_build_url. * removed the HTML whitespace from the theming. * twiddled a lot of quotes and apostraphes. * removed 'future' CSS class. ill-defined. * reordered/renamed the CSS classes. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:08 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css.patch (1.56 KB) And the drupal.css patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:56:29 +0000 : Morbus Iff This version of the module is currently running live at http://www.nhpr.org/archive/. ------------------------------------------------------------------------ Mon, 29 Aug 2005 19:59:57 +0000 : Tobias Maier if i click for example on 2003 it would be good if this would go to january or december and marks them that this one will be shown now as you can see it if you click on january 2003. it has to select * on the first: the first month of writing * on the last: the last month of writing * on every else: january I hope you can understand what I mean... greets tobias ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:17:40 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_0.module (11.28 KB) Alright. I've attached another new version that adds a new feature that wasn't part of the original codemonkeyx CVS, but was chatted about on the devel list back in April. If this particular feature has bad code or needs heavy refactoring, certainly consider ONLY the version in comment #9 (and the matching drupal.css patch in #10). This new version supports dated archives based on taxonomy tids. It was a quick addition which NHPR.org needed (for the date nav; the normal tid archive pager wasn't strong enough for our needs). Since it was a quick addition, it supports only ONE tid at a time - the 'and/or' syntax for the taxonomy.module was not brought over. If that syntax was desired, it'd make more sense to create some sort of API for archive.module so that other nodes can take advantage of the dated nav in their normal pages (like node types, users, forums, etc.) The added code supports term matches at any granularity: # all node types that match tid 15000 ('The Front Porch') http://www.nhpr.org/archive/term/15000 # all 2005 node types that match tid 20 ('Health') http://www.nhpr.org/archive/2005/term/20 # all March, 2003 node types that match tid 9 ('Education') http://www.nhpr.org/archive/2003/3/term/9 # all July 11, 2003 node types that match tid 49 ('Economy') http://morbus.totalnetnh.net/nhpr/archive/2002/7/11/term/49 ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:27:26 +0000 : Tobias Maier what does this mean? "Story Archives of 'archives' " on http://www.nhpr.org/archive/term/15000 should this maybe named? "Archive of 'The Front Porch'" if I go to http://www.nhpr.org/archive/term/20 I can only read "archives"... why is there a difference? - I never tested this module on my test site, because I'm not at home - ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:29:34 +0000 : Morbus Iff Tobias: that wouldn't be possible, at least not accurately. The new archive.module supports browsing by year, month, and day, as you know. archive/2005 loads up all the data from a particular year and starts creating a pager out of it. Consider if you have 3 posts in December, and 15 posts in November. It wouldn't be "right" to highlight December because the pager display for the entire year would also include some of November's entries (since 3 is less than the pager increment). Likewise, if we ONLY showed the items from December, then we wouldn't have a "pager by year" feature, only a "pager by month (defaulting to December when none is selected)" feature. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:30:41 +0000 : Morbus Iff Tobias: regarding #14, that's an artifact of the templates that I'm using for NHPR, and has nothing to do with archive.module itself (in fact, once the anonymous cache expires, you'll see that little oopsie go away). ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:31:47 +0000 : Tobias Maier I can see your right :) I hope it comes in HEAD before tomorrow :D ------------------------------------------------------------------------ Tue, 30 Aug 2005 00:20:12 +0000 : dtan I apologize if this is already a known issue. http://www.nhpr.org/archive/2005/9 does not create a link for september 1st, even though there are 2 nodes listed (http://www.nhpr.org/archive/2005/9/1) ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:11:21 +0000 : Morbus Iff dtan: I'm pretty sure I know what this is - I'll address it either later today or tomorrow. ------------------------------------------------------------------------ Tue, 30 Aug 2005 20:49:58 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_1.module (11.53 KB) Alright, I've attached a new archive.module - this is the version WITH term filtering enabled. I can make one without terms if necessary - otherwise, I'll just work from this one for now. This version fixes the bug that dtan saw, as a well as a bunch of other off-by-one errors. Of primary importance, however, is that all mktime's that mattered have been switched to gmmktime, which was one of the oft-reported Issues with the old archive.module. I want to eyeball them all again and make sure they're right though. The URLs from #13 are still operational and the CSS from #10 is still required. ------------------------------------------------------------------------ Wed, 31 Aug 2005 00:02:06 +0000 : Morbus Iff In testing with a few people in #drupal, we've discovered a much bigger problem, which affects this rewritten module as well as the current core archive.module. In a nutshell, the node.created time is stored with time(). PHP's time() bases itself on the server time, NOT on GMT. Thus, for archive.module to work correctly, it must ALWAYS use mktime (relative to server time) and never consider the $user->timezone (relative to GMT). For archive.module, this would cause dates to always be considered via server time, which isn't good, but is better than the craziness going on now. Alternatively, we could try to convert server time to GMT first, and then work with that. The proper solution is to fix node.module to use gmmktime without any arguments for node.created, then have an update path that modifies all node .created and .modified values to GMT, not server time. ------------------------------------------------------------------------ Wed, 31 Aug 2005 05:53:51 +0000 : Junyor Since that is also a problem with the old archive.module, I don't see why it should stop this from getting into core. ------------------------------------------------------------------------ Wed, 31 Aug 2005 06:37:28 +0000 : stefan nagtegaal "Since that is also a problem with the old archive.module, I don't see why it should stop this from getting into core. " Well, I think it's better to only accept the best code rather than accepting bugs getting in core. ------------------------------------------------------------------------ Wed, 31 Aug 2005 07:05:51 +0000 : Kobus I am with Junyor on this. If this can be fixed, great, but if not, it's not a train smash, as the old one exhibits the same problem. I say add the new archive module, if there are no other ciritical bugs with it. It is much more robust and usable than the old one. We desperately need a new archive module. I couldn't find any other bugs while testing with the links Morbus posted. I don't have a HEAD installation anywhere, so can't test it locally at this moment. Regards, Kobus ------------------------------------------------------------------------ Wed, 31 Aug 2005 07:07:49 +0000 : Kobus BTW, code freeze means no new code added, right? Can't this module put in Core as is for the code freeze and the bug sorted out before the official release? Or is that just mean of me to suggest that? Kobus ------------------------------------------------------------------------ Wed, 31 Aug 2005 07:13:09 +0000 : Junyor Stefan: The bug is already in core, since node.module is in core. Archive.module (old and new!) just shows that bug. ------------------------------------------------------------------------ Wed, 31 Aug 2005 07:20:35 +0000 : Tobias Maier I want to have it in core for 4.7, too!!! ------------------------------------------------------------------------ Wed, 31 Aug 2005 07:25:24 +0000 : stefan nagtegaal Junyor: I know that.. Though I think it's not good to accept code which we are aware of that it has bugs in it.. Offcourse this is very double, because drupal contains (probably) a lot of bugs, only they weren't spotted yet.. But, accepting code which has bugs in unacceptable imo.. For example, the node revisions patch had almost 40 reviews/rewritings from Gerhard and several others before it was accepted to be in core.. If we do not allow bugs to go into core, we don't have to bughunt and fix later which is a good thing.. So, imo we should first sort out the problem, then discuss what the best way is to fix the problem, and after that Squeeze that moron! ;-) ------------------------------------------------------------------------ Wed, 31 Aug 2005 09:11:06 +0000 : adrian I vote we include this module, and open up a new issue for the bug. It's not archive's fault that this occurs, it is just showing the data it has access to. The bug already exists in core too. ------------------------------------------------------------------------ Wed, 31 Aug 2005 13:50:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_2.module (10.63 KB) Attached is a new, and most likely final, version of the archive.module. I've removed all user->timezone references - all date determinations are based on server time, which is also the time used in the "created" column of the node table. This is "more accurate" than what the core archive.module currently does (which'll always be wrong because it's treating server time as GMT, which isn't always the case). When node.module does start saving times as GMT properly, archive.module will have be to be tweaked with timezones and blah blah blah. I did fiddle around with determining the server offset in an attempt to get to a GMT base, but I didn't have much luck with that. The NHPR.org URLs above are still valid for testing. I need testers and reviewers. ------------------------------------------------------------------------ Wed, 31 Aug 2005 14:55:16 +0000 : m3avrck I get these two PHP errors when I have *no* content in my Drupal install (just did a clean install to test it): warning: mktime() [<a href='function.mktime'>function.mktime</a>]: Windows does not support negative values for this function in websites\drupal_cvs\drupal\modules\archive.module on line 274. warning: date() [<a href='function.date'>function.date</a>]: Windows does not support dates prior to midnight (00:00:00), January 1, 1970 in websites\drupal_cvs\drupal\modules\archive.module on line 274. Once I add content, these go away. Need some better checks to make sure if there is *no* content you don't get weird errors and what not :) ------------------------------------------------------------------------ Wed, 31 Aug 2005 14:55:45 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css_0.patch (1.56 KB) Updated drupal.css patch for HEAD. ------------------------------------------------------------------------ Wed, 31 Aug 2005 15:26:01 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_3.module (10.75 KB) Attached is the complete module, fixed for m3avrck's #31. ------------------------------------------------------------------------ Wed, 31 Aug 2005 17:30:36 +0000 : m3avrck Reviewed patch and further test, running great over here! Definetly +1 for this one! ------------------------------------------------------------------------ Wed, 31 Aug 2005 20:03:36 +0000 : Morbus Iff Note: The NHPR folks preferred their archives to be sorted from earliest to latest (SQL ASC vs. DESC) for month/day listings, so no longer use the NHPR.org URLs above as representative of the module itself. ------------------------------------------------------------------------ Wed, 31 Aug 2005 21:26:37 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/drupal.css (10.35 KB) CVS updated for HEAD again. ------------------------------------------------------------------------ Wed, 31 Aug 2005 21:27:00 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css_1.patch (1.56 KB) GRRR.

1 0

[drupal-devel] [bug] Multiple node types are broken
by chx 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/29785 Post a follow up: http://drupal.org/project/comments/add/29785 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node_basename.patch (3.92 KB) People come and tell me that I have broken node_get_module_name. I tell them I fixed it. This leads nowhere. Yesterday Kjartan, jakeg and me had finally a conversation during which we have arrived to the conclusion that there is no need for two hooks and hook_node_name could return either a string or an array in the form of: <?php array('type-a' => array('node type a', 'base')), 'type-b' => 'node type b', 'node type c'); ?> Which would define a 'type-a' , with a human readable name 'node type a' and base_load would be called for hook_load and so forth. for 'type-b' , the difference is that modulename_load would be called. For 'node type c', the node type would be modulename. chx

5 18

[drupal-devel] [bug] Can't delete subjects with '&' in title
by Souvent22 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/27140 Post a follow up: http://drupal.org/project/comments/add/27140 Project: Drupal Version: cvs Component: contact.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Souvent22 Reported by: m3avrck Updated by: Souvent22 Status: patch (code needs review) Thanks. yes, you're right. didn't know if that was universal across the board though since that'st he default, but someone could give their primary key constraint a diff. name. But, with your comment, I'll wait and let you take care of fixing my pgsql portion of my patch. Thanks for your comments though, really helpful...and not confusing. :). Souvent22 Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 14:57:03 +0000 : m3avrck Using the site-wide contact forms, any subjects with an '&' cannot be deleted. Clicking delete for these subjects brings up the expected action flow, however, confirming the delete does nothing. Subject still exists. ------------------------------------------------------------------------ Mon, 25 Jul 2005 13:45:38 +0000 : m3avrck It appears this issue might be linked with this one: http://drupal.org/node/23685 A problem with mod_rewrite and not the actual contact module. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:51:56 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_6.patch (4.7 KB) Redid how contacts work. It now references contacts by ID instead of their category as the unique identifier. It also allows for contacts to have weights, so that one may control where the contact will appear in the listing. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:53:01 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc (27.23 KB) This is the update.inc for the database cahnges that goes along with this patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:37 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_7.patch (4.5 KB) Updated patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc_4.patch (1.29 KB) Updated database patch. ------------------------------------------------------------------------ Sat, 03 Sep 2005 16:17:21 +0000 : Cvbge Hi, 0. You should keep all changes in one file, i.e. pake one patch, not patch for every file 1. You should include changes for database/database.{mysql,pgsql} 2. IIRC auto_increment was depreciated, you should use db_next_id() (but I see auto_increment in cvs...) 3. You use "WHERE cid = '%s'", but cid is integer so this should probably be %d (although this probably would not break anything..) ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:31:21 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full.patch (6.38 KB) Ok, I've taken your suggestions in, and i think I have it this time. Let me know if this is a correct format for a patch. This only fixes the bug of not being able to delete special characters. ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:37:30 +0000 : m3avrck Check your database updates, the UNIQUE fields don't look right syntactically. ------------------------------------------------------------------------ Wed, 07 Sep 2005 18:23:07 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full_0.patch (6.25 KB) Ok, i apologize for the last upload. Pleasle ignore. I send the wrong file. :-[. Anyway, here's a tested, tried, and correct patch. ------------------------------------------------------------------------ Wed, 07 Sep 2005 18:26:33 +0000 : m3avrck +1 patch works great! Latest HEAD version applied with update.php works great, modifies database correctly for MySQL (and PostgreSQL looks correct as well) and contacts can now be deleted if they have '&' in the subject. Also, dumped entire database and created from modified database.mysql and everything works great. I'd say this patch is ready to be committed! ------------------------------------------------------------------------ Wed, 07 Sep 2005 21:44:47 +0000 : Cvbge Hi, patch does not applies to currect cvs anymore. For the database.pgsql you need to remove (11) from int(11) and also first "category" from UNIQUE line, so it looks like this: CREATE TABLE contact ( cid int NOT NULL, category varchar(255) NOT NULL default '', recipients text NOT NULL default '', reply text NOT NULL default '', UNIQUE (category), PRIMARY KEY (cid) ); The updates are also not compatibile with postgres, but postgres upgrade path is completly broken in cvs and I'll fix it later, so do not pay attention to it. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:05:54 +0000 : Souvent22 Hello. Thanks for the feedback. I'm in the middle of fixing it, but i have a question. You'll have to excuse my ignorance with PostGres, I'm not as familiar with it as I am MySQL. With that said, I have a question..... I am trying to make my update where one does not lose data. However, in PostGres, I have to make a seperate "temp" table before hand and then copy the date over the the new table (cause i don't know the exact name of the constraint to drop e.g. the primary key). Basically I'm asking if there is a better suggestion in which I doint have to use a temp table, and i could just manipulate the original table? Thanks. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:12:35 +0000 : Souvent22 Also, I created a temp name for my temp table. However, for prefix purposes, should I enclose it? Example: $temp_name = rand(); $res = db_query("SELECT * FROM $temp_name"); or $temp_name = rand(); $res = db_query("SELECT * FROM {$temp_name}"); Thanks. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:55:40 +0000 : Souvent22 Clarification: $temp_name = rand(); db_query("CREATE TABLE $temp_name AS SELECT * FROM {contact}"); $res = db_query("SELECT * FROM $temp_name"); or $temp_name = rand(); db_query("CREATE TABLE {$temp_name} AS SELECT * FROM {contact}"); $res = db_query("SELECT * FROM {$temp_name}"); ------------------------------------------------------------------------ Thu, 08 Sep 2005 17:52:06 +0000 : Cvbge "cause i don't know the exact name of the constraint to drop e.g. the primary key " Yes, you know it, it's tablename_pkey. In this case it's contact_pkey. You can drop it by dropping index with it's name (you could drop constraint with it's name but it was not available in 7.2) Adding a column and adding unique attribute is also doable without temp table. You can look at (some) previous updates. But some of them are incorrect ;) By saying that I'll fix it later I meant that I want to introduce function to modify tables and don't want to make temporary fixes now.

1 0

[drupal-devel] [bug] On admin/themes/settings, the "Display post information on" section does not appear on HEAD.
by amanuel 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/30716 Post a follow up: http://drupal.org/project/comments/add/30716 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: amanuel Updated by: amanuel Status: patch (ready to be committed) On admin/themes/settings, the "Display post information on" section does not appear on HEAD. this is due to a simple typo: $node_type shoulde be $node_types patch: --- system.module 2005-08-28 14:17:47.000000000 -0400 +++ system.module.fixed 2005-09-08 15:24:31.000000000 -0400 @@ -794,7 +794,7 @@ } // Toggle node display. - $node_type = module_invoke('node', 'get_types'); + $node_types = module_invoke('node', 'get_types'); if ($node_types) { $group = ''; foreach ($node_types as $type => $name) { amanuel

1 0

[drupal-devel] [bug] fix empty form elements
by Dries 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/18663 Post a follow up: http://drupal.org/project/comments/add/18663 Project: Drupal Version: 4.6.3 Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: killes(a)www.drop.org Updated by: Dries -Status: patch (ready to be committed) +Status: patch (code needs review) Can someone test this first? Dries Previous comments: ------------------------------------------------------------------------ Thu, 10 Mar 2005 01:51:56 +0000 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ Sat, 12 Mar 2005 18:47:42 +0000 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick. ------------------------------------------------------------------------ Mon, 28 Mar 2005 16:27:03 +0000 : chx Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so. ------------------------------------------------------------------------ Mon, 28 Mar 2005 16:32:16 +0000 : chx Attachment: http://drupal.org/files/issues/checkboxes_0.patch (1.71 KB) Oh NO! One strayed space! I fixed it before steven beheads me.... ------------------------------------------------------------------------ Mon, 28 Mar 2005 17:36:01 +0000 : chx Attachment: http://drupal.org/files/issues/checkboxes_1.patch (1.64 KB) Among other changes, I have moved the hidden field form_checkboxes[] out of $edit. I have included HTML code, yes, but this is a very special thing, so it does not merit changing form_input just 'cos of this. And you won't need to theme a hidden field... ------------------------------------------------------------------------ Fri, 08 Apr 2005 07:19:28 +0000 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_2.patch (1.9 KB) killes did not like the previous version. ------------------------------------------------------------------------ Mon, 11 Apr 2005 23:15:05 +0000 : chx Dries? ------------------------------------------------------------------------ Tue, 12 Apr 2005 19:15:52 +0000 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ Tue, 12 Apr 2005 19:39:00 +0000 : jhriggs I have to agree with Steven that it is up to the calling code...and I hardly think this is critical. Code that is expecting an array from form_checkboxes() should ensure that it is dealing with an array (i.e. is_array()). As for dealing with variables set through things like system_settings_save(), the same thing applies. The code that is retrieving the variable should ensure that it is working with an array. With regards to your patch, what's the difference if the calling code has to remember to check via is_array() or remember to call fix_checkboxes()? This method is no less error prone as it's just as easy to forget this call as it is to check for an array. That is unless you are suggesting that fix_checkboxes() gets called for every page load which seems rather crufty. I wrote the original patch to add form_checkboxes() -- which didn't exist -- and if I remember, this was the desired behavior if nothing was selected. Isn't this the same behavior one would see using a multiple form_select() if the user chooses nothing? They should behave the same. A single select widget is the same as a radio group, and a multiple select widget is the same as a group of checkboxes. They should behave the same; the select types just take up less realestate. ------------------------------------------------------------------------ Tue, 12 Apr 2005 21:23:06 +0000 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_4.patch (2.06 KB) Previous patch had index.php missing. jhriggs, the current problem is that a form_checkboxes expected to be an array. Currently, empty form_checkboxes is a string. That's bad. ------------------------------------------------------------------------ Tue, 12 Apr 2005 22:51:25 +0000 : jhriggs -1 on this patch. I still don't understand the problem. What do you mean by "form_checkboxes expected to be an array"? Is there code in core that assumes it is an array but it is not checked with is_array()? If so, let's add the missing checks. The same goes for contrib. This seems like swatting a fly with a sledge hammer to me. If we do go ahead and make this change, however, then we will need to change form_select() also (when multiple = TRUE). Radios and single select should be consistent, as should checkboxes and multiple select. ------------------------------------------------------------------------ Sat, 23 Apr 2005 11:35:30 +0000 : chx Attachment: http://drupal.org/files/issues/fix_form.patch (4.71 KB) See Gordon's complaint http://lists.drupal.org/archives/drupal-devel/2005-04/msg00934.html ------------------------------------------------------------------------ Sat, 23 Apr 2005 11:38:07 +0000 : chx Forgot to change the title. ------------------------------------------------------------------------ Sat, 23 Apr 2005 11:46:46 +0000 : chx It seems that it's not obvious why this is necessary. The calling code can not always handle itself the situation if the save is done by system_save_settings. The edge case is: I set up something, so variable_get no longer falls to its default value, later I decide to empty it. If we do not do something like this patch, system_save_settings can not know there is something to be set to 0/array() because it is just not in $_POST. ------------------------------------------------------------------------ Sat, 23 Apr 2005 13:23:37 +0000 : chx Attachment: http://drupal.org/files/issues/fix_form_0.patch (4.72 KB) Small bugfix. ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:53:05 +0000 : chx doh. still has serious problems when the name is an array. stay tuned. ------------------------------------------------------------------------ Sun, 24 Apr 2005 09:13:00 +0000 : chx Attachment: http://drupal.org/files/issues/fix_form_1.patch (4.97 KB) Recursive version. ------------------------------------------------------------------------ Sun, 24 Apr 2005 12:51:18 +0000 : Dries Patch looks good but I would add some phpdoc to document what and why we are doing this. ------------------------------------------------------------------------ Sat, 21 May 2005 16:43:47 +0000 : chx Attachment: http://drupal.org/files/issues/fix_form_2.patch (3.23 KB) People told me that form_radios does not need this because we can reasonably expect that a radio is checked, that's different between a bunch of checkboxes and a bunch of radios. form_select submits an empty array (as also told by some). So we are back to checkbox and checkboxes which need the fix. ------------------------------------------------------------------------ Sat, 21 May 2005 16:55:24 +0000 : chx Attachment: http://drupal.org/files/issues/fix_form_3.patch (3.24 KB) ------------------------------------------------------------------------ Sat, 21 May 2005 18:34:20 +0000 : Dries Committed to HEAD. Thanks. ------------------------------------------------------------------------ Mon, 23 May 2005 00:09:30 +0000 : TDobes Why do we now have both a _fix_checkboxes() and fix_checkboxes() function? Shouldn't we name these something a little more intuitive? Without poking through the code, I have no idea what _fix_checkboxes is for and why it's different than fix_checkboxes. It really deserves some phpdoc too. Any sort of more-pleasant variable naming in _fix_checkboxes() would be much appreciated as well... It's easy to get lost in that array1/array2/single letter variable business pretty fast. Sorry for nit-picking, but most of the Drupal core code is far more readable than this. ------------------------------------------------------------------------ Tue, 06 Sep 2005 03:00:14 +0000 : mr700 It's strange that this problem still appears in drupal 4.6.3 (August 15, 2005); 4.6 CVS, and CVS Head and has been marked fixed on May 21, 2005. The last patch (fix_form_3.patch from comment 20 [1]) still applies with little fuzziness and fixes the problem. [1] http://drupal.org/node/18663#comment-30411 ------------------------------------------------------------------------ Wed, 07 Sep 2005 22:30:42 +0000 : tostinni Attachment: http://drupal.org/files/issues/fix_form-4.6.3.patch (3.54 KB) "It's strange that this problem still appears in drupal 4.6.3 (August 15, 2005); 4.6 CVS, and CVS Head and has been marked fixed on May 21, 2005. The last patch (fix_form_3.patch from comment 20) still applies with little fuzziness and fixes the problem. " The problem has been fixed in HEAD as Dries said in #21 HEAD refer to the future 4.7 version. Here is the updated patch that apply to 4.6.3

1 0

[drupal-devel] Release critical bugs for September 08, 2005
by drupal-devel＠drupal.org 08 Sep '05

08 Sep '05

/ bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 33 weeks 5 days url: http://drupal.org/node/15654 / bug reports Submit button needs double-press when menu options dropped-down age: 1 week 1 day url: http://drupal.org/node/30097 update.php is broken when drupal is installed in subdirectory age: 1 week 1 day url: http://drupal.org/node/30075 Drupal "forgets" some blocks... age: 1 week 6 days url: http://drupal.org/node/29733 system_settings_save() bypasses access_control age: 1 week 6 days url: http://drupal.org/node/29680 files table needs a "module" column age: 2 weeks 4 days url: http://drupal.org/node/29297 Dont't work rewrite for apache 2 assigned: Алексей age: 2 weeks 5 days url: http://drupal.org/node/29238 logo uploads still broken...? can't replace default logo with new drupal 4.6.3 tar ball? age: 2 weeks 5 days url: http://drupal.org/node/29221 Error when anonymous user creates content age: 3 weeks 1 day url: http://drupal.org/node/29032 Reset user mail variables. age: 3 weeks 3 days url: http://drupal.org/node/28868 Free Tagging broken on forums age: 4 weeks 1 day url: http://drupal.org/node/28607 js addLoadEvent not working. age: 5 weeks 4 days url: http://drupal.org/node/27884 Forum bug with drupal 462 age: 6 weeks 10 hours url: http://drupal.org/node/27663 enable MySQL client side for UTF8 age: 7 weeks 2 days url: http://drupal.org/node/26990 Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4) assigned: bigeye age: 7 weeks 6 days url: http://drupal.org/node/26780 postgresql autocomplete code age: 10 weeks 20 hours url: http://drupal.org/node/26027 Accidentally Deleting Forums Vocabulary in Categories Breaks Forums? age: 13 weeks 5 days url: http://drupal.org/node/24274 Taxonomy Multiple Hierarchy doesn't display children for all its parent age: 14 weeks 1 day url: http://drupal.org/node/24023 Getting term node counts fails without "Administer Nodes" permission age: 14 weeks 2 days url: http://drupal.org/node/24015 Mysql Password with special symbols assigned: zignit age: 18 weeks 4 days url: http://drupal.org/node/21719 4.6 aggregator showing/not interpreting HTML tags age: 22 weeks 5 days url: http://drupal.org/node/19874 User deleted - nodes still "crippled", NOT deleted! age: 24 weeks 6 days url: http://drupal.org/node/19098 New submit error, non-admin user, postgresql database assigned: adrian age: 26 weeks 2 days url: http://drupal.org/node/18552 user redirected to homepage when logging in age: 26 weeks 6 days url: http://drupal.org/node/18381 Change to sesssion.inc violates UID database constraint age: 33 weeks 4 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 34 weeks 3 days url: http://drupal.org/node/15411 PHP 5 gives error when session table has no session assigned: adschar age: 34 weeks 3 days url: http://drupal.org/node/15399 Argument NOT must be type boolean age: 42 weeks 3 days url: http://drupal.org/node/12950 Comments in approval queue still show up in tracker age: 46 weeks 5 days url: http://drupal.org/node/11647 Twin problems with comments assigned: Junyor age: 48 weeks 5 hours url: http://drupal.org/node/11366 user error: Duplicate entry assigned: Kjartan age: 1 year 39 weeks url: http://drupal.org/node/4428 / feature requests Site Slogan Margin age: 4 weeks 4 days url: http://drupal.org/node/28382 Filter the title to allow HTML comments age: 7 weeks 4 hours url: http://drupal.org/node/27205 moving pages en masse age: 23 weeks 5 hours url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 26 weeks 1 day url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 28 weeks 3 days url: http://drupal.org/node/17663 Allow named anchors to work without specifying full path to node age: 1 year 41 weeks url: http://drupal.org/node/4213 / support requests blocks age: 11 weeks 3 days url: http://drupal.org/node/25378 Problem with Forums age: 34 weeks 5 days url: http://drupal.org/node/15299 / bug reports Users with non-english locale cannot add events. age: 2 weeks 2 days url: http://drupal.org/node/29452 search over fields.inc fields conceptual error age: 44 weeks 6 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 44 weeks 6 days url: http://drupal.org/node/12257 / feature requests event.module support of repeating/recurring events? assigned: thehunmonkgroup age: 1 year 42 weeks url: http://drupal.org/node/4122 / bug reports Menu item not showing age: 48 weeks 6 days url: http://drupal.org/node/11210 / bug reports segmentation fault related to filestore age: 1 year 50 weeks url: http://drupal.org/node/3001 / bug reports file size bug age: 12 weeks 6 days url: http://drupal.org/node/24728 / bug reports gallery2 embeded bug with RC1 age: 3 weeks 20 hours url: http://drupal.org/node/29090 gallery bug - not integrated in drupal assigned: vidy age: 4 weeks 1 day url: http://drupal.org/node/28598 gallery.module doesn't synch passwords when they're changed age: 6 weeks 2 hours url: http://drupal.org/node/27702 Full screen slideshow in Gallery module is not working (erroring out on the wrong URL) age: 9 weeks 20 hours url: http://drupal.org/node/26479 Drupal session being logged out each time gallery module is called age: 11 weeks 4 hours url: http://drupal.org/node/25614 Gallery error age: 19 weeks 3 days url: http://drupal.org/node/21290 Fatal Error: variable_get() age: 24 weeks 4 days url: http://drupal.org/node/19189 No Gallery Image Block age: 25 weeks 9 hours url: http://drupal.org/node/19045 Mini applet can't find gallery at url / age: 25 weeks 5 days url: http://drupal.org/node/18785 Fatal error: Undefined class name 'galleryembed' age: 28 weeks 2 days url: http://drupal.org/node/17746 / support requests Can't Embed Gallery into Drupal age: 27 weeks 4 days url: http://drupal.org/node/18029 / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 1 year 25 weeks url: http://drupal.org/node/6392 / bug reports Path for image folder not inserted correctly when nodetype = image age: 1 week 2 days url: http://drupal.org/node/30031 image module patch & image_import module age: 2 weeks 3 days url: http://drupal.org/node/29377 image module fails on dual site configuration age: 8 weeks 17 hours url: http://drupal.org/node/26657 Editing a previously uploaded and thumnailed image loses the thumbnail. age: 11 weeks 2 days url: http://drupal.org/node/25465 Cannot upload .jpgs age: 27 weeks 3 days url: http://drupal.org/node/18076 Image.Module does not know the correct filename age: 42 weeks 2 days url: http://drupal.org/node/13032 / feature requests Image deletions? age: 1 day 16 hours url: http://drupal.org/node/30557 / support requests Images are there but not showing assigned: Stepfordtwit age: 6 weeks 1 day url: http://drupal.org/node/27615 Image Module Permissions age: 9 weeks 4 days url: http://drupal.org/node/26280 path problems on upgrading... age: 18 weeks 4 days url: http://drupal.org/node/21725 / bug reports RSS "no element found at line 1" age: 9 weeks 6 days url: http://drupal.org/node/26185 Outdated help texts age: 1 year 5 weeks url: http://drupal.org/node/9692 Import doesn't like XML/RSS feeds with no Title element age: 1 year 14 weeks url: http://drupal.org/node/8128 / tasks move XML-parser into an inclde file. age: 11 weeks 2 days url: http://drupal.org/node/25439 / feature requests Notify.module ignores the true submission queue age: 1 year 45 weeks url: http://drupal.org/node/3765 / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 23 weeks url: http://drupal.org/node/6795 / bug reports Reminder email links don't work age: 10 weeks 6 days url: http://drupal.org/node/25677 / bug reports access control problems age: 6 weeks 5 days url: http://drupal.org/node/27273 Download link is wrong age: 11 weeks 3 days url: http://drupal.org/node/25363 Projects not listed and page not complete age: 14 weeks 2 days url: http://drupal.org/node/23956 Date for latest is incorrect age: 21 weeks 12 hours url: http://drupal.org/node/20485 Invalid link to release files age: 28 weeks 4 days url: http://drupal.org/node/17625 Node body not complete w/o releases age: 30 weeks 6 days url: http://drupal.org/node/16733 blank page after install age: 31 weeks 1 day url: http://drupal.org/node/16575 / support requests Help with everything - nothing seems to work in the latest build age: 41 weeks 3 days url: http://drupal.org/node/13310 / bug reports Error with URL to recipe age: 1 week 3 days url: http://drupal.org/node/29885 / bug reports Can't get the inline tag to show series age: 17 weeks 2 days url: http://drupal.org/node/22520 / feature requests Request to generate email for all content changes/additions, including comments age: 7 weeks 5 days url: http://drupal.org/node/26824 / bug reports javascrip downloads square.gif for every category age: 29 weeks 2 days url: http://drupal.org/node/17366 / bug reports Sends trackbacks for unpublished nodes assigned: ankur age: 32 weeks 1 day url: http://drupal.org/node/16239

1 0

[drupal-devel] [bug] Handle full URLs in url() and l()
by adrian 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/10888 Post a follow up: http://drupal.org/project/comments/add/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: adrian Status: patch (code needs work) What needs to be removed from core are not uses of url() and l(), but all occurences of the anchor tag. The anchor tag was mostly used because l() didn't do external links. Also, in the case of phptemplate , that is the line that creates the array that is passed to the template. adrian Previous comments: ------------------------------------------------------------------------ Thu, 16 Sep 2004 15:01:24 +0000 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ Thu, 30 Sep 2004 11:09:30 +0000 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ Mon, 24 Jan 2005 20:06:26 +0000 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ Sun, 13 Mar 2005 22:36:34 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ Mon, 14 Mar 2005 00:05:17 +0000 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ Sat, 02 Apr 2005 06:23:10 +0000 : TDobes This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's? ------------------------------------------------------------------------ Sat, 02 Apr 2005 07:25:13 +0000 : asimmonds Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes) The &'s had been changed to & amp; , here's a valid patch ------------------------------------------------------------------------ Thu, 12 May 2005 14:57:07 +0000 : adrian This is a new patch against cvs that allows url() to create external links, with the side-effect that menu can now be used to make external links. Also closes http://drupal.org/node/10177 This will be even more important with the primary links menu integration. (This patch already cleans up a special case in phptemplate for that). Killes benchmarked this, and it turns out the difference is negligible. Requests per second: 1.33 [#/sec] (mean) = with patch Requests per second: 1.31 [#/sec] (mean) = without patch. ------------------------------------------------------------------------ Thu, 12 May 2005 14:59:57 +0000 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ Wed, 25 May 2005 04:50:08 +0000 : Steven +1 on the idea of this patch. It allows people to use l() for external links. However, I don't like the implementation. Running that complicated regexp for every url() call is simply wasteful. 95% or more of url() calls have a fixed string as parameter and point to Drupal's own paths. I suggest we create an url_external() wrapper around url() which allows external URLs. Any path which we want to allow external URLs in can use url_external() instead. The places where we use it will not be many anyway. ------------------------------------------------------------------------ Wed, 25 May 2005 05:05:55 +0000 : gordon splitting into url() url_external is not a good idea. The main reason for this patch that I see is for putting external urls into the navigation menu using the menu.module, and if all goes to plan, the primary and secondary menus. ------------------------------------------------------------------------ Wed, 25 May 2005 06:00:01 +0000 : Steven gordon: I still think this is a bit excessive. Perhaps instead of valid_url() we could use a simpler regexp !^[a-z]://!i or even strpos('://'). ------------------------------------------------------------------------ Wed, 25 May 2005 06:15:36 +0000 : gordon I am not says that it is or is not excessive. I was just saying that this is where it is going to be used, so creating url() and url_external() is not really an option ------------------------------------------------------------------------ Wed, 25 May 2005 06:57:53 +0000 : Bèr Kessels we /do/ need an external_url() thing. The links bundle (handling weblinks and the likes) willprovide this /and/ need this. People will get all sorts of tools to do /stuff/ with external links, like add permissions, track clicks etc. depending on the modules they have and the settings. All outgoing weblinks, should somehow respect those. Patches for core are coming, though. On top of that, a external_l() finction is simple. And if people want them in primary links they can do the regexping /before/ the function, not /in/ the function. The calling code can decide whether to call l() or external_l(), instead of putting logic in l() that is unneded 95% of the times. But i hereby promise to introduce such a function tbefore the end of this week :) ------------------------------------------------------------------------ Wed, 25 May 2005 07:17:47 +0000 : gordon The only thing I do not see in this plan is how with this work with the menu module and the navigation menu. ------------------------------------------------------------------------ Wed, 25 May 2005 10:04:12 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links.patch (1.75 KB) What happened to the patch i uploaded ? It doesn't use a complex regexp, but uses strpos($url, '://') < 5. ------------------------------------------------------------------------ Thu, 26 May 2005 06:19:32 +0000 : Bèr Kessels Allthough this works, is clean AND does what it should do, I still am in favour of a better nitegrated solution. So please do not yet commit this, untill I upload my patch. We can then discuss what solution to take. It will not differ a big lot though. ------------------------------------------------------------------------ Thu, 26 May 2005 08:39:32 +0000 : adrian is this the patch where you want to introduce an el() to allow for counting of external links ? That's a different patch altogether. This is primarily about stopping url() from not handling external links when there is no good reason for it to do so. Your el() has a very specific use in the weblinks api, and should probably be included with it. ------------------------------------------------------------------------ Thu, 26 May 2005 16:18:31 +0000 : Bèr Kessels Yes, that el() But let me explain why i am anxious for my solution: el(), by default will not do much, in fact it will just be an URL()-clone but one that allows outgoing links. But it has a hook-caller. Again: by default it does nothing much, for there will not be any hooks around in core. It will allow, for example, weblinks, to track clicks, or to look up a permission and allow or disallow users to follow a link. Now, the whole issue, IMO is, that we should *not* provide two ways for handling external URLS, but rather a single one, that is weblink-safe. If we would introduce URL() with outgoing links-capabilities, we can no longer track any outgoing URLs trough them. We will then have two ways for handling outgoing URLs, resulting in inconsistencies, and confused users. (hey, my anonymous users can follow link foo, while i have "follow outgig links" permission disabled for them). (BTW weblink will soon be renamed into links, just for reference) ------------------------------------------------------------------------ Thu, 30 Jun 2005 11:06:11 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links_0.patch (824 bytes) I've updated the patch. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:12:36 +0000 : adrian spoke to dries about this patch, and apart from the incomplete patch I uploaded, there are about a dozen instances where in-line html is used were l() would suffice. I will be cleaning them up and submitting a new patch soon. ------------------------------------------------------------------------ Fri, 05 Aug 2005 18:44:03 +0000 : moshe weitzman hopefully adrian or someone else will chase down the remaining urls which should use this function. ------------------------------------------------------------------------ Fri, 05 Aug 2005 19:25:08 +0000 : jsloan I've come to this party late but would like to see a patch soon... I've used the patch from Adrian (#15) but this did not work correctly in my setup (IIS 5.0 / no clean urls) I applied it against 4.6.2 and cvs. Where is the latest patch that I can test ... I'll throw some time at this because I need it for a module used within our Intranet. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:06:03 +0000 : jsloan Attachment: http://drupal.org/files/issues/external_urls_2.patch (3.67 KB) I'm not sure what the final plans are for this in the CVS so I have developed a patch for use on 4.6.2 I decided to add a parameter named $external that is passed to url() function. The default is FALSE so this should not break any existing calls to either l() or url(). I have also refactored url() so that it is much easier to understand and extend --- I'm thinking of Bèr Kessels intention to "allow, for example, weblinks, to track clicks, or to look up a permission and allow or disallow users to follow a link" " Since the parameter is passed to activate the external url there is no need for regex or strpos, this should be handled by the calling function and then set the $external parameter to TRUE For example I have patched the theme_menu_item_link() function in menu.inc to accept external urls: <?php function theme_menu_item_link($item, $link_item) { // this next line was added so that a menu item could point to the default home $link_item['path'] = preg_replace('/^\/$/','',$link_item['path']); // this next line was added so that a menu item could point to an external url $external = (preg_match('<^[a-z]+://>', $link_item['path'])) ? TRUE : FALSE ; return l($item['title'], $link_item['path'], array_key_exists('description', $item) ? array('title' => $items['description']) : array(),NULL,NULL,FALSE,FALSE,$external); } ?> I hope that this patch will spur some solutions - I'm using this now in production but have not tested extensively across every scenario. thanks jim sloan ------------------------------------------------------------------------ Fri, 19 Aug 2005 12:10:50 +0000 : jsloan ... are there any thoughts on this? What is the status of the final patch? ------------------------------------------------------------------------ Sun, 28 Aug 2005 15:48:08 +0000 : adrian The problem with this patch is that we still need to fix all the inline occurrences of the <a href tag. I don't think we should confuse the issue and implement a hook at this point, as url() breaking with external links is a bug, pure and simple. ------------------------------------------------------------------------ Thu, 08 Sep 2005 15:24:16 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/theme.inc.patch.txt (1.16 KB) Adrian, your second patch for theme.inc looks wrong to me. Don't you still need the line $settings[$type .'_links'][] = l($text, $link, $attributes); ? I also got rid of unset($attributes); Where was that supposed to come from that it needed unsetting? ------------------------------------------------------------------------ Thu, 08 Sep 2005 15:48:02 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/theme.common.inc.patch.txt (1.83 KB) Here is a unified patch that I updated to fix a bug in Adrian's common.inc code (everything was being handled as absolute), plus the update to theme.inc that I questioned in the previous post. In my initial testing, this works perfectly. I can put absolute URLs in for the paths in menu items and it handles them fine, and changes no other behavior. I searched core for all uses of url() and http:// and found no more violating code such as that in theme.inc. Net change in core with this patch: 0 lines of code. Please review quickly, I'm writing in the upcoming book about this functionality as if it is in. =) ------------------------------------------------------------------------ Thu, 08 Sep 2005 15:49:43 +0000 : robertDouglass Correction: net change to core -1 line of code.

1 0

[drupal-devel] [bug] Can't delete subjects with '&' in title
by Cvbge 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/27140 Post a follow up: http://drupal.org/project/comments/add/27140 Project: Drupal Version: cvs Component: contact.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Cvbge Status: patch (code needs review) "cause i don't know the exact name of the constraint to drop e.g. the primary key " Yes, you know it, it's tablename_pkey. In this case it's contact_pkey. You can drop it by dropping index with it's name (you could drop constraint with it's name but it was not available in 7.2) Adding a column and adding unique attribute is also doable without temp table. You can look at (some) previous updates. But some of them are incorrect ;) By saying that I'll fix it later I meant that I want to introduce function to modify tables and don't want to make temporary fixes now. Cvbge Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 14:57:03 +0000 : m3avrck Using the site-wide contact forms, any subjects with an '&' cannot be deleted. Clicking delete for these subjects brings up the expected action flow, however, confirming the delete does nothing. Subject still exists. ------------------------------------------------------------------------ Mon, 25 Jul 2005 13:45:38 +0000 : m3avrck It appears this issue might be linked with this one: http://drupal.org/node/23685 A problem with mod_rewrite and not the actual contact module. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:51:56 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_6.patch (4.7 KB) Redid how contacts work. It now references contacts by ID instead of their category as the unique identifier. It also allows for contacts to have weights, so that one may control where the contact will appear in the listing. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:53:01 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc (27.23 KB) This is the update.inc for the database cahnges that goes along with this patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:37 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_7.patch (4.5 KB) Updated patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc_4.patch (1.29 KB) Updated database patch. ------------------------------------------------------------------------ Sat, 03 Sep 2005 16:17:21 +0000 : Cvbge Hi, 0. You should keep all changes in one file, i.e. pake one patch, not patch for every file 1. You should include changes for database/database.{mysql,pgsql} 2. IIRC auto_increment was depreciated, you should use db_next_id() (but I see auto_increment in cvs...) 3. You use "WHERE cid = '%s'", but cid is integer so this should probably be %d (although this probably would not break anything..) ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:31:21 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full.patch (6.38 KB) Ok, I've taken your suggestions in, and i think I have it this time. Let me know if this is a correct format for a patch. This only fixes the bug of not being able to delete special characters. ------------------------------------------------------------------------ Wed, 07 Sep 2005 17:37:30 +0000 : m3avrck Check your database updates, the UNIQUE fields don't look right syntactically. ------------------------------------------------------------------------ Wed, 07 Sep 2005 18:23:07 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact_full_0.patch (6.25 KB) Ok, i apologize for the last upload. Pleasle ignore. I send the wrong file. :-[. Anyway, here's a tested, tried, and correct patch. ------------------------------------------------------------------------ Wed, 07 Sep 2005 18:26:33 +0000 : m3avrck +1 patch works great! Latest HEAD version applied with update.php works great, modifies database correctly for MySQL (and PostgreSQL looks correct as well) and contacts can now be deleted if they have '&' in the subject. Also, dumped entire database and created from modified database.mysql and everything works great. I'd say this patch is ready to be committed! ------------------------------------------------------------------------ Wed, 07 Sep 2005 21:44:47 +0000 : Cvbge Hi, patch does not applies to currect cvs anymore. For the database.pgsql you need to remove (11) from int(11) and also first "category" from UNIQUE line, so it looks like this: CREATE TABLE contact ( cid int NOT NULL, category varchar(255) NOT NULL default '', recipients text NOT NULL default '', reply text NOT NULL default '', UNIQUE (category), PRIMARY KEY (cid) ); The updates are also not compatibile with postgres, but postgres upgrade path is completly broken in cvs and I'll fix it later, so do not pay attention to it. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:05:54 +0000 : Souvent22 Hello. Thanks for the feedback. I'm in the middle of fixing it, but i have a question. You'll have to excuse my ignorance with PostGres, I'm not as familiar with it as I am MySQL. With that said, I have a question..... I am trying to make my update where one does not lose data. However, in PostGres, I have to make a seperate "temp" table before hand and then copy the date over the the new table (cause i don't know the exact name of the constraint to drop e.g. the primary key). Basically I'm asking if there is a better suggestion in which I doint have to use a temp table, and i could just manipulate the original table? Thanks. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:12:35 +0000 : Souvent22 Also, I created a temp name for my temp table. However, for prefix purposes, should I enclose it? Example: $temp_name = rand(); $res = db_query("SELECT * FROM $temp_name"); or $temp_name = rand(); $res = db_query("SELECT * FROM {$temp_name}"); Thanks. ------------------------------------------------------------------------ Thu, 08 Sep 2005 13:55:40 +0000 : Souvent22 Clarification: $temp_name = rand(); db_query("CREATE TABLE $temp_name AS SELECT * FROM {contact}"); $res = db_query("SELECT * FROM $temp_name"); or $temp_name = rand(); db_query("CREATE TABLE {$temp_name} AS SELECT * FROM {contact}"); $res = db_query("SELECT * FROM {$temp_name}");

1 0

[drupal-devel] [feature] move image.module to core
by robertDouglass 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/25685 Post a follow up: http://drupal.org/project/comments/add/25685 Project: Drupal Version: cvs -Component: other +Component: base system Category: feature requests Priority: normal Assigned to: walkah Reported by: robertDouglass Updated by: robertDouglass -Status: active +Status: patch (code needs work) Attachment: http://drupal.org/files/issues/image_in_core.patch.txt (29.01 KB) So here's a patch. It needs work - some of the update tasks for getting this ready for 4.7 are quite obtuse. Somebody with intimate knowledge of the image module and HEAD should take a good look, but at least there is a patch. There is still time left before the freeze, and neither Dries nore Steven have indicated that they are opposed to including this, but it will take some work. The next round is for someone else. robertDouglass Previous comments: ------------------------------------------------------------------------ Fri, 24 Jun 2005 14:02:38 +0000 : robertDouglass How do people feel about moving image.module to core? My personal view is that it is the right thing to do. We will have had the entire 4.6 cycle to evaluate image.module and image.inc, and I think that they are both on the same level of quality as Drupal as a whole. Furthermore, image.module is essential to most known uses of Drupal, including drupal.org. The amount of work needed for making this move is relatively small. There is no new database schema. The biggest issue would be the image.module specific upgrade script and the documentation that would need to be written to warn and instruct people who might be upgrading from the previous image module. -Robert ------------------------------------------------------------------------ Sun, 26 Jun 2005 01:03:14 +0000 : kbahey According to this http://drupal.org/node/25704, it is one of the most downloaded modules on Drupal.org. Also, part of it is already in core (image.inc). So, for me, it makes sense to move it to core as well. But: keep it minimalistic, with fancy addons as contribs. ------------------------------------------------------------------------ Mon, 27 Jun 2005 23:05:33 +0000 : shane +1 But - I wouldn't want to lose site of the fact that the image.module is WAY TOO BASIC and needs some more features to make it actually useful. The initial discussion regarding img_assist.module in the top20 page is a great example of the problems with the workflow of adding images. ------------------------------------------------------------------------ Tue, 28 Jun 2005 13:50:52 +0000 : Uwe Hermann +1. The image module really belongs in core. Uwe. ------------------------------------------------------------------------ Wed, 29 Jun 2005 13:09:56 +0000 : walkah robert - i'm flattered that you think so highly of the code... Dries and I talked about putting image in core when I was doing the rewrite ... and decided against it. I can't totally remember why now... I'm essentially +1 to this idea, and am fully willing to continue maintaining a core image.module (and adding enhancements, etc). One thing I think we need to figure out though is ... what do folks want most out of a core image.module? (i.e. do we want galleries? just easy inclusion in blog posts? bulk uploading? etc...) ------------------------------------------------------------------------ Wed, 29 Jun 2005 14:04:40 +0000 : pegmonkey +1 HOWEVER.... it wasn't ready and yet released for 4.6. I'd say it's a good consideration, but I advise caution. The upgrade to 4.6 just about destroyed my working images. Derivatives were broken and though fixed now, had some major issues that took a while to get sorted out. Yes I backed it up.. so no big deal. But, still it was far from ready to be released. I had actually considered solutions other than drupal for my sites during that time, but I stuck with it. Others might not have been as persistant. Images are a very important part of most web sites so it should go in eventually. I'd have given the initial 4.6 release an alpha rating at best. I would suggest that if it goes in, it go in as a very basic module and then additional modules that add features be created. I think mass upload would be good to include. Galleries and various other features could be external modules. ------------------------------------------------------------------------ Wed, 13 Jul 2005 04:45:49 +0000 : Zed Pobre I'd volunteer a +1, if it meant that the breakage would be less likely to occur in the future. I'm still running 4.5.2 because image.module is too critical to my website, and I can't deal with it breaking. If making it a core component meant tighter integration and upgrade handling all around, I'd be much happier. Bulk upload is a key feature for me, by the way, one of the other reasons I haven't forged ahead. I make heavy use of the old image.module galleries, but if additional modules will give me any gallery ability, I'm not very particular about the features or the exact form. The pictures just need to be accessible. ------------------------------------------------------------------------ Mon, 15 Aug 2005 20:22:01 +0000 : walkah i'm gonna see what I can do on this front... assigning so i don't forget :) ------------------------------------------------------------------------ Mon, 15 Aug 2005 21:45:01 +0000 : sepeck +1 for me. So far most/any issue's that people have experianced seem to have come down to permissions issues specific to the server configuration that they were on and whether the files/images directory existed or not.. ------------------------------------------------------------------------ Mon, 15 Aug 2005 22:28:39 +0000 : robertDouglass I'm glad that there is so much support for the idea. It will be especially nice because the imagemagick.inc file can be in the includes directory from the start (I always forget to move it). Are there any reasons NOT to put this module in core? If there are tasks that still need doing, please, let's talk about them so that we can get them done before the code freeze. ------------------------------------------------------------------------ Tue, 23 Aug 2005 13:19:09 +0000 : neuraxon77 +1 core it. please. With the galleries. More work needs to be done, and could be at a later date. They way it is now is functional as far as i'm concerned. The img_assist module still needs work but again something like it IMHO should be in core too. There needs to be more modules like these essential to content creation in core. Quick! Get it in before the code freeze. :) If it has Images, Galleries and the Free Tagging, 4.7 should be good.

1 0

[drupal-devel] [support] Problems with using relative path names
by Goba 08 Sep '05

08 Sep '05

Issue status update for http://drupal.org/node/13148 Post a follow up: http://drupal.org/project/comments/add/13148 Project: Drupal -Version: 4.6.3 +Version: cvs Component: base system Category: support requests Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: Goba -Status: active +Status: patch (code needs review) What if you let this issue get solved for CVS HEAD (4.7), before requesting a patch for 4.6.x? (Restoring important status values). Goba Previous comments: ------------------------------------------------------------------------ Fri, 19 Nov 2004 03:29:34 +0000 : 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/x template/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/ pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutto n/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! ------------------------------------------------------------------------ Sat, 20 Nov 2004 04:10:17 +0000 : 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. ------------------------------------------------------------------------ Sat, 20 Nov 2004 04:35:06 +0000 : 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. ------------------------------------------------------------------------ Sat, 20 Nov 2004 09:55:21 +0000 : 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 :) ------------------------------------------------------------------------ Sat, 20 Nov 2004 10:19:30 +0000 : Dries Goba is right. We need paths relative to the domain name to fix this 'problem'. ------------------------------------------------------------------------ Sat, 20 Nov 2004 20:19:32 +0000 : 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? ------------------------------------------------------------------------ Sun, 21 Nov 2004 16:24:27 +0000 : chx Attachment: http://drupal.org/files/issues/common_inc_patch.txt (471 bytes) I have implemented what Goba suggested. ------------------------------------------------------------------------ Sun, 21 Nov 2004 16:43:56 +0000 : chx Attachment: http://drupal.org/files/issues/common_inc_patch_0.txt (825 bytes) Maybe this one is faster? ------------------------------------------------------------------------ Sun, 21 Nov 2004 17:34:37 +0000 : 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 ------------------------------------------------------------------------ Mon, 22 Nov 2004 00:28:01 +0000 : 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'] . '/' ); ?> ------------------------------------------------------------------------ Sun, 28 Nov 2004 04:08:56 +0000 : kbahey Did this patch make it into CVS yet? If there are any objections to it, can someone please explain what they are? Thanks ------------------------------------------------------------------------ Sun, 28 Nov 2004 09:33:01 +0000 : 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. ------------------------------------------------------------------------ Sun, 28 Nov 2004 18:54:02 +0000 : 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? ------------------------------------------------------------------------ Sun, 28 Nov 2004 19:26:59 +0000 : 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... ------------------------------------------------------------------------ Sun, 28 Nov 2004 23:06:39 +0000 : 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. ------------------------------------------------------------------------ Thu, 02 Dec 2004 20:31:27 +0000 : 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. ------------------------------------------------------------------------ Thu, 02 Dec 2004 21:15:19 +0000 : 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. ------------------------------------------------------------------------ Thu, 02 Dec 2004 22:07:08 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Dec 2004 15:31:57 +0000 : Goba Please commit this into Drupal core, this fix is badly needed. ------------------------------------------------------------------------ Mon, 17 Jan 2005 13:00:12 +0000 : 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. ------------------------------------------------------------------------ Mon, 17 Jan 2005 13:09:10 +0000 : 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. ------------------------------------------------------------------------ Mon, 17 Jan 2005 16:03:02 +0000 : 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 ------------------------------------------------------------------------ Mon, 17 Jan 2005 16:57:09 +0000 : 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? ------------------------------------------------------------------------ Mon, 17 Jan 2005 17:38:10 +0000 : 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. ------------------------------------------------------------------------ Mon, 17 Jan 2005 18:35:07 +0000 : 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. ------------------------------------------------------------------------ Mon, 17 Jan 2005 21:36:32 +0000 : 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. ------------------------------------------------------------------------ Mon, 17 Jan 2005 21:48:45 +0000 : 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). ------------------------------------------------------------------------ Mon, 17 Jan 2005 21:54:30 +0000 : 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… ------------------------------------------------------------------------ Mon, 17 Jan 2005 22:34:25 +0000 : 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 ------------------------------------------------------------------------ Tue, 18 Jan 2005 07:14:21 +0000 : 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. ------------------------------------------------------------------------ Tue, 01 Feb 2005 23:33:58 +0000 : 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 ------------------------------------------------------------------------ Tue, 01 Feb 2005 23:37:23 +0000 : 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. ------------------------------------------------------------------------ Wed, 02 Feb 2005 23:40:36 +0000 : 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? ------------------------------------------------------------------------ Thu, 17 Feb 2005 14:50:29 +0000 : kbahey This patch is badly needed. The lack of a leading / in many paths is causing lots of problems. ------------------------------------------------------------------------ Sat, 12 Mar 2005 20:32:26 +0000 : kbahey Can this patch be applied for 4.6? it is really badly needed. ------------------------------------------------------------------------ Tue, 22 Mar 2005 20:50:55 +0000 : 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. ------------------------------------------------------------------------ Tue, 22 Mar 2005 21:00:45 +0000 : chx The second patch is better. ------------------------------------------------------------------------ Tue, 22 Mar 2005 21:46:27 +0000 : 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. ------------------------------------------------------------------------ Tue, 22 Mar 2005 22:03:51 +0000 : jhriggs I have to agree with the last comment from grohk. ------------------------------------------------------------------------ Tue, 22 Mar 2005 22:39:33 +0000 : 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. ------------------------------------------------------------------------ Wed, 23 Mar 2005 00:37:52 +0000 : 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. ------------------------------------------------------------------------ Fri, 29 Apr 2005 23:29:41 +0000 : kbahey Circular log errors reported here too http://drupal.org/node/9499 ------------------------------------------------------------------------ Sat, 30 Apr 2005 19:35:50 +0000 : 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... ------------------------------------------------------------------------ Sun, 01 May 2005 22:09:58 +0000 : 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 ------------------------------------------------------------------------ Sun, 01 May 2005 22:11:04 +0000 : clydefrog That should be "encourage other more marginal crawlers to observe the standards." ------------------------------------------------------------------------ Fri, 06 May 2005 19:00:40 +0000 : 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. ------------------------------------------------------------------------ Fri, 06 May 2005 19:14:23 +0000 : 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. ------------------------------------------------------------------------ Fri, 06 May 2005 19:37:37 +0000 : kbahey "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. ------------------------------------------------------------------------ Sun, 08 May 2005 14:52:40 +0000 : killes(a)www.drop.org The patch apparently hasn't found much favour, setting to "active". I suggest to get hold of the IP ranges the broken crawlers use and block them in the .htaccess file we ship with Drupal. Long live open web standards! ------------------------------------------------------------------------ Sun, 08 May 2005 18:08:12 +0000 : kbahey It is really sad that most of us do not see a problem here, or brush it off as someone else's problem. Standards are only valid if everyone follows them. The reality is that some do not, and depending on the market presence and strengths of those in violation of the standard, they are insignificant to something that is to be dealt with. If web designers ignored Microsoft Internet Expolrer, with its blatant aloofness to standard, unintentional or otherwise, they would be out of business. 80% of people are still using MS IE. This is exactly the same issue. To see the magnitude of the problem, run the following SQL against your site: > select hostname from watchdog where type = 'httpd' and message like '%.css%'; > select hostname, count(*) cnt from watchdog where type = 'httpd' and message like '%.css%' group by hostname order by cnt asc; The first shows 5383 rows, the latter shows 1886 rows. As I said we will not be breaking any standards by qualifying our URLs and making them unambiguous to everyone, starting with the /. ------------------------------------------------------------------------ Sun, 08 May 2005 23:24:50 +0000 : clydefrog kbahey, have you contacted any of these crawlers to tell them their software is broken? ------------------------------------------------------------------------ Mon, 09 May 2005 01:30:18 +0000 : kbahey No. I haven't. There are 1866 unique IPs over the a period of 4 months. Even if we assume that these are in subnets, and say 10 per subnet, this means I have to contact 186 separate organizations/individuals, which is such a great effort. Even if I assume that there is skew, and that there are 20 organizations/individuals, it is still a great effort, and how many of those will respond, let alone fix their crawlers. The question is: what is within our control and influence and what is not. This is like writing CSS for MS IE and for other standard conforming browsers. Or like defensive driving in an area where there are many rogue drivers. You cannot say that you are conforming to css standards and hell with the rest of the world, and you will not deal with them at all. Nor can you say that you are within your lane, at the set speed and keeping your distance, and will cross a green light while a drunk person is crossing the intersection. We had to deal with comment spam (Google's nofollow, various modules to deal with it, or turning off anonymous comments, and moderating them), and referer spam (hide the statistics pages from view, or disabling statistics altogether). Didn't we? It is a rough world out there, and if the others are unethical or criminals or just don't play by the rules, we still have to deal with them. How is this any different? Seeing this as a purely external issue and not dealing with it in the software we control is unrealistic. Remember that the fix does not break any standards. We will still be standard compliant with it, so the standards slant of it is not convincing. Sorry, I just see it this way, and none of the counter arguments so far is convincing to me so far. ------------------------------------------------------------------------ Mon, 09 May 2005 02:04:28 +0000 : clydefrog This is not at all like MSIE. IE is a majority browser, so designing sites that don't work with it loses users. This, on the other hand, is a small minority of crawlers making a nuisance of themselves. The drunk driver analogy is a little bit closer, but this isn't a life or death situation. You've convinced me that you want this feature, but you haven't convinced me that I want this feature. If this is committed, *please* make it optional! ------------------------------------------------------------------------ Wed, 18 May 2005 00:14:56 +0000 : jayCampbell This issue interferes with BlogLines' ability to autodetect feeds. Several desktop clients have the same problem. While I agree that ideally this should be an optional change, losing 10% of your RSS readership is serious stuff. Thank you for the interim hide-saving, chx. ------------------------------------------------------------------------ Wed, 18 May 2005 03:18:56 +0000 : kbahey chx Was the patch updated for 4.6? I have applied only the common.inc. But since I am now using phptemplate based themes (pushbutton, and soon a custom one), can you please give some instructions on what to change (e.g. putting path_to_theme() in some places?) Thanks in advance. ------------------------------------------------------------------------ Wed, 01 Jun 2005 21:47:16 +0000 : njvack I've tested this with 4.6 -- one of the hunks didn't want to apply to common.inc; I think it was a line count off-by-one change or something, though -- I made the change by hand and it's working great. This patch hasn't found widespread acceptance... is it breaking things for some people? This feels like a better method of handling links than using BASE HREF, as far as I can feel. The way I see it is: Google is pretty good at indexing web pages. Not perfect, but I'm willing to believe they understand HTML better than I do. BASE HREF isn't a new part of the standard. At all. If Google doesn't support the way Drupal is trying to use BASE HREF, my money is that Google is right, and Drupal is using the tag in an unintended way. But anyhow, it's happy under 4.6 for me, so far. ------------------------------------------------------------------------ Sun, 19 Jun 2005 18:56:20 +0000 : mjr I just read through this thread because i have been beaten by the problem: I am in need for URLs relative to the server document root for different reasons. First, my server lives in a LAN behind a firewall. Since it runs several web apps, drupal in installed in a subdirectory of my document root. It is accessible from the outside solely via https and from inside the LAN under a different name, via https as well as using normal http (the latter is necessary to get cron.php working correctly, isn't it?) Secondly, run a clone of this site as a testing platform on my laptop, which obviously has its own URL and to be able to sync it with as little hassle as possible. IMHO this is very important - especially if You set up sites using many modules You will need to test Your setup somewhere else before going onto the production system. Thirdly, it prevents me from using http(s)://localhost/drupal46 or IP addresses to access the site. Fourthly i or some remote user will get hassle to mirror the site or parts of it into static pages (that's again the crawler problem). Such a situation has been discussed elsewhere in this forum multiple times, and the commonly accepted proposal was to use a relative path as a base URL, in my setting '/drupal46' (if i remember correctly, it is even in drupal's manual, isn't it?) --- although this will obviosly break the HTML-standard. Now comes the real problem: relative paths in are interpreted as intended by this hack by most relevant browsers: Mozilla et al., Opera, MSIE 5.x, Safari, even by exots like lynx and links, but there are a few ones that adhere strictly to standards in this respect, beside a few other exots like w3m and amaya MSIE 6.x also belongs to this group. Which means that my site is not accessible by 2/3 of the world. Really ugly. I am aware of using a multisite setup as a workaround, but seriously, why use a workaround which costs me administrative effort if a clean and standard conforming solution is at sight, namely avoiding the use of the tag in favour of using paths relative to the document root of my server or virtual host. So i would strongly vote for modifying drupal to drop using the tag. Although being part of HTML even before HTML 1.0 has been defined (always as an optional tag, BTW) it brings in more trouble than it helps. best regards Michael ------------------------------------------------------------------------ Mon, 22 Aug 2005 13:36:39 +0000 : Uwe Hermann What's the status of this issue? ------------------------------------------------------------------------ Mon, 22 Aug 2005 13:53:53 +0000 : Goba Now that we have /patch (code needs work)/, this is a perfect issue to put into that status. I would vote for the change provided by the latest patch in this issue, although I have not tested the patch myself. At least at weblabor.hu and drupal.hu, we run with a custom url() function which just does what this patch is about to do (but since these Drupal setups are in the root folder, we just prepend a slash to all path values). The patch [6] needs to be updated to latest CVS, and as Dries said [7] he is willing to fix this problem, it should be committed after a review. [6] http://drupal.org/node/13148#comment-19433 [7] http://drupal.org/node/13148#comment-16088 ------------------------------------------------------------------------ Mon, 22 Aug 2005 14:30:19 +0000 : chx Attachment: http://drupal.org/files/issues/base_kill.patch (8.25 KB) Reworked. ------------------------------------------------------------------------ Thu, 08 Sep 2005 15:59:30 +0000 : bergermann same patch for version 4.6.3 distributed files P L E A S E ... :-)

1 0