Category: WordPress

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

add_action('admin_init','my_init');

function my_init() {
add_page('title','title',10,'my_options_page');
}

function my_options_page() {
if (isset($_POST['my_value'])) {
validate_value();
update_option('my_option',$_POST['my_value']);
}
<form>
Enter value <input type="text" name="my_value" value="<?echo get_option('my_option')?>
</form>
}

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.

Trash emptier wordpress plugin

The trash was introduced in wordpress version 2.9, and the operations of deleting posts (all types of post types) and comments was replaced by sending them to the trash. Actual deletion from the DB is done through trash management which is separate for each post type and comments. In addition an automatic process empties everyday all trashed items which where in the trash from more then 30 day. read more about the trash feature in the codex.

The plugin has two function

  • Provides a way to conctol the maximal amount of time an item will be kept in the trash before being deleted as an alternative to defining the EMPTY_TRASH_DAYS constant in your wp-config.php file. You can have the automatic trash empty performed faster, or set such a riciculously long interval that essently makes emptying the trash a puerly manuall operation.
  • Manually empty item from the trash based the time they been there.

Installation

  1. Download it from the repository
  2. Using your favourit FTP software upload the emptytrash folder into your site /wp-content/plugins directory
  3. go to the plugin management page and activate.

Usage

  • To Manually empty the trash go to the “Tools” >> “Trash emptier” menu
  • To configure the automatic emptying interval go to “Options” >> “Trash emptier”  menu

If you find this plugin usefull, don’t forget to donate

I will be very surprised if I will receive enough donations to cover the cost of the effort in designing, coding testing and supporting this plugin.but it is a nice sign of appreciation for my work.

Localizing/Translating wordpress plugins and themes names and descriptions

Cool small localization feature that WordPress has is the ability to localize/translate the meta data of a plugins and theme. If plugin and theme authors will actually use it, it will enable localizers to provide a totally localized experience to the users even on the plugin and theme management pages.

This feature is very easy to activate, you should just add two lines into your plugin or theme header block

Text Domain: mytextdomain
Domain Path: lang_folder

where “Text domain” (mytextdomain in this example) is the text domain you used for your plugin/theme localization in the __e() and __() calls, and “Domain path” (here it is lang_folder) is the directory under your plugin/theme root directory in which the *.mo file resides.

For plugins, you can localize Name, PluginURI, Description, Author, AuthorURI, Version. For themes, you can localize Name, Description, Author, Version, ThemeURI, AuthorURI, Status.

While localizing Author info is probably not very moral, and localizing version probably not very smart, it is possible to localize the PluginURI and ThemeURI so they will point to a support/info URL relevant for that local. In other words, a plugin/theme developer can set up support page in english and another one in spanish, and use localization to point the spanish users to the spanish support page instead of the english one.

The only problem left is how to put those strings into your *.pot/*.po file.

For the plugin header below

Name: Plugin name
Description: Plugin description
Author: me
Version: 1.0
PluginURI: http://example.com/plugin
Text domain: mytextdomain
Domain Path: /lang

you can add the following code which enables the localization of only the name and description of the plugin. The location of this snippet in your code is not important as long as poedit can parse the file and conclude that ‘Plugin name’ and ‘Plugin description’ are translatable strings

_plagin_header_local = array(
__('Plugin name','mytextdomain'),
__('Plugin description','mytextdomain')
);

There are also other methods to achieve the same effect.

Relevant reading: Jacob Santos and Viper007Bond wrote on this feature.

Should you optimize your wordpress MYSQL tables? (probably no)

While it looks like a no brainer (you only need press one button  to optimize. so why not), the consensus between the mysql experts tend to discard the usefulness of optimizing as a way to improve your wordpress performance.

The real question here is not if optimizing is good or bad, but whether you should dedicate in advance time to perform it. And since while the table optimization is done the site should be offline, does the benefits are high enough to justify it.

What the optimization does it to defrag the files used for the table and rebuild the index. defraging might save some space on your harddisk, but will not impact your site’s performance. The index rebuild potentially can improve performance but in practice it rarely does so, especially for the small sites which is probably 99.9% of the stand alone wordpress sites in the world.

For people managing wordpress networks it might be more complicated as the defrag benefits might accumulate to something substantial, but I have a feeling that whatever the benefit will be, the time and effort needed to communicate to your users that their sites will be down will outweigh them.

Maybe this is something that you should do only when you are already performing site maintenance for other reason like version upgrade.