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.
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
ConfigCorruptionExceptionfatal error. The user sees something like: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.