Changing URL via Database edit

They would all need to be changed. Why not use the functions.php method? It’s far easier.

Thanks for the comment esmi – I was just trying to understand the process from the perspective of database manipulation. It seems odd to me that the codex wouldn’t SAY that it needs to be changed everywhere (at least that is how I read it). Is there something else going on in the background that IS taking care of all those references?

(the references are usually to an image that has its location defined using and absolute file path rather than a relative file path)

On a side note, with regards to the functions.php method, why would you have to reload the page several times?
How would you know if you’ve reloaded it enough times?
Yes it seems easy, though a little less precise. No?

Step 4 of the 1.2 Edit functions.php method says:

4. Load the login or admin page a couple of times. The site should come back up.

A couple of times? As in 2 exactly? Why 2? Why not more?
It just seems a little loose to me.

. . . where as mine is exact. Just curious.

Is there something else going on in the background that IS taking care of all those references?

Quite a lot of the url references in the database are stored in serialized arrays. That’s why the Codex recommends using a plugin to handle site url changes sometimes – such as after a site move. Trying to manipulate serialized arrays manually can be very difficult and time consuming.

hmmmm, now this is getting just a little beyond what I currently know.

Question 1:
Is a ‘Serialized array’ something that a “Find & Replace” can’t pick up when editing a *.sql file?

Question 2:
Does changing the site URL in this method (1.4 Changing the URL directly in the database) solve the ‘Serialized array problem?

Question 3:
Doesn’t using my method not already change THAT options table field; and if the answer to question 2 is ‘Yes’ then by default is my method still safe?

Question 4:
With regards to the 1.2 Edit functions.php method Why do we have to load the page a couple of times and not just once? Is this to make sure that we are not looking at a cached page of some sort?

I really appreciate your help on this esmi.
Hopefully I am not being to difficult. I am just trying to learn a little more about how this all works.

Your comment on serialized arrays I’d have never known about if you hadn’t mentioned it.

Thanks for the help.

Is a ‘Serialized array’ something that a “Find & Replace” can’t pick up when editing a *.sql file?

Yes. A serialized array looks something like a:2:{i:0;b:0;s:8:"auto_add";a:0:{}} (that’s actually an array for nav_menu_options). As you can see, there’s nothing in plain text that refers to a url but some plugins may store their data (including site urls) in such an array.

Have a look at https://wpgarage.com/tips/data-portability-and-data-serialization-in-wordpress/ Its the best explanation of how serialized arrays work ( that I know of). In essence, such an array not only stores a url but also stores the number of characters in that url – which is part of what makes them so problematic to change manually.

Does changing the site URL in this method (1.4 Changing the URL directly in the database) solve the ‘Serialized array problem?

Ummm…. on balance – no, I don’t think so. The site should work OK but some theme or plugin options may not work correctly.

Is this to make sure that we are not looking at a cached page of some sort?

I would guess so, yes. Personally, I’ve never had a problem with loading the page just once but then my browsers are all configured to never use cached pages. ??

re:

Does changing the site URL in this method (1.4 Changing the URL directly in the database) solve the ‘Serialized array problem?

Ummm…. on balance – no, I don’t think so. The site should work OK but some theme or plugin options may not work correctly.

#1
If it doesn’t address the ‘Serialized array problem’ then isn’t it a BAD thing to suggest 1.4 Changing the URL directly in the database as an option?

#2
Does the 1.2 Edit functions.php method update all instances of the ‘myOLDurl.com’ and replace them with the ”myNEWurl.com’ URL references (serialized or not) within the database?

#1: I’d need to discuss that will some of the other forums mods & regulars. It’s not a method I’ve ever used myself, so I have no direct experience to go on.

#2: I’ve not come across an issue with this method & I have used it a few times.

Please do, as I’d be very interested to know what is the ‘SAFEST’ way to proceed regarding the serialization issue.

From the link you provided ( https://wpgarage.com/tips/data-portability-and-data-serialization-in-wordpress/ ) the WP Migrate DB Plugin looks to be the most promising and simple to use option for dealing with serialization of data & the migration issue.

I look forward to hearing if the above 2 methods are safe with regards to Serialization.

I’ve not used that plugin myself, so I couldn’t comment it. I’ll ask some of the other forum regulars to weigh in on this topic generally to give you a more balanced view.

I haven’t used the plugin mentioned either, but I’ve used this script – https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

What I do is transfer my db to the new server
transfer all my wp-content files.
run the script
then delete the file right away.

It takes care of everything and I haven’t had a single issue.

@christine: I’d spotted that script previously and wondered how good it was! Thanks for confirming that it works (bookmarking it now).

Hello, everyone. I saw esmi’s call for help and I thought I could weigh in.
Since URLs have special characters that will get escaped upon saving settings to the database, the way I would do my search and replace is through an SQL query, so the reviewed steps in this case would be:
1. Export the database using phpMyAdmin (with “Drop Table” option enabled).
2. Import the Db dump of my oldURL to my myNEWurl.com’s database.
3. Find and replace ‘myOLDurl.com’ with ‘myNEWurl.com with an SQL query inside phpMyAdmin.
Here’s a query that I use to export my live Db into my local one:

UPDATE wp_options SET option_value = replace(option_value, 'https://oldURL.com', 'https://newURL.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'https://oldURL.com','https://newURL.com');
UPDATE wp_posts SET post_content = replace(post_content, 'https://oldURL.com', 'https://newURL.com');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'https://oldURL.com', 'https://newURL.com');

I hope this helps!

@esmi – That script is my best friend ??

But to come back to the topic at hand, most of the time you don’t need to change all instances of the new domain name!

You MUST change the home and site URL in wp_options.

You MUST change the interpost links in the post_content field for wp_posts

The rest? You can totally leave alone.

This is all good stuff, and I have a couple of questions. Regarding my earlier inquiry (modified ever so slightly):

#1
If 1.4 Changing the URL directly doesn’t address the ‘Serialized array problem’ then isn’t it a BAD thing to suggest “1.4 Changing the URL directly” in the database as an option? Or DOES it address Serialization?

#2
Does the 1.2 Edit functions.php method update all instances of the ‘myOLDurl.com’ and replace them with the ”myNEWurl.com’ URL references (serialized or not) within the database?

I am getting the impression that these methods DO NOT handle the required changes that get stored in a serialized array. Is that correct?

Out of curiosity, how would one know if any of your data WAS stored that way? I don’t ever recall plug-in developer stating that they did or didn’t use that method, but it is sounding like it should be a mandatory piece of info that should be included in any plug-ins description considering the implications here.

Hello again. My method would not work for serialized arrays, Christine’s script on the other hand would.
That being said, in the case of site and home url values (which is what you seemed to be asking about), there should be no need for plugins and themes to store that information again inside a serialized array, since the info can be accessed as a regular (non-serialized) string via default WP options.
I hope that makes sense.