WordPress news, updates, etc.
Have you ever wanted to display a shortcode in a post? i.e. like this: [gallery]
It’s actually quite simple thanks to a little-known feature of WordPress. All you need to do is double up on the brackets:
[[gallery]]
[[example]foobar[/example]]
Note where the double brackets are in that last example.
Say you have a WordPress install where you need to pull in data from a separate database or server. The normal $wpdb instance of the wpdb class is limited to the database that your WordPress tables are located in. Yes, you could use mysql_connect() and the other standard PHP database functions, but then you don’t get all of the WordPress magic. So what to do?
The answer is surprisingly simple: make a new instance of the wpdb class! Dion Hulse (DD32) was kind enough to point out this great solution to me a few weeks back and I thought it was worth sharing with you all.
[php]$myotherdb = new wpdb( $dbuser, $dbpassword, $dbname, $dbhost );
$myotherdb->get_results( "SELECT id, name FROM mytable" );[/php]
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.
[code lang=”php”]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 );[/code]
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! 🙂
Normally I’d just retweet this and be done with it, but I feel this is worth blogging:
I never fully understood the concept of "painting the bike shed" until I changed the typeface in the world's most popular blogging software.
— Matt Thomas (@iammattthomas) July 6, 2011
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.)
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. 🙂
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? 😉
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
highlight="5,6,7,8,9,10,14" you can now just do highlight="5-10,14".Upgrade or download it now! 🙂
The PBS station that covers the San Francisco area did a piece on Matt Mullenweg that’s worth watching:
I’ve released a new plugin that switches WordPress’s language setting based on the user’s browser language preferences. More details on the plugin’s homepage.
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.