The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem. $form['value']['#options'] = [
1 => $this->t('Flagged'),
0 => $this->t('Not flagged'),
// @todo Find out what in the hell filter type ALL is supposed to do.
// 'All' => t('All'),
];
Haha... 'All' is there for the use case when this filter is exposed, and there are other exposed filters too, so you can combine them or not.
For example, if your filters are 'flagged' and 'published', the 'All' option allows you to show 'published' and 'unpublished' along with combinations such as 'flagged and published' or 'unflagged and unpublished'.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | flag-regression_all-2813503-13.patch | 1.66 KB | grimreaper |
| #3 | flag-all_option-2813503-3.patch | 1.57 KB | grimreaper |
Comments
Comment #2
morbus iffI believe the only reason to uncomment this line would be for defining the DEFAULT setting.
Currently, with it commented in -dev, if I define a single exposed filter that is NOT required, then "-Any-" will show up in the rendered select box. Selecting "-Any-" will show me all (entities, in my case nodes) regardless of whether they have been flagged or not. However, it doesn't appear that I can ever set "-Any-" as the default value (unless I switch over to a Grouped filter and force it there).
If I uncomment the line, however, I'll see "Any" show up as a "Status" and if I select that in the exposed filter, then it will be the default option in the rendered UI. Which, in the long run, feels like the right default choice for an exposed filter (if I'm new to a site and go to a View with this filter defaulting to "Flagged", I'll see no content at all, which would be hella confusing).
Whether this is the RIGHT way to add "All" (or "Any"), I'm not entirely sure.
Comment #3
grimreaperHello,
I encountered the same need to have multiple exposed filters on a view with a flag relationship and I don't want the view filtered by default.
Here is a patch that uncomment the lines.
Thanks for the review.
Comment #5
grimreaperYeah!!! Failing code sniffer tests on untouched parts of the file...
Comment #6
berdirThe coding errors are just for information that's not why it fails. It fails because there are test fails and a patch can't be committed when tests fail.
Comment #7
grimreaperOk. My bad.
I was focused on the "codesniffer_fixes.patch Interdiff of automated coding standards fixes only." of the error message I haven't seen it before.
Comment #8
grimreaperAfter some tests using simplytest.me:
The errors do not come from the patch, I will try to fix the tests.
Comment #9
grimreaperIt seems that the issue is known and the work is in progress in #2898502: Convert/Modernise FlagContextualLinksTest.
Comment #10
grimreaperBlocker issue as been fixed. Setting back to needs review.
Comment #12
socketwench commentedNeeds a reroll. :-(
Comment #13
grimreaperHere is a rerolled patch.
Comment #14
socketwench commentedMuch better. ^_^
Comment #16
socketwench commentedThanks everyone!