Tag: WordPress Development

After reading Pippin Williamson’s post about gettext speed issues, I wanted to learn more. My IDX+ plugin has 815 translatable strings, and I was worried that it was having a performance impact on the plugin.

I created a test that looped through different methods of outputting and printing strings to try and determine their relative speed. WordPress uses different functions for translating strings, as documented in the Codex, and I included __() and _e(), the functions I use the most often.

Here are the results of a 100,000-iteration loop:

echo 'Test': 0.1786 seconds

$out .= 'Test': 0.2454 seconds (37.4% slower)

__('Test'): 0.5301 seconds (196.8% slower)

_e('Test'): 0.5639 seconds (215.7% slower)

echo __('Test'): 0.5722 seconds (220.4% slower)

__('Test', 'test'): 0.5743 seconds (221.6% slower)

_e('Test', 'test'): 0.6076 seconds (240.2% slower)

echo __('Test', 'test'): 0.614 seconds (243.8% slower)

$out .= __('Test', 'test'): 0.6885 seconds (285.5% slower)

“Findings” (non-scientific)

Contrary to what I had read, echoing inline was by far the fastest method.

Adding a domain (the second parameter) to translation functions slows the functions down a bit.

Storing strings in a variable after using __() is slow.

All times are well below 1/10th of a second when translating 10,000 strings instead of 100,000.

Conclusion

Although translating 100,000 strings adds half a second processing time, if your site is processing well less than that, you shouldn’t have a problem.

It seems the site Pippin was working on had enough strings to affect the responsiveness of the site, but I would bet that’s not a normal site. I also would bet that the issues the site was having are not because of the translation functions themselves, but the translation plugin the site was running.

I’m going to be using more _e() and less echo __(), but other than that

Bradycardia is the resting heart rate of under 60 beats per minute….Wikipedia

A new feature in WordPress 3.6 is an upgrade to the autosave functionality that’s been around for years. It’s called “Heartbeat” and it makes sure you have valid authentication credentials, aren’t working on the same post as other people, and more. The problem is that (as it is) it slows web pages down to a grinding halt.

Ever since WordPress added a Live Preview option to the Manage Themes screen, it’s been frustrating to test a plugin using multiple themes.

Why Live Preview sucks for developers

When using Live Preview, you can’t modify the URL of the page you’re visiting or open the preview in a new window or tab. Live Preview prevents you from viewing multiple themes at once in different tabs.

Much cleaner. One static and unchanging JS file to cache. Parameters get put into your HTML itself as a one-liner. You can deal with the parameters using a normal PHP array before passing them over. No need to screw around with generating Javascript from PHP or looking for wp-load or even messing with tricky actions.

Coding better WordPress plugins

As I’ve worked with WordPress plugins, I’ve learned new ways of working with WordPress. WordPress has tons of built-in functionality that is very useful and easy to use once discovered.

I am by no means a great PHP coder. I am still learning OOP principles and how to write code better. In creating new WordPress plugins (see a list of my plugins), I have improved how I code: writing more efficient code using WordPress functionality rather than hacks.

One of the methods of coding that I have discovered (thanks to Jeremy Clarke) is using the WP Cache and Transient APIs to store plugin data. It’s made a big difference in the speed of all my plugins.

We can do this the easy way or the hard way. What’ll it be?

The WordPress form plugin Gravity Forms (if you don’t use it, you should — it’s great) comes with a stylesheet found at [plugin-directory]/plugins/gravityforms/css/forms.css. SEODenver.com’s is found here.

WordPress.org plugin page layout change likely for usability

What the WordPress.org plugin page used to look like.

A couple of weeks ago, WordPress.org changed the layout of their plugins directory plugin pages. The update was likely to improve usability for users trying to determine whether a plugin is trustworthy and what it does. I believe the re-arranging of the page has achieved those goals.

The update removes author links

The layout redesign removes links to the official plugin page. I believe this makes it more difficult for users trying to get support on plugins.

Removing links also affects plugin authors. One of the ways that plugin authors are “rewarded” for creating plugins used to be a link from the WordPress.org website. This resulted in two things: increased traffic to the author’s website and some passed SEO value from the WordPress website to the author’s website.

These horses are somehow not cool. Speeding up your blog is.

I am working on a WordPress project that has a pretty heavy database, and I want to be able to auto-optimize the WordPress database. Even though they are integrating this functionality into WordPress 3.0, I want it now, and without having to use a plugin (I have had some issues with WP-DBManager configuring properly on a few sites).

Mad Mimi, Meet WordPress

Mad Mimi email marketing has the simplest, most elegant email designer I have ever seen. It’s so easy, you’ll freak — I know I did….So I created the Mad Mimi plugin for WordPress. The plugin makes it simple to add a signup list to your content or sidebar using a sidebar widget or the integrated [madmimi] shortcode.

The Best WordPress SEO Plugin? A combination of two.

All in One SEO Pack (AIOSEO) is the leader in WordPress SEO plugins. It offers great functionality and simple integration into the process of writing a post. AIOSEO is not a perfect plugin, however, because it lacks some very important functionality:

I’ve been using Joost de Valk’s Simple Taxonomies plugin for a couple of projects, and I’ve been very disappointed by the formatting of the terms output code.

When configuring the plugin, you have the option of choosing “Add terms to the end of posts” or “Add terms to the end of excerpts.” If you do, you get a <div> and a couple of spans. Not very semantic. Also, the code uses an #id, instead of a .class, meaning that if you have more than one post on a page with taxonomies, it no longer validates.

Set up a testimonials category — no need for a plugin.

There are a couple of plugins designed specifically for testimonials, but I didn’t want to use them; they use their own databases, and don’t keep with WordPress’ simplicity. If possible, the best way to work with WordPress is to use it’s built-in functionality.

I also wanted to have the testimonials as a category in WP, rather than as a separate plugin. This code will work for any type of category, not just a testimonial.