JayDarnell → created an issue.
JayDarnell → created an issue.
JayDarnell → created an issue.
Patch #26 seems to work well for group_content_menu 3.0.1, group 3.2.2, and drupal 10.2.5
swirt → credited JayDarnell → .
Patch #57 worked for me
JayDarnell → made their first commit to this issue’s fork.
Patch 38 appears to work
JayDarnell → created an issue.
As I've started brainstorming on this, I can't help but wonder if these subscriptions should be entities. If they were entities I could leverage views to create a much more robust subscription page. At a minimum I can see how the views pager and the ability to utilize views filters would make for a more user friendly experience, especially on sites with a large number of groups.
Thanks so much bircher. I need some practice writing tests as it is. If you want I could turn this issue into a feature request and create a new branch and PR to add this as a sub module with a suitable test.
JayDarnell → created an issue.
JayDarnell → created an issue.
JayDarnell → created an issue.
JayDarnell → created an issue.
I've tested the patch from #90 on a few sites now and it seems to work really well.
JayDarnell → created an issue.
Tested with Drupal 10.1.6, PHP 8.1.21 and 8.x-1.5 and the patch from #5. Unfortunately my initial sitemap.xml generation still failed. The only way I could get it to complete is if I manually bump my memory limit with ini_set('memory_limit', '2G') But this worked even without the patch.
Hi bircher, first of all thank you for this awesome module. I wasn't quite sure how to utilize the new hook and would greatly appreciate any guidance in that respect. I couldn't figure out how to create a pattern that only ignores block config from the block_content module because the naming convention for block_content blocks and blocks from a different module all follow the same naming convention: block.block.
_.yml
Examples:
We have a custom block type called "Text" that is simply a block description and body field. I created one of these with the block description "Carl Sagan" and config management wanted to export the file: block.block.mytheme_carlsagan.yml.
A block from the book module for book navigation is exported as the file: block.block.mytheme_booknavigation.yml.
In our environment end users could create an infinite number of custom text blocks so we don't want to track any of them, but with the way these ymls are named, I can't tell the difference between a block created by block_content and other blocks. The only difference I could find was the settings->provider value within each of their yaml files (which tells us the module responsible for creating them)
Thank you in advance for your help. If we can avoid using a one off patch and can work with the module as provided that would be preferable.
The initial merge request takes care of not tracking these items for export, but I need to update it so the custom blocks aren't deleted on import.
JayDarnell → created an issue. See original summary → .
JayDarnell → created an issue.
JayDarnell → created an issue.
I can update the issue fork to add a span around the subset of the label containing the equation in order to satisfy the failed test but wanted to get maintainer feedback first.
Also updating this to a major bug due to the fact the module as written will not pass accessibility tests.
With this still being a problem in the 2.x branch I'm going to update the issue appropriately, create an issue fork, and reroll adriancruz's patch from #2 for the latest 2.x release.
This no longer appears to be an issue. As mentioned above, the initial patch supplied here: https://git.drupalcode.org/project/legal/-/merge_requests/3.patch actually breaks the redirect altogether (in the 3.x branch at least). After I removed this patch I attempted to recreate the initial bug reported in this issue but cannot. I suspect the problem was fixed elsewhere and this issue merely needs to be closed.
False alarm. The 3280 patch does in fact apply in 10.1.3. The problem is that I already had an older patch (#47) for Drupal 8+ from this issue https://www.drupal.org/project/drupal/issues/2086125 🐛 Last read comment field/filter/argument uses still the node.changed instead of node_field_data.changed column Needs review applied but it was no longer working for Drupal 10. Replacing that patch with this one fixed the issue for me.
I could not get the patch from 3280 to apply in Drupal 10.1.3. I will attempt to rewrite it today and report back. One thing to note in the meantime, this appears to be an issue with the Comment Statistics: Updated/commented date wholesale, not just for sorting and filtering. Just trying to output the value of the field in 10.1.3 also fails so I'll see if I can add coverage to that to a patch as well.
JayDarnell → created an issue.
Good catch @majorrobot!
New merge request coming along momentarily. I accidentally omitted two use statements from the .install file.
@DamienMcKenna hopefully the merge request I created above is helpful. This is the first time I've written an update hook to recreate a view from a module's config folder. This worked like a charm locally but please let me know if you find any issues with it.
JayDarnell → made their first commit to this issue’s fork.
Once more for good measure as I overlooked one of the previous changes:
Had to add in the # for a couple lines in the info.yml which are added by the drupal.org packaging script for the patch to take:
Attempted reroll for D10 compatibility
While this issue is technically for Drupal 9 compatibility, I'm going to reroll the patch above to hopefully support the 8.x-1.x branch in Drupal 10 as well. This will give folks who may still be running on this older branch of USWDS a stop gap for D10 support until they can upgrade any custom themes they have based on USWDS to use the latest release.
Good catch. I was really confused when I upgraded to 2.0.1 and saw the duplicate "modules" in the core.extension.yml :)
Could we please get the solution from bletch merged?
This is the first I've heard of this concept but I love it.
I'm working on a fix for this now @swirt
JayDarnell → made their first commit to this issue’s fork.
JayDarnell → created an issue.
JayDarnell → created an issue.
JayDarnell → created an issue.
JayDarnell → created an issue.
I believe I have this one sorted @swirt
JayDarnell → made their first commit to this issue’s fork.
I'm looking into this now swirt to see if I can come up with a solution.
JayDarnell → created an issue.
Closing in favour of https://www.drupal.org/project/group_subscription/issues/3221373#comment... ✨ Improve UI/functionality for holding and requeuing subscriptions Active
This issue is sorta a duplicate: https://www.drupal.org/project/group_subscription/issues/3353499 ✨ Move checkbox for optionally omitting group content from subscriptions to vertical tab Closed: duplicate
JayDarnell → created an issue.
Attempting to move this to the 3.0.x branch. We'll see if the next automated pass actually checks that branch or not.
If a user is in multiple groups and a given piece of content is posted in both groups this could create duplication so we'll need to account for that. If we're not going to just send two immediate emails and not include two references to the item in the same daily email that means our email templates need to account for the item being in multiple groups somehow.
This is still a pretty solid enhancement we could use.
I'm not sure this is something I'll still work on. Definitely low on the priority list.
This is an oversight on my part. Should just be an additional checkbox on the gnode configuration page to also send updates for comments on those items.