Sometimes I like to talk like a batshit HipHop star.

This started years ago, possibly after hearing one-too-many infamous rants by the Ol' Dirty Bastard. It's been brought into rotation again, heavily influenced by Kanye West's inane rants and Tracy Morgan's completely-fucking-brilliant character "Tracy Jordan" on 30-Rock.

Channeling the insanity gods, I recently asked a friend "Where are all the sexy bitches at tonight?"

He had no idea.

So we asked some search engines.

Sadly, no one knew.

To correct this, I've been using the phrase a lot. And when asked, I always answer -- right here.

Hopefully, within the next few weeks, search results will magically update... so when you ask the internets "Where are all the sexy bitches at tonight?", you'll know where to find them... right here.

Addendum - Let's start a Twitter hashtag for this -- Where are all the sexy bitches at tonight = #waatsbat

Once upon a time there was a franchise of movies starring Jim Varney as Ernest P Worrell, a lovable and annoying character. First he went to summercamp, then he saved christmas, went to jail, was scared stupid, rode again, went to school, played basketball, went to africa, and somehow ended up in the army. No matter what Ernest did, you were sure to laugh!

End copywriter crap.

Truth be told, the Ernest movies were awful, but in a wonderful way. No matter what he did, you'd end up laughing -- either with him or at him, it didn't really matter.

Ernest saves Christmas was especially ridiculous -- while working as a Taxi Driver in Florida, Ernest meets Santa Claus who is in town to hire his replacement , a local children's television show host.

After a series of mishaps, the television show host ends up being cast in a movie he thinks is called "Christmas Sleigh", which is actually a christmas alien slasher horror film called "Christmas Slay".

This scene in Ernest saves Christmas was cheesy, awful, and one of the most ridiculous things ever to be shot on film.

Until, of course, some hollywood producers were piss drunk, coked up, or something when the movie came on cable 15 years later... and decided to actually make Christmas Slay.

Of course they couldn't do the exact movie, without paying royalties, so we end up with a made for (spike)TV film "Santa's Slay" -- a re-imagining of Christmas where :

• Santa is really the son of Satan
• Christmas was originally "The Day of Slaying" , where he goes on a killing rampage
• In 1005 AD an angel beat him in a curling match; losing the bet made him deliver presents to children for 1000 years
• In 2005, the bet has been lifted and Santa is free to slay again!

I used to love A Christmas Story, but the past 3 years it has been derailed as my #1 holiday pick by Santa's Slay -- a movie that can actually claim that it was based entirely on a bad joke from Ernest Saves Christmas.

Somehow, these are the two most popular blogging packages. I really can't believe it - they're both crap.

I've come up with a listing of pros & cons for each one, with hopes that others find this useful.

This entry will be updated regularly as I find new things to complain/praise.

i like to joke that using these is like the tagline for Aliens v. Predator -- whoever wins, we lose.

MovableType 4.2

pros

• stable & security minded
• extensive database support -- mysql , postgresql , sqlite , etc
• publisher minded workflow
• natively supports php templates for website users (not admin) or publishing to static php files for advanced customization.

cons

• the plugin system is hard to develop and integrate. flat-out -- it's poorly planned. the distribution mechanism means making multiple links on install.
• its almost like crippleware - while the MTOS system provides 'core' functionality, SixApart's definition of core is different than the public. basic functions like adding custom fields to your posts require paid upgrades.
• there aren't even many plugins out there, and ones that offer key functionality found on other platforms are offered with licenses often at the $100+ range.
• the templates are a nightmare to design, port, manage. MT decided to treat 'theme' 'template' and 'style' as distinct options to manage and distribute -- yet a true site design is a mix of all 3.
• completely unusable as a CGI application. absolutely requires FastCGI for usability.

WordPress 2.7

pros

• abundance of plugins
• plugins and themes are well thought out -- drag&drop folder based packages

cons

• unstable & insecure. extremely poor coding and QA standards.
• mysql only
• workflow is for one person , the ACLs must be hacked with plugins to make usable for a publishing situation
• • a history numerous security issues in every release
• • i'm still amazed that the 2.5 password_generate and password_validate functions were out-of-sync with unusable passwords generated a signifanct percentage of the time.
• the permissions and workflow systems can be unusable as-is. ie: you need a new plugin to allow contributers to upload images.

Dare I say it? You betcha -- your Social Media Campaign is... Stupid.

Two years ago Brands and Advertisers weren't just cautious of social media, they were apprehensive and distrustful.

In as quick of a 180° change as Social Networks opened last summer, marketing interests have rushed to embrace social media... albeit with overwhelmingly pointless campaigns.

Everyone feels they need to have a Facebook App, a MySpace page, a Twitter campaign... the list goes on...

The marketing budgets spent on these endeavors are no laughing matter, and neither are the talents hired -- with some of the best and brightest production shops, digital agencies, and creatives backing the efforts.

So what is going wrong?

Why are Facebook apps turning into ( as Advertising Age proclaims ) brand graveyards ? Why are Twitter campaigns failing , when there are so many success stories out there? Why are you all alone, because will no one be your friend on MySpace?

The problem is simple -- bad strategy.

In a rush to homestead on Social Media properties, everyone has gone out and hired "Social Media Consultants" -- 'experts' who overwhelmingly have little to no background in advertising or digital media , they just 'get' social media and are avid networkers. These are people who know little about ROI or Branding, instead measuring their success by the size of their contracts.

My friend Phil Gillman has been talking recently about how Advertising has failed online because marketers have been trying to keep too unified a messaging across media - and not tailoring online activity to the interactive marketplace. He's right - a lot of issue is that television campaigns won't work online.

But I say this goes a step further -- not every online medium is the same. Facebook and MySpace have vastly different cultures -- as do all the niche social networks. You wouldn't run the same mix on NBC, BET and Univision -- so why run the same social media campaigns across networks?

Some online projects can be 'insanely viral' -- others are not. My friends The Barbarian Group are often lauded with their success with the Subservient Chicken campaign for Burger King -- and they should be, it reached across demographics with equal appeal. But where is the appeal to Facebook or MySpace users for displaying the latest news from The Wall Street journal on their page? That's not social media strategy, that's social media stupidity.

When my company FindMeOn was working with non-profit and political groups to streamline our social network mapping technology, we ran into the same conversation during every meeting -- clients wanted to run the same online campaign on 15 different networks. We always gave the same answer -- and every time I consult I still give this same stock answer:

• I understand your position, it's a bad one.
• I'd be glad to take your money and implement that - or you can just give me money for nothing in return, because you're not going to get any ROI off of this
• Every social network and medium is different -- you need to leverage your brand against them

The strategies I always recommend is nothing more than common sense:

• Discover your core audience on each network, and communicate with them. Facebook and MySpace users are not the same, and will not react to the same messaging.
• The key is in communication -- you need a two-way brand relationship.
• By building up users across networks, you can leverage their homesteads in each network and reach more people.

Users want to feel like they're interacting with your brand. Syndicating content or duplicating campaigns across social networks by merely find/replacing logos and names does nothing but cheapen their experience.

Marketers need to be critical of themselves and their campaigns - no one seems to ask "If I'm a common user, why would I download/use/install this?" We don't live in a field of dreams -- 'If we build it , they will come' is nothing more than foolish optimism.

Which brings me to my case in point - Twitter. I haven't read an issue of "Advertising Age" in months that doesn't have at least 3 articles on the now-ubiquitous service. If someone isn't already using Twitter for brand reinforcement and advertising, they're openly talking about their plans to. There's even a few pay-to-post brand advertising networks coming out on it.

I like using Twitter as an example, because it's the perfect illustration of who "gets it", and who doesn't in social media -- it also best-illustrates the key points in Social Media marketing.

Many people gauge the effectiveness of a Twitter account based on the number of 'followers' -- assuming someone with 50-500 followers is not as effective as someone with 500-5,000. This is a dangerously wrong assumption -- and one built on fundamental misunderstandings of both Social Media and basic marketing skills. The success of your brand in Social Media depends on one thing and one thing alone -- engagement.

Twitter is not a syndication platform -- it is not a newsletter, a RSS feed, or a subscription service. It's a platform for engagement.

While the most popular Twitter brands have average 20,000 followers ( i.e.: Zappos CEO Tony Hsieh and Gary Vaynerchuck of WineLibrary ), their ROI has never been exhibited by their quantity, but instead their quality. The success of these Social Media campaigns lie in their use of bi-directional customer engagement -- with the brands not only broadcasting information, but interacting with consumers on a personal level. To reinforce this point, I often like to remind people "It's SOCIAL, stupid.".

FindMeOn always advices non-profits and organizations to not create personal/closed whitelabel networks, but build open social networks that leverage their fans' existing accounts.

One of the 2008 Presidential campaigns really wanted us to build them a closed network. Our response? "That's a bad idea. Why would you want to have a bunch of your fans feeding off each other? They need to be talking out in the open - you need to use them as your advocates."

Instead of bringing people together behind closed doors, your online property should be a gathering place , a common hub or 'linkage' for your followers across websites and networks. For example: if you leverage Flickr or MySpace for photo sharing, instead of building your own photo gallery, their photographs appear across sites. You gain brand positioning within their activity streams and, consequently, gain a chance to convert more followers. This is the social media equivalent of "Collateral damage" - we call it "Collateral Branding".

Twitter exemplifies Collateral Branding -- and Social Media Marketing best-practices -- because of how it's engagement model works.

Let's take the example of someone with 5000 followers: if all they do is broadcast a bit of information every few hours, all they really have is 5000 passive listeners. That's nothing to really boast about. Really, what good does it do to your brand to blanket a few thousand people with random news blasts? This is the social equivalent of opt-in spam, and can leave consumers disaffected or damaged.

Now let's look at a Twitter brand with 500 followers, and characterize them as someone who actively engages with their fans. That means using the network and tailored communication to open a dialogue with users - not just broadcasting to them, but fostering a conversation. This doesn't just build a stronger, more positive connection with the brand, but has the potential to engage more users in new, unique, and positive ways. While their messaging may only be directed at 500 people, every user-generated message addressed @them shows up on the timelines of those originators' followers. If the brand receives 50 messages from unique followers each day, and those users each average 100 followers themselves, their realized Social Marketing Imprint is the sum of their outbound messaging ( 500 unique users ) + their inbound messaging ( 50 users * 100 followers = 5000 potentially unique users ).

So in this example, our brand with 500 followers is not only fostering a better brand connection and reinforcement with its consumer base, but is actually creating a slightly larger marketing imprint. Who woulda' guessed?

Social Media is still a young concept for marketing, but it can be extremely powerful when done right. Don't just build apps and broadcast messages, hoping people will install them. Actually think about what you're building, why you're building it, and what the ROI will be. Having a Facebook app or Twitter page is not ROI - using them to create and foster brand loyalty and sales is. If you're a brand or advertiser, you shouldn't question Social Media -- online advertising and social media has a proven track record; you simply need to question your strategy and show a little common sense.

I talked with some of FindMeOn's lawyers this morning about an idea that we've been kicking around... and I think this may happen!

FindMeOn may introduce Licensing / Amnesty program for people who implement google's OpenSocial / Social Graph API or other technology covered by our pending patent applications.

I hate bringing up an allusion to the SCO program, but it is similar in concept.

The system will likely work like this:

- Social Media and Advertising Companies can apply for licensing / amnesty agreements during our trial run. Approval will be granted to implementors of infringing technologies, but denied to companies that develop/contribute to infringing technologies.
- In return for a verified donation to selected non-profits -- in an amount that is commensurate with their usage of infringing technologies -- companies will receive a license and amnesty.

To be clear:

- Obviously, we're not going to be making any money off this licensing program.
- Amnesty will be given to firms for verified donations to select non-profits. We haven't finalized the system or non-profits yet, however the general idea is that you will either provide FindMeOn with a receipt or a check addressed to the Non-Profit -- meaning that your donation will be directly to the non-profit and tax deductable.
- FindMeOn is, as stated before, pursuing an aggressive intellectual property agenda. FindMeOn does not want to penalize or inconvenience end users - be they companies or consumers - for implementing stolen , infringing or derivative technologies.
- We'll likely continue this program after our patents clear, but participants will lock in a reduced rate.
- This is our attempt to turn an extremely unfortunate situation into something positive for the world.

For those that don't know the history of FindMeOn, here's the quick version:

- FindMeOn started in 2005, and launched publicly in August 2006.
- Our August 2006 launch included the FindMeOn platform and AND OpenSN / Open Social Network open source project. Between the two technologies, users could port account information, updats, content and contacts across networks. For the first year after our launch, FindMeOn remained the first and only system commmited to data portability -- offering a true platform and mapping/syndication service wheras other 'aggregator' systems merely created new portals as social content consumers.
- More than a year after our launch, several large companies , including Google , re-implemented our technologies using their own brand name. Public records - and corporate blogs - show these companies proudly boasting of beginning development long after our products were on the market and patents filed.

This is my own creation, adapted from a few base recipes.

This creates 2-3 servings, and scales easily.

Ingredients

• 2 Cups 2% Reduced Fat Organic Milk
• 3 Tablespoons Corn Starch
• 3 Tablespoons Sugar ( white or brown )
• 3 Oz Unsweetened Baking Chocolate
• 2 Oz Dark/Bittersweet Eating Chocolate
• 1 tsp Vanilla Extract
• 1.5 oz Medium Quality Bourbon ( Bakers is best )

Directions

1. Put 1cup of milk and all the chocolate in a saucepan under low heat.
2. Mix 1cup milk with sugar & cornstarch , then add to saucepan.
3. Stir until all chocolate is dissolved, and the mixture begins to thicken.
4. Add in vanilla extract and bourbon, stick until mixture is thick and starts to bubble.
5. Divide and serve warm or cold.

MovableType 4.23 was released, and I had to upgrade a couple of installs.

As previously mentioned, I use (and recommend) a fairly customized server layout to handle my MovableType installations.

I hacked together this quick Python script to create symlinks (as needed) for MovableType plugins.

Obvious note, this ONLY works if you use the same directory layout as me.

The script essentially does this

1. loops a shared _plugins dir to figure out what plugins you have, and which need to support plugin and mt-static links
2. chdirs into _current to create necessary relative symlinks

simple, eh?

I've placed the script in one of my svn repositories:

http://svn.2xlp.com/Public/svn/MovableType/plugin_migrator/

As of the writing of this article, the current version is in tags/v0.01

** Updates below **

People keep throwing snowballs at me on Facebook. I'm pissed.

it seems that no matter how many times I block this application, it comes back with a new name. It's up to 4 now.

The developers behind this, whomever they are, seem to be migrating people across versions with subtle trickery -- do an action on one version, and it posts to another version of the app. Facebook asks for a new auth, but the names are confusingly similar - leading most people to think its the same application and jsut a bug.

Here's a picture of my blocked applications setting right now.

(ice) Snowball Wars
id = 8476307935

(cold) Snowball Wars
id = 4902358249

(new) Snowball Wars
disappeared / id unavailable ( but it is unique in my blocks list )

(frost) Snowball Wars
disappeared / id unavailable ( but it is unique in my blocks list )

I wonder what the point of the developers are -- to get around the constant blocking that purely annoying applications like this create ? Are they just trying to pump up ad sales? Or is this some method to get as many people to 'add' an application, so the id + subscriber base can be sold to another company for rebranding/utilzation as a new app (believe it or not, a lot of that goes on).

I don't know who's behind these apps, but Facebook and the Advertisers/Ad Networks should be ashamed of themselves.

It's the responsibility of Facebook to keep people like this who abuse Social Media platforms in check. The failure to do so not only lessens the utility of their platform, but harms their own brand image and affinity.

More importantly , it's the responsibility of Ad Networks to maintain brand integrity across channels. I'm truly sorry for all of the brands and advertisers who have placed ads with networks displaying on these applications -- I can't fathom the damage done to the advertising brands' image.

** Updated **
After talking with friends, it appears that just by accessing the application, 'Snowballs' are 'thrown' at people in your friends list through no opt-in of your own.

I think the developers are using a mixture of cross-application-linking with non-opt-in actions to circumvent the Facebook API throttles on publishing invitations and notifications.

Based on this behavior, I would recommend that people NOT grant any access to a 'snowball' application out of concern for personal privacy and the ability to publish activity through a Facebook account.

• note: this was updated on 2008.12.07 with a slightly modified layout: the versions were put into their own folder *

I've had the misfortune of having to leverage MovableType and WordPress into miscellaneous projects quite a bit lately.

With frequent updates for all these systems, I've developed a filesystem strategy for each that makes maintenance a tiny bit less of a headache.

This tips work on Linux/FreeBSD.

My MovableType install requires Apache , and optionally Nginx. But you still must use apache.

My WordPress install can use Apache or Nginx.

Shared Tips

First off, I serve all web content out of a home directory.

Why?

1. If its a shared hosting plan that I use for some blogs, I'm already locked into my home dir
2. On servers that I admin, I create new users for different projects and install into their directories. It's not as secure as using Jails/Sandboxes, but it adds a bit of security and makes it easier to switch deployment later on. I also like the idea of fully isolating projects into their own space.

MovableType

My MovableType deployment is fairly straightforward, and works for a multiple-blog and multiple-domain setup.

In my base directory ( in this example, its my home dir : /home/jvanasco), I have the following layout:

/home/jvanasco/__MovableType
/home/jvanasco/__WebRoot

Intro: /home/jvanasco/__WebRoot

This functions as my default webroot. Some hosting providers will automatically host domains as /home/USERNAME/www.domain.com . I find that very messy, because other files may be saved onto your home directory, and it can be hard to see all the files you care about at a given moment when you've got www.domain.com and blog.domain.com in the same folder with non-hosting files.

So I serve all of my domains in this format:

/home/jvanasco/__WebRoot/blog.domain.com
/home/jvanasco/__WebRoot/www.domain.com

As a side note, if you have more than a dozen domains with subdomains, you might want to utilize reverse sorting...

/home/jvanasco/__WebRoot/com.domain.blog
/home/jvanasco/__WebRoot/com.domain.www

Intro: /home/jvanasco/__MovableType

This is where I keep / manage my MovableType install.

I also manage/archive it into Subversion.

Currently, the directory looks like this:

/_current
/_plugins
/_source
/_themes
/_versions

If you're savvy, you already know how this layout works...

• _verisons contains all of the expanded mt versions.

• I have 3 versions of MovableType in this directory, v4.01, the Pro and OpenSource versions of 4.21 - this is so I can rollback if an issue arises.

  /MT-4.01 /MT-4.21-en /MTOS-4.21-en

• I keep a copy of the source files at all times in _source , just as an extra safety.

• I maintain my personal themes/setup in their own folder.. more later

• _current is actually a symlink to the current version. if we were in the shell, we could find out special information about it like this:

  $ ls -alh __MovableType/
  lrwxrwxrwx   1 jvanasco jvanasco   10 2008-11-29 21:54 _current -> _versions/MT-4.21-en
  

To those unfamiliar with symlinks, _current is special because its not really a file - its just a link. It was created with this command:

$ cd ~/__MovableType
$ ln -s _versions/MT-4.21-en _current

That basically makes _current a virtual representation of MT-4.21-en

This is useful, because all I have to do to switch MT versions ( assuming there are no database upgrade/downgrades ) is this:

$ cd ~/__MovableType
$ rm _current
$ ln -s _versions/MTOS-4.21-en _current

$ rm _current
$ ln -s _versions/MT-4.21-en _current

$ rm _current
$ ln -s _versions/MT-4.01-en _current

Tying things together

Let's use the real world example of this blog to tie things together:

1. Make the domain root directory

   $ mkdir ~/__WebRoot/www.destructuring.net

Serve via standard cgi

This is not really recommended , as a server having issues can show your source instead of executing it. But basically, you do this

1. jump into the home directory

   $ cd ~/__WebRoot/www.destructuring.net
   

2. create an alias to the current version of movabletype

   $ ln -s ~/__MovableType/_current mt
   

Serve via aliasing

I prefer this method, as you can protect code from being viewed

Edit your htaccess to read something like this:

    AddHandler       cgi-script .cgi

    <FilesMatch "^mt-(add-notify|atom|check|config|feed|testbg|upgrade|wizard|xmlrpc)\.cgi$">
         SetHandler cgi-script
    </FilesMatch>

    ScriptAlias /mt /home/jvanasco/__MovableType/_current
    <Directory /home/jvanasco/__MovableType/_current>
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

    Alias /mt/mt-static /home/jvanasco/__MovableType/_current/mt-static
    <Directory /home/jvanasco/__MovableType/_current/mt-static>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

What we're doing in this example is twofold:

• The ScriptAlias directive tells apache to process /mt as a cgi-bin , essentially protecting you from showing source.

  reference: http://httpd.apache.org/docs/2.2/mod/mod_alias.html#scriptalias

  The ScriptAlias directive has the same behavior as the Alias directive, except that in addition it marks the target directory as containing CGI scripts that will be processed by mod_cgi's cgi-script handler. URLs with a case-sensitive (%-decoded) path beginning with URL-path will be mapped to scripts beginning with the second argument, which is a full pathname in the local filesystem. A request for http://myserver/cgi-bin/foo would cause the server to run the script /web/cgi-bin/foo. This configuration is essentially equivalent to:

  and

  It is safer to avoid placing CGI scripts under the DocumentRoot in order to avoid accidentally revealing their source code if the configuration is ever changed. The ScriptAlias makes this easy by mapping a URL and designating CGI scripts at the same time

• The Alias makes sure that we serve the mt-static subdir as static files.

If you want even better performance, there are 2 things you can do:

• Serve all content through Nginx, and only proxy the /mt directory to Apache -- also have a rule to serve the /mt/mt-staic from nginx. There is no reason why you should waste memory and CPU on Apache's bloat.

• Use fastcgi, not cgi, to streamline peformance.

I haven't figured out a good way to run MT through Nginx yet. I'd love to find one, until then, using Apache on an alternate port to run cgi/fcgi stuff is really simple to get started.

Installation or Upgrading

Assuming everything works as planned, you can point your browser to mt/mt.cgi and handle your install/upgrade

Configuration

From the MovableType console, I make 2 important edits under the Publishing Setting tab:

1. I select "Publish archives outside of Site Root"
2. I change the archives root to: /home/jvanasco/__WebRoot/www.destructuring.net/archives

This centralizes all of my archive files into the /archives subdir. This means when I upgrade, everything is nicely packaged in that directory. it also means that I can use easier regular expressions to handle load balancing and proxing if I shift web servers around -- I know for sure that everything in there is static.

We do all this because... Upgrading your next MT Install

This is where your new setup really shines.

To upgrade your blog software, all you have to do is this:

1. Get the new version of MT and put it on your server

   $ cd ~/__MovableType
   $ wget new-movable-type-version.tar.gz
   $ cp new-movable-type-version.tar.gz _source/
   $ tar -zxf new-movable-type-version.tar.gz
   

2. Edit the config file

   Sometimes It may be useful to show a diff file of changes. Usually I keep a .dist (distributed) copy of each file in the dir.

   $ cp new/mt-config.cgi new/mt-config.cgi.dist
   $ diff old/mt-config.cgi.dist new/mt-config.cgi.dist
   $ vi new/mt-config.cgi
   

3. Backup your site.

   Better safe than sorry. Make sure you have a copy of your DB

   $pg_dump -Uusername -p database > DATE_TIME-SITE--backup-sql.sql
   

   It's not needed, but you should archive the docroot

   $ tar -cf DATE_TIME-SITE--backup-html.tar ~/__WebRoot/www.destructuring.net
   

4. Almost there... switch it over...

   $ rm _current
   $ ln -s _versions/new-directory _current
   

5. And finally... test/do the programmatic upgrade' Open your browser to http://domain.com/mt/mt.cgi , and follow the instructions. If anything happens, you have a copy of your sql and html archives!

That's it! This approach has really made it simple for me to maintain MT installs across versions.

Misc Stuff

Themes

Overview

I really hate how MovableType handles themes. I question the aptitude of the entire company for making such a half-assed attempt at a customization engine that requires 3rd party plugins to author into any sort of exportable or reusable concept. SixApart should be ashamed for making such crap.

I've been working on a way to make themes 'easier' to manage across installs, and have a partial solution. Here it goes:

~/__MovableType/\_themes is my theme repository. lets use the destructuring.net theme as an example.

$ ls ~/__MovableType/_themes/destructuring
_css
_img
_tmpl
screen.css
thumbnail-large.gif
thumbnail.gif

Explained:

• screen.css , thumbnail-large.gif , thumbnail.gif

  These are the standard MT stylecatcher files.

  screen.css looks like this:

  /*
  name: destructuring
  designer: jonathan vanasco
  designer_url: http://2xlp.com
  layouts: layout-wt , layout-wm
  */
  @import url(/mt/mt-static/themes/destructuring/_css/destructuring.css);
  

  notice how I'm importing another file. I find it easier to manage when I isolate my code from the MT stub.

• _img - the images needed for my theme

• _tmpl - I package all of the templates I use via a link-to-file setting. let's see how I do that:

  $ ls ~/_MovableType/themes/destructuring/_tmpl archive index modules system widgets

That should look familiar -- its the same section titles from the Admin interface where you edit templates.

And how are the files named ?

$ ls ~/__MovableType/_themes/destructuring/_tmpl/index
ArchiveIndex.tmpl  
MainIndex.tmpl  
MasterArchiveIndex.tmpl  
Stylesheet.tmpl

pretty simple! CamelCase the template name + .tmpl

Deploying

The theme gets deployed in 2 ways

1. The real location of the theme is ~/__MovableType/\_themes/THEME\_NAME

2. When I upgrade my install, I link the theme to the MT themes folder so it can be found

   $ cd ~/MovableType/current/mt-static/themes $ ln -s THEMENAME ~/MovableType/themes/THEMENAME

I then configure the link-to-file options in the MT admin interface to access the templates via: mt/mt-static/themes/THEMENAME/tmpl

as the root for the templates.

Caveats

The problem with this approach is that the 'link to file' option for template management needs to be manually configured/reconfigured.

I tried using /_active_templates as a symlink to the currently selected theme -- but it still requires a bit of scary stuff and needless labor.

If anyone knows how to make MT plugins well, lets talk! I have an idea for a free plugin/shell script that can do the following:

1. At the least, automate the 'link to file' process.
2. Even better: "load" templates from the distribution concept above into a workarea for MT and/or the database.
3. Even better 2: "publish" them out.

WordPress

My WordPress deployment is fairly straightforward as well. It's been designed for a single-domain setup, so it might not be of use to people using multi-blog feature (if they exist now) or plugins.

In my base directory ( in this example, its my home dir : /home/jvanasco), I have the following layout:

/home/jvanasco/__WordPress
/home/jvanasco/__WebRoot

I'm using the MovableType overview above as a template, so apologies if this starts to sound redundant.

When I need to use multiple wordpress blogs, I cheat -- I just create more linux shell accounts and users , and replicate this setup.

In the past I've done things like:

/home/jvanasco/__WordPress/
/home/jvanasco/__WordPress/blog1
/home/jvanasco/__WordPress/blog2
/home/jvanasco/__WordPress/blog3

But I've since decided that I like the multiple shell accounts because of the isolation it gives -- which is especially important if you've got multiple contractors or developers/designers working on projects with you.

Intro: /home/jvanasco/__WebRoot

Read the above section on MovableType, it is identical.

The one thing to note is that I often don't use a webroot for WordPress installs -- I find it unnecessary.

Intro: /home/jvanasco/__WordPress

This is where I keep / manage my WordPress install.

I also manage/archive it into Subversion.

Currently, the directory looks like this:

/uploads
/_current
/_plugins
/_source
/_themes
/_versions

If you read the MovableType section, you can guess how this works:

• I have 2 versions of Wordpress in the _versions directory, 2.6.2 and 2.6.3 - this is so I can rollback if an issue arises.

  /versions/wordpress-2.6.2 /versions /wordpress-2.6.3

• I keep a copy of the source files at all times in _source , just as an extra safety.

• I use an uploads dir outside of the webroot to store all my uploads
• I maintain plugins and themes outside of the install root, more on this later

• _current is actually a symlink to the current version. read the MovableType info above to find out more about symlinks, but in general, I created this link by doing

  $ cd ~/__WordPress $ rm _current $ ln -s _versions/wordpress-2.6.3 _current

Tying things together

Let's use the real world example of this blog to tie things together:

1. Make the domain root directory

   $ mkdir ~/__WebRoot/www.destructuring.net

Serve via standard php

Personally , I prefer using Nginx + FCGI to serve wordpress and all other php things. Something that is really useful about this setup, is that it often works very much like Apache's ScriptAlias -- in that your source will not be served in the event of a server misconfig.

The basic config is very simple -- you simply set your docroot to be ~/__WordPress/_current.

WordPress Configuration

Wordpress Console:

• under Settings -> Miscellaneous , I set store uploads in this folder : /home/jvanasco/__WordPress/uploads

Filesystem Configuration : Uploads, Plugins & Themes

Wordpress has A LOT of updates. A crazy amount, really.

Why?

• The code is AWFUL. I say this a lot. It's pathetic. The 2.5 (or 6) upgrade, for example, had a passwordgenerate function that was incompatible with its passwordvalidate function. This isn't just me griping -- It's downright shameful.
• There are countless security issues. Some of these aren't necessarily WP's fault, but due to the PHP platform or coding conventions it necessitates.

Sometimes you'll install a WP version and find an update the next day. Sometimes you'll upgrade and need to upgrade again the next day -- and you need to

With that in mind, I gave up on the recommended WordPress concept of moving content, plugins and themes around. Instead I do the following:

• I keep ALL 3rd party or personal plugins and themes in their own folders under ~/__WordPress/_plugins or ~/__WordPress/_themes
• I remove wp-content/uploads from each distribution and link it to ~/__WordPress/uploads ( see symlink info under MovableType )

So to handle this, after unpacking wordpress each time, I do this:

$ cd ~/__WordPress/_versions/VERSION/wp-content

$ rm uploads
$ ln -s ~/__WordPress/uploads uploads

$ cd ~/__WordPress/_versions/VERSION/wp-content/plugins
for each plugin I manage, i do this:
$ ln -s ~/__WordPress/_plugins/$NAME $NAME

$ cd ~/__WordPress/_versions/VERSION/wp-content/themes
for each themes I manage, i do this:
$ ln -s ~/__WordPress/_themes/$NAME $NAME

I find this solution to be far superior to WordPresses for a simple reason: the plugins/themes that come with each release are apt to change. wp-content is POORLY designed , because :

• uploads ONLY have user info
• plugins and themes ALWAYS has wordpress content that could upgrade, and OFTEN hhas user info With those 2 concepts in mind, it's just not a good idea to overwrite files/directories -- you might lose an important upgrade or personal information.

We do all this because... Upgrading your next WP Install

This is where your new setup really shines.

To upgrade your blog software, all you have to do is this:

1. Get the new version of WP and put it on your server

   $ cd ~/__Wordpress
   $ wget new.tar.gz
   $ cp new.tar.gz _source/
   $ tar -zxf new.tar.gz
   

2. Edit the config file

   Sometimes It may be useful to show a diff file of changes. Usually I keep a .dist (distributed) copy of each file in the dir.

   $ cp new/wp-config.php new/wp-config.php.dist
   $ diff old/wp-config.php.dist new/wp-config.php.dist
   $ vi new/wp-config.php
   

3. Backup your site.

   Better safe than sorry.

   Make sure you have a copy of your DB

   $mysqldump -uusername -p database > DATE_TIME-SITE--backup-sql.sql
   

   It's not needed, but you should archive the docroot

   $ tar -cf DATE_TIME-SITE--backup-html.tar ~/__WebRoot/_current
   

   NOTE: I've never had to rely on a docroot copy, so I'm not sure that it works. If anyone can email me and confirm that the contents of the symlinked dirs are archived into the tar, I would be grateful. I don't have time to research this on my own.

4. Symlink the plugins, themes, uploads stuff as described above

5. Almost and then switch it over... $ rm _current $ ln -s _versions/new-directory _current

6. And finally... test/do the programmatic upgrade'

   Open your browser to domain.com/wp-login.php , and follow the instructions. If anything happens, you have a copy of your sql and html archives!

Conclusion

That's it!

These tips have helped me manage multiple domains and multiple installs. I'm always open to new tips and tricks -- so if you have any ideas that could streamline administation even more, please share!