Greater integration of Pages addon functionality
Feature Requests
I manage a large (university department) site, which I’ve been running on EE for many years, and am working on moving from EE2 (2.11.3) to EE3. I have an EE 3.5.0 install running on a test server and have been playing with it. There are a lot of great improvements — yay for those — but I have a pretty big disappointment with respect to how EE3 supports the structure of our site, and I’d like to make what I hope are some practical and realistic feature requests.
Our site comprises roughly 1000 active pages/entries, about half of which are standard time-ordered dynamic channel entries for blogs, news, etc. The other half (about 500) are static pages, divided into about 10 site sections, each with its own template group, and each of a few dozen pages. Almost all of the static pages in each section use a common index template for that section.
Notably, I use the Pages module to assign URLs to these static pages, using a /section/subsection/page three-level structure. EE provides other ways to assign URLs to channel entries, but the Pages module is by some distance my preferred method for this — it provides a clean, simple, flexible way to create the static page structure that I want.
My hope in moving from EE2 to EE3 was that I would see the Pages module begin to be properly integrated into EE. Instead, it’s still considered an “add-on”, and (still) something of a dirty secret. I’d like to argue that for some (not all!) site structures, the Pages module is exactly the right tool, and it belongs within EE proper, as one tool among many.
Some specifics:
In EE2, the Pages module allows me to see a single-screen overview of the nested URL structure of the static pages on our site. It’s a little basic and unwieldy, but it works.
In EE3, the equivalent display adds page titles, which is nice, but the display is paginated, with 20 pages per display, and this cannot be overridden or filtered in any way. Using this display to locate a specific page in our site structure, which in EE2 required only scrolling, now requires potentially a large number of clicks and page loads. There’s no way to jump to a specific place in the structure, and no way to filter the page display. This makes the Pages management display significantly less usable for me.
In addition, despite there being an option to display nested URLs in the Pages module, I’m not able to make them display in that way. (If this is something I’m doing wrong, please ignore! I’ll work it out. If it’s a bug, it would be great if it could be fixed).
Obviously, an alternative method I can use to locate specific pages is via the Edit menu for the relevant channel, but this is also limited in the case of our site. Page titles do not in themselves show site structure, and there’s no overview of the Page URLs defined for the entries in each channel — it’s necessary to open up each entry individually to view its Page URL. This is therefore not usable to obtain an overview of site structure.
I’m aware that there are third party add-ons that might do some or all of what I’m looking for here. My argument would be that this functionality belongs within EE proper, and basically is already part of EE proper. Sort of. It just needs to be integrated more fully, and fleshed out. EE is quite rightly marketed as a CMS for large, complicated sites. The Pages module can provide key functionality for such sites — and does so for our site. Please don’t treat it as an add-on.
I have some specific requests with respect to the above, which would make the Pages module in EE3 more usable, and which I think/hope are practical. The key issue here is being able to see an overview of the structure of static pages. Roughly in order of usefulness:
When listing the entries in a particular channel, if any of these entries have Page URLs assigned, add a column which displays the Page URLs, to provide an overview. Allow the entries to be sorted by this column, so page structure can be seen. (In some ways this is a more practical addition than changing how the Pages module itself behaves, because it’s already focused on a specific channel). This avoids having to open each entry individually to see Page URLs. Ideally, allow Page URLs to be nested, as well as sorted.
In the Pages module management itself, allow pagination to be turned off, so the entire structure of static pages can be viewed, as was possible in EE2. (This is already possible in EE3 when listing channel entries.)
In the Pages module management, add an option to sort by URL by default, rather than by page title.
In the Pages module management, improve display of nested Page URL structure.
Thanks for listening.
Paul Bailey | [email protected]
Hi Paul,
It’s an add-on because EE’s soul is to not be “page” driven. EE3 brings you the ability to limit each channel to 1 entry as well.
I think in your case having a Channel for each of the 10 site sections would make complete sense.
Pedro: “I think in your case having a Channel for each of the 10 site sections would make complete sense.”
Thanks for the reply, Pedro. I have a separate channel for the static pages in each major section of the site (in addition to six channels used for the more traditional dynamic content — news/blogs/etc.). Sixteen channels in total. The problem here isn’t that the content isn’t suitably organised into distinct channels.
But a number of the site sections (and corresponding channels) are quite large. I just counted, and the largest is 77 active pages (and a number that aren’t currently active), each of which has a URL defined using the Pages module. What I’m missing is really an effective way to see an overview of the URL structure of a section/channel such as this.
The Pages module (or add-on, or whatever) exists, and is an excellent tool to create the sort of static page structure, with semantically meaningful URLs, that I want. I’m hoping to argue for two things:
In the wider scope of things, I’d like to see the Pages module more fully integrated into EE proper, and not considered an awkward hack. For me, and I imagine for many others, it’s an effective and central part of the design of page structure.
Specifically, I’m suggesting some simple changes which, even with the Pages module remaining as an add-on, would significantly increase its usability:
- In the overview of entries for each channel, display the Pages URL in a new column, and allow sorting using this column. This would avoid the need to open each entry individually to see its URL, and provide a clear overview of page structure.
And/or:
- In the Pages module itself, allow the very restrictive 20-page pagination to be removed or customised. As it stands, the pagination makes EE3 much less usable for viewing static page structure than EE2.
Paul
Pedro is correct that ExpressionEngine by design does not think of content in terms of where it lives (pages). One of the primary benefits of ExpressionEngine is that it has always explicitly been a content-driven CMS rather than a page-based CMS. This is the most flexible, future-proof approach that ensures your content is reusable regardless of what happens to delivery technologies.
You might notice that our documentation says that if you are using the Pages module to manage more than 10 pages, the Pages module is probably not the implementation you are after. It’s not meant to handle how you are using it, and I don’t foresee our vision for the Pages module changing much in that respect, even if we solve some of the display issues you’ve raised above, which I agree could and should improve. Have you looked at Structure? I think it’s probably the right tool for how you want to manage your content.
Aside: “Channel” is also an add-on, so there’s no lesser class by that term, it’s just the nomenclature used for the various components of the system, which is modular in nature, so no worries there!
Thanks for the reply, Derek. I appreciate it.
Derek: “Pedro is correct that ExpressionEngine by design does not think of content in terms of where it lives (pages).”
Sure, yes, but there (obviously) does at some point have to be a mapping from content to public-facing structure. These are quite rightly seen as two separate things. I’ve always been a big fan of the flexibility of how EE can handle internal organisation of content — it was a big part of why I chose it going on 10 years ago.
I don’t want to just rehash stuff I’ve said earlier here. The site I manage uses various ways of mapping content to structure. About half of the site is time-ordered blog/news content, which EE handles very naturally. The other half is a pretty complex structure of static page content. The basic EE way of using template structure to create public-facing page structure just doesn’t/wouldn’t support the deep structure I have. It gets me part of the way; the Pages module gets me the rest of the way.
To be clear, I’m absolutely not arguing that a one-to-one mapping from channel entry to static page URL should be the only way of creating structure. That would be incredibly limiting. But as one option among many, it’s useful, and very much so in my case — which is probably a larger site than most. My assumption is that I’m not the only developer in this position.
Derek: “You might notice that our documentation says that if you are using the Pages module to manage more than 10 pages, the Pages module is probably not the implementation you are after.”
Yes. I’ve been aware of this as long as I’ve used EE, and for all this time the Pages module has been the implementation I’ve been after — albeit with some limitations, as I’ve discussed. I’ve never had any technical issues with using it for a large structure of static pages, and it’s provided the right tool for the job. If EE provides a more natural way of doing what I want, I’m missing it.
I’ve always been a bit baffled by the presentation of the Pages module as a hack to be avoided. No, it’s not the right tool in all situations, but there are situations it’s just right for. I can only imagine that you’re thinking of sites much smaller than mine, or structured very differently. Using the Pages module doesn’t undermine any of the other ways that EE provides to map content to structure. It just provides additional flexibility.
Derek: “Have you looked at Structure? I think it’s probably the right tool for how you want to manage your content.”
I have, and I’m considering it, but very reluctantly. I really like to run a very clean install, with as few dependencies as possible. Depending on a third-party add-on for what I use as a core functionality is something I’m not enthused about. The point I’m hoping to make here is that I genuinely think the functionality provided by the Pages module should be part of EE proper, as one option among many for mapping content to structure. Also, that that could happen with relatively few, and relatively simple tweaks.
Derek: “Aside: “Channel” is also an add-on, so there’s no lesser class by that term, it’s just the nomenclature used for the various components of the system, which is modular in nature, so no worries there!”
I agree that the terminology is a bit of a red-herring here. But, FWIW, in 3.5, “Channel” isn’t listed as an add-on. The Pages module still is, among other add-ons which are genuinely not central to the EE functionality.
Okay, I’ve probably made as much of a case here as I’m likely to be able to. Absent thinking of the Pages module in very different terms, would you be willing to consider the couple of changes I’ve suggested above?
Add an option to include a Pages URL column in the channel entry listing, to allow an overview of structure defined using the Pages module
Relax the pagination in EE3 for the Pages module management, and maybe provide some additional filtering options.
Thanks.
Paul
The Pages module still is, among other add-ons which are genuinely not central to the EE functionality
True, I should have been more specific. Channel isn’t listed because it is not optional. The only add-ons we list in the Add-on Manager are ones that can be installed/uninstalled. But they are all “add-ons”, and the designation in that table just means that it’s not enabled unless you need it.
Pages module in very different terms, would you be willing to consider the couple of changes I’ve suggested above?
I’ll bring your first bullet point up to the team for consideration. The second one is likely a bug, as our other tables have filter tools that would allow you display more records per page.
Derek: “I’ll bring your first bullet point up to the team for consideration. The second one is likely a bug, as our other tables have filter tools that would allow you display more records per page.”
Great. Thank you. Really appreciate it.
Paul
Derek,
Sorry to nag, but could I follow up on this:
“I’ll bring your first bullet point up to the team for consideration. The second one is likely a bug, as our other tables have filter tools that would allow you display more records per page.”
Is there any chance of any of the suggestions I made for the Pages module going anywhere? And were you able to identity whether the lack of filtering functionality in the Pages module display is a bug?
Thanks.
Paul
Hey Paul, it is indeed a bug, and is in queue to be addressed in a future ExpressionEngine release.
Hey Paul, it is indeed a bug, and is in queue to be addressed in a future ExpressionEngine release.
Great, thank you.