"This value should be of the correct primitive type" error when field has no value

I have this problem too.

|| The Authored on date is invalid. Please enter a date in the format 2014-05-01 1:45:48.
|| This value should be of the correct primitive type.

Can you be a little more specific so we can try to reproduce the bug?

If I create the field as required and I don't fill the fields, I will get the expected "this field is required" error.

If it isn't required, I get no error.

But anyways, you should check this link https://www.drupal.org/node/2012690, there's an ongoing discussion about message types, it will clarify you some points about the error messages with the entity system.

I get this on the default install adding an image to an article. It has a required alt field which seems to cause this.

- adding an image
- try to save the node
- alt text is required
- add some text to the alt
-

This value should be of the correct primitive type.

I guess this should have been reported already

https://www.drupal.org/project/issues/drupal?text=This+value+should+be+o...

does not reveal much issues.

I mark this as major as I cannot save an article with an image

The steps described by @pablitt seems to apply to.

I seem to found a fix for image but that feels not quite OK as the reported issue is about another compound field.

I tried to reproduce this on Link field which also has an Alternative text according to https://www.drupal.org/node/465106#alt-text

I promote as parent #2012690: [Meta] Add useful information to 'type' constraints error messages

I retested this and discovered devel-generate can generate article. Attached a (shortened) screenshot.

Cannot reproduce. Are there any steps missing?

@lokapujya thanks for testing. I cannot reproduce this either on the image. What I do see is the preview works way different then last friday. Set prio back to normal.

I still like a patch review as I do not get the 'label' field type for image alt + text

I had the same issue but it wasn't related to the Alternative text.

It seems that my issue was related to the image thumbnail was not being generated. And my issue was related to imagemagick needed some more info on what images to work with.

(How to solve the imagemagick issue look in the README.txt and where it says ENABLE/DISABLE SUPPORTED IMAGE FORMATS)

Need to make a better case for why the field type should change. I don't see yet why 'string' is better that 'label', since 'label' is more descriptive.

@clemens.tolboom
I'm a bit confused why we remove the translatability from this configuration. Is this really the right thing to do?

@dawehner iirc my reasoning was that image 'alt' is not a 'label' but a 'string'. I checked with other entity label vs string usage and 'string' had a better match for alt

Have someone an idea, why this could happened to us after an update from D8 core from 8.0.1 to 8.0.2 with current imported data from running 8.0.1 website?

@IT-Cru: Can you please provide more details. What exactly is happening? and what caused it? is it reproducible?

@lokapujya: We are using our images together with media_entity modules. Existing images doesn't have the problem. Only creation of new ones make problems with alt, title and focal point data field from focal_point contrib module.

Any idea how to debug this?

That still doesn't explain how to reproduce the issue. See https://www.drupal.org/issue-queue/how-to#Description The original issue description described the problem ok, but those steps seem to no longer recreate the error.

In our project with this error after upgrading from 8.0.1 to 8.0.2 I found a solution:

Debugging shows that all new created images have no height / width. This brings me to check our image toolkit settings (we are using imagemagick). ImageMagick settings makes problems, so I switch back to GD and then creation of images works again.

Then I give imagemagick again a try and configured it new and export settings. After running the D8.0.1 to D8.0.2 upgrade again with our current database all works fine.

Perhaps this will help other ones.

The issue is probably not with drupal but with the jpg

Added step to reproduce this bug.

This patch doesn't resolve the issue for me.

After reading #17 properly, I was able to fix my issue. The image styles were broken because of the SVGs uploaded and caused this error. What is this issue about? Preventing this error when image styles fail to be generated?

This appears to be a duplicate of #2377747: Incorrect node create validation error when an invalid image is attached to a field. Thanks!

This should not be closed, as the related issues are indeed related, but this is actually more related to uploading SVG files. Whenever an image is uploaded, it will try to generate a preview by default. For an SVG, it can not apply image styles, since they can not be scaled/cropped like a bitmap file.

The workaround would be to disable thumbnail preview on the image field in the form display settings. Works for me.

Thanks @Martijn Houtman.

If the SVG issue will not be resolved by #2377747: Incorrect node create validation error when an invalid image is attached to a field, then this issue needs to be rescoped for whatever bug related only to SVGs would be left over after that is fixed. The current issue title reflects a duplicate, so the issue would need a new title.

At the least, postponing on #2377747: Incorrect node create validation error when an invalid image is attached to a field so that the main bug is fixed first.

Patch #5 this_value_should_be-2220381-5.patch does not resolve my issue adding a Fivestar field

I'm running Drupal 8.3.2,

I was having the same problem uploading an image to the article content type. The image was a jpeg. I'm running on a windows localhost (WAMP). When I looked at the image in the windows file folder, the thumbnail for that image was not appearing.

I looked for another image which had the thumbnail appearing in the windows file folder and tried it, and it worked. So the Issue has to do with the uploaded image itself.

I don't know why this is happening since both images have a .jpeg extension.

Any help would be appreciated

I'm using Drupal 8.3.2 on Wamp,

I'm facing the same issue while trying to save a node for the article content type with an image uploaded.

The image I'm uploading is a jpeg image. Checking the windows file folder where that image resides, the thumbnail preview does not appear. Other Image thumbnails in the windows file folder that do appear when uploaded to the article node and saved do work. I have attached a screenshot of the file folder.

So I guess the issue is due to the image uploaded. But I don't understand why since both are jpeg images.

Any Help would be appreciated.

please anyone give the proper solution . i am facing the same problem in 8.5.x version.

When I ran into this issue I had my image toolkit set for what I have in production. I changed it to GD2 and the error message went away.

The error is not related to D8 core, but to image toolkit plugin, I just applied the solution by @albertski to change to GD2 and it works properly.

Check the MIME type of this file. I just ran into this error and the image file has an unknown MIME type. An easy test is to open the local image file in a web browser.

#2377747: Incorrect node create validation error when an invalid image is attached to a field is in now, unpostponing.

I faced same error but it was found later that the error was related to improper permissions to files directory... Thus it was related not to alt and title fields but to the entire file field.

I've seen the same error when creating a custom field type with two integer properties and a simple widget with two number fields.
We were not able to submit the form with empty values as it was considered incorrect.

Edit: I found a workaround in the widget

  public function massageFormValues(array $values, array $form, FormStateInterface $form_state) {
    foreach ($values as $key => $value) {
      if (empty($value['my_first_value'])) {
        unset($values[$key]['my_first_value']);
      }
      if (empty($value['my_other_value'])) {
        unset($values[$key]['my_other_value']);
      }
    }

    return $values;
  }

#18 nailed it for me. The image was damaged and thus the preview couldn't be generated.

My solution turned out to be the directory settings and not the title, image or GD. There was an invalid character in the upload directory name.

Config import to set imagemagick in /admin/config/media/image-toolkit seems to be a little buggy. To fix:

1. Go to /admin/config/media/image-toolkit
2. Manually set to GD then save
3. Go back to /admin/config/media/image-toolkit
4. Manually set back to imagemagick then save

Fixed the problem for me.

#24 seemed to be the right fix for me.

The validator core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/PrimitiveTypeConstraintValidator.php should bubble-up what it's the error if it can get any more information.

For example, to DateTimeInterface:

if ($typed_data instanceof DateTimeInterface && $typed_data->getDateTime() && $typed_data->getDateTime()->hasErrors()) {
  $valid = FALSE;
}

It could use $var->getErrors() to get what is the actual fail.

The same with other data types, another way you must stop execution in the validator to see the exact error.

I think an actual issue here is that if the settings of width, height (and possibly others) of an image field are empty this misleading error is thrown and the alt field has the error set on it. Looking at the comments this is usually do to bad widgets (or stream wrappers?), but the error should be better.

This still needs Needs issue summary update. We have ~50 comments of which a lot are 'I have this too' in various conditions.

The search https://www.drupal.org/project/issues/drupal?text=This+value+should+be+o... found another #3101445: "This value should be of the correct primitive type" error with working file field in custom entity after upgrade to 8.8.0 which seems to be about File and is referring back to #2012690: [Meta] Add useful information to 'type' constraints error messages

Searching for 9.x did not result into title hits. Is it fixed in D9?

Hopefully someone can update the summary listing field types and other steps to reproduce :-)

My scenario matches #41 and the solution there works, but why this has not been address in the core is a bit confusing. The need to save nullable integers seems like a valid and common use case.

I my case I am creating a custom field-type...

The field definition looks like:

class MyCustomFieldType extends FieldItemBase {

  /**
   * @inheritDoc
   */
  public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition)
  {
    $properties = [];
    $properties['birth_date'] = DataDefinition::create('integer')
                                              ->setLabel('birth date')
                                              ->setDescription('The member instance birth date.');
    return $properties;
  }
 
public static function schema(FieldStorageDefinitionInterface $field_definition)
  {
    return [
      // columns contains the values that the field will store
      'columns' => [
        'birth_date' => [
          'type' => 'int',
          'not null' => FALSE,
        ],
      ]
    ];
  }

  public function isEmpty() {
    return false;
  }

Widget looks like...

class MyCustomFieldTypeWidget extends WidgetBase {

  /**
   * @inheritDoc
   */
  public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state)
  {

    $element['birth_date'] = array(
      '#type' => 'textfield',
      '#title' => t('Date Of Birth'),
      '#description' => t('Enter member\'s date of birth'),
    );

    //setting default value to all fields from above
    $children = Element::children($element);
    foreach ($children as $child) {
      $element[$child]['#default_value'] = isset($items[$delta]->{$child}) ? $items[$delta]->{$child} : NULL;
    }

    return $element;
  }
}

... and a basic formatter (not shown).

Now when I attach the field-type to a node and configure, when saving the defaults you get the above mentioned error.
The reason is that primitive type validation does not accept an empty string for integer fields. In some ways this makes sense, but then there should be a way to set the default to null or some solution.

We were getting this on empty Taxonomy reference fields as well. We have a distribution with various taxonomy reference fields and sometimes they aren't even used, so they never get filled with terms. With recent updates to d9, we have had to make sure these fields are disabled on the content types if there are no terms to select.

Faced the same issue with the taxonomy reference field only when value is none which was using a simple hierarchical select (provided by shs module) field in the form. Solved the issue by changing it to the normal select field in form.

Not sure if it has anything to do with field formatter type or of any constraints.

Doing Bugsmash triage.

First, thanks to everyone here working on this.

I have read the IS and skimmed the comments. It really isn't clear what bug this issue is working to fix. An issue summary update and re-scoping was asked for 5 years ago and that has yet to happen. This was mentioned again in #51.

Let's see if I can do something useful here.

Reading through the issue there are many comments from people having this problem, which appears to mean the error message. But #27 and the steps to reproduce in the Issue Summary say that this issue is to fix the problem only for upload of svg. So, which is this, a general fix for the error message or something about svg upload?

To help decide I tested this with 9.3.x, standard install, following the steps in the issue summary and could not reproduce the problem. Uploading an svg worked just fine, no error. So, this is just about the error message.

So, the next step here is to get an Issue Summary update, including steps to reproduce. I have added the standard template to the IS and removed the steps to reproduce because I could not reproduce the error and they were for unsupported versions of Drupal.

Hope that helps to move this along.

I don't know if it will help narrow this down, but I just installed some updates to my site, including updating simple hierarchical select, and this error began showing up on my site. Given that another poster a month ago also reported simple hierarchical select, I suspect that something changed in the 12 commits between SHS shs 8.x-1.0-alpha5 and 2.0.0-rc1 that causes this issue to show up. For the moment I'm unfortunately on a time crunch and will probably just switch over to cshs rather than try to debug further.

Update: This issue with shs is reported and worked on here: https://www.drupal.org/project/shs/issues/3241169

I've already moved onto cshs, but it appears that error is caused when Drupal is expecting an array and receives a string value instead.

Added related issues mentioned in comments #51 and #57

I just had this issue pop up with a Taxonomy reference field. I altered the #empty_option to '' and got these errors on all empty select lists. Switched to '_none' and the errors went away, but also ruined our select list JS library in the process, as it's expecting an empty option for the placeholder.

Following discussion thread in #52, and being broadly in the same scenario (custom entity reference field type and a widget that extends EntityReferenceAutocompleteWidget), for me the validation error could be avoided by making $form_state->setValueForElement($element, ['target_id' => null]) when the field is submitted empty, in the validate method.