🇺🇸United States @rclemings

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.

https://status.authorize.net/incidents/ynl52t1jg58c

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.

I just started seeing this too, after enabling an ECA model that used the cron event. (Cron runs from crontab using wget.) I also updated Drupal core to 10.3.1 and hook_event_dispatcher to 4.0.3 about the same time. ECA is 1.17.

Here's a traceback in case it helps:

Error: Call to a member function get() on null in Drupal\Core\Cache\CacheCollector->lazyLoadCache() (line 352 of /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cache/CacheCollector.php)

#0 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cache/CacheCollector.php(144): Drupal\Core\Cache\CacheCollector->lazyLoadCache()
#1 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/State/State.php(80): Drupal\Core\Cache\CacheCollector->get('timestamp.cron-...')
#2 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/EcaState.php(77): Drupal\Core\State\State->get('timestamp.cron-...', 0)
#3 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/Event/CronEvent.php(105): Drupal\eca\EcaState->getTimestamp('cron-Event_06cl...')
#4 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/Event/CronEvent.php(71): Drupal\eca_base\Event\CronEvent->isDue('Event_06clj7s', '0 2 * * *')
#5 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Entity/EcaStorage.php(106): Drupal\eca_base\Event\CronEvent->appliesForLazyLoadingWildcard('Event_06clj7s::...')
#6 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Processor.php(135): Drupal\eca\Entity\EcaStorage->loadByEvent(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#7 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/EventSubscriber/EcaBase.php(76): Drupal\eca\Processor->execute(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#8 [internal function]: Drupal\eca\EventSubscriber\EcaBase->onEvent(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#9 /home/xxxxxxx/public_html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#10 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Event/TriggerEvent.php(73): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#11 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/HookHandler.php(71): Drupal\eca\Event\TriggerEvent->dispatchFromPlugin('eca_base:eca_cr...', Object(Drupal\eca\EcaState), Object(Drupal\Core\Datetime\DateFormatter), Object(Drupal\eca\ConfigurableLoggerChannel))
#12 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/eca_base.module(24): Drupal\eca_base\HookHandler->cron()
#13 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(335): eca_base_cron()
#14 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(395): Drupal\Core\Cron->Drupal\Core\{closure}(Object(Closure), 'eca_base')
#15 /home/xxxxxxx/public_html/web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php(68): Drupal\Core\Extension\ModuleHandler->invokeAllWith('cron', Object(Closure))
#16 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(343): Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->invokeAllWith('cron', Object(Closure))
#17 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(159): Drupal\Core\Cron->invokeCronHandlers()
#18 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/ProxyClass/Cron.php(75): Drupal\Core\Cron->run()
#19 /home/xxxxxxx/public_html/web/core/modules/automated_cron/src/EventSubscriber/AutomatedCron.php(65): Drupal\Core\ProxyClass\Cron->run()
#20 [internal function]: Drupal\automated_cron\EventSubscriber\AutomatedCron->onTerminate(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#21 /home/xxxxxxx/public_html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#22 /home/xxxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(115): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...')
#23 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(66): Symfony\Component\HttpKernel\HttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#24 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/DrupalKernel.php(715): Drupal\Core\StackMiddleware\StackedHttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#25 /home/xxxxxxx/public_html/web/index.php(22): Drupal\Core\DrupalKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#26 {main}

rclemings → created an issue.

Patch attached.

rclemings → created an issue.

Patch attached.

rclemings → created an issue.

Patch attached.

rclemings → created an issue.

Works fine on both issues. Thanks.

rclemings → created an issue.

I thought it might be something like that. Sorry I didn't dig deeper into the code first. It was getting late.

The only thing I would question is whether publish shouldn't force update to silent, instead of the other way around. Publish seems like the more important event to me, but maybe that's just because of my use case. (Same for unpublish.)

Trying to think this through ... if content is published, that's an update in itself (right?) so in that case, it's the update event that is superfluous.

Of course, there might be an additional update before the publish event, and the notification for that would be silenced if the content is then published before the next cron. How important is that? Beyond that, how many non-admins are going to request update notifications anyway?

On createContent and deleteContent, I think the existing design makes sense.

rclemings → created an issue.

Is this still a work in progress or is it ready to use (more or less)?

I'm not sure. I see that 2.3.x-dev already has all of the fixes (except the possibly unneeded "title" argument at line 114). Is that what you needed me to check? Either way, it's working fine for me so I guess you can just ignore this MR. Sorry for the noise. Maybe I based it on 2.3.3 instead of 2.3.x-dev.

rclemings → created an issue.

Any idea whether this can be fixed soon? I'd like to use it for a current project.

One caveat:

It says here that role_paywall doesn't work with layout builder. It's not clear if/when that will be fixed:

https://www.drupal.org/project/role_paywall/issues/3376583#comment-15503960 🐛 Paywall module not working with layout builder Active

@quietone: Understood. I don't think my patch applies any more anyway, and in any case, it just skipped the problem record instead of importing it.

The real issue turned out to be missing entries for one order in these tables:

field_revision_commerce_line_items
field_revision_commerce_total
field_revision_commerce_order_total
field_revision_commerce_customer_billing

I fixed it by populating those fields from their field_data_commerce_* counterparts and now everything works fine.

(Posting just in case it helps someone else.)

For one order, and only one, I just found a situation similar to #15 -- an entry in field_data_commerce_line_items but no matching entry in field_revision_commerce_line_items. Moreover, the same was true for the following tables as well:

field_data_commerce_total/field_revision_commerce_total
field_data_commerce_order_total/field_revision_commerce_order_total
field_data_commerce_customer_billing/field_revision_commerce_customer_billing

The same fix worked in each case -- export the record from field_data and import it into field_revision. Took quite a while to figure that out though.

The only error I saw at any point was "upgrade_commerce1_order:total_price: CommercePrice input array is invalid for destination 'total_price'." Better than nothing but not really that informative.

I know this is awaiting a refactoring but meanwhile I had to move ahead with a migration and made a patch from the current merge request. To say others step I have attached it here.

Patch for those who prefer the old style.

This took me a while to figure out and probably affects a lot of people. I propose it be added to README.md pending a complete fix. Will do a merge request.

I'm not getting this in the current dev version, though the code is unchanged. I'll reopen if necessary.

rclemings → created an issue.

The code looks different in the current dev. I can't find a commit that did that. I'll reopen if it's still a problem.

rclemings → created an issue.

rclemings → created an issue.

I had one site with the error and one without. The site with the error had these modules that weren't on the unaffected site:

globalredirect (PATH MANAGEMENT)
metatag (SEO)
better_exposed_filters (VIEWS)
profile2 (OTHER)
search_api (SEARCH)

I disabled them one by one (along with their dependencies) and it made no difference.

Just one more data point.

I added some watchdogs to the .module file and figured out how to fix the problem, although I don't understand why it wasn't working in the first place.

I added this after line 199:

watchdog("_antibot", "form_state_input_antibot_key: <pre>" . print_r($form_state['input']['antibot_key'], TRUE) . "</pre>");
watchdog("_antibot", "form_id in antibot_form_validation: <pre>" . print_r($form['#form_id'], TRUE) . "</pre>");
watchdog("_antibot", "antibot_generate_key: <pre>" . print_r(_antibot_generate_key($form['#form_id']), TRUE) . "</pre>");
watchdog("_antibot", "form_state_key: <pre>" . print_r($form_state['input']['antibot_key'], TRUE) . "</pre>");

I added this after line 212:

watchdog("_antibot", "form_id in _antibot_generate_key: <pre>" . print_r($form_id, TRUE) . "</pre>");

That gave me the following results in the watchdog log (in order):

form_id in _antibot_generate_key: job_advertisement_node_form
form_id in _antibot_generate_key: comment_node_article_form
form_state_input_antibot_key: 1eaa6fbfdb079197d7f04912d6aa1f79
form_id in antibot_form_validation: comment_node_article_form
form_id in _antibot_generate_key: comment_node_article_form
antibot_generate_key: 4f287b465e1f4cfd8eeb32033a1e28bf
form_state_key: 1eaa6fbfdb079197d7f04912d6aa1f79

I added another watchdog to check the value of $form['#form_id'] and it was "comment_node_article_form." Why, I don't know. Comments are closed on that comment type and the comment form doesn't appear anywhere on the page. If I search the page source for "comment" I get no hits.

Anyway I changed line 199 to get the form_id from the form element:

//    $expected_key = _antibot_generate_key($form['#form_id']);
    $expected_key = _antibot_generate_key($form['form_id']['#value']);

And now it seems to work. (Haven't moved it to the live site yet, but it's working in devel.)

Here's what I get in the watchdog now (only the second line is different):

form_id in _antibot_generate_key: job_advertisement_node_form
form_id in _antibot_generate_key: job_advertisement_node_form
form_state_input_antibot_key: 1eaa6fbfdb079197d7f04912d6aa1f79
form_id in antibot_form_validation: comment_node_article_form
form_id in _antibot_generate_key: comment_node_article_form
antibot_generate_key: 4f287b465e1f4cfd8eeb32033a1e28bf
form_state_key: 1eaa6fbfdb079197d7f04912d6aa1f79

Does that clarify anything? I'm pretty much at the limit of my understanding of how forms work but the fact that $form['#form_id'] and $form['form_id']['#value'] are different seems significant.

rclemings → created an issue.

Another site on the same server as the first one (CentOS) doesn't seem to have the problem. I think I'm going to have to figure out what's different about those two sites.

I'm seeing this on a second site now, different server (both are Knownhost with cPanel but different OSs, Centos 7 vs. AlmaLinux 8, not that any of that would matter).

Here are the contrib modules they have in common, fwiw:

better_exposed_filters
ctools
date
entity
entityreference
field_group
globalredirect
libraries
link
masquerade
metatag
pathauto
profile2
redirect
rules
search_api
token
views_data_export
views
wysiwyg
xmlsitemap

No external caching. I wonder if there's some js conflict with another module. Not sure where to start looking.

Thanks. Let me know if you need any more details off list.

@danrod:

After updating to 7.x-1.3, I'm getting the error "Submission failed. Please reload the page and try again" similar to the one referenced in https://www.drupal.org/project/antibot/issues/3419697#comment-15455166 🐛 No longer protecting Fixed .

It happens with a clean browser or a used one, normal mode or private/incognito, and every browser I tried (Firefox, Chrome, Opera, Edge), all up-to-date.

It happens on a live site with JS compression enabled and a development site with JS compression disabled.

Suggestions? Rolling back to 7.x-1.2 fixes the problem.

Patch for those who prefer the old-fashioned way (including me).

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

I tried that but got an out-of-memory error. I didn't investigate but I suspect there could be a problem if there are four or more newlines in a row.

Bullets are stripped and not replaced with anything meaningful either, so I added another line to handle that:

        $output = str_replace("</p>\n<p>", "\n\n", $output, $count);
        $output = str_replace("<li>", "  * ", $output, $count);
        $output = trim(PlainTextOutput::renderFromHtml($output));

FWIW, I agree with removing the "Strip first line" code unless there a good reason for it that isn't stated here. It's causing me problems with a lot of notifications.

I also agree with @eelkeblok that double line breaks can be a good and necessary thing for readability, so I've made this change:

//          $output = str_replace(["\n ", "\n\n"], "\n", $output, $count);
          $output = str_replace("\n ", "\n", $output, $count);

Meanwhile, I think I found a third issue related to this block of code.

For one content type, I want to send the full body field in the notification. The body field is composed with the Restricted HTML text format, unmodified except that CKEditor5 is the text editor and the "Correct faulty and chopped off HTML" filter is added. The order of the filters is "Limit allowed HTML tags and correct faulty HTML", "Convert URLs into links", "Convert line breaks into HTML (i.e. <br> and <p>)", and "Correct faulty and chopped off HTML."

In the editor and on the page, there's a blank line between each paragraph. But in the notification, it's all one block, with no spaces between the paragraphs. It's hard to read, at least for my aging eyes.

What I think is happening is this:

$output = trim(PlainTextOutput::renderFromHtml($output));

That line is stripping the HTML tags from the content. As a result, what was "</p>\n<p>" becomes just "\n." That means there are no spaces between paragraphs (i.e. it needs to be "\n\n" instead of "\n").

My quick and dirty fix is to add a str_replace just before the "renderFromHtml" line, basically stripping the paragraph tags and replacing them with "\n\n" before the strip_tags is called.

$output = str_replace("</p>\n<p>", "\n\n", $output, $count);
$output = trim(PlainTextOutput::renderFromHtml($output));

I doubt that's the best way to do it, but it's working so I thought I'd add it to the discussion.

Works for me too. Setting to RTBC.

New version. First one didn't work right.

Done, I think. Let me know if anything is wrong. First time doing it this way.

Actually I think "gets" could be changed to "is" to save a couple of characters. I'm probably going to make that change and a few others on my site, but I'll save them for another issue, because they may not suit everybody.

rclemings → created an issue.

All it took in my case (Drupal 10.1.7 => 10.2.1 via composer) was a cache rebuild (drush cr since the site was down).

Am I missing something or does this NOT migrate subscriptions?

I'm able to migrate newsletters, issues, and subscribers, but not the corresponding subscriptions. All of the boxes on /admin/people/simplenews/edit/NNN are unchecked.

Probably not related, but I did have to apply this RTBC core patch to get it to work, possibly because of some orphaned newsletter tids in the source:

https://www.drupal.org/project/drupal/issues/3365895 🐛 When sub_process encounters a row skip, it should skip its internal row, and not bubble up to the outer row RTBC

I've migrated one site from this module to Wysiwyg/CKEditor4 and it works (at least for now) except for a few gotchas:

1. There are some classes in css/ckeditor.css that won't (naturally) be available in Wysiwyg. We noticed this when some centered type was suddenly flush-left because the browser couldn't find the "rtecenter" class. The fix was to copy those classes to the css in our custom theme.

2. On the "cleanup and output" tab of each Wysiwyg profile, there's a box labelled "Apply simple source formatting." If that box is not checked, then all of the line breaks are removed from the source code view (using the "Disable rich-text" link), making it hard to read.

3. We had to remove the filter "Convert line breaks into HTML (i.e.
and

)" from the text formats that use Wyswiyg/CKEditor. Otherwise, line breaks in the text are doubled when the node is displayed ("

" instead of "
").

That's it so far, except that CKEditor4 is still EOL.

rclemings → created an issue.

Wysiwyg still seems to work with CKeditor 4, for now.

Thanks. The downgrade appears to have worked, although composer put up a bit of a fight so I had to downgrade pf_email 2.3.0 => 2.1.2.

rclemings → created an issue.

Changing version tag to reflect newest Drupal 9/10 beta.

Patch.

rclemings → created an issue.

Another vote for #15. That makes seven so I'll set it to RTBC.

rclemings → created an issue.

Ignore previous. It was missing a new file.

This updates the #2 patch to fix a couple of significant bugs. Making this change configurable remains on my list, but I wanted to post this in case anyone wants to go ahead and use this patch as is.

I've just installed this on Drupal 10.1.5 with the patch from #7 and everything seems to be working fine. Since Drupal 9 has been EOL for more than a month now, it would be nice to get this committed, so I will set it to RTBC.

Here's another duplicate that I filed and closed after discovering this was the cause. The patch in #31 worked.

https://www.drupal.org/project/eca_vbo/issues/3354722 🐛 Error in EcaVboBulkForm Closed: duplicate

Looks as if the issue is in contact_storage and there's an RTBC patch: https://www.drupal.org/project/contact_storage/issues/3191567#comment-14... 🐛 Notice: Undefined index: entity:delete_action:contact_message in contact_storage_action_info_alter() RTBC

This wasn't easy to figure out. I ended up dumping all of the defs using this snippet adapted from https://www.drupal.org/project/views_bulk_operations/issues/3171938: →

$am = \Drupal::service('plugin.manager.views_bulk_operations_action');
$defs = $am->getDefinitions([
  'skip_actions_permissions' => TRUE,
  'nocache' => TRUE,
]);
dump($defs);

With that I saw, at the bottom of a long list:

  "entity:unpublish_action:paragraph" => array:9 [▶]
  "message_delete_action" => null

Well, now, there's our null.

Dr. Google then led me to https://www.drupal.org/project/contact_storage/issues/3306684 → and https://www.drupal.org/project/contact_storage/issues/3191567 🐛 Notice: Undefined index: entity:delete_action:contact_message in contact_storage_action_info_alter() RTBC and all is now well.

Bumping ...

Drupal 9 has been EOL for three weeks now and as #25 notes, composer complains if you try to require the current version.

Could we get a new release ASAP?

TIA

I was able to get it updated to v3 successfully by following EXACTLY the steps listed here:

https://www.drupal.org/project/commerce_license/releases/8.x-2.0 →

It's complicated. It took more than one try, But it worked. The updb step is critical.

Maybe the same steps should be listed on https://www.drupal.org/project/commerce_license/releases/3.0.0 → as well, just so nobody misses it?

I found a similar error when importing errors. Patch attached. I suppose I could open a new issue but this one seems to be languishing so I'll just add it here for the benefit of future googlers.

Most of the above seems to be for v8.x-1.x. In case it helps anybody else, here's how I was able to change the group type for a simple group (no entity references, etc.) in v2.2.1:

1. Create the new group type if it does not already exist.
2. Install the appropriate content plugin/s ("set available content" from dropdown on /admin/group/types).
3. Add/edit group roles ("edit group roles" dropdown) as needed.
4. Set permission ("edit permissions" dropdown) as needed.
5. In database, in the "groups" and "groups_field_data" tables, change "type" field to new type for the relevant group/s.
6. Cross fingers, rebuild cache.

Here's a patch for the merge request mentioned by @steven-jones in #33. It strikes me as the better approach given the comments by @TR in #6. I'll mark it as needs review to get the testbot involved.