🇦🇺Australia @GuillaumeG

guillaumeg → created an issue.

guillaumeg → created an issue.

guillaumeg → created an issue.

I am closing this ticket as all items have been addressed:

• Ported it to Drupal 10
• Updated hardcoded code to use config instead (e.g., region, ACL)
• Fixed code style issues
• Created a new stable project release
• Applied for inclusion in security advisory coverage

Thanks both.

Patch applied and merged https://git.drupalcode.org/project/tome_aws/-/merge_requests/2.

GuillaumeG → changed the visibility of the branch 3274677-support-multiple-aws-regions to hidden.

GuillaumeG → made their first commit to this issue’s fork.

Drupal 10 compatibility fixes Merge Request merged in 1.0.x branch.

Thanks 8ballsteve.

I am closing this issue.

GuillaumeG → created an issue.

Hi @ericgsmith,

Thanks for your detailed answer.

I tried your suggested solutions:

• Using the dev version of the purge_queuer_url module to get all the latest fixes and trying the code from the MR on https://www.drupal.org/project/purge_queuer_url/issues/3045503 ✨ Registry expiration as opposed to removing it too soon Needs work
• Using the purge queues module along with the mentioned patch.

Unfortunately, I did not see any improvements.

I checked the X-Drupal-Cache-Tags headers and did not notice anything unusual for the nodes I saved during testing.
I found the same cache tags when browsing the SQL table purge_queuer_url_tag.

For other developers who need to know how to display Drupal Cache Tags, you can refer to https://www.drupal.org/docs/8/api/responses/cacheableresponseinterface#d... →

However, I did notice that the queue was almost always equal to the Traffic Registry size, and saving the node again would simply double the size of the queue.

Example (after training the traffic registry with wget and registering 85 items):

• Traffic Registry size: 85
• Queue size: 0

After saving a node:

• Traffic Registry size: 85
• Queue size: 85

After saving the same node again:

• Traffic Registry size: 85
• Queue size: 170

Is there anything I'm missing here?

Hi,

This patch was helpful in resolving an issue described at https://www.drupal.org/project/better_exposed_filters/issues/3299926#com... 🐛 TypeError: Cannot access offset of type string on string in Drupal\Component\Utility\NestedArray::setValue() Postponed: needs info

Hi,

I can replicate this issue on a vanilla Drupal installation:

1. Install Drupal 10 and enable the Better Exposed Filters module
2. Create a new Drupal view listing Articles
3. Add a new tags filter
1. Set the Selection type to dropdown
2. Check "Expose this filter to visitors" to allow them to change it
3. Click "Allow multiple selections"
4. Apply the changes
4. In the Advanced tab under "Exposed form style", select "Better Exposed Filters"
5. For the Exposed filter "field_tags_target_id" with label "Tags (field_tags)", choose "Checkboxes / Radio buttons" for the Exposed filter widget
6. Save the view
7. Visit the View page and append /articles-list?field_tags_target_id=All (any other values will result in the same error).

Upon accessing the website, the following error occurs:

The website encountered an unexpected error. Please try again later.
Error: Cannot create references to/from string offsets in Drupal\Component\Utility\NestedArray::setValue() (line 155 of core/lib/Drupal/Component/Utility/NestedArray.php).

The following Drupal core patch fixes the issue https://www.drupal.org/project/drupal/issues/3023924#comment-14841300 🐛 Cannot create references to/from string offsets Needs work but not quite sure this is a core or a BEF issue at this stage.

Thanks @s_leu.

Patch tested. It is looking good now, no more errors.

Ok I was missing the Advanced Settings option.

And to programmatically set that, we can override the plugin GridDialog.php.

Closing the issue.

GuillaumeG → created an issue.

Same behavior as @gaele 🐛 Exceptions thrown when toggling Advanced section of linking form RTBC

The patch #9 🐛 Exceptions thrown when toggling Advanced section of linking form RTBC helps to fix the layout and when clicking advanced for the first time but this error is still thrown when clicking on Advanced multiple times.

Looking good, thanks Andreas!

Patch commited and new release created.

GuillaumeG → made their first commit to this issue’s fork.

Ok, ended up triggering the following in a service on hook_entity_insert() / hook_entity_update():

public function purgeCache(EntityInterface $entity) {
    $invalidations[] = $this->purgeInvalidationFactory->get(
      'url',
      $entity->toUrl('canonical', ['absolute' => TRUE])->toString(),
    );
    try {
      $this->purgePurgers->invalidate($this->processor, $invalidations);
    }
    catch (DiagnosticsException | LockException | CapacityException $e) {
      $this->messenger->addError($e->getMessage());
    }
  }

GuillaumeG → created an issue.

New issue created with a patch working 2: https://www.drupal.org/node/3386017 →

GuillaumeG → created an issue.

Hi @bomoko / tobybellwood,

Thanks both, I was definitely missing these fields.

I have re-added the file with some changes to make it work with the LogRecord class.

Ready for review again.

Hi bomoko,

Thanks a lot for checking the MR.

I removed LagoonLogsLogProcessor because I was able to get all the fields in the logs (OpenSearch) without this class and could not see any difference when comparing with a previous log entry.

Happy to restore the file with the changes you proposed if I am missing something, which is surely the case !
Or feel free to push a commit to my MR directly if you prefer.

GuillaumeG → created an issue.

GuillaumeG → created an issue.

GuillaumeG → created an issue.

Hey there,

Any chance to get that patch reviewed ?

Thanks !

Awesome, thanks for getting that merged to 11.x !

Could we also get that change backported for 10.2 ?

+1, patch working as expected.

gargsuchi → credited GuillaumeG → .

GuillaumeG → created an issue.

+1 the patch provided works and fixes the issue with Drupal 9.5.x

Changing the status to Reviewed and tested by the community

Hi down2under,

As Google Analytics 4 now uses first-party cookies instead of third-party cookies to comply with laws like GDPR, this module won't be needed anymore from the 1st of July : https://support.google.com/analytics/answer/11583528

Closing this issue and will mark this module as deprecated on the project page.

GuillaumeG → created an issue.

GuillaumeG → made their first commit to this issue’s fork.

Hi Vishal.kadam,

Code updated, you can review it again.

Thanks

GuillaumeG → created an issue.

Thanks for the merge @Guietc 🙂

Release 2.0.0 created to add D10 compatibility.

Patch updated with an adding control and rerolled with 9.5.x

GuillaumeG → made their first commit to this issue’s fork.

gargsuchi → credited GuillaumeG → .