Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a Recovery Mode #178

Open
mlwilkerson opened this issue Aug 25, 2022 · 0 comments
Open

Provide a Recovery Mode #178

mlwilkerson opened this issue Aug 25, 2022 · 0 comments

Comments

@mlwilkerson
Copy link
Member

Recent issues in the support forum indicate scenarios where upgrading, downgrading, and fallback among multiple installations of the plugin--sometimes by various themes or plugins shipping it as a library--results in a ConfigCorruptionException fatal error. The user sees something like:

When trying to load Font Awesome, the plugin's configuration was invalid. Try deactivating, uninstalling, and re-activating the Font Awesome plugin.

The plugin's Loader is designed to accommodate the possibility of multiple simultaneous instances of this plugin being present on a site. It simply elects the newest version available.

When any version of the plugin runs, it looks to see if upgrade logic needs to run, to update the configuration schema in the database.

If a newer version does update the configuration schema in the database, it may render the configuration schema incompatible with one of the earlier versions of the plugin. This is fine as long as that newer version is the one that continues to run.

But if that newer version were removed for any reason--say a theme using a newer version of this plugin is uninstalled--then if some other plugin continues to depend on the Font Awesome plugin, the uninstallation of that theme will not result in the clean up of the Font Awesome configuration in the database. This is by design, so as not to "pull the rug" out from any other clients that continue to depend on the presence of the plugin.

However, the trouble case here is: when falling back to an earlier version of the plugin that is not compatible with the newer configuration schema, you would get a ConfigCorruptionException.

It may not be easy to discern which themes or plugins are involved (see support forum topics here and here).

What might be useful here is a utility for just resetting the configuration for whatever version of the plugin is currently running.

An alternative would seem to be: install a newer version of the plugin and allow it to run its normally automatic upgrade logic to put the configuration into a valid state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant