October: All caches are flushed on backend login

[mrbohnke]

All caches are flushed when you login to backend, right in the moment when you hit the submit button on the login form. Is this a feature? is it necessary? IDK if this is expected or not, we noticed it trying to discover why logins to the backend took sooo long, and thought maybe it was something in our plugin, but after disabling all plugins the behavior persists.

October build

434

[mrbohnke]

Nobody? nothing? 💔

[LukeTowers]

@mrbohnke
The support demand for October is increasing, while the available time the founders have to give remains the same. These issues will be handled in time, however there are ways you can help:

• Submit a pull request that introduces this feature and wait for it to be reviewed
• Contribute to my Patreon so that I can spend more time on issues like these
• Make a financial contribution to the project so we can allocate more time towards making improvements like these that benefit everyone

[mrbohnke]

I'm just surprised about nobody else being afflicted by this problem since it is very evident, frustrating and we can't manage to understand how or why it is happening. I totally understand that time is scarce and the issues many, didn't want to look pushy.
Thank you very much for your time, this project is awesome and we will totally contribute.

[LukeTowers]

@mrbohnke it all depends on what your cache situation is in relation to other people encountering the same issue.

If you're using a non-default option, you've already limited the number of people that might potentially encounter the issue to the number of people using that caching system and then it's further limited by people also operating on the same scale as you. In-request caching of the cache system (pretty meta right?) was just implemented by someone who used an external cache server (Elasticache) https://github.com/octobercms/library/pull/308 for their caching system. It was an issue for them but not a large number of people had such a setup so it ultimately came down to them addressing their need and providing the changes to us in the form of a PR for everyone else to benefit from as well (with the added benefit of the burden of supporting that feature being passed to us instead of them).

As for this issue in particular, https://github.com/octobercms/october/issues/2659 is directly related. More specifically, this is the line of code that is causing you grief: https://github.com/octobercms/october/blob/master/modules/system/classes/UpdateManager.php#L159. See @daftspunk's comment in #2659 for the rational / explanation

[mrbohnke]

Thank you VERY much, we actually saw this issue in the very beginnings of our research on the problem and, as soon as I read october:up, thought it wasn't related. Right now, reading more carefully, I see he actually says that it also occurs on login —bad researcher!
We will continue from there and will update on any news if necessary.
Again, thank you and sorry for all the trouble.

[petehalverson]

@mrbohnke You're not alone, I've run into this before as well and thought it was odd.

Would it make sense to introduce a config option and allow the automatic update check on login to be disabled?

[LukeTowers]

@petehalverson I'd agree with that, feel free to make a PR

[LukeTowers]

cms.runMigrationsOnLogin has been added in https://github.com/octobercms/october/commit/c21c22e1baf1e85ceeb11999a1c1ad144f5f3a2d