Okay, created similar issues for both of the other modules - hopefully these can be combined in some way, shape, and form, and it looks like the three interested parties can join forces for one, well supported module!
Hi Tzatziki, you mention Gin - but core will also soon have a dark mode option baked into Claro/Olivero core themes as well if I'm not mistaken.
Jigarius, we came up with another solution for allowing customizable flyouts similar to and compatible with the core Olivero flyout. Let me know if you'd like to take a look - production implementation is for the filter flyout (on mobile) under the Olivero burger menu here - https://www.kobejet.com/en/lessons
Let me know if even reviewing this implementation may be helpful.
+1 to "Display tooltips" per longwave's suggestion - my preference would be off by default.
Just also chiming in I ran into this trying to uninstall the older 2.0.2 version of the Group module from a 10.2.6 install. I had to recreate the offending/missing group types, then uncheck all but the default Admin allowed permissions, then I could remove the group types again and proceed without hitting additional errors.
tekNorah → credited W01F → .
Just commenting I finally got around to removing group v 2.2.2 from a site, and this was the last step. I had to reinstall group, manually delete these two views (group nodes, group members), then uninstall and remove the module again, and everything looks good.
Thank you very much! That is extremely helpful and I will continue to dive more into this in the coming weeks. As I said, I'm already using and enjoy this on a few sites already in cases where the content editors want an easy way to add some of their own CSS/JS and understand the general implications - risks and best practices.
I can't replicate this on any of my Drupal 10 (various versions) sites.
Seeing this as well for regular authenticated users that want to make use of the toolbar for easy (permitted) content adding and editing, but don't need to see Configuration, Reports, etc. that they only get "Access denied" for anyway.
Wondering if this can/will be fixed, or if the idea is to wait and swap to the new core admin toolbar coming in... 11?
Closing as seems to be a duplicate of https://www.drupal.org/project/better_exposed_filters/issues/3103626 ✨ Better Exposed Filters: Textfield in auto-submit filter with Ajax should retain focus submitted Needs work , which has a working patch for the expected ajax behavior on the latest 6.x dev version.
Updated the title to be clearer regarding the purpose of this issue as requested. Here are some examples of what I think the ideal alternative height should look like, and would like other's opinions.
https://www.kobejet.com
https://www.gordillo.legal
Would a simple toggle option for one reduced height option be sufficient, or would a numeric field to set the desired height in px/rem be desirable? Also, any other options (e.g., vertical centering - top, middle, bottom - for the header elements, manual option to set mobile menu swap width, etc.)?
Just looking into some site improvements, including adding modern CSP policy header recommendations, and would also love some basic descriptions and potentially suggestions for setting this up for sites.
Thanks @murilohp, and thanks for the fast response. I would just include some of that explanation in the similar modules section. Makes complete sense and I may be switching over soon as well to simplify the module/code on our team's end, allowing that config to be done in the Adsense panel as well!
Hi Gaus, just following up on this - I discovered that using trimmed with aggregation turned on will show raw output. The fix is to also select "Format" as a "Group columns (additional)" setting in the Aggregation settings for the description field.
This should resolve this - thank you.
W01F → created an issue. See original summary → .
Following this in case there's a backport to D10
Well, I don't think a note simply stating you're closing it because it's "old" is a proper method to close tickets.
Might I recommend something a bit more helpful, such as "We do not currently intend to support this feature." or "We do not currently have time to develop this additional feature, but are open to contributions if someone would like to take this up. Closing for now." Or... possibly even a "After reviewing the request, I realize this is already possible, and am including instructions for how to implement below, with a reference in the readme."
But generally the maintainer of module leaving a note that doesn't even convey they took the time to read a submitted ticket is rather discouraging. If you find yourself strapped for time or lacking technical expertise to respond properly, I would suggest opening the module up and advertising for a co-maintainer.
Note: Copy/pasting my response from the other ticket that was inadequately closed... as that was the method used for the closing comment.
Well, I don't think a note simply stating you're closing it because it's "old" is a proper method to close tickets.
Might I recommend something a bit more helpful, such as "We do not currently intend to support this feature." or "We do not currently have time to develop this additional feature, but are open to contributions if someone would like to take this up. Closing for now." Or... possibly even a "After reviewing the request, I realize this is already possible, and am including instructions for how to implement below, with a reference in the readme."
But generally the maintainer of module leaving a note that doesn't even convey they took the time to read a submitted ticket is rather discouraging. If you find yourself strapped for time or lacking technical expertise to respond properly, I would suggest opening the module up and advertising for a co-maintainer.
Just following up here for clarification as we're also seeing some confusing reports for several sites in Google Analytics recently and are trying to track the cause down.
Uploading screenshot of what I'm understanding are the recommended settings to, again as I understand we should have to:
- avoid the deprecated 'ping' method
- continue to display the hreflang sitemap for the language variant standard recommended by Google
Just following up here that a dark mode would indeed be wonderful, and the "sync with system" option as seen on symfony's site would be a welcome automated feature. In general is D.O looking to move to a new theme other than bluecheese with the next major upgrade? Is there a good page resource for either of those - D.O's upgrade plans and theme development?
First, thank you both for your work on this so far.
I'm setting back to "needs work" and will endeavor to detail the issues a bit more here.
The original issue was only about the potential for accidental double-tapping, resulting in a potentially frustrating menu access experience for users on mobile.
The current delay as currently implemented actually degrades the user experience. Users expect immediate responsiveness when using buttons, links, anything really. So we don't want to disrupt (or delay) the near instantaneous open/close action of the menu upon a press.
Rather, after a press and open/close action has been performed, we should add a short delay until the button again becomes functional.
That is:
1. User presses burger menu to open (or close).
2. Trigger to open (or close) menu instantly fires and moves the menu.
3. Burger menu button is deactivated for .5s (or whatever the current delay is fine)
4. After delay, button becomes useable/clickable again.
Thank you everyone, and I hope that helps.
W01F → created an issue. See original summary → .
This would be fantastic as a submodule... just saying =)
Well, I may have fixed it for my use case at least. I just changed the permissions for the media library view from:
- Permission, view media
To:
- Role, authenticated
That seems to have done the trick for me. Now at least all the users see in the popup is the "Choose files" option.
I have a similar use case where I want to expose a media field for upload to anonymous users to add documents for review, but don't need or want them to see any existing documents. I've already limited them being able to access documents, but on testing they still seem to be able to view the names and select to insert on the media popup. A simple upload form would be ideal.
Just came across this and wondering if anyone has had success with this module or another in tandem to recognize faces to determine focal points and help "smart crop" images.
I have this module installed, but still see some room for improvement, such as on this page:
https://www.kobejet.com/en/song/go-distance
You can see several of the images awkwardly crop the faces.
I think the download part actually works fine, but it is very difficult to actually click on the link that opens in Photoswipe. So it likely just needs a style update.
I'm attaching two screenshots of a simple node that has a Powerpoint media file attached, and then what the download link looks like when it opens in Photoswipe.
I think the link and text should be larger and easily legible.
I believe this is issue (and potential solution) is with Photoswipe, not Splide.
W01F → created an issue.
I just tried adding the translation filter on the node autocompletion callback view used for search autocomplete and this didn't work (screenshot attached). We're are using the 3.x-dev@dev version of the module on Drupal 10.2.
Hi Sandeep... had a few long weeks. Translation simply needed to be enabled as it does for all types of fields. Closing - and thank you!
I just tried the patch on a multilingual Japanese/English site on Drupal 10.2 and using Taxonomy Manager 2.0.9. I can see the translate fields below the terms on the Taxonomy Manager page for vocabularies, but hitting "Save term" doesn't save, and redirects to the TM term edit page, where editing the translated fields (I'm just using titles) doesn't save correctly either.
Absolutely I can facilitate related, interlinked issues for the projects concerned, if Andrei is interested in connecting with the other maintainers.
Agreed, I think I initially excluded the non-10.2 compatible modules. Apologies if I didn't, or at least didn't denote them as being for previous major Drupal versions.
Just seeing multiple solutions for very similar functionality and recognizing both the potential for collaboration/consolidation among module maintainers and making the overall module landscape for potential Drupal users easier to understand and navigate, i.e. assess their various options, analyze the differences in their functionality, and choose a solution.
Ahh.. okay, I was confused because the module description includes that:
"The module provides a form element that can be used programmatically but also integration with Better Exposed Filters and Webform.
...suggesting it can integrate with webforms, but not dependent upon it. In my case I was interested in testing it out with some BEF buttons for some views on a site that isn't even using webforms.
So now I'm curious if this could be changed to an optional integration if webforms is installed, or I think the module page should change the wording or include additional information that webform is required.
Thank you for the fast response!
W01F → created an issue.
Just noting here the maintainer has mostly moved to a new slideshow library and module -
https://www.drupal.org/project/splide →
.
This is what we're using now.
Seconding as this is the only factor keeping us from testing implementation of Easy Responsive Images.
Hi, is this in the new dev version and testable?
I had a similar issue, where if JS aggregation was disabled, and a user logged out, they wouldn't be able to log back in and would only see the error message that JS needed to be enabled on their browser.
+1
+1 to Same Page Preview getting in Core.
I don't have the devel_php module. If I uninstall and reinstall the module - would that ensure capturing that decimal places change in the database?
Hmm, it is possible I actually posted this in the wrong module's issue queue?? Thank you for the response Eric, I'll close it for now.
Hi matslats, I'm currently using version beta3. Is this fix in the dev version (even though it's older)?
This seems to be fixed and works in D10 by updating the module file give/src/Form/Donation/PaymentForm.php with:
1. Adding "use Drupal\Core\Extension\ModuleHandlerInterface;" at the top.
2. At line 163, replacing with:
if ($give_settings->get('log_problems')) {
// Use the ModuleHandler service to get the module path.
$moduleHandler = \Drupal::service('module_handler');
$mod_path = $moduleHandler->getModule('give')->getPath();
// Define the drupalSettings for problem logging.
$form['#attached']['drupalSettings']['give']['problem_log'] = [
'donation_uuid' => $donation->uuid(),
'url' => Url::fromUri("base:$mod_path/give_problem_log.php")->toString(),
];
}Came here looking for this exact thing - I did some wonky CSS to make it more user friendly on mobile, but agree with original poster that having the entire "button", text + arrow, would be more intuitive and easier to use OOB.
Fastest response ever! I updated, tested, and agree it works beautifully - much, much better selecting and embedding experience for users, thank you!
Also having content editors hitting this on a multilingual site
W01F → created an issue. See original summary → .