Support

Site Restoration

#31175 Renaming of WP Database entries on restoration to new URL

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by sneadm on Monday, 01 April 2019 08:15 CDT

Sunday, 31 March 2019 11:00 CDT

sneadm
After restoration, in the last step of the installer is the script to change URL's in core tables and selected others. I selected all. There were two things not changed:
1) In wp-posts, the UID fields were not changed from http://old.url to http://new.url
2) Also in wp-posts, some URLS were in the form of http:%2F%2Fold.url%2F and were not changed by your script.

It wasn't hard to run the needed SQL in phpmyadmin but I thought I'd let you know.

Monday, 01 April 2019 01:26 CDT

nicholas
1. This is on purpose. It is a very long discussion which I will try to sum up. The UID field is supposed to contain a "unique identifier". This is used in RSS and Atom feeds so the reader software knows to NOT include articles it has already seen. WordPress completely misunderstands the specification and uses the URL of the post as a unique identifier. THIS IS WRONG. However, we MUST not change it because that causes SEO issues on the restored site. In fact, we used to change that and we received complaints from people. That's why it's not replaced anymore.

What should have WordPress done? They should have used a UUID instead of a URL in that field. I am told there are third party plugins which do that but I've used none of them so I can't recommend any.

2. You can address it at restoration time by adding a rule with FROM set to http:%2F%2Fold.url%2F and TO set to http:%2F%2Fnew.url%2F. It would help me plenty to know which plugins caused records like this. I want to double check they should be replaced before adding these as default replacements in the restoration script. I have had really bad experiences with the crazy things some plugin developers do with data in the database :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 01 April 2019 08:15 CDT

sneadm
Nicholas,
Thank-you, I was not aware of the SEO implications. Since the original value was my localhost development environment, I don't think I'll have any issues. For the URL format, I had already run the SQL so that was taken care of. It looks like the offending plugin is CMS Button from the CMSSuperHeroes plugins, maybe in some of their others too.

I'll consider this closed.

Thanks again,
Mark

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!