🇺🇸United States @NicholasS

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;
}

This bit me with Google Tag and Require login modules would love to find a fix for this as well.

Thank you this also fixed our issue on Acquia Search hosting, where we had the same issue and could not select the Solr queryhandler.

Can confirm all the above and #2 worked for a temp fix so we could update to 10.2.x

This patch worked for me thanks!

Changed the alias from 'nrd' to 'nrrd' since that is technically new-relic-rpm:deploy this change would obviously need to be mentioned in the Release Notes.

Yeah so these two modules have the same alias which is why the drush commands are not working for me, when when I am not using the alias of either module.

  /**
   * Mark a deployment in newrelic.
   *
   * @param string $revision
   *   The revision label.
   * @param array $options
   *   The options to pass through to the deplopment.
   *
   * @command new-relic-rpm:deploy
   * @aliases nrd

/**
   * Deletes old node revisions for a given content type.
   *
   * @param string $type
   *   Content type machine name.
   * @param array $options
   *   The options.
   *
   * @option dry_run Test run without deleting revisions but seeing the output.
   *
   * @usage nrd article
   *   Delete article revisions according to set configuration.
   * @usage nrd page --dry_run
   *   Execute the deletion process without delete the revisions, just to see
   *   the output result.
   *
   * @command node-revision-delete
   * @aliases nrd
   */

Given that Node Revision Delete has a much higher usage, and that its drush command is more likely to be typed by a human, and new relice deployments are likely used more in CI instances. I think this module should just remove its alias? I will attempt that patch, or modify the alias so it doesn't conflict with 'nrd' alias of the larger module.

Ok so I think this could be a conflict with another drupal module called "Node Revision Delete". Since that error message is coming from that other modules code, and when I uninstall node revision delete the new relic drush commmand appears to work.

The error you're experiencing might be due to a conflict between the new-relic-rpm:deploy command and the nrd command from the node_revision_delete module.

NicholasS → created an issue.

Same for me The "type" argument does not exist. error
D10 with Drush 12

Update: So today I tried another migration again and its seemed to not be a problem, so could have just been a deployment hiccup? I guess well see if it happens to others or not to see if its an issue, and I guess worst case it can be solved with a cache clear I assume.

Just as follow up our deployment CI is pretty typical, its an Acquia Cloud Next hook as follows and it was clearing cache after deployment. Again too this white screen of death only happened to use ~5min after deployment when our Cypress Testing was about half way through testing, and we have about 509 cypress tests that test various routes of the CMS and features.

drush cr
drush updb -y
drush cim -y
drush cr
drush sset environment_indicator.current_release $deployed_tag

NicholasS → created an issue.

❤️ Thanks! Yeah had to wait for the reporting delay but reports are showing traffic now again after a ~20 day flatline!

While I wait for a release, is the "Hot fix" to visit the settings page /admin/config/services/google-tag and uncheck the "Enforce Privacy Consent Policy" settings and hit save?

This is behind the same toggle that https://www.drupal.org/project/smart_date/issues/3174063 → so people would have to opt in to adding this markup if that helps. I put it here as a patch in the interest of sharing code.

But yeah we have Date Augmenter installed don't really know how to use that module, but ran across that other issue when trying to theme our smart date which is why I went this route.

You can leave it unmerged if you want I will just keep the patch here so it can be applied to our site.

Side note: If anyone knows how to get Guzzle Streams to work with a corporate firewall that does HTTPS inspections would love to know how.

Error I get is "There was an issue obtaining a response from OpenAI. The error was: Connection refused for URI https://api.openai.com/v1/chat/completions"

I modified the Merge request so that when there are errors it does not fail silently, and modified the openaiapi.php to not return just empty strings.

Now you get something like this when it fails. (For others this is likely HTTPS firewall inspections on corporate networks)

FYI for any others, the module does not appear to optimize image pre-upload. And if it did https://github.com/fengyuanchen/compressorjs isn't as good as a WASM solution like Photon https://github.com/silvia-odwyer/photon/wiki/Benchmarks

So I guess the path forward would be to use this as a base, and create a new module...

Would like to add another use case. I am primarily interested in this module for Webform Usage. Such as attempting to collect multiple images, say photos from a phone, 13 x 7MB each is alot to upload, and interested in a client side image optimizer to reduce the photos to web quality using https://uppy.io/docs/compressor/

Also was considering https://pqina.nl/filepond/

If you module doesn't already support this I most likely will be working on a patch!

So yeah I guess this was my mistake for keeping the same machine name, but also seems like a fairly common foot gun that could happen to others.

Yeah so steps to reproduce.

1. Start with a simple text are a form and submit a test submission

elements: |-
  title:
    '#type': textfield
    '#title': title
  site_contact_details:
    '#type': textarea
    '#title': 'site contact details'

2. Then import (drush cim) a new version of that webform that makes the field become a WYSWIG text area.

elements: |-
  title:
    '#type': textfield
    '#title': title
  site_contact_details:
    '#type': text_format
    '#title': 'site contact details'
    '#allowed_formats':
      webform_html: webform_html

3. Do another test submission

4. See errror on submisison page

Ok so diving into this a bit more over the last hour I can't reproduce the issue in a new form, but I think I have a better Idea as to what is going on.

What happened is a normal text area was "upgraded" to a WYSWIG, and it appears the same machine name was kept.

When I do this locally, and I mean
1. Delete the old text area
2. Readd the same field but as a WYSWIG field

I don't get an error.

But I think when we exported this change to config, and migrated it to prod is it possible that the migration process did not actually clear out the old plain text submissions?

Looking into this yes It seems when its rendering the submissions as soon as it gets past the new submissions which had 2 text areas with a conditional field. I get this error when its rendering out a submission from the old form that only had 1 text area and not conditionally hidden fields.

Locally I could get this fixed by adding

    // if value is array convert to string
    if (is_array($value)) {
      $value = implode(", ", $value);
    }

to

  /**
   * {@inheritdoc}
   */
  protected function formatHtmlItem(array $element, WebformSubmissionInterface $webform_submission, array $options = []) {
    $value = $this->getValue($element, $webform_submission, $options);

    $format = $value['format'] ?? $this->getItemFormat($element);
    $value = $value['value'] ?? $value;
    // if value is array convert to string
    if (is_array($value)) {
      $value = implode(", ", $value);
    }
    switch ($format) {
      case 'raw':
        return $value;

      case 'value':
        $default_format = filter_default_format(User::load($webform_submission->getOwnerId()));
        return check_markup($value, $default_format);

      default:
        return check_markup($value, $format);
    }
  }

NicholasS → created an issue.

My First attempt here explodes on ' ' spaces, wraps them based on the original format, and re assembles. So you get markup like
<span class="smart-date--date"><span class="part-d,">Thu,</span> <span class="part-m">Mar</span> <span class="part-j">28</span> <span class="part-y">2024</span></span>

The limitation here is that there has to be spaces, I think in most languages there are, but not sure if there is a more clever way of doing this, but it accomplishes what we need in terms of adding tags so that we can accomplish better designs.

Bug possibilities: if any of the PHP date formats had spaces it would cause issues, looks like "r" https://www.php.net/manual/en/datetime.format.php#refsect1-datetime.form... is the only one so I generally think this would work for all the different formats.

NicholasS → created an issue.

Screenshot of 8.x with the patch.

I would like to see this in the 8.x and up version.

I think you can, just use a comma to add multiple addresses

#20 worked for me core 10.1.x and 4.0.x

I would love an official how to on how to do this, also in this same boat.

https://git.drupalcode.org/project/content_reminders/-/blob/1.0.x/src/Co...

My Feedback, maybe you should do this like URL REDIRECTS module works, where the add button when clicked takes you to a form to create a redirect /admin/config/search/redirect/add?redirect=node/14931&destination=/node/14931/edit instead of trying to do it directly in the sidebar edit form.

FYI got past the composer issues with Drupal Lenient

"drupal-lenient": {
            "allowed-list": ["drupal/content_reminders"]
        }

Also enabled the module on our page content type.

And attempting to add a reminder in Gin and I get an ajax error /node/14931/edit?ajax_form=1&_wrapper_format=drupal_ajax

The website encountered an unexpected error. Please try again later.



Symfony\Component\HttpKernel\Exception\HttpException
: The specified #ajax callback is empty or not callable. in Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse()
(line 67
of core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php
).

Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException(Object, 'kernel.exception ', Object)
call_user_func(Array, Object, 'kernel.exception ', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.exception ') (Line: 239)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable(Object, Object, 1) (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

NicholasS → created an issue.

Have you tried #31 https://www.drupal.org/project/bootstrap_barrio/issues/3228330#comment-1... 💬 Bootstrap conflicts with Drupal core "placeholder" class Fixed ? I have been running that for long while with no issues.

There is usually always a way to target something even if they share identical CSS classes.

Drupal's .placeholder
[data-drupal-messages] .placeholder

Bootstraps .placeholder
.placeholder

There is probably a similar way to target the CKeditors place holder, likely a parent element or other attribute, if you share the details for CKeditors conflict I could help create one.

For anyone else who stumbles upon this and wants the solution.

Seems when the page is cached, there is no $node->current_view_mode; so I had to extract the view mode out of the cache tags to maintain the same theme suggestions as non-cached pages.

function THEME_theme_suggestions_page_alter(array &$suggestions, array &$variables) {
// Add suggestions for the page based off the node type and view mode
  $node = \Drupal::routeMatch()->getParameter('node');
  if ($node) {
    // Get the nodes current view mode by extracting it from  cacheTags()array 0:"config:core.entity_view_mode.node.preview" its the last part of the string
    $cacheTags = $node->getCacheTags();
    // loop over cacheTags to find the view mode entity_view_mode and extract the view mode from the string
    foreach ($cacheTags as $cacheTag) {
      if (strpos($cacheTag, 'entity_view_mode') !== false) {
        $cache_node_view_mode = substr($cacheTag, strrpos($cacheTag, '.') + 1);
      }
    }
    $node_view_mode = $node->current_view_mode;
    // use either current_view_mode or the one from the cacheTags
    $node_current_view_mode = !empty($node_view_mode) ? $node_view_mode : $cache_node_view_mode;
    $suggestions[] = 'page__' . $node->getType() . '__' . $node_current_view_mode;
  }
}

Awe thanks, ok yeah must be my theme suggestions. I see I have something like

function THEME_theme_suggestions_page_alter(array &$suggestions, array &$variables) {

  // Add suggestions for the page based off the node type and view mode
  $node = \Drupal::routeMatch()->getParameter('node');
  if ($node) {
    $suggestions[] = 'page__' . $node->getType() . '__' . $node->current_view_mode;
  }

}

and

function THEME_preprocess_node(array &$variables, $hook)
{
  if (isset($variables['view_mode'])) {
    $node = $variables['node'];
    $node->current_view_mode = $variables['view_mode'];
  }
}

I'll play with those, I guess when its cached those suggestions for some reason are not being fired.

Does the display also change when you reload the switched node several times after it has been cached?

I only see the switched mode immediately after the node is saved. Refreshing a second time+ I see the default view mode continuously.

I will add in another part of the site we are using this module, to display a field in another view mode and it works correctly. I know my needs might be non-typical use of the field, as I want it to "bubble up" a change so to speak to affect the header, aka use a different twig template.

Maybe I am just miss-using the module? Love if it could help the my use case though! :D

Ok I loaded up the page when it was the "default" view mode. Then saved the page which triggered the view mode switch, here is a diff of the cache markup
https://www.diffchecker.com/fNijtehK/

The right side when it says "

" is when I see the view mode switch (no-headers-or-footers)

I'll attach a video too as there is alot more cache tag info hope I got the right ones you wanted.

Thanks for the fast reply.

so I wanted to ask, if this is something you render programmatically or is the whole page created by your node template?

Yeah sorry some missing details. The default view of my pages is the page.html.twig and when I change the view mode the page should be using page--page--no-headers-or-footers.html.twig no-headers-or-footers being the name of the view mode. And yeah its just simple hardcoded HTML in that twig that sets a different header/footer.

When I remove that cache clear I added, and I get that normal view mode when its not supposed to I see its using the default view mode.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'page' -->
<!-- FILE NAME SUGGESTIONS:
   * page--page--.html.twig
   x page--node--page.html.twig
   * page--node--72661.html.twig
   * page--node--%.html.twig
   x page--node--page.html.twig
   * page--node.html.twig
   *

Then I re-save the page and get the view mode suggestion.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'page' -->
<!-- FILE NAME SUGGESTIONS:
   x page--page--no-headers-or-footers.html.twig
   * page--node--page.html.twig
   * page--node--72661.html.twig
   * page--node--%.html.twig
   * page--node--page.html.twig
   * page--node.html.twig
   * page.html.twig
-->

Let me dive into the cache debug in services.yml and report back with those findings.

Uploading a view of the behavior, along with showing how the current change appears to solve it.