Patch applied on 1.0.0-beta4, fixes the broken links.
Accessing the listing using the `administer feedback message entities` permission works with the latest MR and is better already as now the collection can be accessed. Attached the change as a static patch for composer projects.
Anyhow it might need to be re-thought though as the current description for the permission is "Allow to access the administration form to configure Feedback message entities.", which kind of implies that is meant to be much deeper permission, and it's also defined as `admin_permission` in the FeedbackMessage entity.
A new `access feedback overview` permission could make sense, as that's the way the collection route permissions are usually defined. For example Taxonomy has collection_permission = "access taxonomy overview" in its Entity definition.
Along with the Menu Link module patch for Menu Admin Per Menu (from https://www.drupal.org/project/menu_link/issues/3092282 🐛 This module breaks the menu system with used with Menu Admin Per Menu Active ), combined with the current changes in this MR, the field is appearing correctly and by quick testing there seems to be no issues on 8.x-2.0-alpha6. Will be testing this further still.
Attached is a patch with the current MR changes, for static composer patching.
Actually with some further testing the Menu Admin Per Menu perms aren't fully respected, as all of the available menu permissions are being added into the array.
So, if the user has perms by MAPM to only administer the "Main" menu, but the Menu field configuration allows placing items into "Footer" and "User menu" as well, the latter ones will be shown to the user too. So this does fix the issue with the access to the field being FALSE, but the individual menus inside the field aren't being limited.
Confirming that the MR does fix the menu link field being inaccessible.
Attached is a patch with the current MR changes, for static composer patch.
MR63 working as it should, the error is no longer appearing with faulty URLs. Attached is a patch from the current MR63 changes to get a static patch for composer installs.
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 → ).