Though we are all working with data at the heart of the WordPress database, we often take it for granted.
But data drives our content, our navigation, our presentation, our whole website.
Wouldn’t it be a good idea if we managed it properly?
I must confess, I love data. Actually, that’s as perverted as loving money – I actually love what can be done with data, rather than data itself. Structured and handled properly, application development, from the most basic WordPress plugin to a full blown web application becomes much more scalable and easier to manage if we get the data right.Our sample project Happiness Today, relies on data, just as it’s inspiration, Hello Dolly does. Whereas Hello Dolly data, the song lyrics, are hard-coded in the plugin, Happiness Today data is put where it belongs – in the WordPress database.
Each Pods project starts with data. This is the basic building block, known simply as a Pod. In complex applications, the hard part is learning how to structure data, especially if it needs to be split into different Pods.
Our example is very simple – every record in the Pod is just a lyric from the song. Experience tells me that I need keys to data in databases. In this case I use a simple line number identifier, which allows me to sort the records should I wish to output the whole song.
It is a good habit to always think of record keys when designing a Pod, or any other database. Pods helps us here by always creating a field called name, which will always uniquely identify records. With the Pod created, we simply need to add the text to each record, which we do with the standard Pods CMS record editing screens.
Job done, except that we need to get the data out. I’ll be looking at presentation in the next article. In practice, when planning this type of application, you would start by designing the display(s) that need to be produced, and work back to the data required to fulfill that. The crucial point is that the two are completely separate. We have the song data held independently as text records, unchanged but for some keys to identify individual lines.
It is important to grasp this separation between data and presentation. It is also important to plan them both before you start. This example is fairly trivial, but it illustrates the guiding principles. For example, had the application been to present random words, then the database structure would be different.
If you are new to databases, it is a good idea to create some example Pods to familiarize yourself with the features available. When you design an application in future, you will always start planning the outcomes first, then the data structures. When we build the application, it is data first, followed by presentation and often some calculation or other forms of data manipulation.
In this series, we are also concerned with distributing our data via the WordPress Pods Plugin Builder. There are two elements – the data structure, and the data records.
Pods has an inbuilt mechanism for exporting and importing Pods data structures within its Pods Package feature. This is exposed programatically through the Pods UI plugin, with an import routine demonstrated in the Pods UI demo plugin. The demo has the import code hard-coded into the plugin, but I needed this to be file based for maximum portability. As this is more than just data, I’ll cover the routines for programatically exporting and importing Pods packages in a later installment (I should also suggest this for the Pods codex, so remind me if I forget).
Similarly, the Pods API exposes import and export methods, so I included these in the builder, to build sample data and import it. To my delight, the proof of concept works fine. The builder creates files for the data structure and data records and a plugin.php file. The plugin imports these during initialization and all is fine, except that it doesn’t really…
It is still fine, but the data import has to be separate from the structure import. I have a fairly good idea why this is the case, but as I was thinking about the solution I realized that the data record import SHOULD be separate from the structure import.
To make Happiness Today really useful, it is important to allow users to easily package their own text messages and links. Therefore, I believe that the data import, complete with block delete and export functions should be included in the basic plugin as user routines, separate from installation routines.
My only dilemma is that the extra layer of functionality adds a little more complexity to the idea of a very simple example. Perhaps it is pointless to take simplicity below the level of usefulness?