How to make taxonomy pages appear as result in wordpress search

In addition to many other drawbacks wordpress search has it just can’t search the description associated with a taxonomy (category, tag) or author, so even if the most obvious search search result is the category page, the internal search will never show it.

But there is a way to hack around it if you really have to. All that needs to be done is to have a page with the exact same URL as a taxonomy.

If you which for the category “events” to be searchable, assuming its url is /category/events, all you have to do is to create two pages, one with the slug “category” and a sub page of it with the slug “events” and put the text associated with the category in the “events” page.

The only problem is that the search result will be styled like a page, but this is a small price to pay.

In wordpress, pages can have whatever URL you want them to have

For all content types  except pages wordpress uses a system of patterns to identify from the structure of the URL itself which type of content is being accessed. Once identified it can know in which part of the DB it should look for the content associated with the URL.

This is the reason why you usually should have a prefix “directory” in the URL which uniquely identifies your content. If there are two possible interpretations wordpress will match the first that is found.

Pages are different. WordPress kind of assumes that by default all content in the site is pages and the parsing rule for page URLs is “if it is not something else it might be a page”.

This lets you place pages anywhere in the URL structure. Here the question was about having an Event/post_slug URL for posts and have also an Event/Contact URL for a page. To do that you just need to have a page with a slug Events and a page with a slug Contact as its sub page.

As long as there is no post with the slug contact, when wordpress get a Events/Contact URL it tries to find a post in the events category with the slug Contact, and if there is none it will try to find a page with the slag Contact under a page with the slug Events and BINGO.

Two problems with this approach. Neither of them is probably major enough to prevent to use of this technique

  1. For every URL of the structure Events/xxxx where there is no post with the slug xxxx, wordpress will have to make another DB query to check if there is a page with the slug xxxx under the page with the slug “Events”
  2. You always have to remember not to create a post or subcategory of the category “Events” with the slug  “Contact”. If you do that you page will not be access and you will not have any warning about that.

WordPress plugins and themes do not have to be GPL since the court ruled that APIs are not copyrightable


  1. I don’t like GPL, I think that for most places that it is being used at, especially in wordpress, the BSD license would have served as well and would have removed the illusion that just by selecting a restrictive license your code becomes less prune for IP theft.
  2. Matt Mullenweg created a great product and succeeded to maintain a great community around it. So far his insistence on GPL everywhere haven’t really hurt either of them and maybe actually strengthened them.

It seems like once a year there is some form of debate about wordpress, GPL and whether people might develop software related to wordpress which does not use a GPL compatible license. This time it is about whether people selling themes/plugins under split license (one for code and another for styling) should participate in wordcamps.

Maybe it is time to take one step back and ask again whether themes and plugins have to be GPL compatible.

The legal base for the claim is this legal opinion from James Vasile of the Software Freedom Law Center. There are two things to notice

  • By law a lawyer have to help his client to present the best legal case for his objective. If I had the money I could find 10 lawyers which will contradict every second word in that post.
  • After many bold claims the last paragraph backtracks from it all

    Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.

But the most important thing to know about lawyers opinions is that they are always not much better then a guess and only the court can actually decide what is the correct legal interpretation of a legal situation. Lawyers can “guess” much better when there are precedences, but there where no court cases revolving around the nature of derivative work similar to wordpress plugins and themes that I know of (and I’m sure the lawyer would have cited them if he was aware of any).

Well, in may 2012 there was a ruling about a similar issue, whether API is copyrightable.In the legal battle between Oracle and Google about the use of java derivative in the android OS. Oracle claimed that just because Google implemented the same API that java has, without a license from Oracle, it infringed on its copyright. This claim was dismissed in court, but it has more to it then that, and according to the report the judge had set a limit to when a derivative work do not inherit the license of its origin.

Ninety-seven percent of the source code in the API packages is different; it’s only the three percent that overlaps that formed the heart of Oracle’s copyright claim. That three percent included packages, methods, and class names. But those declarations—like starting a function with package java.lang—can only be used in certain ways. “In order to declare a particular functionality, the language demands that the method declaration take a particular form

Therefore claiming that just because some lines of code are similar in all themes to the GPLed themes provided as part of the wordpress distribution as Mark Jaquith says

If that argument doesn’t convince you, then note that the vast majority of themes derive from the original WordPress core themes. How they load different PHP subfiles, loop through posts, and get and interact with WordPress data is all covered by the original WordPress core themes, which are explicitly GPL

Doesn’t hold water unless there is some different way to use the wordpress API, which there isn’t. Big part of the PHP code in many themes is identical because there is either no other way to perform a specific functionality, or it is the best practice.

In my opinion the wordpress foundation (or or whoever is talking for wordpress) might have a right cause, but they win the fights because they have bigger sticks, and not because the law is on their side.

Writing a translatable library/framework that is used by wordpress plugins and themes

I got burned in the wordpress stack exchange while answering a question about variables in translatable text, which was really more about adhering to (IMO wrong) theme repository conventions while using third party code which doesn’t use them. My mistake came from misinterpretation of the translation strategy the third party code being used (the TGM plugin activation library) was using.

There are twp possible translation strategies for such libraries, self contained and integrated.

In the self contained strategy the library is distributed with the translations of its strings, using a specific text domain for them. The theme/plugin author using the library just needs to include it and initialize it.


Assuming the library expects its translation file to be in the “lang” sub directory of its root it only has to do

function useful_lib_init() {

and use “useful_lib” as its text domain whenever the translation functions ( __(), _e()…) are called.

The advantage of this approach is that whoever uses the library don’t need to worry about the translation of the strings used in the library, and once a translation is updated he can simply include the new version of the library and push an update.

The disadvantage is that you don’t have full control over the translation of your theme/plugin (you can claim it works in language X only if  the library supports the language as well) and you have to communicate to translators that the files residing in the “useful_lib” directory should not be translated as it will have no impact on the result (maybe suggest to the translator to contribute the translation to the library).

In the integrated strategy you let the theme/plugin determine which text domain to use. The easiest way is by forcing them to DEFINE it.

if (!defined('USEFUL_LIB_TEXTDOMAIN')) {
  error('USEFUL_LIB_TEXTDOMAIN had to be defined');
// then you have in the code

This way there is some duplicated translation effort between different users of the library, but the end result is totally under the contrul of the theme/plugin author.

And…. there can be an hybrid approach. If no explicit text domain is specified use our own, just need to remember to load the text domain

if (!defined('USEFUL_LIB_TEXTDOMAIN')) {
// then you have in the code

In my opinion, libraries should follow the “integrated” strategy unless they have non trivial amount of translatable strings, and the maintainers are willing to maintain the translations as part of the library.

As for the hybrid approach, I don’t see any real life use case for it. If library can be used as “self contained” it is probably better to use it that way, and get automatic translation updates whenever there are, instead of asking your theme/plugin translators to retranslate just because there was a change in the library.

BTW, my failing was due to the library in that question using the hybrid strategy while I thought it is a “self contained” because I failed to notice the text domain initialization variants, and this calls for an article about how wordpress theme and plugin writers misuse the OOP paradigm….

Nice touch to the wordpress iphone app, it opens the admin at the right page if it detects that XML-RPC is disabled. Which makes me wonder why it doesn’t go all the way and submit the changed setting, or at least highlights/explains what shoud be changed.

You can’t disable pingbacks in wordpress :(

Yeh, the best that you can do is not to display them. All the site wide and per post options control whether the pingback/trackback will be stored in the DB, but the piece of code handling pingbacks from reception till checking if to put them in DB will always be executed.

This is probably not a big thing as I don’t remember exploits utilizing pingbacks, but it annoys me esthetically that an option  described “Allow link notifications from other blogs (pingbacks and trackbacks.) ” doesn’t do what can be interpreted from the description (what it does is to set the default of the ping option on the post edit page).

The decision to enable xml-rpc remote publishing support by defualt in wordpress 3.5 is good, but the execution is lacking

xml-rpc protocol is basically used to expose a set of API implemented by a site/server which enables other software to interact with the site/server in a way which is easier to program then trying to mimic user interaction. WordPress currently (version 3.5) expose API for publishing pingbacks, and content. Software like windows live writer by Microsoft uses the content publishing API supplied by WordPress to create a non browser editing environment, but the main users of the protocol right now are smartphones because the small screen size makes the WordPress web interface almost unusable.

Upto WordPress version 3.4 the remote publishing by XML-RPC was disabled by default, and the text explaining the option in the admin was technical and said nothing about smartphones.

With the rise of smartphone use, and the number of smartphone apps that use XML-RPC to publish content to wordpress, it is only a logical move to enable XML-RPC by default, but the development moto of “decisions not options” was taken too far as in this case the option has enough importance to justify having it.

The reasons are mainly security related

  1. It doesn’t matter how robust is WordPress code there is always a chance of a security bug that might relate only to the XML-RPC code
  2. Plugin authors will probably start supporting XML-RPC opening more attack vectors, and user will not even know about it because it will not have any GUI indication, and you will not know that unless you read the plugins documentation.
  3. There is no knowledge base on how to defend against brute force/dictionary attacks from XML-RPC. Current plugins might work,but will they give you a notice like “You failed to login 3 times, please wait 5 minutes till the next attempt” on the XML-RPC layer, and how the app will display that notice?

It might be that core developers are right and there is no risk added by having XML-RPC on all the time, but I think that a more conservative two step approach like

  1. Make it default to on, leave the option in the admin
  2. In two releases look at the experience of running WordPress that way and decided whether to eliminate the option as well

The reason it should work that way is that most user just leave the default setting on, so there will be a big enough user base to field test the feature even when the option to turn it off exist.

WordPress settings API is PITA

The WordPress settings API is there to “help authors manage their plugin custom options“, but does it? Many lengthy tutorials pointed to from the codex hints that the answer is probably “not really”. To quote Olly Benson from yet another settings API tutorial/example (emphasize mine)

WordPress does make a habit of creating mountains out of molehills sometimes, and the Settings API seems to be a fantastic example of this.  Trying to follow the instructions on the initial page got me hopelessly lost, and it was only when I went through Otto’s WordPress Settings API tutorial that I begin to understand how to implement it.

And the problem is not with the codex, the problem is in the structure of the API itself. Instead of having a simple fast and dirty code like


function my_init() {

function my_options_page() {
if (isset($_POST['my_value'])) {
Enter value <input type="text" name="my_value" value="<?echo get_option('my_option')?>

Where all the logic of handling the change of values is placed in the same place as the presentation, the my_options_page function, which makes it much easier to understand and debug.

The settings API basically moves your options handling away from your presentation code. To use it you need to call at least 3 initialization functions to which you have to supply 3 callback functions, and all the handling is done in a “black box” that doesn’t give you any hint for misconfiguration and it is hard to debug.

When trying to use the API I end spending more time to make myself feel good about following coding best practices then needed to code the same functionality in an equally accessible and secure way.

__return_false and its siblings are great way to provide callbacks that do nothing in wordpress

Some of the wordpress API functions like add_settings_section require that one of their parameters will be a valid callback function. If your callback does not suppose to do a thing then you can simply use __return_false that immidiatly returns false as the callback instead of declaring a dummy callback by yourself.