!!! TASK: Mvc\Dispatcher::afterControllerInvocation will not be called for CLI requests anymore.
#3296
Conversation
This file contains 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
|
Related #3232 (comment) and @kitsunet 's comment:
And #1892 |
…led for CLI requests anymore. Reverts that the cli dispatcher invokes the mvc slots dispatcher slots with cli requests. When there was one dispatcher the slot `afterControllerInvocation` was fired for both cli and web request. (Seemingly only ever at Runtime?) Then with the split of web and cli dispatchers this legacy layer was introduced: neos@cf55b18#diff-2c9408e74a8ac737f84468e74c23956d2057e64196e66b97281905d8697226ca Now during a short time the `Mvc\Dispatcher::afterControllerInvocation` signal was now also called for cli request during compile time. With this bugfix neos#2529 the initial behaviour was restored again. For cli request it will only fire at runtime, and web request are either way always runtime. This breaking change cleans up the legacy layer. - The original signals Mvc\Dispatcher 'afterControllerInvocation' and 'BeforeControllerInvocation' Will be only invoked for action requests. They still only fire at runtime, as web requests happen at runtime. - The with Flow 6.0 introduced signals Cli\Dispatcher 'afterControllerInvocation' and 'BeforeControllerInvocation' Will still be only invoked for cli requests. Will still fired either at compile or runtime, as cli requests can happen always. In case you used the MVC signals and relied on it to also be invoked for CliRequest, you need to connect as well to the respective Cli\Dispatcher signal. But keep in mind that you might need to check if flow is in runtime as this signal will be also fired for compile time unlike the mvc signal before.
mhsdesign
force-pushed
the
task/removeLegacySignalForwardingInCliDispatcher
branch
from
026c523
to
4708efc
Compare
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.
Reverts that the cli dispatcher invokes the mvc slots dispatcher slots with cli requests.
When there was one dispatcher the slot
afterControllerInvocationwas fired for both cli and web request. (Seemingly only ever at Runtime?)Then with the split of web and cli dispatchers this legacy layer was introduced:
cf55b18#diff-2c9408e74a8ac737f84468e74c23956d2057e64196e66b97281905d8697226ca
Now during a short time the
Mvc\Dispatcher::afterControllerInvocationsignal was now also called for cli request during compile time.With this bugfix #2529 the initial behaviour was restored again. For cli request it will only fire at runtime, and web request are either way always runtime.
This breaking change cleans up the legacy layer.
The original signals
Mvc\Dispatcher'afterControllerInvocation'and'beforeControllerInvocation'Will be only invoked for action requests.
They still only fire at runtime, as web requests happen at runtime.
The with Flow 6.0 introduced signals
Cli\Dispatcher'afterControllerInvocation'and'beforeControllerInvocation'Will still be only invoked for cli requests.
Will still fired either at compile or runtime, as cli requests can happen always.
Upgrade instructions
In case you used the MVC signals and relied on it to also be invoked for CliRequest, you need to connect as well to the respective Cli\Dispatcher signal. But keep in mind that you might need to check if flow is in runtime as this signal will be also fired for compile time unlike the mvc signal before.
Review instructions
Checklist
FEATURE|TASK|BUGFIX!!!and have upgrade-instructions