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: menu bar, shrewdBar, WordPress database, WordPress Pods CMS
