Sylius: Multiple channels with php-cli is not possible
Sylius versions affected: > 1.2 I suppose
Description
When having two channels and try to use a command witch use a ChannelContext, it throw a ChannelNotFoundException
Steps to reproduce
Two channels defined and trying to use ChannelContext while executing commands.
Possible Solution
Create a PhpCliChannelContext (priority: -256) that check if we are in a command line env and load a Channel witch can configured by service configuration (calls: [['setDefaultChannelCode', ['MY_DEFAULT_CHANNEL_CODE']]]) or by a global Sylius Channel configuration.
If the defaultChannelCode is not provided, we could fallback to the first channel we found.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (13 by maintainers)
@lchrusciel for that to work, Sylius would need to separate all of it’s business logic from the HTTP layer and get the channel as an argument instead of relying on channel context everywhere. Respectively, the channel context should only be used in the HTTP layer to get the current channel and pass it downstream to the application’s business layer. The road to achieve that is long… probably even Sylius 3 long. Right now most of the Sylius business logic is extensively coupled to the HTTP layer, most of it is inherited from the resource layer. The most representative example is that you can’t do anything in the resource layer without the infamous RequestConfiguration. What @Prometee and I proposed is just a workaround until the foundation allows for better solutions.
Summary: We don’t want to merge it, as no Sylius CLI command is suffering from this problem. What is more, we do not consider such usage as a good solution to the problem, so we don’t want to encourage others to solve it this way.
The cookbook: https://docs.sylius.com/en/1.13/cookbook/cli/handle-multiple-channels-in-cli.html
Hey folks!
I would like to add my 2 cents here. Contexts by design should be considered as stateful services. They reference to session, current request etc. As a result they should be used mostly in HTTP Controllers or as close as possible to them.
As a result all CLI and or MessengerHandlers should be context free. Still, this is a recommendation and not whole code is supporting this case, like related https://github.com/Sylius/Sylius/pull/13545/.
From the ideological point of view, we even shouldn’t be able to determine channel, locale, cart or customer of CLI operation. Perhaps, we should do some high-level early return for all these contexts to not execute services below, as they may be heavy.
This doesn’t mean that a context where you may define default context may be useful.
When executing commands you don’t have any frame of reference which channel to use. I would suggest that your command should have an argument that is called channel and then you just load the channel from the repository.