Sqlite cache and duplicator

  • Resolved Imageflicker177

    (@flicker177)


    3 months ago

    Hello all,

    First, very nice plugin, speeds things up, and gets rid of the WordPress health check warning “You should use a persistent object cache.” My hosting plan does not provide redis or memcached.

    I’ve spent a few days struggling with an issue involving this plugin and Duplicator. I’ve used Duplicator for years to back up WordPress sites and run them locally using Laragon. This has always worked fine. Suddenly, migrating a Duplicator backup to my localhost completely broke everything. The local links that always worked fine suddenly started directing me to bad url’s on the live site. I couldn’t access the local site at all. I recalled that I installed this plugin recently and indeed, that seems to be the root of the problem.

    This turned out to be a known issue between the two plugins. If I deactivate the Sqlite object cache plugin before migrating, all is well again. However, if I reactivate the Sqlite object cache plugin on the localhost it completely breaks everything again. After that I can no longer access the localhost site at all, I get redirected to the live site with a bad url. The only way I can get it working again is to completely delete the localhost site and restore it from the backup made with the Sqlite object cache deactivated. Restoring just the database from the backup doesn’t help, there’s just no way I can get the Sqlite object cache to run properly on the localhost.

    My only solution is to just leave the Sqlite object cache deactivated on the localhost. This really isn’t a problem but it scares me. I don’t know what would happen if I ever wanted to use my backup to restore the live site. I’d be more confident if the backup-migrate-restore process worked OK.

    Even uninstalling the Sqlite object cache on the localhost and then re-installing it doesn’t help.

    Any idea how this could happen? Are there files somewhere that might point to the live site after the migration that need to be deleted? Most confusing.

    Thanks,

    –Bill

    The page I need help with: [log in to see the link]

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

    (@flicker177)

    3 months ago

    I played with this some more. A Google search found this:

    Deleting the migrated .ht.object-cache.-a.sqlite and object-cache.php manually via ftp solves the redirection problem.

    Deleting these files *before* reactivating the plugin on the localhost solved the problem. If I’m not wrong it wouldn’t be a problem for the plugin itself to delete these files when uninstalling, activating or de-activating the plugin to avoid this issue. Anyway, I now have a good workaround and all is well here.

    Thanks again for the great plugin!

    –Bill

    Plugin Author ImageOllieJones

    (@olliejones)

    2 months, 3 weeks ago

    That’s right. It’s smart to deactivate this cache before creating a Duplicator package. If you’re using the APCu feature and you will restore to a staging site on the same php process pool, you *must* deactivate first.

    Alternatively, you can give the file names of the .sqllite, .sqlite-wal, and .sqlite-shm files to suppress their backup manually.

    BackWPUp, Updraft Plus, and WP Staging all include hooks to allow other plugins to prevent the backing up of their files, but Duplicator does not have that particular hook feature. I use the hooks where they are available.

    Thanks for reminding me of this problem. I think there’s a way to force the deactivation of the plugin on Duplicator restore.

    Thread Starter Imageflicker177

    (@flicker177)

    2 months, 3 weeks ago

    Hi Ollie,

    Yes, I understand that and deactivating the plugin before making the duplicator package is easy. The part that stumped me was that after migrating the site and reactivating the plugin broke everything again.

    The key was in deleting the files .ht.object-cache.-a.sqlite and object-cache.php before reactivating the plugin on the new site. This wasn’t obvious to me at all but it fixed the problem.

    Again, if the plugin deleted these files when activating, deactivating, or deleting the plugin I think we’d avoid the issue.

    Thanks,

    –Bill

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.