Actions
Bug #86747
openUsing PersistedPatternMapper has some drawbacks
Status:
New
Priority:
Must have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
-
Start date:
2018-10-26
Due date:
% Done:
0%
Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:
Description
I configured the route of an extension's single page in my config.yaml
of the site management with the help of the PersistedPatternMapper:
routeEnhancers:
Person:
type: Extbase
limitToPages: [67]
extension: Person
plugin: Pi1
routes:
- { routePath: '/{name}', _controller: 'Person::show', _arguments: {'name': 'person'} }
aspects:
name:
type: PersistedPatternMapper
tableName: 'tx_person_domain_model_person'
routeFieldPattern: '^(?P<given_name>.+)-(?P<last_name>.+)$'
routeFieldResult: '{given_name}-{last_name}'
I am facing now two problems:
- In the generated URL for the single page the result (
{given_name}-{last_name}
) is not in lower case like the other parts of the slug (the result is e.g. "John-Doe" instead of "john-doe"). - When using umlauts the slug is e.g. "Mäx-Müstermänn" instead of "maex-muestermaenn".
Hint: In the given example the < and > chars are converted from Redmine to < and >.
Updated by Guido Schmechel about 6 years ago
- Related to Bug #86797: No field value tranformation/URL sanitation when using extbase extension custom field as a route path segment added
Updated by Chris Müller over 5 years ago
- Subject changed from Using PersistedPatternMapper gives 404 error back to Using PersistedPatternMapper has some drawbacks
- Description updated (diff)
Updated by Julian Stock over 5 years ago
This problem is still present and a blocker for everyone who wants to update their TYPO3 v8 to TYPO3 v9.
Updated by Oliver Hader over 4 years ago
... As mentioned above however, special characters in the title might still be a problem ...
Anyway, I understand the use-case. For generating URLs it would be fixable (strtolower, substitute special characters). However, when resolving URLs it's difficult since a direct database look-up is not possible.
Thus, I see two possibilities:
- when
uid
field is used, generation process shall use SlugHelper; resolving process just shall focus onuid
- when
uid
is NOT used, try to perform substitution on database level (LCASE, REGEXP on MySQL - this might be different and to be handled in DBAL for other DBMS like PostgreSQL or SQLite)
Actions