All settings lost when migrating database to another domain

  • Resolved fiskhandlarn

    (@fiskhandlarn)


    6 years, 9 months ago

    If I set the Social Image Fallback URL to an image in the media library, the absolute URL for that image is saved to the database instead of just saving the media ID. The autodescription-site-settings is then saved as a serialized object in the database. If I set the social image on my local server and then migrate the database (by replacing my local domain with the remote server domain in the database dump) the whole settings array will fail to unserialize on the remote server if the two domain names are of different lengths.

    I kind of understand the need for setting a social image by writing a custom URL, but wouldn’t it be better to not use social_image_fb_url at all if social_image_fb_id is set?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter fiskhandlarn

    (@fiskhandlarn)

    Right now, if I keep the value for social_image_fb_url intact in the database dump, the remote server will still output social_image_fb_url (with my local domain) as the og:image url instead of using the url derived (with wp_get_attachment_url for example) from social_image_fb_id. The only way to migrate and keep all settings and get the correct og:image is to change \"social_image_fb_url\";s:68 to another string length.

    • This reply was modified 6 years, 9 months ago by fiskhandlarn.
    Plugin Author Sybre Waaijer

    (@cybr)

    Hi @fiskhandlarn,

    I understand your frustration with the failed transfer.

    However, please note that when manually transferring the domain names in the database, serialized fields are bound to break. If you’ve used a third party tool, it should’ve interpreted the fields (via is_serialized() or equiv.) and rewrote them correctly, even more so when it’s built specifically for WordPress. This could’ve (should’ve) prevented the string-length incompatibilities you’ve experienced.

    TSF handles its plugin data via WordPress’ Options and Meta API. It is common practice that these fields are serialized. The API functionality WordPress delivers have various redundancy checks for this. In fact, WordPress serialized the option fields automatically, not TSF. Therefore, this is out of my hands, because any other field could potentially cause this issue, too.

    Onward to your suggestion, TSF stores both the ID and URL for various reasons. First, the user can input an image address without entering an ID. Secondly, it adds multidomain and (pending) CORS support–WordPress Multisite installations that were set up prior to WP v4.7 require this functionality. There are more reasons, but it’s already becoming very technical.
    To make a long story short, I’m not going to change this behavior, as the benefits and stable operation far outweigh this (preventable) corner-case.

    Now, I recommend retransferring the SEO settings, but without applying the domain transformation. Then, you can manually change and correct the fields.

    I hope this provided enough insights. If you still have any doubts, feel free to follow up. Cheers ??

    Thread Starter fiskhandlarn

    (@fiskhandlarn)

    Thanks for the thorough and quick answer! I now understand that there are more complications for changing this behaviour than I first thought. I will try a migration helper plugin instead of my homebrewn regexp script.

    • This reply was modified 6 years, 9 months ago by fiskhandlarn.
Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘All settings lost when migrating database to another domain’ is closed to new replies.