Cm_RedisSession default to true

[mpingu]

Affected file: /app/etc/modules/Cm_RedisSession.xml

Could we set the Default value for the module to be true?

When you just update the core with unzipping the tar.gz you overwrite this file and deactivate your Redis integration and Magento will write the sessions into the MySQL Database.

[seansan]

​+1 haha did not even realize this - as a result, I see we are also using core_session DB (instead of Redis)​

…

On Fri, Nov 17, 2017 at 2:30 PM, Carsten Bohuslav ***@***.***> wrote: Affected file: /app/etc/modules/Cm_RedisSession.xml Could we set the Default value for the module to be true? When you just update the core you overwrite this file and deactivate your Redis integration and Magento will write the sessions into the MySQL Database. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#379>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAn0axFm5uNK_1JNbsoE7m3RjLrimz-Qks5s3YqAgaJpZM4QiClW> .

[seansan]

#380

[tomekjordan]

what if store is not using redis for sessions?

[infabo]

It does not harm enabling Cm_RedisSession by default. But IMHO any module not being used, should be disabled. In my experience, only "bigger" shops/setups use Redis for session storage (I can see no reason for Redis on a simple single instance shop with SSD file-storage for example).
Anyone in need for Redis (e.g. on scaling setups) should already have a proper deployment configuration up-and-running, so it is easy to consider "enabling modules" like Cm_RedisSession automagically. Just my 2cents.

[tomekjordan]

true. I use Redis only for FPC

[colinmollenhour]

There are a couple things going on here:

1. If your method of updating Magento is to untar files into your production directory you're doing it wrong.. If you insist on doing it this way then definitely do not modify any files that are included in the tar file. Perhaps set the read-only flag on all core files to prevent it explicitly. Then, to enable/disable modules add your own app/etc/modules/Z-local.xml (Z to sort after all other modules) which will override the existing files without you modifying them.

2. The Magento core code does not allow for easily adding new backends so while it should not even be necessary for Cm_RedisSession to be a proper module (versus just an auto-loaded class), it is required in order to work without modifying core code. However as we actually can modify core code perhaps the best solution would be to allow for other backends so that Cm_RedisSession and the 'db' backend can coexist peacefully. Specifically, here:

https://github.com/OpenMage/magento-lts/blob/1.9.3.x/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php#L59

3. Enabling Cm_RedisSession causes a rewrite so I wouldn't say there is 0 impact:
   https://github.com/OpenMage/magento-lts/blob/1.9.3.x/app/code/community/Cm/RedisSession/etc/config.xml#L42
   This is related to (2) above so if that was fixed this rewrite could be removed and then it would be a non-issue.

If I remember correctly the newer version that uses the abstracted handler that is shared with M2 actually removes this fallback functionality. I don't think it is the best situation since with the fallback people can think they're using one and in fact be using another. Enabling it by default and then removing the fallback could be disastrous to those using the MySQL handler.

[mpingu]

Thanks for the clarification on this point.Imho we can close this then and reference to it if someone askes for the consequences of it.