🇩🇪Germany @Rudi Teschner

I noticed that once i change the display of the field in the node form display from "workflow transition form" to "checkboxes/radio buttons" I was able to save nodes again, maybe that helps narrowing it down

@johnv: Adding the 4 latest commits ( 54c2865f, 8a007858, 4e816b23, e015b366 ) to the current project I work on causes errors so I'll just add em here for you to check whether they have any value for your work.

Warning: Undefined array key "original_deltas" in Drupal\Core\Field\WidgetBase->flagErrors() (line 573 of /var/www/html/docroot/core/lib/Drupal/Core/Field/WidgetBase.php).:

Warning: Trying to access array offset on null in Drupal\Core\Field\WidgetBase->flagErrors() (line 573 of /var/www/html/docroot/core/lib/Drupal/Core/Field/WidgetBase.php).:

Warning: Undefined array key "" in Drupal\Core\Field\WidgetBase->flagErrors() (line 574 of /var/www/html/docroot/core/lib/Drupal/Core/Field/WidgetBase.php).:

TypeError: Drupal\Core\Field\WidgetBase::errorElement(): Argument #1 ($element) must be of type array, null given, called in /var/www/html/docroot/core/lib/Drupal/Core/Field/WidgetBase.php on line 577 in Drupal\Core\Field\WidgetBase->errorElement() (line 643 of core/lib/Drupal/Core/Field/WidgetBase.php).

@johnv: I still get the validation error ("This value should not be null.") when i update workflow to latest dev version (#3caa0ec) in my existing project - for new content as well as when editing/saving existing content if that helps.

@smethawee
In my composer.patches.json its not drupal/tests but drupal/core since composer would not know that it has to patch core otherwise, does it?

    "drupal/core":{
      "3505049 - Drupal 11.1.2 upgrade causes \\Drupal::$container is not initialized yet error": "https://git.drupalcode.org/project/drupal/-/merge_requests/11169.patch",
    },

Aside from that I fear I do not have any other useful suggestion

@smethawee I've added the patch to drupal/core in my project's composer.patches.json file
"3505049 - Drupal 11.1.2 upgrade causes \\Drupal::$container is not initialized yet error": "https://git.drupalcode.org/project/drupal/-/merge_requests/11169.patch"

and triggered drush cr afterwards. Result might be coincidence though since I didn't verify against a clean build.

The maintainers of the workflow module adressed this issue https://www.drupal.org/project/workflow/issues/3497950 🐛 \Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container. Active by changing the calls to loadInclude to require_once

- \Drupal::moduleHandler()->loadInclude('workflow', 'php', 'workflow.api');
+ require_once __DIR__ . '/../../workflow.api.php';

for protocol the problem with the container seems to be solved in core in the issue https://www.drupal.org/project/drupal/issues/3505049 💬 Drupal 11.2 upgrade causes \Drupal::$container is not initialized yet error Active

I've had the same problem happening during drush updb that resulted in custom modules with functional split up files to throw the error when loading files via Drupal::moduleHandler()->loadInclude().

https://git.drupalcode.org/project/drupal/-/merge_requests/11169.patch fixed it for me so that I don't get an error while using drush updb anymore.

This issue still seems to be a problem, we get the message after upgrading to 1.8 or latest dev too in our project too. If me or my colleague have time we will try to dip into this issue in the next days.

First guess is that it could be related to https://www.drupal.org/project/workflow/issues/2926094 🐛 WorkflowTransitionElement is called twice on a form Fixed and commit https://git.drupalcode.org/project/workflow/-/commit/ad73361bec3d8fc6ce8... but we will see.

Works perfect

I'm currently getting my project ready for D11 update and this still is an issue in latest dev

Warning: Trying to access array offset on value of type int in Drupal\workflow\Element\WorkflowTransitionElement::copyFormValuesToTransition() (Zeile 363 in /var/www/html/docroot/modules/contrib/workflow/src/Element/WorkflowTransitionElement.php).

Warning: Trying to access array offset on value of type int in Drupal\workflow\Element\WorkflowTransitionTimestamp::valueCallback() (Zeile 52 in /var/www/html/docroot/modules/contrib/workflow/src/Element/WorkflowTransitionTimestamp.php).

rudi teschner → created an issue.

rudi teschner → created an issue.

rudi teschner → created an issue.

Patch application fails against 3.0.0

Issue can be closed since its already handled in code via adding \Drupal\Component\Utility\DeprecationHelper::backwardsCompatibleCall but the upgrade status check does not recognize this (yet?)

rudi teschner → created an issue.

rudi teschner → created an issue.

rudi teschner → created an issue. See original summary → .

rudi teschner → created an issue.

Missed one occurrence of spaceless in submodule that was pointed out as warning in upgrade status module.

File: modules/contrib/flag/modules/flag_count/templates/flag-count.html.twig
Line: 14
Warning: Since twig/twig 3.12: Twig Filter "spaceless" is deprecated. See https://drupal.org/node/3071078.

File: modules/contrib/flag/templates/flag.html.twig
Line: 17
Warning: Since twig/twig 3.12: Twig Filter "spaceless" is deprecated. See https://drupal.org/node/3071078.

I've added the changes in State.php to a system that had the messages appear every 5 minutes in watchdog - and the messages don't appear anymore

rudi teschner → created an issue.

Thanks for the fast reply. No, I don't have any patches for the feeds module applied.

I checked a different test system and there I actually get the error you mention (Error: Call to a member function addMessage() on null in Drupal\feeds\State->displayMessages()) during the cron runs. So it seems to actually be two different errors depending on whether the feed page is accessed or the cron jobs are executed.

What I wondered though ... the messenger is addressed different ways in the feed module. No clue if that has to do something at all though.

/src/Controller/CustomSourceListController.php:130: $this->messenger()->addError($e->getMessage());
./src/FeedTypeForm.php:355: $this->messenger()->addStatus($this->t('Your changes have been saved.'));
./src/Feeds/Processor/EntityProcessorBase.php:1292: $this->messenger()->addWarning($this->t('When mapping to the entity ID (@name), it is recommended to set it as unique.', [
./src/FeedForm.php:225: $this->messenger()->addMessage($this->t('%title has been created.', $t_args));
./src/FeedForm.php:229: $this->messenger()->addMessage($this->t('%title has been updated.', $t_args));
./src/FeedForm.php:235: $this->messenger()->addError($this->t('The feed could not be saved.'));
./src/Form/CustomSourceEditForm.php:137: $this->messenger()->addStatus($this->t('The source %label has been updated on the feed type %feed_type.', [
./src/Form/MappingForm.php:161: $this->messenger()->addWarning($this->t('Your changes will not be saved until you click the Save button at the bottom of the page.'));
./src/Form/MappingForm.php:392: $this->messenger()->addWarning($e->getMessage());
./src/Form/MappingForm.php:1076: !empty($message) ? $this->messenger()->addWarning(Markup::create(implode('
', $message))) : TRUE;
./src/Form/DeleteMultipleForm.php:53: $this->messenger()->addMessage($this->formatPlural($count, 'Deleted 1 feed.', 'Deleted @count feeds.'));
./src/Form/FeedUnlockForm.php:45: $this->messenger()->addMessage($this->t('%title has been unlocked.', $args));
./src/Form/FeedDeleteForm.php:73: $this->messenger()->addMessage($this->t('%title has been deleted.', $args));
./src/Form/ClearMultipleForm.php:52: $this->messenger()->addMessage($this->formatPlural($count, 'Deleted items of 1 feed.', 'Deleted items of @count feeds.'));
./src/Form/ImportMultipleForm.php:52: $this->messenger()->addMessage($this->formatPlural($count, 'Imported 1 feed.', 'Imported @count feeds.'));
./src/Form/FeedScheduleImportForm.php:61: $this->messenger()->addStatus($this->t('%title has been scheduled for import.', $args));
./src/Form/CustomSourceDeleteForm.php:100: $this->messenger()->addStatus($this->t('The source %label has been deleted from the feed type %feed_type.', [
./src/FeedExpireHandler.php:26: $this->messenger()->addWarning($this->t('The feed became locked before the expiring could begin.'));
./src/FeedExpireHandler.php:83: $this->messenger()->addError($e->getMessage());
./src/FeedExpireHandler.php:105: $this->messenger()->addStatus($this->t('Expired @count items.', ['@count' => $state->total]));
./src/Plugin/Type/Target/TargetBase.php:113: return $this->messenger();
./modules/log/src/Form/DeleteForm.php:44: $this->messenger()->addMessage($this->t('Log %id has been deleted.', [
./modules/log/src/Form/ClearLogConfirmForm.php:47: $this->messenger()->addStatus($this->t('Logs cleared for feed %label.', [

against

./feeds.install:49: $messenger = \Drupal::messenger();
./tests/src/Kernel/FeedsEventsTest.php:63: $messages = \Drupal::messenger()->all();
./tests/src/Kernel/FeedsEventsTest.php:68: \Drupal::messenger()->deleteAll();
./tests/src/Kernel/FeedsEventsTest.php:92: $messages = \Drupal::messenger()->all();
./tests/src/Kernel/EntityIdTest.php:52: $messages = \Drupal::messenger()->all();
./tests/src/Kernel/EntityIdTest.php:165: $messages = \Drupal::messenger()->all();
./tests/src/Kernel/Feeds/Processor/GenericContentEntityProcessorTest.php:106: $messages = \Drupal::messenger()->all();
./tests/src/Kernel/Feeds/Target/LinkTest.php:83: $messages = \Drupal::messenger()->messagesByType('warning');
./tests/src/Kernel/Feeds/Target/TimestampTest.php:105: $messages = \Drupal::messenger()->messagesByType('warning');
./tests/src/Kernel/Feeds/Target/BookTest.php:297: $messages = \Drupal::messenger()->all();
./tests/src/Traits/FeedsCommonTrait.php:351: $messages = \Drupal::messenger()->all();

Additional Stacktrace

Drupal\feeds\FeedViewBuilder->getBuildDefaults() (Line: 157)
Drupal\Core\Entity\EntityViewBuilder->viewMultiple() (Line: 123)
Drupal\Core\Entity\EntityViewBuilder->view() (Line: 134)
Drupal\Core\Entity\Controller\EntityViewController->view()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
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)

rudi teschner → created an issue.

@mingsong: the empty-end-date-handling has not been altered by my suggestion

            // Deal with the end date in the same way as start date above.
            if (!empty($end_dates[$i])) {
              if ($end_field_option['type'] === 'timestamp') {
                $end_date = $end_dates[$i]['value'];
                $end_date = intval($end_date);
                $end_date = date(DATE_ATOM, $end_date);
              }
              elseif (strpos($end_field_option['type'], 'daterange') !== FALSE) {
                $end_date = $end_dates[$i]['end_value'];
              }
              elseif (strpos($end_field_option['type'], 'datetime') === FALSE) {
                // This field is not a valid date time field.
                $end_date = '';
              }
              else {
                $end_date = $end_dates[$i]['value'];
              }

              if (!empty($end_date)) {  <-- my changes start after this check
                $all_day = (strlen($end_date) < 11) ? TRUE : FALSE;

@luenemann: yeah, a little

I don't know the reason why it happens yet. But I've found a workaround by patching core for fields related to this module.

If the exception handling is removed for fields related to this module it does the trick - no exceptions thrown. Though I don't know why the exception handling causes the problems though - or rather brings the problems to light?

diff --git a/core/modules/layout_builder/src/Plugin/Block/FieldBlock.php b/core/modules/layout_builder/src/Plugin/Block/FieldBlock.php
index 4318ebee24..4d3fe0a698 100644
--- a/core/modules/layout_builder/src/Plugin/Block/FieldBlock.php
+++ b/core/modules/layout_builder/src/Plugin/Block/FieldBlock.php
@@ -160,21 +160,32 @@ public function build() {
     $display_settings = $this->getConfiguration()['formatter'];
     $display_settings['third_party_settings']['layout_builder']['view_mode'] = $this->getContextValue('view_mode');
     $entity = $this->getEntity();
-    try {
+    
+    if ($display_settings['type'] == 'editablefields_formatter') {
       $build = [];
       $view = $entity->get($this->fieldName)->view($display_settings);
       if ($view) {
         $build = [$view];
       }
     }
-    // @todo Remove in https://www.drupal.org/project/drupal/issues/2367555.
-    catch (EnforcedResponseException $e) {
-      throw $e;
-    }
-    catch (\Exception $e) {
-      $build = [];
-      $this->logger->warning('The field "%field" failed to render with the error of "%error".', ['%field' => $this->fieldName, '%error' => $e->getMessage()]);
+    else {
+      try {
+        $build = [];
+        $view = $entity->get($this->fieldName)->view($display_settings);
+        if ($view) {
+          $build = [$view];
+        }
+      }
+        // @todo Remove in https://www.drupal.org/project/drupal/issues/2367555.
+      catch (EnforcedResponseException $e) {
+        throw $e;
+      }
+      catch (\Exception $e) {
+        $build = [];
+        $this->logger->warning('The field "%field" failed to render with the error of "%error".', ['%field' => $this->fieldName, '%error' => $e->getMessage()]);
+      }
     }
+    
     CacheableMetadata::createFromRenderArray($build)->addCacheableDependency($this)->applyTo($build);
     return $build;
   }

This should do the trick - solution analog to the linked issue. Only tests need to be added.

Rudi Teschner → created an issue.

Here is a version that works for me on a D10 website with D10.1.4 and workflow 8.x-1.7

The changes in the patch in #7 alone are not enough. For example are the event classes missing

Rudi Teschner → created an issue.

Adding an advanced html/text element according to https://www.drupal.org/project/webform_validation/issues/3261965 → there still is an error:

Warning: Undefined array key "title" in webform_validation_webform_element_configuration_form_alter() (Zeile 59 in /var/www/html/docroot/modules/contrib/webform_validation/webform_validation.module).

My mistake. I forgot to initialise the user_history database via user_history/update :)

I fear the patch I suggested was just handling the error, but not dealing with the origin of the problem.

I have fields where changes need to be tracked and they are listed in $attached_fields. So far, so good.
But while looping through $attached_fields they are missing from $field_definitions in function user_history_create_user_history and therefore cannot be dealt with

// Get a list of fields attached to the user_history entity.
  $field_definitions = \Drupal::service('entity_field.manager')->getFieldDefinitions('user_history', 'user_history');

The patch above deals with the error. But the problem is that the field_definitions should be made available at this point so that the values can be tracked.

Has this worked for fields added via field api before?

Rudi Teschner → created an issue.

Rudi Teschner → created an issue.

Here's your suggested change as patch for 2.x

Rudi Teschner → created an issue.

In my opinion the only plausible solution would be to skip the conflicting user, add the proper watchdog message and continue syncing the rest of the users.

I found it pretty annoying that its hijacking the user links too without an option to prevent that from happening, since I use tabs to structure node content and its rendering into every single tab.

Guess an config check could be added to renderCacheLink() where the link is rendered but it could probably be solved way earlier.