January 2nd, 2010
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.
Posted in Development, Tutorials, WordPress | Read 9 Comments
July 19th, 2009
Last night there was a discussion as to what could be achieved today as part of a “WordHack” session at WordCamp UK and SimonD tweeted that he would like to be able to add extra user meta fields to the back end user profile page easily.
I tweeted back that it was already easy and so here is the proof of concept code which shows you:
- How to add a user meta field to the page
- How to process the new value when it is updated.
These can the been displayed on the front-end using the standard template tags get_the_author_meta() and the_author_meta()
<?php
/*
Plugin Name: PJW User Meta
Plugin URI: http://blog.ftwr.co.uk/archives/2009/07/19/adding-extra-user-meta-fields
Description: Allows users to configure some random extra meta value.
Author: Peter Westwood
Version: 0.02
Author URI: http://blog.ftwr.co.uk/
Use of the frontend as get_the_author_meta('something') or the_author_meta('something')
*/
class pjw_user_meta {
function pjw_user_meta() {
if ( is_admin() )
{
add_action('show_user_profile', array(&$this,'action_show_user_profile'));
add_action('edit_user_profile', array(&$this,'action_show_user_profile'));
add_action('personal_options_update', array(&$this,'action_process_option_update'));
add_action('edit_user_profile_update', array(&$this,'action_process_option_update'));
}
}
function action_show_user_profile($user)
{
?>
<h3><?php _e('Other Contact Info') ?></h3>
<table>
<tr>
<th><label for="something"><?php _e('Something else'); ?></label></th>
<td><input type="text" name="something" id="something" value="<?php echo esc_attr(get_the_author_meta('something', $user->ID) ); ?>" /></td>
</tr>
</table>
<?php
}
function action_process_option_update($user_id)
{
update_usermeta($user_id, 'something', ( isset($_POST['something']) ? $_POST['something'] : '' ) );
}
}
/* Initialise outselves */
add_action('plugins_loaded', create_function('','global $pjw_user_meta_instance; $pjw_user_meta_instance = new pjw_user_meta();'));
?>
Enjoy!
Updated to correctly use the $user/$user_id passed to the actions rather than the global $user_id
Posted in Development, Tutorials, WordPress | Read 19 Comments
May 26th, 2009
I was reminiscing today on what the world was like when I released my WordPress version check plugin back in 2005.
What a different world it was, upgrading WordPress took time and people just didn’t bother even though new versions which contain security fixes had been released.
Now we are just about to get WordPress 2.8, people can upgrade with the click of a button and there hasn’t needed to be a security release for WordPress 2.7 how things change.
In celebration of this I have decided to take down the web-service which supported the plugin and have started the shutdown process by changing the message returned to point to this blog post. So please un-install the plugin and rely on the notification that has been built in to WordPress for a few releases now.
Oh and don’t forget if your one of those people who has been ignoring these messages and are still running v1.5.2 (yes you know who you are) then please upgrade.
Posted in Development, Security, WordPress | Comment on this post
May 26th, 2009
I had a request recently for help on using my Query Child Of plugin to create a page template to show the grandchildren of a page as well as a number of people asking for better examples on how to use my plugin in general to just list the children of a page.
I am now happy to announce that I can provide these examples and have updated the plugin documentation on in the WordPress plugin directory to match as well.
Read the rest of this entry »
Posted in Development, Tutorials, WordPress | Read 2 Comments
May 11th, 2009
Just went to check my ohloh stats today to find I have reached a milestone in my work as a WordPress lead developer.
According to there counts I have made 500 commits to the trunk section on the WordPress subversion repository.
Posted in Development, WordPress | Read 2 Comments
March 20th, 2009
By popular request I have updated my Query Child Of plugin to support limiting the number of child pages returned (and to support the ability for this limit to be offset).
The plugin is also now hosted on WordPress.org Extend as PJW Query Child Of and I have also writen up some example php code so as to make it really easy to use!
Posted in Asides, Development, WordPress | Comment on this post
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