Recently, I’ve delved into CMS development, specifically Expression Engine (EE) development, after being predominantly a Laravel developer for the past few years. I liked some things about EE and disliked others, but overall I can see where a tool such as EE can be leveraged to build very customizable Web sites, and even Web applications that non-developers are able to configure and maintain.
Pros:
- Faster to develop dynamic Web sites than a full framework such as Laravel
- Easy to configure by user.
- Template system is relatively powerful.
Cons:
- Hard to deploy to existing installations.
- Version controlling configuration is tricky.
- Information is lacking.
- There aren’t that many people discussing Expression Engine, and the example code out there isn’t exactly great quality.
Why Would You Use a CMS?
The big reason to use EE over custom coded Laravel or flat files is a balance of speed and configurability. Sites can be developed quickly, but also can be easily configured by end users without having to make any modifications to code. A CMS also allows non-developers to update most or all of what is displayed on a site. Typically, CMSes, such as EE, have many add-ons that are both community created and vendor created, that can be easily installed to extend the functionality of the CMS, which is a big positive because even non-developers can upgrade a CMS-based site without ever touching code.
Thoughts on Expression Engine
It would be nice if, similar to Laravel’s blade templating, a master template could be defined and have placeholder sections where other templates or code can be inserted. In EE templating, every template will need to define the same various sections, typically something like headers, footers, etc.
Iterating through channels and various other grouping mechanisms for entries in templates is quite powerful. There are many parameters available to filter and output, and these parameters can also be automatically grabbed from URL parameters. For the most part the parameters to entry tags are sufficient to output data filtered in any way it needs to be, but I ran into an issue when trying to output more complicated filtered data.
The multiple site manager provided by EE is useful, and allows a single installation to serve multiple sites, that can have shared configuration. Sites can also share data between them, but certain parameters are required by entry tags to specify which site the content is coming from. I found it slightly confusing to manage content on a master site, to affect a sub site, but then use the sub site’s admin panel to manage other content.
The difference between channels, categories, snippets, etc., confused me at first, but after working with them it became more clear how each should be leveraged to do what I needed.
It’s unfortunate there isn’t a tool similar to composer/packagist that can be used to easily find and install open source third-party add-ons as easily as Laravel allows. Composer could probably be used to manage dependencies, but it’s not something built in, and the number of packages for EE on packages is probably fairly low.
Flexibility
EE allows extension through many methods, one of which being modules. Through modules a developer can hook into underlying EE codebase, and write new functionality. Modules can leverage CodeIgniter which EE is built on top of. This means the code gets access to models, class loaders, migrations, among other useful features.
While writing modules for EE, I do feel like I am working to mostly adhere to the constraints of EE rather than building exactly what I desire. When coding in Laravel there is a lot of different ways to approach coding something, and code can be written as framework agnostic and not conform to any particularly Laravel-way of doing things. In EE, modules have specific functionality they can perform, and must be structured a particular way, with only a certain number of hooks into the underlying EE code which doesn’t give complete control to the developer. I’m not sure if this is mostly due to CodeIgniter or EE, but it does feel limiting.
Issues
While the documentation covers most of the functionality, it lacks more extensive examples, and mostly just displays single cases of how functions work. There also isn’t a great deal of information from third-party sources about how to do many things well in EE, and what I could find wasn’t always correct for my version of EE. I found the admin UI a little unintuitive as well, and it didn’t seem as powerful as WordPress.
I found no good way to migrate data from one server to another other than just dumping tables, and setting up configuration values each time. A lot of setup is in the database, which isn’t conducive to version control without some sort of migration/seeding mechanism. When updating an existing site there are challenges for migrating updated database values due to the fact the site being updated has data that needs to stay in place, while adding data for the updates. Usually I updated content on installations manually using the admin UI, but this is clunky and slow. Usually I would dump my database and start fresh, but this also slows things down as anything previously inserted is cleared.
Final Thoughts
While EE does have its benefits, I think a better option is WordPress. EE isn’t nearly as popular as something like WordPress, so it can be hard to find plugins or code examples to perform necessary functions. WordPress for example has thousands of packaged modules that can be plugged in and used to change and configure it to a high degree, and there are countless tutorials online to do pretty much anything with WordPress. EE may be a step up from flat files, and faster to work with than full-fledged Web frameworks, but the lack of community and available add-ons pulls it back from being recommended over WordPress.
About the Author
Justin Hamm is a senior Web developer at Enola Labs, a custom Web and mobile app development company headquartered in Austin, Texas.
