Template organization is indeed a basic, "entry-level" concept with regard to ExpressionEngine development, but given the number of convoluted and disorderly site builds that we've inherited over the years—and continue to encounter—it's a topic that still warrants discussion.
Among our more extreme examples, one such project stored all 60+ of its templates in a single template group. Another had a whopping 37 template groups and nearly 200 templates—among them five slightly different variations on a simple header embed.
Overkill? You bet.
But those are rare cases. The more common scenario is a site like this one, which we recently rebuilt and reorganized in such a way that it would be more sensible and user-friendly for the client. It began as such:
That's a very reasonable number of template groups, and they're appropriately named in such a manner that we were able to make accurate generalizations about the contents of each folder. This started to fall apart, however, when we opened pages.group and found that there were nearly 60 templates in that folder alone! And many of them (37, to be precise) were embeds, while a handful of others—likely unused, in which case they should have been deleted—bore names such as careers_test.html or contact_test2.html.
To the front-end user, of course, these problems were likely invisible; but from a development perspective, it's important to build and maintain sites as cleanly and logically as possible. As it stands today, the Foster Made process for our standard site builds (which we continually discuss and refine as a team) adheres to these basic template groups:
Contains elements associated with user-facing actions such as saving, printing, bookmarking, ecommerce, etc.
Contains forms that would not otherwise be included within an existing page template or layout file.
Contains site-wide embeds.
Contains layout files.
Contains elements associated with user-facing messages such as email notifications, etc.
Contains templates assigned by modules such as Structure or Pages.
Contains the site's index template.
Contains site-wide search results/no results templates.
Additionally, in ExpressionEngine's Template Manager, we'll take the time to organize these groups alphabetically, as they will display in the file system. While it's true that we rarely (if ever) edit templates through ExpressionEngine itself, the Template Manager can be a great tool for quick troubleshooting and evaluation, and having the template groups alphabetically arranged certainly makes things easier—especially on larger, unwieldier projects.
Obviously, several of our recommended groupings are entirely optional—if not infrequent. Not every site utilizes custom actions, messages, or even search. In fact, a standard, bare-bones site build may consist of little more than:
Whereas others that may combine (or forego) Structure with fully dynamic, traditional ExpressionEngine templates may include additional folders for a calendar, resources, and so on.
In any case, we also try to keep the files within these template groups as clearly named as possible. For instance, within _page-templates.group one might find:
While _includes.group could contain:
It's understandable, though, that so many sites suffer from varying degrees of organizational adversity. It can be easier said than done. After all, there are exceptions to every "rule." If, say, the home page uses an embed to list out the five most recent blog posts, and that embed is not used anywhere else on the site, it would make perfect sense to store that embed within the home.group folder rather than the _includes.group folder, and so on. At the end of the day, we just continue to strive for a clean, simple, less-is-more type of approach as often as possible.
So, where did we land with our latest rebuild, as cited above? Within a matter of days, we consolidated down from nine template groups and 96 templates to seven template groups and just 38 templates. Furthermore, to illustrate how properly assessing and organizing templates carries over into other areas of development, we were able to delete four unused or unnecessary channels and a considerable 51 unused or unnecessary custom fields in the process.
All of this can have a significant impact on improving site performance and clarity, not to mention cutting down on maintenance efforts—thus reducing the cost of ownership for our clients!