For the last two weeks I’ve been working on a very complex scenario. My client hosts an annual virtual race of tagged ocean dwelling Marlins. It’s pretty cool. Their members sponsor a race team and pays for a satellite tracking tag placed on a Marlin. This tracking data is collected by a university and periodically they update the tracks shown on the client’s website.
I’ve been helping them implement a replacement for their current ASP.NET website with one built in WordPress. Adding and updating the tracking information on their current site is difficult. It isn’t in a database and the pages have to updated periodically as the races progress over several months. They needed a much more flexible way to enter and update the data as well as a better interface to search and present the data on the site. My original thought was to add the maintenance piece to the separate web application I have written for them to manage their other legacy data. But one of the reasons for needing greater flexibility is to update what is essentially a textual blog of the race data.
A custom post type in WordPress is a much better option for maintaining and displaying the data but the search functionality was very weak.
Pods is a plugin for WordPress to handle custom post types and custom fields. It can extend existing post types or create news ones. These new post types can live in the normal WordPress posts table or stored in a separate table within the WordPress database. While Pods does provide more options for searching it was still not the kind of user experience they wanted.
Since the new post type is in a separate table it was easy to add a database connection from the Laravel based api built for the other custom searches and create the exact user experience they wanted. On the Laravel side the search form and summary displays are generated from Laravel views using Vue.js and the HTML is returned to WordPress for display.
It’s nice and clean. Except some of the data in the new post type is a relationship to other post types. For example, each race has multiple teams. That’s another Pods custom post type. The same is true for other related data. In all we ended up with five custom post types with Pods neatly managing the relationships. Pods manages those relationships using a single table and the linking is very different than the way Eloquent models in Laravel would handle it.
Thankfully, Laravel is very flexible. With just a few entries in the .env file on the Laravel side we can easily let the user search on related field data through the Pods relationship table and pull a set of race records to generate the table summary view needed. In that summary view each race is clickable using the WordPress permalink to take the user to the custom page displaying the race data with the related team data.
It’s pretty slick and since the Laravel simply generates and returns the html using the class names from the WordPress side, the look is seamless and if they change their styling in the future all of the custom search and display areas will pick it up without having to change anything on the Laravel side unless they introduce a new class name needed in the returned HTML.
Enter happy client.
This is the first time I’ve used Pods in WordPress and so far, I’m very impressed. The interface is clean and intuitive. It has built in ability to export custom post types and the pages and templates needed to display them to import them on another site. This is a very nice feature because I was able to build everything in a development environment before pushing it all up to the production site.
Even though creating custom post types in a custom plugin is very straight forward I can definitely see myself using Pods again because the user can change the custom post types in the future without having to have a developer modify a custom plugin … and that’s kind of the whole point of a system like WordPress.
My only complaint of Pods is side loading data is very difficult because of the way the developers chose to store relationship data. This isn’t a concern for the client but it did take some time to workout the scripts to side load the data. The other issue is extracting that data from the client’s existing site but that is a whole different ballgame.