[wp-trac] [WordPress Trac] #32639: A URL Agnostic Wordpress
WordPress Trac
noreply at wordpress.org
Sat Jun 13 20:34:33 UTC 2015
#32639: A URL Agnostic Wordpress
-------------------------+-----------------------------
Reporter: mattfiocca | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: trunk
Severity: normal | Keywords:
Focuses: |
-------------------------+-----------------------------
My apologies if this has been discussed before. I've tried digging, but
couldn't find a discussion about this.
I'm curious why Wordpress has to store the domain (site_url) in the
database, and why absolute URLs are used and stored in the DB? It just
makes migrations really messy for large DBs, from one domain to another.
Plus, in spirit of Wordpress being stateless, wouldn't it be nice just to
be able to pick up and move a site from one server to another, on another
domain without requiring some regex db scrapping migration plugin?
To me, the database should only care about things specific to the
Wordpress blog content itself, and I think that link/url building should
be happening at runtime within the application. Purely my opinion.
I imagine this could be accomplished by using the request headers to
determine what domain your on when using functions like `site_url()`. For
sites that are not rooted at /, but at locations like /blog, we could
leverage the config file for a constant like `define('BLOG_ROOT','/blog')`
or something along those lines, that could be appended to the domain found
in the request, and together prepended to the relative resource url at
runtime. I would vote to keep the `WP_HOME` and `WP_SITEURL` constants, so
that if they are present, those values are used instead. But, why store
that stuff in the DB when links can be built at runtime? It would also cut
down on DB queries.
A use case for this would be at the PaaS level, where a hosting provider
could offer managed Wordpress hosting. when a client spins up a new
Wordpress site, the provider could put that site at a temporary domain
like clientid.hosting.com. As the customer builds their site, nothing
about that temporary domain is being saved in the DB. Once the customer
finally obtains their own domain name, and points to their account with
the hosting provider, absolutely nothing should have to change in the
customer's database, and the hosting provider shouldn't have to mangle the
customer's config file on the server. The site should just be allowed to
behave like an application that is listening for requests, and serving
content, regardless of domain.
Like I said, this might have been discussed at length before, and there
might be pitfalls that i'm just not recognizing, I just wanted to submit
this request to the community to see what kind of discussion this would
produce.
Thanks all. Go easy on me if this was a dumb idea to present :)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/32639>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list