TYPO3 visibility and Doctrine DBAL a.k.a. Restrictions

Updated 2016-06-03
Details for restrictions.

When it comes to visibility (e.g. flags like „hidden“, „starttime“ or „deleted“) TYPO3 implements a lot of magic, that works differently in the Frontend and in the Backend. Imagine a list view for example. In the Backend list all records flagged with „hidden“ are shown while in the Frontend list they are hidden. In the past (before the change to the Doctrine DBAL facade that I mentioned in my earlier post [1]) that was archieved by the function ContentObjectRenderer->enableFields().

And now this will change again. Once change 48049 [2] is merged into the master, this will simplify things drastically. So, what you are reading right now is brand new stuff, stuff that is even only in code review at the moment of writing. Please be aware of this and forgive me for any misinformation that might be in this post.

The approach of the new TYPO3 Doctrine DBAL facade is to enable by default the most common restrictions and transfer the responsibility to show or hide more items to the developer. Therefore „delete“, „hidden“, „starttime“ and „endtime“ restrictions are always enabled and need to be actively removed if necessary. Other restrictions need to be provided manually depending on the desired result.

In the following examples, I rely on the fact that you already have a $queryBuilder as described in the last post [1].

Show everything

This command will disable all restrictions and force the queryBuilder to return all items including the deleted ones. A nice example would be the recycler, where you can restore deleted items.

Show active and inactive items

„Inactive“ items are those, that are either hidden or would not be displayed because starttime isn’t reached or endtime has passed. These are the classic „enableFields“, so a good example for using this is a typical Backend list, where all items, even inactive ones, are listed.

Show active and deleted items

I can’t imagine any use case where you would want to show all active items together with only the deleted ones, but here is the example, for the sake of completeness.

Best practice

I would not suggest to simply remove some restrictions. Because you might not be sure, with what preset of restrictions you were starting and the next developer would have the problem to determinate, which restrictions are applying and whose not. If I need to change restrictions I always like to do a fresh start to have the final definition encasulated within the range of as less lines as possible.

So in this example we remove all applied restrictions and add only two.

What is possible?

At the moment of writing, there are several restriction classes ready at your service.


Only non deleted elements will be affected.


Only non hidden elements will be affected.


Only elements without a start time or a start time lesser then „now“ will be affected.


Only elements without an end time or an end time greated then „now“ will be affected.


Only elements connected directly to the root page (UID = 0) will be affected.


You have to pass on the FE user group IDs as an array, but as of right now I am still uncertain, how to do so.


Don’t ask as I have no clue about workspaces.


Didn’t I tell you not to ask?

Own presets

You might ask „Is it really necessary to always remove the default restrictions with a lot of calls? It would be much easier, if I could just define a preset / context (e.g. „Backend“).“ I agree and from what knowledge I gained by looking at the code, the query builder seems already prepared for that kind of requirement.
Have a look at \TYPO3\CMS\Core\Database\Query­\Restriction­\DefaultRestrictionContainer . That container is the default one, bound to every query builder upon construction. So it should(!) be easy to define your very own „BackendRestrictionContainer“ based on the default, were you initialize the global $defaultRestrictionTypes only with DeletedRestriction::class and hand it over to the query builder.

Additional Links

[1] Migrate TYPO3 database wrapper to Doctrine DBAL
[2] Doctrine: Simplify restriction handling

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.