WordPress.org

1. henningsprang
   Member
   Posted 4 months ago #

   I'm running a development system of our multisite Blog with about 10 Blogs on different hostnames (for the main blog as well for the instance, we use Domain Mapping).

   I'm switching hostnames in the production database dump before importing it into the (empty) development database, and the sites are accessible with the development hostnames.

   My problem is, recently, the widget settings are not correct on the development system anymore after importing data from production again.
   Site is shown perfect, also with the right Theme, but some settings seem just to be lost.

   Any idea what the reason could be for this?

2. Ipstenu
   Half-Elf Support Rogue & Mod
   Posted 4 months ago #

   Data serialization.

   If your OLD domain and new domain aren't the same length, widget data can get lost because it keeps track of the domain name in the data storage.

   Blanket search/replace is bad because of that.

3. henningsprang
   Member
   Posted 4 months ago #

   Thanks for your reply!

   Yes, the domain names have different lengths. I'm doing a simple replacement of domain names directly in the SQL dump file with sed befor importing into the development instance. And that works well for all other things. Contents are shown correctly, just widget settings seem wrong - and even those not all.

   So, you're saying, widget settings are not retrieved from the system simply by hostname, as content is, but some other way, if I get it right.

   Is there any "proper" way to get what I want - a domain name migration, or a complete import of all content and settings including widget settings from the live site to a development copy?

4. Ipstenu
   Half-Elf Support Rogue & Mod
   Posted 4 months ago #

   So, you're saying, widget settings are not retrieved from the system simply by hostname, as content is, but some other way, if I get it right.

   No, what I'm saying is that your domain name is stored in the data encapsulation of widgets, and when that gets changed, the widgets barf.

   The 'proper' way, the way we all cheat, is to either get a URL exactly the same length, or use hosts files to 'fake' a domain. Like I have ipstenu.loc on my local computer and I can search/replace domain names that way :)

5. henningsprang
   Member
   Posted 4 months ago #

   Thanks for your reply, I guess we mean the same, I'm just looking from the other end and my description is heavily oversimplified, as I admit ;)

   Unfortunately, these ways are not well suited for our environment - changing hosts files is not easy for people with Mac's or Windows in our corporate environment, and also changing development names to match a specific length sounds ugly and won't work with all names.
   Another hack that might work is to use a proxy with a faked hosts file.

   We gonna see what we will do, maybe digging deeper into the code to find out in detail how widget settings work. Even though there's something coded at a deeper level, there must also be a way to change/trick this. At least I hope so...

6. Ipstenu
   Half-Elf Support Rogue & Mod
   Posted 4 months ago #

   changing hosts files is not easy for people with Mac's or Windows in our corporate environment

   Alas, changing ANYTHING in a corp environment is a PITA, yeah. I would consider a DNS alias then. You should be able to use that...

   However, if you can't, you can STILL change the URLs in your database, but you can't change them ALL on a blanket search replace.

   Yes, search/replace all the wp_x_posts tables. But MANUALLY review the wp_options, and wp_sites wp_blogs and wp_sitemeta. If you see something like {s:12:http://ddsadas.com), DO NOT change it.

7. henningsprang
   Member
   Posted 4 months ago #

   Thanks!

   I'm going to figure how I'll get this done.
   Either I have to use an intelligent regex to leave these untouched when running sed over a full live db dump, or something else.

8. Ipstenu
   Half-Elf Support Rogue & Mod
   Posted 4 months ago #

   I actually JUST wrote this up: http://tech.ipstenu.org/2012/moving-wordpress-multisite/

   There's a link iun the comments to a plugin that may help :)

9. henningsprang
   Member
   Posted 3 months ago #

   As I needed a solution that is scriptable and does not require using the web GUI or anything like "got through tables manually" because I want to be able to import live data continuously, easily fast, I wrote a shell script that works well for me.

   Turned out to be much simpler than it looked in the end. Obviously, even though the hostname is contained in many serialized arrays, there seems to be no need to replace all these occurences.
   If that need would arise, I'd go to rewrite this script in php and do an unserialize - replace hostname - serialize - save action for each of them.

   DB_BASE_COMMAND="mysql -h $DB_HOST -u $DB_USER $DB_PASSARG $DB_NAME -e"
   
   # set password to testtesttest to prevent confusion with the live system login!
   $DB_BASE_COMMAND 'UPDATE wp_mu_users set user_pass="$P$BShSdURpZajVRVrWIX5i/PX/MB24H1.";'
   
   $DB_BASE_COMMAND "UPDATE wp_mu_site set domain = '$HOSTNAME' where id = 1;"
   $DB_BASE_COMMAND "UPDATE wp_mu_blogs set domain = '$HOSTNAME';"
   
   $DB_BASE_COMMAND "UPDATE wp_mu_options SET option_value = 'http://$HOSTNAME' WHERE option_name = 'home' OR option_name = 'siteurl' ;"
   
   BLOG_IDS=<code>$DB_BASE_COMMAND 'select blog_id from wp_mu_blogs where blog_id!=1 \G;' | grep blog_id | cut -f 2 -d\</code>
   
   for blog in $BLOG_IDS; do
           BLOG_PATH=<code>$DB_BASE_COMMAND "select path from wp_mu_blogs where blog_id=${blog}\G;" | grep path  | cut -f 2 -d \</code>
           #echo $BLOG_PATH
           $DB_BASE_COMMAND "UPDATE wp_mu_${blog}_options SET option_value = 'http://${HOSTNAME}${BLOG_PATH}' WHERE option_name = 'home' OR option_name = 'siteurl';"
   done
   
   # turn off domain mapping
   $DB_BASE_COMMAND 'UPDATE wp_mu_domain_mapping set active = 0;'

Reply

You must log in to post.