I use Apache Solr, and the related Drupal module, to power the search on this site.

Something that’s always bothered me about the out-of-the-box way this displays search results is that the date display with each search result is the “date the content was last changed.”

So, for example, for this post I wrote in 2015, the date that appears under the search result (when I search the site for pickles) isn’t November 1, 2015, when I wrote the post, but rather July 7, 2016, when it was last updated:

Things I’ve Liked Recently

favourite meal there: toast (from Breadworks bread), smoked salmon, vegetables, pickled onions and cheese. …

Peter Rukavina — 2016-07-03 11:22 — 1 comment

Because Drupal’s very vigilant about keeping the “changed” date current, this date can get updated for a lot of different reasons.

For example, on July 3, 2016 I used the Search and Replace Scanner module do to some automated processing of almost every post here, and Drupal dutifully updated the “changed” date for all of the affected posts to July 3, 2016. That’s fine for auditing purposes, but it just creates confusion for displaying search results, when what I want to know is when was this written.

There are various ways to fix this: altering Solr so that it indexes the created rather than changed date, altering the search results template so that it looks up the created date and displays it, etc.

But the simplest approach, assuming you’ve no need to track revisions, is to simply update the changed dates to match the created dates, via a MySQL query, like this:

UPDATE node SET changed = created;

Once I did that, and then deleted the Solr index and re-indexed everything, the dates in search results became much more helpful:

Things I’ve Liked Recently

favourite meal there: toast (from Breadworks bread), smoked salmon, vegetables, pickled onions and cheese. …

Peter Rukavina — 2015-11-01 14:35 — 1 comment

This is a “nuclear option,” inasmuch as you lose the audit trail for each node. But it was quick and painless for me.