Best practices for avoiding frequent request/response console bugs

[timkelty]

A seemingly very common bug is for devs to rely on request/response props and methods that are available in a web app context, but not in a console one.

Especially with the queue, devs may not realize that their code needs to be able to run as web OR console.

So, one generally needs to sprinkle a bunch of getIsConsoleRequest conditionals around.

Is there a better solution here?

The bug is understandable, as things may work fine for the dev when testing if they are not running their queue from console.

Examples:

• Seomatic breaks console nystudio107/craft-seomatic#222
• Cannot call renderPageTemplate from a console request cms#3124
• Error when updating entries from console command nystudio107/craft-seomatic#39

[Anubarak]

Maybe it's a good idea to take a look at Pixel and Tonics easy and clever solution for this problem in their services, helpers, elements and so on.

They mostly don't use it.

There are only a few uses of the request component in their code because that's the "correct" design pattern of an MVC. The controller should handle the request and the controller knows what kind of request it is - because you separate them in console and web controller. After your controller handled iti you should ry to avoid relying on it too heavily.

When you only pass the variables you need you won't get in trouble. Besides that you should check what kind of request you have in order to use the correct response component.

If your code end up with those if conditions all over the place maybe it's worth the rethink the design pattern (not talking about you in particular, just in general way)

Don't get me wrong - I can totally understand your point and I got to deal with it too in the past but when you structure your classes in a certain way from the beginning you won't have that much to worry. Of course it's "easier" to grab variables from request nearly everywhere instead of passing them all the way to the service but it's sometimes the cleaner approach

[timkelty]

@Anubarak Yep, agreed with your points.
In my case I'm mostly fighting against this not in my own code, but in plugins I'm using.

So, I think whatever the solution is, I think something in the docs specifically advising devs would be ideal.