- Development - lists.drupal.org

[drupal-devel] [bug] Fix 404 handling without clean URLs
by killes 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/13594 Post a follow up: http://drupal.org/project/comments/add/13594 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Steven Reported by: Steven Updated by: killes(a)www.drop.org -Status: active +Status: patch (code needs work) Steven what's up with this? killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sun, 28 Nov 2004 15:08:31 +0000 : Steven Attachment: http://drupal.org/files/issues/404.patch (1.07 KB) When clean urls are enabled, non-existant pages are rewritten to www.site.com/?q=non/existant. The menu handler will throw a 404 on the non-existant Drupal path. However, if clean urls are not active, then the 404 page (index.php) is called as is. $GET['q'] will be empty, and the front page will be shown without any indication of the 404 or without a log entry in the watchdog. Note that this only happens if .htaccess is being read, but mod_rewrite is not present or enabled. Not too common, but still a bug. The attached patch fixes this problem by checking for a 404 in index.php and calling drupal_not_found() if needed. It also sets $_GET['q'] to request_uri(), so the 404'd URL shows up correctly in the watchdog (same as the rewrite rule). This should go in 4.5 as well as HEAD. Patch is for HEAD, but it should apply to 4.5. ------------------------------------------------------------------------ Sun, 28 Nov 2004 15:17:22 +0000 : Steven An alternative solution is to drop the ErrorDocument 404 from .htaccess, then the web server will handle them if there are no clean URLs. However I think the intended behaviour is for Drupal to log all 404s. ------------------------------------------------------------------------ Sun, 13 Mar 2005 20:44:58 +0000 : killes(a)www.drop.org Doesn't apply anymore.

1 0

[drupal-devel] [bug] PostgreSQL fix
by plj 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/28287 Post a follow up: http://drupal.org/project/comments/add/28287 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: plj Updated by: plj Status: patch (code needs review) Attachment: http://drupal.org/files/issues/forum.module_5.patch (1.02 KB) In addition to this [1] old bug there is another bug in cvs version of forum.module, when the database in use is PostgreSQL. When forum configuration page is accessed first time, Drupal attempts to create a new vocabulary for forums: INSERT INTO vocabulary (name, description, help, multiple, required, hierarchy, relations, tags, weight, module, vid) VALUES ('Forums', '', '', 0, 1, 1, 0, '', 0, 'forum', '1') Unfortunately, this throws an 'Invalid input syntax for integer' error, as no value is assigned for field 'tags'. I've included a patch that should insert 0 into that field to avoid the error, but I hope someone would review it, as I'm no expert in PHP and thus unsure that I made it correctly. Only one row is affected. [1] http://drupal.org/node/23499 plj

2 1

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

19 Aug '05

Issue status update for http://drupal.org/node/10888 Post a follow up: http://drupal.org/project/comments/add/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: jsloan Status: patch (code needs work) ... are there any thoughts on this? What is the status of the final patch? jsloan 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

1 0

[drupal-devel] [bug] PG_QUERY ERROR - LOCK TABLES - IMPLEMENTATION FAULT.
by Cvbge 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/22911 Post a follow up: http://drupal.org/project/comments/add/22911 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: kinai Updated by: Cvbge -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/locks.diff (2.91 KB) The patch adds two functions to lock and unlock tables. Cvbge Previous comments: ------------------------------------------------------------------------ Sun, 15 May 2005 14:34:48 +0000 : kinai I get this error : Warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error on or near "cache" at character 13 in /var/www/drupal/includes/database.pgsql.inc on line 45 Fatal error: ERROR: syntax error on or near "cache" at character 13 query: LOCK TABLES cache WRITE in /var/www/drupal/includes/database.pgsql.inc on line 62 Someone could solve this problem ? Thanks kinaï ------------------------------------------------------------------------ Sun, 15 May 2005 15:19:26 +0000 : kinai The SQL Command : LOCK TABLES like used in bootstrap.inc is only specified for MySQL, not for PostgreSQL. The UNLOCK TABLES SQL command is not implemented in PostgreSQL. Someone could solve this problem ? Thanks, Kinaï ------------------------------------------------------------------------ Sat, 28 May 2005 23:34:03 +0000 : bd_csmc this issue still exists, i've verified it on a fresh cvs install w/ pgsql 8 ------------------------------------------------------------------------ Sat, 28 May 2005 23:39:52 +0000 : bd_csmc i fixed the problem in my installation, by changing the syntax to: LOCK TABLE {cache} it's table, not tables. and i dropped the 'write' bit. furthermore, pgsql does not support the UNLOCK command, so i had to comment the unlock tables command. unless there are more lock/unlock commands elsewhere in the code, this works fine for me. according to pgsql docs, UNLOCK is automatically performed at transaction end, which is why there is no such command.

1 0

[drupal-devel] [bug] Call to undefined function check_plain in in xmlrpc.inc in drupal 4.5.5
by puregin 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/29149 Post a follow up: http://drupal.org/project/comments/add/29149 Project: Drupal Version: 4.5.5 Component: other Category: bug reports Priority: normal Assigned to: Anonymous Reported by: underwaterguy Updated by: puregin Status: patch (code needs review) Attachment: http://drupal.org/files/issues/29149_01.patch (929 bytes) I can confirm that this problem exists and that underwaterguy's patch fixes the problem. I am supplying his patch in unified diff format. Djun puregin Previous comments: ------------------------------------------------------------------------ Thu, 18 Aug 2005 20:54:47 +0000 : underwaterguy Attachment: http://drupal.org/files/issues/xmlrpc.inc.underwaterguy.patch (342 bytes) I'm getting an error in my hourly cron run: Fatal error: Call to undefined function: check_plain() in /home/wadsworth/www/jeaun.com/includes/xmlrpc.inc on line 67 It appears that the new version of xmlrpc.inc in drupal 4.5.5 contains a call to the check_plain function, which I believe only exists in drupal 4.6. I'm guessing that those function calls should be changed to drupal_specialchars, since the two functions appear to be doing essentially the same thing. I've attached a patch that switches the function calls. I can't seem to upload the patch (although it's easy enough to make manually,) so here it is: 67c67 < return '<string>'. check_plain($xmlrpc_value->data) .'</string>'; --- > return '<string>'. drupal_specialchars($xmlrpc_value->data) .'</string>'; 80c80 < $return .= " <member><name>". check_plain($name) ."</name><value>"; --- > $return .= " <member><name>". drupal_specialchars($name) ."</name><value>"; ------------------------------------------------------------------------ Thu, 18 Aug 2005 20:56:42 +0000 : underwaterguy Okay, so the patch was uploaded. The preview function wasn't working for some reason, so I couldn't see that it was already there. ------------------------------------------------------------------------ Thu, 18 Aug 2005 23:17:25 +0000 : Uwe Hermann Hi, thanks for the report. Please provide patches in a proper format, though, see http://drupal.org/patch.

1 0

[drupal-devel] Wordpress 1.6 "node" edit form
by Dries Buytaert 19 Aug '05

19 Aug '05

http://asymptomatic.net/wp/2005/08/18/1898/better-every-day/ I sorta like the resizable textarea (see animated gif). -- Dries Buytaert :: http://www.buytaert.net/

4 4

[drupal-devel] [bug] Do not encode apostrophes
by chx 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/29103 Post a follow up: http://drupal.org/project/comments/add/29103 Project: Drupal Version: cvs Component: base 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/check_plain.patch (567 bytes) walkah complained that XML-RPC escapes apostrophes. Steven said it's OK not to do so, so here is the patch. I am quoting the manual: "It takes on one of three constants with the default being ENT_COMPAT: ENT_COMPAT Will convert double-quotes and leave single-quotes alone. ENT_QUOTES Will convert both double and single quotes. ENT_NOQUOTES Will leave both double and single quotes unconverted. " chx

3 3

[drupal-devel] anyone interested in participating in SpikeSource's Open Testing Contest
by Kai Mai 19 Aug '05

19 Aug '05

Hi, I am wondering if anyone interested in participating in SpikeSource's Open Testing Contest (http://www.spikesource.com/events/opentestingcontest/) I see this is more of an opportunity to bring automated testing coverage to Drupal. I've used SimpleTest to implemented some automated tests for a Drupal module I wrote. SimpleTest is pretty solid in doing unit testings and web-based black-box testing. I went to SpikeSource's headquarter for their test festival where I saw the demo of using phpCoverage(http://www.spikesource.com/projects/phpcoverage/) and SimpleTest on Mambo. It's really cool. It's getting harder and harder to manual test a big and growing system like Drupal. Automated testings may be hard to implement initially. But it gives quick feedback on changes made to a system. Drupal should make use of SpikeSource's Free Project Test service at http://spikesource.com/spikewatch/index.jsp. We can pick which stacks we deploy Drupal and do the testings. I am not affiliated with SpikeSource. I just really like their testing services for open source projects. Thanks. Kai

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by Morbus Iff 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/19934 Post a follow up: http://drupal.org/project/comments/add/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: bwooster47 Updated by: Morbus Iff Status: patch (code needs review) Attachment: http://drupal.org/files/issues/_ports_0.patch (2.25 KB) Grr. Parens in the wrong place. Right patch attached. Morbus Iff Previous comments: ------------------------------------------------------------------------ Sun, 03 Apr 2005 23:07:58 +0000 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-) ------------------------------------------------------------------------ Fri, 08 Apr 2005 07:08:53 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are. ------------------------------------------------------------------------ Fri, 08 Apr 2005 11:16:52 +0000 : Dries Won't commit. Removing the port seems like a bad idea (I could have two drupal sites at two different ports but otherwise identical URLs) and adding regex' all over the map isn't advised. If ":" is an invalid character, then there might be more such characters. I suggest we replace them with '.' and that we document this behavior much like we do with $db_url. ------------------------------------------------------------------------ Mon, 11 Apr 2005 23:25:51 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports_0.patch (1.35 KB) ------------------------------------------------------------------------ Tue, 19 Apr 2005 17:03:46 +0000 : bwooster47 Regarding update #3 - does this mean the code has made it in, and will be available in the next release? Secondly: I follow the logic for the update, and it makes sense for non-standard HTTP port numbers, but not sure if the logic is valid when port 80 is used. For example, http://yourdomain.com/ and http://yourdomain.com:80/ both will go to the exact same page, but looks like the search for the conf.php will be different. Not sure if this matters... ------------------------------------------------------------------------ Mon, 01 Aug 2005 01:23:28 +0000 : killes(a)www.drop.org patch still applies, my testsite kept working (is not on a non-standard port, though). ------------------------------------------------------------------------ Mon, 01 Aug 2005 05:31:56 +0000 : Dries I think the PHPdoc is confusing. The second example URL is non-existing/invalid. Did you meant showing a configuration file? I agree with bwooster that this gets tricky with the default port '80'. Do we need to discuss this some more? ------------------------------------------------------------------------ Sat, 06 Aug 2005 07:20:03 +0000 : Boris Mann I like the period (".") character as the delimiter for ports. If people really do tack on :80, then site admins can symlink domain.com.80 to domain.com (much as you would need to symlink www.domain.com to domain.com as well). I think this is largely a documentation issue. ------------------------------------------------------------------------ Fri, 19 Aug 2005 01:27:39 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_ports.patch (2.25 KB) +1. This patch is absolutely required for my home development, which is behind an ISP that doesn't like webservers on port 80. I've attached a new patch that fixes the doc mistake from the last patch, as well as adds a note to the INSTALL.txt too. I'm with Boris on the :80 issue - if a developer is using it knowingly, he should be smart enough to put 2 and 2 together.

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by Morbus Iff 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/19934 Post a follow up: http://drupal.org/project/comments/add/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: bwooster47 Updated by: Morbus Iff Status: patch (code needs work) Attachment: http://drupal.org/files/issues/_ports.patch (2.25 KB) +1. This patch is absolutely required for my home development, which is behind an ISP that doesn't like webservers on port 80. I've attached a new patch that fixes the doc mistake from the last patch, as well as adds a note to the INSTALL.txt too. I'm with Boris on the :80 issue - if a developer is using it knowingly, he should be smart enough to put 2 and 2 together. Morbus Iff Previous comments: ------------------------------------------------------------------------ Sun, 03 Apr 2005 23:07:58 +0000 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-) ------------------------------------------------------------------------ Fri, 08 Apr 2005 07:08:53 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are. ------------------------------------------------------------------------ Fri, 08 Apr 2005 11:16:52 +0000 : Dries Won't commit. Removing the port seems like a bad idea (I could have two drupal sites at two different ports but otherwise identical URLs) and adding regex' all over the map isn't advised. If ":" is an invalid character, then there might be more such characters. I suggest we replace them with '.' and that we document this behavior much like we do with $db_url. ------------------------------------------------------------------------ Mon, 11 Apr 2005 23:25:51 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports_0.patch (1.35 KB) ------------------------------------------------------------------------ Tue, 19 Apr 2005 17:03:46 +0000 : bwooster47 Regarding update #3 - does this mean the code has made it in, and will be available in the next release? Secondly: I follow the logic for the update, and it makes sense for non-standard HTTP port numbers, but not sure if the logic is valid when port 80 is used. For example, http://yourdomain.com/ and http://yourdomain.com:80/ both will go to the exact same page, but looks like the search for the conf.php will be different. Not sure if this matters... ------------------------------------------------------------------------ Mon, 01 Aug 2005 01:23:28 +0000 : killes(a)www.drop.org patch still applies, my testsite kept working (is not on a non-standard port, though). ------------------------------------------------------------------------ Mon, 01 Aug 2005 05:31:56 +0000 : Dries I think the PHPdoc is confusing. The second example URL is non-existing/invalid. Did you meant showing a configuration file? I agree with bwooster that this gets tricky with the default port '80'. Do we need to discuss this some more? ------------------------------------------------------------------------ Sat, 06 Aug 2005 07:20:03 +0000 : Boris Mann I like the period (".") character as the delimiter for ports. If people really do tack on :80, then site admins can symlink domain.com.80 to domain.com (much as you would need to symlink www.domain.com to domain.com as well). I think this is largely a documentation issue.

1 0