Skip to:

Opened 13 years ago

Closed 11 years ago

Last modified 8 years ago

#3240 closed enhancement (wontfix)

search.php functionality needs updating

Reported by: djpaul's profile DJPaul Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.2
Component: Templates Keywords: has-patch


Review feedback says that search.php needs updating pretty heavily, as explained at

Looking at the file history,, it hasn't really been touched since it was created.

Attachments (7)

search-mockup-modemlooper-1.png (163.9 KB) - added by modemlooper 13 years ago.
search spotlight mock
search-mockup-modemloper-2.png (110.3 KB) - added by modemlooper 13 years ago.
search-mockup-modemloper-3.jpg (102.2 KB) - added by modemlooper 13 years ago.
ajax search
BuddyPress (4.8 KB) - added by modemlooper 13 years ago.
First patch files
3240-1.patch (11.5 KB) - added by DJPaul 13 years ago.
3240-2.patch (12.7 KB) - added by DJPaul 13 years ago.
3240-3.patch (13.6 KB) - added by boonebgorges 13 years ago.

Download all attachments as: .zip

Change History (48)

#1 @DJPaul
13 years ago

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.

#2 @bowromir
13 years ago

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:

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

#3 @sbrajesh
13 years ago

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).

#4 @DJPaul
13 years ago

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.

#5 @DJPaul
13 years ago

  • Owner set to bowromir
  • Status changed from new to assigned

13 years ago

search spotlight mock

#6 @johnjamesjacoby
13 years ago

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

#7 @modemlooper
13 years ago

A little more cleaned up.

13 years ago

ajax search

#8 @DJPaul
13 years ago

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

#9 @DJPaul
13 years ago

  • Owner changed from bowromir to modemlooper

#10 @modemlooper
13 years ago

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?

#11 @DJPaul
13 years ago

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).

#12 @modemlooper
13 years ago

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

#13 @sbrajesh
13 years ago

ohh wow, @modemlooper, very nicely done :)

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

#14 @modemlooper
13 years ago

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

#15 @modemlooper
13 years ago

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.


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.

#16 @boonebgorges
13 years ago

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

#17 @modemlooper
13 years ago

oh wow didnt realize there was

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

Is that the right way or is there another?

#18 @johnjamesjacoby
13 years ago

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.

#19 @boonebgorges
13 years ago

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' ) );

#20 @modemlooper
13 years ago

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?

#21 @modemlooper
13 years ago

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?

Last edited 13 years ago by modemlooper (previous) (diff)

#22 @DJPaul
13 years ago

There is a fake "Search" component. Check out bp_core_action_search_site(). It basically redirects to (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 --'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.

Last edited 13 years ago by DJPaul (previous) (diff)

#23 @boonebgorges
13 years ago

+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.

#24 @modemlooper
13 years ago

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.

13 years ago

First patch files

#25 @boonebgorges
13 years ago

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.

#26 @modemlooper
13 years ago

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

#27 @boonebgorges
13 years ago

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 :)

13 years ago

#28 @DJPaul
13 years ago

  • Keywords dev-feedback has-patch added
  • Version changed from 1.3 to 1.2

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.

13 years ago

#29 @DJPaul
13 years ago

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.

#30 @DJPaul
13 years ago

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).

Last edited 13 years ago by DJPaul (previous) (diff)

#31 @boonebgorges
13 years ago

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.

#32 @johnjamesjacoby
13 years ago

Right now it appears search is broken all together.

#33 @boonebgorges
13 years ago

Right now it appears search is broken all together.

Can you be more specific? Normal searches are working fine.

#34 @boonebgorges
13 years ago

  • Severity set to normal

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. has one way of doing pagination. See 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.

#35 @DJPaul
13 years ago

  • Keywords dev-feedback removed
  • Milestone changed from 1.3 to 1.4

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.

#36 @DJPaul
13 years ago

  • Type changed from defect to enhancement

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.

#37 @DJPaul
13 years ago

  • Owner modemlooper deleted

#38 @boonebgorges
13 years ago

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.

#39 @boonebgorges
13 years ago

  • Milestone changed from 1.6 to Future Release

#40 @DJPaul
11 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

#41 @DJPaul
8 years ago

  • Component changed from Appearance - Template Parts to Templates
Note: See TracTickets for help on using tickets.