+1 here as well for off by default. i almost always end up hiding these.
Duplicate of π Error: Call to a member function label() on null in Drupal\menu_link_content\Form\MenuLinkContentForm->form() (line 99 of /var/www/html/docroot/core/modules/menu_link_content/src/Form/MenuLinkContentForm.php). Fixed . Fix is in D10.3-dev, 10.2-dev, so should be in 10.2.5 (and, of course, 10.3 when stable comes out). https://git.drupalcode.org/project/drupal/-/merge_requests/7228.diff is the patch file if you want to just add to composer.json.
Nice one, thanks for the custom module. Simple enough and certainly contrib-worthy until this is addressed in core. In our case, the Event node type has a tab for admins to see registrations, which of course don't apply to other content types. Thanks again, @aleix.
Working for me as well. Hope to see this passing tests and RTBC soon :) Thanks!
I tried for way too long to manually make things match up for this to work as expected, but simply recreating it using the "Duplicate as Data Export" option was all it took. Not sure what had gotten messed up under the hood for it to stop working, but thanks for the tip @tce!
Just an additional note that this has a side effect of changing how clean_class
twig filter works. For example, we had a block which had:
{% set classes = [
'block',
'block-' ~ configuration.provider|clean_class,
'block-' ~ plugin_id|clean_class,
] %}
Previously, the plugin_id had its : stripped out and the css was written and applied to that class. After this post, the class name changed because clean_class
no longer stripped that out. Not a huge deal, but something I hadn't anticipated and had to do a (very minor) css update to address. I would assume there could be other unexpected side effects for other places/modules that use the cleanCssIdentifier
method of this class.
No time to really evaluate more deeply, but a quick update that this doesn't seem to work as of Drupal 10.1.6.
They take completely different approaches:
- Group Webform - https://www.drupal.org/project/group_webform β - requires the patch β¨ Entities identified by strings as group content Closed: won't fix which is not going to be merged into Group core and thus is only able to be used with that patch and with Group v1. The approach here was to make webform entities themselves group_content. I personally do not recommend using this module for those reasons.
- Webform Group - https://www.drupal.org/project/webform_group β - does not depend on the patch and works with Drupal 10 and latest Group 3. The approach, however, is very different and (only?) allows access to a webform based on the user's role in the webform node's owning group(s).
Hope that helps.
@loze While that would definitely be a great feature, it doesn't really fit into the scope of what's being addressed in this issue. See https://www.drupal.org/project/media_embed_view_mode_restrictions β contrib module which was created out of #3308069: Provide per-bundle configuration for embeddable view modes β as a potential solution (tho it doesn't have a D10 release yet).
I find myself adding this patch to every build and haven't seen any issues. Setting as RTBC.
I just found β¨ Add advanced option to display children of current menu item Needs review which does some of this and I updated my patch to (hopefully!) be formatted correctly and it incorporates all of the options there as well as additional ones from menu_block.
scotwith1t β created an issue.
I don't know about others but, to me, removing the ability to link media altogether is not a viable solution. Linking media is a critical function for many sites.
Worth noting that the Content region is specifically called out in the title of this issue and description because I did debug some to find that if the masquerade block is placed in another region, this does not happen, so there's a workaround there.
scotwith1t β created an issue.
Actually the latest thing I was noticing this on was in the permissions screen but anywhere roles are used Iβd love to see it sorted by role weight.
Latest version of Group shows them grouped by Outsiders, then Insiders, then Individual scoped roles. Still would love to see this sorted by the role weights. Thx for considering!
Thanks so much, folks. So glad to find this patch when I came across this bug. Working as advertsied, no idea about the failing test, sorry! +1!
Same here. Getting the error from both CssCollectionOptimizerLazy and JsCollectionOptimizerLazy and the only module I can find that's missing a license URL is owlcarousel, which has both js and css in its library.
scotwith1t β created an issue.
Still seeing problems with this in CKEditor 5 with D10.1.2. While adjusting the order of the filters does link the image (Yay!) the markup is still broken.
This is compounded and becomes particularly visible when using ExtLink module, where the broken markup results in multiple external link icons being added.
scotwith1t β created an issue.
Yeah, I guess I'm starting over. I really don't know how to do this properly. Stay tuned... :)
Hopefully this will do it. I really need to be schooled on how to properly patch a module :-/
Bah. Uploaded wrong file.
Another couple of changes as I do a little more functional/practical testing on the project where we're using this.
After applying the latest patch here
- all of the buttons for multi-value fields as well as paragraphs buttons in the form are being placed in the modal's footer
- I also still see the Published and Menu form components, even though they are moved out of the form in the selected form mode.
I love it when someone on the team is like "it'd be nice if we could hide those counts" and I'm thinking "I really don't have time to figure out that little detail" and the community already has a patch ready for us! :) Thanks everyone and +1 for this working and being a nice addition. Another +1 to it being defaulted to hidden and having to opt IN to having the counts.
I just updated a client site to D10 and having two sets of "allowed formats" settings on fields is confusing for site builders. But we still really need the hide tips/guidelines functionality.
Seems like this functionality should not have rolled out in core without coordinating with this module to provide that new version/upgrade path. Current users of this module are now confused/penalized by having 2 sets of these checkboxes in the UI and existing field config data stored by the contrib module until an upgrade path is figured out. Will keep an eye on this, for sure.
A bit cleaner now, removed stuff about Fixed Parent, which is illogical in the context of this module. Also don't render the menu/block at all if the settings leave just the block title. Fixed a caching bug. I'll learn how to do an interdiff soon...I tried but got an error about whitespace π€·ββοΈ.
This was, admittedly a fairly quick, copy/paste/adjust bonanza directly from Menu Block code, so it will undoubtedly require cleanup and refinement, just wanted to get this out there. Thanks!
scotwith1t β created an issue.
scotwith1t β created an issue.
This would be up to @kristianvandeneynde, the maintainer of the Group module, primarily. I agree that it is a critical piece to every Group-based site I've ever built, so not sure what the likelihood is but a +1 from me, for sure.
Thanks, not sure how I missed that! Clearly a core bug based on what you posted to π CKEditor 5 should respect Fixed , will keep an eye on that. Thanks again!
scotwith1t β created an issue.
Also, the README doesn't mention the need to use (not does the module declare any dependency on) the Base Override UI module, though the project page does mention it (though this doesn't apply to this particular issue, thought I'd mention it here anyway).
Just confirming this is not working on CKE5-enabled long text fields. I don't see how this module works at all just looking at the code. I don't see any form alters or any sort of interaction with the form API whatsoever, just the config stuff.
FYI, patch in #81 still applies cleanly to 10.0.9 and works as expected.
Adding field_permissions
to the list...
Incredibly important patch for anyone using the USWDS framework and many others. Thanks @heddn and others! Not sure what else is needed to get this to land, other than passing tests, but hope to see this one in a release soon! :)
+1 for this patch to make views integration more useful. counting the # of revisions it's used in and then linking to a page which shows way less results in most cases was very confusing and this views patch makes it possible to set up a view for the client that they can make sense of. Thanks!
Taking a stab...this is NOT my strong point, apologies if this is all messed up.
Patch needs a re-roll for new 3.0.0 release.
Thanks folks. All that makes sense. Moving forward with the latest dev and looking forward to a new stable release with that in the future. Thx!
I'm confused...the patch isn't implemented, but rather a different approach which doesn't seem to address the underlying concern, namely that the typing in the definition is stricter than the hook it is implementing. I am applying the patch instead of just using the latest version and that fixes my issue. I don't think the approach in 3.1-dev (not 3.1.1) goes far enough and am re-opening for another look.
It also might make sense to add a check of the entity type while you're at it, something like
if ($entity->getEntityTypeId() !== 'paragraph') return;
to ensure even further that this hook implementation doesn't over-reach. Thanks!
Would be nice if this worked alongside β¨ Make all the widget interface text customizable Needs work too.
scotwith1t β created an issue.
+1 for RTBC (Hey @jidrone!! Long time no see!)
Not sure if this belongs here, but just FYI that the tests below are using the since-removed permission "bypass group access"
/tests/src/FunctionalJavascript/EntityGroupFieldWidgetTest.php:85: 'bypass group access',
/tests/src/Functional/EntityGroupFieldFormatterTest.php:49: 'bypass group access',
/tests/src/Kernel/GroupAutocompleteFormElementTest.php:131: 'bypass group access',
Noticed this when trying to uninstall the Group module and start over with G3 on a new build.
scotwith1t β created an issue.
+1 for new release with #14 applied. Thanks!
That was so easy, thanks so much! I've been trying to stick with just core stuff for a simple site and ended up needing to customize just a little of the css and templates, so this was a huge win for my site. Thanks!
New versions of webform do not require a hook implementation, this is available through the UI.
Just FYI for others who stumble across this, in the newer versions, Webform is an entity reference field on your content type and the Form Display settings for the webform field has an option to disable the default submission data portion of the form.
I had to +1 the issue with the "revert" terminology. Why not "restore"? To me, that communicates what "revert" was trying to but doesn't imply rolling back in time but rather bringing it back to the state it was in at that point in time. My $.02 :)