Saving views fails when importing a finder from config.

  foreach ($bundles_names as $bundle) {
    $fields[$bundle] = FieldConfig::loadByName($entity_type->id(), $bundle, $field_name);
  }

This looks like Views getting tripped up by bundle fields.

I have to say, I probably didn't check my local dev copy for log errors!

(Another reason why we need Kernel tests to fail on log errors!)

I wonder why this is only complaining for finders_events_date, and not for the other bundle fields the Finder is defining.

I only get this error when I first install the module.

Could you give me steps to reproduce it without doing that? I've tried deleting the view and then importing earlier-exported config and there's no error with that.

NM, my breakpoint fired when I loaded the finder edit form.

In the backtrace we have date_recur_field_views_data().
That calls datetime_range_field_views_data(), because date_recur fields sort of inherit from datetime_range fields.
We end up in datetime_type_field_views_data_helper().
That calls views_field_default_views_data().

This is all for the field finders_events_date -- a bundle field!!

Which has me wondering how the hell a field storage config entity is there for a bundle field that's in code.

Aaaaand... the culprit is... Finders Events:

    // Invoke hook_field_views_data() directly on date_recur module with our
    // dummy field storage config entity, so we can use that as the views data
    // for our bundle field.
    $data = $module_handler->invoke('date_recur', 'field_views_data', [$dummy_field_storage_config]);

It's me being too clever. Not sure how tests didn't pick this up!!

My comment at the time says:

    // Declare our event bundle field to Views ourselves, as core doesn't
    // declare bundle fields to Views, and Date Recur module's Views support
    // complains if it's not there.

and without the hack, we get this error instead:

> Warning: foreach() argument must be of type array|object, null given in Drupal\date_recur\DateRecurViewsHooks->viewsDataAlter() (line 191 of modules/contrib/date_recur/src/DateRecurViewsHooks.php).

So, the problem is that one the one hand, DateRecurViewsHooks::getDateRecurFields() loads all date_recur fields using the field definition API. That gets you code AND config fields.

But views_field_default_views_data() is working with config fields only.

The two areas of code are disagreeing about what they're doing.

Ultimately, we don't massively care about these fields getting declared to Views, since our Views support goes via SearchAPI.

Our options are:

- fix the bugs in core. Not easy to do -- this touches on 🐛 [PP-1] bundleFieldDefinitions() are not added in EntityViewsData Needs work and 📌 Allow @FieldType to customize views data Needs work
- fix the bug in date_recur. It's getting *all* field definitions and passing them on to a system which expects only config fields. I suspect the checks for BaseFieldDefinition are the problem
- decorate DateRecurViewsHooks to wrap getDateRecurFields() and remove the bundle field

My hunch about the BaseFieldDefinition check in date_recur was right, and so fixing that to not produce a warning is the simplest fix.

Therefore, I am:

- removing the Views data workaround in this module, which means a views data rebuild causes a warning
- fixing 🐛 views data doesn't work with bundle fields and produces a warning Active in date_recur
- adding a note to the README about needing the patch to prevent the warning

LocalGov Events should add the patch to its composer.json -- off to file an issue for that.

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