Add Tag to Filter Query in admin/content/node

nice thanks
any chance you could add the code you used to add the filter in hook_form_alter too please?
And how did you make the new filter go in Session $_SESSION['node_overview_filter_ext'] ?

I can't get the added filter to bring value in hook_query_alter.

1. please remove line SPACE :)
2. against D8.x and backport

Sorry?

bot is happy.RTBC

subscribe

Fixing tag.

Sounds like a reasonable use case to me. But before proceeding with this, I'd love to get a sanity-check from one of the database system maintainers about the usage of the DB tag system here and whether it's appropriate: chx, crell, DamZ, etc. I could see this opening a can of worms a bit by creating inconsistency around developer expectations on what sorts of queries get tags, and what tags those are.

Incidentally, another approach to this is hook_menu_alter() and just replace the page callback with one of your own devising. Views effectively does this to completely override the page output with its own stuff.

Thanks for the suggestion webchick, i guess i will do what i want with views,till this gets committed (and if)

I have marked #1244504: Add drupal_alter to node_filters() and provide for query_alter to react to those filters as a duplicate. This patch added the query tag and introduced a new filter alter hook (which is a duplicate of #450666: Filter DB Extender).

Love to get this into the next release. Could someone ping "chx, crell, DamZ, etc" to push this forward?

Without patching core, this was my current workaround (which shows how unstable things are if you are not overriding the entire page callback / form):

function HOOK_query_alter(QueryAlterableInterface $query) {
  // Only run on this page
  if (arg(0) != 'admin' || arg(1) != 'content' || arg(2) != 'node') {
    return;
  }
  // Lets see if the node is the base table
  $node = FALSE;
  foreach ($query->getTables() as $alias => $table) {
    if ($table['table'] == 'node') {
      $node = $alias;
    }
  }
  // Of the 3 queries running on a clean 7 theme (no additional blocks), the filter form is the only one that is untagged.
  if ($node && empty($query->alterTags)) {
    // Alter the query - finger crossed we are not restricting other functionality!
  }
}

Ignore, this found the answer.

@Reg [Edited for context] Regarding the usage of this tag. This is only really visible via the hook_query_alter() and hook_query_node_access_alter(). It is a tag that is hard coded so that module coders can filter the results based on this.

You replied faster than I could revoke the question. Thanks. I was just reading through all the links in the post and came across what you mentioned.

I see two issues here. First is making the filters extensible on the content management page, the 2nd is having a "tag filter" on the same page.

I think there is no question that it would be useful to have filtering on this page extensible so that has my vote.

The issue of specifically adding a tag filter I think is a little more involved and I would like to see that particular filter added to the core. The reason being is that when I first started using D7 not too long ago I came across a Content Type ("Article" I think) that had tagging already on it "out of the box". I saw value to that and started using the tagging almost immediately. However when I went to the Content Management page I saw no way of identifying those tagged pages with the existing filters. So the Content Management page doesn't adequately reflect what is being given "out of the box" which needs to be properly addressed as well.

Ultimately, we ended up carefully naming the pages so we could tell what was tagged with what... which is tagging the same page in two different ways for the same thing... and that makes no sense for anything except what it was, a workaround.

Re: #0 & #12, since hook_query_alter() can be used for any query I would probably structure the code something like this:

Assuming you put the code in a module called "tweaks", otherwise change tweaks to your module's name:

/**
 * Implementation of HOOK_query_alter()
 */
function tweaks_query_alter(QueryAlterableInterface $query) {
  switch (TRUE) {
    case $query->hasTag('node_admin_filter'):
      tweaks_node_admin_filter($query);
//    break; //Uncomment when you get additional cases.
  }
}

/**
 * Alter the query on the Content Management form
 */
function tweaks_node_admin_filter(QueryAlterableInterface $query) {

}

This way the structure of your code cleanly reflects the catchall nature of the hook. Of course if you are creating a module to only extend the query form and nothing else then the case statement calling a separate function is overkill in which case probably just ignore this.

@Reg: you could implement directly hook_query_TAG_alter

I presume that this issue is no longer relevant for Drupal 8, as the content page is now a View and can be altered in the standard Views ways.

The patch in #5 still applies for Drupal 7. Do we need a test for it?

The content page isn't a view in Drupal 8 unless the Views module is turned on, as far as I know (i.e. same as Drupal 7) but I think the difference is that the fallback page doesn't have filters. If so, there's nothing really equivalent to the problem described in this issue, and the page is generated by a totally different entity-listing method anyway so it would be altered in a different way.

We don't need a test for adding a tag. And @webchick's comment in #8 was more than two and a half years ago, so if anyone wanted to complain about this use of tags they've had plenty of time :) (Personally, I think it's OK, but maybe I'm biased because I've run into a problem very similar to this one in the past.)

Given that, I committed this to 7.x - thanks!