I may not be able to test the fix right away, but {{ :number|0 * 3 }} valid as a basic calculation, like, multiplying the number (or 0 if not set) by 3?
Unfortunately it seems this is not converting block ownership to anonymous, leading to their deletion when the user is deleted.
My branch provides a potential fix. (It seems to work for us, not sure if there would be any side effects.)
MR now attached, asking for review.
kpaxman → created an issue. See original summary → .
Looking at the user_expire module page, but without trying it out, it seems that the difference is that that module locks the user out completely, where this request is just to remove a specified role. (For example, you want to expire their access to edit the site, but still be able to log in to fill in an authenticated form.)
I'd prefer it to be behind an "enable feature" checkmark, FWIW, as someone who is running way too many modules already. :)
While I have asked Eric put together an update hook that only alters the one attribute, I do sort of wonder what other modules do when they update their views - I feel like there is an argument that any alterations to a view that you don't have full control over should be done programatically, for precisely this type of situation.
And I do feel fairly strongly there should be *some* sort of update hook, because if you're on the older version of the view, you are no longer redirected away from the field editing page when you save, because the update that changed the view also removed the code-based redirect. This makes it seem like the module isn't working.
Follow-up issue to provide an update hook: ✨ Update hook for redirect from a FillPdfFieldForm back to its parent FillPdfForm Active
Tentatively, it seems like this should have had an update hook to modify existing views. Our older sites running this module do not have the destination parameter.
It's working for me, but it would be nice if someone outside the organization could test. Setting the status to "needs review" in the hopes that happens.
Also important due to the recently announced library vulnerability. https://github.com/advisories/GHSA-ghg6-32f9-2jp7
Above is the image from the 2nd comment - it loads for me.
Without this patch, the scheduling options appear "loose" at the bottom of the form, instead of in the tabs at the side.
I confirm this patch fixes the issue. Setting to RTBC, perhaps the maintainers can weigh in on #3423469-4: Scheduling options appear in wrong place on Quick node clone forms → should be pursued or if this is good enough.
My MR in theory preserves the fix for Gin without having it break other themes. I did basic testing with Gin and the Gin Toolbar to confirm the icon was still visible there, but I don't know enough about Gin to test more than that.
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?