UI fatal caused by views argument handlers no longer can provide their own default argument handling

Here's the same patch as #183, with fixed tests.

After some investigation, I can confirm the following:

• I applied the patch #183/#184 to D9.5 => no error when submiting the ajax form
• I spun-off a vanilla D9.5 (aka without the patch) => error when submitting the ajax form

So I assume the patch works, I just don't know why the tests which are exactly the same as #169 don't work anymore.

Hello,
We were using the patch on #169 🐛 UI fatal caused by views argument handlers no longer can provide their own default argument handling Needs work and we could not apply it when updating to Drupal 9.5.

So I'm adding a re-roll of #169 to apply cleanly on 9.5.x in case is useful

ok, so... I think I've found the issue with the tests failing. The test fails because the view is never loaded.

Both tests, the one for the plugin at core/modules/views/tests/src/Functional/Plugin/ArgumentDefaultTest.php AND the one for node module at core/modules/node/tests/src/Functional/Views/DateArgumentDefaultTest.php are trying to use the same view wih id test_argument_default_date the problem is the view itself, the config for it, is added on the views_test_config test module.

If you look at the DateArgumentDefaultTest setUp method, is using a different test module: node_test_views which does not provide the expected view and then of course it fails to load it.

Now I'm really not sure if we should either:

1. Duplicate the view config, and add it to the node_test_views module.
2. Or try to re-utilize the view from the views_test_config module.

For the second option (which seemed better so we do not duplicate a view config in a different directory) I've tried to load that module in the DateArgumentDefaultTest setUp method, something like:

  protected function setUp($import_test_views = TRUE, $modules = ['views_test_config']): void {
    parent::setUp($import_test_views, $modules);

but I've got:

1) Drupal\Tests\node\Functional\Views\DateArgumentDefaultTest::testArgumentDefaultNodeCreated
Drupal\Core\Entity\EntityStorageException: 'view' entity with ID 'test_argument_default_date' already exists.

/var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php:553
/var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php:517
/var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php:253
/var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php:339
/var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php:608
/var/www/html/web/core/modules/views/src/Tests/ViewTestData.php:52
/var/www/html/web/core/modules/views/tests/src/Functional/ViewTestBase.php:49
/var/www/html/web/core/modules/node/tests/src/Functional/Views/NodeTestBase.php:21
/var/www/html/web/core/modules/node/tests/src/Functional/Views/DateArgumentDefaultTest.php:78
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:703

So now I'm trying the other approach, but it really doesn't seem like a good idea.
If anyone here could provide some input on this, it would be great :)

Thanks,

Mariana

Changing to "needs review" since a MR was provided applying most of the requested changes from last review.

Also in here I'm adding the re-rolled patch for 9.5.x that hopefully now passes the tests...

Verified the issue on D10.1 with a standard install following the steps in the issue summary.
Applying MR 3751 fixes the issue

Question for committer will new default value require upgrade paths? Imagine since this was a fatal error and no one could use the functionality the answer is no but want to make sure.

Tried to clean things up a bit.
Started by removing all patches now there is an MR.

Then assigned credits
Removed credits for simply rerolling

It looks like from #157 that this didn't work for datetime range fields?

Adding needs followups tag for #114 and #176

Updated the issue summary after reading all the comments 😩

Reviewing code next.

Left a review on the MR, thanks

Did the constructor property promotion stuff, added some questions, going to look at using a base class or trait which sounds like a good idea

Think I got everything, lets see if it stays green

Can the MR be updated for 11.x
Currently doesn't apply.

Even after applying the patch, views timestamp_formatter postupdate fails. We are trying to upgrade the site from 9.5 to 10.1.

Adding MR !3751 with the latest commit 3b362cc8 as a patch.

Thank you! This patch fixed the updb error. But I am getting this error "Drupal\Core\Entity\Query\QueryException: Entity queries must explicitly set whether the query should be access checked or not. See Drupal\Core\Entity\Query\QueryInterface::accessCheck(). in Drupal\Core\Entity\Query\Sql\Query->prepare() (line 141 of /app/web/core/lib/Drupal/Core/Entity/Query/Sql/Query.php)" when I load any page. Admins pages are working fine. Any idea on what's causing this error? I couldn't figure out what's causing this. Any help would be appreciated

@irsar, what @smustgrave said in #196. I'm also trying to figure out if there's a version I can use for the latest D10.

I am having trouble after updating to Drupal 10

When running the update script I get:

views module
Update timestamp_formatter
Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "calendar" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: calendar_week, calendar_month, fullcalendar_view_display, unformatted_summary, default_summary, grid_responsive, opml, grid, default, table, rss, html_list, entity_reference, blazy in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /home/lhvxidmy/public_html/rise/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I have tried removing and reinstalling the Calendar and Calendar_View Modules
I have tried uninstalling both as they are not used.
The Calendar View module will uninstall but the Calendar module will not with the following error:

The website encountered an unexpected error. Try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "calendar" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: calendar_week, calendar_month, fullcalendar_view_display, unformatted_summary, default_summary, grid_responsive, opml, grid, default, table, rss, html_list, entity_reference, blazy in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('calendar') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('calendar', Array) (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance('calendar') (Line: 821)
Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('style') (Line: 897)
Drupal\views\ViewExecutable->initStyle() (Line: 877)
Drupal\views\ViewExecutable->getStyle() (Line: 476)
Drupal\views\Plugin\views\field\FieldPluginBase->defineOptions() (Line: 372)
Drupal\views\Plugin\views\field\EntityField->defineOptions() (Line: 143)
Drupal\views\Plugin\views\PluginBase->init(Object, Object, Array) (Line: 109)
Drupal\views\Plugin\views\HandlerBase->init(Object, Object, Array) (Line: 136)
Drupal\views\Plugin\views\field\FieldPluginBase->init(Object, Object, Array) (Line: 199)
Drupal\views\Plugin\views\field\EntityField->init(Object, Object, Array) (Line: 899)
Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers('field') (Line: 510)
Drupal\views\Entity\View->onDependencyRemoval(Array) (Line: 479)
Drupal\Core\Config\ConfigManager->callOnDependencyRemoval(Object, Array, 'module', Array) (Line: 342)
Drupal\Core\Config\ConfigManager->getConfigEntitiesToChangeOnDependencyRemoval('module', Array) (Line: 43)
Drupal\system\Form\ModulesUninstallConfirmForm->addDependencyListsToForm(Array, 'module', Array, Object, Object) (Line: 160)
Drupal\system\Form\ModulesUninstallConfirmForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('system_modules_uninstall_confirm_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The site seems to work fine however I can not remove these errors.
I applied this patch with no effect on the errors.
I may be in the wrong place altogether. Any advice would be much appreciated.

Patch on fork

3751.patch

Tested ok drupal 11 and work fine.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Upon updating to Drupal 10.2.5, it became evident that the current patch ( https://www.drupal.org/project/drupal/issues/2325899#comment-14900128 🐛 UI fatal caused by views argument handlers no longer can provide their own default argument handling Needs work ) was no longer compatible. In response, I have refined the patch code to ensure its compatibility with the latest Drupal version, 10.2.5. My objective is to make this revised code advantageous for individuals utilizing Drupal 10.2.5 and in need of this particular functionality.

Drupal : 10.2.5
php: 8.2.15

@foodslover is there an interdiff?

I tried to reroll the merge request for drupal 10.2 but I'm not sure of the correct workflow, especially since the current merge request is based on the 10.1 branch.

Here is the commit I made: https://git.drupalcode.org/issue/drupal-2325899/-/commit/d665b876f6c1ab2...

And I'm attaching a patch which should hopefully work on 10.2.6

I applied #210 to 10.2.5 and my affected view allowed me to save without white screening in addition to adding and removing the date contextual filter.

I then updated to 10.2.6 and was able to do the same tests as I did for 10.2.5 without running into any issues.

Rerolled the patch against 10.3.x and pushed up a branch to the issue fork. Also added a static patch here

Confirm #213 worked!

#213 did not resolve the "The "date" plugin does not exist." error in my clean Drupal 10.4.0 install. I am still unable to select 'Current date' as the default for a contextual filter.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "date" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: node, taxonomy_tid, user, current_user, raw, query_parameter, fixed in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /code/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Adding credit for the triage as per @cilefen in #64.

I rerolled, diffed the diffs after — no changes other than context lines (and index hashes). And diffed the MR 3751 against #213 🐛 UI fatal caused by views argument handlers no longer can provide their own default argument handling Needs work

Trying to help this along... next I plan to review the unresolved comments, so leaving as Needs Work.

I will hide the other MRs to keep the focus on that one.

joelpittet → changed the visibility of the branch 2325899-10.3.x-refactor to hidden.