🇺🇸United States @dasginganinja

Hi kristiaan I hope this helps

Create a new group type `example` (with admin role) granted to creator and don't make them complete membership on group creation.
Observe permissions page for group and see that inside administrator has all boxes checked green since they are marked as "is_admin".
Create a new group of type `example` as admin user.
Navigate to /group/1/content/create/group_membership and experience 403 access denied.

Can we make this a merge request so I can grab a new patch file?

The current version doesn't seem to be working after the update to 3.3.x

Thanks!

We just realized today that this stopped our migrations from running.
We had the following value: item_selector: /events/event

After updating this to `events` this started working in 6.0.4.

Our item selectors were all using the format of `event/field_name` already. I'm surprised this was working in the first place. 😜

dasginganinja → created an issue.

I just went through the past issues and tried to get an understanding of what's going on in this thread. Hopefully this summary helps guide this issue towards an actual patch.

I was starting with patch #49.

There is a MR for this thread that is based on #49 available here: Merge Request !5

Notes for #49 patch / #66
- Patch by default uses MD5 with first 4 characters in #49 and what is expected with this patch for those who has applied it
- Patch 66 seems like it's #49 version rerolled
- Patch #51 can be added to #49 to limit it to just being tags. This is an issue with path invalidation cases and should be applied.
- This does not have any configuration / schema

New functionality / schema changes in #61/63
- Seems like there is a lot of configurability in these -- good work!
- 61 vs 63 was the latest comparison for the _NEW_ work for alternate methods of shortening tags
- Both contain dictionary and MD5 approaches
- 63 has a new "compress" function as well as all the previous work (except #50?)
- 63 changes from simplification_logic to minification_logic configuration key. This means that anybody on simplification_logic key will need to migrate to that. Perhaps we fall back to the previous simplification_logic key?
- 63 will allow the original tag through if there is no config or it is set to null
- 61 will default to md5 if the simplification_logic config is not present

Missing functionality overlooked in #51 as this logic applies to path type expressions as well. This should be incorporated into all of these patches.

I think it would be great if #61 / #63 could be combined into a similar request, using the simplification_logic key. The code in #63 is a lot easier to read FWIW.

I hope this helps move things forward.

This doesn't play nicely with installing from existing config on the minimal profile.

Would it be possible to define these as valid permissions?
It should be possible to look up a listing of the custom block types and just add the permissions that way.

dasginganinja → created an issue.

Updating target for 3.3.x-dev

@KarlShea, thanks for opening those MRs!

I used !159 and it worked ONLY AFTER I added the following line at the top of `src/Access/GroupPermissionAccessCheck.php`:

use Drupal\group\Context\GroupRouteContext;

After this patch was in place existing usages of the context_provider now started matching nodes associated with groups to their associated group.

Please note we only allow a group cardinality of one in our case.

Thank you and please add that to your MRs!

Would this work?
https://www.drupal.org/project/group_mandatory →

I can confirm that I can see the Form under place block. 👍

Is this feature still on the books? 🤔

This issue persists for me to this day.

Metatag 1.26.0
Revision Log Default 1.3.0

I'm also seeing this issue in my 1.8.0 release.

hook_update_8003 installs optional config which is missing a theme key and has an empty region.

I'd be curious if this happens on a new install as well.

I can confirm that the changes in #19 in MR !88 were able to resolve our issues on our site.

--- on a sidenote:
That nvmrc is WAY outdated @ Node 10...

I can confirm that there are event listeners getting added on each click event for things not in the TB Megamenu. It seems that more and more of these listeners keep getting added as well and that causes a linear/exponential amount of work to stack up, causing the page to become unresponsive.

This click event should be faster. Maybe the handleTouch() function needs some love so we don't get all of these defined?

I've tested the code by @dwisnousky in the MR as well as the patch in #33.

I can confirm the preview modal shows over the existing modal and does not close it out.
Closing out the preview modal allows the modal behind it to be selected again and doesn't lose the data changes that were present.

Tested with
- Field Group @ 3.4
- Gin @ 3.0RC10
- Drupal 10.2.5

I'm running into this issue as I'm looking to get off of the Bundled purger.

We've tried to do some unwinding of our $settings['reverse_proxy_addresses'] but have ran into the issues described above.

Is there some sort of way that this "zero config" purger (which appears to be the best out of the bunch due to supporting many invalidation types) can have a settings form or at least be more configurable from a code approach?

I could see the main functionality of the purger coming into another base of sorts and have different methods of instantiation.
For example, if somebody wanted to use the zero config functionality that would be possible, but there could also be a settings form for configuring the instance.

I've looked into potentially using PHP Reflection classes to override some site settings in the object to make it work with this functionality but I'd hate to have to maintain something custom on my end that the community would benefit from.

I can confirm that this fixes this issue for us as well as we had issues upgrading to 4.8 with null value for this as well.
Thank you!

How is this not in yet?

This is looking ready on my end. Can we please get a tagged version of this for Drupal 10?

Thanks!

Will this module be seeing an update into Drupal 10? I surely would like to continue usage of this module but will find another way if needed.

Add .map files to your fast404 exclude list so Drupal stops rendering a full 404.

This module needs love. +1 for Anybody as a co-maintainer

dasginganinja → created an issue.

Was there any resolution on this @Anybody? @justin2pin

Using both the patch in #15 and #20 I was getting a HTTP 414 URI too long error after repeatedly checking / unchecking exposed filters.

The URL string was growing to no length because the exposed sorts were just being *added* to the array, not merged.

This patch simply changes #20 from array addition to an array merge. Interdiff also attached.

Can we get context for what array key is being processed in the tamper function?

I have a similar problem to this where my incoming data is an array and this tamper runs on every array item instead of the array itself. I expected $data to be an array since that was the source....

How do we get an array to the tamper when we originally passed an array? This is a source value that has an array. I'm so confused about the mechanics of this @megachriz

Just some additional comments on this:
There are four parameters that can be used to size these URLs down. People probably won't need all of them. This module might want to make this configurable? Maybe?

I was able to get the outlined fonts to <300kb with this URL for reference: //fonts.googleapis.com/css2?family=Material+Symbols+Outlined:wght,FILL@100..400,0..1

Attaching a patch we used to slim down this to 800kb.

dasginganinja → created an issue.

On a _quick_ passthrough of this code I noticed that the ${var} syntax is being used in strings. PHP 8.2 doesn't like that ;)

Perhaps consider using sprintf to prepare the table/column names?

dasginganinja → created an issue.

I have tested the latest patch #6 and it doesn't work with Drupal 9.5.9.

I observe the same error upon form submission.

I was still running into this even after the upgrade to 1.0-beta3.

Even though $group_content wasn't null, $group_content->getGroup() returned NULL.

Attached is a patch to handle this situation. I'm not sure if there are any unintended side effects, but this made a site without cached entities work again.

This appears to happen during drupal_rebuild()

I just wanted to add another comment on to this.

We observed this behavior on our site when we used Backup & Migrate to fetch the databases from production for local development.

The default profile for this excluded a lot of the data from the `cache_*` tables, however `cache_groupmenu` wasn't included in there and was causing this issue for us.

Running Cron or Update.php seemed to resolve it before we knew what the issue was. The odd thing is that a cache clear didn't clear these tables :)

I also ran into this issue today and tried patch #13.

It stumbled upon the CKEditor image plugin so I added support for that in.

I'm not sure if this needs additional tests, but it's not RTBC anymore :)

Yes, I was speaking about keeping those two in sync, if it was possible. I'm not sure how feasible it is, but it was something that we completely overlooked after switching over to the filefield functionality for directory pathing.

I was checking out the filename transliteration module [1] and noticed they had linked to core's issue.

It looks like core's issue is #2492171 [2].

[1] - https://www.drupal.org/project/filename_transliteration → -- Filename Transliteration module
[2] - https://www.drupal.org/project/drupal/issues/2492171 ✨ Provide options to sanitize filenames (transliterate, lowercase, replace whitespace, etc) Fixed -- Provide options to sanitize filenames (transliterate, lowercase, replace whitespace, etc)

I hope this helps. Thanks for all of your work on this and Feeds, etc.

An additional thought I had about this:

Would it be beneficial for this module to have a checkbox for keeping the core folder settings path up to date?

dasginganinja → created an issue.