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
Comment #2
claudiu.cristeaPatch.
Comment #3
claudiu.cristeaComment #4
claudiu.cristeaIS update.
Comment #5
larowlanI 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.
Comment #6
claudiu.cristea@larowlan, In my case
Views::viewsData()->get('taxonomy_index')returns an empty array because we've suppressed generating views data for this entity type inhook_entity_type_alter():$entity_types['taxonomy_term']->setHandlerClass('views_data', NULL);.But the
taxonomy_indextable has astickyfield, coming from the view YAML (view:views.view.taxonomy_term).Comment #7
claudiu.cristeaAnd this is a regression as it never happened before 8.6.x.
Comment #8
jhedstrom@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?
Comment #9
claudiu.cristeaNever thought that I will write a test for such a bug :)
Comment #10
claudiu.cristeaFull patch. The interdiff is the patch from #9.
Comment #13
claudiu.cristeaNo, using the existing
datetime_test.modulewas a bad idea. Created a new testing module.Comment #15
jhedstromThis looks great to me! Just one small issue with the test:
This reliably reproduces the issue, but IIRC, all tests should have at least one assertion or they will cause issues with the
beStrictAboutTestsThatDoNotTestAnythingwe specify inphpunit.xml.dist(oddly this is set to true, but I think therun-tests.shscript ignores it).So perhaps simply asserting the return value of the save call or something?
Comment #16
claudiu.cristeahere's the assertion.
Comment #17
jhedstromThanks for the fix and the test!
Comment #18
alexpottI think we should avoid the assignment in the condition. Let's do a continue instead so something like...
Comment #19
alexpotttest methods usually have a more descriptive name.
Comment #20
claudiu.cristeaOK, even I like assignments in conditions :)
Comment #21
oriol_e9gWorks, with tests and comments addressed.
Comment #22
alexpottCommitted and pushed 687c6ec32d to 8.7.x and a7983d5146 to 8.6.x. Thanks!