Bug #76222
open
sys_category_record_mm doesn't get updated when deleting pages and records
0%
Description
After deleting a page with some sys_category selected into the trash, the entry in sys_category_record_mm for that page is still present.
Even after erasing the page from the trash does not lead to an update on sys_category_record_mm.
The same problem exists with records of extensions. I have added a sys_category field by using \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::makeCategorizable(...) for that.
When I delete such an extension record the entry in sys_category_record_mm is still present. My first thought was that it is a mistake within the usage of makeCategorizable() by me,
but since this happens for pages as well this seems to be a bug/missing implementation.
Updating the reference index does not change anything, it tells me the integrity is perfect, which seems strange.
On long term this will lead to an exploding sys_category_record_mm table and inconsistent database state.
Relation to #63918 (was closed due to missing feedback)
Files
Updated by Markus Kobligk almost 8 years ago
Additionally I just saw that the [Ref] column does not show any references when browsing sys_categories in list view.
Neither for pages nor for records this shows any references at all (although they are set) and I can delete a sys_category
without being warned that there are references on that sys_category record.
Updated by Andreas Wolf almost 8 years ago
- Status changed from New to Accepted
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.
Updated by Markus Kobligk almost 8 years ago
Here is a more detailed explanation of the behaviour when using sys_categories (see comment 1) and what this implies for editorial users:
Scenario:
- Define some sys_category named "foo"
- Edit page1 and set "foo" as the selected sys_category
- Edit page2 and set "foo" as the selected sys_category here as well
When I now use the list view and browse to the sysFolder where my sys_categories are stored the [Ref] column is empty (-) for the sys_category "foo".
Since sys_categories are defined bidirectional I edited that sys_category and it shows me the two pages in the tab "items". Switching back to the
list view and showing the "items" field via "Set fields" leads to the same result. The column "items" does NOT show the two pages, but instead it says "N/A".
The information seems to be stored the other way around. When I browse the pages in list view the [Ref] column says 1 for both page1 and page2, since I have
selected the category "foo" in both pages. This behaviour is due to the bidirectional implementation of sys_categories.
The TCA Reference says for MM_opposite_field: Bidirectional references only get registered once on the native side in "sys_refindex".
This seems to be exactly what is happening here, from the technical point of view everything is ok.
But:
With this implementation editorial users (and even admins) have no chance at all to find out if some sys_category is used or where it is used.
Additionally to that I can delete the sys_category "foo" without being warned that it is used somewhere!
From the logical/editorial point of view the implementation should be like in FAL I think. When I browse records in FAL list view the Ref column tells me exactly
if/how often that FAL item is used and when I click on the Ref number it tells me exactly where it is used. Deleting such an item leads to a warning that it is used.
The behaviour for sys_categories should be exactly the same.
The information that my category is used in two pages is there, otherwise the field "items" wouldn't show me the two pages when I edit that category.
The list view should take care about showing the correct number in [Ref] column and when someone clicks on that number it should trigger
the same dialog as in FAL showing the usage of that category. That would be a great improvement and help for any user.
The next step would be to make sure that the relations are recognized when someone deletes a category, there has to be a warning that it is used somewhere.
As said before the information is there, but it does not seem to be recognized/used.
I don't know why the behaviour here is different from FAL relation handling, maybe a design issue, maybe something technical.
Please let me know if you need any further information Andreas.
Updated by Riccardo De Contardi almost 7 years ago
- File Schermata 2017-05-23 alle 22.49.11.png Schermata 2017-05-23 alle 22.49.11.png added
- File Schermata 2017-05-23 alle 22.49.25.png Schermata 2017-05-23 alle 22.49.25.png added
- File Schermata 2017-05-23 alle 22.51.26.png Schermata 2017-05-23 alle 22.51.26.png added
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
Updated by Markus Kobligk almost 7 years ago
Besides the problem e) you mentioned, what about the fact that the table itself does not get cleaned when I delete a record with a category, even when I empty the Recycler?
Is this intended behaviour and still present? Or might this be a bug?
I could understand to leave the entries in sys_category_record_mm until a record is deleted finally via Recycler.
But at he latest when deleting a record with the recycler the corresponding MM entries have to be deleted.
Otherwise the database is inconsistent and the table will grow and grow.
Updated by Bastian Stargazer 3 months ago
- TYPO3 Version changed from 7 to 11
- PHP Version changed from 5.6 to 8.1
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?