Replacing URLs in databases and serialised PHP

[Forboding Angel]

Malric, frankly you aren't helping. Worse, your information is incorrect

The plugin in question makes it so that moving wordpress around is not an issue.

who should ever read this post? (TL;DR)
why should i do that? i explained my POV what wordpress is doing wrong. to use it for spring, the process of applying changes to the website has to be changed, this is bad.

No, it doesn't. Did you even read his post? What are you even talking about?

who should ever read this post? (TL;DR)

Apparently, you.

@AF, Forb
also keep in mind, you are the experts related to wordpress. if you are unable to solve such isses / find a acceptable solution then i don't see us setting up a wordpress site for springrts.com.

There is no issue. You are making up fake issues for some reason.

Let me try to lay it out for you once and for all...

Test database never gets written to live db (exception being when you first make it live of course). Test db is just that. As AF says, you should be able to trash your test environment at any time.

Therefore pretty much everything you bring up is completely null and void.

Read AF's post.

[malric]

Malric, frankly you aren't helping. Worse, your information is incorrect

Which information is incorrect? My point is that I do not like that there is an (external) plugin to do that operation and I personally prefer a configuration parameter. abma seems to have a similar opinion (although his usage scenario might be different). As someone said "look at other CMS-s" I gave as an example Joomla who does not seem to need any special plugin for changing the domain name.

In case it was not clear, I never discussed the usage of live and test databases. If am am not mistaken this is in Offtopic, and about "replacing urls in databases" and not directly about live and test one.

[AF]

As I said, urls in the database is necessary in numerous situations, and there are advantages. It is not a simple clear cut thing as you suggest it is, and there are tools to automate, mitigate, and remove this.

But I should also point out this thread was created with general wordpress in mind, not wordpress on this specific site. For which I would say there is a distinct lack of a deployment or build process. There are no scripts, no clear documentation, and the closest we have is a git one liner jK mentions in #sy, and a repository with some processes that are being flouted.

These are necessary to simplify things, with or without wordpress. Right now too much of the process is manual with too many interdependencies.

[AF]

I should add that research would also have shown up these:

Code: Select all

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

Including:

Code: Select all

define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );

The home and site URLs are not always the same, and sometimes it's not possible to determine one via the other. For example, example.com/wordpress may be the root of the install, but the home url is not example.com/wordpress, it's example.com, there are plenty of edge cases where it's not possible to reliably detect these things.

Using constants in a multisite environment where a single installation handles multiple websites at different URLs does not scale.

Also keep in mind that this sql query:

Code: Select all

update wp_options set option_value = newexample.com where option_name = siteurl

Is significantly easier to understand, modify, find, and much more portable than:

Code: Select all

sed -i "/WP_HOME/s/'[^']*'/'newexample.com'/2" wp-config.php

The first will run on any WordPress environment, and depends on standard MySQL. The second has difficulties requiring additional tools and slightly different syntax across different platforms, with Windows portability issues.

There is also

Code: Select all

wp search-replace 'http://example.dev' 'http://example.com'

[malric]

Using constants in a multisite environment where a single installation handles multiple websites at different URLs does not scale.

I do not have a multi-site environment. I probably do not have what you call "edge cases". My feeling is that insist that Wordpress way(s) are "better" for every scenario. I am happy that you can do anything with Wordpress.

Even so, I think that you can do all of the above scenarios without storing the absolute URL in the database. (which was the thread topic).

[AF]

You cannot, multisite installations are the prime example, but keep in mind what goes into WP Core by default, has to work by default, for everyone. WordPress is used by a lot of people, and those edge cases carry with them a lot of people, you can't just break a few hundred thousand blogs because it's just an edge case, especially in a project that values backwards compatibility.

I would note that multisite installations are not an edge case, most WordPress websites are running off of them. I seriously doubt WordPress.com could run all those millions of sites off of a giant PHP configuration file, and having one piece of code running everywhere on its own won't tell the machine when you arrive at abc.com 123.com and xyz.com, show the content from jackson5.com, but on moominpapa.com show moomin stories etc..

[malric]

You cannot, multisite installations are the prime example, but keep in mind what goes into WP Core by default, has to work by default, for everyone. WordPress is used by a lot of people, and those edge cases carry with them a lot of people, you can't just break a few hundred thousand blogs because it's just an edge case, especially in a project that values backwards compatibility.

I would note that multisite installations are not an edge case, most WordPress websites are running off of them. I seriously doubt WordPress.com could run all those millions of sites off of a giant PHP configuration file, and having one piece of code running everywhere on its own won't tell the machine when you arrive at abc.com 123.com and xyz.com, show the content from jackson5.com, but on moominpapa.com show moomin stories etc..

Ok, fine. You can't have one variable set somewhere per each site. Everything has to be in the database everywhere. Guess for these multisites, you also put images in databases, encoded as base64 just in case? Also, in next version of Wordpress, by license everyone is allowed to run only multisite installations.</end sarcasm>

Backwards compatibility is a very good reason and I think it is the first time I see it in this thread (although it seemed to me the main reason the lead developer of wordpress was mentioning the situation will stay as it is, in the bug report you linked). I never suggested you should change Wordpress anyhow or switch to something else. I was discussing theoretically about if I feel like the absolute URL should be stored in the database everywhere. I find this storing similar to database de-normalization - which I do not like either. You might love both and be very successful.

I don't want to convince you of anything, so in my opinion both points of view should have been clearly explained by now and I have nothing more to add.