Repository navigation
fix(plugin): load nothing next to Pro instead of deactivating - #252
Merged
Merged
Conversation
Ghost Kit Pro ships this core inside itself, so the two must never run together. That was enforced by deactivating whichever plugin was not just activated, on top of a `class_exists` guard that only holds while Ghost Kit Pro is included first. The standalone plugin now reads the active plugin list before it defines anything and returns when Ghost Kit Pro is there, so the guarantee no longer depends on include order: network-activated plugins are included before site-activated ones, and a third party can reorder `active_plugins`. Testing `plugin_basename( __FILE__ )` keeps the copy bundled in Ghost Kit Pro loading, along with copies embedded in a theme or another plugin. Deactivation now reaches only free versions below 3.7.1, which declare the core class a second time instead of standing aside. Ghost Kit Pro is never deactivated.
`active_plugins` goes on naming a plugin whose directory was removed by hand, and WordPress simply skips it while the option keeps the row. Reading the option alone meant this plugin could go quiet for a Ghost Kit Pro that never loads, leaving the site with neither. Check that the Pro main file is there before stepping aside. The version floors gain an `-alpha` suffix so `bump:prerelease` builds of the same version count as new enough. `version_compare()` ranks a pre-release below the release it precedes. Guard the plugin header read behind `file_exists` as well, since `get_plugin_data()` reads the file without checking that it is there.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ghost Kit Pro ships this plugin's core inside
core-plugin/, so the two declare the sameclasses and only one of them may run. That was enforced by deactivating whichever of the pair
was not just activated, on top of an older
class_existsguard that only holds while Prohappens to be included first. Both can now stay activated instead: the standalone plugin reads
the active plugin list before it defines anything and returns when Pro is there, so none of its
own code loads.
The check reads the option rather than leaning on
class_existsbecause the include order isnot ours to choose. WordPress includes network-activated plugins before site-activated ones,
and a third party can reorder
active_plugins; in either case this plugin wins the race andPro ends up running its modules against a core it did not ship. Testing
plugin_basename( __FILE__ )is what separates the two roles this one file plays: thestandalone plugin's basename is in the list, the copy Pro bundles resolves to
ghostkit-pro/core-plugin/…and never is, so Pro keeps loading its own core. Copies embeddedin a theme or another plugin resolve outside the plugins directory and are likewise unaffected.
This has to ship as 3.7.1 or later.
FREE_PLUGIN_MIN_VERSIONis the floor below which aninstalled free copy is still deactivated, because those releases declare the core class a
second time instead of standing aside. Carrying this change in a release numbered below the
floor leaves it inert.
Deactivation is narrowed rather than removed, and it never touches Pro any more. Activating
this plugin next to Pro no longer switches Pro off; deactivating Pro is now the way back to the
free plugin. It also refuses to go quiet for a Pro that WordPress will not load, since
active_pluginsgoes on naming a plugin whose directory was deleted by hand and the site wouldbe left with neither.
Ghost Kit Pro needs no change of its own: it carries no bootstrap-level deactivation, and it
picks this up through the
core-pluginsubmodule bump in its own pull request. The equivalentchange is open in
visual-portfolioandlazy-blocks; the Visual Portfolio one additionallyreads the Pro version, because that Pro does have such a bootstrap.
Verified in wp-env for Visual Portfolio, whose diff is identical to this one after normalising
names: Pro alone loads its bundled core, both plugins active in either include order leave only
this file included and returning, the free plugin alone is unchanged, and a free copy below the
floor is still deactivated.
npm run lintandnpm run test:unit:phppass here.