[meta] Search entities (nodes, terms, etc.) within the administrative interface

I can see two alternative ways of doing this:

• enable the Search module by default, and rely on the Search API to display those search boxes and their result. In order to do this properly, we want to refactor the search module into a Search API and a Core search indexer. That would enable those boxes to use alternative indexing engines (think: Apache Solr).
• implement those search boxes by direct queries, under the assumption that performance (and result relevance) is not really an issue here.

I strongly favor the first route. Input is appreciated on ways to make it happen ;)

First example:
Being able to search content on node title in admin/node/content

Does it need a full-text search to search the title?

Hint: I added an (as an example) autocomplete username search/filter field in my Filter proposal: #450666: Filter DB Extender. With my patch, it should be easy to do the same for admin/node/content and other listings in general. Oh, and that issue needs UI review too, but mikey_p and I thought that it would be better to get the technical backend commited first, and then think about a good UI. There are some ideas at http://groups.drupal.org/node/18008

Hint #2: Oh, and my current search.module DBTNG conversion #394182: DBTNG search.module would imho actually make it possible to use a generic search expression for that table. It would need to be more flexible, though. The Search Extender in its current form can only be used directly on the search_index table, but filtering the table on generic search query would need to make it possible to extend a db_select('node') object and automatically join all necessary tables. However, I have no idea if that would be performant. Actually, I'm pretty sure it would be slow ;)

@Berdir: as a generic rule of a thumb, never try to mix "select a list of object ids" and "retrieve the data associated to a those objects", as it is always inefficient (think: multiple SQL joins...).

The job of search is to retrieve object ids. It's up to the object-specific result page to complement those objects and to make actions possible on those.

I had a discussion about this with DamZ in #drupal, I'm trying to summarize how I understood it.

To do that in a generic way, with different search backends and performance in mind, we need to handle two cases:

Case A, No search module is available: We don't offer a search expression field and everything works pretty much as it is now (In the end, maybe there are different classes/workflows to get there, but it is a paged query with optional filters and it can be sorted with the TableSort Extender).

Case B, A search module is available: We display a search expression field and maybe more complex filters/whatever and pass *everything* to the search API. Including paging and sorting. The search api returns N object id's (for example, nid, uid, tid, ...) and we load these with a query, node_load_multiple/whatever and display them.

I still think that my linked issues above can help, but they both obviously need work (atleast the Filter). Or maybe two different Filter classes, one for case A and another for case B.

This reminded me of http://drupal.org/project/views_bulk_operations, would like to know what might be the differences?

#503982: Enable search module by default.

If we go for Damien's A, then taxonomy module needs a hook_search() I think. That's not necessarily a bad thing.

Reviving this issue: #601674: Index taxonomy terms in core search.

I think it'd look better like this

The main site search box relies on the nodes to be indexed, I believe. So, if you search for a node you just created 10 minutes ago and cron hasn't run, you won't find it.

Version attached that is ridiculously better than what we had (nothing), but could use a little interface love. The main thing I couldn't decide on was what to do with "Is" and otherwise what text to use.

Changes:
* Added Title search filter, which is very fast and searches just node titles
* Added "data" filter, which uses the core search module
* Changed radios to checkboxes, so you can select more than one at a time (needed minor css and jquery additions).

Unless there are bugs to fix I'm going to pass this off on someone else now, just wanted to give it a kick in the pants (it's super important). Functional but ugly > no search, even if we had to release D7 this way.

For D8 I'd like to rewrite this to be hookable. Right now there's no way for a module to expand on it by adding new filters.

This seems like a great UX improvement. I found a number of problems while reviewing.

First, Coder picked up two spacing issues in node.admin.inc. There needs to be a space between "foreach" and "(" in two places.

Line 12: Control statements should have one space between the control keyword and opening parenthesis
      foreach($result as $node_result) {

Line 4: Control statements should have one space between the control keyword and opening parenthesis
      foreach($form_state['values']['filter'] as $filter) {

Next, after applying the patch, I get the following notice at admin/content:

Notice: Undefined index: options in node_filter_form() (line 205 of /drupal_testing/modules/node/node.admin.inc).

I was able to successfully filter by title.

However, when I tried to filter by data, it threw a SQL error. Search module was enabled when I attempted this.

# PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 2: SELECT COUNT(*) AS expression FROM {node} n INNER JOIN {users} u ON n.uid = u.uid WHERE (nid IN ()) ; Array ( )  in PagerDefault->execute() (line 86 of /drupal_testing/includes/pager.inc).

Thanks for the review!

New patch fixes all mentioned items, the existing tests were updated, and some new tests were added.

status

Missed a debug line.

I tested the patch and was able to search with search module enabled or disabled. The patch also passed Coder review.

While searching using the "title" or "data" textfield, I was able to search for a title and a title in addition to status, type, or term.

However, after initiating a title search, I received the following notice:

Notice: Undefined index: options in node_filter_form_submit() (line 296 of /Users/JuliaKM/workspace/personal/drupal_testing/modules/node/node.admin.inc).

This is because $filters[$filter]['options'] is empty since there is no select pull-down for a textfield. The following is throwing the error:

<?php
        if ((is_array($filters[$filter]['options']))) {
          // Flatten the options array to accommodate hierarchical/nested options.
             $flat_options = form_options_flatten($filters[$filter]['options']);
        }

To get around this, I added an if clause to check for the textfield. There's probably a more efficient way to do this check but I re-rolled the patch anyway.

<?php
      if ($filters[$filter]['type'] != 'textfield'){
        if ((is_array($filters[$filter]['options']))) {
          // Flatten the options array to accommodate hierarchical/nested options.
             $flat_options = form_options_flatten($filters[$filter]['options']);
        }
      }

Also, from a UX perspective, I'm not sure I understand why we have separate "title" and "data" searches. I think it might be preferable to merge these into one textbox with a title like "Text Search" and have the search only search titles when search module is disabled.

I guess I'll mark it as needs review even though we might run into the same exception as before.

Singly text field which does a full text search when the module is enabled, and title search only when it isn't, seems better than just a single search box. We should make sure it's not too hard for modules like apache solr to swap that out though.

I disagree about having only one text search. Searching on title only is typically both faster and less likely to have false positives / other undesirable results included than using the search module because of the restricted domain. Much more importantly, title search will find nodes that search cannot because they haven't been indexed yet.

I haven't tested it with SOLR, and although support for that needs to go in at some point, it definitely can be added later. It shouldn't hold up the base case getting committed.

Cleaned up the new if block from JuliaKM a little and added another check that would avoid an error on enable search -> do data search -> disable search module without clearing session.

if ($filters[$filter]['type'] == 'select' && is_array($filters[$filter]['options'])) {

// Avoid errors when there is session data but the module is disabled.
if (!module_exists('search')) {
  break;
}

This was working and passing tests, but the commits of #551034: Find Content filter accessibility and #602522: Links in renderable arrays and forms (e.g. "Operations") are not alterable will mean a significant rewrite for the patch.

subscribe

I haven't had time to get back to this yet, but my plan is to just turn it into a contrib module for D7. Not having an appropriate admin node search is driving me batty.

did some work :
http://drupal.org/project/ext_search_page

Coming here from #1279652: Add title search feature on the node listing admin page, which Bojhan marked as duplicate. I'm not sure it is duplicate, since (a) the multilingual initiative use case is to be able to search in the whole search index, not just title; title is very limiting (a) this issue is about entities in general, which core search does not work with generally (ie. does core search let you search for comments or taxonomy ever?). We can merge that with this one, but I'm not seeing how this is going to happen for Drupal 8, given its such a very broad scope. What do people think about that?

@Bojhan: I don't see how this can be considered a general starting point for entity search support on admin pages. First off, entities are not required to have titles that I know (http://api.drupal.org/api/drupal/includes--common.inc/function/entity_la...), and second, this is so custom to nodes that I'm not sure of the way to generalize this. (Apart from it not fitting the D8MI use case I think).

Just adding more background info: The D7UX mock-up calls for both a search box in the admin interface, and redesigned filters. The latter are the subject of issue #355820: Improve query filter UI on admin/content , which could probably be fixed separately (first?).

So... Let's think about what this is for: to help content admins find the content that they want to review or edit, right?

In my experience setting up sites for clients, a title keyword is probably enough. That could easily be added to the filters on the node admin page without using the search module (I think title is still in the node table for d7? maybe not).

Other things that I've done on custom "find content to edit" pages for clients in the past few years:
- Taxonomy filter

Hm. Yeah, the title keyword and taxonomy term are the only things I've actually done, and so far the clients seem to be happy.... Gabor, is your experience different?

The D7UX mock-up also suggests filtering by author.

If we decide to not support full-text search, then clearly labeled search fields (for example "Title contains these words") will go a long way into taming user expectations.

@jhodgdon: well, the idea is to make this possibly useful as a translation dashboard as well to look up nodes for translation, etc. Having a full text search there I think would be much better for that, but unfortunately search module indexes comments with nodes, so you are pretty stuck there with false positives then. I think title search is still better than nothing at least :)

I posted a redesign of the filters at #355820-21: Improve query filter UI on admin/content , excluding the search component. Please go over there to provide some feedback.

Adding to D8MI language-content leg.

Does anybody have more real world experience like reported in #36 for this? Wonder what we should do to get this back on track.
From what I read in #32 the generic 'entities' scope severly complicates what we want to achieve

I think a title search for content items is what we want to aim for first, as this tool is primarily intended for content admins to find the items they are looking for. I've reopend #1279652: Add title search feature on the node listing admin page for the node-listing specific search.

I think a title search for content items is what we want to aim for first...

That's partially true; finding a single piece of content to edit is the primary activity. However, a very close second for us is "search for a group of nodes that meet this criteria to do bulk operations on".

In product-presentation based sites, like the one that I manage, we may not know the title of the product we are looking for but we do know the metadata about it. Filtering by taxonomy terms is something I really miss in D7.

Thanks, and agreed. #36 points out taxonomy filter as the second major use case.

Who can shed some light on how much implementing taxonomy filter is a *different* job? We should aim to do both, but if they are not dependent on eachother I propose to do it in a seperate issue.

Is it possible to build a generic filter that would let you choose a field and type in a value to search for? Because in D7 and beyond, taxonomy is not really a special case any more, it's just one type of field. Also, for non-node entities, there isn't any special taxonomy-entity indexing being done (as far as I know), so I think you'll have to do something somewhat complex to filter on taxonomy (an entity field query). Filtering on other fields would be equally complex.

Which is why I've generally built custom "find and manage the content" pages for my clients using Views. The fields I have built searches for (these were nodes obviously not generic entities) or allowed sorting the output by:
- content type
- title keyword
- taxonomy terms
- published/unpublished status
- date created (between x and y, before x, etc.)
- date last updated
- author
- value of some field that I had created

@jhodgdon: yeah, ideally (for this feature), we would have views and vbo in core and just ship a preconfigured admin view. Neither views nor vbo seem likely to land in core AFAIS at least. Or please correct me if there is some effort to that effect. So all we have left is to decide if we want to keep the default UI cripelled or build more custom code that becomes irrelevant once you override with views. Looks like we are leaning to this last direction, and the very common views+vbo override is what makes poeople not interested to work on this.

Edit: moved my comment over to a separate issue #1475204: [META] Provide a generic search/filter UI interface pattern for listing pages

http://drupal.org/project/instantfilter

#1475204-5: [META] Provide a generic search/filter UI interface pattern for listing pages

Hi,

Im using drupal 7. In my case, I need to filter the contents by content type fields in admin>content.

Any idea about this. Is there any contributed module for this.
Plz guide me. Its very urgent.

Hi drupalvino and welcome to Drupal! I believe that what you're looking for is Views, but it does have a steep learning curve (or its user interface is intimidating to newcomers at the very least), so I'm not sure you'll be able to get things done in time if you are in a hurry. You can give SimpleViews a try if you don't require complex filtering conditions.

As a note, I'd like to point you to the fact that posting non-related questions in issues is considered "issue-hijacking" and it's frowned upon in our community. Even if this issue here seemed close to what you're after, your question is still unrelated. Please search harder next time and try going through the documentation ;)

... Drupal documentation -> Structure Guide -> Working with Views. In that section, I suggest you take the time to go through as much as you can, but for a crash-course on using the module and in order to get a general idea, I'd go straight to How to use Views (video tutorials).

PS: ...posting the same question in multiple places won't help you either. The most likely thing to happen is that people will start ignoring your comments :/

I think we should search on everything that's displayed in the listing. For example, on the node page the search should also include author. I'm not sure we need to search anything that's not already on the page, so maybe we can do this with jQuery, just like the searchable table on the modules page :)

See #396478: Searchable modules page

+1 on #50's idea of making search on all of the columns that are shown.

But I don't think JQuery will be very useful for this. For most sites they will have much more than one page of entities/nodes, so searching within the currently displayed page will not get you the results you need. At least, I'm assuming that is all a JQuery search would do.

Searching for stuff that is already on the page is a feature built into browsers, right? I think a search field on node lists would be expected to search in all nodes that otherwise match the criteria (ie. other search filters).

#14: node_search.patch queued for re-testing.

Unfortunately no resources in D8MI to focus on this one.

#1279652: Add title search feature on the node listing admin page just got committed, so we at least have one admin view covered. :)

Definitely something we should look at for the next version

Hm. Sorry, why does this need to be Drupal 9? Isn't it literally the matter of adding one filter to each admin view?

Ah yes. I thought we already had a meta for adding title filters to views but I can't find it. I guess this issue makes sense to track this?

#1823450: [Meta] Convert core listings to Views seems related.

Should we move this the ideas queue to make sure that this issue get's the attention it deserves?

Ideas queue is generally more for bigger, over-arching efforts that require higher-level sign-off. This one seems pretty straight-forward, just needs someone to do the reviewing + patching. :)

Filters were (or being) implemented under #1823450: [Meta] Convert core listings to Views