Skip to toolbar

Best Practices For Pods Deployment

Best practices for local development, migrating site content and Pods configuration.

At Pods we always recommend doing all development in a local development environment and only pushing the changes to a live server once the site is ready. This is very easy for a live site thanks to tools like Vagrant, VVV, or ServerPress’s DesktopServer. It does get a little trickier when making changes to an already live site. This is especially true when content on the live site has changed between when the site was pulled down to the local development environment, and the changes are ready to be deployed In this article we will be discussing doing local development, using best practice method for migrating site content and Pods configuration.

A Little Background On How Pods Content and Configuration Is Stored

The configuration for Pods, IE the details that define a Pod or a Pods field are actually stored as posts. Pods and Pods fields are private in custom post types–_pods_pods and _pods_fields. This means that the Pods configuration is stored in the post and postmeta tables. Therefore the ID of a Pod, is the ID of a post in the _pods_pods custom post type. The ID of a Pods fields is technically speaking the post ID of a post in the _pods_field post type. IDs of posts in WordPress are assigned using SQL’s auto increment. Pods content–IE the information stored in each item of a Pod, is stored in various locations based on the type of Pod and the Pods’ storage options. For example, custom post type Pods, with default meta storage use the posts and postmeta table, just like any other WordPress post type. But, with the table storage component active, they can be optionally configured to use a custom table instead of the postmeta table for custom fields. Advanced content types (ACT) on the other hand use a custom table for their content. Their configuration is still defined by posts in the _pods_pods and _pods_fields CPTs and is therefore dependent on the post and postmeta table.

Deploying A New Site To A Live Server

When a new site has been created in local environment, deploying the database is very simple. You can copy the database using phpMyAdmin, or a WordPress database deployment tool such as Delicious Brains’ WP Migrate DB Pro, or migrate the entire website using iThemes’ Backup Buddy. Since there is no existing content, none of the issues discussed the next section will apply. Simply copy the database and everything will be the same on the live site as on the local environment. This is fine if your Pod is brand new to the site, ie you’re adding a new Pod with relationships to existing tables (as long as those two were perfectly in sync), but not so great if there are Pods configuration changes.

Updating A Live Site With Changes Made In The Local Environment

Replacing the live database, or even specific tables is not always possible, when making changes to an already existing site. If changes in the local environment involved changes to the Pods configuration, which are stored in post and postmeta, copying those tables from local to live may not be feasible, as you could overwrite changes on the live site to post content in other post types. Relationship fields in Pods are one of its most useful and hardest to deploy features. Relationships are defined by a an option (technically a meta key/ value pair in _pods_fields) called sister field ID, which stores the ID of the related field. So if field 1 is related to field 2, there is a meta key assigned to field 1, called sister field ID, whose value is 2. When you do Pods Package export, somewhere in the JSON file that the Pods Migrate Packages creates is says Field 1’s sister field ID is 2. This is a problem when importing that package to a live site, as the fields will be created with the next ID based on the new site’s database’s auto-incrementor. If you import to another site but, it’s auto-incrementor is already at 27. So Field 1 is now field 27 and field 2 is field 28, but field 1’s sister field ID is still 2. For this scenario, we created Pods Deploy. Pods Deploy automates the process of creating a Pods Deploy package, pushing it to a live site and importing it, using our JSON API. That part of the process suffers from the same issue, discussed above and will break bidirectional relationships, as the Pods Migrate Package stored sister field IDs using their IDs on the local site, into the live site. Since we can not endow the Pods Migrate Package with time travel or the powers of precognition, Pods Deploy creates a snapshot of the bi-directional relationships based on Pod names and field names. It then updates the bi-directional relationships on the live site, using the names as reference, but the correct IDs. For more information on how relationships between Pod items are stored, please see this article.

What About Content?

Pods Deploy does not affect Pods content at all. Moving custom post type content, without affecting other content between sites is tricky, and is a good job for a CSV import export tool that can select only certain post types. WP All Import is a good choice for this situation since it handles both XML & CSV formats, and their Pro Version comes loaded with added functionality for images, WooCommerce and support for other premium plugins. One advantage of using Pods Advanced Content Types is that their content is stored entirely in a separate table. Therefore, after running Pods Deploy, you can simply push just their tables to the live site. This process is made very easy with WP Migrate DB Pro.

Additional Resources

Delicious Brains, the folks behind WP Migrate DB Pro, have released two incredibly helpful ‘tours’ of the WordPress Database both for Single and Multisite installations: