May 2005 - Development - lists.drupal.org

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

25 May '05

Issue status update for http://drupal.org/node/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 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. adrian Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 17:01 : 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 ?> ------------------------------------------------------------------------ September 30, 2004 - 13:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 24, 2005 - 22:06 : 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. ------------------------------------------------------------------------ March 14, 2005 - 00:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 14, 2005 - 02:05 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ April 2, 2005 - 08:23 : 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? ------------------------------------------------------------------------ April 2, 2005 - 09:25 : 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 ------------------------------------------------------------------------ May 12, 2005 - 16:57 : 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. ------------------------------------------------------------------------ May 12, 2005 - 16:59 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ May 25, 2005 - 06:50 : 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. ------------------------------------------------------------------------ May 25, 2005 - 07:05 : 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. ------------------------------------------------------------------------ May 25, 2005 - 08:00 : 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('://'). ------------------------------------------------------------------------ May 25, 2005 - 08:15 : 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 ------------------------------------------------------------------------ May 25, 2005 - 08:57 : 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 :) ------------------------------------------------------------------------ May 25, 2005 - 09:17 : gordon The only thing I do not see in this plan is how with this work with the menu module and the navigation menu.

1 0

[drupal-devel] [bug] Handle full URLs in url() and l()
by gordon 25 May '05

25 May '05

Issue status update for http://drupal.org/node/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: gordon Status: patch The only thing I do not see in this plan is how with this work with the menu module and the navigation menu. gordon Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 01:01 : 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 ?> ------------------------------------------------------------------------ September 30, 2004 - 21:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 25, 2005 - 06:06 : 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. ------------------------------------------------------------------------ March 14, 2005 - 08:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 14, 2005 - 10:05 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ April 2, 2005 - 16:23 : 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? ------------------------------------------------------------------------ April 2, 2005 - 17:25 : 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 ------------------------------------------------------------------------ May 13, 2005 - 00:57 : 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. ------------------------------------------------------------------------ May 13, 2005 - 00:59 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ May 25, 2005 - 14:50 : 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. ------------------------------------------------------------------------ May 25, 2005 - 15:05 : 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. ------------------------------------------------------------------------ May 25, 2005 - 16:00 : 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('://'). ------------------------------------------------------------------------ May 25, 2005 - 16:15 : 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 ------------------------------------------------------------------------ May 25, 2005 - 16:57 : 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 :)

1 0

[drupal-devel] [task] Introduce Daylight Saving Time for Drupal
by gordon 25 May '05

25 May '05

Issue status update for http://drupal.org/node/11077 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: crunchywelch Reported by: killes(a)www.drop.org Updated by: gordon Status: patch Do not take this the wrong what, but when it comes to dst, this is exemely simplisict. What would be the best method of doing this is to use the Zone Info files from libc. These not only have all the dst splits, but also all the timezones, and would be the most acurate. Have a look at Sources of Time Zone and Daylight Savings Data [1] whcih has pointers to where all this information is. Did you know that Australia has 21 different Timezones and DST areas. If you could enter the same information from tzdata then this would be the altermate dst system [1] http://www.twinsun.com/tz/tz-link.htm gordon Previous comments: ------------------------------------------------------------------------ September 26, 2004 - 13:01 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst.patch (6.04 KB) Many people have wanted to have a Daylight Saving Time setting in the past. If we use the "server time" modell (all times are displayed the same around the world) this isn't all that hard to do. I found a lot of usefull information here: http://webexhibits.org/daylightsaving/g.html The patch introduces a new DST setting and uses it if the "Configurable time zones" setting is switched off. ------------------------------------------------------------------------ September 26, 2004 - 14:40 : gordon This is a lovely patch, but you do realise that you have opened a can of worms. Daylight saving is a messy business, I had to write the Contestable Electricity billing for a company here in Australia which had multiple installations in multpile timezones, all with different daylight savings rules, which impacted upon the bill. The way that dst is legistated is very messy and here is Australia it is very messy. Daylight savings don't follow state lines, as some towns that are very close to the border may choose to follow the only the daylight saving period of the next state, and when we had the olympics NSW went into daylight savings months before anyone else. There are other examples of weird things like even the 1 hour forward is not also true. I know that in the 1999 change to daylight savings there was a small set of islands north of New Zealand that went ahead by 2 hours as they wanted to be the first into 2000. >From what I can see of your patch it only allows for a single daylight savings period for the entire system. Their can be situations where there can be users from multiple countries and in different timezones/dst. I think that entire timezone system needs to looked at again, and maybe re-implement it so that it will allow for dst. Maybe make it a bit more user friendly so instead of setting up the timezone by name much like how operating systems do it, and then this will automatically work out the timezone. +1 for this is something that would be good, but it still needs work. ------------------------------------------------------------------------ September 27, 2004 - 00:13 : Anonymous The patch works as it is now. I had good reason to limit its capability to the setting where users cannot chose their own timezone. ;) I also assume that a server administrator knows if he has dst or not. I also didn't (yet) cater for all countries where dst is in use mainly because some insist on not giving a sensible rule for the change dates. ------------------------------------------------------------------------ September 27, 2004 - 08:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst_0.patch (6.04 KB) The last comment was mine. After a code review by Kjartan I provide a slightly improved patch. I want to stress that solving the DST issue in a "suits everybody" manner isn't the intention of this patch. It solves the problem for people who have chosen to let all times on their site be displayed in the server's time setting. By covering a large portion of the earth's landmass I hope to be able to help most site admins. It would be possible to extend the patch to allow users to chose their DST setting, too. In my experience, however, users tend to not care about time settings at all. This may be EUrocentric though, as we have only one time zone. Feedback is welcome. ------------------------------------------------------------------------ September 28, 2004 - 07:12 : drumm +1 >From a code review I think this is an excellent solution. Could use a little more comments in the section that sets $node->date to explain the (probably good) reasoning behind that chunk of code. I don't have anything resembling a good set of tests so I did not apply the patch and try it. ------------------------------------------------------------------------ January 26, 2005 - 06:38 : killes(a)www.drop.org I just want to point out that this patch still applies and would make for a fine feature for Drupal 4.6... ------------------------------------------------------------------------ January 27, 2005 - 02:46 : alliax wouldn't hurt to have this feature in upcoming drupal. I would use it for sure, my users are from the same place, with dst ------------------------------------------------------------------------ April 29, 2005 - 02:12 : Sage This is an incredibly useful feature and I would like to see it incorporated into the next release (current release is 4.6.0). ------------------------------------------------------------------------ May 5, 2005 - 02:06 : syntaxerror Works beautifully.. I'm going to work on getting this to work with event.module. ------------------------------------------------------------------------ May 5, 2005 - 03:53 : crunchywelch I have just discussed with killes and rorris an enhancement to this patch which I will implement. We have proposed putting the ical timezone db (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ical/ical.sql?re…) in core. We will implement a DST field in that db for each zone which coreesponds with the zones in killes' patch here for dtermining whether a zone is currently in dst or not. Currently, the 5 zones in the drupal_is_dst() function in this patch will be the only regions assigned to timezones. If more regions are desired they can be submitted by the community. To be clear, this must be implemented before additional development on ical/event.module can proceed properly. We would like this to be in core for 4.7, and move one more step with timezone handling in event module to use this as well. Discuss! ------------------------------------------------------------------------ May 5, 2005 - 04:13 : tostinni I agree to put more specific region to DST as it's easier for someone to know which city DST he belongs than which DST Zone (Pacific Standard Time...). I like pretty much the way that windows manage this. +1 ------------------------------------------------------------------------ May 5, 2005 - 12:45 : Jaza The patch looks good... however, it doesn't take into account the fact that in Australia, DST starts and ends at 2am on Sunday morning. So these lines: case 4: // Australia // start of DST (last Sunday in October) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + $timezone; // end of DST (last Sunday in March) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + $timezone; break; Should read: case 4: // Australia // start of DST (last Sunday in October at 2am) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200 + $timezone; // end of DST (last Sunday in March at 2am) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + 7200 + $timezone; break; There are also a whole lot more countries (and their specific DST rules) on http://webexhibits.org/daylightsaving/g.html than are implemented in this patch. I'd ultimately like to see an admin interface to let the webmaster add additional DST rules for whatever country they live in (or are developing for). These rules could be entered in raw PHP, or using a somewhat friendlier interface. Jaza. ------------------------------------------------------------------------ May 25, 2005 - 16:11 : Steven +1 on this patch. Catches most cases and at least provides a base for others to work on.

1 0

[drupal-devel] [feature] i18n - Adding language to nodes, taxonomy terms and vocabularies
by Steven 25 May '05

25 May '05

Issue status update for http://drupal.org/node/16547 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: Steven Status: patch char(2) is not sufficient for language codes. There are 3 letter codes too, but also, you can add local variants (en-gb, nl-be). I'm not sure we need this in core. Core already outputs a language attribute in the <html> tag. This belongs in i18n.module in a separate table. Steven Previous comments: ------------------------------------------------------------------------ February 1, 2005 - 13:29 : Jose A Reyero Attachment: http://drupal.org/files/issues/i18n_language_fields_01.patch (4.65 KB) This one adds a simple language field to the following tables: node, vocabulary, term_data Includes a small patch for taxonomy module in order to add the new fields to the list of fields to be inserted/updated. This is not needed for node module, as the field can be introduced with hook_nodeapi

1 0

[drupal-devel] [bug] Handle full URLs in url() and l()
by Bèr Kessels 25 May '05

25 May '05

Issue status update for http://drupal.org/node/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Bèr Kessels Reported by: jhriggs Updated by: Bèr Kessels Status: patch 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 :) Bèr Kessels Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 16:01 : 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 ?> ------------------------------------------------------------------------ September 30, 2004 - 12:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 24, 2005 - 21:06 : 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. ------------------------------------------------------------------------ March 13, 2005 - 23:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 14, 2005 - 01:05 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ April 2, 2005 - 07:23 : 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? ------------------------------------------------------------------------ April 2, 2005 - 08:25 : 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 ------------------------------------------------------------------------ May 12, 2005 - 15:57 : 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. ------------------------------------------------------------------------ May 12, 2005 - 15:59 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ May 25, 2005 - 05:50 : 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. ------------------------------------------------------------------------ May 25, 2005 - 06:05 : 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. ------------------------------------------------------------------------ May 25, 2005 - 07:00 : 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('://'). ------------------------------------------------------------------------ May 25, 2005 - 07:15 : 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

1 0

[drupal-devel] [bug] Brackets should not be used in IDs (primary offender: form_ functions)
by Steven 25 May '05

25 May '05

Issue status update for http://drupal.org/node/19986 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: killes(a)www.drop.org Reported by: factoryjoe Updated by: Steven Status: patch JonBob: while there can be a problem with file uploading, the id attribute is used purely for theming and CSS/JS. I didn't see this patch and already applied a more recent one [1]. It is similar to this one, except that it only replaces ][ in the id. Feel free to submit a patch there with a regexp if you think it is better. Note that you should replace a string of /consecutive/ disalowed characters with a single dash. This is better for readability. [1] http://drupal.org/node/23516 Steven Previous comments: ------------------------------------------------------------------------ April 5, 2005 - 00:41 : factoryjoe Attachment: http://drupal.org/files/issues/blah.html (1.13 KB) Square brackets in IDs are not valid XHTML and cause a host of problems when trying to style individual elements. I have attached a page that proves this. Additionally, when you try to style an element by an ID that contains brackets, *all other styling from that rule will be ignored*. Brackets are simply not valid characters for IDs [2] (/emphasis added/): There's also a difference between CLASS and ID attributes as regards to the allowable format of values. By HTML rules, CLASS is CDATA, which basically means 'anything goes', but CSS rules impose some restrictions. /And by HTML rules, ID is ID, which means that only letters of the English alphabet ([A-Za-z]), digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".") are permitted, and the first character must be a letter (and underscores don't work reliably)/ " If you validate the attached document, you will get these two errors: XHTML validation error Line 25, column 19: character "]" is not allowed in the value of attribute "id" <div id="edit-16188][weight"> CSS validation errors Line: 17 Context : #edit-16188 Parse Error - #edit-16188][weight { border: 2px solid blue; } Line: 20 Context : #edit-16188 Parse Error - #edit-16188][weight, #test-2 { border: 2px solid green; } [2] http://css.nu/faq/ciwas-aFAQ.html#QA14 ------------------------------------------------------------------------ April 5, 2005 - 01:50 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/valid-forms.patch (5.95 KB) Ok, here is an initial patch. The patch needs testing. I introduced a new function _form_get_id that is supposed to replace any non-allowed characters by a dash. This is not really nice, as we will get CSS IDs that have double dashes, but it is valid. We cannot simply reduce the double dashes to single dashes because there already might be another ID with only a single dash. ------------------------------------------------------------------------ April 5, 2005 - 02:29 : gordon This will tidy up the id's of the fields. I have seen this esp. in writing htmlarea as I need to manipulate the ids to remove the [] and other chars. When this is applies please inform Me, and the Authors of FckEditor, and TinyEd as this patch will break the gui editors in some places. This is not a minus, but I myself will like to avoid having the htmlarea module broken for no longer than it needs to. ------------------------------------------------------------------------ April 5, 2005 - 10:39 : Bèr Kessels can we not expand this into a general ID checker. So that we can be assured of unique ids on any page? Bèr ------------------------------------------------------------------------ April 5, 2005 - 15:52 : killes(a)www.drop.org It would be possible to do this, yes. We'd need to ensure that all IDs are generated by this function and save the IDs in a static var and do something if the ID is already taken. However, this coul dlead to different IDs for the same tag on different pages. So it isn't a really good idea. it is mandatory that Drupal ets fixed before the 4.6 release. So please somebody test the patch: :) ------------------------------------------------------------------------ April 5, 2005 - 16:01 : JonBob The problem does go a little deeper than this. There are several places in the code where it is assumed that form field names are scalars rather than arrays. Typically, we get around this with the ugly 'array][field' syntax, and that causes problems for IDs to be sure. But it also confuses other APIs that take form element names, such as file_check_upload(). You can't pass an 'array][field' name to this function and have things work. I think we need a more global solution that gets away from the confusing bracket sequence entirely. Perhaps allow an array of strings to be passed to the form_ functions, so we could do form_textfield('foo', array('foo', 'bar')) instead of form_textfield('foo', 'foo][bar').

1 0

[drupal-devel] [bug] Handle full URLs in url() and l()
by gordon 25 May '05

25 May '05

Issue status update for http://drupal.org/node/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jhriggs Updated by: gordon Status: patch 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 gordon Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 01:01 : 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 ?> ------------------------------------------------------------------------ September 30, 2004 - 21:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 25, 2005 - 06:06 : 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. ------------------------------------------------------------------------ March 14, 2005 - 08:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 14, 2005 - 10:05 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ April 2, 2005 - 16:23 : 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? ------------------------------------------------------------------------ April 2, 2005 - 17:25 : 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 ------------------------------------------------------------------------ May 13, 2005 - 00:57 : 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. ------------------------------------------------------------------------ May 13, 2005 - 00:59 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ May 25, 2005 - 14:50 : 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. ------------------------------------------------------------------------ May 25, 2005 - 15:05 : 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. ------------------------------------------------------------------------ May 25, 2005 - 16:00 : 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('://').

1 0

[drupal-devel] [task] Introduce Daylight Saving Time for Drupal
by Steven 25 May '05

25 May '05

Issue status update for http://drupal.org/node/11077 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: crunchywelch Reported by: killes(a)www.drop.org Updated by: Steven Status: patch +1 on this patch. Catches most cases and at least provides a base for others to work on. Steven Previous comments: ------------------------------------------------------------------------ September 26, 2004 - 05:01 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst.patch (6.04 KB) Many people have wanted to have a Daylight Saving Time setting in the past. If we use the "server time" modell (all times are displayed the same around the world) this isn't all that hard to do. I found a lot of usefull information here: http://webexhibits.org/daylightsaving/g.html The patch introduces a new DST setting and uses it if the "Configurable time zones" setting is switched off. ------------------------------------------------------------------------ September 26, 2004 - 06:40 : gordon This is a lovely patch, but you do realise that you have opened a can of worms. Daylight saving is a messy business, I had to write the Contestable Electricity billing for a company here in Australia which had multiple installations in multpile timezones, all with different daylight savings rules, which impacted upon the bill. The way that dst is legistated is very messy and here is Australia it is very messy. Daylight savings don't follow state lines, as some towns that are very close to the border may choose to follow the only the daylight saving period of the next state, and when we had the olympics NSW went into daylight savings months before anyone else. There are other examples of weird things like even the 1 hour forward is not also true. I know that in the 1999 change to daylight savings there was a small set of islands north of New Zealand that went ahead by 2 hours as they wanted to be the first into 2000. >From what I can see of your patch it only allows for a single daylight savings period for the entire system. Their can be situations where there can be users from multiple countries and in different timezones/dst. I think that entire timezone system needs to looked at again, and maybe re-implement it so that it will allow for dst. Maybe make it a bit more user friendly so instead of setting up the timezone by name much like how operating systems do it, and then this will automatically work out the timezone. +1 for this is something that would be good, but it still needs work. ------------------------------------------------------------------------ September 26, 2004 - 16:13 : Anonymous The patch works as it is now. I had good reason to limit its capability to the setting where users cannot chose their own timezone. ;) I also assume that a server administrator knows if he has dst or not. I also didn't (yet) cater for all countries where dst is in use mainly because some insist on not giving a sensible rule for the change dates. ------------------------------------------------------------------------ September 27, 2004 - 00:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst_0.patch (6.04 KB) The last comment was mine. After a code review by Kjartan I provide a slightly improved patch. I want to stress that solving the DST issue in a "suits everybody" manner isn't the intention of this patch. It solves the problem for people who have chosen to let all times on their site be displayed in the server's time setting. By covering a large portion of the earth's landmass I hope to be able to help most site admins. It would be possible to extend the patch to allow users to chose their DST setting, too. In my experience, however, users tend to not care about time settings at all. This may be EUrocentric though, as we have only one time zone. Feedback is welcome. ------------------------------------------------------------------------ September 27, 2004 - 23:12 : drumm +1 >From a code review I think this is an excellent solution. Could use a little more comments in the section that sets $node->date to explain the (probably good) reasoning behind that chunk of code. I don't have anything resembling a good set of tests so I did not apply the patch and try it. ------------------------------------------------------------------------ January 25, 2005 - 22:38 : killes(a)www.drop.org I just want to point out that this patch still applies and would make for a fine feature for Drupal 4.6... ------------------------------------------------------------------------ January 26, 2005 - 18:46 : alliax wouldn't hurt to have this feature in upcoming drupal. I would use it for sure, my users are from the same place, with dst ------------------------------------------------------------------------ April 28, 2005 - 18:12 : Sage This is an incredibly useful feature and I would like to see it incorporated into the next release (current release is 4.6.0). ------------------------------------------------------------------------ May 4, 2005 - 18:06 : syntaxerror Works beautifully.. I'm going to work on getting this to work with event.module. ------------------------------------------------------------------------ May 4, 2005 - 19:53 : crunchywelch I have just discussed with killes and rorris an enhancement to this patch which I will implement. We have proposed putting the ical timezone db (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ical/ical.sql?re…) in core. We will implement a DST field in that db for each zone which coreesponds with the zones in killes' patch here for dtermining whether a zone is currently in dst or not. Currently, the 5 zones in the drupal_is_dst() function in this patch will be the only regions assigned to timezones. If more regions are desired they can be submitted by the community. To be clear, this must be implemented before additional development on ical/event.module can proceed properly. We would like this to be in core for 4.7, and move one more step with timezone handling in event module to use this as well. Discuss! ------------------------------------------------------------------------ May 4, 2005 - 20:13 : tostinni I agree to put more specific region to DST as it's easier for someone to know which city DST he belongs than which DST Zone (Pacific Standard Time...). I like pretty much the way that windows manage this. +1 ------------------------------------------------------------------------ May 5, 2005 - 04:45 : Jaza The patch looks good... however, it doesn't take into account the fact that in Australia, DST starts and ends at 2am on Sunday morning. So these lines: case 4: // Australia // start of DST (last Sunday in October) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + $timezone; // end of DST (last Sunday in March) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + $timezone; break; Should read: case 4: // Australia // start of DST (last Sunday in October at 2am) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200 + $timezone; // end of DST (last Sunday in March at 2am) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + 7200 + $timezone; break; There are also a whole lot more countries (and their specific DST rules) on http://webexhibits.org/daylightsaving/g.html than are implemented in this patch. I'd ultimately like to see an admin interface to let the webmaster add additional DST rules for whatever country they live in (or are developing for). These rules could be entered in raw PHP, or using a somewhat friendlier interface. Jaza.

1 0

[drupal-devel] [bug] Forum module's use of if in Postgresql
by patrickslee 25 May '05

25 May '05

Issue status update for http://drupal.org/node/23499 Project: Drupal Version: 4.6.0 Component: forum.module Category: bug reports Priority: normal Assigned to: patrickslee Reported by: cchamilt Updated by: patrickslee Status: patch Oh what have I done! I changed nothing! IF(l.last_comment_uid <> 0 AND l.last_comment_uid IS NOT NULL, cu.name, l.last_comment_name) patrickslee Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 16:32 : cchamilt Postgresql function "if" is defined to return a boolean value, yet forum requests an integer - last_comment_uid. user error: query: SELECT n.nid, l.last_comment_timestamp, IF(l.last_comment_uid, cu.name, l.last_comment_name) as last_comment_name, l.last_comment_uid FROM node n, node_comment_statistics l /*! USE INDEX (node_comment_timestamp) */, users cu, term_node r WHERE n.nid = r.nid AND r.tid = 1 AND n.status = 1 AND n.type = 'forum' AND l.last_comment_uid = cu.uid AND n.nid = l.nid ORDER BY l.last_comment_timestamp DESC LIMIT 1 OFFSET 0 in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 62. warning: pg_query() [function.pg-query]: Query failed: ERROR: function if(integer, character varying, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /var/www/hosts/www.ambigc.com/htdocs/includes/database.pgsql.inc on line 45. ------------------------------------------------------------------------ May 25, 2005 - 10:07 : patrickslee Attachment: http://drupal.org/files/issues/forum.module_3.patch (2.69 KB) I have also encountered this bug and made a possible patch by replacing IF statements to CASE. A patch file is attached. ------------------------------------------------------------------------ May 25, 2005 - 10:28 : adrian There is an IF function defined in the database.pgsql function. On what page is this happening, as what might be happening is that the type isn't being picked up correctly. It's defined as IF(anyelement, anyelement, text) returns anyelement. IIRC. What I have seen happen is that it wants the text field to return integer, or vice versa. ------------------------------------------------------------------------ May 25, 2005 - 10:32 : patrickslee I found the definition in database.pgsql. It is like this: CREATE FUNCTION "if"(boolean, anyelement, anyelement) RETURNS anyelement AS ' SELECT CASE WHEN $1 THEN $2 ELSE $3 END; ' LANGUAGE 'sql'; So it is actually wanting boolean. ------------------------------------------------------------------------ May 25, 2005 - 10:43 : patrickslee So my patch will work, and we can make it easier by replacing the IF function to: IF(l.last_comment_uid 0 AND l.last_comment_uid NULL, cu.name, l.last_comment_name) BTW there is another place in forum.module use IF like this. ------------------------------------------------------------------------ May 25, 2005 - 10:45 : patrickslee Oops... my <>s are stolen. IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) ------------------------------------------------------------------------ May 25, 2005 - 17:20 : cchamilt Yes that line works great. Thanks for your help! ------------------------------------------------------------------------ May 25, 2005 - 17:52 : patrickslee This patch shows another problem. The last post user will always show "Anonymous" or whatever you defined. Looking for solution... ------------------------------------------------------------------------ May 25, 2005 - 18:00 : patrickslee Use this line instead: IF(l.last_comment_uid <> 0 AND l.last_comment_uid <> NULL, cu.name, l.last_comment_name) Don't forget there are two places in forum.module need to be changed.

1 0

[drupal-devel] [feature] favicon patch for themes
by nysus 25 May '05

25 May '05

Issue status update for http://drupal.org/node/20809 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: nysus Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/favicon.patch (4.57 KB) Here is a patch that allows a user to manually set the path to the "favicon.ico" file. It makes a single change to the user interface: it adds a text field to the "Logo image setting" section of the "themes/settings" page. This is especially useful for sites sharing a single code base as you no longer need to create a new theme just so you can have a distinct favicon.ico. nysus

9 17