I am working on a site in which I have created a new Field Type: MyCustomFieldType (+widget/Formatter)
A field of this type has been added (name=field_mb_orders) to a paragraph field [and this paragraph to a node].

Everything runs fine but at some stage I need to drush cr and I got the following error:
Unable to determine class for field type 'MyCustomFieldType' found in 'field.storage.paragraph.my_field'

Of course the module and plugIn files for the fieldType exists... (restarted apache in any case)

The only way I could solve this is by running the following commands:

drush sqlq "DELETE FROM cache_config"
drush sqlq "DELETE FROM config WHERE name = 'field.storage.paragraph.field_mb_orders' OR data LIKE '%field.storage.paragraph.field_mb_orders%'"
drush sqlq "DELETE FROM config_snapshot  WHERE name = 'field.storage.paragraph.field_mb_orders' OR data LIKE '%field.storage.paragraph.field_mb_orders%'"

After those commands, my site is usable but I still need to re-add field_mb_orders to my paragraph (which is ok as there are no data for it yet)

This is the third time it happens...
Note 1: there are no config file for this custom Field Type as there are no settings for it..
Note 2: Don't know if this is a paragraphs issue or a core issue

FYI: The first time it happens I was thinking it was a problem with the underscores inside the class names... but I removed them and I got this problem few time after

Comments

DuneBL created an issue. See original summary.

cilefen’s picture

cilefen commented
Priority: Critical » Normal

We don’t know if the custom code in the context of this issue is using APIs appropriately so I’m bumping this to normal priority.

dunebl’s picture

dunebl
Primary language French
commented

@cilefen: fair enough...

But even if I don't use appropriately the API, how can we explain

A-Site/Custome Field Type/Widget are working
B-Clear cache => Site is down [I am sure at 95% that I made other drush cr before]
C-Removing some occurrences in the DB WITHOUT changing anything in the source file => Site is back
D-Clear cache =>My custom field type is back

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Postponed (maintainer needs more info)

The error happens if that field type is not found, which is either because it is missing in the file system or the module is not enabled.

This is an explicit error message telling you about that, Drupal can't function in that state with the code missing, so there really isn't much that could be done about it except telling you about the error.

What I noticed is that you used a) camel case for the plugin/field type ID, which is very uncommon but *should* not cause problems and b) MyCustomFieldType really isn't a good field type ID ;)

I suggest you share the name of your module and its location, FQDN of the plugin class, its annotation and anything else you think might be relevant. But this is very unlikely to be a problem in core or in contrib.

> Note 1: there are no config file for this custom Field Type as there are no settings for it..

I'm not sure what that means, clearly there *is* configuration for it, that field?

Note that you delete possibly quite a lot with that statement, e.g. all form/view displays that depend on it.

dunebl’s picture

dunebl
Primary language French
commented

@Berdir many thank for your help...
I keep getting this problem... and I can replicate it by following the steps (poorly) described in #3
In other words, I can follow this looping process:
Working web site => drush cr => Not working web site => remove records in db (see #1) => drush cr => Working web site

Before sharing the code (to avoid loosing your time... but see below), I discovered that I have a message in the /admin/reports/status page regarding the fields that I have created (using my custom field type)

The %field_name field needs to be uninstalled.

To solve this, I ran cron, I drush cr and finally drush entup =>but this last step display the following error:

In DiscoveryTrait.php line 52: The "field_item:mwd" plugin does not exist.

mwd is the id of my problematic custom field type...

Unfortunately I can't get rid of it: impossible to remove this warning in the /admin/reports/status page

If you think it is appropriate, here is the code of my field type

/**
 * @file
 * Contains Drupal\dailysoup\Plugin\Field\FieldType\MWDItem.
 */
namespace Drupal\dailysoup\Plugin\Field\FieldType;

use Drupal\Core\Field\FieldItemBase;
use Drupal\Core\Field\FieldItemInterface;
use Drupal\Core\Field\FieldStorageDefinitionInterface;
use Drupal\Core\TypedData\DataDefinition;
use Drupal\Core\TypedData\DataReferenceTargetDefinition;
use Drupal\Core\Validation\Plugin\Validation\Constraint\AllowedValuesConstraint;
use Drupal\Core\StringTranslation\TranslatableMarkup;

/**
 * Provides a field type of MonthWeeksDays Item.
 *
 * @FieldType(
 *   id = "mwd",
 *   label = @Translation("Days of week in a Month for a user"),
 *   description = @Translation("Store all days of week in a month for a user."),
 *   category = @Translation("Calendar"),
 *   default_formatter = "mwd_ds_formatter",
 *   default_widget = "mwd_ds_widget",
 * )
 */
class MWDItem extends FieldItemBase implements FieldItemInterface
{

    /**
     *
     * {@inheritdoc}
     */
    public static function schema(FieldStorageDefinitionInterface $field_definition)
    {
        return [
            'columns' => [
                'json' => [
                    'type' => 'varchar',
                    'length' => 2000,
                    'not null' => TRUE
                ],
                'target_id' => [
                    'type' => 'int',
                    'description' => 'The ID of the user.',
                    'unsigned' => TRUE
                ]
            ],
            'indexes' => [
                'target_id' => [
                    'target_id'
                ]
            ]
        ];
    }

    /**
     *
     * {@inheritdoc}
     */
    public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition)
    {
        $properties = [];
        $properties['json'] = DataDefinition::create('string')->setLabel(new TranslatableMarkup('Days of week in a month formated as JSON'))->setRequired(TRUE);

        $properties['target_id'] = DataReferenceTargetDefinition::create('integer')->setLabel(new TranslatableMarkup('User ID'))
            ->setSetting('unsigned', TRUE)
            ->setRequired(TRUE);

        return $properties;
    }

    /**
     *
     * {@inheritdoc}
     */
    public static function mainPropertyName()
    {
        return 'target_id';
    }

    /**
     *
     * {@inheritdoc}
     */
    public function isEmpty()
    {
        //I don't know why, but this function is not called when
	//a "last item" is automatically added in the widget and
	//I try to submit the form... If I understood correctly
	//it should be called and the validation should be skipped
	//as the field is empty... but the function is not called and I
	//get a validation problem (required field)

	$targetId = $this->get('target_id')->getValue();
        $json = $this->get('json')->getValue();
        return ($targetId == NULL) && ($json == '');
    }

    /**
     *
     * {@inheritdoc}
     */
    public function getConstraints()
    {
        $constraints = parent::getConstraints();
        // Remove the 'AllowedValuesConstraint' validation constraint because entity
        // reference fields already use the 'ValidReference' constraint.
        foreach ($constraints as $key => $constraint) {
            if ($constraint instanceof AllowedValuesConstraint) {
                unset($constraints[$key]);
            }
        }
        return $constraints;
    }

    public static function is_same_month(array $mwd_model, array $mwd_db)
    {
	//code removed because not useful for my problem
     }

    public static function get_mwd(int $month, int $year)
    {
	//code removed because not useful for my problem
     }

}

As a side note:

1-The problem is not linked with the paragraph module as I have tested this field in a node: same result
2-Clearing the caches with devel does not trigger the error... only with drush cr
3-let me know if you need the widget part

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

devkinetic’s picture

devkinetic commented

I've run into this recently on the last couple of Drupal 8.8 releases. It's always after adding a module that defines a new field type and when I've just run drush cim -y to update an environment.

I can consistently work around it by running drush en module_name && drush en module_name

Each time, I see [notice] Already enabled: module_name but something is happening because everything is fine afterwards.

paulmicha’s picture

paulmicha commented

There are 2 situations (Drupal 8.7.12, Drush 9.7.2) where I've experienced this error :

  1. Immediatey after having restored a local DB dump
  2. During drush site install, after having manually updated some field config exported .yml file in a feature module - specifically : adding a new paragraph type in a reference field (entity_reference_revisions)

The 1st case is solved relatively painlessly using workarounds such as https://drupal.stackexchange.com/a/246231/10419 (as originally described in this issue).

I'm currently stuck on the 2nd case which occurs during site install. The exact error message I get is : Unable to determine class for field type '' found in the 'field.field.' configuration..
The exact same error was apparently also encountered here : https://www.drupal.org/project/avatars/issues/3051270

There are no missing dependency errors.

Potentially relevant contrib modules versions :

  • paragraphs 8.x-1.2
  • entity_reference_revisions 8.x-1.8
  • features 8.x-3.8

Details :

in web/core/lib/Drupal/Core/Field/FieldConfigStorageBase.php, function mapFromStorageRecords() - both $record['field_type'] and $config_id are empty or NULL :

$record = Array
(
  [settings] => Array
  (
    [handler_settings] => Array
    (
      [target_bundles] => Array
      (
        [post_home] => post_home
        (...)
      )
      [target_bundles_drag_drop] => Array
      (
        [post_home] => Array
        (
          [enabled] => 1
        )
        (...)
      )
    )
  )
)

Whereas the field_type is there higher up in the call stack, i.e. in web/core/lib/Drupal/Core/Config/ConfigInstaller.php, function createConfiguration() line 337 - in variable $config_to_create :

$collection = 
$id = paragraph.layer.field_liste_de_composants
$name = field.field.paragraph.layer.field_liste_de_composants
$entity_type = field_config
$config_to_create = Array
(
  (...)
  [field.field.paragraph.layer.field_liste_de_composants] => Array
  (
    [langcode] => fr
    [status] => 1
    [dependencies] => Array
    (
      [config] => Array
      (
        (...)
        [16] => paragraphs.paragraphs_type.post_home
        (...)
      )
      [module] => Array
      (
        [0] => entity_reference_revisions
      )
    )
    [id] => paragraph.layer.field_liste_de_composants
    [field_name] => field_liste_de_composants
    [entity_type] => paragraph
    [bundle] => layer
    [label] => Liste de composants
    [description] => 
    [required] => 
    [translatable] => 
    [default_value] => Array()
    [default_value_callback] => 
    [settings] => Array
    (
      [handler] => default:paragraph
      [handler_settings] => Array
      (
        [negate] => 0
        [target_bundles] => Array
        (
          (...)
          [post_home] => post_home
          (...)
        )
        [target_bundles_drag_drop] => Array
        (
          (...)
          [post_home] => Array
          (
            [enabled] => 1
            [weight] => 87
          )
          (...)
        )
      )
      [field_type] => entity_reference_revisions
    )
  )
)

However, there's no $id in web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php, function doLoadMultiple() line 189 :

$id = 
$this->idKey = id
$ids = Array
(
  [0] => paragraph.layer.field_liste_de_composants
)
$names = Array
(
  [0] => field.field.paragraph.layer.field_liste_de_composants
)

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

aubjr_drupal’s picture

aubjr_drupal commented

If you don't know which config settings are causing the issue (I ran into this when trying to uninstall a config-related module), try a join query (like below). It'll point out what config entries aren't being rebuilt in cache_config.

SELECT cc.cid, c.name FROM `config` c LEFT JOIN `cache_config` cc ON cc.cid = c.name WHERE cc.cid IS NULL and c.name LIKE 'field.field.%';

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Version: 8.9.x-dev » 9.2.x-dev

On Drupal 8.9.x, only security issues are fixed.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented
Issue tags: +Bug Smash Initiative, +Needs steps to reproduce

As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" almost 4 years ago.

Since that time, several comments indicate that this may be an issue that can be reproduced but we still need concrete steps to reproduce that start with a vanilla Drupal install.

Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" many years ago.

Since there was no additional information provided since it was requested last year, I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active" [or "Needs Work" if it has a patch, etc.].

Thanks!