Image Issue after Cloning

We’re running into an issue with our WordPress setup when working across multiple servers. We use NS Cloner to duplicate sites from our development server to production. These sites are built with Oxygen Builder , and many of the pages use background images. After cloning and moving the site to production, we’ve noticed that the background images from the duplicated site often disappear when we try to edit the pages. The regular images may be fine, but the backgrounds specifically are missing. We’re not sure if this is being caused by the cloning process, something in Oxygen Builder, or an issue with how the image URLs are handled. Our suspicion is that the blog ID or database references for the images aren’t being updated properly during the clone, so the URLs to the background images don’t change to match the production server. At this point, we’re looking for a solution or best practice to ensure that background images remain intact after cloning so that we can edit without having to manually re-add them each time. We experienced the same issue (continue to, actually), and support seemed to think it might be related to us hosting on WPEngine — any chance you’re hosting there? In any case, our issue seemed to be that the images weren’t picking up the new domain name after cloning, and support had some ideas in our original thread: https://wordpress.org/support/topic/weirdness-with-empty-site-url-when-cloning/ Hi @grex22 Thank you for your help, but we are hosted on DigitalOcean servers, not WPengine. Hi @amplispot , It sounds like you’re seeing a classic “URL + cache” mismatch after cloning Oxygen sites. Backgrounds in Oxygen are often stored inside builder data (JSON/shortcodes) and CSS caches—not just as normal image attachments. If the old domain (dev) still lurks anywhere in that data, or the Oxygen CSS cache wasn’t rebuilt, backgrounds disappear in the editor. Here’s the solution I recommend (in order): 1) Clone with serialized-safe URL replacement ON NS Cloner already does smart, serialized-safe URL swaps during a clone. Make sure that’s enabled, and if you’re “teleporting” between servers, add an explicit dev→prod replacement so the builder’s buried references get flipped. You can also re-run Cloner’s Search & Replace mode post-clone across the live site. 2) Immediately run Oxygen’s built-in URL Replacement After the site is up on production, go to Oxygen → Settings → URL Replacement and replace the dev URL with the prod URL. This hits Oxygen’s design data, page options, selectors, etc., which is exactly where background image references often live. 3) Re-sign shortcodes & rebuild Oxygen’s CSS cache Do the standard Oxygen migration cleanup: Settings → Permalinks : save twice Oxygen → Settings → Security : Re-sign shortcodes Oxygen → Settings → CSS Cache : Regenerate CSS Clear any page/server caches/CDN These steps fix stale CSS and signature mismatches that can blank backgrounds. 4) Sweep the database for stragglers (just in case) Even with the above, you can still have hard-coded URLs in custom selectors or custom CSS. Run a final serialized-safe search/replace across the DB for the dev domain (NS Cloner’s Search/Replace mode is fine here). This is the most reliable way to catch leftover background URLs embedded in JSON/meta. 5) Validate the media itself Make sure all uploads actually made it over (especially if you use offloaded storage/CDN). If the files exist but aren’t rendering, it’s almost always the URL/caching issues above—not missing attachments. General migration threads across builders (Oxygen/Bricks/etc.) report backgrounds as the first thing to break when URLs aren’t fully replaced. Quick diagnostic checks (targeted) In the DB, inspect postmeta for Oxygen keys like ct_builder_json / ct_builder_shortcodes on a problem page—if you still see dev.example.com in that JSON, you’ve found the culprit. (Run the step 4 sweep.) Inspect /wp-content/uploads/oxygen/css/ on prod—if those files reference the dev domain, your CSS cache wasn’t rebuilt. (Run step 3.) Hope this helps!