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.