Updated: Comment #N

Problem/Motivation

All field with field types provided by core (core/lib/Drupal/Core/Field/Plugin/Field/FieldType) are gone after cache rebuild.

Steps to reproduce

- Create a Entity Reference Field (field_foo)
- Goto admin/config/development/performance and clear the cache
- Go back to the "Manage fields" of the entity type
- The Entity Reference Field is not visible

I did some debugging and found the root cause of this problem.

The field.field.node.field_foo.yml file contains to wrong properties.

- module: Core
- active: false

During cache rebuild the field_sync_field_status() function is called. field_sync_field_status() writes directly to CMI and disables the field because the field definition contains "provider = Core". Because the FieldItem class is provided by core. field_sync_field_status/() uses provider as module name and "Core" is no valid and loaded module.

All field types provieded by core have this problem. Its reproducible with boolean, date, email, ER, Float etc..

Proposed resolution

Remaining tasks

User interface changes

API changes

CommentFileSizeAuthor
#2 field-definition-provider-2131765-1.patch750 byteswebflo

Comments

webflo’s picture

webflo commented
Title: test » Fields are gone after field info rebuild
Component: file system » field system
Issue summary: View changes
Priority: Minor » Critical

Updated issue summary.

webflo’s picture

webflo commented
StatusFileSize
new field-definition-provider-2131765-1.patch750 bytes

Attached file. I use the following patch in my local env to fix entity reference fields.

dawehner’s picture

dawehner
Primary language German
commented

One problem is that field.views.inc relies kind of that you can execute hooks like that:

function field_views_data() {
  $data = array();
  $module_handler = \Drupal::moduleHandler();

  foreach (field_info_fields() as $field) {
    if (_field_views_is_sql_entity_type($field)) {
      $result = (array) $module_handler->invoke($field->module, 'field_views_data', array($field));
      if (empty($result)) {

This would limit us from being able to specify specific views integration for all "Core" fields. I know that at least entity references will certainly need one.

swentel’s picture

swentel commented

Interesting. Text module doesn't have the problem though ...

- edit - so yeah, and it's normal that this works fine since it doesn't extend on a field item from core ..

swentel’s picture

swentel commented

Related: #2115291: Field types must use as provider its own module instead of Core when are defined in hook_field_info_alter() - has the same patch as well, but doesn't solve it for all field types.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

It does now I think.

However, if we want to do #2052135: Determine how to deal with field types used in base fields in core entities, then we should probably make Core a valid special case of being always active (I think the active stuff is going anyway?).

Note that I really think there shouldn't be "Core" (because that's not a component), instead, I'd like to have something like "core.field", or "core/field" or something like that. Maybe we can already consider that, or at least have a test that will make sure that we have to update this..

swentel’s picture

swentel commented

Also related: #1503314: Remove the concept of active / inactive (field types, storage) from Field API which would make this a non problem.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

I just committed [##2115291].

Don't think we should make 'Core' a special-case, better to not rely on that as much as possible.

Between that and removing inactive, I think we can mark this duplicate. But please re-open if I missed something.