I have a custom entity type being created by a module, and it uses the standard Field UI. Using this custom entity type, I attempt to do the following:
a) Create a bundle using the UI from the module.
b) Go to Manage Fields.
c) Add a plain text field.

When I submit the form from the Manage Fields page, I get the following error:

There was a problem creating field [the entered field label]: The "string" plugin does not exist.

I traced this down to an exception that is being thrown from the following lines of \Drupal\field_ui\FieldOverview.php:

        // Make sure the field is displayed in the 'default' form mode (using
        // default widget and settings). It stays hidden for other form modes
        // until it is explicitly configured.
        entity_get_form_display($this->entity_type, $this->bundle, 'default')
          ->setComponent($values['field_name'])
          ->save();

Specifically, the save() line is where the exception is generated.

As a note, the field is actually being created correctly, using the default field/formatter/widget values, when I submit the form. The problem is that normally when you submit the form you get to the next screens that let you set formatter/widget stuff, and these are not appearing. I can get back to them by clicking Edit however.

As a note, if before attempting to create a field, I visit the Manage Form Display page and save the form display, I am then able to create fields without problems.

I also have a test that reproduces this behavior, but it relies on an entity module that the test is supposed to be testing, so I am not sure how useful it is for this issue. Apparently the Field UI tests are not triggering the problem; they are using Node for testing the Field UI. It probably does not have this problem because when you create a content type, you get the Body field added, which might do something like saving the default form display before you actually get to the Field UI page.

Also, this is reproducible. After saving the Manage Form Display page if I go create a new bundle, the problem happens on the next bundle too.

So... I can't really figure out what "string" plugin would be missing? The only thing I can think of is that the default widget for plain text fields is Drupal\text\Plugin\Field\FieldWidget\TextfieldWidget, which extends Drupal\Core\Field\Plugin\Field\FieldWidget\StringTextfieldWidget, and that one has in its annotation:

 * @FieldWidget(
 *   id = "string_textfield",
 *   label = @Translation("Textfield"),
 *   field_types = {
 *     "string"
 *   }
 

This apparently refers to the Drupal\Core\Field\Plugin\Field\FieldType\StringItem class plugin... is it possible that this is somehow not being loaded soon enough or something weird like that?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhodgdon’s picture

Title: Fields cannot be created until form mode is saved » Error when creating fields until form mode is saved

Fixing title, since the field is created

jhodgdon’s picture

Also, as a note, this was working about 4 weeks ago -- my test was passing. And today it isn't. I am not sure exactly when it failed because I didn't try the tests in the meantime.

larowlan’s picture

This hit me too, in various contrib projects, https://github.com/md-systems/file_entity/pull/5 is one example fix

jhodgdon’s picture

So you're saying that all entity base fields need to use "string_textfield" instead of just "string"? Because Node does not do that:

    $fields['title'] = BaseFieldDefinition::create('string')

So this doesn't make sense to me?

jhodgdon’s picture

Oh wait, you're saying it's on the formatter. Ah, got it!

jhodgdon’s picture

But.. #2271419: Allow field types, widgets, formatters to specify config dependencies is the referenced issue and that issue didn't change the Node.php file. Where is the issue that actually made this change?

swentel’s picture

jhodgdon’s picture

Assigned: Unassigned » jhodgdon

Assigning to me to test again.

jhodgdon’s picture

Status: Active » Closed (cannot reproduce)

I tested this today and the problem has vanished.

jhodgdon’s picture

Status: Closed (cannot reproduce) » Active

Actually, I think the error still kind of exists.

This works fine in the UI now, as I reported in #9. However, when I try to add a field from the UI *inside a test*, I get a schema error:

There was a problem creating field The field label: Schema errors for core.entity_view_display.myentity.test.default with the following errors: core.entity_view_display.myentity.test.default:content.title.hidden missing schema

All that the test is doing is:

a) Adding a bundle using my module's entity UI for that.

b) Visiting the Manage Fields page.

c) Clicking "Add field". This message is displayed.

So it looks like the "default" entity view display is not working for my entity's built-in Title field. I can't add any new fields in a test with this broken...

jhodgdon’s picture

My mistake. The error happens when you try to submit the form after Add Field, same as in this original report.

jhodgdon’s picture

Status: Active » Closed (cannot reproduce)

More debugging: I attempted to reproduce this in a test with the Taxonomy Term entity type. The test passed. And as noted in this original issue summary, it also works fine in tests with the Node entity type, which I think is because nodes have a Body field added when bundles are created (maybe Taxonomy is doing something similar).

So it only seems to fail (so far) on my test entity.

So... oh wait! I see that in the base field definition for my entity, I still had a

          'hidden' => TRUE,

setting on the Title field in the display section. Node seems to have lost that. So, removed that line... Test gets past this problem!

Back to Cannot Reproduce then.

dpopdan’s picture

Status: Closed (cannot reproduce) » Needs work

I still got this error on beta-10. It is the same error and it disappears after saving the form mode display.

jhodgdon’s picture

Assigned: jhodgdon » Unassigned

I'm not working on this right now.

dpopdan’s picture

Re-tested this issue, the error still exists.

mmrares’s picture

Seems to be related to this changes: https://www.drupal.org/node/2457593. Since String is a reserved word in PHP 7 the plugin named String was removed probably.

matthias_bauw’s picture

So this this still exists...

For those like me who didn't get the workaround right at the first try; You need to change the the type string into string_textfield, but only on the setDisplayOptions('form'

not on the setDisplayOptions('view'

not very consistent if you ask me

catch’s picture

@DragonEye can you post updated steps to reproduce?

matthias_bauw’s picture

@catch: I'm gonna try. I checked my git repo and this should be the version of the class that had the problem:
Class Newsletter extends ContentEntityBase{
public function preSave(EntityStorageInterface $storage) {
parent::preSave($storage);

//set the current user as created_by
$currentuser = \Drupal::currentUser()->id();

$this->set('created_by',$currentuser);

}

public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
$fields['id']= BaseFieldDefinition::create('integer')
->setLabel(t('id'))
->setDescription('Unique identifier for the newsletter')
->setReadOnly(TRUE);
$fields['created_by'] = BaseFieldDefinition::Create('entity_reference')
->setLabel(t('Created by'))
->setDescription(t('User that has created the newsletter'))
->setSetting('target_type', 'user')
->setCardinality(1)
->setReadOnly(TRUE);
$fields['sent'] = BaseFieldDefinition::Create('boolean')
->setLabel(t('Send complete'))
->setDescription('Indicates wheter users have received the newsletter')
->setReadOnly(FALSE);
$fields['title'] = BaseFieldDefinition::Create('string')
->setLabel(t('Title'))
->setDescription('Title for the newsletter')
->setReadOnly(FALSE)
->setRequired(TRUE)
->setSettings(array(
'default_value'=>'',
'max_length'=>'150',
))
->setDisplayOptions('view', array(
'label'=>'inline',
'type' => 'string',
'weight'=> -5,
))
->setDisplayOptions('form', array(
'label'=>'inline',
'type'=>'string',
'weight'=>-5,
));
$fields['subscription'] = BaseFieldDefinition::Create('entity_reference')
->setLabel(t('Subscriptions'))
->setDescription(t('Indicates to wich groups of subscribers this newsletter must be sent'))
->setReadOnly(TRUE)
->setSetting('target_type', 'subscription')
->setCardinality(FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED)
->setRequired(TRUE)
->setDisplayOptions('view', array(
'label'=>'inline',
'type' => 'string',
'weight'=> -4,
))
->setDisplayOptions('form', array(
'label'=>'inline',
'type'=>'options_buttons',
'weight'=>'5',
));

return $fields;
}
}

When I changed the type parameter on setDisplayOptions to string_textfield the problem was solved. The whole thing is just some code I wrote to learn about entities and Drupal 8 since I'm a beginner.

The whole module code is available at https://github.com/Matt-From-Belgium/jestaatnietalleen/tree/ff44c210ab03...

This should be the version of the module with the bug in it. I think the bug was definately shown on beta15. Not sure about later versions.

matthias_bauw’s picture

oh just to make sure: I only changed the setDisplayoptions('form'....

on the view it does not seem to be a problem. So it's limited to the widget i think. formatter seems fine.

johnv’s picture

ATM I have the same problem , working on the workflow module, trying to make workflows fieldable.
The error appears on any field type. Each generates the error referencing 'string'.
My hunch was that my entities are not translatable.

[EDIT] I've got is working. After reverse enigeering Node.php and content_entity_example.module

tormi’s picture

Project: Drupal core » examples
Version: 8.0.x-dev »
Component: text.module » Code
Related issues: +#2454439: [META] Support PHP 7

Based on comment #21, it seems to me like a bug in Examples for Developers module, a leftover from CR Various classes/interfaces renamed to support PHP 7

tormi’s picture

Project: examples » Examples for Developers
Version: » 8.x-1.x-dev
Component: Code » Content Entity Example

Sry, previous was wrong examples module ;)

johnv’s picture

Title: Error when creating fields until form mode is saved » content_entity_example: Error 'The "string" plugin does not exist.' when adding field until form mode is saved
Status: Needs work » Active

Settigs to 'Active', since there is no patch.

Still happens todays dev-version when adding a Number field, using Drupal 8.0.0 using DevDesktop stack on Windows with PHP 5.6.14

The error implies there is an error. But returning to the Manage Fields page, the field is there, and you can inspect the Field and Storage settings. They seem OK. You can also add an entity, and edit and view the new field without problem.

There is no problem when adding the same field to a new entity type using Field UI. So the problem seems to be in examples' "Content Entity Example" .

johnv’s picture

Hmm, after the error occurred (this is not the first time I encountered the error. It happened to me in the past, too),
I tested simpletest_exampel and node_type-example. I could add fields to all 3 node types for both modules without problem.
Then I deleted the field from content_type_example, and added the field again with another name. The errro did NOT occur....

Perhaps it only happens on a fresh install for the first added field? In that case, it is no error from examples module.
I cannot find a related core issue with the same error, though.

Chi’s picture

Title: content_entity_example: Error 'The "string" plugin does not exist.' when adding field until form mode is saved » content_entity_example: wrong plugins IDs
Status: Active » Needs review
FileSize
1.19 KB

Fixed plugins IDs

Mile23’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Needs tests

Thanks, a lot of good work here.

I'm able to repro by enabling content_entity_example and then going to the contact entity field management page: admin/structure/content_entity_example_contact_settings/fields. From there I try to add any type of field (boolean was first in the list) and get an error like this: There was a problem creating field test: The "string" plugin does not exist.

I think the patch in #26 is the right solution, but let's prove it.

We need a functional test that adds a field to a Contact entity.

If we could see a test-only patch that fails, as well as a solve-everything patch, that would be awesome.

pflame’s picture

Status: Needs work » Needs review
FileSize
3.29 KB
2.09 KB

Attached test only patch file and full patch file along with test.

Status: Needs review » Needs work

The last submitted patch, 28: 2372717-28-full.patch, failed testing.

Mile23’s picture

If you name both patches as *.patch they'll both run and we can see the results right here. :-)

pflame’s picture

@Mile23,
I thought only one patch file should be submitted for one comment. Now I attached 2 patch files with test case only and full patch.

I changed test case a bit, instead of checking the entire url with query options, just checked the path. This is good for checking if the add field is working without raising any errors.

pflame’s picture

Status: Needs work » Needs review

The last submitted patch, 31: 2372717-31-test-only.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 31: 2372717-31-full.patch, failed testing.

pflame’s picture

Fixed the URL issues in the above test case.

Now full patch does not fail, only test only patch fails.

The last submitted patch, 35: 2372717-35-test-only.patch, failed testing.

Mile23’s picture

Status: Needs review » Fixed
Issue tags: -Needs issue summary update, -Needs tests

Great. Thanks, everyone, and pflame for sticking with it.

  • Mile23 committed d0521b8 on 8.x-1.x authored by pflame
    Issue #2372717 by pflame, Chi, jhodgdon: content_entity_example: wrong...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.