Although this mutes the PHP Notice, it is not the correct fix. Look at Uri.php and you will see the Notice comes when Joomla assumes you are running IIS

/*
* Since we do not have REQUEST_URI to work with, we will assume we are
* running on IIS and will therefore need to work some magic with the SCRIPT_NAME and
* QUERY_STRING environment variables.
*
* IIS uses the SCRIPT_NAME variable instead of a REQUEST_URI variable... thanks, MS
*/

The correct fix is to make Uri.php CLI Aware and not have it try to generate http urls using invalid data.

make more sense now ?

@alikon I don't think that it is a good idea to prepare Uri to understand the Application context and change the internal behavior according to the execution.

If an object has to use "isClient", then it is a bad signal and it is better to think twice about what we are doing.

The problem is the application context mismatch, why the current Application is calling Uri without sending the right parameter.

As I pointed out in #35818, the problem is that the Content Component boots the Site Application with $container->get(SiteApplication::class). The Content Component doesn't have to force the Site Application.

About #35625, the problem is that the php cli/joomla.php list is firing the "System - Page Cache" when it's called from the console. Why would a console application fire the "System - Page Cache" plugin? It shouldn't. By default, a console application doesn't have to interact with the site cache.

I have tested this item ✅ successfully on a510896

With the code and tutorial I wrote yesterday I can confirm this works as described.

I have tested this item 🔴 unsuccessfully on a510896

No No No.

Faking an URL 'localhost' into $_SERVER['HTTP_HOST'] is not the way to solve it.

The problem is the "System - Page Cache" plugin executing in the console context. The plugin must ignore the execution when it is in the console context.

closed as per #35877 merge