TYPO3 Core

A closer look shows:

• Mountpoint situation creates an identifier with a comma
• const PATTERN_ENTRYIDENTIFIER = '/^[a-zA-Z0-9_%\\-&,]{1,250}$/'; does not allow this (TYPO3\CMS\Core\Cache\Frontend\FrontendInterface)
• That causes the exception in TYPO3\CMS\Core\Cache\Frontend\VariableFrontend
• This is used from TYPO3\CMS\Core\Utility\RootlineUtility->get
• That is called from RealURL - $rootLine = $this->sysPage->getRootLine($id, $mpvar);

In TYPO3 4.7.15 PATTERN_ENTRYIDENTIFIER is the same but when RealURL gets a rootline, that is done by t3lib_pageSelect::getRootLine which is built very differently and doesn't cause that exception.

+1:

I am experiencing the behavior mentioned above on a large TYPO3 installation (6.1.11). Mount points are being used and errors occur when they're nested.

Christian Hellmuth wrote:

+1:

I am experiencing the behavior mentioned above on a large TYPO3 installation (6.1.11). Mount points are being used and errors occur when they're nested.

As a dirty workaround you can try changing the definition for PATTERN_ENTRYIDENTIFIER to allow a comma.

Thanks Christian. As I am not much of a PHP coder could you perhaps give me a hint where to change that? Or even better, would you happen to have a patch file for that?

Hi,

this is a dirty core hack.
In your TYPO3 source browse to typo3\sysext\core\Classes\Cache\Frontend\FrontendInterface.php
There look for about line 48
Overwrite

const PATTERN_ENTRYIDENTIFIER = '/^[a-zA-Z0-9_%\\-&]{1,250}$/';

with

const PATTERN_ENTRYIDENTIFIER = '/^[a-zA-Z0-9_%\\-&,]{1,250}$/';

this adds a comma and allows cache identifiers with a comma.
Everything that is used as an identifier and doesn't match this pattern throws ' not a valid cache entry identifier.'
After changing the file, clear the cache and make sure@ \typo3temp\Cache\Code@ is empty, and load the page that as affected by the error.

In my case this worked around the problem.
As for side effects, I can't say whether allowing cache identifiers with commas can have any unexpected results.

If it works: Of course as a core hack this will disappear if you replace the source with a new one. So you always have to remember to repeat it.
You can workaround this by using the code from git and having this as a local change, instead of downloading tarballs and replacing them.

Thanks for your detailed explanation.

I think this is an issue that still deserves its fix. Mount points are a pretty common use case, especially on larger websites. And as nesting of mount points is possible and realurl one of the most widely used community extensions, a self-proclaimed enterprise CMS should not fail at this point.

By the way: Will this error still occur in 6.2 LTS or is it fixed there? Any info on that?

Could you please test and confirm (or not) whether the fix described above works for your case?

I have seen the same problem with 6.2 LTS.
I also know that collaborating teams have encountered the PATTERN_ENTRYIDENTIFIER problem and fix on their own.
In 6.2.5 you will find the same definition at line 35 of typo3\sysext\core\Classes\Cache\Frontend\FrontendInterface.php and the same fix still works experimentally.

The problem is that the PATTERN_ENTRYIDENTIFIER is a very basic definition which as far as I know is backported from the TYPO3 FLOW framework.

So it isn't going to be changed "just like that" but perhaps core developers will take a look at it if awareness rises that it is a problem "in the wild".
I didn't get any response on asking about this issue on the newsgroup a year ago.
Perhaps you can try posting again with reference to this bug report.

Okay, so I just applied the fix you suggested and it solves the described problem. The error does not occur any longer.
I cannot tell about possible side effects just yet. That will require some more testing.

This is an open issue that affects the current LTS.

Page trees that used to work with 4.5 or 4.7, and employ permitted TYPO3 Core functionality, throw an exception in the frontend with current LTS.

Also navigations and sitemaps rendered for those trees throw exceptions.

While many users don't care too much about Mount Points it is an issue encountered "in the wild" and should IMHO be acknowledged as a bug.