Resetting the More plugins

Some users have asked for a way to reset the More plugins to its default state to start over. And I thought I’d let you know how it’s done.

In More Fields, More Taxonomies and More Types there is a line in the plugin php file that looks like this:

if (0) update_option('more_nn', array());

where nn is fields, types or taxonomies respectively.

Open the file and change that line to:

if (1) update_option('more_nn', array());

Load the settings page for that plugin (Settings » More nn).

Then change that same line back to

if (0) update_option('more_nn', array());

This should revert all settings of that plugin back to null.

Please note

This is a hard reset of the plugin data. There is no undo. Use with caution. (And do backup before you start playing with it.)

More Plugins Dev Camp

This weekend we’re having a More Plugins Dev Camp in Örebro, Sweden.

The plan is to release More Types 1.0, More Taxonomies 1.0, and More Fields 2.0 before the weekend is over.

To tease a bit we’re implementing template tags for More Types, More Taxonomies, and More Fields to make it easier to use and work with the plugins in your theme work.

For our flagship plugin, More Fields, we’re also implementing some HTML5 features for input type="nn". We know that most browsers won’t be able to make much of them for now, but in time they will and we will be ready.

With these features you can create fields that only recognises numericals, a range, a colour, a date, a time or datetime.

We’ll see you on the other side.


The weekend is over and still no new releases yet. But I thought I’d give you an update on what we’ve been up to.

We’ve made another rewrite of how More Plugin handle different types of Post types, Taxonomies and Custom fields, which required some significant structural changes within the plugins. Now we’ve separated items within the plugin to make it easier to distinguish between different types.

For More Types the admin page is separated into:

  • More Types Post types
    Post types created with More Types or has been imported from other sources.
  • Saved More Types Post types
    Post types from files created with More Types.
  • Post types defined elsewhere
    Post types created with functions.php or other plugins.
  • Default Post types
    Built in post types.

The functionality is inherited bottom up, that is:
If you have the same Post type defined in Saved More Types Post types as in a Post type defined elsewhere the settings from Saved More Types Post types will override the settings from Post type defined elsewhere. Do you guys think that’s the correct order of things?

Expect GM versions posted to the repository soon.

A favorite .screenrc setting

I thought I’d share my current and favorite, .screenrc settings:

vbell off
autodetach on
defscrollback 10000
startup_message off
pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."
caption always "%{= gk}%-Lw%{= rW}%50> %n%f* %t %{-}%+Lw%< %= %{= Gk} %H %{= rW} %l %{= Gk} %0c:%s %d/%m %{-}"
shell -$SHELL

Looking like:

From the bottom left to right:

  • Screen name 'tabs': %-Lw%{= rW}%50> %n%f* %t %{-}%+Lw%<
  • Server name: %H
  • Server load: %l
  • Date & time: %0c:%s %d/%m

I put this togehter a few years ago, back in London, when working at multimap, but I cannot remember where I sourced it from. So, I'm putting it here for posterity.

What is your favourite .screenrc configuration?

Taking control of WordPress' xml export

I’ve been working on a plugin that uses the custom fields (post meta) to hold settings and content. To transfer the settings of the plugin from the development server to the live server (yes, we’re skipping staging, hoping to set one up soon), I thought the simplest way was to create a WordPress xml export file, for this one post, accessible via one simple link click.

The link to the xml file looks like this (btw, the plugin is called ADMinister, which is a plugin to handle advertising, and other temproary content, not related to specific pages or posts):

Download Worpress xml export for one post.

And in the plugin, the following bit of code will alter the export process to only export the specified ID or IDs.

function p2m_export_administer () {
   global $post_ids;
   if ($_GET['administer'])
      $post_ids = array(get_option('p2m_ad_post_id'));
add_action('rss2_head', 'p2m_export_administer');

The id of the page/post is held in the option ‘p2m_ad_post_id’, and the url parameter ‘administer’ is used to signify that we want to later the behaviour of the export. The global parameter $post_ids is the array that holds the ID of what to export. Even though we’re intent on only exporting one, the parameter must remain an array.

The xml file can then be imported into another WordPress installation. Obviously, this is rather inflexible if you want to transfer settings back and forth, but the point here is to illustrate how to better control the WordPress xml export file.

Translating plugins – the $domain parameter

Any half descent WordPress plugin should be able to handle different languages. The gettext translation system that WordPress uses is really easy to use, once one has the right tools, namely POEdit.

The function that loads the translation file is declared in WP as follows:

function load_plugin_textdomain($domain, $path = false)

Where $domain is the second parameter called in __($en_US_text, $domain) and _e($en_US_text, $domain). The difference between these two functions is that the _e() echoes the text, whereas __() just returns it. So, the $domain parameter defines the namespace within which the translation file (.mo) is valid, and this namespace must be specified for each translatable entity.

We load the .mo file in the plugin using the ‘init’ hook:

function p2m_translate(){
        load_plugin_textdomain('p2m-links', PLUGINDIR
            . '/' . dirname(plugin_basename (__FILE__)) );
add_action('init', 'p2m_translate');

In this example, the domain is ‘p2m-links’, which mean that translatable text should be expressed as:

__('Gobbledygook', 'p2m-links');
_e('Gobbledygook', 'p2m-links');

If no domain is specified in a plugin then WordPress will look for translations in the .mo file contained in the wp-includes/languages directory.

Grepping for files with byte order marks (BOM)

Finding offending php files with UTF8 byte order marks (BOM):

grep $'\xEF\xBB\xBF' * -rl | grep .php

Having byte order marks present in any of the WordPress or bbPress files causes the content not to validate to XHTML 1.0 Strict.