Opened 9 years ago
Last modified 6 years ago
#32639 new feature request
A URL Agnostic Wordpress
Reported by: | mattfiocca | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | 2nd-opinion |
Focuses: | Cc: |
Description
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 :)
Change History (6)
#3
@
9 years ago
- Keywords 2nd-opinion added
- Type changed from enhancement to feature request
- Version 4.3 deleted
#4
follow-up:
↓ 5
@
9 years ago
@SergeyBiryukov , thanks for sharing that design decision link. I think each of the points made there could be addressed in my feature request though:
RSS Readers: the application would still display absolute urls, they just wouldn't be stored in the DB absolutely. Its my understanding that RSS endpoints aren't pulling content directly from the database, but are rendering an xml template. In this RSS template, you would use permalink and site_url() functions for a resource, and these functions could return the domain, blog root (/blog, if set that way for example), and the relative URI from the database concatenated together to form the absolute URL.
Permalinks: The root-relative issue would be addressed with the introduction of the BLOG_ROOT config constant (or even an entry in the wp_options table).
Moving sites: You would only need to revise the BLOG_ROOT config, if it was previously set to "/dev", it would just become "", and the site would continue to display the correct absolute URLs, built dynamically from the new conditions.
#5
in reply to:
↑ 4
@
9 years ago
Replying to mattfiocca:
Moving sites: You would only need to revise the BLOG_ROOT config, if it was previously set to "/dev", it would just become "", and the site would continue to display the correct absolute URLs, built dynamically from the new conditions.
It might be not that simple in practice:
- How do we migrate the existing content?
- What should be done with plugins and themes that still store absolute URLs?
Adding a constant would not cover all the cases, it would just add one more step to the existing migration process.
Previously: #17048
See also https://make.wordpress.org/core/handbook/design-decisions/#absolute-versus-relative-urls.