[TYPO3-dev] Mountpoint issues in 6.1/6.2 - Question about PATTERN_ENTRYIDENTIFIER in TYPO3\CMS\Core\Cache\Frontend\FrontendInterface

[Christian Reiter]

Hello everyone,

I have migrated a large site from TYPO3 4.5.30 into updated versions 
running on 4.7.15, 6.1.5 and 6.2 (recent master from git, as the 
problems with the Package Management and loadorders made 6.2beta1 
unusable for this project)

I've run into one interesting problem that doesn't occur in 4.7 but hits 
in 6.1 and 6.2:

A plain sitemap (standard TYPO3 sitemap content element) crashes with an 
exception '"x,y" is not a valid cache entry identifier' thrown from 
TYPO3\CMS\Core\Cache\Frontend\VariableFrontend

public function get($entryIdentifier) {
if (!$this->isValidEntryIdentifier($entryIdentifier)) {
throw new \InvalidArgumentException(...
}

An example for the identifier is "147_33-245,147-430_0_0_0". Note the comma.

The site uses mountpoints aggressively, including nested mountpoints. 
These haven't been a problem though in the entire history of the site 
that included 4.1 through 4.5 and then 4.7

The offending IDs can be traced back to a mountpoint situation.

The pages can be navigated and called normally, so rendering Typoscript 
navigations for these mountpoint trees or browsing/displaying the pages 
in FE is no problem - not in 4.x and not in 6.x.

But 6.x can't make a sitemap for them.

BTW RealURL is the same version 1.12.7, with require_once and 
ext_autoload fixes in all installations (4.7 doesn't really need the 
require_once lines and 6.2 doesn't accept them)

If I follow the code, I see that function isValidEntryIdentifier comes 
from TYPO3\CMS\Core\Cache\Frontend\AbstractFrontend, which implements 
TYPO3\CMS\Core\Cache\Frontend\FrontendInterface, which defines

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

and anything that doesn't match that throws the exception.

If I simply manipulate the core code and add the "comma" character which 
appears in the identifier "147_33-245,147-430_0_0_0" the sitemap works.

Actually TYPO3 4.7 has the same PATTERN_ENTRYIDENTIFIER but the 
difference is that 6.x has TYPO3\CMS\Core\Utility\RootlineUtility->get 
which uses $cacheIdentifier = $this->getCacheIdentifier() and that uses 
the cache interface.
4.7 still uses t3lib_pageSelect::getRootLine which is built very 
differently.
And it is getting the rootline where the exception is caused.

Now of course hacking the source is not a clean solution.

I'm familiar with TYPO3 style 6.x XClassing, and this has worked for me 
in such situations where I needed it (for instance porting the old 
fl_langtranslate to 6.x - i.e. extending 
\TYPO3\CMS\Core\DataHandling\DataHandler).

But Xclassing TYPO3\CMS\Core\Cache\Frontend\VariableFrontend didn't 
work, and I guess the interface and abstract can't be xclassed anyway.

As I understand the cache interface is a backport from FLOW.

It seems that in the past there have been situations where types of 
cache identifiers were needed in TYPO3 CMS, but didn't occur in FLOW, 
were initially not supported by the backport. At least that is how I 
understand the discussion here: 
http://typo3.3.n7.nabble.com/RFC-10741-Create-version-of-page-crashes-in-Cache-td202453.html

What is the best approach in this case?

It's a bit strange to tell the client he can't have a TYPO3 sitemap 
anymore when he had one since 4.1. But hacking the core is really bad.

Any tricks?

Best regards,

Christian