TYPO3 Core

Hello

Thanks for taking care of creating an issue.

Could you provide more context to the performance issue that you have?
Especially TYPO3, php and database version.

Also, an example extension, with the mentionned TCA would be helpful.

And an screenshot of the browser's devtools showing the rendering time of the page (to see if it is a server issue or a browser rendering issue).

Cheers.

Providing TCA examples etc. would require more time as I do not want to provide the TCA which is used in a customer project. As I have time, I provide a demo ext. along the Dev-Tool Screenshot. I keep that in mind and hope to be able to provide that somewhen soon. Thus I guess it will not happen within the next months. I am very much up for this feature, yet have other higher priorities atm.

In the meantime I provide a more in depth description:

We have a Model "Campaign" which has 5 tabs. In the general tab are a few simple fields and relation to an other Model "CampaignValue". Editors can CRUD "CampaignValue"-Records to schedule Record-Updates. It also includes a "CampaignValue"-History-Table. As manual changes of "Campaign" leads to a new "CampaignValue"-Entry this list can become quite long over the time. Further, each Campaign is associated to a "Product" and in the Campaign selected "Product"-Data can be overwritten. Nowadays a lot of fields can be overwritten. These fields are RTE, IRRE, 1:n relations and simple fields such as input. The Model Product has a bunch of tabs and relations either, yet I guess the Campaign example is fine.

I hope so far you get what I am talking about.

All the data needs to be loaded, yet not every may be required when we want to edit a record. Let's say we only want to change a few properties, only these would require being loaded. So, for example all of these are on the first tab, then only the first tab is loaded upon opening the record. Then we do our changes, hit save and are good to go.

Of course, if there're displayConds, these needs to be considered by a lazyload feature. I assume there's more to consider. I rate the complexity to medium / hard.

We're also making quite heavy usage of the bookmark-feature to access our test records quickly. So, we end up in the regular TCA Edit-View always. Hence, I am aware of the option to edit selected properties via TCA-List-View.

Here are a few ideas:

- Lazyload needs to be enabled per table.
- Lazyload can be enabled for certain fields
- Lazyload can be enabled for tabs

An other reason for this feature:
T3 BE allows editor to work on their mobile phones already. Loaded content can be reduced and therefore editors can work more fast via mobile phones.

Do you have more info about the structure of the TCA and their inline elements?
For example, one known performance bottleneck happens when you have a TCA table with 1:n IRRE relations to another TCA table and that child tables "label" in the TCA isn't a simple db field of the same table, but for example the relation field to its parent. Something like:

// TCA config of the 1:n irre child
return [
    'ctrl' => [
        'label'                    => 'title',
        'label_alt'              => 'tt_content', // the relation field to its parent table
        'label_alt_force'.    => true,
        'sortby'                   => 'sorting',

TYPO3 would then automatically look up the label of the parent table from the "tt_content" relation field and show it in the TCEForm for the children elements. But this could easily turn into a performance bottleneck in several cases. For example, the "l10n_parent" selects would then all need create many similar db calls to fetch these labels from the foreign table and this would easily blow up the number of db calls in the backend for each new 1:n irre record that is added.

I'm also having this issue with a frontend user record for example. Once you click on editing the fe_user record, there are related records with several 1000 records as a dropdown field for example. Imagine a frontend user that has a company that you can select. In this case the dropdown is not the best option to choose a record (but only one can be selected, so the "group" is also not optimal).

In Laravel Nova (payed product) exists a way to define a relationship as searchable. That will create a searchable dropdown: https://nova.laravel.com/docs/resources/relationships#searchable-relations

I have an old version of nova and could give insights in how they implemented this. This would definitely be a killer feature for TYPO3!

In general we could get a lot of inspirations from Laravel Nova.

@Simon Schaufelberger We do have a "suggestWizard" that would probably be usable? The technique should be pretty straight-forward, I doubt we will need to rip it out of any other system. ;)

It's "just" REST- and UI-legwork... and I do agree, optimizing this would be great to have.

Yes, we do have a suggestWizard but that is not usable for dropdown values (single values), or? I just don't want to misuse a group field for that and set max to 1.