TYPO3 Core

My gut feeling is that this problem comes from the relations to categories being "owned" by the categories and not the record using the categories. There’s a technical reason for this: in MM tables, a table and field name can only be set for the foreign side, not for the owning side (=> potentially, a lot of different record types can be referenced in one field, but only from one type of records (it is possible to also use MM_match_fields to create relations with multiple table–field–combinations as the owning side).

Category fields in the core are of type "select" with sys_category_record_mm as the MM table. "tablenames" and "fieldnames" are match fields for the foreign side of the relation. DataHandler treats the category-using fields as reference fields (cf. isReferenceField()).

The owning side of a category–record relation is a fixed field, "items" in table sys_category. The new fields for category relations are inserted into this field’s TCA config entry (config.MM_oppositeUsage.<tablename>, an array of field names each).

Deleting a page is performed by a hook in EXT:version, not by DataHandler itself; but the hook is in turn using DataHandler, even the same instance, so I don’t suspect that there is some information lost along the way, leading to this bug (this has happened to me before, therefore I’m sensitive to such bugs).

Te relations to categories are also not removed from the RefIndex, which is corrct, as only the record using the category gets its "deleted" flag set. TODO find out if the RefIndex entries are deleted once the record is finally deleted by the recycler.

TODO: File relations are being deleted (in deleteRecord_procBasedOnFieldType) because they are of type "inline". It might be that a similar mechanism is missing for regular reference fields. In "normal" reference tables, no deleted field is present however, therefore this cannot be easily compared. MM tables don’t even have a TCA entry, as they don’t need to be directly editable.

I tried to test the behavior reported in comment 3 on TYPO3 9.0.0-dev (latest master) in this way:

1) Create a category "FOO FOO"
2) create a page PAGE1WithFOOCAT and assign the category FOO FOO
3) create a page PAGE2WithFOOCAT and assign the category FOO FOO

RESULTS:¶

a) In list view, I was not able to see the [_REF_] field
b) clicking on the info button of the category it shows the pages where the category has been assigned (see attached Schermata 2017-05-23 alle 22.49.11.png)
c) This information is also visible editing the category (see attached Schermata 2017-05-23 alle 22.49.25.png)
d) if I go to the parent page of the two pages > list view > set fields > I can add the "categories" field (see attached Schermata 2017-05-23 alle 22.51.26.png)
e) it is still true that I can delete the category without a warning

This is still an issue in the current versions.

We copied a page-root which contained lots of sys_categories, and all the records stored on that original page-root was copied too (that was not our intention). So we have a duplicate of each sys_category including all sys_category_record_mm relations, but the relating items of one category exist only once (which is good, at least).

To clean up the mess, we tried starting to delete all the new/copied categories, but their related MM entries are kept in the DB. Removing them manually seems to be dangerous, because we can't estimate which side-effects that might have in the depths of TYPO3s structures.

Wouldn't it make sense add a clean-up function to "cleanup:deletedrecords" to delete such records if the category does not exists anymore?