Yet Another Software Blog

Plugins should add content to the RSS feed but only if that is there main function, otherwise they probably should not. Why not? because the main functionality of the RSS feed is to notify a subscriber about new content, while giving him a glimpse of what the content is about.

Most of the plugins which add something to the content displayed on the web page, such as the social bookmarks icons, do not add any new content to the post itself, and therefor they should not be adding anything to the RSS feed.

A typical social bookmarking plugin code looks like

function handle_content($content) {

 $content = $content.'<div><a href="url1"><img src="src1" /></a><a href="url2"><img src="src2" /></a></div>
';
 return $content;
}

Which looks good on the web page, but in the RSS the result will depend on the number of words in the original post. If the original post contained less than 55 words, the extra html which was added by the plugin will be sent as part of the RSS.

The result might be (due to some cleaning that WordPress does)

Original content

<a href="url1"><img src="src1" /></a>
<a href="url2"><img src="src2" /></a>

Which adds two links which are not part of the content. Actually it can be even worse with the extra content being split up and the result is something that resembles junk. That is why the plugin code should look like

function handle_content($content) {

 if  (is_feed()) // do nothing if we are generating a feed
   return $content;

 $content = $content.'<div><a href="url1"><img src="src1" /></a><a href="url2"><img src="src2" /></a></div>
';
 return $content;
}

This way the changes made by the plugin are not seen in the RSS feed. But there always should be an exception, and if the RSS has the full post maybe it does make sense to add the same content to the feed and the post. Add a check of the value of the rss_use_excerpt option, which indicates whether the RSS is full, and the code becomes

function handle_content($content) {

 if  (is_feed() && (get_option('rss_use_excerpt') == 1)) // do nothing if we are generating a feed of excerpts
   return $content;

 $content = $content.'<div><a href="url1"><img src="src1" alt="" /></a><a href="url2"><img src="src2" alt="" /></a></div>
';
 return $content;
}

But what should be done with shortcodes?

I was testing some wordpress optimization ideas which lead me into writing some profiling code which somehow lead me into installing alex rabe’s wordpress memory usage plugin. What especially caught my eye was the test that demonstrated that wordpress with german translation requires 6.5 Megs more then the english wordpress version. I have repeated his test with the hebrew translation and got a difference of about 4 Megs (the difference between the languages can be explained by the fact that german has notoriously long words or the hebrew translation is somewhat sloppy).

This just confirmed something that I have thought for quite a long time but hadn’t figured out how to quantify it. The problem with the wordpress translation process is that you translate the whole of wordpress and generate a single translation file which essential contains pairs of strings and their translation. Then you place your translation in predefined place and wordpress loads the whole translation pairs to the memory when the first string is being translated.

The problem with this approach is that as time passes by, the admin interface accumulates much more translatable strings then the front end functions. Of the ~3200 translatable string in wordpress I guess that no more the 400 are used when the actual HTML for the blog posts is generated. In other words, about 80% of the memory consumed by the translation will never be used for the work wordpress does for the 99% of the incoming trafic.

As if to demonstrate the problem, for version 2.8 the wordpress developers had split the translation file and created a unique translation file for the cities of the world, used when configuring time zone information, which is loaded only in one location in the admin interface and by that saved 400 string from loading at any other page of the site. But then, those strings where actually loaded when you reached that page, and with some help from inefficient PHP code, have caused an “out of memory” php error. The end result was that part of the page did not get displayed and since the error was not displayed, it was really hard to even understand what is the problem, and harder to find its cause.

The whole issue is not being helped by the fact that there is no way to use the PHP gettext module from wordpress without hacking the core. I don’t know how much it will be more efficient but since it is written in the C language it can theoretically use less memory and have a faster response time then the PHP implementation.

Ideal translation implementation will have a single translation file for a single uri, but this is currently far from being practical as it is hard to know all the possible execution paths just by looking and the code, and therefor hard to determine which translations will be required for each uri. Maybe some run-time adaptive algorithm which will compute the translation file while wordpress is executing will give the best approximation to the ideal.

Meanwhile, in the real world, the translation should be separated at least in to two parts – the front end, and the admin. This should be done either by moving all of the admin related string to reside under the wp-admin directory while the front end will be found only under wp-includes directory. Alternatively the wordpress release process should generate two POT files for the release by employing some internal knowledge on which files/strings should be used only at the admin, aknowledge which most of wordpress tranlators lacks.

While this will not necessarily solve the problem of the translation “nuking” the admin interface, it will at least reduce the memory consumption and improve CPU performance at the front end

Note: while caching plugins like super cache can be used to practically ignore this problem, not every shared hosting has the facilities to support it, and it has its own drawbacks which will prevent it from being a bullet proof solution (otherwise its place is in the wordpress core).

Update: Looks like I am not the only one who is bothered by the inefficiencies in the way the translation works. Johan Eenfeldt had created a plugin which provides caching to the parsed translation file. This might not solve my memory related problems (I will have to use the file cache option), but at least it is a performance gain.

So you have a working WordPress based site and you are really happy with it until one day you add some new content and when checking the result you think to yourself “man this design is getting really old and out of fashion”.

What follows is a cycle of redesign which by itself is followed by coding the new design into a theme, and then you reach the point where you like to test your design with “live” data. For small sites it is possible to simply export all the posts, or the entire DB if you have fancy plugins, and import it into your testing environment, but for big enough sites it might be a difficult task running against space and time limitations imposed on the usual exporting tolls.

Hey, who am I kidding, I like any other decent programmer prefer to develop instead of setting up test environments, and the faster I can get my code to the server the better I feel. For me the best thing is to do most of the development on the live server.

The main obstacle for testing new themes on the server is the fact that only one theme can be active at any given time*, which means that you can not test without disrupting the look and usage for the normal users of the site.

To the rescue comes a feature which was introduced in version 2.7 – the theme preview. When you use the themes management it shows you the way the site will look when  you will activate a theme, and this can be used to test a theme without activating it. All you have to do is log in as an admin, or any user which has a ‘switch_themes’ capability, and browse the following url:

Yoursite?preview=1&template={name of template}&stylesheet={name of theme}

Where {name of template} should be replaced with the name of the directory in which the main theme is located and {name of theme} should be replaced if with the name of the child theme being used. If you don’t use a configuration of base and child themes, then you don’t have to specify the stylesheet parameter.

And what about testing the admin related changes if you have any? The only advice I have is to try and avoid the urge to reuse the names of the options which were used in the old theme. In the price of having to do some extra configuration, it will make testing on the server a lot safer and will keep your ability to revert to the old theme at any time.

* One day someone will write a plugin to fix this, but for version 2.8 this is the situation.