Patch To Add User Profile Search
jjeff - August 6, 2005 - 02:49
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Here's a patch that adds a search function for user profiles.
Users with "access user profiles" privileges can search all public profile fields, while users with 'administer users' privileges can search both private and public profile fields.
Search results display username (as a link) along with a snippet of the user's profile.
-Jeff Robbins
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| profilesearch.patch | 1.88 KB | Ignored | None | None |
#1
profile.module is only 1 component of the profile page. other modules plug in using hook_user, and i'd like for those same modules to participate in profile search.
this patch is useful still, but i'm hoping we can do better.
#2
Moshe, are you suggesting some sort of hook that modules would/should implement in order to have their contributions searchable? Say for instance:
<?phphook_user($op, $blah, $blah){
switch ($op) {
case 'search':
// return an array with SQL additions to user search
$array = array('joins' => array('my_table')), 'columns' => array('column1' , 'column2'));
// array of returned 'joins' will be impleded with "LEFT JOIN"
// array of returned 'columns' will be imploded with ', '
/* end result looks something like
"SELECT * FROM {users} u LEFT JOIN {my_table} x ON u.uid = x.uid WHERE (u.username LIKE '%%s%') OR (x.column1 LIKE '%%s%') OR (x.column2 LIKE '%%s%')";
*/
return $array;
case 'search results':
// return rendering for search results??
// does 'view' work for this?
?>
I don't really think that there should be separate searches for "user" and "profile", but I'm having a hard time coming up with a good way of creating a SQL call that doesn't make the server cough and sputter... Like for instance, I don't think that all of those ORs above are going to work very efficiently.
Anyone know of a good way to incorporate the SQL stuff in my patch into the SQL for the user search? Is there a way to search for the same thing accross several columns? That would at least unify the searching for user.module and profile.module. (Why are these separate modules anyway?)
Then (if this seems like the right way to go) we can tackle some kind of an additional case in the user_hook to handle injections into the search.
As always, comments are appreciated!
-Jeff
#3
http://drupal.org/node/28275 is another approach, as moshe proposes. Allthough It goes far beyond the scope of jsut making sear profiles searchable, it still aims at searchability of *anything*. PLease have a look there, too.
#4
#5
It would be better to just merge user_search() into profile_search(). user_search() on its own is pretty useless, and to the end-user there should just be a single 'user search'.
#6
Jjeff,
Is it possible to have this patch upgraded to work for 4.7? It's really useful and, I suspect, used by quite a few Drupalers.
Regards
Patrick
#7
I'd like it too!
#8
I've updated the patch to 4.7b4/HEAD.
This adds the search functionality to profile.module under a seperate "profiles" tab on the global search page.
I do agree that it would make sense to have it merged with the 'user' search but didn't want to start on that until somebody decides what is best.
For now I think this patch is a suitable edition to the coming 4.7 release of Drupal and should be included.
I've tested searching profile fields which are both public, restricted, and hidden. Access control is honoured.
Search results correctly display all the profile fields - no matter how many categories there might be. The previous patch had a bug which just returned 'Array' in the search result 'snippet'.
#9
Patch without the SQL wrapped over multiple lines.
#10
untested quickie patch:
- Code style (spacing around operators and foreach)
- Remove user_search()
- Add matching of username to search
I'm slightly worried about performance of the SQL query, needs more testing really.
#11
Steven: what testing procedure do you suggest? I'd like to get this in to profile.module for 4.7 if possible.
#12
to test this one would need to create some regular profile fields and some admin only profile fields (i.e. hidden). then perform searches with authenticated user and as admin and assure that the correct searches return correct results. non admins can't get hits on admin fields.
also test wildcard searching to verifythat it works as documented
#13
I fixed a couple of bugs in the previous patches:
Tested on scratch.drupal.org. The query is quite heavy there (200ms) but for smaller sites it's ideal. I suppose for a dedicated social networking site, you'd need to look towards a more advanced solution.
#14
Forgot to remove admin/user/search from user.module.
#15
Applied your patch to a fresh CVS install.
It's working fine, but I can't say anything about performance.
vg
#16
Would be fabulous if we could have a search API used by all the user-related contrib modules. For instance, the address module -- part of ecommerce which stores first and last name, address, and phone number -- is not (yet) searchable, as far as I can tell.
#17
Until/If the search function gets in to profile.module core, i've knocked out a quick module to add searching without the need to keep patching your core profile.module file.
You can find the ProfilePlus module in CVS @ http://drupal.org/node/55469
#18
I think there is some other issue covering this
#19
um, this one has a promising patch in it. please demonstrate a better patch before closing this one.
i do much appreciate pruning of the issue queue.
#20
#21
Not sure why this is marked for 7.x - I'm curious if there is the ability to search by more than just username. This seems to do a full text index of the profile - but what about email address or other standard user fields not part of profile.module?
#22
Features go into 7.x
#23
That's right. Back to 7.x.
#24
This post acts as a reminder for me to have a look at this later.
#25
Note for later: LOWER is the SQL antichrist:
WHERE LOWER(pv.value) LIKE LOWER('%%%s%%') OR LOWER(u.name) LIKE LOWER('%%%s%%')so a different solution is desired. Perhaps we should use the search_index table?#26
Cleaning up the issue queue.