I am proud to announce that Tentacle will now support sub pages! That’s right! Nest as many as you want!
One of the biggest challenges I had with building this CMS is the data structure.
On paper it looks easy.
Posts will have an ID, a Parent ID, Date, Title, and so on.
We end up with something like this:
| ID |
Parent ID |
Title |
| 1 |
0 |
Home |
| 2 |
1 |
Portfolio |
| 3 |
2 |
Web Design |
| 4 |
0 |
About |
Like I said, Simple!
But, Once you begin to work with the data you will soon realize that in order to query the data and return something usable you will have to work a bit of magic.
Typically hierarchical data is better handled with a database like Mongo DB. MySQL is a relational database and is not hierarchical. Establishing a Parent/Child relationship that is dynamic has a number of issues. It can’t be done with one query. Since I would like to make Tentacle just as easy to install as it is to use I go with what the majority of web servers offer out of the box, MySQL!
Some common methods for dealing with hierarchical data include the Nested Set Model and the Adjasency List Model but they are complicated and for every record added, multiple records need to be updated.
To complicated!
I reviewed a hand full of popular CMS solutions and a few smaller up and coming MVC/Framework based CMS’s wondering how they went about storing their page structures. While some of them did use the Nested Set Model almost all used a Patent/Child relationship.
Good enough for me!
One of the challenges had been retrieving the content, ordering ( Sort order ), and then creating the page tree was creating the initial object. Once I created my object it looked a little something like this.
I thought this was perfect… At least it looks cool. That is until I sat back and thought about how I was going to be using the data.
Basic navigation functionality would require that we display one level of navigation at a time, with the option to show sub pages of a parent page in another location.
I had no easy way to loop through the data at this point, and I also didn’t have an easy way to return the children of a sub page.
One problem WordPress has in its navigation functionality is the dreaded multi level navigation, where the third level has no connectivity to the top-level parent. There are plenty of plugins to solve the problem today, and I have even written a post about this in the past here.
After a bit of magic and a lot of trail and error I ended up with a flat Object that took into account menu order, parent/child relationships, and finally how many levels deep each child is.
Perfect!
