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

WordPress Trac wp-trac at lists.automattic.com
Thu Oct 27 21:49:36 UTC 2011


#17048: URLs delivered to the browser should be root-relative
-----------------------------+-------------------------
 Reporter:  dmole            |       Owner:  edwardw
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:  3.1
 Severity:  normal           |  Resolution:  maybelater
 Keywords:  close            |
-----------------------------+-------------------------

Comment (by MarcusPope):

 @SergeyBiryukov - any chance that ticket (my patch) will make it into 3.3?

 For the rest of you:

 Since it was referenced here I figure I'll add my $.02.  This problem is
 laughable in the development circles I work in.  The idea that Wordpress
 core members don't see the value of root-relative URLs or the pitfalls of
 absolute URLs literally makes people laugh when I tell them.  Mostly
 because this is a problem that was solved in enterprise web development
 platforms well over a decade ago.

 However, to cheer up those who desire this functionality I just wanted to
 inform you that I have solved the problem via a plugin and wp-config.php
 change for vanilla installs.  It has been tested and we currently use it
 on a couple of production sites.  If #18910 is ever reviewed and added to
 the core, it will work for MU path-based installs too.  Subdomain based MU
 sites are screwed because of the severe lack of judgement on WP's part,
 but I will aim to solve that too with a complete fork of 3.3 when it's
 released.

 To the core members who suggest things like output buffering and defining
 WP_HOME/SITEURL - those hacks make the problem even worse.  Try them out
 and run a packet sniffer while you do so to see what I'm referring to.
 Additionally try using the site from both urls at the same time over a
 couple of weeks and watch your content become a mish-mash of various URLs
 that result in 404s and a broken user experience.  You obviously don't
 understand the problem if you think these solutions are viable in a
 production environment.  And you have obviously never tried to login to
 the admin section if you think output buffering is all you need (ahem
 @nacin)

 In reality this plugin requires hooking into 20 different hooks and doing
 an unecessarily excessive amount of transformations on urls (and really
 the core does an unecessarily excessive amount of transformations on urls
 without this plugin - aka HTTP/HTTPS.)  I'm not sure how well it would
 scale for larger sites (thousands of pages or more than 50 plugins,) but
 it's at least a viable option for now where as before there was not one.

 In addition to publishing this plugin very soon (probably tomorrow if not
 tonight) I'm also in the process of writing a full synopsis on this
 problem and the viewpoints of everyone involved.  It will include some
 criticism on the WP core team members for outright ignoring completely
 valid points made by the community.  Additionally it covers topics yet to
 be discussed, like being unable to test development changes from an iPhone
 or other mobile device in a local-only staging environment without network
 level NAT configuration (something that isn't very common on most WIFI
 routers.)

 Ultimately a "design decision" can also be a "bad design decision" that
 needs to be changed. And in this case you should listen a little more to
 your community.

 http://wordpress.org/extend/plugins/root-relative-urls/

 I'm wrapping up the readme docs today and will publish it by tomorrow at
 the latest.

 -Marcus

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


More information about the wp-trac mailing list