[wp-trac] [WordPress Trac] #17048: urls deliverd to the browser should be root-relative

[WordPress Trac]

#17048: urls deliverd to the browser should be root-relative
--------------------------+------------------------------
 Reporter:  dmole         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------------------

Comment (by dmole):

 Addressing Nacin's concerns:

 >Root-relative URLs aren't really proper. /path/ might not be WordPress,
 it might be outside >of the install. So really it's not much different
 than an absolute URL.
   WordPress already requires you to provide the /path/to/wordpress, the
 difference in omitting the protocal://domain.tld is that WordPress will
 work simultaneously with different domains/IPs and protocols(http/https)
 out of the box. (yes there is already an ugly https rewrite and it breaks
 with caching plugins)


 >Any relative URLs also make it significantly more difficult to perform
 transformations when >the install is moved. The find-replace is going to
 be necessary in most situations, and >having an absolute URL is ironically
 more portable for those reasons.
   All URLs in the DB should be relative to the WordPress root requiring no
 changes on migration.

 >As you said, absolute URLs are needed in numerous other places. Needing
 to add these in >conditionally will add to processing, as well as
 introduce potential bugs (and >incompatibilities with plugins).
   It will actually reduce processing because it will remove the https hack
 for relative urls. additionally we would just call a different function
 for root-relative URLs avoiding the processing hit of an if statement.
 Bugs and incompatibilities should be minimal if plugins were written in a
 robust way, but yes they happen with every change to WordPress.

 >Unfortunately, the opinion of those threads are skewed in the direction
 you mention due to >most of them not really understanding the problem or
 the design decision (nor are most of >them active core contributors or
 core developers). I've tried to cover a bit of the design >decision on wp-
 hackers before, and I've been able to locate this reply of mine (the first
 >part, in particular):
   I agree the lack of knowledge is a problem, I think it would be great if
 there were a website for commonly disputed design decisions. It would save
 us all a lot of time.


 http://lists.automattic.com/pipermail/wp-
 hackers/2010-November/036195.html:
 >In the red corner, WordPress should store relative URLs. Relative to
 what,
 >I'm not sure, as WordPress is often in a subdirectory, which means we'll
 >always need to process the content to then add in the rest of the path.
 This
 >introduces overhead.
   Relative to the WordPress root defined in the UI. The overhead is
 already there and it will likely shrink not grow. (currently we check for
 https and root folder)

 >Keep in mind that there are two types of relative URLs, with and without
 the
 >leading slash. Both have caveats that make this impossible to properly
 >implement.

 >As Peter points out, I'm not even sure how we'd detect URLs we need to
 now
 >append to. A placeholder perhaps? What better placeholder than the domain
 >itself? Were there to be this implemented, it would actually decrease
 >portability of your content, as your content must now go through a
 >non-agnostic filter to actually be useful.
   There is no need for a placeholder you just strip all the domains off on
 upgrade.

 >You can't sacrifice stability for perceived portability. Read that back.
   I can't call a fresh install with no CSS when NATed or used with another
 domain "stable"

 >In the blue corner, WordPress should (and does) store absolute URLs. This
 >requires no pre-processing of content, no overhead, no ambiguity. If you
 >need to relocate, it is a global find-replace in the database.
   you actually currently pre-process https and the WordPress root folder,
 so there would be no performance hit.

 >Really, what you should do, is reverse the deployment process, as Otto
 >suggests. Don't work off http://localhost/example/ then try to deploy to
 >example.com. Rather, have your install believe it is the live
 example.com,
 >then fake it to work on your staging environment. If it breaks on live,
 you
 >have a problem; it it breaks on staging, well, that's not much of a
 problem,
 >is it?
   The problem is if you have 1 live environment with >1 domain/IP/protocol

 >...

 Please provide a specific example if I have missed anything. I agree it
 will be work to implement root-relative URLs, but I also believe WordPress
 will be a more robust product as a result. Thanks for your comment.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17048#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software