"Top search phrases" report not showing any data

Panopoly Search 1.16 uses Search API 1.14 (http://cgit.drupalcode.org/panopoly_search/tree/panopoly_search.make#n11). This is still something that Panopoly Search could take care of - maybe also working with the guys in Search API.

This has nothing to do with Panopoly. Panopoly is just an installation profile. The issue you see is caused by the Search API module which is used instead of the core search. So you should direct this to that project instead.

I do think this is Panopoly's concern. We are responsible for whole experience of users on the default configuration that we provide. It's Panopoly that's enabling all the necessary modules (dblog, search and search_api) to cause there to be a useless "Top search phrases" report. :-)

So, even if the fix ends up being in search_api, we can lead the way by creating an issue in their queue with a patch, and then use this issue in our queue to get that patch added to our panopoly_search.make file. This is a pattern we follow a lot, where we have an issue in the Panopoly queue AND in the queue of the project where the actual bug is being fixed.

For example, when we added the ability to search for content added via Panelizer: #2416525: Allow users to search for content added to a node via Panelizer

It's really the Panelizer modules responsibility to provide this feature, so we made a patch in their queue as well: #2416505: Allow indexing content from "Full page override" with Search API

Anyway, on this issue, I agree with @cboyden: we should either come up with a way to log searches or not expose the "Top Search Phrases" report.

I found a really old issue about this in the Search API queue:

#1189264: Top Search Phrases Report

The maintainer was pretty adamant that this belonged in a seperate module, not Search API:

But I just don't think this belongs into the framework module itself, so unless I'm convinced, you won't get around another module.

And it ultimately got closed as "won't fix".

I think that means we're likely going to have to implement this in panopoly_search itself. Luckily, the above issue also suggests an implementation! I'll see what I can come up with...

Here is a patch to implement this! Ideally, we'd have some tests for this too.

Here is an additional Behat test to verify this functionality! I'll try this on Travis-CI in a moment.

EDIT: Here is the Travis build: https://travis-ci.org/dsnopek/panopoly/builds/51520789

Blergh! Of course, this actually fails under Travis-CI because dblog is disabled. When I get a chance I'll test with dblog enabled (and try to look up why we disabled it in the first place).

EDIT: Here's a test run on Travis with dblog enabled: https://travis-ci.org/dsnopek/panopoly/builds/51533545

It appears that dblog was disabled on Travis-CI to fix this issue: #2231631: Tests randomly fail with "MySQL server has gone away" (take 4)

If we can't use it on Travis, maybe a solution is just tagging it with @dblog and having Travis skip those? It sucks that we wouldn't get CI for this test, though...

Trying a new fix for the MySQL "server gone away" error:

#2231631-19: Tests randomly fail with "MySQL server has gone away" (take 4)

Also, since not all distributions will use dblog, we should mark this test with a @dblog tag. New test patch attached!

EDIT: Here is a Travis-CI build for just this test with that new fix attempt: https://travis-ci.org/dsnopek/panopoly/builds/52318418

EDIT-2: Bah! I messed up the patches in the last one. Here's a better one: https://travis-ci.org/dsnopek/panopoly/builds/52320215

Ok! With that other issue now committed, these tests are passing. :-)

Thanks for the review! Committed. :-)