8A. Claim a merge only where the standalone really went away - #66
Open
nikolaystrikhar wants to merge 2 commits into
Open
8A. Claim a merge only where the standalone really went away#66nikolaystrikhar wants to merge 2 commits into
nikolaystrikhar wants to merge 2 commits into
Conversation
The merge notice was queued as the deactivation was made, and the re-check that asks whether the standalone actually went off ran afterwards and fed the redirect alone. A site whose mu-plugin filters `option_active_plugins`, or a host that bound `Plugin\Contracts\Deactivator_Interface` to a no-op -- which that interface invites by name -- therefore got no redirect, correctly, and a notice saying a plugin they can watch still running had been deactivated, re-queued on every admin GET. The re-check moves in front of the notice, so the sentence is written on the branch that confirms it. One notice per plugin lost is unchanged: it is still queued per sub-plugin, as each deactivation is confirmed, and still before the redirect that would otherwise carry it off. Nothing is reported through `report_error()` on the other branch. This is the DEFER outcome reached by another route -- the standalone is running, so its own guard constant stands the bundled copy down and nothing re-declares -- and DEFER announces nothing. Every route here is a site's own configuration rather than a mistake in the host's code, which is who `_doing_it_wrong()` addresses, and the conflict is re-detected on every admin GET, so a report would print the same sentence on every screen of a debugging site for a site behaving as its owner set it up to.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Container failure moved from read-time to build-time when the reader took its registrar as a constructor argument: a pass that exists has already resolved everything it needs. The hook prefix is what is left, and it is read when a notice is worded.
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.
What:
Conflict\Resolverqueues the merge notice from the branch where the post-deactivation re-check confirms the standalone is gone, atplugins_loadedpriority 5.Usage: a site whose mu-plugin filters
option_active_pluginsback, or a host that boundPlugin\Contracts\Deactivator_Interfaceto a no-op, now gets no notice at all instead of "the standalone has been deactivated" about a plugin still visibly running.Why this way:
The notice waits for the answer the redirect already waited for. The re-check existed and fed the redirect alone, so the request correctly stayed put and incorrectly reported a merge — re-queued on every admin GET. One
ifmoves it in front of the writer.One notice per plugin lost is unchanged. It is still queued per sub-plugin as each deactivation is confirmed, and still before the redirect that would otherwise carry it off.
Nothing is reported on the other branch. That outcome is
DEFERby another route — the standalone runs, its guard constant stands the bundled copy down, nothing re-declares — and every route to it is site configuration, not a mistake in the host's code that_doing_it_wrong()addresses.