TYPO3 Core

This is the concrete call in ext_tables.php:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable($_EXTKEY,'tx_regionalobject_domain_model_regionalobject','categories');

the field exists in ext_tables.sql and of course in the database

I think the TCA definitions are just built too early.

He meant: works with 6.2.0, broke since 6.2.1. Might be related to the introduction of TCA-overrides (#57942) though that should not break existing things.

Same problem. Most likely related to overrides.
Because from Bootstrap->executeExtTablesAdditionalFile() the applyTca() is gone.
It is now done in applyTcaOverrides.
However instead of using
\TYPO3\CMS\Core\Category\CategoryRegistry::getInstance()

The registry is injected and is therefore a different instance then the one where makeCategorizable adds the category information.

CategoryRegistry is a singleton. So I guess you should receive the same instance.

Just my thoughts on that:

A functional change between one big release and a patch (eg. 6.2.0 -> 6.2.1) should never take place, mark it as deprecated and use the new approach in 6.3
If someone uses the new approach the benefits will be given i think, so ensure backwards compatibility within version 6.2. All Extensions that work with 6.2.0 should also work with 6.2.*.

Splitting up TCA definitions in 2 files anyway is bad, (i hated that weird dynamicConfigFile bullshit too) especially for new developers.
Maybe it would be best to have something like that in your tables TCA:

$TCA['table']['columns']['categories']['config'] = ExtensionManagementUtility::getCategoryFieldTCAConfig('table','categories',array());

Like you can use:
ExtensionManagementUtility::getFileFieldTCAConfig

Philipp Wrann wrote:

A functional change between one big release and a patch (eg. 6.2.0 -> 6.2.1) should never take place, mark it as deprecated and use the new approach in 6.3
If someone uses the new approach the benefits will be given i think, so ensure backwards compatibility within version 6.2. All Extensions that work with 6.2.0 should also work with 6.2.*.

I totally agree in general, but in this case, how should it have been done?

The category fields added were not changeable because applyTca was executed after ext_tables.php, if we move applyTca before ext_tables.php then we could change category fields there again, but cannot add them in ext_tables.php because TCA is already applied. See the chicken/egg problem here?
Would be great if you had an idea how to theoretically fix that without breaking something, then I'm happy to implement it.

This really is a chicken/egg problem: applyTca before ext_tables.php then you cannot register any more, applyTca after ext_tables.php then you cannot modify the applied TCA any more.

So where should we put it without breaking something?

Splitting up TCA definitions in 2 files anyway is bad, (i hated that weird dynamicConfigFile bullshit too) especially for new developers.
Maybe it would be best to have something like that in your tables TCA:

$TCA['table']['columns']['categories']['config'] = ExtensionManagementUtility::getCategoryFieldTCAConfig('table','categories',array());

Like you can use:
ExtensionManagementUtility::getFileFieldTCAConfig

Yes. This is what should have been done, it hasn't because the goal has been to also create the database field automatically (I guess).
Nevertheless such API would be good to have in exchange (or in addition) to the current API.

Helmut Hummel wrote:

Splitting up TCA definitions in 2 files anyway is bad, (i hated that weird dynamicConfigFile bullshit too) especially for new developers.
Maybe it would be best to have something like that in your tables TCA:

$TCA['table']['columns']['categories']['config'] = ExtensionManagementUtility::getCategoryFieldTCAConfig('table','categories',array());

Like you can use:
ExtensionManagementUtility::getFileFieldTCAConfig

Yes. This is what should have been done, it hasn't because the goal has been to also create the database field automatically (I guess).
Nevertheless such API would be good to have in exchange (or in addition) to the current API.

Ok, thought about this again. The scope of something like ExtensionManagementUtility::getCategoryFieldTCAConfig and ExtensionManagementUtility::makeCategorizable is really different.
If you introduce a new table and want to have it categorizable, then just write the TCA for it (currently no support for you in that regard) and put it into Configuration/TCA/<table_name>.php and you are set.

Do not use ExtensionManagementUtility::makeCategorizable when introducing tables yourself.

ExtensionManagementUtility::makeCategorizable fits perfectly to easily add a category field to an existing table. This can be done in ext_localconf.php and /Configuration/TCA/Overrides/

However I would be fine introducing ExtensionManagementUtility::getCategoryFieldTCAConfig in 6.2.x if somebody wants to do this.

When I write something that should be categorizable maybe I don't want to think about what TCA makes it categorizable but just use the function for that? That's also how extension-builder (soon to be released version) does it - independent of whether it's an existing table or if you just defined it in the very same class.
I guess you mean it just won't work? So if you define your own TCA and want to use makeCategorizable, would the makeCategorizable() then need to go into a separate TCA-overrides-file (inside the same extension) to make it work?

Ok, thought about this again. The scope of something like ExtensionManagementUtility::getCategoryFieldTCAConfig and ExtensionManagementUtility::makeCategorizable is really different.

If you introduce a new table and want to have it categorizable, then just write the TCA for it (currently no support for you in that regard) and put it into Configuration/TCA/<table_name>.php and you are set.

I agree. I think we need both functions. One for adding TCA to an existing table and one to help extension authors to provide category fields themselves as part of their extension (e.g. tx_news).

Stefan Neufeind wrote:

When I write something that should be categorizable maybe I don't want to think about what TCA makes it categorizable but just use the function for that?

True, but this never worked.

That's also how extension-builder (soon to be released version) does it - independent of whether it's an existing table or if you just defined it in the very same class.

We need to fix the core first before we can say what code the extension builder should create.

I guess you mean it just won't work? So if you define your own TCA and want to use makeCategorizable, would the makeCategorizable() then need to go into a separate TCA-overrides-file (inside the same extension) to make it work?

Yes. Introducing a new table and at the same time making it categorizable never worked.

[EDIT] Behavior also changed from 6.1.0 to 6.1.1

Here a matrix that will help on changes in that area. Any change should add more + than we had before.
Judging the change introduced in 6.2.1: it added many + but to do so we had to give up one, that is use makeCategorizable in ext_tables.php

[1] In same extension
[2] Was buggy for EM
[3] in ext_tables.php
[4] in 6.2.1 changes to TCA created by CategoryRegistry can only be overridden in ext_tables.php

[EDIT] [6] and [7] is fixed with #58039
[EDIT-2] Added failing case to table
[EDIT-3] Fixed failing case to table

[1] In same extension
[2] Was buggy for EM
[3] in ext_tables.php
[4] in 6.2.1 changes to TCA created by CategoryRegistry can only be overridden in ext_tables.php
[5] new API: CategoryRegistry::getTcaFieldConfiguration()
[6] not the case for new API and also not the case when makeCategorizable is used in Overrides/file.php
[7] This is true when calling makeCategorizable from Overrides/file.php which has the downside, that the DB field will not be added during DB compare any more and has to be added manually
[8] TCA ctrl section of table must be defined before calling makeCategorizable !

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29560

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29560

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29560

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29560

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29560