Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The docs say:
* You can refine the behavior of filters by setting the following Boolean
* member variables to TRUE in your plugin class:
* - $alwaysMultiple: Disable the possibility of forcing a single value.
* - $no_operator: Disable the possibility of using operators.
and:
/**
* @var bool
* Disable the possibility to use operators.
*/
public $no_operator = FALSE;
However, the only place where this variable is checked is in showValueForm(), which only adds some wrapping HTML:
if (empty($this->no_operator)) {
$form['value']['#prefix'] = '<div class="views-group-box views-right-70">' . (isset($form['value']['#prefix']) ? $form['value']['#prefix'] : '');
$form['value']['#suffix'] = (isset($form['value']['#suffix']) ? $form['value']['#suffix'] : '') . '</div>';
}
Furthermore, when the filter is exposed, the wrapping HTML is clobbered by showExposeForm().
Comment | File | Size | Author |
---|---|---|---|
#20 | 2869191-nr-bot.txt | 144 bytes | needs-review-queue-bot |
#15 | 2869191-15.patch | 3.67 KB | Lendude |
#15 | interdiff-2869191-11-15.txt | 2.63 KB | Lendude |
#11 | 2869191-11.patch | 2.17 KB | Lendude |
Comments
Comment #11
LendudeAs far as I can tell, this only makes sure that there is room made to show the operators in the dialog, so you don't have your other options floating on the right of the dialog.
Frankly, who cares. Let's get rid of this.
It is only used in core by the history filter and it serves no purpose there since both the left and right blocks are empty in that case.
On the off chance that somebody is actually using this, their filter options will now have some extra white space on the left in the Views UI filter dialog.
If we decide that this is a way to go, we will need to add a CR and update the @see statements, and add deprecation testing.
Comment #12
joachim CreditAttribution: joachim at Factorial GmbH commentedLGTM.
Comment #13
LendudeQuoting myself:
I think we need to do a little more work if we want to go this route, but I'll take your RTBC as a +1 ;)
Comment #14
LendudeAdded a CR, I'll update the patch, see https://www.drupal.org/node/3281125
Comment #15
LendudeNow with the right CR referenced and a deprecation test.
Comment #16
joachim CreditAttribution: joachim at Factorial GmbH commentedCan you check how other parts of core do this? A separate @see is rendered on the API site as a separate paragraph, so it's not clear it's about the deprecation. I've filed an issue about it in coding standards.
CR looks good, but could maybe say we've removed it because it's unused in core?
Comment #18
Lendude@joachim thanks for the review. Added a line about it being unused in core to the CR.
Did another quick find on 'deprecated in drupal:9.4.0' in core and all of them use the @see on a separate line, so that does seem like the current standard, but I get your point, so lets see what comes out of the coding standards issue!
Comment #20
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.