Multilanguage support for counting of relations
As stated in Bug #5951 the counting of relations seems to be broken when using a mutlilanguage setup.
I tracked down the issue to the function processDatamap_afterDatabaseOperations in class class.tx_tagpack_tceforms_addtags.php where in case of a translated page the function is called twice (or more, depends on the number of translations).
The first call gets 0 for $caller->checkValue_currentRecord['hidden'] and NULL for $caller->datamap[$table][$id]['hidden'] which leads to a $command of 'unhide'.
This command increments the relation counter by one.
So for every save-action on a translated page which has tags assigned the relations-counter for that tag gets incremented.
#1 Updated by Jo Hasenau over 9 years ago
- Status changed from New to Accepted
- Assignee set to Jo Hasenau
- Priority changed from Should have to Must have
Since this is not about the sophisticated stuff we talked about in Elmshorn but just about making the tagpack work with multilanguage setups at all, I just thought about a quick (and dirty) solution.
IMHO the problem is not that the hook function is called multiple times, since this is the desired behaviour. In fact there is just some action missing while translating the stuff AND additionally there should be a change in the tagclouds methods to get the number of relations.
The missing action is: Each translation process MUST create a new relation to the new record and save it with the proper sys_language_uid, which means that in case of pages the table "pages_language_overlay" must be in the list of taggable tables (maybe we can add it automatically, if pages is i the list). Then we will get the correct number of relations for each tag in a certain language by counting the MM records with the correct sys_language_uid. This gives us two options:
1) The number of relations to a certain tag can still be found in the field of tx_tagpack_tags, but it will not be used for the tagcloud anymore. This means we had to count the number of relations while creating the tagcloud (which would significantly decrease performance)
2) The number of relations to a certain tag can still be found in the field of tx_tagpack_tags, but we will translate any tag as well, if the translation doesn't exist yet and save the number of relations separately for each of the languages. This way we could still get the number of relations from the tag record itself.
The problems with the second approach are:
What if there are tags that don't have an entry in the default language?
How to handle stuff when the translation hasn't got exactly the same meaning as the original and has to be replaced with something else for some of the tagged items?
What, if the original tag gets removed from the original record - should we keep the translated tag(s) for the translations or remove them?
You see - it's not that easy and the second approach will in the end lead us to the sophisticated stuff we talked about in Elmshorn :-)
The first approach will be much easier to realise, since the tags woudln't care about translations at all. This means: Each tag can be assigned to any record (regardless of the record's language) and if you want a translated tag, this would be treated the same way as a new one and still have no sys_language_uid. This way we can still get tagclouds for a certain language just by checking for the sys_language_uid of the MM relations. Maybe we can introduce a kind of counter cache to avoid counting the relations for all the tags each time the tagcloud has to be generated. So this cache will be updated when something changes in the backend, but it will be treated separately from the relations field. Maybe this could be a serialized Array saved to an additional field of tx_tagpack_tags.
Any other ideas?
#2 Updated by Jo Hasenau over 9 years ago
I just thought about the "serialized" Array and came to the conclusion that this wouldn't be of much help since we couldn't use it for sorting by number of relations in a certain language during MySQL queries.
So I guess a caching table would be the better approach for a multilingual tagcloud.
It could be automatically filled once within a given time frame or based on a flag that will be set at each change happening in the backend. So there would be only one FE request with a decreased performance, while the rest would be still as fast as possible.