Changes in site building process can run into Cannot access offset of type StringTranslation\TranslatableMarkup on field creation path

Thanks @quietone for correcting the version scope.

To save time of all who want to chime in I would like to let you know: I probably am about to change the summary over the next days after more investigations again. Because we're may be on the trail of something in a bigger picture here which maybe rather leads to an FR, like:

"Let's provide a better exception not breaking frontpage or admin pages for all the type and offset errors raising now with newer PHP versions."

Maybe another related (still not linking them since it needs to cleared how and IF the are related really): 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active

hi there,
I'm facing this issue with d11.
Everything was working pretty good, and this morning... field additions broke on content type, product types, commerce types, etc.
I tried to trace the problem by adding a line of code in the DiscoveryTrait file :
if (isset($plugin_id)) { print($plugin_id); echo "<br>"; }
It results in a long list, in which the last value is "Commerce" (with cap).
I lowercased $plugin_id, and it finally throws another error :
TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup on array in Drupal\field_ui\Form\FieldStorageAddForm->processFieldDefinitions() (line 141 of core/modules/field_ui/src/Form/FieldStorageAddForm.php).
The last value displayed in my list is "general".
Hope it helps ... it's my sixth hour of research :D I need a break and a pizza !

Ok guys,
I have the confirmation that the issue is related to commerce in my case.
The freak variables are isolated with this code :

    if($plugin_id=="Commerce") {
      echo "<pre>";
      print_r($definitions);
      echo "</pre><br>";
    } else {
          // Avoid using a ternary that would create a copy of the array.
          if (isset($definitions[$plugin_id])) {
            return $definitions[$plugin_id];
          }
          elseif (!$exception_on_invalid) {
            return NULL;
          }
    }

The add field form is working now, even if the problem is not solved.
At the moment I don't understand what's happening.

I'm also getting the same error today, and the research found that it was caused by the missing "category" in the custom field.

Thanks for all the reports. This indicates that we maybe need a proper exception handling and warning for such cases to prevent WSOD and sites being unmaintainable in this state.

I have encountered this issue as well, but in my case it was with the Prism module: https://www.drupal.org/project/prism/issues/3491768 🐛 Prism causes WSOD on field creation for all field types Active

In my case, I think the problem was caused by setting 'category' to a Translation in the FieldType definition.

Created a merge request that throws an exception when the field type category is not valid.

We're running into a very similar issue in the function:

TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup on array in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 45 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php). 

Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 136)
Drupal\field_ui\Form\FieldStorageAddForm->processFieldDefinitions() (Line: 80)
Drupal\field_ui\Form\FieldStorageAddForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 96)
Drupal\crowdsec\Middleware->handle() (Line: 263)
Drupal\shield\ShieldMiddleware->bypass() (Line: 162)
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: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I'll try to find the root cause now.

Update: The attached MR adding an exception with very helpful details GREAT!

Instead of the message in #20 we now see a nice verbose error:
Exception: Invalid field category for field typeentity_reference_display, category must be the ID of aa defined field category, got Referenz. in Drupal\field_ui\Form\FieldStorageAddForm->processFieldDefinitions() (line 136 of core/modules/field_ui/src/Form/FieldStorageAddForm.php). from which we can see it's a migration issue and how to fix this.

RTBC! Would be nice to cherry-pick this into 10.4.x and 10.5.x

Confirming RTBC and fixed typo

Root cause for us (we were able to find that thank to @berdir's MR): 🐛 Using a translatable string as a category for field type is deprecated Active

There's still a missing space typo.

Thanks @godotislate, sorry I didn't see that. Fixed that. As both were only textual changes, I'm setting this back to RTBC, but feel free to confirm that.

I read the IS, MR and the comments . I didn't find any unanswered questions. I did leave a comment on the MR but before taking action it would be better to get the opinion of another committer to determine if this is the correct fix.

I think I agree with @quietone's review - doesn't look like it loses any information from the error message, and moving one line earlier seems fine too.

Made the change per @quietone and @catch. Back to NR.

Does this need a test? It was at RTBC previously without one.

As a bug I would assume it would need a test as mentioned no?

We have some rules around skipping tests if the fix is straightforward and unlikely to break again. This is just a safety guard against code that was not properly updated to D10+ to provide a more helpful error.

Testing it would require that we add an invalid test implementation of a field type and that seems a lot of trouble for this.

Lets try :)

Thanks. It is easy to find the culprit now!

✨ Use modal in add new field flow Active completely removed the exception. In manual testing, I don't even get far enough because there's an assertion in \Drupal\Core\Field\FieldTypePluginManager::getGroupedDefinitions(), but that was there before and it's not as helpful I think. Maybe instead of that assert(), we should throw the exception there?