Note: I filled this under datetime.module as there's no datetime_range.module component yet.

Problem/Motivation

In our project we're swapping the taxonomy_term entity storage and we're not providing any views data:

function somemodule_entity_type_alter(array &$entity_types) {
  $entity_types['taxonomy_term']->setStorageClass(TermCustomStorage::class);
  $entity_types['taxonomy_term']->setHandlerClass('views_data', NULL);
}

But in datetime_range_view_presave() is assuming that everytime the views data is present. This is breaking out tests when the views are imported:

Undefined index: sticky

web/core/modules/datetime_range/datetime_range.module:133
web/core/lib/Drupal/Core/Extension/ModuleHandler.php:403
web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php:347

The error appeared in 8.6.x, specifically in #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields

Proposed resolution

Check first if views data exists.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

claudiu.cristea created an issue. See original summary.

claudiu.cristea’s picture

Issue summary: View changes
StatusFileSize
new1.76 KB

Patch.

claudiu.cristea’s picture

Status: Active » Needs review
claudiu.cristea’s picture

Issue summary: View changes

IS update.

larowlan’s picture

I had a failing test for this too, same line but different field.

In my case the test view referenced a field that didn't exist in the test.

Can you check you view's yaml to see if it is in same boat?

In my case, creating the field in the test setup resolved it.

claudiu.cristea’s picture

@larowlan, In my case Views::viewsData()->get('taxonomy_index') returns an empty array because we've suppressed generating views data for this entity type in hook_entity_type_alter(): $entity_types['taxonomy_term']->setHandlerClass('views_data', NULL);.

But the taxonomy_index table has a sticky field, coming from the view YAML (view: views.view.taxonomy_term).

claudiu.cristea’s picture

Title: Check first if views data exists in datetime_range module » [regression] Check first if views data exists in datetime_range module
Issue tags: +Regression

And this is a regression as it never happened before 8.6.x.

jhedstrom’s picture

@claudiu.cristea any chance that something similar to your alter hook could be added to a to a test module so we could have test coverage to prevent future regressions?

claudiu.cristea’s picture

StatusFileSize
new2.22 KB

Never thought that I will write a test for such a bug :)

claudiu.cristea’s picture

StatusFileSize
new3.98 KB

Full patch. The interdiff is the patch from #9.

The last submitted patch, 9: 2995578-9.test_only.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 10: 2995578-10.patch, failed testing. View results

claudiu.cristea’s picture

Status: Needs work » Needs review
StatusFileSize
new2.82 KB
new2.08 KB
new4.58 KB

No, using the existing datetime_test.module was a bad idea. Created a new testing module.

The last submitted patch, 13: 2995578-13.test-only.patch, failed testing. View results

jhedstrom’s picture

This looks great to me! Just one small issue with the test:

+++ b/core/modules/datetime_range/tests/src/Kernel/Views/EntityTypeWithoutViewsDataTest.php
@@ -0,0 +1,43 @@
+    $view_yaml = drupal_get_path('module', 'taxonomy') . '/' . InstallStorage::CONFIG_OPTIONAL_DIRECTORY . '/views.view.taxonomy_term.yml';
+    $values = Yaml::decode(file_get_contents($view_yaml));
+    View::create($values)->save();

This reliably reproduces the issue, but IIRC, all tests should have at least one assertion or they will cause issues with the beStrictAboutTestsThatDoNotTestAnything we specify in phpunit.xml.dist (oddly this is set to true, but I think the run-tests.sh script ignores it).

So perhaps simply asserting the return value of the save call or something?

claudiu.cristea’s picture

StatusFileSize
new830 bytes
new4.61 KB

here's the assertion.

jhedstrom’s picture

Status: Needs review » Reviewed & tested by the community

Thanks for the fix and the test!

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/datetime_range/datetime_range.module
@@ -52,10 +52,10 @@ function datetime_range_view_presave(ViewEntityInterface $view) {
-        if ($filter['plugin_id'] === 'string') {
+        if ($filter['plugin_id'] === 'string' && $table_data = Views::viewsData()->get($filter['table'])) {
 
           // Get field config.
-          $filter_views_data = Views::viewsData()->get($filter['table'])[$filter['field']]['filter'];
+          $filter_views_data = $table_data[$filter['field']]['filter'];
           if (!isset($filter_views_data['entity_type']) || !isset($filter_views_data['field_name'])) {
             continue;
           }

@@ -127,10 +127,10 @@ function datetime_range_view_presave(ViewEntityInterface $view) {
-        if ($sort['plugin_id'] === 'standard') {
+        if ($sort['plugin_id'] === 'standard' && $table_data = Views::viewsData()->get($sort['table'])) {
 
           // Get field config.
-          $sort_views_data = Views::viewsData()->get($sort['table'])[$sort['field']]['sort'];
+          $sort_views_data = $table_data[$sort['field']]['sort'];
           if (!isset($sort_views_data['entity_type']) || !isset($sort_views_data['field_name'])) {
             continue;
           }

I think we should avoid the assignment in the condition. Let's do a continue instead so something like...

$table_data = Views::viewsData()->get($filter['table']);
if (!$table_data) {
  continue;
}
alexpott’s picture

+++ b/core/modules/datetime_range/tests/src/Kernel/Views/EntityTypeWithoutViewsDataTest.php
@@ -0,0 +1,43 @@
+  public function test() {

test methods usually have a more descriptive name.

claudiu.cristea’s picture

Status: Needs work » Needs review
StatusFileSize
new2.46 KB
new4.6 KB

OK, even I like assignments in conditions :)

oriol_e9g’s picture

Status: Needs review » Reviewed & tested by the community

Works, with tests and comments addressed.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed 687c6ec32d to 8.7.x and a7983d5146 to 8.6.x. Thanks!

  • alexpott committed 687c6ec on 8.7.x
    Issue #2995578 by claudiu.cristea, jhedstrom, alexpott: [regression]...

  • alexpott committed a7983d5 on 8.6.x
    Issue #2995578 by claudiu.cristea, jhedstrom, alexpott: [regression]...

Status: Fixed » Closed (fixed)

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