Closed (fixed)
Project:
User displays
Version:
6.x-1.1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 May 2010 at 21:13 UTC
Updated:
3 Jan 2014 at 01:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
swentel commentedShould be easy - with function user_search_page($results) {} (untested). Not sure where I should put this - in nd_search or in user displays?
Comment #2
swentel commentedSadly enough, this will be a bit hard to implement - the default search results in the array (see attach) only gives me two keys - unless with some regular expressions, which I'd rather stay away from to include this by default.
Comment #3
dpalmer commentedI think you would want to put this in the user display module maybe in a sub-module like ud_search?
Can you post a patch so I can see your code and maybe give you some help?
Comment #4
swentel commentedWell, didn't have a lot of code yet :) I created user_search_page($results) {} and looked what was in the results - but not a lot really.
Comment #5
dpalmer commentedSwentel,
Would it be safe to assume that the logic would be much like the nd_search module for this ud_search? If that is the case, I can take a stab at it and see what I come up with. (As you can tell from me posting issues on all your modules, and on the apachesolr module pages, I'm building some big solr web apps right now :D )
Thanks!
Comment #6
swentel commentedOk, here's some pseudo code
Shouldn't be a separate function imo - could easily be inserted in ud.module I think. I'll do some tests in the next couple of days for preprocess variables and other stuff - if you have code, don't hesitate to post :)
Comment #7
swentel commentedtagging as ds 1.3 - what a move from won't fix to getting this included ;)
Comment #8
dpalmer commentedSwentel, I'll start playing around with this today and let you know my progress.
Comment #9
dpalmer commentedSwentel, have you ever used Drupal's arg() function? http://api.drupal.org/api/function/arg
I believe you would be able to grab that uid from a url such as localhost/drupal/user/1 using arg(1);
I have tested this on individual user pages and my DPM is displaying the correct data. I tried to implement your code into my user_display.module file with the arg change I have suggested but unfortunately it doesn't seem to change anything, I suppose this is because there is currently no admin interface to enable user display search or should it just override it by default?
Hope that helps!
Cheers,
Donovan
Comment #10
dpalmer commentedUgh disregard my last post, I just realized that the arg() function would only help if that user url was the URL in the browser.
Comment #11
dpalmer commentedWhat do you think of that?
Comment #12
swentel commentedI think (untested) it's dangerous to rely on '/user/' - that won't work when the user has an alias for his profile. Other than that, looks good.
Comment #13
dpalmer commentedSwentel, even if they do have an alias for their profile, doesn't drupal still generate a /user/ page for that user even though there might be an URL alias to get to that profile?
Comment #14
swentel commentedThat's true, but I've tested with users having an url alias and the problem with that is that in $result['link'] the link is already the alias and not with the uid, eg http://drupal6/users/admin
So I guess we'll have to check if the uid is numeric and if not, than we'll have to look for the alias, which is annoying as in at least one query per result.
Comment #15
dpalmer commentedAh I see what you mean now, bummer. That condition you suggested should do the trick though.
Comment #16
dpalmer commentedSwentel, do you think you can post an updated version of the module with the user search support sometime relatively soon?
Comment #17
swentel commentedWorking on it now - I think I'll be able to commit something in 2 or 3 hours.
Comment #18
swentel commentedOk, here goes, works fine with and without aliases.
I've committed this already to the dev version of user displays, which adds a new menu admin/ds/ud/search to override or not. Let me know how testing goes, after that I'll close the issue :)
Comment #19
dpalmer commentedSwentel, I updated to the latest code and I see the search tab under Display Suite -> Layout -> User -> Search
I have added the fields I wanted, but when I do a search and a user is returned its still the default output which is a link to their profile.
With Node Display Search, there is an option Display Suite -> Node Display -> Nd_Search which then has several configurable options, most importantly the checkbox:
Override search page
Toggle this checkbox if you want to display the result of search with the display suite.
I have enabled this thinking it would help, and yes it removes the default search results and replaces them with DS but on user results it says "undefined" for me even though in the Search build mode for users I've added several fields.
Maybe the search for user display needs a checkbox like that to override the search results with whatever build mode the user selects? Also, the path admin/ds/ud/search just redirects me to the base User Display page.
Perhaps I'm missing a step?
Comment #20
swentel commentedWell, there should be checkbox at DS -> user displays -> search (admin/ds/ud/ud_search) - maybe with a clear cache that one will apear also ?
Comment #21
dpalmer commentedYeah I see your hook_menu_alter and you have obviously implemented it correctly. I've cleared cache, rebuilt the menu router, tried everything possibly and i still dont get access to that page.
Comment #22
dpalmer commentedI've looked at a lot of the code now and it all looks good, I'm just not sure where I can't access that page, I'm the super user so it's definitely not a permissions issue. Perhaps I have a conflicting module?
Comment #23
swentel commentedaaaaaah, I've got it hehe, the path for that checkbox is at admin/build/ds/ud/ud_search , not admin/ds/ud/ud_search
we are moving the complete menu of Display Suite into admin/build (under structure) .. that's why it's not showing up in your menu ..
Comment #24
dpalmer commentedAh okay I see it now, I should update my DS module then too.
cvs update -dP ftw. :)
Thanks, I'll let you know how it works.
Comment #25
swentel commentedWell, we're still testing some stuff with multiple styles on fields - especially when going from 1.2 tot 1.3 - it may cause some notices on saving field screens which we're going to tackle on friday, other than that, the rest should still work though .. :)
Comment #26
dpalmer commentedSwentel, it works great with default drupal search, I tried it on my local sandbox and it worked as intended, but for the application I need it for, we are using apache solr search for users. We want to have this application were users can select districts & schools in faceted filters, and then only get their username and email as the result (hence my need for display suite & user display), so when I enabled the module and set it to override user search pages on the solr driven site, it didn't override the results, it still gave me the default ones. Would it be easy for you to add support for apache solr user search?
Btw, here is the apachesolr user search module, http://github.com/SupermanScott/apachesolr_users
Thanks for your help, I seriously owe you like half of my paycheck.
Comment #27
swentel commentedWhat's the Drupal path when searching for users ? Because I don't see how that module is adding a new search tab.
edit
I'm most of the time on IRC on #drupal, that might be faster sometimes ;) But now I'm of to bed!
Comment #28
dpalmer commentedComment #29
dpalmer commentedSwentel
The URL is the same as core apachesolr search.
http://localhost/drupal/search/apachesolr_search/
It just allows $users & $user profiles to be indexed and searched by solr.
I'm looking at your nd_search module in the section where you override solr search and seeing how I can implement it with the ud_search.
here is a screenshot of a DPM of one of the $result objects passed to the
function apachesolr_search_search_page($results)
Maybe this will help you....
Comment #30
dpalmer commentedWell Swentel, I finally got off my lazy arse and did it myself. I think I got it to work.
Here is the new function I added to the ud.module
Comment #31
swentel commentedHmm, looks cool, but does your normal node search still work then ?
Comment #32
swentel commentedBut this can be set to fixed right ?
Comment #33
dpalmer commentedI'll have to test it with the normal node search, the system I need the apachesolr user search though will probably only be for searching users though. It would be nice to make this flexible to work both ways though.
It can be set to fixed, but I'd like you to implement this code for the 1.3 release so I don't have to use a "hacked" version of the module.
Comment #34
dpalmer commentedSwentel, after some quick testing it seems like node search results are replaced by the buildmode that user search results are using...
Do you think there is a way we can detect if it's a user or node result and then load the appropriate build mode for that content type? edit: if you look at the dpm($result); you will see that there is a type attribute in the $result object. It is always NULL for users, and if it's a node, it should have the content type in there. Perhaps this is how we can check if it's a user or a node and then load the search result build mode for whatever content type it is.
Comment #35
swentel commentedThis has been committed to nd_search - ud search is obsolete for apachesolr search on the content tab (but still usefull for the user tab).
Comment #36
dpalmer commentedSwentel, I got the latest code for nd_contrib (for nd_search) and reverted my ud.module. It's working great man, this is exactly what I wanted. Thanks for all your time and help. If you ever need help maintaining these modules I'd be more than happy to help out, I've got a good grasp of the code now. :)
Now, I just need to get faceted filters for CCK fields that are in a node (content_profile module) to show up for when the users are returned so that's what I'll be working on for the next few days.
Thanks again Swentel, I couldn't have done this without you.
Comment #37
swentel commentedHrm, well, if you are using content profile, those nodes (and thus the user) are indexed (unless you are not using one content type for a user), since, well they are nodes, why would you use the apache solr user indexing in the first place ? With the content profile, you are able to select what will be indexed with the 'search index' build mode and control the output with the nd display. Never tested this though, but it looks that would work - at least in theory and in my head :)
Glad to be of help!