Posted by Bojhan on June 21, 2009 at 12:16pm
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | D8MI, language-content, Usability |
Issue Summary
The usability test at Baltimore relieved the importance of being able to search entities within the administrative interface.
First example:
Being able to search content on node title in admin/node/content
Second example:
Being able to search a term on admin/content/taxonomy/1
Third example:
Being able to search a node (by its title), instead of having to copy+paste path on admin/build/menu-customize/navigation/add
What about the new Fields? I think there are a lot of use cases for such a generic pattern.
Comments
#1
Tagging, Damien mentioned we might have to re factor the search module.
#2
I can see two alternative ways of doing this:
I strongly favor the first route. Input is appreciated on ways to make it happen ;)
#3
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 ;)
#4
@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.
#5
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.
#6
This reminded me of http://drupal.org/project/views_bulk_operations, would like to know what might be the differences?
#7
#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.
#8
Reviving this issue: #601674: Index taxonomy terms in core search.
#9
#10
So a mockup, I envision this to work like http://dmitrizone.com/229193.mov - filtering the table on the go (probally a little delay, but one can find the right nuance in that)
#11
I think it'd look better like this
#12
dmitrig01: I am not sure I agree, we are mixing actions (links to other places) with interactions on the page, that will confuse the user. Let's try to find a better solution for these filters - but that should not be part of this issue.
#13
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.
#14
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.
#15
The last submitted patch failed testing.
#16
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).#17
Thanks for the review!
New patch fixes all mentioned items, the existing tests were updated, and some new tests were added.
#18
status
#19
Missed a debug line.
#20
The last submitted patch failed testing.
#21
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:
<?phpif ((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.
<?phpif ($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.
#22
I guess I'll mark it as needs review even though we might run into the same exception as before.
#23
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.
#24
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.
<?phpif ($filters[$filter]['type'] == 'select' && is_array($filters[$filter]['options'])) {
?>
<?php// Avoid errors when there is session data but the module is disabled.
if (!module_exists('search')) {
break;
}
?>
#25
#504012: Index content when created
#26
The last submitted patch failed testing.
#27
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.
#28
subscribe
#29
Lets really do this in Drupal 8
#30
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.
#31
did some work :
http://drupal.org/project/ext_search_page
#32
Coming here from #1279652: Add 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?
#33
@Gabor I think we can just start with an initial implementation, for just content. I do think its valuable to keepp in mind that we want this to be generic as possible to allow for other entities (imagine drupal commerce product listing par example).
#34
@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).
#35
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?).
#36
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?
#37
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.
#38
@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 :)
#39
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.
#40
Adding to D8MI language-content leg.