TDP'sGM

Thanks for that Mika. Per chance, is there a Guide as to how to go about that? I could probably figure it out, but I’d rather not reinvent the wheel if there is someone who has already compiled a nice step by step “How to”. Why miss something if I don’t have to, right?

Again, thanks for the help.

To be clear, I can export a site that is part of a Multi-site installation (files & Database content) and import it back into a NON-multi site installation (and Vise Versa)?

I ask as there are certain settings that are not the same.
For example, in a NON-Multisite installation we have this option under “Settings>Media”:

>>>Organize my uploads into month- and year-based folders

That option is NOT available in the Multi-Site setup.

If that was unchecked in a NON-multisite setup and imported into a Multisite setup, would there be a conflict?

Is there a good step by step tutorial on how we’d do this if I wanted to?

Thanks

@marventus: Sorry – you posted while I was typing and testing.

Sounds like we’ve come to the same conclusion basically.

Thanks everyone for weighing in here.

What I have got out of this is that as long as the plugin comes from the “WP plugin and theme directories”, we shouldn’t have to worry much about Data being in Serialized Arrays.

. . . well this is interesting: Just for the fun of it I used the SQL commands suggested in this post here to make the changes. All total it affected 35 Rows ===> Rows don’t seem to be the issue here and I don’t think are very relevant.

I then exported the database and opened it in Notepad++ and did a search for the ‘newURL.com’ (without the single quotes).

That method found 52 of them.

I then searched for the oldURL.com and it found 6 more that the SQL commands didn’t change.

Probably because they were not in a table that I told it to go to – I am not sure which table it was but it looks like a couple of them have something to do with the “Dashboard”. Nothing to serious.

My original method of just opening the original exported database file changed a total of 58 occurrences.

I don’t know if this little test is very scientific or not, but my method sure is super simple, hard to screw up, and, though I realize we have already discussed that it is not really that important, at first blush seems to catch every instance there is of the ‘oldURL.com’.

Hopefully I’m not offending any SQL purists out there, but isn’t easier better if it is doing the same job?

Maybe someone could try it with a more complex DB and tell me how it all works.

Thanks Marventus. That certainly helps clear a few things up.

This does bring me full circle back to my original post.

What I wanted to know is if following this procedure is incorrect for some reason:

1. Export the database using phpMyAdmin
2. Open the *.sql file in notepad++
3. Find and replace ‘myOLDurl.com’ with ‘myNEWurl.com’ (without single quotes)
4. Save and close file.
5. Import changed file back to myNEWurl.com’s database

Question 1:
What am I risking by doing it this way?

I know you said that:

Since URLs have special characters that will get escaped upon saving settings to the database, . . . .

I very well could be wrong, but I didn’t think that there were any characters that get escaped in a url ( assuming you don’t add the ==> https:// )
I understood that some areas the https:// gets recorded, and others not. Some areas have the trailing forward slash, and others not.

If I just use the URL ONLY this solves all those problems.

I realize that you have given me the SQL commands in this post here but my way seemed so much simpler – which is why I started this thread. It seems to cover everything.

Yes it does. Thank You. I think the key here is:

if the plugins and themes you are using follow WP coding practices and standards

I am not sure how one would know that.
Could you help me with that?
How would I know?

Obviously some people have run into this:
https://wpgarage.com/tips/data-portability-and-data-serialization-in-wordpress/

. . . enough so that Christine posted a script to solve the problem HERE

@marventus (et al):

I am reposting the link that esmi submitted earlier regarding the serialized arrays:
https://wpgarage.com/tips/data-portability-and-data-serialization-in-wordpress/

@christine: Thanks for the link. Can this be used on ANY database, or do you have to KNOW which tables contain data in a Serial Array?

@marventus: Thanks for the response. I am a little confused. You mentioned:

. . . 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.

Then what’s the purpose of running this script that Christine has offered ( https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) as an option to deal with that data and a change in site URL?

Maybe I missed the point. Could you help me here?

This still doesn’t really leave me with a clear answer on this:

#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?

Thanks

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.

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.

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?

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.

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.

Hi Mikko,
I just wanted to let you and anyone else know that there apparently is a conflict between the Premium Plugin “Views” from the “Types and Views” website located here: https://wp-types.com/

The only way that I could get Relevanssi to complete the indexing was to Deactivate the “Views” Plugin.

I’d run the index, and then reactivate the “Views” plugin and then everything was ok.

I don’t know if you want to talk to them and see if you can’t sort out the issue there. I’ll post it on their forum as well and maybe you folks can connect on a solution.

I am currently trying to trouble shoot an issue with the “views” plugin, but I don’t think that Relevanssi was the issue – though I am not 100% sure. I will deactivate it for the moment while I try and figure it out.

Hope this helps others.

Types creates custom fields. Is it possible to have Relevanssi index these fields as well . . . assuming we can get the views conflict resolved?

Every time I change a page in the admin section of wordpress I get this message at the top of the page:

Relevanssi needs attention: Remember to build the index (you can do it at the settings page), otherwise searching won’t work.

I am trying to do that.

I have reduced the add documents to 30
And reduced the basic options limit to 5 (although I believe that that is for search results.
No Joy.

Let me know if I can dig up anymore info that might help solve this.