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?
Comment | File | Size | Author |
---|---|---|---|
#35 | 2372717-35-full.patch | 2.7 KB | pflame |
| |||
#35 | 2372717-35-test-only.patch | 1.5 KB | pflame |
#31 | 2372717-31-full.patch | 2.65 KB | pflame |
#31 | 2372717-31-test-only.patch | 1.46 KB | pflame |
#28 | 2372717-28-test-only.txt | 2.09 KB | pflame |
Comments
Comment #1
jhodgdonFixing title, since the field is created
Comment #2
jhodgdonAlso, 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.
Comment #3
larowlanThis hit me too, in various contrib projects, https://github.com/md-systems/file_entity/pull/5 is one example fix
Comment #4
jhodgdonSo you're saying that all entity base fields need to use "string_textfield" instead of just "string"? Because Node does not do that:
So this doesn't make sense to me?
Comment #5
jhodgdonOh wait, you're saying it's on the formatter. Ah, got it!
Comment #6
jhodgdonBut.. #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?
Comment #7
swentel CreditAttribution: swentel commentedIt think it was #2313757: Remove text_processing option from text fields, expose existing string field types as plain text in UI
Do we need further action here or can this be closed ?
Comment #8
jhodgdonAssigning to me to test again.
Comment #9
jhodgdonI tested this today and the problem has vanished.
Comment #10
jhodgdonActually, 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...
Comment #11
jhodgdonMy mistake. The error happens when you try to submit the form after Add Field, same as in this original report.
Comment #12
jhodgdonMore 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
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.
Comment #13
dpopdan CreditAttribution: dpopdan commentedI still got this error on beta-10. It is the same error and it disappears after saving the form mode display.
Comment #14
jhodgdonI'm not working on this right now.
Comment #15
dpopdan CreditAttribution: dpopdan commentedRe-tested this issue, the error still exists.
Comment #16
mmrares CreditAttribution: mmrares commentedSeems 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.
Comment #17
matthias_bauw CreditAttribution: matthias_bauw commentedSo 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
Comment #18
catch@DragonEye can you post updated steps to reproduce?
Comment #19
matthias_bauw CreditAttribution: matthias_bauw commented@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.
Comment #20
matthias_bauw CreditAttribution: matthias_bauw commentedoh 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.
Comment #21
johnvATM 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
Comment #22
tormiBased 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
Comment #23
tormiSry, previous was wrong examples module ;)
Comment #24
johnvSettigs 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" .
Comment #25
johnvHmm, 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.
Comment #26
Chi CreditAttribution: Chi commentedFixed plugins IDs
Comment #27
Mile23Thanks, 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.
Comment #28
pflame CreditAttribution: pflame commentedAttached test only patch file and full patch file along with test.
Comment #30
Mile23If you name both patches as
*.patch
they'll both run and we can see the results right here. :-)Comment #31
pflame CreditAttribution: pflame commented@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.
Comment #32
pflame CreditAttribution: pflame commentedComment #35
pflame CreditAttribution: pflame commentedFixed the URL issues in the above test case.
Now full patch does not fail, only test only patch fails.
Comment #37
Mile23Great. Thanks, everyone, and pflame for sticking with it.