Why I don’t use the Structure module
While clients and potential clients are welcome to read this Blog entry, it is primarily aimed at Web developers familiar with ExpressionEngine, so it gets a little technical.
There seems to be a lot of debate within the ExpressionEngine community about whether to use the Structure module by Travis Schmeisser and Jack McDade. Some believe that it makes content management simpler for end-users because it organizes content in the control panel in a list of nested pages. I’ve built some sites using Structure and although I’ve always received top-notch support from Travis, I’ve concluded that it’s not for me. This post explains why.
Problems I’ve encountered with Structure
- The last time I used Structure, it only allowed for two levels of depth in the navigation tag. This became a real problem once my client decided - after the site had been built on Structure - that she required three levels of depth in some sections.
- Structure also didn’t allow for multilingual design. I often work with Canadian non-profits who need their sites to be fully bilingual, but Structure’s navigation menu tag uses the titles of entries to label the menu links to those entries. So it didn’t matter that I’d created a custom field to hold the French title for an entry; Structure wouldn’t let me use it in the navigation.
- This also means that my menu links had to be labelled the same as their corresponding entries. Most of the time this is standard procedure, but non-profits often have elaborate but official event names like “The 2011 Annual Professional Conference and General Meeting.” Despite this, they usually want the link to be labelled something more succinct and recognizable like “Conference.” With the Structure module however, the entry and the link to it must be the same.
- I sometimes like to link to a page from two sections of the site. The only way to do this with Structure is to create a false entry whose only purpose is to launch a template that contains nothing but redirect code that sends the visitor to the true entry. Imagine how confused a client would be if she opened up the false entry thinking it was the real one only to find a blank publish form!
The real problem
Granted, many of these particular issues may have since been resolved in subsequent Structure updates [EDIT: Indeed some have, as Jack explains in the comments] but the real problem was a realization that I had upon encountering those ones: Structure is a commitment. If I invest in the Structure module to organize my content, there’s no turning back. If I encounter a roadblock during development and decide to abandon the module, I’ll need to completely re-code my templates and re-train my client on how to manage content.
Let ExpressionEngine be ExpressionEngine
Another gripe I have with Structure is that it undoes a lot of what I like about ExpressionEngine. Structure’s philosophy holds that even within the control panel, your site content is a collection of pages. Sure, this may be familiar to clients since they already see the front-end of their site as such, but I would argue that that’s a problem in itself. In suggesting that a site’s content is a collection of pages, you reinforce the idea that content resides in one place and not in another, like the pages in a book. If a character dies on page 200, he does not also die on page 50.*
I’ve seen clients get confused by the listings vs. pages thing and add listing entries as child-pages:
When you consider that they understand their content to be a collection of pages, it’s not surprising that they would do that.
Besides, there are plenty of CMSs that display content in the control panel in a page-tree format. If I wanted that, I’d use one of those options.
I prefer to teach my clients a philosophy that is at the core of ExpressionEngine: That a site is a made up of content, not pages. In ExpressionEngine 2, EllisLab wisely named content containers Channels, implying a stream of information without position. Some EE developers had previously - and inaccurately - suggested the term Sections, which implies location.
On the Web, something can exist in several places at once. When you add a News entry, you’re not creating a page, you’re simply adding that content. Where it appears on the public-facing site depends on how we’ve designed it. It may appear in the News section, on the Home page, and in the footer of every page. The Structure module unravels this notion.
One real problem with EE that Structure attempts to address is that there is no easy way to allow non-technical clients to manage navigation menus. I am currently handling this with Booyant’s add-on NavEE. While it’s not perfect, it does what I want it to and nothing I don’t.
NavEE doesn’t hijack ExpressionEngine’s content management architecture. I can still teach my clients to add content using the appropriate channels. NavEE just lets them create links to that content. And since it only recognizes entries that use EE’s native Pages module, there’s little danger of them confusing listing entries with pages.
Like Structure, NavEE displays its content in a nested list, but in this case it’s appropriate since the display reflects the front-end navigation menu itself and not the back-end content. Using NavEE, I haven’t experienced any of the problems I’ve encountered with Structure as mentioned earlier.
NavEE is also an add-on in the true sense of the term: it is added on to the CMS, and thus can easily be removed if needed. If I decide NavEE is not the right solution, I can relatively painlessly extract it from my site and go in another direction.
Whatever technique you use to manage content and navigation on your ExpressionEngine sites, it’s good to know that there are great add-on developers out there like Travis, Jack, and Mike who are working to make EE better, and I’m grateful for that.
From Gainesville, FL
Tuesday, June 14th, 2011 at 1:06pm
Commenting is closed for this entry. Sorry!