Single Site Instructions

The MT: GS single site migration documentation for is quite excellent. My process was only marginally different than what they describe. A brief outline of the process which took 10 – 20 minutes per domain depending on file sizes:

1. Add a new domain on MT:GS
2. Create email user with FTP and SSH access for the domain.
3. Create new database and user / pass with permissions access to it.
4. Login to your phpmyadmin to take an export of your entire database.
   Optional: Use a WordPress database backup plugin if you find it easier.
5. SSH login to your existing webhosting domain root folder (httpdocs? html? wwwroot?)
6. tar -zcf yourentiresitebackup.tar.gz *to create a single archive of your entire site.
7. SSH login to your MT:GS server and the appropriate domain /html/ folder.
8. wget http://[insertyourdomainname.com]/yourentiresitebackup.tar.gz to copy the archive folder.
   For large sites or for those who are not on truly high-speed connections, doing this server-to-server copy of a single file is MUCH faster than the alternative download to local PC / upload to new server alternative.
9. tar -zxf yourentiresitebackup.tar.gz to uncompress the archive.
   Don’t forget to delete the archive once you’ve confirmed the site is operational.
10. Go into the MT:GS database admin page and import your mySQL archive from step 3.
11. Setup your new local FTP connection in your development IDE of choice.
12. Your database connection strings will have changed. Modify the wp-config.php files on the new server.
    The tutorial linked above outlines this information very well. The change of localhost to $ENV{‘DATABASE_SERVER’} was the only unexpected item to me for this.
13. Replacing 000000 with your account details, you can now preview the domain either at http:/s00000.gridserver.com if it is the primary domain on your MT:GS site or http://sub.alt-example.com.s00000.gridserver.com if it is an additional domain.
14. Update the DNS entries and wait for the magic to happen.

Their tutorial did cover updating site paths & previews within the SQL database before updating the DNS, but once you’ve ensured your landing page is accessible, the rest of the site will show properly when the DNS have propogated so I found it as a step worth skipping. You may have to re-generate your .htaccess file via the WordPress admin console once that has been done. If you’re DNS are taking longer than you care to wait you can temporarily map DNS/IP addresses to the new server.

Another quirk I discovered is regarding the mail server configuration. Despite the fact that, “When a domain is added to a (gs)Grid-Service, the mail service is automatically created” it is not enabled by default. You have to enable it via the account center in Media Temple.

MultiSite Migration

Wash, rise, repeat? Almost. In the case where I was migrating existing domains as a part of a MultiSite installation things were essentially the same for steps 1 to 13 as above for the primary domain.  In the case of the sub-sites there is no need for database or file transfer since the primary one stores everything. One merely had to create a symlink between your subsite and primary network site via ssh on your MT:GS environment. This was actually a lot easier to resolve than my previous hosting environment which had a mix of cPanel + Plesk and required an intricate series of steps.

To bring other domains over to the new WordPress Network on MT:GS environment this migration guide was a useful place to start. A couple of other pieces of info I discovered along the way that may prove helpful to others:

• The WordPress Import screen for WXR data will not be available on sub-sites until you enable it on the primary domain of your Network.
• With the Super Admin / Network Admin changeover, as of 3.2.1 you may find the excellent domain mapping plugin menu has changed locations.
• When dealing with a site that was already domain mapped in the new installation (but had not yet had the DNS updates) I was struggling to find a way to preview the site similar to step #13 above for a single site. The subsite URL would re-point to the full domain, and the subsite.s000000.gridserver.com would be treated as if it were a new registration request. The easiest solution is actually to NOT have a domain mapping in the primary site until you are ready for the switch, that way subdomain.primarydomain.com will display everything as you need to test plugins, theme, etc.
• The WXR import / export will bring all your posts, pages and related content and then offer you the option to bring across all attachments which could be a lengthy conversion depending on size of your files – which are essentially moving from /wp-content/uploads/ on your single-site to /wp-content/blogs.dir/##/ on the new server where ## represents the ID of your subsite.
• Don’t forget to confirm whether the plugins / theme features from your single install work on the multi-site environment.

Good luck! If you find any other tips / tricks that can help others on this path, feel free to post a comment to share.

Capture and display custom data types using ICE and More Fields

Building on the concept of category templates which I started with the FAQ template tutorial last week, this tutorial will cover how to capture and display custom fields in a template. What’s more, I’ll go through the step-by-step process of how to implement this using More Fields which is a plugin that “enables you to define post types, which are custom Write/Edit pages that contains a pre-defined set of boxes” that store their data behind the scenes in custom fields. The concepts from this tutorial will be of interest for anyone who:

• Has multiple categories of blog content with unique data to capture / present. Thumbnail per post, photo of the day or other customized items.
• Uses WordPress as a CMS for unique page data types (event calendar, classified ads, business partners, etc)
• Finds the selection of custom fields from a drop-down to not be the best user interface experience for capturing structured data.

Direct Video Link:http://www.screencast.com/t/2dcpYsSlk

Example Code

The only real code in this template that is unique is the retrieval of data from a custom field using the get_post_meta function.

A single custom field retrieval
Place this example within the loop of an existing category / post template.

<?php $locationPhone = get_post_meta($post->ID, 'locationPhone', true);
if ($locationPhone != '') { ?>
	<div class="locationInfo">
		<h4>Phone Number</h4>
		<?php echo  $locationPhone; ?>
	</div>
<?php } ?>

Full retail location fields
This example is the full loop for use within a category.php file to display the contents of custom fields named: location

<?php if (have_posts()) : ?>
	<?php while (have_posts()) : the_post(); ?>
 
	<h2><?php echo the_title('','',false); ?></h2>
	<?php the_content(); ?>
	<div class="clear"></div>
 
	<?php $locationAddress = get_post_meta($post->ID, 'locationAddress', true);
	if ($locationAddress != '') { ?>
		<div class="locationInfo">
			<h4>Address</h4>
			<?php $locationMapURL = get_post_meta($post->ID, 'locationMapURL', true); ?>
 
			<?php if ($locationMapURL != '') {
				echo  "<a href='" . $locationMapURL . "'>"; ?>
			<?php } ?>
 
			<?php echo  $locationAddress; ?>
 
			<?php if ($locationMapURL != '') {
				echo "</a>";
			} ?>
		</div>
	<?php } ?>
 
 
	<?php $locationPhone = get_post_meta($post->ID, 'locationPhone', true);
	if ($locationPhone != '') { ?>
		<div class="locationInfo">
			<h4>Phone Number</h4>
			<?php echo  $locationPhone; ?>
		</div>
	<?php } ?>
 
	<div class="clear"></div>
 
	<?php $locationHours = get_post_meta($post->ID, 'locationHours', true);
	if ($locationHours != '') { ?>
		<div class="locationInfo">
			<h4>Business Hours</h4>
			<?php echo  $locationHours; ?>
		</div>
	<?php } ?>
 
	<?php $locationWebsite = get_post_meta($post->ID, 'locationWebsite', true);
	if ($locationWebsite != '') { ?>
		<div class="locationInfo">
			<h4>Website</h4>
			<?php echo  "<a href='" . $locationWebsite . "'>" . $locationWebsite . "</a>"; ?>
		</div>
	<?php } ?>
 
	<div class="clear"></div>
 
	<?php endwhile;
 
else : ?>
 
	<p><?php _e('Sorry, no posts matched your criteria.'); ?></p>
 
<?php endif; ?>

A repository is just a fancy way for saying a place to store your data much like an FTP server. What makes using one so important is that you create versions of files so that you can always roll back if you make mistakes. The WordPress.org site contains some very good information on How To Use Subversion to create / contribute to a plugin…if you are a fan of command line tools. Some people probably prefer that approach – just like using vi as a text editor. However, I find graphical based user interfaces easier and more efficient to use.

This tutorial is for those who – like me – use Dreamweaver for web development and want to maintain their plugin code on the WordPress repository through it. For those who use Eclipse, you can follow a similar process using SubClipse. The two key pieces of the puzzle are:

• TortoiseSVN – An SVN client for Windows that makes version management simple.
• SubWeaver – A Dreamweaver extension to integrate SVN commands through Tortoise.

Setup your WordPress.org account and plugin repository

The first thing you will want to do is go to WordPress.org > Extend > Plugins and register for an account. The contact information (name, email, website, etc) you provide will show up with any plugins that you create or contribute to.

Since you’re on the site and ready to start your first plugin, go to the Add a Plugin form and provide the appropriate details (name, description, url). Note that it may take 24 – 48 hours for your plugin request to be approved, but this will create a new repository for your plugin.

Install Tortoise and SubWeaver

Download and install Tortoise SVN from http://tortoisesvn.tigris.org. You will have to restart your computer for the changes to take effect.  After that has completed, you will want to download and install Subweaver from http://code.google.com/p/subweaver/

When you are looking at the file explorer in Dreamweaver, you will now see a new SubWeaver sub-menu that I will explain the primary uses of it as we go along.

Create a local repository

You will need a folder on your hard drive to store the plugin files / folders. Find the folder in Windows Explorer and right-click on it to select SVN Checkout. You will have to add the repository information which was specified when you completed the Add a Plugin form. The repository path should start with http://svn.wp-plugins.org/ as the image at right shows for Idealien Category Enhancements.

You could do this through Dreamweaver directly, however I prefer to do the initial checkout by Tortoise so that when I create the site in Dreamweaver it already contains the standard SVN structure.

Understanding the structure of a repository

There are 3 different locations where you can place code which are loosely based on the analogy of a tree:

• Trunk represents the area where your active development goes. When starting your plugin, it will be where you add your first files. It is the latest and greatest so might not be ready for public consumption.
• Tags are for specific versions of your plugin. Any time you commit significant changes to your trunk (i.e. a new version) you should create a new tag and update the readme.txt file to indicate what the newest release is. I have gotten into the habit of developing on a separate WP installation (easier for testing, debug, etc) and as a result the code in the trunk usually mirrors the most up to date tag available.
• Branches are for working on enhancements or code you would like others to beta test or build in isolation of other functionality. When you’re satisfied with a particular branch, you will have to merge the changes into the trunk. Smaller scope plugins usually won’t use branches.

Or as the wordpress.org site puts it:

Each time you make a formal release of your plugin, you should tag a copy of that release’s code. This lets your users easily grab the latest (or an older) version, it lets you keep track of changes more easily, and lets the WordPress.org Plugin Directory know what version of your plugin it should tell people to download.

Add, Modify, Delete or just Commit!

You now have a link between the repository and your local computer. Work with the files on your local PC until you are satisfied and ready to commit them to the repository.

• Highlight all of the files that you have modified.
• Right click and chose to SubWeaver > Commit
• Dreamweaver will show you the SVN log in which it compares every file on your PC against the repositor and the action (add, modify, delete) it did to the version in the repository as well.
• If you want to ensure you don’t miss anything, select the top-level folder for your plugin and then commit. Note that if you do this and you have added / deleted any files, you will have to specifically check their checkbox under the changes made window.

The update process on the repository server will take a few minutes to show up in the Plugin Directory.

Updates and Merges

The work scenario I described above is written on the assumption that you are the only one editing files for your plugin. If you are collaborating on another plugin, before you start to work on changes you will want to execute an SVN update to ensure you have pulled the latest files from the server to your local PC.

It is possible (read: likely) that at some point in time you will encounter a scenario where someone else has updated the files which you are working on in between when you updated your files and when you went to commit. You now must merge your changes with theirs which is the bane of many developers. While Tortoise / SubWeaver do have tools built in to compare files, I have found that WinMerge is a better tool built specifically for this task. You can install it and configure it with Tortoise under the Settings > External Programs menu.