If computed view argument is empty the default value or action is not used

I am reopening this issue because it differs from Drupal issue #3027640 🐛 Empty strings ("") passed in as contextual filter argument aren't considered missing Needs work , which addresses passing empty values to views arguments in general. This issue specifically concerns the default value not being applied when the value is empty, as described.

The patches provided in the other issue do not resolve this one. I have attached a patch that specifically addresses this issue.

To clarify, if you have a URL like /search?keywords= and a fallback set in the views exposed form, the current getArgument() method in the QueryParameter class does not consider a key/value pair without a value as empty, and therefore does not use the default value.

The RFC 3986 does not specify whether key/value pairs in the URL query without a value should be processed by consumers. However, \Symfony\Component\HttpFoundation\Request does include query parameters without values in its array, which are later used in views to check the presence of each parameter.

In this context, when the exposed filter states "The fallback value to use when the above query parameter is not present," the term "present" could mean either that "the parameter key" is present or that "both the key and value" are present.

I believe the option is intended to set a default value when no value is provided. Therefore, a query string parameter without a value should be considered "not present" in this case.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

All fixes should be in an MR please.

Most likely will need test coverage too to show the issue.

manibharathi ezhimalai ravi → made their first commit to this issue’s fork.

Hi,
MR has been created !9584 for the changes. Testcases also passed in the pipeline. Let me know incase of any new changes needs to be add.

Hi,

MR has been created !10005(https://git.drupalcode.org/project/drupal/-/merge_requests/10005).

Written testcase as per requirement. Please let me know incase of any new changes needs to be add.

Thanks!

Why start a new MR when 9584 is pointing to the right branch?

oily → changed the visibility of the branch 2937759-if-computed-view to hidden.

Hiding MR 9584 because MR 10005 is now 'where the action is'.

The test coverage in 10005 is not adequate because manually running the 'test-only' test passes whereas it should fail.

It needs to be discovered whether the test passes because the issue is now fixed or the test is wrong.

There is now a failing test that turns green. Changing status to 'Needs review.'

Remove 'Needs tests' tag.

smustgrave → closed merge request !9584

Left a small comment on the MR about test coverage expansion.