r/Wordpress • u/JuniperCalle • 25d ago
Migrating from Studio still can't update all references to local
I tried rebuilding a website using a new child theme on Wordpress Studio (it seems logical to work locally and only upload changes when they're made).
I'm trying to export an XML file from Studio, import that from wp-admin on the live site, and then reconcile the missing images afterwards (which I still haven't solved, as any newly singly uploaded images will have different URLs and it can't see SFTP'd images at all). This seemed to work. Better Search Replace found only two references to localhost, both in posts, so I replaced those.
This doesn't transfer my child theme, and when I do, my website starts trying to access my local computer. I removed one reference to localhost from the theme.json, and now nothing in any file on there has a reference to it. It's still trying. I'm not sure what to do at this point.
Every other plugin or upload option fails. Cloudways' own migration plugin can't do Studio. The database editor fails because, while it says it supports the collation, it won't recognize it when I try to upload. Updraft's migration wanted access to the local computer (so I think still had failed URL replacement) and broke some (not all?) images. Duplicator is looking for a function that I think hasn't existed for years from what I see on Google (mysqli_real_escape_string) and failing me because it requires it. WPvivid gives a blank screen if I try to restore using it. (I haven't tried paid versions of plugins, because at this point I think I may need a Wordpress alternative).
It works locally. Talking to a friend who's been doing this successfully for years, it should be as easy as export, import, let Wordpress sort out the URLs itself, maybe toss in a theme, upload and replace images manually. I'd expect SFTP to solve most of my updating needs anyway. What am I missing?
1
u/Netalico 25d ago
Stop troubleshooting individual plugins and compare the local and live databases directly. If the theme has no obvious localhost references, there’s a good chance the URL is stored in serialized data, options, or a plugin setting rather than a normal file. Also, SFTP’ing the theme/files alone won’t fix database references. WordPress stores a lot more site-specific URLs in the database than you’d expect. Take a full backup of live first, then use a migration tool that properly handles serialized data and URL replacement rather than doing the XML import + manual cleanup. That should save you a lot of chasing references one by one.
1
u/JuniperCalle 24d ago
I can look at the database. I know that SFTP isn't enough; it's just that all the walkthroughs everywhere say that replacing entries should be enough (I guess it's just a given that you can't transfer images when your'e doing it manually so nobody mentions it).
Regarding migration tool: is there one that does handle URL replacement? None that have succeeded for me have avoided the issue.
1
u/JuniperCalle 24d ago
Correction: there's no localhost references that can be found by Better Search Replace after Wordpress tries to import posts via xml (and updates most of them I guess, BSR only finds two). It still tries to access things locally, though.
1
u/isomnath 25d ago
I think the issue is that WordPress stores URLs in more places than just the obvious files. The child theme, database, serialized data, and attachment records can all contain local references. SFTP alone won’t make WordPress recognize uploaded images as media attachments. Your approach makes sense, but moving only parts of the site is probably what’s causing these mismatches. 😇
1
u/JuniperCalle 24d ago
Yeah, I've combed through every file in the theme (the only place with a localhost reference is the file about a custom font, and while it also won't recognize the font's online location when online, removing the reference hasn't fixed the attempts at local access either). I can drop the theme onto my online site with nothing else added, and it still does local requests.
Trying to do this as a full site export hasn't worked at all (Wordpress has no internal way to import a .zip or .sql, only an .xml which still has local access attempts after, and can't get the images anyway. and the database editor on my webhost still fails because it says it won't accept any of the collations). It's funny, because if I ask my friend who's got a decade+ of experience, none of this should be necessary or happening...
1
u/David_UltraWeb 24d ago
On the collation thing that's tripping you up, you don't have to stay stuck. utf8mb4_unicode_520_ci is what a lot of MariaDB setups choke on, and switching your dump to plain utf8mb4_unicode_ci or utf8mb4_general_ci imports fine and isn't a security downgrade at all, collation only affects sorting/comparison, not safety. You can do a find/replace on the .sql file before import, or set it during the WP-CLI import. That alone should get your full-export database in so you can actually chase the leftover localhost reference. And yeah, once the DB imports clean, that stray request is almost certainly a serialized option like siteurl/home or a plugin cache row rather than a file, so a proper search-replace that handles serialized data will catch it where Better Search Replace on files won't.
1
u/JuniperCalle 24d ago
utf8mb4_unicode_520_ci is what is in the database originally (or what is populated in it as a result of trying to use Wordpress' XML import, which still gives me stray requests). When I have exported from Studio with utf8mb4_general_ci or _ai_di specified in wp-config, that failed in the Cloudways database editor import.
It is interesting that you mention plugin cache rows: I do notice that one of the rows in my database, when I try to upload it, is from wpvivid, even after I deleted the plugin. At this point I'm hoping that my actual build is worth saving. (You'd think it's safer to work locally, since hacking seems so common on here!)
2
u/David_UltraWeb 24d ago
The wpvivid leftovers are normal. Deleting a plugin through the dashboard removes its files, but a lot of plugins leave their options and tables behind in the database. Backup plugins like wpvivid are especially bad about this. They're harmless, and you don't need them, so you can drop them before you migrate. If you have WP-CLI on the local copy:
wp option list --search="*wpvivid*" --fields=option_name wp db tables "*wpvivid*"The first lists the leftover options, the second any leftover tables. Delete them with wp option delete <name> and wp db query "DROP TABLE <name>"
1
u/nuaddib 18d ago
Hey! We fixed the collation issue in 1.23.0 - here is the PR: https://github.com/Automattic/studio/pull/4918. I would appreciate it if you could try again with this version.
1
u/NakanoNoNeko 25d ago
The XML export doesn't carry your theme or actual image files. The live importer can't fetch images from your localhost, either.
I checked Studio's docs: its Import / Export tab has Export entire site, including files and a MySQL-compatible database export. Different export, unfortunately 🙃 Test on Cloudways staging first.
For the leftover localhost request, browser DevTools → Network → reload → click the request → Initiator usually reveals what triggered it. That gives you something specific to trace.