Pages Module 1 - an Introduction and History
This past week a number of the threads in the ExpressionEngine Support Forums were related to the first-party ExpressionEngine Pages Module. It seemed to me that people were either trying to use it in ways it wasn’t intended to be used or were running into limitations that aren’t made clear in the documentation.
I set about to write a comprehensive article about the module - what it is, where it came from, why it was developed, what it does, what it doesn’t do, what it prevents you from doing, how people are using it, and how 3rd party developers are extending it. As I started putting the article together it started getting pretty long, so I’ve decided to break it up into either a 2 or 3 part series. This first installment covers the basics of what the Pages Module is (and isn’t) and takes a look at the history of the module with interviews from a couple of the key developers in its history.
What this article won’t do is talk in great detail about 3rd party addons like Structure and Taxonomy. While they are part of the Pages Module lineage I haven’t yet used either one of those tools and would rather not cover them without direct experience. But hey - that’s what comments are for, right?
“What’s this stuff? Some Cereal. Supposed to be good for ya.”
So what is the Pages Module? Your first encounter with the Pages Module may be in the Addon-Ons > Modules area of ExpressionEngine where it says:
Uses Channel Entries to make Static pages
Oh, cool, so this module creates static .HTML files from my channel entries, which should load faster. This is a performance-related module then?
Let’s read on, now from the description from the Pages Module documentation where it says the module:
allows you to easily create and maintain page content that is more akin to static content than dynamic information.
How much more akin? Is the content stored differently somehow? Is the whole page managed this way, or just parts of it? Is the process for creating new “pages” different than an “entry”? Is there a difference between “content” and “information”?
Additionally, these special “page” entries can be displayed with virtually any URL desired.
Now there’s some meat. ExpressionEngine by default has a relatively prescribed URL structure. How you name and organize your templates and template groups has a direct effect on your generated URLs. Most times that’s fine, other times it’s a barrier to another goal. Being able to work outside that structure when desired is handy.
The documentation lists some additional features:
- Allows content authors to add and maintain pages without needing access to Templates
- Enjoy the full flexibility of channel entries in how your “page” information is entered
- Use virtually any URL to display the “page”
#1 is reassuring. I certainly don’t want content authors to need access to templates. But wait - does that mean if I don’t use the Pages Module they’d need access to templates? #2 just tells me I haven’t lost any flexibility - so that’s good. #3 re-iterates the point made above.
So the Pages Module is…anyone? Anyone?
So some of the confusion around the Pages Module comes from the EE documentation because it doesn’t fully explain what the module is and is not. Here’s my take on it - the Pages Module is primarily a way to:
- allow content authors to define a URL to the content.
- allow content authors to define content heirarchy by creating URLs that establish it.
- provide content authors navigation to edit existing Page entries that reflects heirarchical URLs.
- allow developers a way to offer content authors different “output templates” for their Pages content, without affecting URL structures.
The Pages Module is not:
- a way to have ExpressionEngine generate true static .html files from rendered content & templates.
- the only way to prevent content authors from needing access to templates.
- a significantly different way for content authors create or maintain page-based content.
- usually the basis for an entire website built in ExpressionEngine.
“Just sit right back and you’ll hear a tale / A tale of a fateful trip”
Later in this series we’ll look deeper at the ins and outs of the Pages Module, but first I wanted to to look at where it came from and why it was developed.
Mark Huot’s Tome
As with many of the significant ExpressionEngine Add-ons, the Pages Module started with Mark Huot, Technology and Development Director for Happy Cog. Mark wrote a module initially called “Pages”, later renamed to “Tome” after ExpressionEngine came out with its first party Pages Module.
Tome’s approach was to use one weblog as the Tome weblog. You’d create a category group for this weblog and use ExpressionEngine’s category management tools to establish a hierarchical structure (think one category per page). Once the hierarchy was established you would use the Tome interface to get to a node to edit the content there. Or, you could feed other weblog content in at a specific node by changing the module configuration, routing its output to a different template.
Mark graciously agreed to answer some questions about Tome as background for this article:
What was your reason for developing Tome? Was it for a specific client project or something you wanted to provide for the community?
It was developed for the community. I was enjoying EE development so much I started comparing EE to other platforms. I noticed WordPress had a great “pages” feature that allowed you to create one-off static pages. EE was sorely lacking in this area. I had noticed many tutorials on how to use weblogs and nested templates to re-create this kind of functionality, but they all felt like hacks.
It only took a few hours to get the initial proof of concept up and running. EE’s extension hooks (at the time) were far too generous and allowed me to hook in to the very underlying functionality of the system. I was able to rewrite important aspects of the URL routing engine and generate a static page.
What advantages did you feel Tome offered over what EE did natively?
At the time EE didn’t offer anything like this. Its advantage was that it allowed me to break entries free from their channel and allow them to live on their own as stand alone pages.
Did you feel Tome had downsides to being used (did it play well with segment variables, pagination, categories, embedded templates etc)?
Yes, it had many downsides. The biggest of which being 1. my ability to support it and 2. its hacked implementation on top of EE. While I was able to get it to play nicely with most segment variables and categories, pagination was always a bear.
How similar or different to Tome is the native Pages module?
All in all, it was awfully darn similar. The biggest difference was the UI of the CP. I had a release just about ready to go out at the time that Pages was released which enhanced the CP UI to add expand collapse support, drag and drop support and a slew of smaller UI tweaks. Those features never saw the light of day, and unfortunately never made it into the native Pages module either.
With the current state of EE and the addon aftermarket, how would you meet the project requirements today that caused you to create Tome at the time?
The short answer is that I use Structure for most of my development now. It’s robust and offers a much cleaner UI for content editors to get content into EE.
As an aside, Train-ee traces its roots to Tome, as some of the first tutorials I wrote were how to use native weblogs and templates to create “static” content with dynamic navigation.
“Rumors of my assimilation are greatly exaggerated.”
Or not in this case. ExpressionEngine version 1.6 - released in June of 2007 - included a new “Pages Module” that assimilated some of Tome’s features. The primary ExpressionEngine Developers at the time were Paul Burdick and current EllisLab President/CTO Derek Jones. Paul Burdick handled the ExpressionEngine Pages Module and also agreed to answer some questions about it via email:
What were the reasons for developing the Pages Module?
Mark Huot had written a very popular module called Pages that allowed one to organize content into a hierarchy while also dynamically generating navigation for those pages. It was extremely popular as it allowed people to create a slightly more custom site structure. Do not remember how it worked exactly. However, there were a couple bugs that were causing EllisLab to take notice of it, specifically it killing sites with load and install/uninstall/update issues. Mark was working on a new version but with his client work and other responsibilities it was delayed. Since it was popular and seemed to fill a need, EllisLab decided to build their own version with a tighter integration in ExpressionEngine, which allowed the load to be greatly reduced.
What advantages did you feel the Pages Module offered over how EE worked before it existed?
The original intention was to allow users to use entries and templates to create a site structure more fitted to their needs and outside the standard template_group/template URL structure. Essentially, a single entry displayed by any template at any URL they dreamed up. Any hierarchy would be on whatever URL structure they created. Extremely basic functionality, honestly, but something that required modifying the core.system.php file to override the use of the Template class. Also, it allowed designers to create content on the site that was only displayed on a single page (ex: an about page) that was editable in the Publish area by their content editors without needing to touch templates or global variables.
Did you expect that people would use it as the basis for an entire site or just portions?
Definitely portions. An entire site being created with Pages was not even on the radar. It was a rather lightweight addition to EE 1.6.
Is there a reason the module never went further with more dedicated tag pairs for building navigation and breadcrumb trails?
If people remember, the real effort for building ExpressionEngine 2.x started in 2007 at EllisLab. On some level, EllisLab and specifically the development team was spread a little bit thin the latter half of that year with ExpressionEngine 1.x, CodeIgniter, and ExpressionEngine 2.x work. Derek Jones and I were the only full time developers working on ExpressionEngine for most of that year too. So, expanding Pages was not a priority. Further, looking back at the EE 2.0 To Do list now, one of the highest priorities for ExpressionEngine 2.0 was a rewrite of the Template parser. And one of my goals with that was to allow more flexibility in how the site structure could be set up via templates. Obviously, with my departure in early 2008 and the delays with ExpressionEngine 2.0 being released, those two goals were never realized.
Were/are you happy with how the module currently functions?
Looking at it now, no, I am not pleased with how it functions. However, I understand why it was written so simply at the time and that we were *planning* on making much more powerful functionality possible in the future.
Do you feel there are downsides to using the Module and if so, what are they?
Honestly, it is way too simple and not easy enough to create Pages and build a hierarchy (especially seeing the current hierarchy and adding to it). Once again, so much of this seems like something destined for the “Design” area in the CP, as it is a amalgamate of Publishing and Site Structure.
What are your thoughts on how the addon market has extended the use and overall direction of the Pages Module?
Except for Structure, I am not familiar with how the Add-On market is affecting or has been affected by Pages. I tried using Structure during the first EECI Conference in Leiden, but it never tickled my fancy. My personal needs in ExpressionEngine have always run towards the amazingly bland and simple or so extremely specific/complex that I have had to custom build my own Add-Ons or hack ExpressionEngine itself. Professionally, I have not had to work with either Pages or Structure while working with Solspace.
In the next installment of this series we’ll cover how to install & configure the Pages Module, how to code a template to display Pages Module content, and what using the Pages Module means for content authors.
Thanks to Mark and Paul for taking the time to respond to my questions, and thanks to Eric Barstad of Shadow Box Creative Media for supplying the Tome screen captures.