@dgwolf

dgwolf → created an issue.

D 10.3.10, PHP 8.3.12, 11.4.3-MariaDB - error triggered in admin/commerce/invoices/. I've manually created a credit invoice in a shop that has only a manual payment gateway, and upon clicking "pay credit" or some such (in the German view of the completed credits invoice) I get the error below. When I reload the page the error messages are gone, the view of the credit invoice displays properly, and the invoice name has changed from pending to paid, as expected. Caching is afflicted as well: When I go back in the browser to the action menu and try to download the paid invoice, the previous one from another customer is retrieved. The message:

The website encountered an unexpected error. Please try again later. [this line in German, then continues like so:]

Error: Call to a member function hasTranslation() on null in Drupal\file\Plugin\Field\FieldType\FileFieldItemList->postSave() (line 54 of core/modules/file/src/Plugin/Field/FieldType/FileFieldItemList.php).

call_user_func_array(Array, Array) (Line: 938)
Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldMethod('postSave', Object, 1) (Line: 984)
Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldPostSave(Object, 1) (Line: 896)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 56)
Drupal\commerce\CommerceContentEntityStorage->invokeHook('update', Object) (Line: 25)
Drupal\commerce_invoice\InvoiceStorage->invokeHook('update', Object) (Line: 564)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 781)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 489)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 178)
Drupal\state_machine\Form\StateTransitionForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('state_machine_transition_form_commerce_invoice_state_284', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 128)
Drupal\state_machine\Plugin\Field\FieldFormatter\StateTransitionFormFormatter->viewElements(Object, 'de') (Line: 91)
Drupal\Core\Field\FormatterBase->view(Object, 'de') (Line: 268)
Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple(Array) (Line: 340)
Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'admin') (Line: 282)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 239)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func_array(Array, Array) (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725 → ', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 870)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 432)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 263)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 130)
Drupal\shield\ShieldMiddleware->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Surely an additional field for a configurable default email address would make sense to which a copy of the mail to the recipient group gets sent for later reference and archiving, ideally with the group's status and "Sent" date in the title added at the time when the mail was sent, perhaps in brackets, and an attached list of the recipients.

This actually was an error message encountered when entering a payment manually. Reloading the page led to the invoice being marked as paid, but in ithis case the "paid" invoice was not created at all, and the "pending" invocice was gone:

Error: Call to a member function hasTranslation() on null in Drupal\file\Plugin\Field\FieldType\FileFieldItemList->postSave() (line 54 of core/modules/file/src/Plugin/Field/FieldType/FileFieldItemList.php).

call_user_func_array(Array, Array) (Line: 938)
Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldMethod('postSave', Object, 1) (Line: 984)
Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldPostSave(Object, 1) (Line: 896)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 56)
Drupal\commerce\CommerceContentEntityStorage->invokeHook('update', Object) (Line: 25)
Drupal\commerce_invoice\InvoiceStorage->invokeHook('update', Object) (Line: 564)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 781)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 489)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 72)
Drupal\commerce_invoice\Form\InvoicePaymentForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('commerce_invoice_payment_form', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 263)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 130)
Drupal\shield\ShieldMiddleware->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Sorry for the late reply, had too many other tasks. Manual orders seemed to work after a complete reinstall of the invoice module and the patches. However, creating manual payments leads to lost invoices that are listed with the orders under the orders tab but the linked file is sometimes missing. Invoices seem to get recreated as "paid" when the payment is entered manually, but not when a rebate is entered under credits and a new invoice with the old total minus the new rebate listed as credit is sent, and not all pathways to manually entered payments seem to trigger the creation of a paid invoice. I am sort of giving up right now. As the main function of invoice creation upon placing an order works I may have to live with the rest.
When I have a bit more time again I would like to track and debug the invoice creation. Is there a workflow map online somewhere, I am not a programmer but would like to wrap my head around the process flow for creation and storing invoices with the commerce invoice module. And is it possible to let the database look for lost invoices and relink them, if they still exist?

@netzkombuese - I found the time for some more testing on D 10.3.6 with PHP 8.3.11, Symfony Mailer 1.5.0, Commerce 8.x-2.40 and Commerce Invoice 8.x-2.0-rc5 and your patch #22 (which was working well on I think 10.3.4). When I place an order (manual payments only) the invoice pdf is being created (with a patched entity_print for proper CSS rendering), but the pdf doesn't get sent with the outgoing mail. The order confirmation and the mail that should have the invoice attached are being sent alright. The log of the Drupal php container says:

php-drupal | NOTICE: PHP message: Uncaught PHP Exception TypeError: "call_user_func(): Argument #1 ($callback) must be a valid callback, class Drupal\commerce_invoice\EventSubscriber\InvoiceConfirmationSubscriber does not have a method "sendInvoiceConfirmation"" at /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php line 111
php-drupal | NOTICE: PHP message: Error: Call to undefined method Drupal\commerce_invoice\EventSubscriber\InvoiceConfirmationSubscriber::destruct() in /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php on line 723 #0 /var/www/html/web/index.php(22): Drupal\Core\DrupalKernel->terminate()

I'd be very glad if this could be fixed. Regards, dgwolf

Hello netzkombuese, thanks for asking. It is about manually created orders with manual payments as the only payment source. I can place an order, the pending invoice is being created and sent. For this I needed to apply the EntityPrint hotfix patch from here: https://www.drupal.org/project/entity_print/issues/3394857 🐛 After clearing caches, the aggregated CSS is not loading properly, which disrupts the layout of the first PDF. Needs work although another issue with CSS was declared resolved but I still had to use the patch. Now when I add a payment it is being received, the open amount is settled and the refund button shows. The mail is being triggered and a "paid" invoice should be attached. It does not happen though and this time I see a PDF has not even been created. When I go to the invoices tab and try to download it the pending invoice can be seen in HTML is gone and instead of a paid invoice I only see "file not found".

A bit later: Maybe this is now an EntityPrint issue - no invoice is being generated for new orders either although the confirmation mail and the invoice mail are being sent - but wait, three days ago an order was placed and the attached pending invoice arrived at the shop's CC mail address but checking now I see no PDF was saved on the site. I did upgrade to 10.3.6 in the meantime with a few dependencies pulled but this can't be the reason, can it? I'm at a loss how to continue now. Now not even an attached invoice went out (on my testing site with mailhog running).

Latest D10.3 and a low traffic Commerce shop, manual payments only. The patch from #22 fixed the problem for me
.
However, now I found out that upon entering manually a received payment a new invoice with „paid“ in the file name is indeed being generated but not sent. Above it sounded as if this was only tested or fixed and working for PayPal payments. If this holds true for others as well, may I kindly ask fo a fix also for manual payments (or is it a different problem as the patch should cover this use case as well)?

Thanks, but no. Then did drush un taxonomy_manager, composer remove, reinstalled, same result.

Same here. Had uninstalled TM when it didn't work any more, reinstalled today on D 10.3.5 together with fancytree/fancytree - but it doesn't show any terms in any of my 10 or 15 existing groups, instead I see this error message (although it poses just as a warning):

Warning: file_get_contents(libraries/jquery.fancytree/dist/jquery.fancytree.min.js): Failed to open stream: No such file or directory in _locale_parse_js_file() (line 1097 of core/modules/locale/locale.module).

_locale_parse_js_file('libraries/jquery.fancytree/dist/jquery.fancytree.min.js') (Line: 529)
locale_js_translate(Array, Object) (Line: 485)
locale_js_alter(Array, Object, Object) (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter('js', Array, Object, Object) (Line: 313)
Drupal\Core\Asset\AssetResolver->getJsAssets(Object, , Object) (Line: 330)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object, Array) (Line: 167)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 97)
Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object)
call_user_func(Array, Object, 'kernel.response', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.response') (Line: 214)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 202)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 263)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 219)
Drupal\shield\ShieldMiddleware->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Bingo! Thanks for the hotfix in #5 which brought back the CSS coded tables for my Commerce Invoice invoices from modules/contrib/commerce_invoice/css/commerce_invoice.entityprint.css. For lack of coding knowledge I cannot help fixing the bug but maybe my setup details can help:

From the saved invoice PDFs I can clearly state that our low frequency web shop lost its invoice CSS some time in fall or winter 2023/2024. The redirect module is active, but I seemed not to have had a problem with it, and neither redirect nor entity_print seem to have had an upgrade in the time window mentioned. Perhaps something broke when I upgraded from D10.1 to 10.2 which may have taken place back then.

The invoices were legible though, I didn't notice the difference, the customers didn't complain, so I was unaware of the loss until two days ago. Currently I am on D10.3.5, with up to date entity_print 8.x-2.15 and redirect 8.x-1.10. I'll be happy to help pinpointing stuff in my setup if needed. What I can also say is that timing in relation to having cleared caches doesn't make any difference here.

On a local dev system with D10.2.7, PHP 8.3.9 and

admin_toolbar
admin_toolbar_links_access_filter
admin_toolbar_search
admin_toolbar_tools
admin_toolbar_content

enabled the WSOD appeared after upgrading only admin_toolbar from 3.4.2 to 3.5.0 and nothing else. Patch M!95 restored the functionality. Thanks @DYdave.

Sorry, thank you!

Similar problem here:
- A batch upgrade from D10.2.7 to 10.3.2 brought the WSOD. A selective upgrade on 10.3.1 with PHP 8.3.9 made possible to pinpoint 'admin_toolbar' as the primary culprit, in combination with the 'admin_toolbar_tools'.
Upgrading 'admin_toolbar_tools' (3.4.2 => 3.5.0) first while keeping 'admin_toolbar' at 3.4.2 went well. Then upgrading 'admin_toolbar' (3.4.2 => 3.5.0) as well yielded the trace below:

TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given in method_exists() (line 68 of modules/contrib/admin_toolbar/admin_toolbar_tools/src/Plugin/Menu/MenuLinkEntity.php).

Drupal\admin_toolbar_tools\Plugin\Menu\MenuLinkEntity->getDescription() (Line: 124)
Drupal\Core\Menu\MenuLinkBase->getUrlObject() (Line: 215)
Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->menuLinkCheckAccess() (Line: 107)
Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->checkAccess() (Line: 111)
Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->checkAccess() (Line: 111)
Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->checkAccess()
call_user_func() (Line: 153)
Drupal\Core\Menu\MenuLinkTree->transform() (Line: 124)
Drupal\toolbar\Controller\ToolbarController::preRenderGetRenderedSubtrees()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 870)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 283)
{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 282)
toolbar_get_rendered_subtrees() (Line: 295)
_toolbar_get_subtrees_hash() (Line: 168)
toolbar_toolbar()
call_user_func_array() (Line: 416)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 395)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 415)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 78)
Drupal\toolbar\Element\Toolbar::preRenderToolbar()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 870)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 83)
__TwigTemplate_d68a68533d331dfee346749b4e3826a0->doDisplay() (Line: 360)
Twig\Template->yield() (Line: 335)
Twig\Template->render() (Line: 38)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 186)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 263)
Drupal\shield\ShieldMiddleware->bypass() (Line: 219)
Drupal\shield\ShieldMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)s
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Sorry for the noise. My recent composer.json backups reminded me of an install of the project "drupal/trash" which I decided not to keep installed. I had just "drush-uninstalled" but not "composer-removed" it. Therefore the fields' names had rightly so a label "deleted" in them, which was misleading for me. Properly re- and de-installing the module removed the error message from the status page.

Thanks from me as well. Two customers' registrations were afflicted. I had to delete manually two dangling registrations that blocked new attempts to register because the particular event can only be booked once by the registrant.

A question remains: As I rarely check the site's status report, administrating almost everything with composer and drush, I saw only today an error stating there were "Mismatched entity and/or field definitions" in 7 entities: Order, Product, Product Variation, Actions, Coupon, Shop, and Content, stating that one field in each of them, these 7 fields all uniformly named "deleted" ("gelöscht" in German), needed to be deleted. I searched the web and found this command with the result below:

MariaDB [mydatabase]> select * from key_value where name = "field.field.deleted" or name = "field.storage.deleted" ;
+------------+-----------------------+--------+
| collection | name                  | value  |
+------------+-----------------------+--------+
| state      | field.field.deleted   | a:0:{} |
| state      | field.storage.deleted | a:0:{} |
+------------+-----------------------+--------+
2 rows in set (0.006 sec)

And two more commands from another site about mismatched definitions yielded this:

MariaDB [mydatabase]> SELECT * FROM `field_config` WHERE `deleted` = 1 ;
ERROR 1146 (42S02): Table 'mydatabase.field_config' doesn't exist
MariaDB [mydatabase]> SELECT * FROM `field_config_instance` WHERE `deleted` = 1 ;
ERROR 1146 (42S02): Table 'mydatabase.field_config_instance' doesn't exist

I am not versed in SQL and wouldn't know how to proceed, but could it be that cruft from the two failed orders with manually deleted dangling carts be the cause of the error? And how can this possibly be fixed?

I wouldn't even know how far to roll back the DB because the errors could have appeared weeks ago, most probably at some point during the D10.2 period, besides new registrations have come in that would get lost in a rollback. I am sure I always performed database upgrades when required; drush updbst was always clean afterwards. Upgrading my testing instance from 10.2.7 to 10.3.1 didn't change the error. I also couldn't say whether it was present before the most recent commerce update of some weeks ago, and I didn't find a similar report in the Commerce Core issues.

dgwolf → created an issue.

Seconded. I'd have use for sending messages to those on the waitlist.

Hello John, thanks again for your kind and reliable help. I followed your suggestions and could change the states now, just as needed.
Then I wanted to register person D who filled the cancellation gap in the past event, but interestingly now the EUR currency of the seminar fee for which I was trying to register her (i. e., the product price) is not being picked up when I click "Check Basket". Is this related to the non-standard workflow of registering person D through Commerce Registration for an event as an admin, or would I report this as a Commerce Core bug?

Drupal\Core\Entity\EntityStorageException: Could not load the "USD" currency. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\commerce_order\Entity\OrderItem->recalculateTotalPrice() (Line: 135)
Drupal\commerce_order\Entity\OrderItem->setUnitPrice() (Line: 185)
Drupal\commerce_order\OrderRefresh->refresh() (Line: 123)
Drupal\commerce_order\OrderStorage->doOrderPreSave() (Line: 86)
Drupal\commerce_order\OrderStorage->invokeHook() (Line: 529)
Drupal\Core\Entity\EntityStorageBase->doPreSave() (Line: 753)
Drupal\Core\Entity\ContentEntityStorageBase->doPreSave() (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save() (Line: 806)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (Line: 169)
Drupal\commerce_order\OrderStorage->save() (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 463)
Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowBase->submitForm() (Line: 614)
Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowWithPanesBase->submitForm()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 224)
Drupal\Core\Form\FormBuilder->getForm() (Line: 143)
Drupal\commerce_checkout\Controller\CheckoutController->formPage()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
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: 58)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 270)
Drupal\shield\ShieldMiddleware->bypass() (Line: 137)
Drupal\shield\ShieldMiddleware->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: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Thanks for the reply and sorry for the noise. My update yesterday had pulled in all 2.38 versions except core that was stuck on 2.36 because of the unsatisfied address 2.0 plus a related dependency. Seems with the resolution the message is gone now.

Hi John, now I have reverted the DB to 9 Feb before the last updates and, following your instructions, am trying to re-add registrations lost through the DB rollback. Strangely the DB was consistent on 9 Feb and performing the updates no DB update was required at any time although the pending updates had shown up with # drush updbst only two or three weeks after your 10 Feb update IIRC. Anyway, the admin/commerce/registrations summary is no longer white, and WL can be switched on and off as intended, this is a success.
I did enable the admin overrides but there is now one registration (I'll call her person C) that was on the waiting list on 9 Feb and of which I now, after the event, can't manually change the status - only one option, i.e. waiting list, is available. I also raised the capacity so that there is now a space for the person C, enabled auto-fill but this doesn't work either (although it did when the DB was not reverted yet and registrations were still open). Furthermore, while auto-fill may be a good thing for some events, my use case would rather need the "manual fill" option. We had a cancellation for a recent event, person A, and only a new registrant, person D, who had left her phone number, could be reached and in the end she was the one who was able and willing to attend. Immediately opening a space could theoretically have sucked person C into the open space, or even person B from the WL whom I reached and who stepped back. I canceled the two registrations of persons A (Open) and B (WL) and only then asked person D to register which didn't work properly (customer not saved as registrant, no confirmation mail) due to the now apparent recent DB problem.
This raises for me the question: Are manual changes of the registration state possible? Depending on whether a manual payment (bank transfer) has already being made or not this would mean a change to either Open or to Completed state. Maybe I misunderstood the overrides, or are registrations after an event so far only possible on the Commerce order and not on the registration level? The latter would be a big help for managing registrants on the WL.
Regards, Andreas

Not sure it belongs here but here goes: D10.2.4, PHP8.3, perhaps this is already taken care of in the commit? My error message goes like this:

Deprecated function: Calling get_class() without arguments is deprecated in Drupal\commerce\Plugin\Commerce\InlineForm\InlineFormBase::attachElementSubmit() (line 44 of modules/contrib/commerce/src/Element/CommerceElementTrait.php)
Drupal\commerce\Plugin\Commerce\InlineForm\InlineFormBase::attachElementSubmit(Array, Object, Array)
call_user_func_array(Array, Array) (Line: 1013)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_product_my_product_name_is_here_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_product_my_product_name_is_here_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_product_my_product_name_is_here_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_product_my_product_name_is_here_edit_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('commerce_product_my_product_name_is_here_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
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: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 270)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 137)
Drupal\shield\ShieldMiddleware->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

"It works!" - problem solved. Thank vor very much for your quick help!

dgwolf → created an issue.

dgwolf → created an issue.

The issue persists on D10.2.4 with MariaDB and PHP 8.3 although I was able to install, enable, uninstall, and remove the contact_storage module with Patch #23 from elsewhere (mentioned above). Could somebody please be so kind and provide here for a non-database specialist like me the/a possible sql command(s) for deleting the leftovers that still trigger the error message and block the database configuration?

Thank you very much, Chris, for your quick reaction with a perfect fix that installed withou a glitch, working as intended on D10.2.3 with PHP 8.3. Best regards, Andreas

Dear maintainer, may I ask you humbly to please fix the address 2.0 compatibility issue soon. Uninstalling your module before upgrading Commerce with its requirement of Address 2.0 did not work out cleanly due to the outdated requirements for Address, and for me it has been impossible to remove the address_map_link module completely with the half baked Commerce and Address upgrade that I performed. I was confident that your fix would follow suit with the address 2.0 upgrade but have meanwhile spent a couple hours already trying to fix things. Rolling back everything also failed (my bad, I know), and now the database and Extensions files again report errors related to the missing address_map_link module. Deleting references in the DB only helped partially, and I am sure your upgrade would be the best solution, especially as I like the modules functionality and would like to rely on it again. Your help with this would be highly appreciated. Thank you!

"It works". Thank you, @viren18febS!

dgwolf → created an issue.

Hello longwave,
thanks for your swift help. The culprit are lines from the beta contrib module "Allow existing users to register without errors" that I had installed weeks ago and forgotten about as there no new registrations happened since ( https://www.drupal.org/project/created_account_register_message → ). Deactivating it solved the issue. I'll report there, and your question taught me how to better pinpoint a new issue next time. Best regards, Andreas

dgwolf → created an issue.

Same here on 10.1.6 with PHP 8.1.26. I don't have the Contact Storage module installed any more but keep getting the error message. I was wondering whether the missing key could be the reason why "init_commands' => [ 'isolation_level ..." from settings.php doesn't work and READ COMMITTED can only be set manually - whereupon the error appears in admin/reports/status#error.

thanks for looking into this- I‘ll report back in the next few days. Best, Andreas

dgwolf → created an issue.

Sounds good, and thanks for the background information in #5.

Thanks for encouraging me to try the patch. It works, the page loads without a glitch. +1 for the MR!

Thanks, but are you sure? I abstained because of the warning on the devel_entity_updates module's page:
"Do not use this to fix the Mismatched entity and/or field definitions error: again, this is not meant to fix production sites."
"If you encounter that error you should identify which module defines the problematic entity type or field definition and open a bug report or support request in its issue queue."
Seems there is a newish module though called entity_update but it may not have the function that is needed here.

Had issues with my upgrade from D 9.5.11 to 10.1.14 but after a clean replay of the upgrade the problem persists. Using the module makes the page using it crash with said error messages. Unchecking "Enabled Date Augmenters" - "Content" in the display section of the page's Smart Date field disables the module and the page loads properly.

Thank you.

Thank you very much for your time and replies, cilefen!

I rolled back the upgrade and realized when repeating it that I accidentally had upgraded the Dynamic Entity Reference module from 8.x-1.16 to version to 3.1.0 instead of 4.0.0-alpha3 as suggested by the upgrade checker (seems my eyes had registered some version 3 one line above for one of the two other modules I had to take care of). I had managed to work around the ensuing composer messages, but this may have done more harm than anything.

Other than that the site seemed upgrade ready alright but ... the crashes occurred again upon saving a simple test page of the type Article and stopped after deactivating Admin Toolbar Content 1.3.12 that was, not rightfully so, it seems, flagged as _compatible_ in the upgrade status list. However, upgrading to the also recommended version 2.0.2 fixed this too.

It seems the site is OK now except for the error "Transaction isolation level READ-COMMITTED [...] The following table(s) do not have a primary key: contact_message. - May I ask, how do I find out to which module, core or contrib, the table contact_message belongs?

Best, Andreas

Same here on D 10.1.4 with PHP 8.1. After upgrading from SmartDate 3.7.2 to 4.1.0-rc2 two of my standard SmartDate fields were reported as being in need of such updates. There were no recurring dates involved but a simple "node.field_when" on a testpage and a similar field "commerce_product_variation.field_zeiten" in a set of commerce products. Downgrading to 4.0.3 resolved the issue. - Regards, Andreas

dgwolf → created an issue.

Seems the issue comes up here as well after upgrading to D10. Any news about the patch? Best, Andreas

Here's my error message on a newly updated Drupal install (9.5.11 -> 10.1.4) when trying to view an event as product in commerce:

Drupal\Core\Entity\Query\QueryException: Entity queries must explicitly set whether the query should be access checked or not. See Drupal\Core\Entity\Query\QueryInterface::accessCheck(). in Drupal\Core\Entity\Query\Sql\Query->prepare() (line 141 of core/lib/Drupal/Core/Entity/Query/Sql/Query.php).

Drupal\Core\Entity\Query\Sql\Query->execute() (Line: 86)
Drupal\date_content\Plugin\DateAugmenter\Content->augmentOutput() (Line: 835)
Drupal\smart_date\Plugin\Field\FieldFormatter\SmartDateDefaultFormatter->augmentOutput() (Line: 155)
Drupal\smart_date\Plugin\Field\FieldFormatter\SmartDateDefaultFormatter->viewElements() (Line: 89)
Drupal\Core\Field\FormatterBase->view() (Line: 265)
Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple() (Line: 268)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple() (Line: 339)
Drupal\Core\Entity\EntityViewBuilder->buildComponents() (Line: 281)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple() (Line: 238)
Drupal\Core\Entity\EntityViewBuilder->build()
call_user_func() (Line: 37)
Drupal\commerce_product\ProductVariationFieldRenderer->renderFields() (Line: 60)
Drupal\commerce_product\ProductVariationFieldRendererLayoutBuilder->renderFields() (Line: 96)
Drupal\commerce_product\ProductViewBuilder->alterBuild() (Line: 291)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple() (Line: 238)
Drupal\Core\Entity\EntityViewBuilder->build()
call_user_func_array() (Line: 111)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 797)
Drupal\Core\Render\Renderer->doCallback() (Line: 386)
Drupal\Core\Render\Renderer->doRender() (Line: 204)
Drupal\Core\Render\Renderer->render() (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 239)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare() (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 187)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch() (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup() (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 270)
Drupal\shield\ShieldMiddleware->bypass() (Line: 226)
Drupal\shield\ShieldMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

dgwolf → created an issue.

Hi, Lighthouse complains that links are not crawlable in our new site on D9.5.7 that doesn't show up in Google search so far. It specifies
"Uncrawlable Link", and

  div#main-wrapper > div#main > div.main-content > a#main-content
<a id="main-content" tabindex="-1">

I am a bit lost as to which patches have been applied in 9.5.7, if any, and what workaround could currently actually be applied with the least damage resulting elsewhere. Or is an upgrade to D10 the best solution?

Dear maintainers, I also stumbled over the issue on a new D9.5.4 install with PHP 8.1.16 and after some frustrating trials I finally found this thread. The functionality would be great to have, but CKE5 does not pick up the icon, so I cannot use the modules Entity embed and URL embed. Can't be such a big deal to make the project really D9/D10 compatible, or is it? Installing CKE4 just for the sake of the embed functionality is no option for me. The fix would be greatly appreciated. Regards

dgwolf → created an issue.

Wow, this was fast! Thank you very much!
Greetings from Austria to Australia

Glad to read you are making this very helpful module D10 compatible, thanks a lot. Any idea when you will be able to release it?

Got one step further: When I drill down from the commerce products menu item to a single product variation, this variation does have a register tab beside the manage registrations tab. That register tab works but I have to choose from the dropdown menu for whom I am registering. This step seems not to be happening or be dealt with when checking out through the cart. Therefore the aforementioned way of registering has nothing to do with commerce's payment module and the checkout workflow. Did I miss a configuration step?

dgwolf → created an issue.

Same here, D 9.5.2, Php 8.1.14, latest beta module in a wodby docker setup with Drupal managed by composer. Maybe unrelated - the unpaid test orders (manual payment) can be seen in the orders view of commerce as complete (although pending in the payments subtab) but never arrive in the prod. variations‘ registration tabs despite using custom event order item and order types. Promoting the payment status to complete doesn‘t move the reg. into their slot, which may be intended, however? Regards, dgwolf

Thanks, mandclu, for the time and sorry for squeezing the format issue into the value-custom issue report. Your example …value-custom:Y expression nevertheless gets rejected by pathauto. Maybe a that is a limitation of pathauto. Will leave it at that for now.
I also repeated creating a custom format in the SD settings, this time no spurious y value appeared, 230125 is the intended output now.

dgwolf → created an issue.

I am now on D9.5.2 with PHP 8.1.14 and Smart Date RC1. Smart Date now functions as intended. Whatever update(s) may have helped, those of Smart Date, and/or PHP, and/or Drupal Core, they fixed the issue for me.

Thanks for looking into that. I am now on D9.5.2 with PHP 8.1.14 and Smart Date RC1. Smart Date now functions as intended and even without the IntlDate module. I assume the processing of the locale now works, whatever update(s) may have helped, those of Smart Date, and/or PHP, and/or Drupal Core. So I guess my report did actually not even concern your project, in which case I apologize for the noise.

PS Actually, I'm on wodby's PHP 8.1.14 meanwhile with D 9.5.2. Thank you!

With your release of RC1 the problem went away for good. Subsequent updates of D9.5 also solved also the internationalization issue (reported there). Sorry for the late reply, and greetings from a happy user.