Tag Archives: WordPress

Changing Core WordPress Strings

Posted on by

One of the lesser known filters in WordPress is gettext. All strings that are run through the WordPress translation functions are also run through this filter after being translated thanks to a ticket I opened way back in 2008. That means you can actually use it to change pretty much any string in WordPress, namely in the admin area.

I’ve used this in some plugins I’ve written in the past and it works incredibly well.

My co-worker and one of the lead developers of WordPress Peter Westwood (westi) wrote a really good blog post about this, however I wasn’t completely happy with his code so I’m writing this blog post to share how I would write some code to take advantage of this versatile filter. Don’t get me wrong — he wrote good and valid code, but it’s not exactly the easiest thing for a novice to extend for their own uses.

function youruniqueprefix_filter_gettext( $translated, $original, $domain ) {

	// This is an array of original strings
	// and what they should be replaced with
	$strings = array(
		'View all posts filed under %s' => 'See all articles filed under %s',
		'Howdy, %1$s' => 'Greetings, %1$s!',
		// Add some more strings here
	);

	// See if the current string is in the $strings array
	// If so, replace it's translation
	if ( isset( $strings[$original] ) ) {
		// This accomplishes the same thing as __()
		// but without running it through the filter again
		$translations = &get_translations_for_domain( $domain );
		$translated = $translations->translate( $strings[$original] );
	}

	return $translated;
}

add_filter( 'gettext', 'youruniqueprefix_filter_gettext', 10, 3 );

So as you can see at it’s core it accomplishes the same thing as Peter’s code however my code should be a bit more clear on how to make it translate multiple strings.

Hope someone finds this helpful! 🙂

Painting The Bike Shed

Posted on by

Normally I’d just retweet this and be done with it, but I feel this is worth blogging:

Matt Thomas also has a blog post if you’re interested in further reading.

(Have no idea what “painting the bike shed” is referring to? Wikipedia has your back.)

Regenerate Thumbnails v2.1.0 (and v2.1.1) Released

Posted on by

I’ve released a major update to my popular Regenerate Thumbnails plugin. From the changelog:

  • Thanks to a lot of jQuery help from Boris Schapira, a failed image regeneration will no longer stop the whole process.
  • The results of each image regeneration is now outputted. You can easily see which images were successfully regenerated and which failed. Was inspired by a concept by Boris.
  • There is now a button on the regeneration page that will allow you to abort resizing images for any reason. Based on code by Boris.
  • You can now regenerate single images from the Media page. The link to do so will show up in the actions list when you hover over the row.
  • You can now bulk regenerate multiple from the Media page. Check the boxes and then select “Regenerate Thumbnails” form the “Bulk Actions” dropdown. WordPress 3.1+ only.
  • The total time that the regeneration process took is now displayed in the final status message.
  • jQuery UI Progressbar version upgraded.

As you can see, lots of great new stuff. I hope you all enjoy it. 🙂

SyntaxHighlighter v3.1.0 Released, Features Old Style Script Option

Posted on by

Not everyone was happy with the new highlighting package featured in SyntaxHighlighter v3.0.0 and using old versions of plugins is a bad idea (you miss out on features, bug fixes, etc.) so I’ve added the ability to toggle between v2 and v3 of Alex G’s SyntaxHighlighting package. I’ve also fixed a few bugs that were discovered post-release (such as HTML entities being broken in the Visual editor).

Everyone, including those who downgraded to v2.x of my plugin, should upgrade to v3.1.0 of my plugin.

One thing to note by the way: I would stay far, far away from TinyMCE (the Visual editor/tab) when blogging about code. It has the nasty little habit of attempting to “clean up” your code (namely HTML) for you and in the process with mess up your code. If you’re writing code, what are you doing using a WYSIWYG editor anyway? 😉

SyntaxHighlighter Evolved v3.0.0: What’s New

Posted on by

I finally found some time to work on my SyntaxHighlighter Evolved plugin and upgrade it use the latest version of Alex Gorbatchev’s highlighter.

What’s New

  • The new version of Alex G.’s script makes it easier to select and copy code. You can just drag your mouse to highlight and you will no longer get line numbers or you can double-click the code to highlight it all (in plain text to avoid getting the colors). Click off of the code to get it to go back to the colorized version.
  • You can specify a range of line numbers to highlight. Instead of having to do highlight="5,6,7,8,9,10,14" you can now just do highlight="5-10,14".
  • BuddyPress support.
  • A few new custom brushes (Clojure and the R language) and a Ukrainian translation.

Upgrade or download it now! 🙂

Why WordPress Doesn’t Have Built-In Persistent Caching

Posted on by

John Gruber of Daring Fireball fame wondered “[…] why WP Super Cache (or some other caching solution) isn’t part of the default WordPress installation” in a recent blog post, so I thought I’d write a blog post explaining why.

First though, a bit of background. When you visit a WordPress-powered website, WordPress asks the database software for some details such as the post contents, details about the authors of the posts to be displayed, the comments for that post (if you’re in a single post view), and so forth. The database is really good at this kind of thing, but if you ask too much of it (too many queries), it will start slowing down and eventually start not replying in time before the webserver software (Apache, etc.) gives up on it. For the vast, vast majority of WordPress sites, this never happens. The database chugs happily along responding to queries and you never have any problems.

However if you get linked to from a popular site such as Daring Fireball, Digg, or Reddit, the high number of page requests will soon overload your database software. This is because most people host their sites on what’s called shared webhosting where you and a bunch of other people share a server. The server doesn’t have much spare CPU power as hosts want to make the most out of the servers. It’s a case of you get what you pay for.

To help avoid this, WordPress does actually have a built-in cache called the object cache. It was introduced way back in 2005 and it basically caches database query results. When displaying a post for example, WordPress usually asks the database for information about the author of that post (name, etc.). When another post is displayed by that same author further down the page, instead of asking the database for the information again, WordPress fetches this data out of it’s internal cache. This simple little feature greatly cuts down on the number of queries required to generate a webpage for a visitor.

However as soon as the page is done being generated, that object cache is discarded. Initially the object cache cached these little chunks of data to the filesystem so that they could be reused on subsequent pageviews. While great in theory, the concept turned out to be terrible in practice. You see WordPress has to be able to run on countless different types of server configurations. One common enough configuration that had trouble with this file-based type of caching was where all of your files were network based. Rather than your website’s files being stored on the server that was generating the webpage for the visitor, they were stored on a different server elsewhere in the datacenter. Having to fetch all of these little cache files over the network was a slow and resource intensive exercise. And that’s only one example of many configurations that the file-based caching had trouble with.

What’s worse is that many sites were actually slower with a persistent object cache enabled. Databases are actually quite fast (as they’re designed to store lots of little chunks of data), often faster than fetching that data from the filesystem and decoding it. So for the vast majority of sites, the ones that get relatively low traffic, having a persistent cache was a lot more trouble than it was worth. Just having a temporary object cache is enough.

While the same issues don’t really apply to WP Super Cache and other plugins total caching plugins because they caching each page to a single file instead of multiple little files, as with a persistent object cache, it simply isn’t needed for most sites due to lack of traffic. More importantly though, they require setup and there’s a tradeoff as your blog is no longer dynamic. Things like “latest comments” will be out of date for example.

So the WordPress developers have instead decided that the best course of action is to make it really easy to use a caching plugin, both behind the scenes and from the user perspective. You can install a plugin in just a couple of clicks directly from the admin interface.

Infact this is how WordPress development is done as a whole — include things that the majority of users will want and make it easy to install a plugin to do the rest. The core of WordPress should stay as slim as possible — bloat is bad!

I hope that clears up the decision why not to include persistent caching by default in WordPress. 🙂

TL;DR: Persistent caching isn’t needed for most sites and is a pain to get working in all hosting environments. Instead WordPress makes it really easy to install a caching plugin if you need it.

Sneak Preview Of Viper’s Video Quicktags v7.0’s Code

Posted on by

If you’re a coder and are interested in the direction I am going with the next version of my popular Viper’s Video Quicktags plugin, I have committed what I have so far to the WordPress.org plugin SVN repository.

Please note that this is not production ready code. It’s still a proof of concept at this point basically where I am just writing ugly code in an effort to get the functionality there so I can test it. Large portions of it aren’t even coded yet (FLV support for example).

I’m only sharing it for anyone who builds on top of my plugin or whatnot with their own code. Everyone else shouldn’t bother looking at it. 🙂

#thesiswp And My Code

Posted on by

I’m not going to post my opinions on why WordPress theme PHP files are required to be licensed under the GPL as many, many, many, people have done a much better job at it then I could ever do.

However I felt I had to write a blog post to point out something: I wrote some of the code that is currently being used in Thesis and I contributed it to the WordPress project under the GPL license. I overhauled a lot of the paged comments code originally contributed by Ryan Boren and others and added new functionality such as what comment page is shown by default or the sorting order of the comments themselves. It’s some of that code that I wrote that is currently in use inside of Thesis’ thesis_list_comments() function and I wouldn’t be surprised if there was more of my code elsewhere in the theme.

So not only is Thesis violating the GPL license, it is violating my copyright as I own all code that I have contributed to WordPress.
Just a little food for thought.