Posts Tagged ‘WordPress database’

WordPress Database With Pods Wings

March 11th, 2010 by Keith from shrewdies | No Comments | Filed in Web Hosting
I start my detailed look at the anatomy of our WordPress Pods plugins by showing you how Pods CMS makes the WordPress database fly.

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

WordPress Database With Pods (click image for full size)

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. (more…)

Tags: ,

WordPress Database Extension

February 9th, 2010 by Keith from shrewdies | No Comments | Filed in Function
Extending the WordPress database is the first step in developing my menu bar.

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:

shrewdies_bar    link    shrewdies_bar_item
name (txt) name (txt)
slug (slug) slug (slug)
bartext (txt) itemtext (txt)
bartitle (txt) itemtitle (txt)
barurl (txt) itemurl (txt)
baritems (pick shrewdies_bar_item)  ¹——∞ itembar (pick shrewdies_bar)
bardisplay (code)
barhold (bool)

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.

Tags: , , ,