Here's a patch that uses the MetatagsFieldProcessor for the metatag_computed field as well. While it does get rid of the extra translation exports, it's likely possible that there is some better solution than this one.
Having this issue as well, MySQL goes away when it tries to cache all the site users (~12k) in cache_entity table, and then dblog does its job by trying to set a single log message for that insert with @message that contains the 85k placeholders.
The patch in #15 does get rid of the error but has issues, including all cids being wrong in all cache tables due to not preserving keys.
Here's a patch that does the following:
- Move the chunking into doSetMultiple() to have it done only once. Not really a fan of the looping the chunks and then the items but here it is anyways. No other logic changes inside the function. Doing it this way it will of course increase the number of inserts by quite much so not sure what kind of implications that would have.
- Preserve the cids
- Update MAX_ENTITIES_PER_CACHE_SET to MAX_ITEMS_PER_CACHE_SET
Also it looks like that the single checkboxes inside checkbox groups get the empty tooltip as well, even though single options only have "Description" and "Helptext" values available for the "Options description display" select.
Here's the YAML export.
Here's a patch for updating the selectors, which should work for newer and older style fieldset templates.
I can confirm that this still happens on 8.x-1.x-dev.
To recap, here are all the steps to reproduce:
- Install clean Drupal and Content Access module
- drush si -y && drush en admin_toolbar admin_toolbar_tools language content_access content_translation -y && drush uli
- Rebuild permissions due to Content Access installation (/admin/reports/status/rebuild)
- Add a new language for the site (/admin/config/regional/language)
- Allow translating the Article content type (/admin/structure/types/manage/article → Language settings → Enable translation)
- Create a new Article in the default language (EN) and leave it published
- Translate the Article in the newly created language (FI in this case) and don't publish it
- Access to both EN and FI pages now return 403 for anonymous user even though the EN page can be seen published on the edit form
- Edit the EN content and re-save it
- Both contents are now visible for anonymous users and the unpublished FI translation shows the red "unpublished" background on its content
Patch didn't apply cleanly against 8.x-1.x, so here's a reroll. This will now include the changes done in https://www.drupal.org/project/content_access/issues/3262813 → as well.
What happened before these changes:
When saving a node, access records were by default created for all translations, because the isPublished() check was done only for the content being saved (not the translations). This meant that saving the published EN content added allowing access record for FI (or any other translations) as well.
What should happen after the patch has been installed:
When saving a node, access records are only created for the translations that are published.
We'd still need to double-check that all this doesn't mess up things for other content access modules (like the quite popular View Unpublished → ).