Monday By Noon » Workbench

WordPress Custom Post Types & PHPurchase: Best Cart Ever – Part 2

Jonathan Christopher — Mon, 09 Aug 2010 05:28:09 +0000

If you haven’t read part 1 I took some time to outline why I feel that the combination of PHPurchase and Custom Post Types can result in the best e-commerce solution for WordPress.

In part 1 I examined the current WordPress cart plugin landscape and outlined a number of reasons I feel that PHPurchase is currently the leading solution for an e-commerce solution, especially with the arrival of Custom Post Types. I’d like to share how and why using Custom Post Types works so well for a WordPress shopping cart.

Setting up and prepping WordPress

The first step will be to get your WordPress 3.0+ install up and running. That’s the extent of detail we’ll cover there. The next step will be to obtain and install a copy of PHPurchase. There are a number of purchase options available, but this walkthrough will cover functionality available under all licenses of PHPurchase.

The installation of PHPurchase is as straightforward as any other plugin. Once you’ve uploaded the plugin files and activated the plugin, you’ll need to enter your PHPurchase order number on the Settings screen:

After validating your order number, the reminder to do so will disappear and you’ll be able to enter in your PayPal, Authorize.net, or Quantum Gateway payment settings. These details aren’t required at this point, but until that information is entered, the plugin won’t let you check out. For now, those are the only details we’ll cover as far as setup is concerned. Using the PHPurchase menu in the WordPress admin, you can begin adding products.

As it stands PHPurchase will automatically implement a number of system Pages it will use to handle the cart view and checkout process for purchases.

While these pages are an extremely important part of the overall e-commerce implementation, none of the products we just added are made available out of the box.

By editing the Store page, you can quickly add a number of products using the PHPurchase icon in the editor toolbar:

At this point, you can feel to proceed as normal. Using this Store page you could add every product you have available as well as apply some style and content using imagery, product copy, and links to relevant information. You could take it a step further and also create child pages with the Store as the parent and dedicate a product detail page to each of your products.

While helpful, you’ll quickly discover missing features that are very commonly found in other e-commerce platforms. Features such as browsing products by category and providing additional information about products in the form of multiple product shots and/or PDF downloads aren’t directly built into PHPurchase. The beauty lies in the fact that you can customize WordPress in all the usual ways to add these features as you see fit.

With the arrival of WordPress 3.0, however, there is an entire layer of additional functionality found in Custom Post Types that makes working with these features a breeze.

Using Custom Post Types for your PHPurchase Store

Custom Post Types are sometimes intimidating to more novice developers. Out of the box in WordPress 3.0 you need to manually register and set up your Custom Post Types. As with many developer-heavy tasks at hand, there is a plugin to make life easier when it comes to Custom Post Types; Custom Post Type UI.

Custom Post Type UI gives WordPress admins the ability to create, edit, and manage all of the Custom Post Types available within the WordPress Install:

Using the plugin you can easily create a Custom Post Type to handle all of your product pages in PHPurchase. You’re able to customize the phrasing used throughout and viewing the Advanced Label Options gives you even more to work with. On top of these Custom Post Type Settings, you can also set up custom taxonomies which can be used in this specific case for a set of categories limited to your store products and separate from your Post categories.

Once you’ve created your Custom Post Type, a new menu item will be made available in the main navigation:

Using the links available you can go ahead and set up your categories as well as add your products.

Once your products have been added to your Custom Post Type, you can view the page on the front end:

Integrating Custom Post Types into your Menu

Now that your products have been added, you’ll want to make browsing your products as easy as possible. There are a number of things you can do, the primary two being including links to your product pages within your site navigation and using your Custom Post Type taxonomy (product categories).

Menus were also a big addition to WordPress in 3.0 and the update comes in handy at this point in our PHPurchase setup. The Menus are smart enough to recognize your Product Pages and allow you to integrate them directly within your site navigation:

Using the Menus you’re able to mix and match your Product Pages, your Product Categories, as well as your WordPress Pages themselves. You can custom build any structure you wish using the menus and the available entries. By default, linking to a Product Category will direct readers to pages resembling those of your other category pages, likely using category.php from your theme. You can customize this to any degree as you would normally when developing your custom WordPress theme.

Integration with plugins

Another significant advantage to using Custom Post Types and PHPurchase to power your WordPress based e-commerce website is the direct integration with many of your favorite plugins. One of the downfalls to a number of other WordPress store plugins is a lack of attention to search engine optimization. When working with product pages powered by Custom Post Types you can continue to use the SEO plugin working to optimize the rest of your website.

Additionally, you’ll be able to use plugins that enhance your ability to make additional product assets available to readers. Plugins like Attachments will let you add multiple product images for use in a product image viewer, PDFs including additional product details, as well as any available product details that may exist.

This is just the beginning

These are just the basics of getting up and running with WordPress 3.0+, Custom Post Types, and PHPurchase in an effort to get the best possible e-commerce shop up and running quickly and easily. While it’s a bit more work to get a large volume of products added and available on your website, I really feel that PHPurchase is a great choice when considering available e-commerce solutions for WordPress.

Upgrading Pods to use TinyMCE instead of NicEdit

Jonathan Christopher — Tue, 30 Mar 2010 20:24:12 +0000

I’ve had my share of troubles with WYSIWYG editors. I’ve had even more trouble with NicEdit. Due to a nasty little bug in WordPress, Pods hasn’t been able to use TinyMCE as WordPress itself does.

NicEdit was frustrating clients left and right, but TinyMCE wasn’t. Some time ago I wrote a plugin that is in dire need of an upgrade called Post Notes that appended any number of WYSIWYG editors for any Post or Page and let you reference them as you wished. I was hoping I could use the same passive method of including TinyMCE in Pods that I had used for Post Notes.

WordPress has come along nicely since I first wrote that plugin, and I’m happy to say that I’ve come up with a working solution to upgrading your NicEdit WYSIWYG columns in Pods to use TinyMCE by adding an Input Helper. Here she is:

TinyMCE for Paragraph Text

Input Helper explained

As a really brief walkthrough what the Input Helper does is modify the markup used to dump out the base textarea that holds our actual data. That’s the standard part. The exiting bit is contained in the conditional at the top of the Helper. The conditional basically checks to make sure that it’s not executed repeatedly for each Paragraph Text column used.

When the time is right the helper will fire wp_tiny_mce() which is a nearly undocumented WordPress function that resembles wp_enqueue_script() on steroids. It will pull in all the necessary scripts for TinyMCE as well as properly initialize them.

The first parameter dictates the TinyMCE theme to use. If set to true the full (advanced) theme will be used, setting it to false results in a stripped down (simple) theme which I prefer to use in this case. The array passed as the second parameter tells wp_tiny_mce() which class to hook, you do not need to edit it. The Package available for download includes both a simple and an advanced TinyMCE Input Helper.

The JavaScript segment of this helper actually hijacks Pods’ saveForm() function call as we need to force TinyMCE to fire triggerSave() which forces the TinyMCE content to be applied to our original textarea which is super important.

Installation

You can snag the TinyMCE Upgrade Input Helper Package from the Pods website. Once downloaded, go ahead and log into the WordPress admin and hit the Package Manager link under the Pods heading:

Then you can hit the Import tab since we’re not Exporting anything:

Just paste the Helper in the provided text box and click Proceed to Confirmation

After Pods validates the Helper you can go ahead and Finalize:

Pods will let you know it’s All done! Your Input Helper is ready to go. Now you can browse to the Paragraph Text Column you’d like to edit which used to look like this:

and update the Input Helper field for the applicable column by first clicking the Edit icon next to your column and then defining the Input Helper by choosing tinymce from the select. Be sure to click Save to ensure the Input Helper is properly defined:

When you go back to edit your Pod, you’ll see a brandy new instance of TinyMCE instead of NicEdit:

Please make sure you’re running the latest versions of both Pods and Pods UI before working with this Input Helper.

Known Issues

I’m currently trying to work with Scott Kingsley Clark on a few details but there may be some problems with using this Input Helper along with a publicForm. Please avoid using this Input Helper on any Pod you plan on using in conjunction with publicForm until it can be better tested. More info coming as soon as possible!

Update: As of March 31, 2010 I can confirm that there is a problem with the Helper if your Pod has not been made Top Level and you’re not using Pods UI for the Pod. If at all possible, making it either Top Level or using Pods UI should achieve the desired results. We’ll keep working away at a fix ASAP!

Update: Version 1.0.2 forces each editor instance to be of a certain height and also disables the resize handle due to it acting up in certain circumstances.

Using Input Helpers in Pods CMS for WordPress

Jonathan Christopher — Mon, 22 Mar 2010 13:36:40 +0000

Pods CMS really aims to be a framework in the sense that you can do anything you want with it. The approach of the developers always seems to keep that in mind, which is sometimes the most difficult thing to do when writing software.

I’d like to review Input Helpers a bit. Out of the box, Pods offers a number of column types including date field, number, boolean, paragraph text, and more. We also can’t forget about one of the more unique column types offered; Pick columns.

Applying Input Helpers to Pick columns

On a recent project (like many projects) I found myself using a Pick column set to WP Page that automagically pulls a list of all WordPress Pages when the Pod entry form is displayed.

The goal with this Pod was to allow the client to dynamically define a background image for their website on a per-page basis. Out of the box, the solution worked as expected:

There was a problem though. I didn’t want the client to have full control over each and every page of the site. There were a number of pages on which it wouldn’t make sense to have a custom background. This is one of the many cases where Input Helpers come to the rescue.

The basics of Input Helpers

Input Helpers were designed to do one thing:

An Input Helper lets you completely customize the appearance of any input field.

What this means is we’re given the opportunity to both hook and manipulate the data pulled to an input field before it is displayed on screen. Input Helpers are applied on a per-column basis (as opposed to a Pod as a whole). The possibilities here are literally endless. If you have a requirement for the options available in an input field, Input Helpers are where you’d start.

As mentioned in the Codex, Input Helpers have a number of variables available to use. Each variable is well explained in the Codex, and depending on the column type, you can use and interact with each of these variables at your will in an effort to obtain your desired result.

Input Helpers are created using the Helpers tab in the admin panel. When naming your Input Helper, ensure the title is comprised of all lowercase (non-special) characters, no dashes, and no spaces. Also be sure to define the helper as Input.

After the Helper is created, you’re provided with a code editor. Here’s where the magic happens. Using this editor, you can manipulate your data using a combination of straight PHP and the variables outlined in the Codex.

After you’re done writing the PHP needed to manipulate the values available in your input column, the last step is to actually apply the Helper to your Input:

Note: due to AJAX, you’ll need to refresh the page before attempting to apply your Input Helper.

Limiting WordPress Pages with an Input Helper

Circling back to our single use case, we’ll go ahead and write a quick and dirty Input Helper that’s going to limit our WP Page Pick column to only a select few Pages I want to make available to my client. Writing an Input Helper might require a bit of initial legwork in inspecting the default markup used for the existing (out of the box) data available. In this example we’re working a multiple Pick, so the markup is as follows:


  
    Page(s)
    *
  


  
    About
    ...
    Team

The snippet has been truncated, but we can see how the Pick column is structured. We simply need to recreate that markup as we filter through the data supplied to the field:



  
     $val) : ?>

What we’re doing with this Helper is first defining $applicable_pages which contains an array of the Page ids we’re permitting to show up for use. We then loop through $value (provided by Pods as per the Codex) and check to see if the current Page id is in our array. If it is, we’ll go ahead and make it available, else we move on to the next. What results is our refined list of available WordPress pages:

A word of warning with this implementation: it’s tied to a single WordPress install. Additionally, problems will come up should the site be migrated to a new WordPress installation without a complete database export/import. WordPress Page ids are not retained using WordPress’ import/export features. Keep that in mind as you write your Helpers.

Input Helpers raise the bar

Input Helpers open a ton of new doors when it comes to Pods. We’ve just scratched the surface with the example above, and as with pretty much anything “Pods” the possibilities are endless.

Another great resource you’ll want to bookmark is the Packages section of the Pods CMS website. You can find a ton of available Helpers that have been made available by the community, some of which may come in handy straight away. The section isn’t limited to Helpers, but you can easily peruse the titles and poke around when you’ve got a minute.

Building a Store Locator with WordPress and Pods

Jonathan Christopher — Mon, 22 Feb 2010 16:43:08 +0000

Truth be told I was always a bit intimidated by proximity searches. That is to say the “Find X within Y miles” implementations we see everywhere. There was always a bit of magic behind how that worked and I’ve had a long time itch to figure out exactly how it worked.

Luckily enough, a client need came through which included such a feature. What better time to teach yourself something? Other programmers at my company had implemented proximity searches in the past, but I wasn’t involved on the projects and didn’t want to simply peruse their code and see what I could pull from it. I sat down with one of the guys as I began working on the feature to discuss past implementations. There were two ways to go about it:

Piggyback on Google Maps
Do things the hard way

It took me about zero seconds to determine that I wanted to do things the hard way. It’s not that I don’t enjoy working with Google Maps. Quite the contrary in fact. I just don’t want to depend on it too much in the day to day, especially for something as generic as a proximity search. Additionally, it just adds another layer of complexity with remote calls, API limits, and the other issues associated with using any other third party service. Hard way it is.

Pods setup

The first thing we’ll do is create a ‘stores’ Pod. If you’re not familiar with creating Pods, take a few minutes to read the beginner series, starting with Pods Basics: Installation and Setup. I’m going to use the following columns:

name (txt)
slug (slug)
address (txt)
city (txt)
state (PICK state)
zipcode (txt)

We’re also going to simply make this Pod a Top Level Menu. If you’re looking to make things even nicer, go ahead and include Pods UI where applicable.

I’ve made every column required data, as an address isn’t very useful without complete information. I segmented the addresses as such simply because the proximity search I’ll be implementing is based on ZIP code, and having that data in a separate column will help with server load. Lastly, I chose to use a txt column for the zipcode instead of a Number because many ZIP codes begin with one (or more) zeros, which would cause a bit of trouble.

As a last step, we’ll go ahead and add a few test store listings using various ZIP codes you’re familiar with. The more variance the better, as you’ll be able to see whether the proximity aspect of the search is working properly or not.

Once you’ve added a few samples, it’s time to integrate.

WordPress setup

For the sake of brevity, this location based search will sit on its own WordPress Page, using a template we’ll put together. We’ll continue working with the WordPress default theme, and add a new template; store-locator.php which includes the following:



  

    
    
    
      

        

        

          
            Your ZIP
            
          

          
            Within (miles)

Nothing exciting happening here, we’re simply setting the stage with the basic form we’ll use to search our store directory by location.

Now that we’ve got our Page using our template, we’ll implement the location search functionality via Pods.

Setting up the location search

Our first step will be to add a conditional that checks to see if the form has been submitted. In this case, I’ll simply add a hidden input to track the current action:

With this action in place, we can include our conditional:


  List our results

Here’s where everything happens. Once we find ourselves in the conditional, we’ll need to do a bit of work:

Sanitize our data
Retrieve search results
Display data

Our conditional will expand to be:



     0 ) : ?>
      Search Results
      
        
          
          
            Name

            Address

            Distance
 miles

You’ll notice that there’s no reference to Pods anywhere in that conditional, but there is a new function to take a look at; mbn_get_stores_by_location().

Implementing the proximity aspect

This new function, mbn_get_stores_by_location(), will take care of all the work including:

Determine the latitude and longitude of the source ZIP code
Use triginomitry to determine which additional ZIP codes fall within the chosen radius
Retrieve all Pods entries matching the pool of ZIP codes
Return an array of results, ordered by distance

The quickest and easiest way to implement the function will be adding it to functions.php in your theme. Before we implement the function, however, you’ll need to add a new table to your database. This table is going to include a listing of all US-based ZIP codes and acts as an integral piece for this function. The table is used to determine the latitude and longitude of applicable ZIP codes, and is used with each search submission. There are a number of places to obtain a ZIP code database, the one I’ve used in the past is made available for free from PopularData.com. It’s made available as a CSV file weighing in at about 700k. There is a donation button available on the download page, and I’d suggest showing your appreciation to the provider should you use the database for any commercial work.

You’ll need to set up a new table in your WordPress database and be sure to name it something unique. You’ll need to remember both the table name and column names as you implement the location search. Once you’ve added the table and verified its integrity, we can go ahead and implement mbn_get_stores_by_location() in functions.php:

get_row( $sql );

  // now we'll get the other ZIP codes within the radius, ordered by distance
  $sql = "SELECT mbn_zip_codes.zipcode, ( 3959 * acos( cos( radians( $coords->latitude ) ) * cos( radians( mbn_zip_codes.latitude ) ) * cos( radians( mbn_zip_codes.longitude ) - radians( $coords->longitude ) ) + sin( radians( $coords->latitude ) ) * sin( radians( mbn_zip_codes.latitude ) ) ) )  AS distance FROM mbn_zip_codes HAVING distance <= $radius OR distance IS NULL ORDER BY distance";

  $nearby_zips = $wpdb->get_results( $sql );

  // we need to store the zips in order to build the Pods query
  $target_zips = array();
  foreach ($nearby_zips as $nearby_zip)
  {
    array_push($target_zips, $nearby_zip->zipcode);
  }

  // we're going to store the results as we go
  $store_results = array();

  if( count( $target_zips > 0 ) )
  {
    $final_target_zips = implode(',', $target_zips);

    if( strlen( $final_target_zips > 0 ) )
    {
      // let's snag the data
      $stores = new Pod('stores');
      $stores->findRecords('id ASC', 9, 't.zipcode IN (' . $final_target_zips . ')');

      $store_data = array();

      while ( $stores->fetchRecord() )
      {
        $store_data['id']       = $stores->get_field('id');
        $store_data['name']     = $stores->get_field('name');
        $store_data['slug']     = $stores->get_field('slug');
        $store_data['address']  = $stores->get_field('address');
        $store_data['city']     = $stores->get_field('city');
        $store_data['state']    = $stores->get_field('state');
        $store_data['zipcode']  = $stores->get_field('zipcode');

        foreach ($nearby_zips as $nearby_zip)
        {
          if( $store_data['zipcode'] == $nearby_zip->zipcode )
          {
            $store_data['distance'] = intval( $nearby_zip->distance );
          }
        }

        array_push( $store_results, $store_data );
        unset( $store_data );
      }

      usort( $store_results, "mbn_cmp" );
    }

  }
    return $store_results;
}

?>

Quite a bit is going on in this function. Once our globals are set and our data sanitized, we’re going to query the new table we set up to retrieve the coordinates of the submitted ZIP code. Once we have those coordinates, we’re going to perform a lengthy query on that same table to determine what other ZIP codes fall within the submitted radius:

SELECT mbn_zip_codes.zipcode, ( 3959 * acos( cos( radians( $coords->latitude ) ) * cos( radians( mbn_zip_codes.latitude ) ) * cos( radians( mbn_zip_codes.longitude ) - radians( $coords->longitude ) ) + sin( radians( $coords->latitude ) ) * sin( radians( mbn_zip_codes.latitude ) ) ) )  AS distance FROM mbn_zip_codes HAVING distance <= $radius OR distance IS NULL ORDER BY distance

You will need to be sure that table and column names are appropriately updated. There are a number of formulas which use trigonometry to solve proximity equations, but I’ve found the above to suit my needs well in this application.

Once we’ve got our nearby ZIP codes ordered by date, we query our Pod for any entries with ZIP codes that match our results. Instead of using get_field() to echo the display directly, we’ll instead use it to store the data in an array consisting of all returned results.

Once we’ve processed the results, our last step will be to use usort to ensure our results are actually sorted by distance:

usort( $store_results, "mbn_cmp" );

usort uses a custom function to determine the comparison result, and we’ll need to add that to functions.php as well:

function mbn_cmp($a, $b)
{
  $a = intval( $a['distance'] );
  $b = intval( $b['distance'] );
  if( $a < $b )
  {
    return -1;
  }
  elseif( $a > $b )
  {
    return 1;
  }
  else
  {
    return 0;
  }
}

Note that the comparison function uses a specific array key to generate a result. If you change the distance key, you’ll need to update this function as well.

That takes all the magic out of it. If we return to our submission form and search for a ZIP code that is known to produce results, we’ll see the functionality at work:

I realize the explanation is a bit lengthy, but I hope it helps to explain how a proximity search can work on a smaller scale.

Alternative implementations

As I researched location based proximity searches, I found a number of alternative solutions using PHP and MySQL. Some of which included stored procedures, and other advanced uses of MySQL. I’m nearly positive other implementations would require less computing power and run a bit faster, but I chose not to take that path because I wanted to keep the functionality as lightweight and portable as possible.

The queries used in the search function are performing quite a bit of math, and probably won’t scale extremely well. If you’re only looking to implement a location search on a smaller set of data (under 10,000 or so) I think using something like this will work for you as well.

Other uses

With Pods making a location based ZIP code search so easy, I’m hoping to implement it on more client projects since it won’t affect the budget very much. Some initial use cases that come to mind are:

Member directory searches
Service area searches
Geographic zone searches
Event listings

The next step I’d take with an implementation such as this would be to remove the requirement of entering your ZIP code manually altogether and instead use geolocation to automatically generate a starting point for the visitor.

The Last of the Pods Basics: Pagination and Sorting

Jonathan Christopher — Mon, 25 Jan 2010 14:57:57 +0000

The Series on Pods has been quite a success so far. I’ve had some back and forth with lots of new people who were itching to give Pods a try, and the series has been quite a bit of help to newcomers. I’m super happy about that, and I’d like to close out the initial push on the series with what I’ll call The Last of the Pods Basics. That is to say, I’d like to go over the last few bits that will really get you up and running with Pods in such a way that you can do even more with both your data as well as your user experience.

As a quick recap, if you haven’t read the first five articles in The Series, you will probably find this article a bit confusing. That said, please make sure you’ve read: An Overview of and Introduction to Pods CMS for WordPress, Pods Basics: Installation and Setup, Pods Basics: Pulling Pods Data to your Theme, Pods UI: The Latest and Greatest Addition to Pods, and How to use Pick Columns (Relationships) in Pods. Being up to speed is essential with this article, as it’s going to build on the system we’ve put in place using the previously published articles. You won’t need to recreate the structure set up in the earlier walk throughs, but knowing the existing implementation will help these instructions remain clear.

Paginated content in Pods

Pods comes with pagination built right in, it’s just a matter of getting it to work the way you want. We’ll begin by flooding the Team Pod we set up previously with a large group of entries. In addition to the Pod setup, I also added Pods UI to help manage the content.

If we were to check out our Team page now, we’d see that the listing has been limited to the default 15 records:

Also by default, Pods doesn’t include any sort of warning that content wasn’t listed. It shouldn’t do that, because Pods does what you tell it to do. You have a few options here. The first would be to change the way we pull the original data. As it stands, we’re using:

findRecords('name ASC');
?>

As it turns out, findRecords has more parameters to work with, one of which is the LIMIT we want to use. You can change the default of 15 by defining the $rows_per_page parameter:

findRecords('name ASC', 20);
?>

If we were to make that change, we’d see all 16 records we have entered, but would also have the same problem once we breached the new limit of 20. A better solution is to include pagination. We’ll revert back to the default limit of 15, and include our pagination links below the Team listing. It’s even easier than it sounds. After you’ve defined your Pod, you can fire the following anywhere:

getPagination(); ?>

getPagnination() basically takes care of everything, and will include the pagination controls where echo‘d:

Here’s the best part, that’s all you’ve got to do. Clicking the second page appends a couple of $_GET variables, reloads the page, and shows you all of your new data. You’re done. There are a few more details concerning getPagination() which will be covered in a subsequent article.

Sorting Pods entries

I’m really excited that the Pods developers are taking so much care with Pods UI. Beyond the inherent user experience improvements it makes, they’re adding features that you can’t even find in WordPress yet. One of my most welcomed additions as of late with Pods UI is the inclusion of drag and drop sorting of Pods entries. Before the functionality was implemented, you had to make a number column in your Pod, and instruct users to use that field to manually order the Pods entries. It was a replication of the limited functionality WordPress offers with Pages. The Pods developers did one better and included such functionality in Pods UI. As with every other aspect of Pods, it’s super easy to integrate, we’ll walk through it quickly.

The first step carries over from the old way of doing things, you’ll need to add a number column to your Pod. We’ll continue working with our Team Pod:

Once the column is added, we’re going to need to modify our theme template to ORDER BY that column as opposed to the name column it’s currently using:

findRecords('displayorder ASC');
  $total_members = $team->getTotalRows();
?>

Easy enough. You could actually leave things as is, and your user could manually edit each of the displayorder columns for each Pod entry, but Pods UI makes that so much easier. We’ll need to modify our custom UI plugin and include a few choice flags that will tell Pods UI the details it needs to enable drag and drop sorting. Our revised plugin is as follows:

ui = array(
        'title'   => 'Team',
        'reorder' => 'displayorder',
        'reorder_columns' => array(
             'name'      => 'Name',
             'position'  => 'Position'),
        'columns' => array(
             'name'      => 'Name',
             'position'  => 'Position',
             'created'   => 'Date Created',
             'modified'  => 'Last Modified'
             ),
        'add_fields'  => $add_fields,
        'edit_fields' => $edit_fields
		);
  pods_ui_manage($object);
}

add_action('admin_menu','pods_ui_team');

?>

While it looks very similar to the Pods UI plugin we developed earlier, you’ll want to note the subtle difference:

'reorder' => 'displayorder',
'reorder_columns' => array(
     'name'      => 'Name',
     'position'  => 'Position'),

These new entries are very important, as they enable the sorting itself, as well as tell Pods which column to use when applying the new sort order. When you break it down it’s quite simple. You define reorder with the number column you set up and would like to use to control the sort order, and reorder_columns are the table columns that appear on the reorder page in the WordPress admin. After modifying your plugin with the following, a new element will be included on the listing page:

Clicking that button will reload the page and bring the user to a page dedicated to managing the order of the Pods entries:

Beautiful! Our user can drag and drop to reorder their entries on the fly, click Update Order at the bottom, and everything is taken care of for us.

Pods never disappoints

I hope that these last couple basic features give you enough information to really get started working with Pods. The developers have really put a lot of time, effort, love, and thought into the implementation and I can’t thank them enough. If you’ve found yourself embracing Pods, please take a moment and donate to the project as I know for a fact they’re working night and day to make Pods that much better with every release.

The Pods CMS Series on MBN

This article is the sixth in a series for Monday By Noon dedicated to Pods CMS.

How to use Pick Columns (Relationships) in Pods

Jonathan Christopher — Mon, 11 Jan 2010 14:57:44 +0000

In this edition of the Pods CMS Series, we’re going to cover Pick Columns. If you haven’t read the first articles in the series, I would highly recommend it as this article assumes basic knowledge of the workings of Pods. Please make sure you’ve read Pods Basics: Installation and Setup, Pods Basics: Pulling Pods Data to your Theme, and Pods UI: The Latest and Greatest Addition to Pods before continuing.

As defined by the Pods developers:

A relationship column is essentially a select list containing items from the related type. If you create a column in one pod that relates to another pod, “event”, then in the edit form you’ll see a select list with all “event” items.

This is really great for us, because it means that any Pod can effectively make use of another Pod or WordPress resource such as a Page. It opens the doors to quite a few things that were more difficult to achieve using a combination of standalone WordPress plugins.

When would you want to use relationships?

When it comes to learning, I always find it better to explore by example. If a technology is applied to a real-life situation (or something very close to that) I find it much easier to fully understand.

Perhaps the most basic use of a Pick column would be to make a link between a Pod entry and a WordPress Page. One example of a situation in which this makes sense is a promotional area. Using Pods, you could set up an area to manage any number of promotions, and have them link directly to a specific WordPress Page.

How to implement a Pick Column

We’ll continue with our Promotions example and create a quick Pod to handle the data. We’ll set it up like this:

With our Promotions Pod set up, let’s add a sample entry to see how the Pick column works:

It’s as easy as that! Pods will automatically pull the active list of WordPress pages, so you don’t have to worry about anything being out of date or inaccurate when it comes to pulling the needed permalink on the front end. Once we’ve saved the Pod entry, let’s go ahead and integrate it into our sidebar. For the demo, I’m just going to work within the default WordPress theme. In sidebar.php:

findRecords(null, 1);
  $total_promos = $promos->getTotalRows();
?>

 0 ) : ?>

  fetchRecord() ) : ?>

    get_field('name');
      $promo_copy = $promos->get_field('copy');
      $promo_link = $promos->get_field('link');

      $promo_link = get_permalink($promo_link[0]['ID']);
    ?>

    
      
      
      Find out more!

What we’re doing here is first pulling our Pod data. If a record is found, we’re going to process it. Everything is standard practice until it comes to our Pick column. Since we chose the relationship to be a WordPress page, Pods is going to give us an array with which to work. What’s great is that the array consists of variables we’re already familiar with by working with WordPress pages. We’re provided the entire set of data we expect:

Array
(
    [0] => Array
        (
            [ID] => 29
            [post_author] => 1
            [post_date] => 2010-01-01 00:00:00
            [post_date_gmt] => 2010-01-01 00:00:00
            [post_content] =>
            [post_title] => Package 3
            [post_excerpt] =>
            [post_status] => publish
            [comment_status] => open
            [ping_status] => open
            [post_password] =>
            [post_name] => package-3
            [to_ping] =>
            [pinged] =>
            [post_modified] => 2010-01-01 00:00:00
            [post_modified_gmt] => 2010-01-01 00:00:00
            [post_content_filtered] =>
            [post_parent] => 23
            [guid] => http://localhost/wp/?page_id=29
            [menu_order] => 0
            [post_type] => page
            [post_mime_type] =>
            [comment_count] => 0
        )

)

Nice, right? Using that data we can completely integrate the Promotion copy to include a link directly to the page selected in the Pick column. Done, and done:

By all means, that’s the most basic way to implement the promotion, you can provide additional fields that allow the user to define the promo link text and more.

Creating relationships with other Pods

Being able to make a connection with a WordPress Page is awesome, you can also establish these relationships with WordPress Posts, WordPress Users, and even WordPress Categories. Pods also lets you link your Pods to one another. Let’s continue with our Promotion example.

Perhaps the website you’re building out has a lot of promotions. So many that you’d like to randomly pull a promotion from a group of promotions at any given time. With Pick columns we can make that happen. The first thing we’ll do is set up a Promotion Categories Pod. All we need is the most basic structure to work with:

Then we’ll add a couple categories, one of which can be Winter Specials:

Once our categories are added, we’ll need to add another Pick column to our original Promotions Pod:

The last step on the setup side of things will be to add a few promos and categorize them:

Once we have our new categorized library of promotions, we can go ahead and revise our sidebar to include only those categorized as being for the winter. To do so, we’re going to use a specific SQL syntax provided by Pods:

findRecords('rand()', 1, 'category.name = "Winter Specials"');
  $total_promos = $promos->getTotalRows();
?>

 0 ) : ?>

  fetchRecord() ) : ?>

    get_field('name');
      $promo_copy = $promos->get_field('copy');
      $promo_link = $promos->get_field('link');

      $promo_link = get_permalink($promo_link[0]['ID']);
    ?>

    
      
      
      Find out more!

The change to notice here is the WHERE bit we’ve added to the findRecords() function call. That statement restricts the results to have a chosen category of Winter Specials in our Pick column. Tied in with the ORDER BY rand() snippet, we have a rotating, random, categorized set of promotions from which to pull.

Again, this is just a most basic implementation of relating one Pod to another, but it really opens up the door for lots of options when it comes to content management!

Integration with Pods UI

When writing Pods UI: The Latest and Greatest Addition to Pods I did my best to convey how helpful Pods UI is when it comes to presenting Pods to actual users. Your Pods are presented in such a way that the user recognizes the structure you’ve set up even quicker than before, and you’re able to better organize that presentation. Pick columns raise that bar even higher.

Before Pods UI, it was a bit cumbersome to explain how one Pod was related to another when Pick columns were involved. Now, with Pods UI, you can group related Pods into the same section in the navigation, providing a visual link between the two (or more) for the user. Circling back to our promotions example, we can now group the Promotions Pod itself alongside the Promotion Categories for easy maintenance:

To get this listing, simply install Pods UI, and create your own separate plugin file:

ui = array(
                    'title'   => 'Promotion',
                    'columns' => array(
                              'name'      => 'Name',
                              'category'  => 'Category',
                              'created'   => 'Date Created',
                              'modified'  => 'Last Modified'
                              ),
                    'add_fields'  => $add_fields,
                    'edit_fields' => $edit_fields
					);
  pods_ui_manage($object);
}

function categories_page()
{
  $object = new Pod('promotion_category');
  $add_fields = $edit_fields = array(
                    'name',
                    'slug');
  $object->ui = array(
                    'title'   => 'Category',
                    'columns' => array(
                              'name'      => 'Name',
                              'created'   => 'Date Created',
                              'modified'  => 'Last Modified'
                              ),
                    'add_fields'  => $add_fields,
                    'edit_fields' => $edit_fields
					);
  pods_ui_manage($object);
}

add_action('admin_menu','pods_ui_promos');

?>

Again, grouping related Pods can help exponentially when it comes to showing this new system to actual users. It reduces the learning curve quite a bit, and really helps people hit the ground running.

This is just the beginning when it comes to Pick columns, in future articles I’ll cover the more advanced attributes of this feature, but understanding these fundamentals will help you get started.

The Pods CMS Series on MBN

This article is the fifth in a series for Monday By Noon dedicated to Pods CMS.

Pods UI: The Latest and Greatest Addition to Pods

Jonathan Christopher — Mon, 04 Jan 2010 07:13:33 +0000

Pods makes it super easy to give your clients the upmost control when managing their content. You can custom tailor WordPress not only to power their blog and standard content-heavy Pages, you can give them a Pods installation that helps to manage that one-off group of data that will really help their website completely reflect their business or organization.

If you haven’t followed the first three articles in the Pods CMS Series, I would recommend starting at the beginning with An Overview of and Introduction to Pods CMS for WordPress so you’re familiar with the setup we’re working with up to this point.

Incorporating Pods UI

Pods UI is the latest feature to become available for Pods. It’s the first add-on, and I’m already in love. If you’ve been keeping up with the Pods CMS Series, we discussed the ability to mark a certain Pod as a Top Level Menu in Pods Basics: Installation and Setup. It was a great way to give a particular Pod a bit more attention by including it as its own entry in the WordPress admin navigation.

If you really take Pods under your wing and end up creating numerous Pods to power various sections of a website, and they all carry a certain bit of importance, the main WordPress admin navigation can get quite busy really quick. Pods UI helps tackle that issue directly.

Before adding Pods UI, we can go ahead and remove Team as a Top Level Menu. Just uncheck the box and click Save settings:

Now we’ll go ahead and install the Pods UI plugin, and create our own plugin file that will interact with Pods UI:

ui = array(
                    'title'   => 'Team Member',
                    'columns' => array(
                              'name'      => 'Name',
                              'position'  => 'Job Title',
                              'created'   => 'Date Created',
                              'modified'  => 'Last Modified'
                              ),
                    'add_fields'  => $add_fields,
                    'edit_fields' => $edit_fields
					);
  pods_ui_manage($object);
}

add_action('admin_menu','pods_ui_team');

?>

Note: I’d suggest creating an additional plugin file outside the pods-ui folder you just uploaded when installing Pods UI, else WordPress will think your plugin file is out of date based on the version number.

There is a lot of custom setup going on, all of which is covered in extreme detail in the Pods UI download, but I’ll cover the basics explaining what we’ve set up.

At first glance, this is just a simple WordPress plugin, and it is, we’re simply interacting with the Pods UI plugin as well. The first function that fires here is:

add_action('admin_menu','pods_ui_team');

We’re hooking admin_menu and firing pods_ui_team as a callback. pods_ui_team is defined as follows:

function pods_ui_team()
{
  $icon = '';
  add_object_page('Team', 'Team', 'read', 'team', '', $icon);
  add_submenu_page('team', 'Team', 'Team', 'read', 'team', 'team_page');
}

Pods UI allows you to define an icon file to use in the sidebar, a nice bit of customization available! From there, we fire add_object_page, a Pods UI function that sets up the menu structure and includes the icon we just defined. This creates a ‘section’ in the WordPress admin navigation sidebar. add_submenu_page then adds a submenu entry to the sidebar section we just created. The last parameter we pass when firing add_submenu_page defines the callback we’d like to fire when that menu is clicked. That’s the other function we need to define in our plugin file:

function team_page()
{
  $object = new Pod('team');
  $add_fields = $edit_fields = array(
                    'name',
                    'position',
                    'photo',
                    'bio',
                    'permalink',
                    'eom');
  $object->ui = array(
                    'title'   => 'Team Member',
                    'columns' => array(
                              'name'      => 'Name',
                              'position'  => 'Job Title',
                              'created'   => 'Date Created',
                              'modified'  => 'Last Modified'
                              ),
                    'add_fields'  => $add_fields,
                    'edit_fields' => $edit_fields
					);
  pods_ui_manage($object);
}

In this function, we define a series of variables. We first define our $object as the Pod with which we’d like to link this UI element. We then define $add_fields as an array of columns we’d like to include on the ‘add’ screen. We can include or omit any existing columns we’d like. In this case, we’ve added all available columns. Next, we define object->ui which actually builds the ‘browse’ table view listing out any existing Pods data. We can define which columns are visible (and therefore sortable) which is very useful! Finally, we fire pods_ui_manage($object); which makes all the magic happen, and we have even more useful sidebar entries for our Pods.

While not completely obvious with just a Team Pod, the real beauty of Pods UI comes when you group a selection of Pods under a generic heading. These cases are usually very client-specific, but can really make the usability of Pods that much better.

This article is meant to be the most basic introduction to Pods UI, I would absolutely suggest checking out the User Guide for further information.

The Pods CMS Series on MBN

This article is the fourth in a series for Monday By Noon dedicated to Pods CMS.

Pods Basics: Pulling Pods Data to your Theme

Jonathan Christopher — Mon, 04 Jan 2010 07:13:27 +0000

If you haven’t had a chance to read the first two articles in the series, I would definitely suggest taking a few minutes to read both An Overview of and Introduction to Pods CMS for WordPress as well as Pods Basics: Installation and Setup. There are details discussed in each article explaining how we’ve worked our way to this stage, pulling data from Pods into our theme.

Pods Pages

Pods comes standard with a feature called Pods Pages baked right in. There is a ton of documentation available in the User Guide, and an entire section set up in the Pods admin screens:

While I’m really impressed with the Pods Pages implementation, I actually prefer not to use it. Instead, I like to integrate Pods itself into my theme files. I like to work with my hands a bit dirty when it comes to plugins, and would rather work with PHP itself in my favorite text editor the way I normally would when developing a WordPress theme. Thankfully, Pods has done a fantastic job with supporting developers like me. For the time being, we’re going to skip the Pages section of the Pods admin, and crack open our template files themselves.

Setting up our Team page

For the purposes of this example, I’m going to work with the default WordPress theme that ships with every download. I’m going to create a really generic template that we can work with:



  

    
    
    
      

        

        Our Team

        findRecords('name ASC');
          $total_members = $team->getTotalRows();
        ?>

        0 ) : ?>
          fetchRecord() ) : ?>

            get_field('id');
              $member_name      = $team->get_field('name');
              $member_position  = $team->get_field('position');
              $member_photo     = $team->get_field('photo');
              $member_bio       = $team->get_field('bio');
              $member_eom       = $team->get_field('eom');

              // data cleanup
              $member_bio       = wpautop( $member_bio );
              $member_photo     = $member_photo[0]['guid'];
            ?>

            
              
              
              
                " alt="Photo of " />

At first glance, it may look like there is a ton going on here but once we break it down, you won’t be very intimidated, I promise!

From a really high level, we’re working with a very basic WordPress template file here. The interesting bits begin with:

$team = new Pod('team');

This is huge! What we’re doing here is defining $team as a Pods object, ready to interact with the data we’ve entered. When we fire:

$team->findRecords('name ASC');

We’re calling a Pods function that lets us directly work with the existing data. If you check out the User Guide for findRecords you’ll discover the various parameters available to us. We can control the order in which the data is returned, the number of records per page, limit the returned data based on certain criteria, and even use our own SQL to pull the data. In this example, the only parameter we’re passing orders the returned data by our name column. A ton of power lies in findRecords, and subsequent articles will cover much of what you can do when pulling your Pods data.

When we fire:

$total_members = $team->getTotalRows();

We’re giving ourselves a reference to check against that tells us just how many records are in the current Pod. This allows us to run a conditional to check whether we even need to continue any further:

if( $total_members>0 )
{
	// work with our data
}

Once we’ve established that we do indeed have data with which to work, we get to the other really exciting part of Pods:

fetchRecord() ) : ?>

  get_field('id');
    $member_name      = $team->get_field('name');
    $member_position  = $team->get_field('position');
    $member_photo     = $team->get_field('photo');
    $member_bio       = $team->get_field('bio');
    $member_eom       = $team->get_field('eom');

    // data cleanup
    $member_bio       = wpautop( $member_bio );
    $member_photo     = $member_photo[0]['guid'];
  ?>

We’re running a couple of Pods-specific functions here that you’ll want to become familiar with:

fetchRecord: Retrieves the next record from our $team object
get_field: Retrieves the data for a specific column (referenced by its given name when the Pod was created)

So what we’re doing with this while is looping through all available records in our Team Pod. We’ve only hit this loop because of the preceding conditional that checked to make sure there was at least one record in the first place. Each field is assigned to a variable for future reference. We’re also able to format the data should the need arise. For example, when it comes to paragraph columns, I like to fire wpautop to ensure the markup is cleaned up a bit prior to my use.

Note: File upload columns return an array no matter what when get_field is fired. The array consists of a number of fields, guid being the actual location of the file, and more than likely the most common field you’ll be using.

As it stands, we’ve defined all the variables we’d like to work with, so it’s a matter of dumping them out as you would any other time:


  
  
  
    " alt="Photo of " />

Giving each Team member a dedicated page

While it’s great that we can pull all this data in any way we’d like, Pods lets us take things even further by taking advantage of the slug column we set up and implemented. First, you’ll need to confirm that you’ve properly set up your .htaccess file, and permalinks are working properly. This is essential. The next thing we’ll need to do is make a quick change to our (now) Team index page:



  

    
    
    
      

        

        Our Team

        findRecords('name ASC');
          $total_members = $team->getTotalRows();
        ?>

        0 ) : ?>
          
            fetchRecord() ) : ?>

              get_field('id');
                $member_name      = $team->get_field('name');
                $member_position  = $team->get_field('position');
                $member_slug      = $team->get_field('permalink');
              ?>

              
                
                   -

Instead of looping through our data and dumping out everything on a single page, we’ll now have an unordered list including list items containing the team member name and position, linking to his unique URL by using the automatically generated slug Pods has provided. If you save this revised template, you’ll see that the team members are listed properly, but clicking his link results in a 404 page not found. That’s because we haven’t told Pods to take over when it comes to these links. This is where we’ll return to Pods Pages.

Click Pods in the left hand WordPress admin navigation, and select Pages from the top of the resulting page, we’re going to Add new page:

Giving your Pods Page the proper name is essential, so mind your spelling, and make sure your page name is acceptable. Of particular note here is the /* portion of our Page name. Since team/ has already been claimed, we’re going to let WordPress have it. We only want to use this Pods Page when we’re trying to view a particular Team member page, hence the wildcard. When naming Pages with a wildcard, Pods will recognize that it should look for anything with team/ in the URL, followed by another URL segment.

Once you’ve created the team/* page, we’ll need to create a new WordPress template.

Alternative Pods Pages setup

In this case, I opted to set up the Team index page as a WordPress page. Alternatively, we could have set up a new Pods Page named team, defined our template file, and continued without problem. I sometimes prefer to add the ‘index’ type pages as WordPress pages depending on the client, as well as the other pages of the site. I’ll usually create an index page as a WordPress page so I can still make use of the user defined title and content, and dump out the Pods data after that. Sometimes, however, you won’t want the client adding their own content to the page. If that’s the case, it would make sense to create the index page as a Pods Page instead of a WordPress Page.

Setting up our Team member template

We’ve got our Team index template, but we haven’t yet told Pods which template to use for our team/* page. Let’s create it:



  data ) )
    {
      $found_member = true;

      // set our variables
      $member_id         = $member->get_field('id');
      $member_name       = $member->get_field('name');
      $member_position   = $member->get_field('position');
      $member_photo      = $member->get_field('photo');
      $member_bio        = $member->get_field('bio');
      $member_eom        = $member->get_field('eom');

      // data cleanup
      $member_bio        = wpautop( $member_bio );
      $member_photo      = $member_photo[0]['guid'];
    }
  ?>

  

    

      
        
        
          
          
            " alt="Photo of " />
          
          
        
      

    

      
	    Team Member Not Found
	    
	      Sorry, that Team member could not be found!

Save this as a new template file. As a result of the AJAX nature of Pods, we’ll need to ‘cycle’ the Pods Pages page by hitting Pods in the sidebar, choosing Pages from the tabs up top, and choosing our newly created team/* from the dropdown. Our Page will load, and the field we’ll need to pay particular attention to is the -- Page Template -- dropdown in the lower right. Select our newly created Team - Member entry and click Save changes:

You can now head back to our team index, hit a link in our Team list, and check out the new one-off page for each Team member!

A few new things are happening in this template. We’ll focus on the following snippet:

global $pods;
$member_slug  = pods_url_variable(-1);
$member       = new Pod('team', $member_slug);

First, we need to bring in the global $pods; variable; we’ll need it. Pods has a nice function available called pods_url_variable() that lets us pull URL segments and use them as variables. We know that the last segment on this page is going to be our Team member slug, so we’ll go ahead and set that.

When we fire:

global $pods;
$member_slug  = pods_url_variable(-1);
$member       = new Pod('team', $member_slug);

We’re passing that slug as a parameter when initially defining our Pods object. Under the hood, Pods is pulling a record from the database that has a permalink that matches the string we’re passing. Wicked handy. Since we’re basing our data on the passed slug, we’re going to need to consider the possibility of an invalid URL, we can use a quick conditional:

if( !empty( $member->data ) )
{
  // dump our data
}

There are a number of ways you can check to see if a record is returned, just make sure you have a fallback in place. Once we know that we have data to work with, we can fire get_field() and pull whatever we need. Easy peasy.

The Pods CMS Series on MBN

This article is the third in a series for Monday By Noon dedicated to Pods CMS.

Pods Basics: Installation and Setup

Jonathan Christopher — Mon, 04 Jan 2010 07:13:20 +0000

Installing Pods is equally easy as installing any other WordPress plugin. You can either use the built in admin installer, or upload the plugin files to your plugins directory. Once installed, go ahead and activate Pods. You may receive a not-so-pretty notice letting you know that you need to modify your .htaccess file. This is so Pods Pages can work properly using SEO friendly slugs (just like WordPress does). Pods offers a text file from which you can copy an acceptable .htaccess file, and even tells you where the file needs to be on your server.

Once installed, Pods gives itself an entry in the admin sidebar:

Under the Pods entry in the sidebar are a number of additional links.

Browse Content: Allows you to browse all the content in the Pods database tables.
Package Manager: Pods has a built in import/export system which allows your existing Pods to be portable.
Menu Editor: Pods also allows you to build a navigation structure based on your existing Pods much like WordPress Pages.
Add country, Add state: These are existing Pods included by default. You can manage the Pod content using these links.

How to create a Pod

I define the need for a Pod when a website has a particular section of pages (or even a single page) that requires a specific set of fields having to do with the subject at hand. As an example, we’ll go ahead and create a Team Pod that will house the various details about company team members. The First step is to Add the Pod by clicking Pods up top, and then Add new Pod:

Note: When creating a Pod, the name must be lowercase, no special characters or spaces.

After you’ve created your Pod, your instantly brought to the Pod manager. Here is where you’ll define what fields your Pod has, as well as a few settings regarding the Pod itself:

By default, Pods will add a name field (which is permanently required) as well as a desc (description) field. The available fields in Pods are as follows:

Date: Required to be a date
Number: Validated as a number
Boolean: Renders as a checkbox to the user
Single Line Text: Generic single line text box
Paragraph Text: Multiline text box with HTML formatting
Code: Multiline code field
File Upload: Ties in directly with the WordPress Media library, also allows you to upload new media directly
Permalink (slug): Automatic slug generation for each Pod entry
Relationship (pick): Allows the Pod entry to be linked to another Pod or a WordPress object (Page, Post, User)

With this being a basics-only tutorial, the last bit which will be useful when first working with Pods is the Attributes section of the field. Using the available check boxes, you can make a field required (can’t be empty) or unique (can’t duplicate the data entered in another entry).

Adding fields to your Pod

You can add as many columns (fields) to your Pod as you’d like. For our example purpose, we’ll add the following columns (name already present by default):

Job Title: single line text
Photo: file upload
Bio: paragraph text
Employee of the Month: boolean
Permalink (optional): permalink (slug)

When adding columns, do yourself a favor and make the name both easy to type as well as easy to remember. No spaces, all lowercase, no special characters. Pods provides a Label field for us to better describe the column to our user:

Note: You’ll notice that we’re using a Permalink column in this Pod. Permalinks work in the same way as in WordPress itself. I’ve purposely labeled this column as optional primarily because the word itself confuses clients. Additionally, Pods will automatically generate a slug when the Pod is submitted if nothing is filled out. No harm, no foul.

When all of our columns are added, we can reorder our fields by dragging the arrow icon and clicking Save settings, we can edit a single column by clicking the pencil icon, and we can remove a field by clicking the appropriate red X. We’ll go ahead and remove the body field if you haven’t already, and be left with the fields we’d like to work with:

Note: Pods uses AJAX a lot. When reordering columns, you’ll need to hit Save settings in order for that change to be applied. Additionally, when creating new Pods, entries in the sidebar will not appear until you’ve refreshed the page. It’s sometimes a recurring theme, but the AJAX is helpful as it allows you to rapidly build your Pod without having to wait for page refreshes every time. I imagine this will be improved upon where possible in further releases.

Managing the content stored in your Pods

Setting up your Pod is only one-third of the process. After getting your columns in order, you need to populate some data to work with. This also gives you great insight regarding what your client will see when they manage their data. If you hit the Pods link in the sidebar to force a page refresh, you’ll notice a new entry at the bottom:

Clicking this new entry will allow us to manage the content within our new Pod.

Clicking Save changes will save all the data to our Pod for reference in our theme. If you hit the Browse button at the top of the edit screen, you’re shown a listing of all team entries:

Isn’t that much better than creating a generic WordPress page? You can order your Pods entries by the available columns, and limit the listing by narrowing the search as you can when browsing other WordPress data tables in the admin.

Integrating your Pods a bit more

Pods allows you to make managing this content that much more straightforward. If you edit the team Pod we just created by clicking Pods (in the sidebar), then the Pods tab up top, and choose team from the dropdown, our team fields will be loaded and we can maintain the various attributes of this Pod. What we’re going to do is mark this Pod as a Top Level Menu. What that means is that our Pod will now show up as its own entry in the WordPress admin sidebar, as opposed to being a subentry under the Pods heading. To make this change, simply check off that this pod is indeed a Top Level Menu, and give it a Menu Label:

Once you’ve filled out the label, you can go ahead and click Save settings. We’ll again hit the Pods entry in the sidebar on the left, and you’ll notice that we now have a dedicated entry for our Teams Pod. Awesome!

Implementing your Pod on this level will help your user to better make sense of how to manage the content of this custom data set.

Limiting access to Pods

One of my favorite features about Pods is that it gives you fine grained control when determining who will be able to manage what when it comes to your Pods content. Using the Roles panel, you can give user accounts access to certain Pods and remove access from others. The feature comes in really handy when taking advantage of the various user Roles WordPress provides. You can manage this access by clicking Pods on the left in the sidebar, and then hitting the Roles tab up top:

Now that we’ve set up our Pod and added a bit of data to it, the next article in this Pods CMS Series will guide you through pulling the data for use in your theme.

The Pods CMS Series on MBN

This article is the second in a series for Monday By Noon dedicated to Pods CMS.

An Overview of and Introduction to Pods CMS for WordPress

Jonathan Christopher — Mon, 04 Jan 2010 07:13:13 +0000

If you follow me on Twitter you know that I mention Pods a lot. As defined by its creators:

Pods is a CMS framework for WordPress. It’s a plugin that sits on top of WordPress, allowing you to add and display your own content types.

Calling Pods a ‘plugin’ is an understatement. It’s one of those WordPress plugins that does so much more than provide some functionality to work with that makes your life a bit easier or makes WordPress that much more useful. Pods has changed the way I work with WordPress. Pods has allowed me to truly use WordPress as the content management system it was born to be. While a ton of great stuff is happening in the core, Pods is giving us what we need to work with today, and it’s spectacular.

Over the next few months, I plan to divulge all I know about Pods in a series of tutorials and articles meant to act as my own personal user guide for Pods. Pods is a big enough system where you can actually work with it in your own style, and I think I’ve done that to an extent. Pods has an entire level of author features that I don’t particularly make use of simply because I prefer to get my hands even dirtier than Pods requires.

An introduction to Pods

As it is defined, Pods is a content management plugin for WordPress. Many people may wonder why a plugin is needed to make WordPress a content management system, doesn’t it do that already? Absolutely, but out of the box, WordPress specifically caters to a few types of content; Posts, Pages, Media, Comments, and Links. WordPress does a ton more (such as categories, tags, users, etc.), but as far as the average user is concerned, those are the major content types you’re able to work with. Themes bring all that managed content together to share with the world, and plugins build on top of that even more.

Many plugins exist to provide you with a new type of content to manage, most often a specific type of content aimed at achieving a specific goal. That’s awesome, and helps tons of people to make that change they’re looking to update on their site. Pods, however, thinks about things in a different way.

Pods provides a platform on which to build your own content types to manage, all the while providing some really advanced functionality having to do with that content. From the User Guide, a Pod is a group of input fields. You can add and arrange any number of the various available input fields to any number of Pods, essentially creating your own custom CMS for each website you build in WordPress.

Finding the happy medium between WordPress core and Pods

So if WordPress is a CMS, and Pods is a plugin that acts as a CMS framework for WordPress, how (and why) can you use them at the same time?

While you can technically accomplish the same functionality with an out-of-the-box copy of WordPress using a crazy blend of nested Pages, categorized Posts, and a ton of Custom Fields, Pods helps abstract that desired ‘next level’ of functionality you’re looking for as a WordPress developer.

Trying to explain what Custom Fields are and how to use them to a client isn’t something I look fondly upon. While it’s super for developers, to the rest of the world it’s terribly bulky and unintuitive. I think Custom Fields are an awesome available resource for plugin developers, but they’re one of those things better left unseen to the novice user. Pods brings the ability to work with custom pieces of data to the client, all the while giving developers a terrific extended platform to build upon. If you find yourself repeatedly using custom fields within your WordPress sites, especially for clients, you’re probably ready for Pods.

The Pods CMS Series on MBN

This article is the first in a series for Monday By Noon dedicated to Pods CMS.