Bug #91247

FrontendRestrictionContainer does not take language into account / There is no doctrine-dbal LanguageRestriction

Added by Leonie Philine Bitto over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Database API (Doctrine DBAL)
Target version:
-
Start date:
2020-04-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

This might be either:

Obviously an implementation of the missing feature would be desirable.

Said documentation page contains the following intro:

The ctrl section of a tables TCA array specifies optional framework internal handling of soft deletes and language overlays: For instance, if a row in the backend is deleted using the page or list module, many tables are configured to not entirely drop that row from the table, instead a field (often deleted) is set from zero to one for that row. Similar mechanics kick in for start- and endtime as well as language and workspace overlays. See the [‘ctrl’] chapter in the TCA reference for details on this topic.

These mechanics however come with a price tag attached to it: Extension developers dealing with low-level query stuff must take care overlayed or deleted rows are not in the result set of a casual query.

This is where this “automatic restriction” stuff kicks in: The construct is created on top of native doctrine-dbal as TYPO3 CMS specific extension. It automatically adds WHERE expressions that suppress rows which are marked as deleted or exceeded their “active” life cycle. All that is based on the TCA configuration of the affected table.

Almost all of what is described here has been implemented via Query Restrictions. (And the API is really nicely designed and very usable.)
The only TCA feature which is missing in the existing Query Restrictions implementation is Language.

The ideal solution:

  • Language Overlays should be implemented for the query builder. At least, akin to the WorkspaceRestriction, a sys_language_uid restriction based on the translation (& fallback) mode and current frontend page language should be made.

Minimally:

  • The documentation page should be updated, stating clearly that for multi-language sites the Query Builder cannot be used; or better stating which steps exactly a developer must take if she wants to select only records in the current language (and automatically apply language overlays), like one would do via $cObj->getRecords().
#1

Updated by Leonie Philine Bitto over 1 year ago

  • Subject changed from FrontendWorkspaceRestriction does not take language into account. to FrontendRestrictionContainer does not take language into account.
#2

Updated by Leonie Philine Bitto over 1 year ago

  • Subject changed from FrontendRestrictionContainer does not take language into account. to FrontendRestrictionContainer does not take language into account / There is no doctrine-dbal LanguageRestriction

Also available in: Atom PDF