Fatal error: Cannot declare class ParagonIE_Sodium_Compat

Issue Summary

Pulled down new files including database from a production site on Flywheel and after launching the site on local I get ( ! ) Fatal error: Cannot declare class ParagonIE_Sodium_Compat, because the name is already in use in /Users/home/Sites/Local Sites/bc-clark/app/public/wp-content/plugins/autoupdater/lib/vendor/paragonie/sodium_compat/src/Compat.php on line 28

Troubleshooting Questions

I’ve got it to happen on other sites that I have hosted on Flywheel with auto plugin updates. I think Local doesn’t have anything in place to deal with any Flywheel sites that have the autoupdater plugin being used when having Flywheel do their site plugin updates.

Replication

Pull down a site on Flywheel hosting that has auto plugin updates enabled.

System Details

  • Local Version - 5.10.5+5403

  • macOS Big Sur Version 11.4

local-lightning.log (844.7 KB)

For anyone else that might be having this issue you can either not download the autoupdater plugin when you pull your site down or just change the folder name to something else to disable it and don’t push that folder name change to your production or staging site as a work around.

Interesting – Getting a PHP error because a class was already named makes me think that the plugin might have updated and moved some files around, but Local didn’t delete the files when using Connect.

If you delete the plugins/autoupdater folder in the Local site and then pull the site, do you run into the same error?

Doing what you suggested results in the same error. The site pulls down the autoupdater plugin and results in the same error. If I disable the plugin by renaming the folder the issue obviously goes away.

I’m doing some follow up with different teams internally. It looks like this is a known bug and that it’s in the backlog to be fixed with the Manage Plugin Updates team. I’m doing a couple other tests to see if I can get you a good workaround while waiting for the fix.

I’m good on waiting for the fix. I’ll just update the folder name locally for now to ignore the plugin while working on sites through Local. I will also just make sure to uncheck the updater plugin box when syncing files back and forth until I see the fix in patch notes.

Thanks for verifying the issue and that it’s on a list somewhere to get fixed.

Nice! Ok, I got some more info and a bit of a workaround.

After pulling the site down, you should be able to deactivate the plugin within Local by right-clicking on the site in Local and selecting “Open Site Shell.” Within the terminal that opens, run this command to deactivate the plugin:

wp plugin deactivate autoupdater --skip-plugins

In terms of what happens if you push a site that has the autoupdater plugin deactivated or deleted – the Flywheel app will notice this and will automatically enable to autoupdater plugin on the remote site.

I’ve also made some noise in the bug report to get a fix worked on sooner. Thanks for your patience as well as bringing this to my attention!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.