Search individual plugin/theme forums

[Daedalon]

There should be options for searching the support forums of individual plugins and themes.

For example if I'm looking for a specific thread of ​Events Manager's ​qTranslate compatibility from September-October last year, ​http://wordpress.org/search/events+manager+qtranslate gives 827 threads. The following options to narrow the list down would be helpful:

• Limit search to one support forum area
• Limit search to topics opened by / replied to by certain users (a comma-separated list)
• Limit time range of when the topic was opened / replied to
• Limit the amount of replies (eg. at least 7, at most 10)

[morktron]

This is a commonly featured request and will save literally millions of people thousands of collective hours searching - I think it should be higher priority ;)

I posted about it here: ​http://wordpress.org/support/topic/ability-to-search-within-a-specific-plugin-support-forum

[AJD]

Agreed! I have been hoping for this for ages.

[sanderbelou]

please make this possible

[jdkoelsch]

I've been wondering about this for years. I thought maybe I just couldn't find it in the interface. Needless to say, this would be very, very helpful.

[karacsi_maci]

Why this feature is not implemented yet? This is a very big lack. And i think, it should be a really high priority task, instead to format the buttons on the dashboard.

[ted.strauss@…]

+100

[zmokin]

It's hard to believe that such a basic function is not available within the support forum. Even the cheapest, most basic forums have this option!

This would cut down on a lot of extra posts and research time (for both users and developers) when looking for answers that may have already been addressed.

Come on WordPress! You folks are so good at everything else, take care of this!

I think the reason there aren't more post for this is that most people are like me - I thought I just couldn't find it in the interface so blamed myself for so long...

Replying to Daedalon:

There should be options for searching the support forums of individual plugins and themes.

For example if I'm looking for a specific thread of ​Events Manager's ​qTranslate compatibility from September-October last year, ​http://wordpress.org/search/events+manager+qtranslate gives 827 threads. The following options to narrow the list down would be helpful:

• Limit search to one support forum area
• Limit search to topics opened by / replied to by certain users (a comma-separated list)
• Limit time range of when the topic was opened / replied to
• Limit the amount of replies (eg. at least 7, at most 10)

[Otto42]

Despite your opinions, this is not something in the forums at present. The support forum for each plugin are not actually forums, they are a special view into the main plugin forum. Thus, there isn't any way to separate them.

Future enhancements may change the way this works.

[Daedalon]

@otto42: Thanks for your reply, it clarifies the issue at hand and finally gives a feeling that at least one core activist has noticed this ticket. As a way to implement this, how about making a search parameter that limits the search to posts that would match the specific view?

As the views have some way of filtering what posts are shown for each support forum, the same should be doable for searching as well. After all, searching is just another way of displaying posts.

As for the priorization, in my opinion this deserves to be the single most important task for the meta team. This has by far the highest impact on the WordPress community.

[Otto42]

Replying to Daedalon:

After all, searching is just another way of displaying posts.

As much as I would like it to be, it really isn't that simple.

As for the priorization, in my opinion this deserves to be the single most important task for the meta team. This has by far the highest impact on the WordPress community.

You're welcome to your opinion, but ultimately, I have to disagree with you here. Search is important, but then again, Google is a thing that exists and they do it better than we can. The new theme directory working, user profiles, plugin enhancements, things like this exist too. There's a number of projects going on, and we work on them all at the same time. Search is indeed something we want to improve, but it is somewhat behind things like "updating the forums to something originally made this decade", sort of thing.

[Daedalon]

As for the priorization, in my opinion this deserves to be the single most important task for the meta team. This has by far the highest impact on the WordPress community.

You're welcome to your opinion, but ultimately, I have to disagree with you here. Search is important, but then again, Google is a thing that exists and they do it better than we can. ... Search is indeed something we want to improve, but it is somewhat behind things like "updating the forums to something originally made this decade", sort of thing.

Thank you for your comment. Google does not currently resolve this issue; that's why this ticket has so many comments from the community. However, I completely agree with the prioritization of updating the forums over this, as that would likely fix this and other issues as well. I know you've been working hard on the theme and plugin directories recently. I hope this would become a priority after the current top tasks have been successfully finished.

To illustrate, I have often posted a question after studying the first 10 to 20 Google results to no effect. Even after this it's common to get a response from the plugin author linking to a post where the question has already been answered.

Quantifying the issue may shed light on the potential effect. Some guesses:

• WordPress.org posts matching the pattern above: 5%
• Time saved in searching, writing, reading and replying: 20min
• Posts on WordPress.org per day: 5k

That gives 5,000 minutes, or 3 days and 11 hours of effort in the WP community daily.

Another perspective is how much time could plugin developers switch from support to development when it's easier for users to find the existing answers. Possibly more than an hour per day for each of the most popular plugins. That has a very positive impact on the community.

[DrewAPicture]

#144 was marked as a duplicate.

[tberneman]

@Otto42: With all due respect, you can disagree with an opinion but one of my pet peeves is a developer telling a user what they need or don't need. Don't you think the user would know more about what they need than you? I am both a user and a developer and I always consider both sides. If multiple users make the same request them maybe you should reconsider your opinion.

This is (IMHO) a major flaw in these "forums". We absolutely do need a way to search by keywords in a particular plugins' support threads. Taking the suggestion of using google, even using the "site modifier" (ex: display checkbox in email site:https://wordpress.org/support/plugin/contact-form-7) returns results that do not match or too few results.

Please do reconsider this request and move to a higher priority. :)

Thank you!

[Otto42]

@tberneman: We will most likely not be adding forum specific searching before we update the forums to the latest bbPress, because doing that will give us better searching for free.

[tberneman]

That is good news! I'm always for not reinventing the wheel so the update will be welcome! Do you have a ballpark time frame for the update? Like next month, or by October 15th, or by the end of the year, etc?

Thanks @Otto42! :D

[samuelsidler]

There is no timeline at the moment. It's a long-term project. Almost definitely not this year.

[tberneman]

OK, good to know!

Also I want to thank you for your prompt and courteous responses!

[SergeyBiryukov]

#315 was marked as a duplicate.

[vasoczki.ferenc@…]

Replying to Otto42:

Despite your opinions, this is not something in the forums at present. The support forum for each plugin are not actually forums, they are a special view into the main plugin forum. Thus, there isn't any way to separate them.

Future enhancements may change the way this works.

In this case, your code design is bad. I think, there are a primary key for each plugin / theme topic in your database, so is it a really hard think to write a " AND id = " . intval($_GETid?)"; ?

[Otto42]

Replying to vasoczki.ferenc@…:

In this case, your code design is bad. I think, there are a primary key for each plugin / theme topic in your database, so is it a really hard think to write a " AND id = " . intval($_GETid?)"; ?

As I stated previously, it is not that simple. The plugins don't have their own individual forums. They have posts in a single forum, with meta data defining which topics go where. Additionally, the current (old) version of bbPress has very poor search capabilities to start with. This is why we have a custom Google search for the main one, instead of an actual search into the forums.

None of this is possible until after the main forums are upgraded to a more recent bbPress. Despite what you think, it's not as simple as just 'writing a query', and regardless, it is not as high a priority as other things on the site.

[spudweb]

+1

[swinggraphics]

it is not as high a priority as other things on the site

I have no idea what the priorities for the wordpress.org are, but from my standpoint as a user, there isn't any as big as making the support topic search usable. This has been true for years. Fancy images for plugin headers? I didn't need that. A bright green box telling me I should search to see if my topic already exists before creating a new one? Like a middle finger to the user. Many developers have notices on their Support pages saying, in effect, "I do not provide support here. Please create an account on my website [sometimes for a fee] to receive support; the WordPress forums are insufficient." I also don't know what's involved in upgrading bbPress, but I think it would be satisfactory to save 0 to 20 of the most recent support topics from any plugin or theme and delete the rest or make them available statically in an archive somewhere. Users create new, duplicate topics trying to get support anyway, primarily because anything beyond the first page isn't practically searchable, so who cares if extant threads cease to exist?

Many thanks to all the volunteers plugging away at this behemoth (the entire wordpress.org) and for providing any kind of a forum to begin with.

[smrgolfer]

If it matters, it's still something people are looking for and would really like...

[TheSupercargo]

Replying to smrgolfer:

If it matters, it's still something people are looking for and would really like...

Agree!

It MATTERS.

So frustrating to be unable to find things. I just found this thread (by accident - trying AGAIN to find a way to search a specific forum). Posted a request for some sort of advanced search function on wordpress support a week ago after having seen people asking for this from two, three, four years back and still nothing.

[aurovrata]

For those of you watching this ticket, I just posted a temporary solution to this problem. You can read about it in the forum,
​https://wordpress.org/support/topic/solution-for-searching-plugin-specific-support-thread?replies=1#post-8217320

[madvic]

Yes yes et reyes !

[dreagose]

I was asked to post my complaint here on having a search feature for individual plug-in's.

the plug-in I was having an issue with had over 60 pages of stuff I had to roll through only to find that there wasn't anything there to help with my problem.

I had tried the available search but it was searching EVERYTHING and again, had to roll through pages of stuff to again come up empty handed.

so, here is my plea - PLEASE make it possible to search the forums for individual plug-ins, etc so that valuable time, and hair can be saved. Also, eye strain can be prevented.

[Otto42]

#2105 was marked as a duplicate.

[planetside]

Sweet jesus, we need search for individual plugin support forums! Wordpress development is rapid and impressive, yet this request has been sitting here, unaddressed, for 3 years? Confusing and disappointing.

[lukecavanagh]

Could not work out why this was not possible yet.

Was on a plugin support section, I just needed to find out if it that plugin extended out WP-CLI but then realized, that there was not a way to limit the search just to the support posts of that plugin.

[Otto42]

At this time, we do not have *any* search solutions available for large scale searching on WordPress.org.

As you may have noticed, the main site search is a Google Custom Search, not something native to our system.

Additionally, in the past, the forums were running older outdated versions of bbPress. Not very amenable to searching them.

And while we have now updated the forums and the themes directory to run on WordPress itself, the built in search functionality for WordPress is not suitable for the scales we're talking about here. While the themes directory search works just fine on a few thousand themes, the Support forums has more than 6 *million* posts in it. WordPress' search simply doesn't scale that well.

At this time, work is being done on the plugin directory and migrating it to WordPress. Now, as part of that process, search for plugins is being improved to use ElasticSearch. This required a fair amount of effort and help from our friends at Automattic, and they are currently working out problems of scaling for that.

Once that new plugin directory launches, then we hope to be able to use some of that code and effort and experience gained to index the support forums as well. Then we'll be able to implement something like this.

But it is slow going and we take things one step at a time. The lack of refined search is annoying, but it is not a usability deal-breaker at present. Getting the forums updated (done) and getting themes and plugins also updated (done and in-progress) are necessary first steps to do any further development. Search would not be possible without migrating these systems off of 10-year-old software.

So yes, we know. We have not forgotten about this ticket or the needs of our systems. We're working on it.

[lukecavanagh]

@Otto42

Hopefully ElasticSearch will help, but 6 million records is a lot of data to deal with in the index for sure.

​https://discuss.elastic.co/t/retrieving-over-a-million-records-in-elasticsearch/41339/3

[tberneman]

With Google you can search a site for a term. For example, to search the Relocate Upload plugin the term "custom folders" you would type this into Google's search box:

site:https://wordpress.org/support/plugin/relocate-upload "custom folders"

GLHF

[SergeyBiryukov]

Replying to tberneman:

With Google you can search a site for a term. For example, to search the Relocate Upload plugin the term "custom folders" you would type this into Google's search box:

site:https://wordpress.org/support/plugin/relocate-upload "custom folders"

That was my initial thought as well, but it would only search that particular page. Individual topics have a different URL structure, e.g. ​https://wordpress.org/support/topic/missing-backslash/, and don't have plugin name in the URL.

That said, I think we could significantly improve current results with 7.patch​ for now.

It adds a "Search this forum" form on plugin- and theme-specific views: 7.PNG​, and then uses the plugin or theme name as intext parameter in the search query passed to Google.

Using Jetpack's forum as an example, this produces much more relevant results:

https://wordpress.org/search/Markdown+stopped+working+intext:%22Plugin:+Jetpack+by+WordPress.com%22/?forums=1

than this:

https://wordpress.org/search/Markdown+stopped+working/?forums=1

[SergeyBiryukov]

In 5162:

Support Forums: Add a search form to plugin- and theme-specific views.

Add support for intext parameter in the search query passed to Google.

See #7.

[SergeyBiryukov]

In 5163:

Support Theme: Add "Search this forum" form to plugin- and theme-specific views.

Use the plugin or theme name as intext parameter in the search query passed to Google.

See #7.

[Starbuck]

I'm rather passionate about this problem. We all get frustrated by inability to find information and tons of duplication of requests in the forums. The following notes can be used right now to effectively search this site. I'm hoping we can vet this content, post it to a FAQ on the site, then link to it from all Search boxes. Other solutions like a replacement for CSE or a new database would still be welcome, but the following requires almost no effort for immediate and effective results.

---

The WordPress.org site uses a Google Custom Search Engine (CSE) which applies custom rules to queries entered in search boxes on this site. While the rules filter the content that's found here, entering plain-text in the search box is subject to default Google search rules, which doesn't help people here to find content that is in specific desired locations. Examples of those locations include specific forums, support threads, plugin reviews, and the plugin repository. The following tips will help you to find the information you are looking for, at least until a different search engine is implemented here, or until the default Search UI can be replaced with one that removes a visitor's need to know these site-specific rules.

This documentation uses the well-recognized Yoast SEO plugin for examples, no recommendation or promotion is implied.

Searching Plugin Support Threads

When you do a Search in the Support area for a plugin, your text is augmented with a modification to help narrow the search. So a search for 'taxonomy' gets modified to this:

taxonomy intext:"Plugin: Yoast SEO"

That tells the CSE to narrow the search to only pages that have specific text on the page. All Support pages have the text "Plugin: " followed by the plugin name.

At this time that shows 10 pages of hit results. To narrow that down add the following to your query:

inurl:"support/topic"

Because this site puts all support posts into a permalink with "support/topic", specifying that URL restriction eliminates anything else the CSE added into the result set. You may note at some point that in the text "support/topic", the slash gets converted to a space by Google, so either slash or space works there.
That narrows the results down to 5 pages, all of which have just the desired information.

Using Google.com to Search Support Threads
If you want to use Google.com to do your searches, you need to use all of those parameters:

taxonomy intext:"Plugin: Yoast SEO" inurl:"support/topic"

But you also need to specify the site you want to search:

site:"wordpress.org"

The Search results from both the CSE and Google.com often include user profiles and non-English results. So add this into the search box with the query:

-site:"*.wordpress.org"

Notice the '-' before the parameter. That removes subdomains which clutter the results. (Specifying the www sub-domain does not return results from just the root domain.) If you want the results from a specified domain and/or language, use site parameters to specify what you do and do not want.

So for Google.com, we're looking at this to query for support topics:

taxonomy site:"wordpress.org" -site:"*.wordpress.org"
intext:"Plugin: Yoast SEO" inurl:"support/topic"

That query returns just 2 concise pages.

Finding Reviews

There are two primary views of a post in WordPress, the Archive and the Post page. To find archives of Yoast reviews that mention "useful":

site:wordpress.org -site:"*.wordpress.org"
"inurl:plugin wordpress-seo reviews"
-inurl:feed intext:useful

The site params are consistent with those above. Note the difference here between specifying a plugin ID as a part of the InURL value, and the plugin Name within the text of the page.

While the URLs for review archives begin "/support/plugin...", we can ignore that detail for now.

The "-inurl:feed" value says "we do Not want the word 'feed' in the URL". Notice the '-' before the parameter.

Rather than just using "useful", this query uses "intext:useful". That eliminates many duplicate hits, and narrows the results down to just a few actual posts. When doing your queries, just use the text you need but you may find it helpful to also try using the intext filter.

Googling through the archives can be frustrating. The results contain the pages as they were when they were crawled. Since the details in archive pages shift, it's frequently going to be inaccurate. The results also just get the titles, so if your search term isn't in the title it might not be in these results. So we need to see review posts too.

If you look at the URL for a review post, it's exactly like a support post. You can't tell the difference from the URL. The only visual artifact on a post page that distinguishes a support post from a review post is a bit of text on the page. So we look for a support post as above, but add refinement to see just reviews:

site:"wordpress.org" -site:"*.wordpress.org" inurl:"support/topic"
intext:"Plugin: Yoast SEO" intext:"In: Reviews" useful

If you change "In: Reviews" to "In: Support" you'll find that you get completely different results where the word "useful" is used in support topics. Because of this, it's advisable to use these intext values in queries to filter your results for support topics.

Narrowing Support/Review Posts by Time

We frequently want to narrow down searches to recent posts, as old issues may have been fixed and no longer apply to our current challenge. You can append a year range to the end of the query, separated by a dash. For example:
2016-2017 or 2017-2017

Just adding the text "2017" into the query will return anything that has the number 2017 in it, which is probably not desired. At Google.com, narrowing down to specific date ranges is currently inconsistent with this data. Try going to Google's Advanced search to see if it helps you find results within desired date ranges.

Non-Plugin Forums

Here's an example to look within a specific support forum:

site:wordpress.org inurl:"support/topic" intext:"Developing with WordPress" permalink slug

That returns only 2 pages of on-topic search result goodness from the desired forum.

Note that the text on the page is actually "Support » Developing with WordPress". For some reason that character cannot be used with intext, and leaving it out results in zero results. If intext:"some forum name" turns out to be common text, you can try to narrow the search using this example:
"Support * Developing with WordPress" permalink slug

There we see an asterisk being used as a wildcard, so the word "Support" must be followed by 'something' which must then be followed by the rest. The text in quotes must be found together, and the text outside of quotes can be found anywhere on the page. This is basic Google syntax but usage of the asterisk is unusual and may be very helpful here.

Summary

The Google CSE on WordPres.org (and all sites that use it) pre-filters content, but site-specific nuances require crafting of the queries that are ultimately processed. Users typing into a Search box shouldn't need to be masters of Google-Fu to find content, so it would be ideal if a plugin could be used to serve as a front-end for this syntax. (That's a huge hint to aspiring and talented developers.) Until then, while we're all frustrated with the defaults we have available now, the tips provided here should allow everyone to find answers to questions before posting what may be a repeat of repeats of postings of the same topic on this site.

---

I can add more content for finding plugins and themes but the mechanisms in place are adequate.

Verification, comments, and suggestions are most welcome. I hope this goes somewhere in one form or another. Thanks

[tellyworth]

There are good suggestions here, but I think it's best to close this ticket now that a workaround has been implemented for the reported problem, and open new tickets for specific issues under the Improved Search milestone.