UI

The UI of ExpressionEngine is, how do you say, unflattering. Many EE newcomers are often coming from Wordpress, which in our opinion has a great UI, but EE’s is a little less refined (and a lot more pink).

For us, the EE Admin homepage is not the center of our content management needs. As a matter of fact, I don’t think we’ve used any of the controls found on the page, even once. Seriously. Yes, this seems like a pretty big UI and UX problem, but in reality it doesn’t matter that much; just don’t think you’re “missing something” if you don’t find yourself using it.

Through the use of override stylesheets, EE allows developers to tweak the styling of the Control Panel, and while the native theme of the control panel is decent, we like it to look a little more professional and polished. Levi Graham’s Override.css does a wonderful job with that.

Settings and Configuration Variables

EE has a plethora of configuration variables which can be modified in the control panel. General Configuration Settings, Localization Settings, Channel Settings, Channel Field Settings, Member Group Settings, Template Group Settings, etc. there are many to learn and they are all found in various parts of the Control Panel. Having so many configuration settings is good and bad. Its great that EE is so flexible and lets you configure to your hearts content, but it also makes it important you review each of these settings during your site’s development.

One thing to note is that EE lets you add configuration variables into your config.php file. By placing configuration variables inside the config.php file, most of the settings found inside the control panel can be overwritten, which centralizes the location of all of these settings and lets you set them based on conditions you specify in business logic.

An alternative to placing your override settings in config.php is Levi Graham’s Bootstrap Config file. This bootstrap file specifies most of the settings you can manually set and also allows you to set environment specific variables, for those of you looking to run EE on multiple environments (local, development, production). One exception to overwriting settings is with setting File Upload Directories. Unfortunately this is not possible, however, it can be somewhat managed using this technique.

Add-ons

Like many pieces of software, ExpressionEngine was built on the idea that third-party developers should be able to extend the core functionality of the system. By creating an architecture allowing developers to quickly build custom Control Panel interfaces, and creating hooks which developers can use to access pieces of core codebase, EE has turned from a content management system into a robust framework for building web applications.

Add-ons play a major role when estimating EE projects and figuring out technical implementations. There is always a debate on whether it is good or bad practice to use Add-ons, but in our builds, we always have a fairly large number helping us out. When scoping a project, always do a quick Devot-ee search to see if the functionality you are looking for has already been built, and if there is anything you can use to help your own build. While we are big proponents of using Add-ons in most of our builds, it should be said that there are some bad Add-ons out there. Bad: meaning the add-on was developed poorly, with bad practices causing poor performance; or Bad: meaning it brings in a piece of functionality that could have been done more efficiently using native EE methods. Whenever you are thinking about using an Add-on always do a little research to make sure it’s the best option.

Conventions

When I first started writing templates in EE I was finding myself getting frustrated having to remember which fields corresponded to which Channels (e.g.: is the {content} tag the content of my blog or the content of my calendar entry?). The simple solution is to namespace your Channel Fields and use naming conventions for your Channels and Field Groups. Typically, we have a 1 to 1 relationship between Field Groups and Channels, but not in all cases. In most cases we try and make the Field Group a singular version of the Channel Name, which is in-turn a pluralized version of the Field Group’s name. For example, the channel Blogs will have a Field Group name of “Blog.” In regards to namespacing individual Fields, we always start the field with the name of the Field Group and then add the name of the field after. So in our Blog example, if we had a field that held the content of the blog, our field name would be “blog_content”.

Another area where we see a lot of discrepancy is in the way people organize their templates. A major component of the way EE works is facilitated by the way templates are organized into Template Groups. In most cases, each page of the site is located inside its respective template group, but what about for template partials or other included templates? For us, we follow the necessary convention of adding all pages into their own template group, and for partials we have a few places we put them. Each of the headings below represents a template group which we use to hold various partials across our site.

Site

For partials that contain our header and footer content areas, as well as our site’s home page index.html file, we add those templates into a template group called “Site”. This template group may also have more general partials such as “Sidebar”, but only if they are included on nearly every page of the website.

Partials

Partials that are very small, say an included ad or a piece of code we are abstracting to avoid variable collisions, we will put these into the template group “Partials”. Normally these are not full pages, but other pieces of content or larger content areas.

Native Template Groups

All pages of a website go into their own template group. Also, if a page has components that are only used on that specific page, we will often times put those pieces in this template group as well. For example, if we have a page called Blogs and each blog entry has a list of social media links, we may put that list into its own partial inside the Blog template group.

Lib

Often times we need to access EE data via an ajax request, or we have a partial that is used solely to return data. In these cases we put templates into the template group Lib (short for Library).

side note: This last section is not intended to recommend you move all repeated code into template partials. Even though we do find ourselves doing that often, performance always needs to be kept in mind. Each time you use the {embed} tag, EE loads the Template Parser on that specific template file, and if you have lots of embeds it can significantly hinder page load time and performance. When you are deciding how you want to organize your templates, always keep performance in mind and don’t over abstract if you don’t have to.

URL Routing + Organizing Content

A big divide in the EE community is if you stick to the Template Group / Template method to route URIs and organize your site, or do you use the Structure module, which hijacks the native URI routing and uses its own hierarchical routing method. We fall somewhere in the middle of this divide; sometimes we stick with the native Template Group based routing and other times we use Structure.

The pros of using the native method is that its fairly straight-forward and does not rely on an additional add-on which you then also have to maintain and keep tabs on. The cons is that sometimes the native template group / template pattern is limiting, for example if you have a very deep site that requires sub-pages and sub-sub pages.

Structure is great if you have a site that is very content heavy, and you need to allow the client to manage different content types and organize the pages of the site. Another added bonus of Structure is that it provides a great Control Panel home page alternative. Instead of sending them to the awkward native admin home page, you can send clients to the Structure module landing page immediately after logging in, which allows clients to edit the majority of the content on the site.

Another routing alternative we have been playing with recently is Freeway, an extension built by Doug Avery which lets you specify URL routes similar to the way routes are handled in Codeigniter or Rails. In Freeway, you specify the URI you want and point it to the template group and template you want it to load. This is a fantastic alternative to the native method of handing url routing because it allows you to write custom urls and is also less intrusive than the structure module.

A Few Quick Tips

Lastly, here are a few more items worth checking out which we did not explicitly mention above:

• ABO (Always Be Optimizing) EE has a number of nuances that can quickly take a bite out of your site’s performance, such as using conditionals and embeds the wrong way. Sometimes its hard to remember all of these things, and the best way to manage your site’s performance is to make it visible when developing. We place this code snippet in our header file which displays the number of queries and page load time, each time the page loads. It will only be shown when logged in as a Super Admin, which means normal site visitors will not be able to see it.

EE Page Speed Helper Code

• Simple vs. Complex Conditionals EE has its own version of conditional statements using if tags. One thing most new users don’t realize is that EE will still parse and run code that is in the if:else block even if it does not get rendered on the page. Not knowing this can significantly hinder performance.

Using plugins like Switch-ee or If-else works around the native implementation and lets you keep your templates running efficiently and under control.

• Understand Parse Order EE’s tempting system is very complex and has somewhat of a high learning curve. When I first started using EE I had lots of problems getting my actual tags to render the correct content, but after reading up on the parse order of things, many of my troubles were solved.

• Read up on building EE Add-ons Even if you are somewhat capable of writing PHP, you should take a look into how EE plugins are written. Instead of turning on PHP inside your templates to perform simple logic, often times it makes sense to just add that logic into an Add-on. We have a few custom Add-ons that don’t serve one specific piece of functionality, but contain a bunch of helper methods to perform minor adjustments or changes to template code. Also, some developers have taken it one step further and create generic extensions that they use to insert global variables or other data into the templates. Matt Weinberg at Vector Media Group brought this to our attention at the last EECI and we’ve been using it ever since.

Comments