Is this ticket now generically to fix elements that should not have the required attribute? (Because the MR includes additional fixes.)
If so, I will also note that Drupal generates this on input type="range", which also does not allow the required attribute. (https://www.w3.org/TR/wai-aria-1.2/#slider)
While noting that it's been years since I wrote this, at a glance I would say the difference is that this tackles the first bullet point from that other ticket, which from what I can tell the other one makes no attempt to solve. This patch makes no effort to solve the other bullet point, which *does* seem to be getting solved in the other ticket.
As noted, this is just a basic matcher. It doesn't try to search existing anchors, it just assumes anything that starts with # is an anchor.
It could probably be extended to search anchors within an existing editor block, but I'm not sure how this would work in a field or in a layout builder environment when you have multiple blocks on a page, each potentially with anchors, not necessarily served by an editor.
Gotcha. I can understand not wanting to go down rabbit holes. :)
looking at the patch I wonder if the issue was just that the old version didn't have a period in front of "csv"...IIRC Windows is horrible at guessing what things are if files don't have a proper extension, and many users don't think beyond double-clicking the file.
kpaxman → created an issue.
We have moderation states of draft, needs review, published, and archived. Draft and needs review don't change the published status of the node. We found that views would always claim that the node was in the published state when there were newer draft or needs review revisions. So that's why we came looking at this module...but I don't discount that there may be a "plain Drupal" solution, we just haven't found one.
I believe I have the same concern as you, though I have to admit I'm not clear on how your posted workaround solves the issue.
I went, I think, in the other direction - if the contents have a class identifying it as being in the modal, then any modal-specific CSS can be written in your admin theme, e.g. to remove margin when in the modal but not in "regular" use, something like .layout-builder-iframe-modal .whatever { margin: 0; }.
I'm attaching a patch that adds this class.
What would be *really* neat if it worked *with* Layout Builder Restrictions, and just hid/prevented use of templates that contained elements that weren't allowed.
As it is, we're probably going to have to figure out how to restrict it to just the content types that have common options. (Can't have people injecting multi-column sections into content types that we don't allow them, for example.)
I think that the Pathauto transform options should only appear/take effect if the Pathauto module itself is actually enabled.
Additionally, it is possible to check both "transform dashes..." and "transform...based on pathauto" at the same time, but it looks like in the code, you can only do one or the other. I think it makes *sense* to do only one or the other, so I'd say the UI should change somehow so only one or the other can be selected (maybe a dropdown, with "no transformation" along with the two transformation types, as the options?).
Aside from that, it does seem to work, but it seems to be set up differently than the default option, including exporting config as "1" instead of "true" - it would be nice if a maintainer could weight in on the method used here.
This ticket specifically says it is for the 8.x-1.x branch, so setting back to that.
The matching issue for 8.x-2.x seems to be #3086817: Prepare for the path alias changes in Drupal 8.8 → .
FWIW, regardless of this, I was unable to get either patch to apply against either version.
I see #149 says that #146 and #148 are not needed, and #164 seems to be an extension of those. Should anyone outside of the people posting those patches be using them? I'm not sure what the point is of an enable option, given that is just honoring existing config.
I have not tested this, but I note that in some cases "midle" is used instead of "middle" - is this intentional/due to typos elsewhere?