Cloned site doesn’t use correct Theme and has critical error when I switch

This topic is marked resolved. Is there a solution?

?Yes, the solution was that SiteGround had to clear the Memcache (Object Cache)…
https://www.siteground.com/tutorials/supercacher/memcached/

Having same issue i was using version 4.1.8 – 2021.09.30;
Today i am updated to lastest 4.1.9.3 – 2022.01.06;
Now clonned site have setted default wordpress twenty theme and all widgets in disabled section; while theme must setted from default site source to divi;
Downgraded back to 4.1.8;
Now all work’s fine, as was;maybe this bug from 4.1.9.1 – “Fix unnecessary object cache flushes and add filter to disable entirely”

@romkahomka @frankprendergast

Yes, this issue is not resolved and the risky workaround has to be performed with every site clone. The entire object cache has to be cleared for cloning to work.

From WPMUDev:
“Are you sure? The object cache should only be cleared if absolutely necessary. It is usually not needed except after making direct database edits or during development. If you aren’t sure, contact support and we’ll help you out.”

@neversettle Can you please do some troubleshooting? Perhaps work on process of elimination?

1. When did the problem start?
2. Which WP or plugin version was affected?
3. Is this a WP issue, or plugin issue?
4. Test other, older versions, hosts, etc.

I hope that you please look into resolving this matter.

Thank you,
Tom

@brakebeat you wrote:

“…the risky workaround has to be performed with every site clone. The entire object cache has to be cleared for cloning to work.”

Clearing the cache is not “risky” — the downside is that it has a negative effective for performance because sites that are using object caching will typically a experience a temporary increase in load times until the cache is rebuilt.

The way that the Cloner worked prior to version 4.1.9.1 was actually to do that every time a site was cloned, automatically, by calling wp_cache_flush() after each cloning operation. For some users (particularly those using WP-Redis for object caching), this was causing an unnecessary performance hit on each clone, so we removed the automatic cache flush, and we thought it might be unnecessary when cloning to a brand new site (it seemed cache flushing might only be necessary when using the “clone over” mode available in the Pro plugin). However, as we’ve seen with this case and others, the behavior is very platform dependent and a cache flush actually is needed sometimes for a new site to appear correctly.

We’ll be working on an enhancement to allow flushing the cache conveniently via the Cloner interface if needed (so you don’t have to go do it / request it through your host), but without defaulting to doing so every time as previously.

@neversettle Thank you. If you could do some troubleshooting and find the best solution (one that doesn’t require the cache flush) it would be greatly appreciated.

It might also be host dependent, but it seems like a lot of hosts are having this issue.

Thanks,
Tom

@brakebeat noted and we’ll explore possibilities. It would seem that since the object cache is the source of the issue, it’s unlikely that there exists a solution that doesn’t involve cache flushing on some level, but if we can find a way to clear the cache values needed without doing a full flush (that works consistently across hosts/platforms, since there’s significant variance there), we’ll follow that route.

@neversettle Ok, ik that’s the case, then it would be best to determine when problems started to arise, then troubleshooting from there (since it was fully functional before).

Thank you,
Tom

Yes, as noted above, it was fully functional before because we were doing a full cache flush every time, but that’s not ideal ??

Wanted to note here that version 4.2.0, released today, contains improvements to the caching logic. It’s difficult to make any guarantees, but this change may help resolve issues described in this thread.