I originally posted this tome of an email to the openmelody mailing list, but figured there might be more people than just developers interested in what we have been working on and thinking about. Here we go…
~~~~
Things have appeared a little sleepy recently. I apologize for that. I have been working on some big stuff for Melody that I wanted to share.
1) Theme Manager - Endevver (disclaimer: I am a principal at Endevver) commissioned Dan Wolfgang to build for Melody a new Theme Management interface. We are working on the finishing details now and so far we really like what we see. At a high level this is an implementation of how TypePad manages templates in that it allows for two modes of operation:
a. Linked to Theme - in this mode, users are not allowed to edit templates. The look and feel of a site is derived exclusively from the theme source code. As changes are made to the theme, the site's templates are updated simultaneously.
b. Unlinked to Theme - the classic MT mode where the user is allowed and invited to edit their templates. In this mode as updates are made to the theme, they are not applied automatically to the theme. You must reapply the theme to see the updates, but at the risk of losing any changes you have made.
Theme Manager also comes with a theme dashboard showing a preview of your site, and other options to customize the look and feel of your site. Again, a lot of inspiration was drawn from TypePad which we think offers a great model for this.
We also allow designers to embed their PayPal email address to more easily prompt users of their themes to donate to the cause.
- Static File Deployment - This is a biggee for end users. When implementing Theme Manager we wanted to look at the entire life cycle of theme management from installation to management. There Dan also implemented a framework by which themes can package their static files for MT to install for the end user automatically. We can’t underscore how big this will be. So big that I think we should revisit the plugin packaging standard for Melody.
NEW PROPOSED PLUGIN PACKAGING STANDARD
Right now plugins are encouraged to package themselves like so:
PluginName-1.0/plugins/PluginName/...
PluginName-1.0/mt-static/plugins/PluginName/...
This is straight forward, but one of the things that this structure makes difficult is to have a plugin be pulled directly from source control because the plugin is fragmented into two distinct groups of files. With the enhancements Dan made to Config Assistant (already core to Melody) static files would be packaged as follows:
$MT_HOME/plugins/PluginName/config.yaml
$MT_HOME/plugins/PluginName/static/*
Upon installation of the theme, MT would automatically copy files found in static/ to:
$MT_HOME/mt-static/support/plugins/PluginName/
And it would give you a template tag <$mt:PluginStaticWebPath plugin="PluginName"$> for you to access the web accessible endpoint where your files were installed - wherever that might be.
This would allow plugins packages like so:
PluginName-1.0/plugins/PluginName/config.yaml
PluginName-1.0/plugins/PluginName/lib/...
PluginName-1.0/mt-static/plugins/PluginName/...
PluginName-1.0/mt-static/plugins/PluginName/images/logo.png
To be packaged like so:
PluginName/config.yaml
PluginName/lib/...
PluginName/static/images/logo.png
PluginName/static/...
Again - the biggest advantage to this is to allow us to use github to automate plugin and theme installation and upgrades because now one could easily do this:
prompt> cd $MT_HOME/plugins/
prompt> git clone http://github.com/byrnereese/mt-plugin-assetgallery
Something that is impossible today due to limitation in git. For example, git does not allow me to clone or fetch a sub-directory within a repos. I can only pull down the repos in its entirety.
Anyway - enough typing. What do people think?
~~~~~
As a post-script to this would-be email, I will also add the following. One of the things I think would be wise is to begin requiring config.yaml files (of course I am not the first person to state definitively that this would be a good, no great idea). Once this file is required then we can defer to the config.yaml to define all the meta data one would need to not only run the plugin, but to also have it hosted in a self-maintaining plugin directory.
To this end, we turn to our brother blogging system WordPress for inspiration for something it has done an amazing job with: building out a rich ecosystem for supporting plugin developers. At the heart of this ecosystem is a plugin directory, and what it does uniquely well is maintaining itself. Movable Type’s plugin directory requires plugin authors to go back to the directory to update if they make any changes. WordPress’ on the other hand, is integrated seamlessly with a source code control system. To register a plugin, you just checkin your plugin’s files to a svn repos they provision for you. Then whenever you update your plugin, the directory is updated automatically for you. By integrating the directory with the developer’s workflow, they ensure that their directory is always up-to-date and minimize the overhead anyone has to spend maintaining it.
I would like to do the exact same thing for Melody.
Ok, now really I have done enough blabbering. Time to sign off the email-turn-blog-post.
Rethinking the Movable Type plugin packaging standard