It seems like we are in for a cold winter with even more snow falling overnight.
I went out to see how deep it really is this time as it looked deeper than last time – it turns out we have about 15cm on the grass and about 19cm on the patio where a large amount fell from the roof.
As a WordPress lead developer, every time I see someone recommending editing a core WordPress file, a little bit of me dies.
You should always avoid editing the core files and put your modifications into a plugin so as to ensure you have a smooth upgrade experience to a future WordPress version.
Therefore inspired by the following forum post here is how to change one of the translatable strings in WordPress without hacking a core file using the filters available in the translation functions:
<?php
/*
Plugin Name: PJW Translation Mangler
Plugin URI: http://blog.ftwr.co.uk/#
Description: Example of how to mangle translated strings.
Author: Peter Westwood
Version: 0.01
Author URI: http://blog.ftwr.co.uk/
*/
class PJW_Translation_Mangler {
/**
* Filter the translation string before it is displayed.
*
* @param $translation The current translation
* @param $text The text being translated
* @param $context The context for the translation
* @param $domain The domain for the translation
* @return string The translated / filtered text.
*/
function filter_gettext($translation, $text, $domain) {
$translations = &get_translations_for_domain( $domain );
if ( $text == 'View all posts filed under %s' ) {
return $translations->translate( 'See all articles filed under %s' );
}
return $translation;
}
}
add_filter('gettext', array('PJW_Translation_Mangler', 'filter_gettext'), 10, 4);
?>
The filter used in this example gettext is one of a set of filters in the translation functions in wp-includes/l10n.php which also include gettext_with_context, ngettext, and ngettext_with_context.
I can’t remember the last time we had snow in the UK this close to Christmas.
Taken with a Canon EOS 300D + 70-200 f4L IS + 1.4x Extender
This is the tale of a mystery and intrigue about the disappearance of the css from a blogs dashboard and how we hunted it down and fetched it back.
Thord Daniel Hedengren, one of the writers for Blog Herald, put out a plea for help on twitter and was pointed in my direction.
He was faced with a WordPress dashboard which looked like this and wasn’t much use:
WordPress 2.8.4 dashboard without all the styling
This evening I hooked up with Thord and with the help of his server administrator we tracked down the issue and thought it a good idea to spread the message to help any one else out there who has a similar issue in the future.
I started off by looking at the headers returned by the php file which concatenates all the CSS files together and noticed something strange:
HTTP/1.1 200 OK Server: nginx/0.7.62 Date: Tue, 29 Sep 2009 19:34:47 GMT Content-Type: text/css;charset=“utf-8″ Connection: keep-alive X-Powered-By: PHP/5.3.0 Expires: Wed, 29 Sep 2010 19:34:47 GMT Cache-Control: public, max-age=31536000 Vary: Accept-Encoding
As you can see here the Content-Type header looks a little strange, it has a charset specified but the value being returned is not a valid charset and it looks like this is probably why Firefox is refusing to apply this css file to the page.
This was starting to look like a server configuration issue so we got in contact with the server admin and we tracked down the errant configuration to the php.ini file.
Within the php.ini file you can set a default charset to be used if one has not already been specified for the request this had erroneously been set in the file with some smart quotes rather than normal quotes and so php was outputting the smart quotes as well as the charset name into the HTTP header.
Now the headers look like this and Firefox is happy to display a fully styled WordPress dashboard:
HTTP/1.1 200 OK Server: nginx/0.7.62 Date: Tue, 29 Sep 2009 19:39:17 GMT Content-Type: text/css;charset=utf-8 Connection: keep-alive X-Powered-By: PHP/5.3.0 Expires: Wed, 29 Sep 2010 19:39:17 GMT Cache-Control: public, max-age=31536000 Vary: Accept-Encoding
In short, check the configuration you use for default_charset in your php.ini file and don’t use any quotes unless you need to the following works fine in my testing:
default_charset = utf-8
Keeping track of a projects progress is a common desire and if the project you are interested in happens to be a WordPress plugin then there are a number of RSS feeds which are an important resource for you (replace plugin_slug with the plugins slug!).
http://wordpress.org/support/rss/tags/plugin_slug http://plugins.trac.wordpress.org/log/plugin_slug?limit=100&mode=stop_on_copy&format=rss
The first of these contains all the support forum posts relevant to a particular plugin and the second is all the code changes that are happening in the plugins repository.
To keep track of these you have a couple of choices.
Firstly you could subscribe to them in your feed reader or if like me you like to receive emails for this sort of thing you can setup a cool tool called rss2email on your pc/server to email you new posts/changes.
A very interesting read on the culture of Netflix – something for all businesses to aspire to?
A better meta API for WordPress
July 23rd, 2009
One of the things that we have being discussing for a very long time is extending WordPress with a comment meta api or even the idea of a generic meta api for WordPress and indeed this is something we are discussing at the moment and I thought I would jot down some thoughts on what I would like to see from an API point of view. Over the weekend at WordCamp UK we also heard about situations where some people are already adding comment meta tables for plugin usage and so the demand is definitely there.
I don’t really care how the data is stored, be it single table or multi table, all I care about is having a good stable API for plugins and the core to work with. If the API is good and well thought out they don’t need to care about the table structure and we can always change it later.
Therefore I thought I would summarise the features I would like to see in a generic meta api:
So I am thinking of an api like this:
/* * Register a new meta type. * If we have a table per meta this will create the table for you if required */ register_meta_type('cron'); /* * Returns the meta value for a particular key */ get_meta_value('cron', $key); /* * Sets the meta value for a particular key */ set_meta_value('cron', $key, $value); /* * Returns the meta values for a particular key based search */ get_meta_values('cron', $search_value, $search_type); /* * Deletes the meta value for a particular key */ delete_meta_value('cron', $key);I would envisage us enabling the use of the new api with wrapper functions for different meta types as required. These wrapper functions would only be included if required, for example we could create a comment_meta wrapper api around these generic meta api functions which would only be available if a plugin / theme called
enable_comment_meta_api()Posted in Development, WordPress | Read 10 Comments