Ticket #58 (fixed enhancement)
Search page isn't as informative as it could be
- Created: 2010-06-25 17:57:46
- Reported by: Reines
- Assigned to: Franz
- Milestone: 1.4.4
- Component: usability
- Priority: normal
On the search results page the user cannot see what keywords actually returned the current results.
Reines 2010-06-30 21:54:38
- Milestone set to 2.0-beta1.
Reines 2010-08-12 18:17:09
- Milestone changed from 2.0-beta1 to 1.4.3.
Reines 2010-10-25 11:20:41
- Milestone changed from 1.4.3 to 1.4.4.
Franz 2010-12-08 21:10:13
- Owner set to Franz.
Let's see if I can get this working for quick searches, too.
Franz 2010-12-13 15:00:12
The last thing that is not working yet is displaying the username of the user whose topics/posts/subscriptions we search for. That is a little more difficult since I would have to restructure search.php a little bit (basically moving the query to be executed before the output is generated).
Is this worth it? I would say yes, since we would have to do the refactoring at some point anyway.
Franz 2010-12-14 18:13:27
Okay, doing this was fairly easy for user topics and user posts. I would have to add another join for the subscriptions page.
Interestingly, this was not done in 1.3, but I think it would be an inconsistency and so would prefer to add it.
The dotted line between breadcrumb and paging links is missing. To fix, find (2 instances):
<p class="pagelink"><?php echo $paging_links ?></p>
<div class="pagepost"> <p class="pagelink"><?php echo $paging_links ?></p> </div>
- Uploaded patch search-show-subscriptions.patch. (view)
I would have to add another join for the subscriptions page.
Attached is a patch for your consideration.
Here is the revised language string:
'Quick search show_subscriptions' => 'Subscribed by %s',
Franz 2011-01-23 18:44:07
Haha, you won't believe it, but I was just now working on this and already had another patch ready.
Which brings me to the question, as I did this differently: Should we fetch the username first and then store that in the cache or do it afterwards (that's how I did it)?
Probably after. Then there is no need to lookup the username if there are no subscriptions for the user.
Franz 2011-01-23 19:22:20
- Status changed from open to fixed.
Ah, okay. Implemented it that way now.
I had figured that you had done it that way to save the one query for every time this page might be called (with one search ID). But that number should barely pass one, so I guess this is fine.
Language string 'Quick search show_subscriptions' needs to be updated.
In profile, "Show subscription" link is displayed to admins, moderators, moderators that can edit user profiles, and users. When moderators are not allowed to edit users profiles, the link is not there when viewing users profiles, however, moderators can access users' subscription by accessing search directly via the browser address bar. In search, we check whether they are admin/mod. Should it be changed to admin and moderators that can edit users profiles?
Franz 2011-01-23 23:17:03
Ah, thanks, I had accidentally not committed the language file.
I will look into the other issue, too. Thanks again.
Franz 2011-01-25 14:11:38
Hmm. Should the last breadcrumb item be a permalink so that people can link to these searches more easily? After all, the link from the address bar (with search ID) can cause problems...