TYPO3 Core

Hi Steffen,

Could you please provide if you're using the calendar base (cal) extension? This might be related to cal. The discussion you are referring to also mentions this. If so, which version are you using?

I can confirm this, again and again and again, now on typo3 4.2.8, with a 2-level TMENU_LAYERS.
OS: openSuSE 11.0, PHP 5.2.9, MySQL 5.x, apache 2.x

I am NOT using cal extension anywhere.

But probably it could be any other extension causing this really anoying bug!

(website has 8 languages, lots of pages and about 2k users a day, which is not that much IMO. ;) )

this is, btw, a duplicate to #17187

Sorry for not responding, but notification mails didn't work for the last months.

No, I also don't use cal.

Hey guys, we're encountering the very same problem for ages now. Isn't there any solution to this yet? This slows down our whole system and we're forced to implement cronjobs to clear the cache table on a regular basis. It would be great if you could raise the priority on this.

Our table currently contains >322,000 MENUDATA records, so yes.. this is quite ugly. I try to have a look after I finished the whole skinning work - hopefully the next days...

Hi,

Ok, I had to inform you about the status.

After the T3BOARD10 I did a lot of investigation regarding this topic and posted the outcome of this investigation to the other core team members. Currently there is no simple solution. The outcome of this investigation was we need to rewrite the whole tslib_menu. As this is a major task, I asked to the other core team members to discuss this during the meeting we have in front of the T3DD10 and see if we can find a good solution. We need to have the views of multiple people, simply because this is pretty complicated stuff to solve.

We already agreed this task was too late and too complicated to get into 4.4.
I'll post my outcome on the dev mailinglist as well, so you know what exactly is going on.

Posted the outcome of my investigation to the dev mailing list

Subject: MENUDATA caching problems

I've uploaded a patch which is the first attempt to get rid of these huge amounts of menudata.

In this patch the caching framework is not taken into account, so if you want to test it, you need to turn this off.

Install the patch, go to the install tool and compare the database. You will see it tries to add two new tables, "cache_menu" and "cache_menu_mm".

If you read my outcome on the dev mailing list, you will probably know there are a few major issues, concerning the MENUDATA caching.
- MENUDATA entries were never deleted while changing page properties
- MENUDATA causes huge database tables
- MENUDATA is not state aware

The second one was my first concern. When using ExpAll = 1 in a HMENU, all the levels on all pages got an entry in the cache_hash table, with quite some data in the "content" field, which was in most of the cases redundant. The fix does not get rid of the huge amount of records, actually you will probably get more, because the caching is not done by level anymore but by menu item, especially in the "cache_menu_mm" table, but these are very small records. The "content" part in "cache_menu" is not redundant anymore.

Also the first problem has been fixed. The "cache_menu_mm" table contains a column "link_page", which holds the page id of the menuitem for the page it was created. When changing page properties in the backend, the records will be cleared with the same functionality which clears the page cache.

This also makes it possible to have some kind of state awareness, although changing page properties does not clear all pages in the rootline. For most of the menu's you should clear the cache for ALL pages, which is not recommended.

The patch is still in a rough state. Please post your findings and comments because it will help finding a solution for a problem which is in the TYPO3 core for a very long time.

One of the things I'm currently thinking of is using an INSERT statement with multiple VALUES lists to insert several rows at a time. This is considerably faster (many times faster in some cases) than using separate single-row INSERT statements.

Work in progress ;-)

And a question to you all: Currently the functions storeMenuHash() and getMenuHash() are in t3lib_page, simply because the storeHash() and getHash() for the "cache_hash" table was there as well. But because both functions are related only to the menu caching, IMHO it makes sense to move them to tslib_menu.

What is your opinion?

if they are only used by menu they should be moved. if it's worth to use it at other places we could create an own class for these kind of function. Eg i always was unhappy for clearing cache to instantiate tcemain.

Will look to your patch these days to get an idea ;)

Are there any updates on this? Is this already fixed in 4.5? I see some installations of us which have growing cache_hash tables with insane amounts of MENUITEM entries.

Thanks a lot for feedback!

I did no deeper investigations on this topic anymore,
but I can tell you, that I did not stumble upon this issue since years.

This maybe is also caused by:

1. consistently using the 'cachingframework' in my LTS installations
2. consistently having the cachingframework garbage-collector task configured.

so from my point of view you may close this issue silently.

regards,

Clemens

The issue still persists on our sites in 4.5.
Looks like it's related to the case, when we have lot's of complex menus on the site.