Change notification "keyword" function doesn't work

Moving to the proper queue.

jhodgdon built this initially so might have some ideas, but since this is just a View, anyone should feel free to download http://drupal.org/project/drupalorg_testing and give it a whirl.

That's because views uses the core search index, but on d.o we use Solr and most nodes aren't indexed by core search see http://drupal.org/project/coresearches for more. Issue queue views work because of a special-case to index issue nodes and comments. See the search_index subdir in the project_issue project.

Since there's a relatively tiny number of these change notice nodes it should be no problem to index them. I see 2 options:

A) Add some similar code to force these nodes to be indexed into the drupalorg feature module that defines the node type and views.

B) Generalize the project_issue_search_index.module so that you just configure what node types you want it to index. Could be split out into a separate project quite easily.

I'd prefer B but I can't do it myself right now, so I don't want to tell someone else they have to do it that way. If I can get a chance to mess with this, I'll assign this to myself.

Cheers,
-Derek

I know this issue was reported quite a while ago (months ago) but I can't find the other issue :( ... Anyway this one has information on how to resolve it -- thanks dww!

I'm taking this on...

Here's a patch that does option (c): In place of using search keywords, have fields for Title and Description keywords, which don't rely on search.module at all.

This can be tested at
http://docs-infra-drupal.redesign.devdrupal.org/list-changes/drupal

After revising the view in the UI and then exporting to make the patch in #5, I applied the patch on my test site, cleared the cache, and reverted the view to code in the Views UI. So it should be a valid test of the patch.

I think it is working fine. Other testing would be welcome. :)

I tested a bit on the dev site and I agree it's working fine. Maybe there's a nicer way in the long term, but I vote for "working at all" in the short term. :)

Clever! ;) That'd probably avoid the problems I explained at #2. However, I have two concerns:

a) The UX is a little more crappy this way. "You mean I have to tell you exactly which field to search in?! c'mon..." Obviously, something that works at all is better UX than what we have now, but I'm just sayin'. ;)

b) If we're not using search.module and therefore {search_index} I'm pretty sure that means this query is going to be awful for the DB servers. :( Since body lives in {node_revision} while title, status, type, etc all live in {node}, we're going to have a WHERE spanning multiple tables, which means it can't be indexed. And an unindexed query on {node_revisions} doing RLIKE on the body field is going to be *painfully* expensive and slow. I could be wrong, but that's how I understand things would be working here. Even though the query wouldn't be fully indexed even if it was using {search_index}, at least it'd be = not RLIKE, so that's way faster. I think it'd be important to see an EXPLAIN on the resulting query before we continue with this approach.

Sorry I haven't have time to do anything else with this myself.

Thanks,
-Derek

The description field is a CCK text field, not the node body field, if that makes any difference. Probably it doesn't for efficiency... but there are tons of other filters on that page that will also be going against other CCK text fields, so I don't think this makes the query any worse?

I agree the UX isn't great, but the people using this are developers anyway so probably can live with it.

Oh, I just assumed node body. Yeah, a separate CCK field makes a huge difference, actually! In that case, we're JOIN'ing on {content_type_changenotice} which is going to vastly shrink the result set from {node} in the first place. Then, when dealing with WHERE, the RLIKE is only on the relatively tiny number of rows in {content_type_changenotice} instead of on the giant {node_revision} table itself. Probably nothing to worry about here. False alarm!

Still wouldn't hurt to see the EXPLAIN, but yeah, I'm much less concerned about the performance of this now.

Thanks!
-Derek

Here's another idea: I could remove the Title keywords field and just leave Description? That would most likely cover most of the use cases (I think any keyword in the title is likely to be in the description). Thoughts?

Here's a new version that just has the Description keywords. It's a bit cleaner, and does not seem to have problems finding issues.

On my test box, I just reverted the previous patch, applied the new patch, reverted the view to using the view in code, and cleared the cache for good measure.

If you want to see this in action, go to
http://docs-infra-drupal.redesign.devdrupal.org/list-changes/drupal (u/p = drupal/drupal)
Try a search for "entity" or "entities" as an example. I think it's fine... definitely better than what we have now!

I tested a few terms on the dev site and it seems to work well. Definitely better UX that way too.

OK, I think it is fine too. Tentatively RTBC unless maintainers object. :)

tagging

Committed and running on staging.devdrupal.org.

Thanks! apparently this is on d.o too... let's see. Yes! Keyword searching works, finally. :)

WOOHOO!! :D

Great work Jennifer! Thanks for the speedy deployment, Neil!