"Is Micro-content" filter has surprising behavior with non-micronode types

Whoa, there's actually more bugginess here. It looks like picking "Is not equal to" doesn't actually change the results.

When I set it to "!= Yes" it shows all my micronodes. When I did that and say "all the things" I had assumed I was seeing all the non-micronodes.

So there are at least two things that need fixing here.

First, we should treat the absence of micronode_is_microcontent the same way we treat FALSE.
Second, we need to either fix or remove the "Is not equal to" setting.

I just noticed this on the project page:

Views will only recognize nodes whose types have this flag at either TRUE or FALSE, but on existing types this will be NULL unless they are re-saved.

I got a bee in my bonnet and pushed something up for this one.

An install and update hook would probably be sufficient, but I also wanted to address the bug related to "Is not equal to" and generally try to improve the filter's UX.

The MR addresses the problem without an update hook. And here's what the form looks like afterwards.

Definitely clearer than it is now (and more functional) though I wouldn't claim to have picked the best wording possible.

Here's what it looks like now, for reference.

A little confusing. And the "Is not equal to" isn't functional.

Looks good to me, thank you for contributing!

This change seems to have significantly degraded view performance on our site with 14K+ content items.

After this update, the render time for our content admin view (100 items/page) went from a little over a second to over two minutes. Removing the "Is Micro-content" filter immediately restored previous performance.

I'm no expert in SQL queries, but maybe the updated where clause leads to issues at scale? I'll try to investigate more as time allows.

I'm no expert in SQL queries, but maybe the updated where clause leads to issues at scale?

Neither am I, though as I was making this change I did worry that "NOT LIKE" was going to be slower than "LIKE". I was hoping that worry was unfounded but perhaps I was right to be concerned.

Since I'm kind of nuts I had been thinking about how to rework this filter even before the comment from @justcaldwell. It occurred to me that it might make sense to copy off of whatever the normal node type filter does in the query. We'd do a call to micronode_get_micronode_types or whatever to get the content types we need to include. I'm not sure if xtending that filter makes sense, given all the extra configuration options and stuff that filter has. Maybe though.

I updated the query method locally to query more like the bundle filter and I got the tests to pass:

  /**
   * {@inheritdoc}
   */
  public function query() {
    $this->ensureMyTable();
    $micronode_bundles = array_keys(micronode_get_node_types(TRUE));
    if ($this->value) {
      // Restrict to micronodes.
      if ($micronode_bundles) {
        $this->query->addWhere($this->options['group'], "$this->tableAlias.type", $micronode_bundles, 'IN');
      }
      else {
        // If there are no micronode bundles views should return nothing.
        // Modeled after Drupal\Core\Database\Query::alwaysFalse().
        $this->query->addWhereExpression($this->options['group'], '1 = 0');
      }
    }
    else {
      // Exclude micronodes.
      if ($micronode_bundles) {
        $this->query->addWhere($this->options['group'], "$this->tableAlias.type", $micronode_bundles, 'NOT IN');
      }
    }
  }

I'm trying to figure out the best way to push this up for a new MR.

Can we please open a new ticket for this and create the MR there?
@justcaldwell it would be great if you could compare the current fix with this new proposal and see if it solves the performance impact you are experiencing? Thanks!

That did the trick. I applied the patch and re-enabled the filter — performance is back on par with the previous release. Thanks for the quick response @danflanagan8! 🙏

I just created 🐛 Degraded query performance after "Is Micro-content" filter change Active . I'll create an MR using Dan's code in a bit.

Automatically closed - issue fixed for 2 weeks with no activity.