2015-11-18, 05:38 PM
Hello,
thanks for the assistance.
In case you're curious the end results looks like this:
http://forum.koohii.com
In the end it made more sense to create a custom "index_topics_list" template and associated php include, based on the search.php code.
The reason for that is that the search page's moderation tools do not assume that the threads belong to the same forum.
I'd like to put it up on github sometime, although I've had to hack a few bits and pieces to customize it.
Forum members seem to like it and have gotten used to it pretty quickly.
ps: performance wise, which was a concern, it seems I got it mostly right. Footer says 13 querries for the index page, and 80ms. It does have to perform the two steps of the search in one page request though. ie. create the list of thread ids, and then do the thread query. I was thinking it's possible to optimize further, by storing those searches the same way the search page works, potentially speeding up repeated page views for individual user.. but I figured it works well enough like that. Oh right, one thing I did is make the "Recent topics" only get results up to 30 days backwards. That way it reduced drastically the selection of thread ids ( "IN" sql operator ), which is fine since the function of the index is to show recent discussions.
thanks for the assistance.
In case you're curious the end results looks like this:
http://forum.koohii.com
In the end it made more sense to create a custom "index_topics_list" template and associated php include, based on the search.php code.
The reason for that is that the search page's moderation tools do not assume that the threads belong to the same forum.
I'd like to put it up on github sometime, although I've had to hack a few bits and pieces to customize it.
Forum members seem to like it and have gotten used to it pretty quickly.
ps: performance wise, which was a concern, it seems I got it mostly right. Footer says 13 querries for the index page, and 80ms. It does have to perform the two steps of the search in one page request though. ie. create the list of thread ids, and then do the thread query. I was thinking it's possible to optimize further, by storing those searches the same way the search page works, potentially speeding up repeated page views for individual user.. but I figured it works well enough like that. Oh right, one thing I did is make the "Recent topics" only get results up to 30 days backwards. That way it reduced drastically the selection of thread ids ( "IN" sql operator ), which is fine since the function of the index is to show recent discussions.