<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>David Raynes Technical</title>
      <link>http://www.rayners.org/technical/</link>
      <description></description>
      <language>en-us</language>
      <copyright>Copyright 2007</copyright>
      <lastBuildDate>Mon, 30 Apr 2007 22:45:20 -0500</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/?v=3.33</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 

            <item>
         <title>Gotcha in the upgrade_functions plugin argument</title>
         <description><![CDATA[<p>Plugins these days can, and often do, store their own data in their own custom object classes.  The <a href="http://code.sixapart.com/docs/movabletype/MT/Plugin.html">MT::Plugin</a> class makes it very easy to set all that up for each plugin, along with versioning the overall data storage scheme for the plugin and allowing for routines to be run upon upgrading.</p>

<p>Here is an example cribbed from the documentation:</p>

<pre><code>schema_version =&gt; 1.1,
object_classes =&gt; [ 'MyPlugin::Foo', 'MyPlugin::Bar' ],
upgrade_functions =&gt; {
    'my_plugin_fix_field_a' =&gt; {
        version_limit =&gt; 1.1,   # runs for schema_version &lt; 1.1
        code =&gt; \&amp;plugin_field_a_fixer
    }
}
</code></pre>

<p>Now, while I will readily admit this was very much a faulty assumption on my part, I thought that the keys of that <code>upgrade_functions</code> hash only needed to be unique within the plugin itself.</p>

<p>I was wrong.  Very wrong.</p>

<p>The keys of that hash need to be unique within the entire MT installation.  That means they cannot be the same as any of the core upgrade functions or any upgrade functions that other plugins might define.  It look me about half an hour to track that one down.</p>

<p>Looking back on it now, it makes sense.  Template tags, junk filters, text filters, and so forth all need to be unique within the system as well, so it being the same for upgrade functions really is not that surprising when you think about it.</p>

<p>So, I am publicly introducing the first of my plugin development best practices: <em>Always prepend the name of the plugin to any key in the <code>upgrade_functions</code> hash argument.</em></p>

<p>Yes, this is pretty much what plugin authors do already with template tags (e.g. MTPluginNameTag), but it can't hurt to have this spelled out explicitly for <code>upgrade_functions</code> as well.</p>
]]></description>
         <link>http://www.rayners.org/technical/2007/04/gotcha_in_the_upgrade_functions_plugin_argument.html</link>
         <guid>http://www.rayners.org/technical/2007/04/gotcha_in_the_upgrade_functions_plugin_argument.html</guid>
         <category>Plugin Development</category>
         <pubDate>Mon, 30 Apr 2007 22:45:20 -0500</pubDate>
      </item>
            <item>
         <title>Getting Lighttpd and RequestTracker working together</title>
         <description><![CDATA[<p>I had been fighting for a while to get my <a href="http://www.lighttpd.net/">lighttpd</a> server to serve up <a href="http://bestpractical.com/rt">Request Tracker</a> via FastCGI, but I was always having minor configuration issues with it.  I finally dug up a handy <a href="http://trac.lighttpd.net/trac/wiki/MasonRecipe">recipe</a> for a Mason (which is what <a href="http://bestpractical.com/rt">Request Tracker</a> uses) FastCGI script for use with <a href="http://www.lighttpd.net/">lighttpd</a>.  After incorporating the changes necessary to deal with <a href="http://www.lighttpd.net/">lighttpd</a>'s quirks, I managed to get things working as well as I would like.  The following is the diff generated from the stock <code>mason_handler.fcgi</code> script that comes with <a href="http://bestpractical.com/rt">Request Tracker</a>:</p>

<pre><code>--- mason_handler.fcgi.orig     2006-09-30 16:45:18.000000000 -0400
+++ mason_handler.fcgi  2006-09-01 18:05:16.000000000 -0400
@@ -65,6 +65,16 @@
     $ENV{'ENV'}    = '' if defined $ENV{'ENV'};
     $ENV{'IFS'}    = '' if defined $ENV{'IFS'};

+    my $uri = $ENV{REQUEST_URI};
+    if ($uri =~ /\?/) {
+      $uri =~ /^(.*?)\?(.*)/;
+      $ENV{PATH_INFO} = $1;
+      $ENV{QUERY_STRING} = $2;
+    } else {
+      $ENV{PATH_INFO} = $uri;
+      $ENV{QUERY_STRING} = "";
+    }
+
     Module::Refresh-&gt;refresh if $RT::DevelMode;
     RT::ConnectToDatabase();
</code></pre>

<p>And the portion of my <a href="http://www.lighttpd.net/">lighttpd</a> configuration file handling <a href="http://bestpractical.com/rt">Request Tracker</a>:</p>

<pre><code>  server.document-root = "/usr/local/share/html"
  fastcgi.map-extensions        = ( ".css" =&gt; ".html", ".js" =&gt; ".html", "/" =&gt; ".html" )
  index-file.names              = ( "index.html" )
  url.access-deny               = ( ".mhtml" )
  fastcgi.server                = ( ".html" =&gt;
                                        ((
                                                "socket"        =&gt; "/tmp/rt-fcgi.socket",
                                                "bin-path"      =&gt; "/usr/local/bin/mason_handler.fcgi",
                                                "check-local"   =&gt; "disable",
                                                "min-procs"     =&gt; 2,
                                                "max-procs"     =&gt; 2
                                        ))
                                )
</code></pre>
]]></description>
         <link>http://www.rayners.org/technical/2006/09/getting_lighttpd_and_requesttracker_working_together.html</link>
         <guid>http://www.rayners.org/technical/2006/09/getting_lighttpd_and_requesttracker_working_together.html</guid>
         <category></category>
         <pubDate>Sat, 30 Sep 2006 16:41:52 -0500</pubDate>
      </item>
            <item>
         <title>Automated plugin testing</title>
         <description><![CDATA[<p>One of programming mantras I try to follow is "Bugs are only found once."  When a bug is discovered, an automated test is written to demonstrate it.  When the test passes, the bug is fixed, and with the test around, subsequent versions of the software will be checked to see if it reappers.  I have been more lax than I like with testing my plugins, but I have started to make things right.</p>
]]></description>
         <link>http://www.rayners.org/technical/2006/08/automated_plugin_testing.html</link>
         <guid>http://www.rayners.org/technical/2006/08/automated_plugin_testing.html</guid>
         <category></category>
         <pubDate>Sat, 19 Aug 2006 23:29:12 -0500</pubDate>
      </item>
            <item>
         <title>Programmatically setting plugin defaults</title>
         <description><![CDATA[<p>When developing a plugin for Movable Type 3.2, you can list out all of the configuration variables you plan on tracking on system-wide or per-blog basis, along with explicit, hard coded default values for those variables.  As I was working on <a href="http://www.rayners.org/plugins/workflow/">Workflow</a> last night, I discovered a way to programmatically set different default values for individual blogs.</p>
]]></description>
         <link>http://www.rayners.org/technical/2006/05/programmatically_setting_plugin_defaults.html</link>
         <guid>http://www.rayners.org/technical/2006/05/programmatically_setting_plugin_defaults.html</guid>
         <category>Plugin Development</category>
         <pubDate>Sat, 13 May 2006 23:01:27 -0500</pubDate>
      </item>
            <item>
         <title>Building Plugin Distributions with Ant</title>
         <description><![CDATA[<p>I use <a href="http://ant.apache.org/">Ant</a> to build the plugin archives that can be downloaded from my site.  Why <a href="http://ant.apache.org/">Ant</a>?  Well, while I can manage to get <a href="http://www.gnu.org/software/make/">make</a> to compile a couple files, I have more experience with <a href="http://ant.apache.org/">Ant</a>, mostly because that is what we use at work right now.</p>
]]></description>
         <link>http://www.rayners.org/technical/2006/03/building_plugin_distributions_with_ant_1.html</link>
         <guid>http://www.rayners.org/technical/2006/03/building_plugin_distributions_with_ant_1.html</guid>
         <category>Automation</category>
         <pubDate>Mon, 27 Mar 2006 22:27:52 -0500</pubDate>
      </item>
      
   </channel>
</rss>
