[wp-trac] [WordPress Trac] #17048: urls deliverd to the browser should be root-relative
WordPress Trac
wp-trac at lists.automattic.com
Tue Apr 5 13:32:50 UTC 2011
#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
More information about the wp-trac
mailing list