labs.dagensskiva.com

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?

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):

<a href="<?php echo get_option('siteurl'); ?> /wp-admin/export.php?download=true&administer=true">
Download</a> 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.

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.

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.