Uh, this has been accepted in the platform. It will make its way to the CMS with the platform merge.

We're still following normal procedures as far as I know and I also think it can go into 2.5 if people test enough.

Than the pull request should be made against 2.5.x, not master. Also it didn't get lost ;)

I have no idea what the normal procedure is with the cms files in the libraries folder. :)

As I said it will be merged back together with the rest of the platform. JModuleHelper will stay in the platform BTW.

ok.

PS: just a shame that these fixes take so long to find their way back to the CMS then. These fixes don't go into the CMS sub releases.

Try getting anything into the CMS releases is tough ;)

If you want things to go into the CMS before that you have to do the legwork yourself.

"If you want things to go into the CMS before that"? It shouldn't be just me that wants this bug fixed in the cms, right?

"legwork"? As in placing a pull request on the joomla cms?

Please create a tracker on joomlacode and a patch towards 2.5.x with test instructions.

Sure, but no one is constantly monitoring the platform for things to backport. And the leg work isn't creating the patch (it can be thou if the files have greatly diverged) but finding testers for it.

I'll just wait till it gets backported. It isn't an issue anyway when using my Advanced Module Manager.
So for me there is no rush.

This is a bad idea to remove modules caching !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
We need to have a choice between caching or not.

Besides in 99% caching is done for a small period of time, and publishing of modules usually occurs on daily date range - so cache is renewed few times a day and modules with precise publishing dates will appear.

Or we can just inform user that publishing won't work if Joomla caching is Enabled.

All such efforts make Joomla completely unusable for high load sites :(

This is NOT about removing module caching. It's about removing the module list caching. Something completely different.

So normal module caching remains as it is AND you already have the option to switch on/off caching per module.

I understand!
But loading of modules list is an additional database query per each page load.

And btw module caching is still disabled for logged users.

Well, as the initial issue describes, caching of the module list makes no sense anymore now that you have publishing by date.
Meaning caching the module list creates a BUG.

Also: "I have tested this extensively and this has no noticeable influence on page render time."

Anyway, I did my part. Do with it what you want.

"tested this extensively" - can you measure the load of website with i.e. 20 hits per second?

Joomla has lots of features that can be considered as a "bug", but we can't completely fix these issues, i.e. com_content is cached but articles can have publishing range too.

So the only conclusion is too disable caching if you have publishing ranges anywhere.

Setting caching to small time still improves the performance, and if the module will appear or disappear not immediately but in i.e. 15 mins - that's not a huge problem.

In fact publishing range for modules is rather strange feature, I doubt that it is widely used and we can't decrease the whole site performance because of small feature.

Can you measure that caching the module list improves performance and outweighs the problems it causes?

There is a difference between caching the content of modules and caching what modules should be shown.

Since the code has made its way to the CMS with the platform merge I'm closing this one.

I plan to put this back in some way (either just for progressive or a new cache mode), I'd love to hear your thoughts on that.