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

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 values displayed in my list are now "commerce" then "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.

I have encountered this issue as well, but in my case it was with the Prism module: #3491768: Prism causes WSOD on field creation for all field types

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

EDIT: I think its because of this change to the API: https://www.drupal.org/node/3375748

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 found out it's a contrib issue:
#3486365: Using a translatable string as a category for field type is deprecated (breaks D11)

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): #3486365: Using a translatable string as a category for field type is deprecated (breaks D11)

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!

#3386762: Use modals in field creation and field edit flow 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?

Ran into this issue today. Saw someone mention that it might be triggered by this api change https://www.drupal.org/node/3375748. Sure enough, grep "category = @Translation(" -r . | grep "FieldType" got a hit in our modules directory. Adjusting the offending module fixed the issue.

Confirming what @redeight posted in #33 - removing an incorrect category on a @FieldType annotation fixed this problem for me also. Couldn't have found the issue though without the patch.