🇩🇪Germany @Rudi Teschner

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.