On 2005-11-29, I suggested a patch to search to allow search to create a block listing recent searches.

Ensuing discussion on #drupal and on the patch page suggested that:

• the idea was interesting
• the implementation was too fragile to be used as such

I looked deeper into this and I think that making this feature more resilient would involve changing watchdog. The idea is therefore as documented below.

As this involves changes to core features, I hope developers with a deeper understanding of core than me will comment on this/edit this page to improve it before I write code involving these core changes. The wiki structure allows this more easily than comments on the patch page.

• add a new column (say, “data”) to the watchdog table, to hold a php serialized content, or NULL
• modify bootstrap.inc/watchdog to pass a new parameter:

<php> function watchdog(

$type, 
$message, 
$severity = WATCHDOG_NOTICE, 
$link = NULL,
$data = NULL) {</php>

The new parameter could be used by modules aware of this new feature to store content of their choice in the watchdog along with the standard parameters, while retaining compatibility with existing call through the use of a default NULL.

• adding a new hook_watchdog_render to be invoked from watchdog.module/watchdog_overview to allow modules to display custom content along with or in lieu of the default log display. It would likely take the same parameters as the new watchdog() function:
• adding a setting to watchdog to toggle display of this additional information:
  • not displayed
  • displayed along the standard information
  • displayed as a link to details in the default watchdog display

In the current 4.6.x core, only watchdog module queries the watchdog table, and does so with queries like:

SELECT w.* [...] FROM {watchdog} w

which means no outside modules should be impacted. These queries could be improved to avoid querying this additional column if it is not needed.

• having this new column available would allow search to store more usable information in the watchdog, typically by storing a serialized version of the query stats:
  • term searched
  • result count
  • something else ?
• with this information available, recent searches could be displayed by unserializing these data instead of processing the HTML-formatted contents of the current columns, allowing full i18n compatibility.
• as suggested by Boris Mann, having this more resilient content would allow for this feature to serve better, possibly by creating a RSS feed on recent searches
• the current display, limited to a fixed count of recent searches, could be improved tby the addition of paging and optional display of the stats attached to the search
• searches beyond “node” and “user” could be displayed too: this mechanism could be used by modules implementing hook_search, since the content, as a serialized object, could also store additional information for these modules.