Avoid re-running full plugin init during activation#1193
Draft
utkarshcloudinary wants to merge 1 commit into
Draft
Avoid re-running full plugin init during activation#1193utkarshcloudinary wants to merge 1 commit into
utkarshcloudinary wants to merge 1 commit into
Conversation
install() called get_plugin_instance()->init() unconditionally, which re-ran the bootstrap out of sequence during plugin activation and could destabilise plugin load order for the request (e.g. triggering ACF to initialise too early). Only run init() when the plugin version has not already been populated; the DB routines only need the version.
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
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.
Summary
Utils::install()— registered as both the activation hook and thecloudinary_version_upgradehandler — unconditionally calledget_plugin_instance()->init(). On the version-upgrade path this re-ran the plugin metadata bootstrap out of sequence (afterPlugin::init()had already run on theinithook), which can destabilise plugin load order for the request — e.g. triggering other plugins such as ACF to initialise too early.This was observed on an enterprise customer site (WP 7.0 / PHP 8.2, ACF Pro 6.8.3): for ~5 minutes after activating Cloudinary 3.3.3, frontend requests fataled with
Call to undefined function have_rows()in their ACF-dependent theme, alongside a flood of_load_textdomain_just_in_timenotices for theacfdomain. The fatals correlate exclusively with the post-activation window across two weeks of logs.Change
Only call
->init()when$plugin->versionis not yet populated:inithook has fired, soversionis empty → fallback->init()runs as before. No behaviour change.cloudinary_version_upgrade(init prio 100):Plugin::init()(init prio 10) has already populatedversion→ the redundant re-bootstrap is skipped. This is the destabilising path.Everything downstream of
install()(get_table_sql,table_installed,dbDeltabranch,upgrade_installand theupgrade_3_xmethods) depends only on$plugin->version, which the guard guarantees.Notes
have_rows()calls); this change removes the plugin's contribution to out-of-sequence bootstrapping — defensive hardening that benefits any site with load-order-sensitive plugins.Testing
cloudinary_version_upgrade) runs upgrade sequence without re-runninginit()