Also curious if there is any work happening on this. This is an extremely useful module that D8+ could really benefit from.
breidert → credited jaydarnell → .
Patch #16 appears to fix the problem for version 8.x-3.5
This is definitely still an issue. I'm caught in a situation where I can either have the displayed date for my events be correct on the node itself while the addtocalendar widget is wrong or the other way around.
jaydarnell → created an issue.
daletrexel - this is my first time using this module and its for a brand new build. When I started the build back in February we were using older versions of core and this module and it seemed to work fine, though to be fair I only did a cursory check as the group functionality was not priority at the time.
Now I'm on the following setup:
- Drupal 10.3.1
- Group 3.2.2
- Group Content Menu 3.0.3
I'll do more testing today to see if I can figure out what is going on. To restate my issue, I want the menu to display on the group itself and any nodes of type "Lab Page" within the group (but nothing else: no other content types, not user entities within the group, etc) I would think all I have to do to restrict this is check the appropriate boxes when I add the group_content_menu block to a given region but that doesn't seem to be the case.
@heddn, just to be sure I follow, are you saying the intended behavior of this module is to automatically display the group_content_menu block in a given region based on group context alone, with no considerations for block visibility settings and that to specify more specific visibility settings I would need to write code to extend the context provided by the group module itself?
One caveat I'm running into with DaleTrexel's patch is that I cannot get the menu to show up on the group itself unless I leave the settings for the menu block to completely unrestricted. The moment I restrict the content types to 1 of the allowed types within the group (In my case I only want the menu to show on pages in the group, not news items in the group) the menu no longer shows on the group itself, even if I explicitly specify the group type.
The patch DaleTrexel supplied in merge request 27 appears to fix the issue for group_content_menu 3.0.3 branch on Drupal 10.3.1. I'll continue testing but so far so good.
I'm still seeing this issue on 3.x. Clearing the cache doesn't fix the problem. When I uninstall group my site is completely down.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "group" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 142 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
This issue needs to be reopened.
I'm seeing the same results as @rpayanm with the patch from MR 459.
Thanks @saschaeggi
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.