Sorry, I closed the 10.4 MR, I wasn't aware of the process.
And yeah, I see now that this can affect other attributes too but I'm not quite sure that reverting the stricter validation should be the way to go, because the need for that seems also valid for me.
The linked issue is just part of the problem. There are other problems with the config schema as I listed in the description. It affects any view which uses the DraggableViews field and/or the DraggableViews Weight sort. If the config schema checker is enabled, it will fail while saving the View and results in a WSOD.
morvaim → made their first commit to this issue’s fork.
morvaim → created an issue.
The validation is indeed triggered on any "overlap" but is that a problem? If an attribute or tag is already enabled by another plugin then that attribute or tag can be used in Source editing mode when editing a content. So it can make sense to not add it as a duplicate to the "Manually editable HTML tags" list if it is already allowed and can be used. Class attribute is an exception in this regard because although the Style plugin adds it in its definition as an allowed attribute, in reality it is not allowed but only those specific classes are allowed which are added to the "Styles" list. This is why it is not "valid" to make the validation fail when someone tries to add the class attribute to a tag in "Manually editable HTML tags" in my opinion.
morvaim → changed the visibility of the branch 10.4.x to hidden.
morvaim → made their first commit to this issue’s fork.
Looks good to me.
Content revision: Moderation state needs to be set, after setting up a Workflow, see attached images.
I couldn't replicate this problem. If the user has the View any unpublished content then all moderated content is listed regardless of `hook_node_access_records()` and `hook_node_grants()` implementations. Couldn't be that the problem here is that there is a "hidden" step during configuring Content moderation and the Content moderation view needs to be updated, because the Content revision: Moderation state filter needs to be configured and until that no content appears on the moderated content listing page?
Hi @nathanhealea,
I would like to try to reproduce what you described and I would need more context. In the first scenario from which Drupal core version did you perform the update to 10.3.5? Was the patch applied during the update? Which related permissions do content editors have on your site? Is the content which was visible for non-authenticated users but not for content editors published or unpublished? And same question for the second scenario: was the content published or unpublished which disappeared? Did the content disappear for all kind of users?
Uploading a new 10.3.x backport, because 10.3.4 introduced changes in `core/.deprecation-ignore.txt` (https://git.drupalcode.org/project/drupal/-/commit/83a80f66982d40ea7cb83...) and the patch doesn't apply anymore. I removed all test related changes from the patch, so those won't cause trouble in compatibility.
Ok, I realized a callable can be an array of a class and a method name, so I don't know why I get this error message.
morvaim → created an issue.
Created a new 10.3.x backport patch from the most recent changes.