This appears to be fixed in a different way in 2.1.0.
line 109:
$link_id = $config->get('link');
$default_node = ($link_id !== NULL && $link_id !== '')
? $this->entityTypeManager->getStorage('node')->load($link_id)
: NULL;
line 171:
'#default_value' => $default_node,
Looks as if the commerce "returning customer" login also bypasses email_tfa by using its own login form.
Thanks for your patience and guidance. I've tried to replicate the changes in modeler_api but there are some errors that don't make sense to me.
Changing status in hopes of getting this (and others) committed and released for Drupal 11 soon.
Can we get this in a release? It just updates the info.yml file to include Drupal 11.
Marking "fixed" after four months in "needs review" with no comments.
Marking "fixed" after six months in "needs review" with no comments.
Marking "fixed" after five months in "needs review" with no comments.
Marking "fixed" after seven months in "needs review" with no comments.
Marking "fixed" after three months in "needs review" with no comments.
A couple of updates; I didn't have much time for this today.
@jurgenhaas: "When it comes to implementation, it's probably best to create a separate module eca_simplenews for this, so that the simplenews maintainers don't have to worry about it."
Should this issue be moved to ECA then?
@jurgenhaas: "I'd assume that this should be possible by parsing the field values of the subscriber history entity. Maybe the token browser helps a bit with understanding the data structure?"
Here's the structure for simplenews_subscriber_history:
Not a lot to work with there except "source," but even that looks ambiguous.
- "route:simplenews.subscriptions_remove" is the unsubscribe link in the newsletter's footer, so that would probably be a user unsubscribe.
- "route:simplenews.subscriber_unsubscribe" is the admin mass-unsubscribe page, so that's an admin unsubscribe.
- "route:entity.simplenews_subscriber.edit_form" is also an admin unsubscribe.
- "route:simplenews.newsletter_subscriptions_user" is a user page, but it's also visible to admin. I also don't see a way to tell the difference between subscribes and unsubscribes from that form.
It gets even more confusing when there are multiple events from both users and admins. I guess you'd have to sort by timestamp desc and then puzzle it out.
Here's the simplenews_subscriber_history__subscriptions table:
The "deleted" field looks promising but I haven't been able to figure out where it's set. All the values in my table are 0.
Maybe the biggest problem is that simplenews doesn't appear to have an active/inactive setting for individual subscriptions, just for subscribers. So an ECA model would have to (1) act on a role change, (2) check whether that user had previously self-unsubscribed, then (3) either subscribe the user (if there is no previous self-unsubscription) or leave it unsubscribed (if previously self-unsubscribed). I was hoping to flip an "active" flag and leave the user subscribed but not receiving mail. Oh well.
Drupal Version
10.5.3
PHP
Version
8.3.23
image_field_caption
Version: 4.0.0-rc4
I don't see anything suspicious in the last six months. If I see it again, I'll reopen.
I've just started looking at this after stalling as long as possible, and at first glance it looks as if a lot of the pieces are already in place.
Subscribers and subscriber history are entities, as are newsletters, which are just ordinary content nodes. So the existing ECA Content actions, etc., should work on them, right?
In addition, simplenews has "send newsletter issue" and "stop sending" actions, which are already visible with ECA Core, ECA UI, and Simplenews installed. I haven't tested them, but if they work, we're getting closer.
What's still missing, I think:
1. An "activate subscription" action. Simplenews has "hook_simplenews_subscription_operations," which includes both activate and deactivate. Can ECA use those? If not, how can they be converted to ECA actions?
2. A "deactivate subscription" action. Same comment.
3. Some way to parse the Simplenews subscriber history entity and identify subscribers who have previously unsubscribed (and therefore should not be resubscribed). Still digging into how that works.
Here's how I think it could be used to sync user roles with simplenews subscriptions, replacing the D7 simplenews_roles module, which happens to be my main need. I'm still a little fuzzy on some details. Should users who lose a role be unsubscribed or just deactivated? Probably deactivated in light of #3 above. And there may be other pieces missing that I haven't thought of, beyond the two Simplenews hooks listed above. But I hope this will at least help keep things moving. This is all with Drupal 11.2.4, ECA 3.03, and Simplenews 4.1.1.
Subscribe/unsubscribe/activate/deactivate when user is updated/created
events:
a. user (entity) is created (ECA Content/Insert content entity; existing)
b. user (entity) is updated (ECA Content/Update content entity; existing)
Type/bundle choices include:
Simplenews subscriber: Any
Simplenews subscriber: Simplenews subscriber
User: Any
User: User
conditions:
a. user has role (ECA User/Role of user; existing)
b. user has subscription (ECA Content/Entity: load by type [Simplenews subscriber] and properties [email address]; existing)
c. user has previously unsubscribed (ECA Content/Entity: load by type [Simplenews subscriber history] and properties [email address]; existing)
actions:
a. create new subscription (ECA Content/Entity: create new [Simplenews subscription]; existing)
b. delete subscription (ECA Content/Entity: create new [Simplenews subscription]; existing)
c. deactivate subscription (hook_simplenews_subscription_operations; needs work)
d. activate subscription (hook_simplenews_subscription_operations; needs work)rclemings → created an issue.
Looks good now, thanks. I'll open a new issue if I see anything more.
1. I'm not sure I understand what you mean by "applies default settings for fields," but after I update to beta4 and run drush updb/cr, both the "Enable Title field" and "Enable Caption field" are unchecked, whereas both were checked previously.
I updated the field settings in the UI and reloaded the node, and the titles/captions were restored with no data loss, but it seems like a step backward if every image on every content type has to have its settings edited after the update.
2. Your "drush config:set" fix for the "plain text" format works and seems safe enough. Worth adding a note to the release page (or even a change record)?
Much better. 4.0.0-beta2 seems to work, at least for the specific case in this issue summary.
I do see two new (minor I think) problems:
1. Opening an existing node with image captions, I get this error three times (there are three images on the node, although one is a type that does not allow captions):
Warning: Undefined array key "caption_allowed_formats" in image_field_caption_field_widget_single_element_image_image_form_alter() (line 42 of modules\contrib\image_field_caption\image_field_caption.module).
image_field_caption_field_widget_single_element_image_image_form_alter() (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter() (Line: 88)
Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->alter() (Line: 470)
Drupal\Core\Field\WidgetBase->formSingleElement() (Line: 140)
Drupal\file\Plugin\Field\FieldWidget\FileWidget->formMultipleElements() (Line: 115)
Drupal\image\Plugin\Field\FieldWidget\ImageWidget->formMultipleElements() (Line: 120)
Drupal\Core\Field\WidgetBase->form() (Line: 190)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm() (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form() (Line: 134)
Drupal\node\NodeForm->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 637)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
I think this error occurs if nothing is checked under "Caption field allowed text formats" on /admin/structure/types/manage/CONTENTTYPE/fields/node.CONTENTTYPE.field_image. This setting did not exist previously, as far as I can tell, so it might affect a lot of users.
A solution I found is to wrap line 42 of image_field_caption.module in an if/else:
if (!empty($settings['#caption_allowed_formats'])) {
$element['#caption_allowed_formats'] = $settings['caption_allowed_formats'];
}
else {
$element['#caption_allowed_formats'] = NULL;
}2. Except for those errors, the node opens OK for editing.
However, for each of the images that allow captions, in some cases, the text format (under "caption") is 'plain text." All of the other formats are listed as well. When I save one of those nodes as draft, the save fails with this:
Error message
The submitted value plain_text in the Text format element is not allowed.I think this is an issue mainly, or even solely, for sites that have been migrated from Drupal 7. In Drupal 10, on /admin/config/content/formats, the "plain text" format says: "This format is shown when no other formats are available." That was not the case in Drupal 7, so there are quite a few captions with "plain text" format.
In any event, the simplest solution is changing the image caption format, so this is not a major problem, but it may confuse some users, so there may be a more user-friendly answer.
I plan to do some more testing tomorrow and will update with any additional finds. Appreciate the improvements.
Do you mean 3.0.1?
4.0.x is listed as beta.
I don't know if the lack of response means no one has seen this problem, but I'm doing a patch for my affected site, so I will add it here in case (as well as a MR) it's of use to someone else.
Just ran into this when an unknowing co-worker disabled CIM from the Authorize.net account.
I know there's no way to post a "don't do that" warning on Authorize.net, but could there be a warning on the Drupal site -- status report, or better, in the message area on admin pages -- if CIM is disabled?
If that's not possible -- how would Drupal know it's disabled until a payment fails? -- then could a sentence like "This module requires Customer Information Manager (CIM) to be enabled on the Authorize.net account" be added on https://www.drupal.org/project/commerce_authnet/ → (under Registering with Authorize.Net) and on https://www.drupal.org/docs/contributed-modules/commerce-authorizenet/in... → and perhaps elsewhere?
rclemings → created an issue.
Unfortunately, I'm still getting sporadic errors, sporadic I guess because the module doesn't need to hit the Mailman site on every request. I can't tell for sure but it looks to me as if the problem lies is in the "convenience methods." So I've tried a different approach, just copying the results of the getBody() and getStatusCode() functions to the $result variable.
$result->body = $response->getBody();
$result->statusCode = $response->getStatusCode();
(Lines 992-993 of user_mailman_register.module)
So far, I'm not seeing any errors with PHP 8.3.13. Fingers cross.
Let me know if you see a problem with this change.
rclemings → changed the visibility of the branch 3526170-dynamic-property-deprecated to hidden.
I'm getting this WSOD intermittently now:
Error: Call to undefined method stdClass::getStatusCode() in _user_mailman_register_parse_http() (line 1050 of modules/contrib/user_mailman_register/user_mailman_register.module).
I think the problem is this code is in the try and catch blocks just prior but isn't available at line 1050:
// Add convenience methods
if ($response) {
$result->getBody = function() use ($response) {
return $response->getBody();
};
$result->getStatusCode = function() use ($response) {
return $response->getStatusCode();
};
}
I added that code again before line 1050 and it seemed to take care of the error. Does that look right to you? Probably not the best way to address the problem though.
I spun up a site with PHP 8.3.13 and the patch worked, with no obvious harm to a site running PHP 8.1.32, so I've merged it. Thanks.
Please do. I may not be able to test it right away but at least it will be available for anyone who needs it.
Most if not all of the other patches you see were written by me and have not been reviewed by anyone else. If they work for you and you're comfortable doing so, please mark them RTBC and I can put them in a new release.
Just hit this bug and the patch works so I'll mark as RTBC while y'all figure out the merging and pushing.
rclemings → created an issue.
Latest dev includes fixes for Drupal 11, based on https://dev.acquia.com/drupal11/deprecation_status/projects/user_mailman_register. I don't have a site to test them on at this time, so feedback is welcome on issue #3513850.
rclemings → created an issue.
rclemings → changed the visibility of the branch 3513850-fix-reported-drupal to hidden.
rclemings → changed the visibility of the branch 3513850- to hidden.
rclemings → created an issue.
rclemings → changed the visibility of the branch 3513578-clean-up-date to hidden.
rclemings → created an issue.
rclemings → created an issue.
Related: It looks as if the system is using this module's receipt template for all orders, even those that don't use the purchase order gateway.
Is that correct/intended?
If so, would it make sense to add the theme suggestions only for purchase orders? Maybe wrap it in something like:
if ($variables['order_entity']->get('payment_gateway') == "purchase_order") {
}I'd like to customize the template for other payment methods and this is a complication.
Thanks, that worked.
I'm not clear, though, on how I should have known to do that. Should I just run it routinely after any module is updated? (No ECA module was updated in this round.) Is there something I missed in the UI? Or should the tamper module have included an update hook?
I should add that the model still seems to work fine. The error just appears in the watchdog log.
rclemings → created an issue.
Sorry I haven't gotten around to making the improvements requested in #4. Meanwhile, here's a new version of the patch for 2.1.0.
rclemings → created an issue.
Just bumping this because it's been almost three months since the last activity and v3.0.0 is needed for Drupal 11 compatibility. Happy to try to assist with testing or other needs, but the simple (one line in each of two files) patch from the merge request works fine for me with 3.0.0-beta4 .
Also changing priority to major because, as noted in comment #5:
Without this patch, you cannot put anything in your cart after enabling the module, this is quite major when using Commerce.
Also changing status to "needs review" because I can't see what work is left except the issue in comment #11, which if valid, might be handled with a change record.
rclemings → created an issue.
FWIW I'm no longer seeing this issue with the current (3.1.0) release and no patches installed.
That would be great. For the benefit of others in the meantime, I ended up doing something like this in a custom module event subscriber:
function custom_module_form_submit(array $form, \Drupal\Core\Form\FormStateInterface $form_state) {
// Can't delete single messages, so loop though them, save the ones we want, then delete all by type, and restore the ones we want.
$messages = \Drupal::messenger()->messagesByType('status');
$n = 0;
foreach($messages as $message) {
// if message starts with "Xxxx Xxxx" and ends with "has been created." do nothing, otherwise save it
if (str_starts_with($message, "Xxxx Xxxx") && str_ends_with($message, "has been created.")) {
} else {
$saved_messages[] = $messages[$n];
}
$n = $n+1;
}
\Drupal::messenger()->deleteByType('status');
foreach($saved_messages as $message) {
\Drupal::messenger()->addStatus($message);
}
}
Circling back on this because it's still an issue for me. Let me see if I understand this correctly.
If "update" and "publish" are both checked in the DANSE content type tab, only the "update" notification will be sent, even if only one user has an "update" subscription and 100 have a "publish" subscription.
That seems to be the case for me. I unchecked "update" on the content type tab, and now all of the "publish" notifications are being sent.
What would happen if I changed the default value for "Force push even if this creates duplicate notification" and checked both "update" and "publish" on the content type tab? Would the one "update" subscriber get his "update" notification and the 100 "publish" subscribers all get their notifications?
Alternatively, what you suggest in #4 would work as well, as far as I can tell. I could take a look at it if that is your preferred approach, but I can't promise I'll have the time or skills to tackle it right away. My own thinking is that the best solution would be to silence the duplicate notifications only for subscribers who are receiving both notifications. If that's possible.
Maybe we need to go to the stretch of finding out if the status field was the only change during an entity update. If so, we silence the update event; otherwise, we silence the publish/unpublish event.
Update:
Certificate Migration Schedule
Sandbox/Production: Feb 2025, exact date for switch over will be provided soon. It is recommended to complete adding any support for the new certificate by January 31, 2025.
https://support.authorize.net/knowledgebase/Knowledgearticle/?code=KA-05545
I'm not seeing this anymore.
Drupal 10.4.0
Views data export 8.x-1.5 with patch from issue 3173296 (comment #10)
New beta released today.
Included in 1.0.0-beta3.
Included in 1.0.0-beta3.
Included in 1.0.0-beta3.
Included in 1.0.0-beta3.
The edit tab is provided by the entity contrib module (/src/Plugin/Derivative/EntityTasksDeriver.php), which is required by commerce, which is required by commerce_fee. So the menu item in commerce_fee.links.task.yml is redundant, correct?
rclemings → made their first commit to this issue’s fork.
I'm still seeing this so removing the draft flag. I see that the function name currently specifies "StreamedResponse" but four lines later, when the $response variable is initiated, it says "CacheableReponse." Does that explain the error?
$response = new CacheableResponse('', 200);
Drupal 10.3.10
PHP 8.1.31
Views PDF 3.0.0-alpha10+3-dev
I have no recollection of this error and am not using this module now, so closing the issue is no problem for me.
Now scheduled for Jan. 15: https://status.authorize.net/incidents/ynl52t1jg58c
According to this the certificate change was rolled back. Not clear where it stands now.
OK, this is all pretty confusing to me and consequently this may be a stupid question but here goes:
I'm looking at /vendor/commerceguys/authnet/resources/cert.pem on my server and it already has certificates for:
DigiCert Assured ID Root CA
DigiCert Global Root CA
DigiCert High Assurance EV Root CA
DigiCert Assured ID Root G2
DigiCert Assured ID Root G3
DigiCert Global Root G2
DigiCert Global Root G3
DigiCert Trusted Root G4
I compared the DigiCert certificates in that file to the latest (2024-09-24) from https://curl.se/docs/caextract.html and they're all identical.
Does that mean I don't have to do anything?
@catch: I agree FWIW:
Although it looks like as long as one of the change from here or the other issue, that times are within margin of error at least as measured by the full page request.
Cross-posted from https://www.drupal.org/project/admin_toolbar/issues/3459723#comment-1580... 📌 Bypass slow access checks Postponed: needs info upon request:
I spent the past couple of weeks troubleshooting (e.g. database tuning) some extremely slow page loads on admin pages. Today I found this thread and I think it solved my problem.
I'll try to address the questions from @benjifisher in the previous comment although the Drupal versions are different.
I chose a random user profile and recorded the following in Firefox dev tools (network tab, cache disabled). All values are for the first line in the dev tools output -- initiator: document, type: html. There are a lot of other elements (js, css) loading after that but they're all pretty fast:
All tests were done with Drupal 10.3.5, and admin_toolbar 3.5.0. Rebuilt cache before each of these:
I think #6 must be with both patches applied, as you surmised. I didn't keep my notes, unfortunately.
Cross-posting to issue 3384600 momentarily.
I spent the past couple of weeks troubleshooting (e.g. database tuning) some extremely slow page loads on admin pages. Today I found this thread and I think it solved my problem.
I'll try to address the questions from @benjifisher in the previous comment although the Drupal versions are different.
I chose a random user profile and recorded the following in Firefox dev tools (network tab, cache disabled). All values are for the first line in the dev tools output -- initiator: document, type: html. There are a lot of other elements (js, css) loading after that but they're all pretty fast:
Rebuild cache before each of these:
1. drupal 10.3.5, admin toolbar 3.5.0 installed and admin_toolbar_tools 3.5.0 installed (Untitled-6.png)
-- waiting 13.07s, receiving 458 ms
2. drupal 10.3.5, admin toolbar 3.5.0 installed and admin_toolbar_tools 3.5.0 uninstalled (Untitled-7.png)
-- waiting 3.20s, receiving 400 ms
3. drupal 10.3.5, admin toolbar 3.5.0 uninstalled and admin_toolbar_tools 3.5.0 uninstalled (Untitled-8.png)
-- waiting 2.96s, receiving 308 ms
4. drupal 10.3.5, admin toolbar 3.5.0 installed and admin_toolbar_tools 3.5.0 installed with patch from core issue #3384600 (MR9500) (Untitled-9.png)
-- waiting 3.58s, receiving 307 ms
5. drupal 10.3.5, admin toolbar 3.5.0 installed and admin_toolbar_tools 3.5.0 installed with patch from this (MR82) (Untitled-10.png)
-- waiting 4.21s, receiving 491 ms
6. drupal 10.3.5, admin toolbar 3.5.0 installed and admin_toolbar_tools 3.5.0 installed with patch from this (MR82) (Untitled-11.png)
-- waiting 4.86s, receiving 528 ms
So ... either patch helps, but the core patch helps slightly more, and both togather help slightly less.
For now I think I'm just going to use the core patch (issue #3384600 MR9500).
When I've seen this it's usually been an issue with file permissions. I don't know why an upgrade would have changed them but it's worth checking.
rclemings → created an issue.
This works as far as I can tell. No errors or any other feedback. Thanks.
jurgenhaas → credited rclemings → .
Thanks for this. I was going to try to work on it this week but from the looks of it I don't think I would have gotten very far. It applies cleanly to DANSE v2.3.5 and with the update and a cache rebuild (maybe not needed?) it works. I'll leave it at "needs review" in case somebody else is watching.
rclemings → created an issue.
In the course of troubleshooting issue #3355294 I noticed that I'm getting this error again. It's not fatal, just appears in the logs. I still can't figure out the cause. Maybe the traceback will help.
TypeError: Drupal\views_pdf\Plugin\views\display\PDF::buildResponse(): Return value must be of type Symfony\Component\HttpFoundation\StreamedResponse, Drupal\Core\Cache\CacheableResponse returned in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 145 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php).
#0 /home/xxxxxx/public_html/web/core/modules/views/src/Routing/ViewPageController.php(56): Drupal\views_pdf\Plugin\views\display\PDF::buildResponse('id_card', 'pdf_5', Array)
#1 [internal function]: Drupal\views\Routing\ViewPageController->handle('id_card', 'pdf_5', Object(Drupal\Core\Routing\RouteMatch))
#2 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#3 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#4 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#5 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#6 /home/xxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#7 /home/xxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#8 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /home/xxxxxx/public_html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /home/xxxxxx/public_html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /home/xxxxxx/public_html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /home/xxxxxx/public_html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#20 {main}This looks like a caching issue. I was able to resolve it by setting "Caching" to "None" under "Advanced/Other" in the view configuration. The patch wasn't necessary.
The OP's error was actually just the first of four (below). I noticed though that the problem went away if I rebuilt the Drupal cache. So disabling caching for the affected view was an easy fix, though there might be a better one.
Warning: Undefined array key "view_build" in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 139 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
Warning: Trying to access array offset on value of type null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 139 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
Warning: Attempt to read property "pdf" on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php)
Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php).I'm on Drupal 3.1 and mail_login 3.0 still seems to work. You just get a warning on /admin/modules/update.
This looks like the problem -- committed but not released yet.
https://www.drupal.org/project/commerce/issues/3464144 📌 Replace UserAuthInterface with UserAuthenticationInterface for Drupal 11 Support Fixed
Reverting to 3.0 also fixes it.
rclemings → created an issue.
This applies cleanly to ECA 1.17 and Drupal 10.3.1 and appears to fix the problem. It won't run on the live site until Tuesday, but I'll report back if there is a problem then.
Just one more note. The cron error was stopping the execution of cron, which meant that none of the cron jobs following ECA cron were running. I worked around this by disabling the ECA cron job. This required installation of Ultimate cron, which permits you to disable a cron job through the UI or (in my case) by exporting and importing the config entry, changing "status" to "false." I'm still not able to disable or edit the ECA model. I may try deleting it via drush later.
Further, I get the same error if I try to edit or disable the model via the ECA UI, and when I try to import the model into another copy of the site.
If I export the ECA Model config and import it with "status: false," it changes the status in the config but not in the UI.
I guess that means I have to change the ECA config instead of the ECA Model config, but when I do that I get this rather mysterious error:
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "private__rDYu60sbWI6g2UEYW4S8VBr9C-73LnNXEJFYjSRvGS8". in Drupal\Component\DependencyInjection\Container->get() (line 159 of core/lib/Drupal/Component/DependencyInjection/Container.php).
The model worked fine in Drupal 10.2.7 and (if I recall correctly) Drupal 10.3.0. It fails only in Drupal 10.3.1.