I think I found the culprit. I have a visibility group with multiple OR conditions (Only one condition must pass). One of those conditions is by Content type. Obviously, if a page is NOT a node page, the condition cannot be evaluated for lack of context (no node) and this raises an error. But the following logic very cleverly ignores the error under certain conditions, so basically if you can't evaluate the Content Type of a non-existent node just return false and go on.
QUESTION: do we need to log the context error if the following code decides to ignore it and goes on as if nothing's happened which totally suits the site developer? Maybe only log the errors we can't ignore?
Finally, do we really need to log those particular errors? #3006822 does not give any rationale behind the change, and the error message as it exists (stack trace) is of zero use when debugging - it does not even mention the specific group or condition where error occured.
I looked into the code and it seems like the only relevant thing that changed from 2.0.1 to 2.0.2 is the addition of error logging (src/GroupEvaluator.php lines #96). So basically it looks like the errors have always been there, but just had not been logged until 2.0.2.
I don't think Major priority is justified (changed to Normal) here but someone should look into this.
I updated to 2.0.2 and I can confirm that my dblog is now flooded with similar messages:
Drupal\Component\Plugin\Exception\MissingValueContextException: Required contexts without a value: node in /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php:150 Stack trace: #0 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/modules/contrib/block_visibility_groups/src/GroupEvaluator.php(91): Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() #1 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/modules/contrib/block_visibility_groups/src/GroupEvaluator.php(64): Drupal\block_visibility_groups\GroupEvaluator->applyContexts() #2 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/modules/contrib/block_visibility_groups/src/Plugin/Condition/ConditionGroup.php(69): Drupal\block_visibility_groups\GroupEvaluator->evaluateGroup() #3 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Condition/ConditionManager.php(77): Drupal\block_visibility_groups\Plugin\Condition\ConditionGroup->evaluate() #4 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Condition/ConditionPluginBase.php(84): Drupal\Core\Condition\ConditionManager->execute() #5 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Condition/ConditionAccessResolverTrait.php(26): Drupal\Core\Condition\ConditionPluginBase->execute() #6 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/modules/block/src/BlockAccessControlHandler.php(116): Drupal\block\BlockAccessControlHandler->resolveConditions() #7 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php(105): Drupal\block\BlockAccessControlHandler->checkAccess() #8 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Entity/EntityBase.php(314): Drupal\Core\Entity\EntityAccessControlHandler->access() #9 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/modules/block/src/BlockRepository.php(63): Drupal\Core\Entity\EntityBase->access() #10 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/modules/block/src/Plugin/DisplayVariant/BlockPageVariant.php(137): Drupal\block\BlockRepository->getVisibleBlocksPerRegion() #11 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(274): Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() #12 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(132): Drupal\Core\Render\MainContent\HtmlRenderer->prepare() #13 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() #14 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() #15 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func() #16 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/vendor/symfony/http-kernel/HttpKernel.php(174): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() #17 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw() #18 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle() #19 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle() #20 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\Core\StackMiddleware\KernelPreHandle->handle() #21 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle() #22 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() #23 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() #24 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle() #25 /home/756170.cloudwaysapps.com/sbuhwewygh/public_html/web/index.php(19): Drupal\Core\DrupalKernel->handle() #26 @main
Even though it's logged as an error, I don't see any blocks missing from the affected pages or any blocks that should not be there. The problem seems to be just with errors flooding the log.
Patch #19 works fine for me, can't tell for others. Could this possibly create problems if the same view is used with or without arguments and the sorting order should be different?
The hierarchy setting introduced in #2867348 and committed to 2.1.4 seems to have solved the problem - all that's needed is tick the Enable hierarchy box in the Draggableviews field settiings. Can be closed I guess.
Isn't the problem just that records with '[]' are faulty and should be deleted?
Nope. The legacy records with '[]' work fine with new module version and views created earlier. If you simply delete them, you will lose the order set by draggable views. The problems only start if you open an old view for editing and save it. That's when a duplicate set of records is created with args set to actual args but the old records with '[]' are not removed creating the confusion.That's when it's a good time to remove legacy records for this specific view.
This should actually be just an update hook to resave the items to the new structure instead of adding code that is not needed anymore afterwards?
@tim-diels: The problem here is that when looping through all records in an update hook out of view context, you have no way of knowing what the view args were when the record was saved.
Shouldn't the description on the module page be corrected accordingly? I see some people confused over the requirement present in the module description but not in the module code anymore.
@dqd, thank you for your resolution - it works fine. In my case it seemed easier to export whole configuration first, grep for affected files, fix them and then import only affected files one by one.
@brenk28, the patch did not work for me (core 9.5.11) - the default value still not saved. Eventually I bit the bullet and switched to Entity Prepopulate module which does not have this (and other) problems.
@kostyashupenko, the core developers clearly don't agree that this is an issue. And with a contrib workaround available - https://www.drupal.org/project/views_random_seed → - who cares?
@dww,
I'm reluctant to add Yet More Permissions(tm) to solve this. Seems more like a widgetselection plugin setting to me (e.g. a "[x] Include unpublished entities the user has access to view" checkbox or something).
If we absolutely can't just change the existing [unexpected and undesired] behavior, then I think a widget setting is a very good idea. Because it will allow to override the default behavior on an individual field level, not on a site level. Who know, maybe someone will need different behavior in different parts of the same site?