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.

WordPress Database With Pods (click image for full size)

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?

In most WordPress extensions, a lot of data is hidden in the code.

The massive advantage of Pods is that we can easily store additional data, and manage it very efficiently.

In the first installment of this series, I introduced shrewdBar, explaining it was based on a WordPress plugin that creates a menu by outputting data in the form of a CSS LIst driven menu. This type of menu is quite common – you style a nested list to have hidden items that reveal themselves when the mouse hovers over them. The added attraction of this type of menu is that without the styling, you simply have a nested list of items that search engines can follow.

The CSS issues are for another time. What I need you to realize is that these menus are usually built in code, with a lot of hard-coded links. True, the original menubar, DashBar, on which shrewdBar is roughly based, does have some items that are extracted from WordPress database tables. In my first version of the menu bar, I extended this to extract messages and topics from the Simple:Press forum.

Pods allowed me to put all the menu items into WordPress database tables, and I explain in this article, how I achieved this.

shrewdBar Database

In its current release, I have limited the menu to two tiers, so we have a Pod for the top tier, that you see across the top of the page. Optionally, each of these top level records can have a variable number of child items.

The schematic is:

Pods automatically creates the name and slug fields when we create a new pod. name identifies the record, and I also use it as a sort order. slug is very useful in many Pods packages, and I’ll cover it in depth later, but it is not really required in the current version of shrewdBar.

The text, title and url fields are the menu links that are used to navigate to different pages. The pick fields are used to relate tables – in this case a one to many relationship.

The top level menu records have two additional fields. The boolean hold field allows menu items to be temporarily hidden, without deleting the record. This is not required for second level items, as it is a simple click to break or make the relationship to a top level menu. The display field allows us to enter PHP code which can programatically control the display giving us very powerful dynamic menus. I’ll be discussing this at length in the next installment.

shrewdBar Options

Like most plugins, shrewdBar needs options to control colors and positioning. Unlike most WordPress plugins, these options no longer have to live in the options table where they soon get lost. I put the shrewdBar options in its own table, which makes it very easy to manage. The options data could be managed using the standard Pods edit page, however I find it better to write a special page with information and instructions. I’ll be covering this in detail in a later installment.

In the next installment, I will explain how simple Pods procedures act on the data to produce the list output that forms the shrewdBar menu.