First things first:

• Zeitgeist is essentially fashion for ideas. See a discussion about it on Wikipedia.
• Why the name ? Because when this idea was first discussed, someone on Drupal (chx, I think) said 'Oooh, a Zeitgeist', and I liked it.

• Log searches with their timestamp
• A themable drupal block with the 'n' most recent searches. Since 4.7.x-1.4, 'n' is settable
• A themable drupal block with the 'm' most popular node searches during the current month. Since 4.7.x-1.5, 'm' is settable
• A page displaying the most requested searches over a given time span
• 4.7.4 to 7.x compatible.

• A RSS feed tracking all searches
• A periodic (weekly) summary of the top queries, by email to the site admin
• A setting to include queries by UID=1 or not
• Export the current table → see offload.module
• Empty the current table

Looking further:

• ability to log various site uses, instead of just searches → won't do, use other D6 logging modules. D6 was extended for that reason.
• coupling with statistics.module
• a cleaner way of trapping queries (why not just hook_search ?)

• Table 'zeitgeist' contains the search log
• Variables:
  • zeitgeist_history: the duration entries are kept in the log table
  • zeitgeist_latest_count: the number of entries to be displayed in the “recent searches” block
  • zeitgeist_latest_info; the customized info of the “recent searches” block (in the blocks list)
  • zeitgeist_latest_title: the customized title of the “recent searches” block (when displayed)
  • In zeitgeist_latest_info and zeitgeist_latest_title, the string %count can be used to insert the value of zeitgeist_latest_count

As of 4.7.x/7.x, Drupal does not implement a standard search logging API. The net result is that code like zeitgeist.module, which needs to record data from core, must obtain them from undocumented behaviours.

• The core patch from which this module has been born used to parse the standard “watchdog” table from the dblog module.
• For zeitgeist.module 4.7.x-1.1 to 4.7.x-1.6, this meant parsing both the “search form” form and search URL, which led to various problems, notably regarding potential safety issues, and the algorithm proved unreliable over minor core releases changing search.module.
• Later versions only alter search forms to add a submit handler. This simplifies the code, but leave it vulnerable to search.module changes.

At some point, drupal core will probably evolve to include such a logging mechanism, and zeitgeist will then be able to use it. Should the module become popular, it is also conceivable that search.module add a recording hook, independent of other recording needs. Things have evolved for the better in Drupal 7, where a single form implementation is used for all search forms, allowing simpler and more generic logging from the form submit handler.

Until this happens, it could be possible to use runki_function_rename to:

1. rename drupal's do_search function to something like zeitgeist_do_search,
2. implement a local do_search() function in zeitgeist.module. At this point calls by other modules should go to the new function instead of the standard version
3. within this local do_search,
   1. perform the _zeitgeist_store_search
   2. invoke the standard do_search, now called zeitgeist_do_search
   3. return the results obtained from the standard do_search from our custom do_search

Problems:

• This would fail if the standard do_search did some stack checking, but the current version doesn't.
• This requires the experimental “runkit” PECL package, absent from most PHP installations, and apparently unstable