With it’s easy to use interface, it is good for novice writers, but it also stands on a very powerful data management platform.
This makes it a real candidate for Rapid Application Development, but how to package and distribute those applications?
Before I present my latest project for building structured WordPress plugins, packaged with properly formatted readme file, straight from the Pods interface let me explain what Pods is.
WordPress Pods Background
Pods builds applications by creating data tables and presenting that data on pages, using display templates to keep presentation simple. Going beyond basic table administration, Pages and Templates can include any HTML or PHP code you like to manipulate data. And going beyond that, there are Helpers that can manipulate data before during or after it has been entered.
This means that any extension to WordPress can be coded in Pods. Tasks that do not require data manipulation probably do not need Pods. On the other hand, most plugins do need to use the WordPress database, even if only to store some options. Using Pods makes that data easy to maintain and it’s structure means that it is very easy to build reusable code libraries.
I will explain Pods Data, Template, Page and Helper features in more detail when I explain how my Pods projects work. First let’s look at my current to build WordPress plugins using Pods.
WordPress Pods Plugin Builder
Pods already does a good job of easing distribution of projects. It is extremely easy to bundle your project components together and export them as a Pods Package. The Pods CMS site has several examples of these packages which as well as being useful in their own right, can be used to learn various techniques.
These packages can be pasted directly into Pods, or loaded programatically, as demonstrated in the Pods UI demo. This makes distribution very easy, but there is one vital thing missing for most projects, and another missing for many.
The vital missing part is data. Though pods can export and import data, this is not part of the Pods package process. If you are handling a project for a client, it is very easy to move data to your clients site by exporting and importing, but it is not possible to supply a single package including code and data.
For most Pods projects, that data problem is the only one, and the import and export routines simply mean you have to distribute code and data separately. For many of my projects, I want to provide WordPress plugin functionality. This means that I need at least one plugin file to hook the functions into WordPress.
My Pods Plugin Builder produces standard format WordPress plugin files from Pods. The plugin it produces will load a Pods package, load the data, and add the hooks that WordPress needs. It also produces a correctly formatted readme.txt file which is so important if you want people to be able to find your plugin in the WordPress repository.
I passed a milestone today when I used the package to produce my first plugin.
WordPress Pods Plugin Builder: Next Steps
In the next few articles I will:
- Describe the package in detail, including work still to do, and potential additional features.
- Introduce the plugin that this package has produced, and describe how key features of Pods work.
- Apply the package to my shrewdBar & shrewdChat projects.
- Release the package for wider testing and distribution.