Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Latest post by sneadm on Wednesday, 23 August 2023 10:31 CDT
Backed up http://dev.ccbroward.org, restored to ccbroward.msneadfamily.com. Upon restoration, menu section was not displaying correctly.
The first picture is a screen shot from the source site, the second is what came up on the restored site. I have tried it to a local server as well with the same result.
You may PM me for logon credentials.
Mark
This looks like a CSS issue.
Restoring a site will restore exactly was in the database na the filesystem. However, some third party plugins and themes may need to be told to regenerate their CSS or caches. If you are using a caching plugin, it needs to be reconfigured for the new domain name.
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!
As always, very helpful! Found that the -transient-wp-core-block-css-files record in the options table did not update the URLs on restore. Deleted the record and it rebuilt it just fine.
Mark
Hm, this is strange, though. We do replace serialised data and I did just check that it does work. I think it may have been a case of either misclicking something in the data replacement page, or data replacement not running to completion.
At least it was easy to fix for you; delete the transient record from the wp_options table, go back to Themes, customise the theme and the transient is restored. Right?
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!
Replacement did work for everything else, just not this record.
Here are the first couple lines after replacement:
/public_html/wp-includes/blocks/spacer/editor-rtl.css";i:437;s:93:"/home/customer/www/dev.ccbroward.org/public_html/wp-includes/blocks/spacer/editor-rtl.min.css";i:438;s:85:"/home/customer/www/dev.ccbroward.org/public_html/wp-includes/blocks/spacer/editor.css";i:439;s:89:"/home/customer/www/dev.ccbroward.org/public_html/wp-includes/blocks/spacer/editor.min.css";i:440;s:88:"/home/customer/www/dev.ccbroward.org/public_html/wp-includes/blocks/sp
The dev.ccbroward.org should now read localhost/ccbroward.org. When I use bbedit to find and replace all, everything works. Although the paths are not right for localhost files so I suspect it's getting a not found on all of them.
After deleting the transient record however, I can't get it to rebuild but the site seems to be working fine without it.
If you use BBEdit to do replacements you have invalid serialised data since dev.ccbroward.org is 17 characters whereas localhost/ccbroward.org is 23 characters. This means all the character lengths (the s:number entries) in the serialised data are wrong, and WordPress can no longer read that serialised data; trying to deserialise it returns NULL which is effectively the same as deleting the transient record altogether.
In any case, I know why this transient was left intact. What I was checking was non-transient option records. However, we do exclude transients from data replacement. This was not a problem before WP 6.3. I have a very good idea now of what is going on and how to work around this :)
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!
Thanks, didn't really understand the serializing. Any harm in just deleting the record? Everything seems to work fine.
No harm in deleting it. I checked WordPress' code. If it's missing and it needs it, it will create it afresh.
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!
Great! Thanks for the info. I'll consider this ticket closed.
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!