Cached search results

Thank you Rickard for your quick reply.

The described behaviour with search ID URLs particularly irritates me, because I value URLs much more than most web developers do. In my forum /forum/search.php?action=show_user&user_id=2 would be rewritten to /forum/user/2 or even better /forum/user/spider8, just to make the URL meaningfull as it is now with my current (custom made) software. An arbitrary search ID will inevitably lead to confusion. E.g. users will post these kind of URLs in their posts to help each other on how to find posts of another user etc.

In the case of user posts, the above mentioned URL forum/search.php?action=show_user&user_id=2 is not the result of POST data, so a redirection would not be neccessary. And for the caching benefit: What about deploying a cookie with the search ID? When the second page of the result set is requested the valid search ID can lead to the cached query results, interpreting the search ID if one is found and still valid, otherwise deleting invalid search IDs from the cookies and performing the search once more.

This method could also be used for POST data based searches, thus a redirect to itself (something like /forum/search) to avoid the annoying popup could do the trick. If the search ID is not valid anymore, a search form could be presented.

I understand, that my insisting in meaningful URLs sounds a bit strange to many people, but my members enjoy using these URLs, as they are selfexplaining. I also made the observation, that Google honours these URLs extremely well, my forum with about 1.000.000 posts ist indexed by Google with about 80% of its content.

I did not even think of having my ideas implemented into the default code base. I just did some brainstorming to prevent myself from overlooking major arguments against them.

You're right, I realised that point a little later too. For my own test bed I found a solution by naming the cookie according to the search itself. E.g. /forum/user/2 a.k.a. forum/search.php?action=show_user&user_id=2 now places a cookie named user_2_search_id, thus several searches in a short period of time would not cause a problem.

In fact it will be more difficult to find a solution for full text searches. In this case there would be three possible solutions.

First solution: making the keyword of the search part of the URL, thus searching for punBB in all forums would result in /forum/search/punBB, in this forum would be /forum/troubleshooting/search/punBB etc.

If the first solution seems to strange (search in two but not all forums would be impossible etc.) I would suggest to submit the correct search ID by additional POST data (buttons to go to consecutive pages) or setting cookies on the client side (JavaScript).

A third way, but the least desirable, would be to have only one full text search at a time by overwriting the full_text_search_id every time POST data is sent. A concurrent search (e.g. in a second window) would still be allowed, but the search needed to be performed again. If however somebody would request a consecutive page of a search after another search has been performed in a second window, he would get the consecutive page's results of the second window's search. In this case, there would be no way to differentiate these two searches by their URL, a scenario which might not happen quite often, but it might cause a lot of confusion.

Although solution 1 has a lot of charme (I like the idea of being able to have bookmarks on search results), I will probably implement it the second way.

Anyhow, I really like your software, and even if I have to code all my ideas myself the basis (your software) seems to be a very sound one. This way is much more effective than turning off several useless features in one of the many bloated softwares out there.

I wish you and your family a happy New Year.