🇺🇸United States @NicholasS

For me it logged as having invalid or empty data. So I do wonder if the cache-data is working correctly... I may dig into this a bit deeper today.

Thank you! - Given that I introduced this error it seems only proper I test it. Yeah I didn't catch it since it involved having to wait long enough to have a cached response, but I was getting the same error today when developing locally, a work around was to clear cache before running cron.

But I tested the patch and it works.

This no longer seems to be an issue with the latest version

After this change if no start date in query param it does not default back to Dec 1969

nicholass → created an issue.

So I think the point of this module is to have button shown, so I vote to keep it simple just have them all shown in the bar, thats what this patch does.

nicholass → created an issue.

nicholass → created an issue.

Can someone explain more about the a11y_title, I am not seeing it when editing H5P content. But it does run the update just fine, just don't want to say this is reviewed without understanding the a11y_title.

I was able to update and save a hotspot that previously existed. So maybe that is enough testing.

 -------- ----------- --------------- --------------------------------------------------------------------------- 
  Module   Update ID   Type            Description                                                                
 -------- ----------- --------------- --------------------------------------------------------------------------- 
  h5p      8005        hook_update_n   8005 - Update hook to modify the database schema to include 'a11y_title'.  
 -------- ----------- --------------- --------------------------------------------------------------------------- 


 // Do you wish to run the specified pending updates?: yes.                                                             

>  [notice] Update started: h5p_update_8005
>  [notice] Update completed: h5p_update_8005
 [success] Finished performing updates.

Ok I think I found my answer https://www.drupal.org/project/h5p/issues/3499799 🌱 Temporary fork supporting latest versions of dependencies Active

I had to combine with a Drush update composer require drupal/h5p:dev-2.0.x-patched drush/drush:^13 -W

But I can confirm this updates h5p so its compatible with PHP 8.3

Adding the "exclude" for "drupal/h5p" to your code example.

@shaundychko

So were on the latest alpha, I then require dev so I can test your patch, but I also need the patch from #3497789 but no matter what order I can't apply both patches. What am I doing wrong, since https://www.drupal.org/project/h5p/issues/3497789#comment-15941539 💬 Support h5p/h5p-core 1.27 and h5p/h5p-editor 1.25 in H5PDrupal.php Active makes it sound like it should work.

Here is my patch in composer, I can't get both to work

"drupal/h5p": {
                "https://www.drupal.org/project/h5p/issues/3194707": "https://www.drupal.org/files/issues/2021-01-26/h5p-fix-keeping-h5p-content-id-3194707-0.patch",
                "https://www.drupal.org/project/h5p/issues/3309446": "https://git.drupalcode.org/project/h5p/-/merge_requests/27.diff",
                "https://www.drupal.org/project/h5p/issues/3497789": "https://git.drupalcode.org/project/h5p/-/merge_requests/26.diff"
            },

@risweb Replying to Comment #17

So after testing with Drupal CMS 1.0 I switched the mail module to "symphony mailer lite" since that seems to be what they went with and is Drupal 11 compatible, Mimemail is not so my sites I guess will have to switch as well.

Replies to:

1. Ok so if the subscriber block is set to a modal, Yeah I can try to get it to have the success message kept in the modal, your right, right now once you complete the modal signup form it just dismisses and the page has the message in it. Not a problem I don't think.

2. I think this was a double HTML escape issue, I also switched to sympohny mailer lite since thats what Drupal CMS choose and I figured the core guys did their research on the best mailer, so see if the most recent version has proper HTML emails.

3. Based on your screenshot page%20notifications%20-%20verification%20email.png is perhaps your "text format" truncating the url, I see the purple text says /verify.... so I think that could be a text format setting issue. Is that the Maximum link text length? Could you test that out an see, none of my testing had truncated links like that. Maybe also this is fixed after I fixed the double escape HTML issue that I mentioned in #2

Thanks for the feedback, I think its getting close!

Tested and works

nicholass → created an issue.

Anytime, glad to have such a responsive maintainer!

@risweb #2 should be fixed now.

Anything else off you notice let me know.

@risweb

#1 I think was a bug and I fixed it in commit

#2 Yeah I noticed that as well I will have to look into that maybe today or early next week, I can have that message customized for sure, I don't know why it just doesn't show the form again so yeah I will look more into that.

I also plan to test Drupal 11 as well to make sure it works there. So I will have a few more commits I think to add but thanks for the initial review.

Do you see any other features missing that the original module had?

Added more features to it such as verified HTML emails are created, allowing hooks and headers and footers so people can customize the email templates as well. Along with an option for the block to be a button and a modal to save on UI real-estate. Also added logic for people who are already subscribed and attempting to re-subscribe.

Tested with a core Drupal 10 install as well, and improved the

After testing on our Acquia hosting, this does appear to fix our issue, and I now see GRPC logging after a cron run with debug.

drush cron -vvv --debug

 [info] Starting execution of google_analytics_counter_cron(), execution of webform_scheduled_email_cron() took 5.41ms. [47.08 sec, 110.3 MB]
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1737655590.172511     303 call_credentials.c:168] GRPC_PHP: call credentials plugin function - begin
I0000 00:00:1737655590.176159     303 call_credentials.c:171] GRPC_PHP: call credentials plugin function - end
 [info] Execution of google_analytics_counter_cron() took 650.16ms. [47.73 sec, 111.84 MB]
I0000 00:00:1737655651.551433     245 call_credentials.c:168] GRPC_PHP: call credentials plugin function - begin
I0000 00:00:1737655651.553439     245 call_credentials.c:171] GRPC_PHP: call credentials plugin function - end
 [info] Retrieved 7350 items from Google Analytics data for paths 1 - 7350. [109.36 sec, 150.36 MB]
 [info] Merged 7349 paths from Google Analytics into the database. [138.03 sec, 150.71 MB]
 [info] Cron run completed. [138.05 sec, 150.4 MB]

Full Disclosure I would not have gotten this fixed without Calude.ai but see the new MR22 which has in it a fix that fixes the segfault issue. I will paste an AI explanation from Claude below, as this is a bit over my head.

Steps to reproduce.

1. Add protobuf https://github.com/protocolbuffers/protobuf to your environment, I used ddev as noted above

webimage_extra_packages: [
  "php${DDEV_PHP_VERSION}-dev",
  "php${DDEV_PHP_VERSION}-grpc",
  "php${DDEV_PHP_VERSION}-protobuf"
]

2. Run cron see seg fault.

Claude.ai Explanation as follows:

The root cause involved three interacting issues:

Protobuf Objects and Serialization

When we tried to serialize Google Analytics' response data, we were dealing with special Protobuf objects. These objects aren't regular PHP objects - they're optimized for network communication using Google's Protocol Buffer format. Trying to serialize them directly caused conflicts between PHP's native serialization and Protobuf's internal serialization mechanisms, leading to segmentation faults.

Memory Management

The original approach tried to handle these Protobuf objects as regular PHP arrays, which created memory management problems. The segmentation faults occurred because we were trying to access memory in ways that the Protobuf extension wasn't expecting, especially when trying to serialize these objects for caching.

RepeatedField Type Safety

The final error revealed that we were treating a Google\Protobuf\Internal\RepeatedField (a special Protobuf container type) as a PHP array. This type mismatch caused PHP's array functions to fail because they expect native PHP arrays.

Thanks I tried the suggested "zend.max_allowed_stack_size: -1" but did not help :(

Were still trying to fix this, but got a new breakthrough, after many attempts to force the Google/gax to use REST instead of GRPC we still were getting a seg fault (seemed to be around accessing the credentials file), BUT we found once we removed the PHP package protobuf https://github.com/protocolbuffers/protobuf our seg faults went away, so that appears to be causing the issue.

# ddev config.yaml
webimage_extra_packages: [
  "pngcrush",
  "libjpeg-progs",
  "ffmpeg",
  "clamav",
  "php${DDEV_PHP_VERSION}-dev",
  "php${DDEV_PHP_VERSION}-grpc",
  "php${DDEV_PHP_VERSION}-oauth",
  "php${DDEV_PHP_VERSION}-http",
  "php${DDEV_PHP_VERSION}-gmp",
  "php${DDEV_PHP_VERSION}-dba",
  "php${DDEV_PHP_VERSION}-gnupg",
  "php${DDEV_PHP_VERSION}-protobuf",  <--- This is the problem, once removed and "ddev restart" and seg fault is fixed.
  "php${DDEV_PHP_VERSION}-pspell",
  "php${DDEV_PHP_VERSION}-raphf",
  "php${DDEV_PHP_VERSION}-rdkafka",
  "php${DDEV_PHP_VERSION}-ssh2",
  "php${DDEV_PHP_VERSION}-yaml"
]

Ok So after a lot more debugging on and off with acquia support, its something related to the Google Vendor gax, I found this comment that talks about a very hard to debug segmentation fault! And I can agree it was very hard :)

https://github.com/googleapis/gax-php/blob/140599cf5eae2432363ce6198e9fd...

And I was able to add enough debugging to pull this out of the codebase

[debug] Getting feed [37.63 sec, 116.37 MB]
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1736874324.703588 708 call_credentials.c:168] GRPC_PHP: call credentials plugin function - begin
I0000 00:00:1736874324.703698 708 call_credentials.c:171] GRPC_PHP: call credentials plugin function - end
[error] Error: Maximum call stack size of 10436608 bytes (zend.max_allowed_stack_size - zend.reserved_stack_size) reached. Infinite recursion? in Google\ApiCore\CredentialsWrapper->Google\ApiCore\{closure}() (line 244 of /var/www/html/vendor/google/gax/src/CredentialsWrapper.php) #0 [internal function]: Google\ApiCore\CredentialsWrapper->Google\ApiCore\{closure}()
#1 /var/www/html/vendor/grpc/grpc/src/lib/UnaryCall.php(43): Grpc\Call->startBatch()
#2 /var/www/html/vendor/grpc/grpc/src/lib/BaseStub.php(295): Grpc\UnaryCall->start()

And then I found the hosting I am using has these PHP differences

grpc
grpc support => enabled
grpc module version => 1.68.0
grpc.enable_fork_support => 0 => 0
grpc.grpc_trace => no value => no value
grpc.grpc_verbosity => no value => no value
grpc.poll_strategy => no value => no value
fiber.stack_size => no value => no value
fiber.stack_size => no value => no value
zend.max_allowed_stack_size => 0 => 0
zend.reserved_stack_size => 0 => 0

Still don't have a solution, but at least the problem is narrowed down a lot more.

Manual Notification: Some people may not want to edit/modify the content which would affect the date, maybe its a reminder that something is the last day or something, so put in a manual notification option.

Manual Addition: Most my clients have emails often from other sources like paper signup forms etc

Migration page with auto complete to transfer subscriptions from one entity to another

Drupal Status message after verification link is clicked

So I migrated all the config I think I can, some of the "Flow" is a bit different so I am not sure the old templates make 100% sense in the new version. Also there is not "manage subscriptions" page, this version simplifies things and all emails just have an unsubscribe link (like slickdeals/camelcamel etc do it). And some of the old v3 emails are just notifications in the newer version.

Here are some screenshots

If on Version: 2.0.0-alpha4 add the following patches to your extras in composer.json

"h5p/h5p-editor": {
      "PHP8 notice https://www.drupal.org/project/h5p/issues/3260094": "https://www.drupal.org/files/issues/2022-01-24/Update_H5P-editor_PHP8_compatible.patch",
    "php83 https://www.drupal.org/project/h5p/issues/346465": "https://www.drupal.org/files/issues/2025-01-13/h5p-editor83.patch"
},
"h5p/h5p-core": {
     "php83 https://www.drupal.org/project/h5p/issues/346465": "https://www.drupal.org/files/issues/2025-01-13/h5p-core83.patch"
},

Until the maintainers can get the upstream h5p library updated, watch https://www.drupal.org/project/h5p/issues/3420268 🐛 Support h5p/h5p-core:1.26 and h5p/h5p-editor:1.25 Needs work

This issue could also be fixed by just updating the h5p library right to something newer than 1.24.4 ?

Recently added Flood protection to the module. The one aspect I think that could use some work is the signup block, would love to make it a button, that spawns a modal(native dialog) and the modal contains the signup form, and posts/updates with error handling in the modal.

But I think a lot of the other areas of the module are solid, so I am going to open a Merge Request for it so it can get some maintainer attention, would love to merge it to a 4.x branch but Gitlab doesn't allow me to do that, so for now I will MR to the 3.x.

Would a maintainer please take a look at my initial refactor of this module to v4. And update hook should migrate all the old subscriptions. I choose not to try to migrate all the old settings so user will have to redo their templates etc. But would love some feed on what I have so far. I tested it and so far looks to work pretty well for me.

Was just wondering myself why they still haven't updated now that 7 is End of Life. 

Got an initial start on the refactor today. Currently it can install, has settings that can be saved, a block to allow subscriptions, a route to see subscriptions, but still needs a lot more work and features. hopefully I get some more time next week.

nicholass → created an issue.

Ok I am going to start a new issue for the refactor of the module, I'll leave this one as is to fix the current issues I experienced with the module.

I think I would be willing to refactor this in a 4.x branch and would propose the following: (Just from initial skim of code)

• Increase Dependency Injection, removing static calls such as `\Drupal::`

Convert to a custom entity type, and provide migration path from nodes

Use Drupal Config management for settings instead of the database to store module/templates, was there a reason for using the database I'm not aware of?

Instead of fields being manually added, I think it should be more automatic, and really I think you just need a checkbox for the editor, and can use revision log message field for the short editor note? Id have to dive into more why you need a timestamp field.

Various token/email validation improvements like token expiration, cron cleanup, also don't love the email in the address bar which would then show in server logs, I feel it could be an obscure ID that relates back to an email.

Do you have any strong opinions on any of those?

@risweb - Thanks for the module, I saw someone else brought up the custom entity type, instead of how its currently designed to use a node and fields to manage subscriptions. I am just curious has that been working out for your sites? It seems it would generate a lot of nodes, and playing around with the confirmation page such as /page-notifications/confirmation/XXXXXX/27956-node-XXXXXX seems a bot can spam that generating a lot of fake node/subscriptions.

I am currently still looking at it all locally, but more I review I feel like this module needs a new 4.x release where a lot of it get refactored with good dependency injection, XXS and validation. Would that be something your open to supporting?

#3 seems to be a cache issue, tried today and was able to save the configuration page,

however it all seems hardcoded to full_html and our site had removed that text format. The dropdowns on the configure page allow me to select another format, but on each save it reverts back to full_html

I love the idea of this module, but man.... I can't get it working and been browsing the code and its full of areas that need work, lots of unused variables and comment blocks. I assume maybe this was a custom module at one point? I am going to look over it for a few days and see if I have the capacity to refactor it.

Any Maintainers want to chime in is this module useable in its current form? Seems not to be.

Ok now when trying to save /admin/page-notifications/tabs/default/second after install I got a

The website encountered an unexpected error. Try again later.

Error: Class "Drupal\page_notifications\Form\Drupal" not found in Drupal\page_notifications\Form\MessagesForm->submitForm() (line 265 of modules/contrib/page_notifications/src/Form/MessagesForm.php). call_user_func_array(Array, Array) (Line: 129) Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67) Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)

nicholass → created an issue.

Skipping step2 was able to get to step5 but again lost and the help text link doesn't help

Do I need another module to add the PineCone Provider? https://www.drupal.org/project/ai#:~:text=complete%20AI%20applications.-... → I don't see one like that on the AI project readme.

Just commenting here, I can't figure out how to do step 2
2. (In Drupal) Ensure you have an Embedding type configured in the AI Core module configuration at Admin > Configuration > AI.

/admin/config/ai/settings just has a bunch of dropdowns with "No default".

UGH now getting

 [info] Starting execution of google_analytics_counter_cron(), execution of file_cron() took 3.68ms. [21.11 sec, 64.77 MB]
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1732220684.750398     339 call_credentials.c:168] GRPC_PHP: call credentials plugin function - begin
I0000 00:00:1732220684.753480     339 call_credentials.c:171] GRPC_PHP: call credentials plugin function - end
Segmentation fault

PROBLEM:

Had a segmentation fault when trying to serialize() Google Analytics API objects (DateRange, Dimension, Metric)
These objects can't be safely serialized in PHP, causing the crash

SOLUTION:

Create two separate parameter arrays:

$parameters: Contains proper Google Analytics objects needed for the API call
$cache_params: A simple array with basic data types that can be safely serialized

WHY:

We only need serialization to create a unique cache ID (md5 hash)
The actual API call requires proper Google Analytics objects
By separating these concerns, we avoid the segfault while maintaining functionality

So going to make that proposed change, Claude.ai helped debug the issue.

The problem seems to lie with the serialize() in the buildQuery method, not really sure where I go from here to debug further....

 [info] Starting execution of google_analytics_counter_cron(), execution of file_cron() took 2.59ms. [19.88 sec, 64.77 MB]
 [notice] Starting cron with memory: 71827456 [19.89 sec, 64.86 MB]
 [notice] Before node count query [19.89 sec, 64.86 MB]
 [notice] Total nodes: 16480. Memory: 71827456 [19.9 sec, 64.95 MB]
 [notice] Starting main processing. Memory: 71827456 [19.9 sec, 64.95 MB]
 [notice] Before database truncate. Memory: 71827456 [19.91 sec, 64.95 MB]
 [notice] After database truncate. Memory: 71827456 [20.52 sec, 65.02 MB]
 [notice] Before queryTotalPaths. Memory: 71827456 [20.52 sec, 65.02 MB]
 [notice] Starting queryTotalPaths [20.52 sec, 65.02 MB]
 [notice] About to buildQuery [20.53 sec, 65.02 MB]
 [notice] Starting buildQuery [20.53 sec, 65.02 MB]
 [notice] Got config [20.53 sec, 65.02 MB]
 [notice] Chunk: 1, Pointer: 0 [20.54 sec, 65.02 MB]
 [notice] Built query dates: Array
(
    [start] => 2024-10-22
    [end] => 2024-11-20
)
 [20.54 sec, 65.02 MB]
 [notice] Property ID: 371690843 [20.54 sec, 65.02 MB]
 [notice] Starting cache options creation [20.55 sec, 65.15 MB]
 [notice] Params structure: Array
(
    [property] => properties/371XXXX43
    [dateRanges] => Array
        (
            [0] => Google\Analytics\Data\V1beta\DateRange Object

        )

    [dimensions] => Array
        (
            [0] => Google\Analytics\Data\V1beta\Dimension Object

        )

    [metrics] => Array
        (
            [0] => Google\Analytics\Data\V1beta\Metric Object

        )

    [offset] => 0
    [limit] => 1
)
 [20.55 sec, 65.15 MB]
 [notice] Before serialize [20.55 sec, 65.15 MB]
Segmentation fault

Still debugging, added a bunch of logging to the current cron logic, looks like the problem lies in the queryTotalPaths()

[info] Starting execution of google_analytics_counter_cron(), execution of file_cron() took 4.12ms. [19.61 sec, 64.75 MB]
 [notice] Starting cron with memory: 71827456 [19.62 sec, 64.82 MB]
 [notice] Before node count query [19.62 sec, 64.83 MB]
 [notice] Total nodes: 16481. Memory: 71827456 [19.63 sec, 64.92 MB]
 [notice] Starting main processing. Memory: 71827456 [19.63 sec, 64.92 MB]
 [notice] Before database truncate. Memory: 71827456 [19.64 sec, 64.92 MB]
 [notice] After database truncate. Memory: 71827456 [20.23 sec, 64.99 MB]
 [notice] Before queryTotalPaths. Memory: 71827456 [20.23 sec, 64.99 MB]
Segmentation fault

An update, our host PHP memory limit is 128mb.

@kaszarabert Thanks for the ideas and I will use them to investigate more, It stopped working across all our Acquia environments, and they actually had different code deployed, so I think it could be an issue with the amount of data being retrieved from Google is my current theory. Since nothing on the servers changed at the point in time when things broke, at least that I have found yet.

Will research more and update tomorrow.

I think this could be the at fault code, where its working with a large array in memory.
https://git.drupalcode.org/project/google_analytics_counter/-/blob/4.0.x...

nicholass → created an issue.

We also ran into this bug, long time Smart Date users, and didn't even know new form display options existed. Seems like you could also fix the classic with a "position: relative" on the end date. We don't mind updating away from Classic, but probably lost of long term users of the module need notified to update their settings.

Ignore #12 for anyone else having a similar issue it turned out to be Akamai configuration issue preventing the origin server from working correctly (header was too large). Sorry for the false alarm.

For more context we are also using the following mix of modules.
- content_moderation_notifications
- smtp

And looks like this module is supposed to unset the CC/BCC headers
https://git.drupalcode.org/project/mail_safety/-/blob/2.x/mail_safety.mo...

But our content_moderation_notifications fired and sent out Bcc emails. The original emails did not have a "To" that was blank, they were just to send out some Bcc email to copy multiple people.

I compared the 8.x to 2.0 and don't see what could have introduced this bug, but I am pretty sure 8.x-1 didn't have this bug.
https://git.drupalcode.org/project/mail_safety/-/compare/8.x-1.x...2.x

Same bug for BCC

I believe this change as introduced a cache issue, we are getting now this issues error https://www.drupal.org/project/o365/issues/3175599 → "OAuth2 Authorization code was already redeemed" but only for users attempting to login outside our network over Akamai. Akamai does not appear to be caching anything, but were going to try to roll back this versions and see if it fixes things.

Tested on my site and these changes eliminated the errors and warnings I was encountering.

I started a new issue but check out https://www.drupal.org/project/bg_img_field/issues/3484950 🐛 Error: Call to a member function load() on null BgImgFieldFormatter Active and see if it solves your orginal error, I never got your exact error, but I assume it stems from the same bad code.

nicholass → created an issue.

Plus I get

Warning: Undefined variable $fileSystem in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->__construct() (line 117 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).

and

Warning: Undefined variable $imageFactory in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->__construct() (line 118 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php).

So not sure how 2.1 release is working for anyone! But the undefined vars probably explains your original issue.

10.3 I get Error: Call to a member function load() on null in Drupal\bg_img_field\Plugin\Field\FieldFormatter\BgImgFieldFormatter->viewElements() (line 188 of modules/contrib/bg_img_field/src/Plugin/Field/FieldFormatter/BgImgFieldFormatter.php). which is the same line this issue has a problem with.

nicholass → created an issue.

Oh wow ok so looking into the history of this issue, it appears the only way those checkboxes work is if you also select the option "Disable SQL rewriting" in the query options for the view.

So maybe this checkbox needs a warning or notice about how it only works with that option enabled. Based on the past issue, everyone had that option checked on I think.

I am also experiencing the same behavior, and do not have a workaround.

Created a patch for 2.1.x branch, patch #4 could not apply for me, so use https://git.drupalcode.org/project/layout_paragraphs/-/merge_requests/18...

Here is a debugger on the issue for those interested
https://www.drupal.org/files/issues/2024-10-03/dragndropjsdebug.mp4 →

@ckng see https://www.drupal.org/project/layout_paragraphs/issues/3476838 🐛 JS error when Drag and Dropping Active for video demo of problem, not sure what exact conditions you have to have for the drag and drop to not work, but its only on some of our content pages not all.

Yeah I think its the same issue I will close mine.

nicholass → created an issue.

nicholass → created an issue.

Looks like the path to check for assets is incorrect, composer does not place the datatables library in a subfolder called datatables.

I'll create a new issue about this.

I am confused, I have updated datatables, but status report says I am missing assets.

This added a check for the following assets
https://git.drupalcode.org/project/datatables/-/blob/2.x/datatables.modu...

// Check if the essential CSS and JavaScript files exist.
    $essential_assets = [
      'css' => ['jquery.dataTables.css', 'dataTables.bootstrap.css'],
      'js' => ['jquery.dataTables.js', 'dataTables.bootstrap.js'],
    ];

But the libraries.yml only loads the non-bootstrap assets.

datatables_core:
  version: 1.10
  js:
    /libraries/datatables/media/js/jquery.dataTables.js: {}
  css:
    component:
      /libraries/datatables/media/css/jquery.dataTables.css: {}
  dependencies:
    - core/jquery

So how are we supposed to load the dataTables.bootstrap.css dataTables.bootstrap.js assets? There is nothing in the readme about that. It seems like those should be removed from the status page check for correct assets, some projects don't use bootstrap.

Maintainers please create a new release.

For other looks like only the dev branch has the fix, an official release has not been created yet.

So it looks like this was fixed two months ago https://git.drupalcode.org/project/rabbit_hole/-/commit/5320357bd2e8d13e... so why is the current version broken when I use composer to update the module?

nicholass → created an issue.

Success! I can patch the file again.

NicholasS → created an issue.

I had the same error one of our environments didn't have a good memecache compiled for its PHP.

BUT the patch did not fix it, so I think it needs work still, same error

Drupal Core = 10.2.6
0365 = 5.0.12

I tried both the headers-already-sent-3422331-10.patch and the MR diff and still have errors in the logs. I can confirm the this is how to replicate the issue, but seems like it still needs work.

HTT:
1. Enable o365_sso & big_pipe
2. Configure o365 with azure like usual.
3. Go to /admin/config/system/o365/settings/sso and enable "Automatically redirect users to the SSO login page"
(switch to an incognito browser)
4. Click on the login link (or go to the /user/login) and get redirected to Microsoft.
5. Notice that even without actually logging in it already logs the "headers have already been sent"

In Core 10.3 I had to change it to this

.ck-body-wrapper .ck {
  --ck-z-panel: 1500;
}
.ui-dialog ~ .ck-body-wrapper {
  --ck-z-panel: 1500;
}