Have you ever looked at the content of a search table record?
It's a REALLY awkward dataset to work with.
As-is, the search function doesn't store a forumid for the target subforum which was searched. Instead, it stores the longwinded SQL query code necessary for identifying the target real-time (in case the forums hierarchy is changed, in between the user's initial search... and some later date when they return and rerun that identical search ???)
^--- along the lines of where forumid!='32' AND forumid!='33' AND...
(the query becomes awkward/complex when nested/parent forums are searched)
For search usage reporting to be really useful, I think it's critical to provide stats that address questions like "What subforums are people searching in? What subforums are most-heavily searched? What keywords are most frequent for users searching subforumX v/s subforumY ?"
With this in mind, I REALLY believe that a reporting hack/add-in will be impractacal until/unless the structure of the search table is first changed ~~ extra columns added... and the search.php routines changed so that the new fields (columns) are populated.
Another limitation imposed by the status quo, in terms of reporting historical usage, is that all 7-day-old+ search resultsets (records, rows within the search table) are deleted each time the seearch.php script runs.
I've created a sort of "mirror" table (named it 'searchhistory') and periodically use a manual SQL query to copy selected fields for all rows over to the other table...
...and although I intended to have search.php update both the search and searchhistory tables with each run, I dropped the project short of figuring out a way to grab the
forum.description value associated with the subforum/branch target of the search.
^---- It can't be all that difficult. The descriptive text is right there, in the selectbox label
(document.forms(0).selectbox.options.optionselecte d.text)
just need to stuff it into a variable onSumbit
If anyone wants to work together on this (please, please) I'll be glad to.
BTW:
another missing puzzle piece:
The results are stored to the search.postids field (column)
as a comma-delimited string. Another field search.showposts is used as a lookup to determine whether the delimited values represent postids, or threadids....
...the actual "count" (# of matches) isn't saved into a field.
Who cares to have the actual postids later, when reporting?
(Many of them will change over time, anyway.)
the searchhistory should have a "count" field & search.php needs a small subroutine to eval the count & write to that field.
Details »»
About Developer
No support by the author.
02-19-2003, 08:56 PM
