The plugin creates a custom post type (Rideshares) which enables you and your community to get to where you want to go using less gas and having more fun on road trips. It has been designed towards event-based rideshares in particular so that drivers and passengers in the same city can co-ordinate their travel to whatever festival, concert, workshop, WordCamp, etc they are attending elsewhere. The admin form is easy for adding / editing rideshares for those who have access to your sites’ admin console. To make the process as easy for your extended community, this plugin also provides an exceptional Gravity Form to let anyone submit their rideshare request via the front-end of your website.

For more details I’d point you to either check out the plugin repository with it’s detailed installation instructions or the rideshare.idealienstudios.com plugin site that I setup to support it.

In case you’re wondering why v0.1, it’s because the plugin doesn’t (yet) have all the features / functionality in it that I think are worthy of a 1.0. At the moment, I’m expecting to do a big version jump when:

• The Gravity Form is added to an installation during initial plugin activation.
• You can configure the plugin via an options screen to operate in a straight date-based model or the event-based one it has initially been designed for.
• Uninstalling the plugin will remove all taxonomy and custom post rideshares.
• Registered users gain the able to remove their rideshare request when you have filled it.
• Cron job added to remove any rideshares that have expired

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.

Fully filterable

I will fully admit that the portfolio page of this site sat dormant for far too long with a ‘mea culpa’ message suggesting that “I am currently updating my portfolio to reflect the work I have done for various clients during my 10+ years in the web design / development industry.” “. The truth is I consistently put the priorities of my clients – and other personal projects – ahead of a polished portfolio. BUT NO MORE!

The new version is built with a fantastic WordPress 3.0 custom post type that allows interested individuals to:

Full of details + pictures

• Sort / filter my past projects with a single-click based on their area of interest (skills used, project type, date, client demographic, etc). I had been wanting to use the jQuery plugin Quicksand for quite some time and this was the perfect situation. The integration of custom taxonomies was not easy, but you can look forward to tutorial /  sample and a portfolio plugin to come to this blog + Idealien Projects before the year is out.
• Read a summary of the project highlights.
• A jQuery lightbox allows those who want to dig deeper to see full-sized images of the key parts of the project as well as learn more about what went into making each of those happen.

The 3 pieces in the portfolio are either my most recent works or my most favourite past project. You’ll have to browse through them to find out. What are you waiting for?

• Less stop and go traffic than my existing commute which could often approach 45-minutes in-city.
• Ample time to listen to great podcasts on my iPhone via FM Transmitter to keep me up-to-date on the latest details of the web design and WordPress industry(ies).
• Opportunities to think about particular coding challenges outside of pressing deadlines. The results of which are highly scalable and re-usable code that will benefit many current and future Idealien Studios clients. Not to mention others in the WordPress community as the results will make their way out as plugins or projects of an open-source variety very soon.

It has been a magical summer to say the least. At the beginning of August we also decided the time (and place) was right to get married on our farm. Mother nature showered us with beautiful blue skies as many friends and family came together to witness the Oastler empire expand by 2

After a few well-deserved weeks off to celebrate said nuptuals, many wonderful things are coming together in a timely manner on the professional side of my life as summer too quickly changes to fall. The release of WordPress 3.0 in June brought with it a significant number of new features which further my long-held belief that WordPress = CMS. Deploying this release worthy of the milestone version mark and the Multi-Site capability in particular will enable faster support deployments to all Idealien Studios small-business clients. The use of custom post types built as plugins will also make content management for clients far easier for those not comfortable with html and even faster for those who are. Specific fields capture your data through radio buttons, checkboxes, etc (known in WordPress lingo as meta boxes or custom fields) and short codes handle the data display on the presentation layer that your customers see exactly what you want them to.

As we enter the last quarter of 2010 I am quite excited about the future for so many reasons. I look forward to more opportunities to share knowledge and success together.

The GPL website FAQ does mostly addresses this concept, “If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.”

Bryan at One Man’s Goal pondered the issues surrounding digital copyright leeching and the following quotes summarize the (then) prevaling opinions on this situation:

By designing on a GPL platform…when you release it to the public you are releasing it licensed to everyone not just those who pay for it. Companies like Redhat linux make their money not by charging for the linux o/s which is open source, but by charing for support and tweaking packages that are added to it. That’s why CentOS can directly clone what Redhat Enterprise is and not be touched.

The part of themes or plugins which makes them subject to the terms of the GPL is that they use WordPress code hooks to extract data from the WordPress database. While theme designers can SAY that their theme is licensed under some non-GPL model, they have no legal basis to do so. Someone profiting from reselling the work of another is ethically rotten, but in the current legal landscape is technically fair.

This issue of theme theft, re-selling (or conflicting business models and the GPL) comes up every couple months. This obviously sucks, but based on the current WordPress code structure and theme distribution model, there isn’t a lot which can be done – it is the nature of the beneficial beast that is working with open source licensing models. It caused me to think outside the box and ponder a different approach to resolve the problem at hand.

Distribute separate theme packages with split license

1. GPL-licensed files which include all references to WordPress logic
   This .zip archive would only contain the .php files which make up the theme – sidebar, header, index, comments, etc. These files would only have integration to css through the id / class names applied to div containers. A blog owner that deploys this package alone will have their content displayed in a reasonable approximation of the theme structure without any styles applied.
2. Images, javascript and css files licensed under whatever terms the designer wishes
   This second .zip file would contain all the elements required to convert that basic structure into the beautiful presentation shown in the theme screenshot / demo. After purchasing this set of files, the user would have to upload these into the theme directory – a process which has been proven simple enough for most blog owners to execute without issue.

What are the benefits?

• Separate downloads equals separate licenses
  This concept would be viable because of the difference the GPL affords non-dynamically linked plugins. As the visual elements could be used with any system they would not be subject to the terms of the GPL.
• Separating form from function
  Decoupling the business logic and presentation layer is a best practice which simplifies future development efforts. Developers already recognize the benefit of separating substance and style – html and css anyone? Automattic made a sound decision to separate blog operations (wp-admin) from custom functionality (plugins) and presentation (themes).
• Consistent with standard design processes
  Designers usually cut a photoshop file up into images and use a static .html template file to perfect the css with them. The non-gpl .zip file would represent this stage of design. The PHP code which uses WordPress hooks to dynamicize this template would become the GPL-licensed .zip file in effect.
• Developing architecture agnostic solutions
  With the graphics and css separated from WordPress specific code, your theme is now portable to other open source architectures: Joomla, Drupal or Expression Engine. Whether the premium designer does the work themselves or partners with someone else, they have diversified their potential markets. Including the static .html file(s) you built during the design phase and it could be sold as a generic css template as well.
• Multiple premium themes from one template
  If the css elements are well-designed it would be easy to create multiple themes from the same template. A fishing blog and could buy incremental series of graphics for ice fishing, fly fishing or bass fishing, or a seasonal treatment to a single outdoor painted scene.

I would suggest that the designers be nice, and implement a basic styles.css with the GPL code. Give the user a rough guideline based on sizes of the placeholders for where the graphics would go. Include a link in the comments at the top – which show up in the WordPress theme page – where they can / should download the graphics if they want the full effect of the premium design.

What are the problems?

• A challenge for premium theme galleries?
  The dozens of free WordPress theme galleries would not require any change, but any premium theme galleries would. One might argue that since they already have a different download process with credit card collection – it’s not like there is a high degree of learned behaviour to overcome so this isn’t that much of a problem.
• Asking users to do more in order to implement a design
  The majority of blog owners seem comfortable with the process of downloading to PC, unzipping into the wp-content/themes/ directory, uploading to server and activating, so adding a second download/unzip/upload is another non-issue of sorts I suspect. If this idea takes hold and all premium theme developers begin to adopt this process, eventually users learn that is the expected set of actions required to install a premium theme.
• A thief is a thief is a thief!
  Not much you can do about someone who has no moral issue with theft. Yet this con becomes a pro by the fact that you now have a legal recourse to sue Mr. Thiefy McStealerton as your original artistic works are not subject to the GPL but to the license you chose to make them available for purchase under.

I could only come up with one other option, which was to suggest that designers host the css / graphic files on their own servers and restrict who has access to them. Obviously this puts an external dependancy on blog performance which many would not like, but would give a more significant level of control as the styles.css file and images would be on your server. Perhaps this concept would work for WordPress.com users and the marketplace concept which Automattic has been hinted is coming in the near future.

In the 2 years since I originally wrote that article, the premium theme industry developed around a number of thriving businesses. Today, most of the theme developers who sell their wares do so entirely under the GPL. The symptoms causing the questions to be raised may have changed, but the important ones still remain:

1. Can (or will) developers distribute their work under multiple licenses which would respect the source code base license?
2. What do you do if someone does not respect the license that your product is distributed under?
3. How will this on-going conversation affect the open-source community surrounding WordPress?

Here are some of the links that I have found most useful in the last few days of my first cut at custom post type implementation and re-factoring with new features supported in 3.0:

• http://wpengineer.com/example-how-to-add-meta-boxes-to-edit-area/
• http://www.deluxeblogtips.com/2010/04/how-to-create-meta-box-wordpress-post.html
• http://www.catswhocode.com/blog/8-useful-code-snippets-to-get-started-with-wordpress-3-0
• http://justintadlock.com/archives/2010/04/29/custom-post-types-in-wordpress
• http://justintadlock.com/archives/2009/05/06/custom-taxonomies-in-wordpress-28
• http://www.webmaster-source.com/2010/01/08/using-the-wordpress-uploader-in-your-plugin-or-theme/
• http://wpengineer.com/use-more-flexibility-in-wordpress-templates/
• http://wpstorm.net/2010/04/editor-styles-custom-post-types-wordpress-3-0/

While the big features coming with 3.0 are getting a lot of the words / press, there are quite a few little things that have been improved that are worth mentioning.

New Installation Screen Updates

Without fail the first thing I would do on installation of any WordPress 2.9 or earlier setup would be:

• Create a new admin account (not named ‘admin’) with a secure password
• Re-login as that user and delete the existing ‘admin’ user

Having the option to provide this as a part of the initial installation is great. It could also reduce the amount of potential site hacks others encounter who never did this in the first place by giving them the username option at install time.

Header Image Management

The new default theme, 2010, looks quite a bit better than Kubrik which was showing its age. While some question the value of theme configuration pages in the admin console, users who want an easy way to tweak the look of their site without touching code will love the header and background image upload capability. I have explored a little of how it has been done (hint: function add_custom_image_header and /wp-admin/custom-background.php) that I can see being useful:

• Uploading of .pdfs or other attachments into a custom post type where you don’t want to have the URL defined in the content editor field.
• Bringing the featured image into a meta box along with other content type data (instead of a stand-alone meta box)

Idealien Category Enhancements: Refactor or Retire?

Idealien Category Enhancements (ICE) was the first plugin I wrote for WordPress, circa WP 2.5. When I was trying to find a workable solution before committing to writing it, I felt like the ability to connect template files through the admin console should be something that was part of the core of WordPress. The significant updates to 3.0 have raised some interesting questions in my mind:

• The inclusion of custom post types  has all but eliminated the use cases where I do make use of ICE in 2.9-. A category-driven approach feels so “duct tape / McGyver” when compared to the full-scope solution of custom post types.
• The ability to define single-{posttype}.php in a theme based on category was the feature most people who left feedback about the plugin indicated was why they were using it. Replace category with custom post type and you don’t need a plugin to achieve the same purpose.
• Pages with short-codes or Page Templates that use the query_var parameter tied to register_post_type can give an easy way to integrate post types into menus and navigation. You can even control the slug so that a page which acts as container for a post type “category” is identical to what the individual post types will use. This was always a challenge with ICE, although some writings on the permalink performance associated with /%postname%/ does make one wonder can vs should questions.

There will be a not insignificant amount of re-factoring work to enable any site to take advantage of the new features coming with WordPress 3.0. As I said at the outset, template management should be something that is part of the core of WordPress so I’m not entirely unsatisfied that this has come to pass. I’d like to think that my plugin helped influence that decision in the positive direction it has gone. I’m leaning towards retiring Idealien Category Enhancements as a result, but would appreciate any comments from those who currently use it and are looking at their options for 3.0 upgrade process.

I would use WordPress to run one of my personal sites. I would not use it to run the websites at work (I lead a government web team). I generally find that people saying it IS a CMS are people who deal mainly with small to medium websites, which WordPress is perfect for, and those saying it’s NOT are dealing with much larger and complex sites.

While this position is debate-able, it is mostly dependant on your definition of the term enterprise and what specific client requirements are involved in a given site. I will cede the point by saying that WordPress is not YET an enterprise-level CMS that can compete on a feature-by-feature comparison with such high cost platforms as Red Dot, Vignette, Interwoven LiveCycle, etc. These systems often require just as much configuration / customization to implement client-specific elements as a small business site built on WordPress – only the consultants for these platforms generally charge a higher premium for their specialized “niche” knowledge.

Don’t look a crazy horse in the mouth

It wasn’t that long ago that the answer of whether WordPress was a CMS was a harder position to defend. I gave a presentation in 2008 at Wordcamp Toronto – WordPress: Beyond a Blog – and mathematically proved that WordPress = CMS. The definitive deliniation came after the crazyhorse fiasco and, in my mind, co-incided with the 2.7 release (Dec 10, 2008) for a few reasons:

1. The major UI improvements to the admin console gave it a more professional (read generic) colour palette.
2. Usability improvements enabled access any content area / type or configuration element via a single click.
3. Steady improvements on the well-defined plugin / theme / filters / hooks architecture and the 1-click update.

Overall these improvements have made the process to create, customize or update a WP-powered site into a task-scale work effort compared to a project-level one. This is an important distinction given the frequency of releases for WordPress (both a pro and con).  I am quite excited about the upcoming killer features of WordPress 3.0 (menu management, custom post data types) that will further make any questions of its CMS capabilities that much harder, ney impossible, to refute.

To summarize: In a less than 18 months, WordPress has gone from being debateable as a CMS in general to being debateable as an enterprise-level CMS. Not bad for a open source project that has blogging as its core focus Especially when compared with other open source projects that often struggle to make in-roads into non-core areas (see Linux desktops in corporate environment). WordPress has grown into a viable COTS (customized off the shelf) product – it just happens to sit on a shelf with a price of $0 which is a big selling point when most other enterprise-level CMS platforms have quite a few more 0′s in their sticker price!

How could WordPress be considered an enterprise-level CMS?

This is the real question I wanted to address with this post. There are a number of features  / areas of concern I see with the current state of WordPress that prevent it from being seriously pitched or deployed as a corporate business platform. In some cases there are plugins which fill the gaps reasonably well. In others there may be limitations that the blog-centric principles it was founded upon prevent it from solving. In all cases, I want to encourage discussion of these areas to see which are areas worth researching by those who have a passion for the platform or have plugin programming powers in need of a niche. If you think of functionality I have missed, or plugins which provide the gaps I have identified, please add a comment.

• Custom Data Types
  Plugin of Choice: More Fields, PODS, WordPress 3.0!
  Yes it is possible to train users to select a strangely titled custom field and populate it, but it is not an elegant solution compared to data entry directly into named fields. Soon,easily configurable custom data capture / presentation will be possible out-of-box with WordPress. This is probably the feature concept I have been most wishing WordPress would add since I started working with it as a CMS.
• Backup
  Plugin of Choice: WP-DB-Backup
  It is critical to have a reliable, regularly scheduled backup process that is easily re-deployable. The newest line of business added to Automattic, VaultPress, offers such a service for those who aren’t comfortable with web server / database backups. It covers “your plugins, dashboard, themes, comments, and even your post revisions are all safeguarded and ready to be restored.” Perhaps someone could re-use the plugin code  to create a version that enterprises could deploy within their own architecture to leverage their existing hardware spend.
• Bilingualisation
  Plugin of Choice: qTranslate
  While the default language of the Internet is english, there are far more people who prefer non-english languages. The support for multiple languages of the admin console is excellent, but content capture and display of multi-language support is still suspect. qTranslate handles the core fields (title, content, excerpt) well, but not custom fields, meta boxes, etc. Hopefully with a robust 3.0 focused upgrade of qTranslate, we might come close to “fully multi-lingual support” across all data types.
• User / Role Management and Content Control
  Plugin of Choice: Justin Tadlock’s Members Plugin
  The default approval concept from contributor / author through editor / administrator fits reasonably well when you have ‘anyone can write anything’ environments and editors who have latitude across the entire site. But a corporate environment might have people who only handle specific types of content. 3.0 will greatly simplify the process of isolating such content areas and improve the associated “data entry screens”. Further capabilities to define roles, which users have access to them, what they can access becomes more important as the variety of workers who interact with the CMS scales up.
• Workflow Management
  Closely related to the roles which users have is how the content approval process happens. Some content only requires single-level approval, others must be blessed by people very far up the corporate ladder before publishing. The addition of this feature should be configurable though off by default to avoid confusifying the “I write my own blog” default use case for WordPress. I haven’t tried or heard of any plugins that have tackled this concept yet, have you?
• Content Release Environments
  Closest Conceptual Plugin: WP Hive
  Workflows work when you are dealing with individual content updates, but how do you handle an entire new section, or re-writing a sizeable portion of an existing site? Incremental draft / publish just won’t cut it. Creating a new instance of a site on an internal server is easy enough (see backups), but merging the changes that occured between the time the copy of  production environment was taken and the new section going live is not.

  It would be interesting to see WordPress converted to a repository-driven approach where content gets “checked-in” to a central instance and staff can “cut releases” to different environments for testing. The low overhead of WP (php / mysql) deployment would make creating new environments a breeze compared to some of the large-scale CMS that have hefty hardware requirements to host.

• Lead Generation / Forms
  Plugin of Choice: Gravity Forms
  The simplicity with which you can use Gravity Forms UI interface to create forms is amazing. They are steadily adding features which, in the hands of great developers, convert WordPress into a complete swiss-army-knife of lead generation or crowd-sourcing content creation. As far as WordPress plugins go, their $199 price tag is steep, but it is well worth it compared to the value it provides. Multi-Step forms with configurable step-logic would be high on my feature request checklist to round out its already impressive functionality.
• 3rd Party Platform Integration
  Closest Conceptual Plugin: Xavisys WordPress Plugin Framework or BackPress
  How do you access and display pricing data from a legacy product database? Or information from a 3rd party supplier API? Can you syncronize customer info from an existing LDAP or Salesforce with WordPress? Each enterprise would have a unique set of requirements to consider the complexity of integrating during the concept initiation phase. Having shared knowledge resources that demonstrate best practices would be invaluable to know what is / is not possible. Or if you have something larger in scope to work with, you might consider BackPress which is starting to sound like a robust way to develop with the principles of WordPress as a framework to start from.

Where to draw the line?

I thought about including functionality most enterprise sites would leverage – event calendars, payment engines, product shopping carts, etc – but stopped as that was starting to blur the line between CMS and web application. It is a testament to the versatility of WordPress that it could just as easily convert into or add-on functionality of an eCommerce system, a forum or social network. With that in mind I ask you, Is enterprise-level CMS really that much more of an ambitious stretch?

Rideshare Custom Fields captured via More Fields

As I mentioned at the end of my last post on the Power of Custom Fields, I recently started working on a prototype site that required rideshare board functionality. Storing the details lends itself well to custom fields, especially when More Fields is used for data capture as you can see from the inset image. However, I struggled to find a solution within WordPress to solve a display challenge: How to display a set of posts based on multiple custom field values? In my case, how to loop through rideshares base on event and ride-givers or ride-wanters.

I explored looping through each post in my rideshare category to match the rideshare event to an array value and then using get_post_meta within to see if results belonged to the ride-giver or ride-wanter. While this might have worked, it certainly wouldn’t be an elegant – or Idealien solution. Dan Butcher did provide a functional solution in the WordPress Support Forums for a similar challenge, but it is not a solution a novice / intermediate WordPress developer would be comfortable customizing, nor would it scale well. Barry @ clearskys.net informed me that,

Whilst the JOINS work, and will work quite well with a few meta-data criteria passed in, I’ve had problems (particularly on shared hosting) in the past when creating an SQL query to search based on a series of tags which used a similar method.

Introducing get_post_meta_multiple

This function I created, with sql optomization support from Barry @ clearskys.net:

• accepts a variable length array of custom field key/value pairs
• returns a list of post IDs which you can loop through
• Could be implemented into your site in one of 3 ways: Added to a functions.php file as a part of your theme, included in a plugin related to enhanced custom field functionality or report a (feature request) bug for a more evolved version of it be included in a future release of the core of WordPress.

The demonstration code below has been prepared for the most common scenario as part of a functions.php file in a theme.

The Demonstration

A series of tables with columns for number of seats available, departure / return dates plus contact / additional info. I have kept the code below intentionally short so the example doesn’t overwhelm. I have posted a more complete version on pastebin that has the markup to match the image above.

The function

function get_post_meta_multiple($metaDataList) {
	global $wpdb;
 
	$querystr = "SELECT p.* FROM $wpdb->posts AS p WHERE p.ID IN ( ";
 
	$querystr .= "SELECT post_id FROM $wpdb->postmeta WHERE ";
	$innerqry = array();
	foreach($metaDataList as $key => $value) {
		$innerqry[] = $wpdb->prepare( "(meta_key = %s AND meta_value = %s)", $key, $value );	
	}
 
	$querystr .= implode(" OR ", $innerqry);
 
	$querystr .= " GROUP BY post_id ";
	$querystr .= "HAVING count(*) = " . count($metaDataList);
 
	$querystr .= ") AND p.post_status = 'publish' ";
 
	$metaResults = $wpdb->get_results($querystr, OBJECT);					
	return $metaResults;
}

Example Usage

Place this inside your category.php or whatever template file you are using to display the results from.

<?php //Create your array of custom field key / values to filter to
	$metaDataList = array(
	'rideshare_event'	=> 'Ottawa Blues Fest',
	'rideshare_type'	=> 'Driver'); 
 
	$resultList = get_post_meta_multiple($metaDataList);
 
	if ($resultList):
	//Loop through each result post to display appropriate contents
	foreach ($resultList as $post):
		setup_postdata($post);
 
		// Define your custom field key
		$key="rideshare_spaces";
 
		// Display value of custom field		
		echo get_post_meta($post->ID, $key, true);
 
   	endforeach;
	else : ?>
		<p><?php _e('No rides are currently available for this event.'); ?></p>
	<?php endif; ?>

The future of the function?

Once I have finished the prototype site that started this concept, I will attempt to package up the pieces in a more manageable method to share for wider use. In the interim, feel free to use and share in whatever ways are most convenience for you. Much like WordPress as a whole, I think this idea can continue to evolve in some great ways that will make it easier for designers, developers and clients to build / use sites based on it. Please link back to this post as you do so that I can keep tabs on how this idea evolves.

Learn to love get_post_meta

The get_post_meta function is a function you will come to know and love when working with custom fields in WordPress. It is used within the loop to present the value based on the name of the custom field.

<?php $key="rideshare_name";
echo get_post_meta($post->ID, $key, true);
?>

Beyond the basics

If you are doing more than just basic data storage / display with custom fields, the following links / examples will be of interest to you:

• Web Designer Notebook covers how to display multiple values for the same custom field name. This might be useful to display a list of ingredients for a recipe site or the parts needed for a set of DIY instructions.
• Tutorial9 has a great tutorial on the many different ways to use custom fields for storing images to represent a post. After uploading the photo, you store the filename of a full-size or thumbnail photo in a custom field and use get_post_meta to extract / display in the appropriate theme file locations.
• Cagintranet has 3 custom field tricks that operate per post: custom read more tags, thumbnails of related posts and post-specific css overrides.
• LiveXP shows how to get custom fields outside the loop. If creating a theme options page is beyond your skill, you can create a private page and store / retrieve the meta values from custom fields attached to that page wherever you need to.
• Two Words: More Fields. This plugin enables you to create custom write panels with custom field data types (radio buttons, drop-down, textbox, wysiwyg, etc). My most recent screencast gives a good overview of using More Fields to design a store location list using the plugin.
• Sidetrack Suggestion: I can easily see (and hope that) the type of functionality More Fields has explored gets built into the core as a part of the post-types being considered for 3.0. With the drag-drop interface of the widgets management area applied to the design of write panels, this would be a fantastic feature of a future version of WordPress.
• Justin Tadlock has written immensely on the power of custom fields. If you want a crash course in custom fields, his site is a great place to start.
• Smashing Magazine shows how to get posts with a specific custom field and specific value as one of their 10 useful WordPress Loop hacks. This is invaluable when capturing data that you want to filter for in query loops.

What actually inspired me to write this post was my recent efforts to build an elegant solution to a query quandry I was having related to custom fields – How to filter / query for multiple custom field key / values? The solution is one that could be of interest to theme / framework designers, plugin developers or possibly even the base concept for implementation into the core of advanced custom field functions WordPress.

If you have any other great custom field tutorials, please share them in the comments of this post.

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; ?>