search.php functionality needs updating

[DJPaul]

Review feedback says that search.php needs updating pretty heavily, as explained at ​http://codex.wordpress.org/Theme_Development#Search_Results_.28search.php.29

Looking at the file history, ​https://buddypress.trac.wordpress.org/log/trunk/bp-themes/bp-default/search.php?rev=4402, it hasn't really been touched since it was created.

[DJPaul]

I would appreciate anyone with more experience at theming to look at what exactly this change involves, and then we can update the ticket description with more specific detail.

It would be very nice to use this template to search more than just blog posts, but that scope of change probably needs to wait until 1.4.

[bowromir]

I'll start on updating the search.php template to the standards it needs to have. I'll also ask Brajesh to ask how he pulled of his global BuddyPress search: ​http://buddydev.com/buddypress/creating-the-sitewide-globalunified-search-page-for-your-buddypress-theme/

We might take a few basic aspects and add that to search.php template :) Good idea?

[sbrajesh]

If the core team agrees on including the global search in 1.3, I will be happy to even update it more for better usability. The current search(global search) is already decoupled for each components and we can further enhance it to ajaxify the fetching of other pages (In case of multipages).

[DJPaul]

The priority for 1.3 is to get search.php up to standards. Something to think about utilising search.php more specifically in BuddyPress is, how would the user get there? Via the search box in the top-right of the header? What about support for searching plugins that add stuff to BuddyPress? Or custom post types? I think we should make another ticket to specifically discuss/mockup this type of enhancement.

[modemlooper]

search spotlight mock

[johnjamesjacoby]

Search mockup 1 blessed. If you can tighten up the padding, margins, let's squeeze that in asap.

[modemlooper]

A little more cleaned up.

[modemlooper]

ajax search

[DJPaul]

modemlooper, just to clarify -- are you working on patching these changes?

[modemlooper]

Ok, once more with feeling. Is sbrajesh patching a unified search or is that for 1.4? Do we want a type in a search and via ajax show a spolightish response?

[DJPaul]

Per search mockup 1, that is what I would call a unified search. There are no plans to AJAX the header.php search box for 1.3 (unless someone wants to, but probably best to make a new ticket just for that if serious).

[modemlooper]

Ok, I'll start on it. Header could reuse same code

[sbrajesh]

ohh wow, @modemlooper, very nicely done :)

btw, are you going to work on php or want me to do it ?

[modemlooper]

@sbrajesh Any help would be great if you want. :D

[modemlooper]

Ok, gonna need some help on this. I have no idea how to create a custom search. Was going to use ajax to snatch the content from the url but there are styling issues and It's not going to work the way I thought it would.

Example: ​http://demo.go-themes.com/?s=wwww

What we need is a php file that I can ajax in that loops through each slug search. If this were just blog posts it would be easy but I have no idea to include members, groups or forum topics.

[boonebgorges]

You should probably use the API functions.

• bp_has_groups() takes a 'search_terms' param (searches over name and description, I think)
• bp_has_forum_topics() takes a 'search_terms' param
• bp_has_members() takes a 'search_terms' param as well. Searches over profile data fields

[modemlooper]

oh wow didnt realize there was

if ( bp_has_forum_topics( 'search_terms=searchword') ) .

Is that the right way or is there another?

[johnjamesjacoby]

We will still need to either intercept the normal search _POST param ( 's' ) and replace the guts of the return with our own, or come up with a new, global search variable that we can use instead.

[boonebgorges]

if ( bp_has_forum_topics( 'search_terms=searchword') )

Yes, though you might have fewer troubles with urlencoding if you do
bp_has_forum_topics( array( 'search_terms' => 'searchword' ) );

[modemlooper]

Skipping the /members/?s=

by passing var in url to ?s= then _GET on a loop page. was creating a new file search-loop.php for the results code.

change url param var via jquery and then ajax refresh loop block in page.

Yes, no?

[modemlooper]

Why don't we have a search slug and then put hooks on the end of loop so plugins can add to the search results?

url.com/search?s=searchparam

[DJPaul]

There is a fake "Search" component. Check out bp_core_action_search_site(). It basically redirects to ​http://ursite.com/groups/?s=query (if you wanted to search groups, for example). The groups component then has a piece of code to look at/for the 's' query and filter the results on it. This is how the search box on the Directory screens work.

In future versions, I want to build something like having a one search function to rule them all, which could be implemented into 1.3's component class. There is not enough time to do a proper job on 1.3 for this.

We should be able to build something similar, but less elegant, for 1.3 -- BP.org's search.php has all of the component loops in the same file, one after the other (also, the regular WordPress post loop). We should do this the same, and just put a do_action at the bottom of the file which plugin authors can hook into.

[boonebgorges]

+1 to what Paul said. Do it the easy way for 1.3. Then we can get a real cross-site search function for 1.4. As for the AJAX loop, I would prefer to have a server-side, template-based implementation first. AJAX loading can be added later as a progressive enhancement.

[modemlooper]

too late already have an ajaxy refresh going. type in a letter and you can see. The styling is still the directory loop but you can see it search with ajax refresh.

​http://demo.go-themes.com/?s=wwww

[modemlooper]

First patch files

[boonebgorges]

Thanks, modemlooper. Did you write this against an SVN checkout of the BP trunk? If so, can you cd into that directory and do
svn diff > ~/3240.1.patch
and upload that file?

Otherwise one of us will have to pick the changes out of your zip. No biggie, but it'll save time in the long run if you export a proper diff.

[modemlooper]

Uhm ok never did that before, asked Paul and he said upload files.

[boonebgorges]

Like I said, if you didn't write this against an svn checkout, then don't sweat it. But if you did, it only takes two commands at the terminal to make the diff.

In any case, for future reference, that method is the most time-efficient way. In the meantime I'll just pick out the diff myself :)

[DJPaul]

I have attached a patch version of modemlooper's changes. I've re-ordered the CSS, and cleared a deprecated function warning, but haven't done anything else to it.

[DJPaul]

3240-2.patch tidies up the code style, corrects i18n, checks that BuddyPress components are active, removed redundant actions & form fields. Something I've noticed is that if you search for nothing, you get an empty page.

[DJPaul]

Other areas to look at are spacing between search groups (espc. the last group bottom margin), font size in header, size of form input & button, and RTL.

The search groups' HTML is all different. Some are constructed with divs, others with tables, and others with UL lists. This ought to be standardised.

I think the member search results should be gridded, like the "who's online" widget with captions (user names).

[boonebgorges]

3240-3.patch does a bit of standardization with ULs vs DIVs, and it also makes the ajax work with non-root installations of BP.

If we had unlimited energy and resources, I'd want to rewrite the ajax so that it does a proper request for search data, instead of requesting an entire html page. But as it stands, I think it's a good addition to bp-default.

[johnjamesjacoby]

Right now it appears search is broken all together.

[boonebgorges]

Right now it appears search is broken all together.

Can you be more specific? Normal searches are working fine. ​http://testbp.org/?s=tonight

[boonebgorges]

I've been thinking about this patch, and I think that it is an improvement over what we have, but I feel quite wary of including it in BP without at least some rudimentary pagination.

buddypress.org has one way of doing pagination. See http://buddypress.org/?s=b for an example. Each set of search results has its own pagination, and the whole page refreshes through a click.

Another thought is to put simple "Next" and "Previous" links at the top of the page. However, we'll almost certainly have to make them dumb links - ie, appearing all the time, whether there are more results or not - because there's no way, with the current setup, to figure out whether we should show another page. We'd have to combine all the queries, or something like that.

IMO this is the last real outstanding issue in the way of a beta release. It'd be really great to get some feedback from other devs. I'd like to leave open the possibility that this ticket gets punted to an early 1.3.x release, so we have time to do it properly without holding up our 1.3 beta.

[DJPaul]

After discussion, we've decided to punt this from the 1.3 release. Expanding on what Boone's written above, we think the idea has merit, but we don't have enough development time in 1.3 to iterate on this and properly implement it.

[DJPaul]

This would be a great ticket for someone interested in running with the ideas in this patch and improving the search page. Otherwise, it will get punted.

[boonebgorges]

This is going to get punted again unless someone steps up and cleans it up in accordance with some of the suggestions in this thread.

[DJPaul]

Going to wontfix this as it hasn't gone anywhere in 2 years. It's not worth the time investment and hassle for changing the functionality of the BP-Default theme in our new compat world.