can you try changing from

to min="0" instead ?

When I read the code correctly, it doesn't matter what your port is in the configuration. It will automatically switched to 0 when you use an absolute path to the socked. My question is does it work and it's only cosmetic or doesn't it work at all to connect to the socket?

When I read the code correctly, it doesn't matter what your port is in the configuration. It will automatically switched to 0 when you use an absolute path to the socked. My question is does it work and it's only cosmetic or doesn't it work at all to connect to the socket?

This is not the subject, it is the field which refuses the "0" when we click on save the configuration, regardless of the port management behind.

@alikon I'll try min="0" asap thanks

@

can you try changing from

joomla-cms/administrator/components/com_config/forms/application.xml

Line 140 in efb7789
min="1"

to min="0" instead ?

it works, but we need to do it also for :

And all is fine

please test #46396

Hi,

Following up on this with more context, since the issue was closed as "Information Required".

The root cause is now clear, and it's purely a UX/validation inconsistency, not a functional bug.

What already works correctly:
Both libraries/src/Session/SessionFactory.php and libraries/src/Cache/Storage/RedisStorage.php already auto-detect a Unix socket path and force the port to 0 internally, regardless of what's stored in the config:

$port = $host[0] === '/' ? 0 : $config->get('session_redis_server_port', 6379);

This was confirmed by @PhilETaylor in #36149 and documented in #26269 (work originally done in #18395). So for both sessions and cache, the port value entered in Global Configuration is effectively ignored when the host is a socket path. Any numeric value passes through and gets discarded.

What's still broken:
The admin form field (administrator/components/com_config/model/form/application.xml) still enforces min="1" on redis_server_port, for both the session field and the cache field. This means:

• Users trying to literally set 0 (as several hosting providers explicitly document, e.g. PlanetHoster's n0c) get Invalid field: Redis server port and can't save.
• There's no indication anywhere in the UI that the port is silently overridden/ignored when a socket path is used. Users have no way to know they don't need to fight with this field, and end up assuming Joomla is broken.

Suggested fixes (pick one or combine):

1. Relax min="1" to min="0" on the port fields in application.xml, matching what several users have already had to patch manually on their own installs (this validation change alone was proposed as far back as #36149).
2. Or, better, update the field description to clarify that the port is ignored/auto-set to 0 when the host is a socket path, so users stop trying to force 0 manually and understand why any value they enter works.

This has confused multiple users across several forums (PlanetHoster, DirectAdmin, the official Joomla community forum) over the years, with some resorting to manually patching application.xml on every update just to be able to save the config. A small documentation/validation fix here would save a lot of repeated confusion for shared hosting users relying on Redis sockets.

Hi,

Following up on this with more context, since the issue was closed as "Information Required".

The root cause is now clear, and it's purely a UX/validation inconsistency, not a functional bug.

What already works correctly:
Both libraries/src/Session/SessionFactory.php and libraries/src/Cache/Storage/RedisStorage.php already auto-detect a Unix socket path and force the port to 0 internally, regardless of what's stored in the config:

$port = $host[0] === '/' ? 0 : $config->get('session_redis_server_port', 6379);

This was confirmed by @PhilETaylor in #36149 and documented in #26269 (work originally done in #18395). So for both sessions and cache, the port value entered in Global Configuration is effectively ignored when the host is a socket path. Any numeric value passes through and gets discarded.

What's still broken:
The admin form field (administrator/components/com_config/model/form/application.xml) still enforces min="1" on redis_server_port, for both the session field and the cache field. This means:

• Users trying to literally set 0 (as several hosting providers explicitly document, e.g. PlanetHoster's n0c) get Invalid field: Redis server port and can't save.
• There's no indication anywhere in the UI that the port is silently overridden/ignored when a socket path is used. Users have no way to know they don't need to fight with this field, and end up assuming Joomla is broken.

Suggested fixes (pick one or combine):

1. Relax min="1" to min="0" on the port fields in application.xml, matching what several users have already had to patch manually on their own installs (this validation change alone was proposed as far back as #36149).
2. Or, better, update the field description to clarify that the port is ignored/auto-set to 0 when the host is a socket path, so users stop trying to force 0 manually and understand why any value they enter works.

This has confused multiple users across several forums (PlanetHoster, DirectAdmin, the official Joomla community forum) over the years, with some resorting to manually patching application.xml on every update just to be able to save the config. A small documentation/validation fix here would save a lot of repeated confusion for shared hosting users relying on Redis sockets.

In the meantime, as I was tired to patch each time, I've made a plugin to allow the save
https://github.com/M-Falken/plg_system_redisfieldfix/releases/tag/v1.0.0

maybe more easy to test #46396

maybe more easy to test #46396

already replied to this test so long time ago : #46162 (comment)

maybe more easy to test #46396

already replied to this test so long time ago : #46162 (comment)
And still wait for this fix to be applied to the 5.4.x branch and up

any pr needs 2 to human test before to become eligible for merge

so you and me :)

for such a simple modification...

no you and someone else cause the pr author cannot be a tester for his own pr

no you and someone else cause the pr author cannot be a tester for his own pr

yes I know...joke