Saving search in vBulletin

[WebMasterAJ]

Hello, I have a question.

First, a quick background. I have a forum for writers to go in, write articles, and then post them. A script on the main page then pulls the articles from a specific forum, displays the first few sentences, and etc.

Anyways, I would like to be able to "save searches." So, for example, I can have a link for viewers to be able to easily view all articles by a specific writer, or with a specific text.

So, for example... if a writer is writing a draft column, he would insert the following in his article: (this is basically making the text the same color as the post background color, to make it seem invisible.

[tablecolor]2003 April Draft News Commentary[/tablecolor]

Then, I would like to create a link on my main page that simply says "Click here to view Draft Articles" which will automatically search for articles containing "2003 April Draft News Commentary".

All in all, basically... I'm trying to find out if there is a way to save searches.

I hope everyone understands what I mean, if not... just ask

Let me know if you have any ideas for my question.

Thanks for your time,
Andrew Tatum

[Xenon]

just run the search once, and then save the url of your results.

that's why there is the searchid thing..

[sparky2]

"just save the URL for the results page" is not a viable idea.
Here's why:

1)
Each time search.php runs, one of its subroutines
deletes any search (row in the search table) that has
a dateline older than 7+ days from time(now)

2)
One of the outermost conditionals (permissions check)
checks the $bbuser[userid]... and considers each
member's search to be his/her own private resultset.
You can close the browser window(s) and return in another session
(within 7 days) and request your previous results page
but if youemail the results page URL to me
vbb won't allow me to view it!

Check this for yourself:
Even here, with the "view 10 recent searches" hack applied,
you cannot view the results page of another member.
Hover your mouse over the link to one of the listed "recent searches" & note the searchid in the statusbar.
After clicking the link, note that the URL in your location bar refelect the searchid of a brand-new search.


The reason for this "limitation" is to prevent members on the "guest" or "registered" usergroup from seeing the resultset returned for an admin account. It would likely
contain matching threads within private forums & the user would just become frustrated; they would click & the permissions check in showthread.php would lookup
their access in the forumpermissions table... and execute show_nopermission()

(In fact, the first release of the "view recent searches" hack failed to take this into account & a patch was released, so that it checked the usergroupid of the person
who had conducted each search -- and it now omits resultsets from mod/admin search runs)

===============================

Okay, what WILL work & will be immensely valuable in terms of reducing server load due to frequent searching (drive reads of the huge searchindex table) is this:

1a) create a new table, let's name it 'searchhistory' with a structure similar to the search table. We'll record (save) all the search particulars EXCEPT the postid field
(which stores the matchind ids as a comma-delimited string which can be HUGE)

1b) include an extra field in the searchhistory table (call it 'targetforumtitle') and capture the text label of the target subforum in each search run, for use in later
reporting

1c) modify search.php so that $bbuserinfo[usergroupid] is passed into a hidden form field during ?action=searchintro

1d) modify search.php to ALSO "INSERT INTO searchhistory..." every time it performs a search ***for usergroupid=2 members

1e) allow the data to accumulate in searchhistory over time

1f) build a hack that queries & reports the most-frequent querystrings (preferably grouped or filtered by forumid)


2a) have the moderator(s) for each subforum periodically check the "top searches" report and...

2b) expand on "recent 10 searches" so that mod/admins can page through the entire recorded past searches (remember, only NON mod/admin search records are
listed in it) and provide a checkbox (or set of inputs) which enable them to select/assign any given resultset as a "Hot Topic" for a particular subforum

3c) create a "hottopic_bit" template which will be inserted into the "forumhome" and/or "showthread" template...

4d) present members with titles/links to these "hot topics" as an alternative to re-running the same-old-search that gets re-run 50 times a day! and as an alternative to
creating new, topical subforums... painstakingly moving relevant threads to them... and merging the threads back into another subforum once the interest wanes.

***regarding the usergroup=2 inclusion/restriction:
As a working premise, guests aren't allowed to use search.php (toward conserving server resources & encouraging membership) and all "registered" members have
access to the same (identical) set of public subforums.
--------
If access masks are enabled in your vBulletin installation (as they are in ours), the search resultsets may contain postids in subforums for which a member browsing
"HotTopics" later doesn't have permission.





If anyone is interested in collaborating on this, let me know.
I've done (and am using) the "searchhistory table data collection" part
--------------
the query necessary to identify "top keywords" will be nearly identical to
the one (covered in another hack thread) used to ID common words in the word table,
so that these can be added to badwords.php (toward reducing the size of the searchindex table)
--------------
the page-at-a-time (and filtered by subforum) reporting can borrow code
from the native "view adminlog" script
---------------
So, it's just a matter of putting the pieces together. When it's all done/built, and used, one of the beauties of it is that the resultsets can STILL disappear
automagically (and WILL if the datecheck isn't removed from search.php). When a selected HotTopic hasn't been clicked for a whole week, it'll be removed.