[wp-docs] dedicated Codex search function

Wed May 2 18:53:40 UTC 2012

Yes, I do think that on a limited scale, a search box that only searched
the Codex should be very doable and would be helpful to most people.

Speaking for myself, I use a browser search bar that posts to
codex.wordpress.org/?search=, and the results I get are very helpful to me.
Being able to type in something like "Settings API" and get to the Codex
page with no clicks saves me tons of time when I'm trying to look something
up quickly. Definitely better than using the slow Ajax Google search when I
know I just want to find the Codex article.

The biggest problem there is setting up redirects from all the possible
search terms to the proper Codex article; there would need to be a whole
lot of redirect pages set up.

The simplest ones (looks like there are 500-1000 of these) are the function
names and so on:

     {function name} to {prefix ie Function_Reference, Template_Tags,
etc.}/{function name}

Creating these could be easily automated, and I can volunteer to do it, if
the docs team approves.

Then there is a more editorial process of creating redirects from common
search terms to the most appropriate page, ie. "Spam" to "Combating Comment
Spam". This requires more knowledge about which articles are good and
regularly updated, and probably some metrics of the most commonly searched
terms. Some of this could be automated or taken on by someone like me, but
some might need more of a committee to make decisions.

I guess my question is: does anyone see objections as to why these redirect
stubs shouldn't be created? I don't personally see any issues with it, but
I haven't been working on the Codex very much yet, and I don't want to add
things to it that someone with a broader vision of the project thinks is a
bad idea.

Thanks,
Than

Nathaniel Taintor, Designer/Developer
*Golden Apples Design*
http://goldenapplesdesign.com

@GoldenApples | 717.434.3226
goldenapplesdesign at gmail.com

On Wed, May 2, 2012 at 10:24 AM, Lorelle on WordPress <
lorelleonwordpress at gmail.com> wrote:

> This would be so awesome. Our MediaWiki is integrated into the entire
> site, and at one time we had search options set that when you are in the
> Codex you only search the Codex and when you are out of the Codex, your
> search covers everything. The attempt has been made to open the search to
> everything, and it is a mess with Google. A perfect search result would be
> one that divided up the resulting content into Codex, Forum, etc. giving
> more choice control to the user.
>
> That's the goal, but is it possible between the WordPress and MediaWiki
> interfaces? It sounds like you think it is.
>
> The Docs team only has so much control over these things, so hopefully
> someone with the ability to engage at the higher authority level on this
> will jump in. You got my support. This has been a thorn for a long time.
> Thanks for being willing to take it on.
>
> Lorelle
>
>
>
>
> On Tue, May 1, 2012 at 12:09 PM, Nathaniel Taintor <
> goldenapplesdesign at gmail.com> wrote:
>
>> Hi all,
>>
>> The existing search functionality on wordpress.org has been bugging me,
>> and apparently other people as well, for quite a while, and I would like to
>> work on helping to fix that - especially in helping to provide a specific
>> Codex search functionality.
>>
>> MediaWiki already has a decent search ability, which redirects to the
>> found page if an exact match for the search term is found in a page title.
>> Exposing this functionality would be an improvement over the current
>> situation: eg. compare the results of "
>> http://codex.wordpress.org/?search=posts" vs "
>> http://wordpress.org/search/posts". In my opinion, just offering a
>> "Codex search" box which used the MediaWiki search results, rather than the
>> Google results that appear now, would be helpful for most users trying to
>> navigate the Codex.
>>
>> The situation gets trickier, however, with the entries which are prefixed
>> with Function_Reference/, Class_Reference/, etc. Look at the search results
>> found, for example, for "
>> http://codex.wordpress.org/?search=wp_remote_post". Not so pretty... And
>> its kind of hard to programmatically determine, for example whether a
>> search term should be prefixed with "Function Reference", "Function API",
>> or whatever else.
>>
>> Overall, this means that the Codex is not as useful to developers as it
>> could be. When I'm working, for example, I depend on DuckDuckGo's bang
>> syntax search often to quickly look up manual pages for functions, and the
>> experience looking up WordPress functions is definitely subpar as compared
>> to other environments. When I'm searching for PHP functions, like "!php
>> array_merge", the experience is a quick zero-click lookup. It would be nice
>> to have that same experience in the WP Codex, like if searching "!wp
>> register_post_type" would bring me directly to the relevant Codex page.
>>
>> What is the solution to this? Does it make more sense to create redirect
>> pages for every function name indexed in the codex, ie creating a page
>> called "register_post_type" with the content "#REDIRECT
>> [[Function_Reference/register_
>> post_type]]", or is there an extension that will make searching more
>> user-friendly?
>>
>> I'd like to work on this, but I'm not sure what discussions and decisions
>> have already happened. Can someone point me to a helpful way to contribute?
>>
>> Thanks in advance,
>>
>>
>> Nathaniel Taintor, Designer/Developer
>> *Golden Apples Design*
>> http://goldenapplesdesign.com
>>
>> @GoldenApples | 717.434.3226
>> goldenapplesdesign at gmail.com
>>
>> _______________________________________________
>> wp-docs mailing list
>> wp-docs at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-docs
>>
>>
>
> _______________________________________________
> wp-docs mailing list
> wp-docs at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.automattic.com/pipermail/wp-docs/attachments/20120502/b588e51c/attachment.htm>