No matter which solution you choose, beware of the technical debt you incur along the way. Sam Hernandez says it well:
When choosing a CMS, compare technical debt. The more it does for you, the greater the future debt (real dollars) #eecms vs #drupal
— Sam Hernandez (@sam_h) June 13, 2013
Posted on Jun 17, 2013 by Ryan Irelan
Luke Wilkins (he’s a developer at Vector Media Group, one of our amazing site advertisers) built a Sublime Text plugin that makes it easy to build ExpressionEngine add-on starter files.
The Sublime Text package walks you through inputting the information needed for creating the add-on type you choose and when you’re done you have the base add-on package built for you. Pretty cool stuff.
After choosing your Add-On type, you will be asked for the relevant pieces of data to get things set up. From there it’s just a matter of adding your logic to the generated Add-On! You can refer to the Expression Engine Docs for more details on Add-On development.
In the event that you wish to add a new Add-On type to an existing Add-On you’ve created (for example, you’ve created a module and now want to add an extension), simply go through the process again with the same Package Name and path and the plugin will allow you to automatically merge that in.
It’s available on Github or you can install it right in Sublime Text.
Posted on May 23, 2013 by Ryan Irelan
EE 2.6 has some improvements with how it handles dates and time.
First, there’s no more messing with choosing whether or not you’re observing Daylight Savings Time. EllisLab says:
With the new PHP version requirements for ExpressionEngine, we were able to take advantage of more modern date handling techniques to eliminate the DST setting all together. All you will have to do is choose your timezone and we’ll take care of the rest.
Because of the new PHP version requirement we also get an enhancements in the Date field that allows relative dates to be used. Things like: “noon tomorrow” or “last day of january.”
Read all about it in the EllisLab blog post.
Posted on May 01, 2013 by Ryan Irelan
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
Imagine you were to build a house. After all the years of building web sites and being a slave to “the man” the pay day has finally come; you’ve sold out and you’re finally gonna hire a contractor to design and build you the house of your dreams (or your wife’s/husband’s/whatever’s dreams). You want to get everything; all the bells and whistles anyone could ever want in a house. Doors and windows and all the other house “things”. No expense is spared and it’s gonna be a marvel of engineering to be proud of.
And then you decide to build it on top of a swamp that floods every year with intermittent droughts, earthquakes, tornadoes, and hurricanes, and wasps and mosquitos. And bed bugs. And that really gross smell tanneries have hanging around. That too.
This is what a lot of web developers do. It’s really weird when you think about it too. They spend so much time putting together their project, crafting the perfect solution to whatever problem they’re trying to solve, and then just throw it up onto any old web server that’s not equipped for it. A website needs a literal solid foundation. A home to live and work that is as specific to it’s needs as possible. Yet so many web developers just throw the site up on a host and consider the project done.
The big problem is the fallacy that “all you need is PHP” a lot of clients (and devs) have in their mind. It’s not really the client’s fault though; how could they understand the nuance of using a tool like ExpressionEngine, that’s built with a PHP framework like CodeIgniter? Nope, the problem lies with us, the web developers. A lot of us just don’t know what the hell’s going on with the server.
PHP, by itself, is pretty lightweight. If you want to display a simple PHP script that connects to a database, compiles information about something, and then display the HTML, using native inline procedural PHP is pretty efficient. It’s also time consuming, likely to be insecure, tough to maintain while keeping ones joy and sanity, and just an all around pain in the ass. So, smart developers use frameworks like CodeIgniter (the framework used for ExpressionEngine).
As a programmer, frameworks are great. They’re pretty much the antithesis of the above. As ExpressionEngine is to building a website, frameworks are to building tools like ExpressionEngine. Most frameworks take security seriously, are easy(ish) to maintain, and are a pleasure to work with (or at least make an attempt to not be an absolute pain). But it usually comes at a cost; performance. It’s a given rule that any time you use a framework you’re going to need more server resources made available to your program.
The biggest reason for this is because frameworks just have a lot of PHP files that do a lot of complicated stuff behind the scenes. Pretty much everything is abstracted and object oriented and polymorphic and buzzword, buzzword, buzzword. It’s a lot of processing. And when you take into account that PHP is an interpreted language that has to compile the PHP on every request it starts to add up.
To get around dealing with the large number of PHP scripts a framework all but requires a PHP Opcode Cache (or PHP Accelerator). An Opcode Cache is a PHP module that takes your PHP scripts and caches the compiled bytecode so later requests don’t have that overhead. For those that don’t what that means, suffice it to say that using a PHP Opcode Cache will improve your PHP performance by, in my experience, anywhere from 60 to 90%. This is serious improvement I’m talking about. More than that, it’s also the most cost effective in terms of time investment and overall implementation pain.
For example, the process of getting setup is ridiculously simple using the Alternative PHP Cache (APC). On my new Ubuntu VM, it was literally 1 command:
Email
Comments
Post to Twitter
Post to Deliciousaptitude install php-apc
That’s it. I run that single command on my server and all my ExpressionEngine sites are running at an average of 4MB on the homepages and at a tenth of a second request time using APC (down from 25MB and 1.5 seconds).
In terms of PHP Opcode Caches, I have 3 personal favorites (though there are lots of others): APC (obviously), eAccelerator, and XCache.
APC is the one I’m currently using for my server. Not because it’s the best Opcode Cache out there but because, as the above demonstrates, it’s crazy simple to get up and running (I’m lazy) and my current needs don’t require more than the “good enough” it offers.
The really nice thing about APC (outside of crazy simple setup) is the maturity. It used to be implemented by Facebook (who also contributed to the project) and has been endorsed by the the people behind Zend. In fact, APC is supposed to be integrated into the core of PHP no later than 6.0 (though I think they’ve moved this to 5.5 though I could be wrong).
eAccelerator has been around for about 9 years now and is my go to when shaving a couple extra MBs of memory matters. The performance return on eAccelerator is really impressive and in my experience it gets no better. eAccelerator is also the Opcode Cache use by cPanel and WHM managed servers (by default) which I think says a lot.
The big downside to eAccelerator is that it’s sort of a pain in the ass to get setup on the command line though. It requires building things custom to the platform and it also needs to be rebuilt every time you update PHP. Definitely an advanced option.
XCache is a really nice Opcode Cache in my experience. For Windows hosting it’s an absolute must and I’ve used it in production on quite a few projects. Setup is simple and straightforward and I have yet to experience any issues on installation. The performance gains are similar to APC though it does depend on what you’re doing and how it’s being done (both work differently so some things work better on one and not the other).
I have had issues with it though. I’m not entirely sure what the root cause of the issue was/is but with Zend Framework based sites XCache didn’t work out quite so well. It’s been a couple years since I’ve used it so this may be a non issue.
There are lots of other techniques you can use to improve the performance of your PHP site outside of an Opcode Cache but none can give you the return quite like it. Adding things like MySQL query caching, or memcached, or a number of other things can help improve things further but you’ll never get the return like on an Opcode Cache.
One thing to keep in mind is that an Opcode Cache can also become a crutch. It’s crucial that one not be used during development. If what you’re building needs an Opcode Cache in order to function you’ve likely made some serious errors elsewhere. Using an Opcode Cache during development will hide this from you and possibly hurt things later.
For production though, an Opcode Cache is an absolute requirement. If you have a dedicated server you’re sort of on your own in terms of implementation. Google is your friend. Things like “Ubuntu install eAccelerator” will do you good (or whatever OS you’re using). For managed hosting though, just send an email to your host and ask them to install the Opcode Cache you want. You’ll be seriously amazed at the speeds and footprint of your sites.
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
Posted on Apr 30, 2013 by Eric Lamb
Something is going on over at EllisLab. It’s obvious that they’re excited about the upcoming release of EE 2.6. The usually quiet, introverted company has been proudly touting their release and confidently sharing through updates on their website.
There are have been a handful of small announcements recently about EE 2.6 and its new features. There’s one big new feature that I thought they would hold out until EE 2.6 was ready to launch, but they couldn’t keep it a secret.
Today the update is available for everyone.
The new native multi-relationship field is a little like Playa by Pixel & Tonic; there are two panes and you can add related entries by clicking them in the left and they appear on the right.
Unlike Playa, you can’t drag and drop between the two panes. To remove an already related entry you have to explicitly click the “x” on the far right of each related entry. Similarly, to reorder them you have to use the grippy area on the far left. Playa offers a much easier way of interacting with the related entries: reorder by clicking and holding anywhere on the entry, remove with a simple double click (in addition to drag and drop or using the arrows between the two panes).
I prefer the aesthetic of the Playa. It is more polished and a nicer user experience. But the new native relationships field copies many of the settings and functionality of Playa. The native field type will get it done for some people the same way that the Rich Text Editor does.
EllisLab had to make this addition to the CMS. Was it a direct shot at their new competitor (Pixel & Tonic is building their own CMS called Craft) and an attempt to cut into their sales of Playa? Or did EllisLab finally realize that they need to start innovating the CMS and adding features that arguably should’ve already been there?
It doesn’t really matter which one it was. Both are strategic business moves. The former will definitely rub people the wrong way because Pixel & Tonic’s add-ons help make ExpressionEngine a more attractive CMS. The latter reason will get praise because we’re all relieved that things are moving forward again.
There will always be people who will be unhappy no matter what happens.
The first step to resuming innovation for EllisLab is to play catch-up with the third party add-on community. When innovation stalls, others will do it for you. That’s what Pixel & Tonic and dozens of other add-on developers have done. EE sorely lacks in many areas but our talented group of third party developers have jumped in to fill the holes left by EllisLab’s stagnation over the last few years.
When others beat you to innovation then you’re forced to cede that feature or risk looking like a copy cat. Neither is good but EllisLab surely knows that they’d rather look like a copy cat while serving their customers than continue to lose control of innovation on their platform.
Posted on Apr 23, 2013 by Ryan Irelan
In Weaning Yourself Off jQUery James Halliday shows how you can use just JavaScript to easily do what you might be using jQuery–and it’s overhead as a library–to do.
As programmers build up applications up from lots of tiny components, if every component included a vendored jquery version, the total javascript size quickly baloons into multi-megabytes. When the jquery version gets pegged, version incompatibilities arise that likewise create redundancy issues. When the jquery version is left to float or its use is demanded externally in the documentation, this also does not scale well and makes it cumbersome and error-prone to use tiny pieces.
Posted on Apr 19, 2013 by Ryan Irelan
A good tip to a web service that helps you test about email sending while building an EE site.
So you need to test and debug email notification templates while working in your local environment. You still need to verify mail is being sent and inspect the email contents. You might create a few accounts with email addresses you own, which I guess works on a small scale. But let’s say you need to test bulk mail delivery, or maybe you’re working with a preexisting member list of thousands of accounts. Even though you’re working on a local server, the email addresses are real and if you mistakenly trigger a bulk mail function, you’re going to end up with some very confused users. Of course you’re already bootstrapping your EE setup with the Focus Lab conifg overrides right? We’ll be using MailTrap.io to isolate and display sent emails from our dev environment.
What follows are a few quick steps on getting set up with Mailtrap.io in ExpressionEngine. The service is currently free for everyone.
Posted on Apr 17, 2013 by Ryan Irelan
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
When working on your average developer tool, a tool to help developers do their jobs as opposed to an add-on or script to add features, you can’t help but obsess over the meta. Normally, a lot of this stuff is just second nature, and rarely given more than a cursory thought, but with tool development, like the EE Debug Toolbar, you just can’t help it.
Take, for example. the question of “high quality in web development”. A couple months ago I had mentioned high quality as making sure “nothing was off about a project”. Not the best definition and certainly open to interpretation. Now that I’ve had some time to think about it I believe I have a better definition for what I consider a quality ExpressionEngine site to mean.
When building out a web project there are 5 points that have to be covered completely for a project to be considered of high quality in my opinion. They are (in no particular order):
All things being equal, this one’s easy and the one most people can achieve. Does the project do what it’s intended to do?
Now, I say this one’s easy because with a tool like ExpressionEngine (and to be fair, lots of other platforms too) its whole purpose of being is to make doing things trivial. And it does do it pretty well. Say what you will about the problems ExpressionEngine may or may not have but it does allow web developers to do some useful things with minimal effort.
That said, nothing can make a project good if the plan is poor. If the list of features isn’t compelling or interesting to users it doesn’t matter how well done the other parts are.
Where things fall apart for those projects with a good feature set is with the other 3 points though.
Things have changed dramatically in the last decade in terms of security and web development and ExpressionEngine does it’s part to make that easy for a lot of situations. (Lots of newbie devs will never appreciate the sheer terror in coming into the office and feeling the odd sense of shame and revulsion over what some script kiddie did to the network. It’s a shame…)
But all this is still at the platform level. Using extra tools like Securit:ee, VZ Bad Behavior, devot:ee Monitor, and all the other security minded add-ons at devot:ee you can improve ExpressionEngine’s security even further. But there’s nothing stopping devs from doing insecure things in the development of their project.
Just a couple base example questions to ask yourself:
Obviously a lot of this stuff is dependent on the project but my point is that security needs to be taken seriously and as an actual “thing” before quality can be claimed.
This one is obviously close to my heart at the moment with the EE Debug Toolbar reaching maturity. Minimal Fingerprint refers to performance and how hungry a site is for system resources.
This is basically the below points for most sites regardless of platform (my personal goals in parenthesis):
Having a secure and kick ass feature set for a site means nothing if it takes 20 seconds for pages to load.
Another thing that gets over looked far too often is how well a site performs “under load”. It is two very different things for a site to work gangbusters with no visitors and no data, but another altogether when the site is under the expected load and expected data set. Knowing (and planning for) this before pushing live is critical for a quality project.
It should be noted that performance is one of the rare exceptions where you can just throw money at the problem. Hardware’s cheaper now than it’s ever been so if you don’t have the time, inclination, or skill, to actually improve on the actual product you can always spread the site out across a load balancer or dedicated database server (or whatever) to help with performance. Definitely an advanced strategy though and not to be taken into lightly and one that’s extremely dirty to go into except as a last resort.
For those of us who have been around the block a few times, this is the really important determination of quality. How difficult is it to make changes/updates to the project? A tool like ExpressionEngine offers much more than just CMS capabilities; it also adds in longevity so long as a little care is taken. There is no reason for a website to have to move platforms just to change the design.
Think of it like this: You got hit by a bus/quit your job/decide the client isn’t worth it. Whatever. Basically, you’re just gone. Now. Are all those clever hacks, nested embeds, template partials gone made, spaghetti code, dynamic variables ({{var1}_{var2}_thing} anyone?) and copy pasta going to make growth and change a problem? Is the developer who takes over once you’re gone going to want to find your grave, dance on it, find a shaman and resurrect you, only to torture you for eternity because of the assault against nature you’ve created? In my experience, more often than not, yup, we’re gonna do some grave dancing and cursing.
Knowing the history on this it makes sense why maintainability would be an issue.
Tools like ExpressionEngine and WordPress and all the other CMS systems out there (and PHP and ASP and Perl before them) make creating websites well within the reach of the average enthusiast and the early successes can lead to a great deal of confidence. Enough confidence to think it’s a good idea to put the old shingle out and be open for business. Unfortunately, it takes a while for these newly christened developers to run into maintenance as an actual issue so they never think about it until later in their career.
Creating a maintainable site, that can scale to change with ease and logic, is of the utmost importance for quality.
Clients never think about disasters and failures when it comes to their websites in my experience. In over eleven years of doing client driven web development I don’t think I’ve ever had a client bring it up except for a couple occasions. That’s why it’s imperative that we (the hired devs/agencies) keep this in mind and set the client up for success.
In a nutshell; what is the plan when things go wrong?
Now, outside of complete website development, disaster recovery isn’t really something that needs to be considered as a constant todo. But, for those projects that are complete sites or those with maintenance contracts (at the least), disaster recovery is an absolute must in order to claim a project as high quality.
Some agencies/devs like to charge for this as an extra line item, and more power to them but, personally, I do not.
First, disaster recovery plans are incredibly rote and straightforward at this point. There’s very little mystery involved. Software wise, it can range from free (Backup Pro(ish), Safe Harbor Lite, and even shell scripts at the server level) to barely 0.004% of a small project budget for an automated backup solution.
Second, when something does go wrong I like to have the confidence I can fix things. Knowing what to do in the event of an emergency is just good sense.
Third, the client can say no. This is the big winner. It’s a tough sell to get a client to think about disaster recovery when they’ve likely never even heard of the possibilities. Worse, in my experience, some clients even get the idea in their head that you’re trying to “nickel and dime them”. It’s a very awkward thing, especially considering the absolutely minimal overhead involved in crafting a plan. No, best to just absorb that cost and look like a bad ass when something goes wrong and a solution isn’t a problem.
For me, it’s very important that all five items receive equal treatment wherever possible. I say wherever possible because when it comes to each of those items, it’s a rare thing when improving one doesn’t change the other. The key is to make your decisions with eyes open as to the full consequences.
For example, improving security on a website will, more often than not, increase the performance costs. Conversely, improving on performance can have negative effects on maintainability (especially with ExpressionEngine), while feature set takes away from maintainability, fingerprint, and security.
It’s a constant back and forth game of whack a mole but one that’s absolutely critical to play in order to build high quality websites.
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
Posted on Apr 16, 2013 by Eric Lamb
Michael Witwicki put together a nice set of tips for communicating support requests and issues with developers.
ExpressionEngine add-on developers (species: Codeignitus Developus) are a unique breed. Should you encounter one in the wild and need support, here are some tips get your question answered as quickly as possible.
His list is specific to ExpressionEngine add-on developers, but the approach is useful for any interaction you have with people who make the software you use.
Posted on Apr 15, 2013 by Ryan Irelan
Today EECI announced that Low’s add-on development class will also be taught in Portland this Fall at EECI 2013.
Portland 2013 will include Low’s how to build an Add-On class for us on this side of the Pond. #eecms
— EECI Conference (@eeciconf) April 9, 2013
Besides being a kind soul and all around wonderful person, Low is also a great teacher. Being able to break down difficult concepts into smaller learnable chunks of information isn’t something everyone can do. Low can do it. And he does it well.
If you’re at all interested in learning ExpressionEngine add-on development, you should definitely keep an eye out for Low’s class this Fall at EECI in Portland.
Until then, he’s teaching at EEUK in May. If you can’t attend that conference, Low also did a 75 minute video tutorial on ExpressionEngine add-on development.
Posted on Apr 11, 2013 by Ryan Irelan
Yesterday I released a new video at Mijingo covering all of the basic concepts of using Git version control for web projects.
Basics of Git by Ryan Irelan clearly explains all of the basics of working with Git for web projects. It’s for Git beginners but it’s for those of you who have already been using Git but aren’t sure why you stage, commit, push, pull, branch, and merge. In 54 minutes, Ryan gives you the foundation you need.
Here’s a quick teaser video of what’s covered:
Git–or some type of version control–experience is quickly becoming a must-have when looking to land a job or work as a freelancer with other teams. This video will give you the foothold you need to get started.
Learn more about Basics of Git
Posted on Apr 11, 2013 by Ryan Irelan
Jacob Graf asked on Twitter what your workflow is for redesigning a site is live and running on production.
What’s your workflow for completely redesigning #eecms site templates while still keeping the production site up and running? Excluding VC.
— Jacob Graf (@jacobgraf) April 6, 2013
How do you do it?
Posted on Apr 11, 2013 by Ryan Irelan
Cole Henley is asking for your input:
#eecms folk - do you tend to use snippets or templates for embedded reusable components (e.g. page header or footer)?
— Cole Henley (@cole007) March 29, 2013
Some good replies already. It’s a simple question but everyone has different reasons for why they do things. What’s yours?
Posted on Apr 02, 2013 by Ryan Irelan
On April 9th, Kyle Cotter (former EllisLab intern and employee, former blogger on this very site) will be teaching a one-day class called Building Flexible Sites with ExpressionEngine.
The class will cover EE history and approach, the Control Panel, building a dynamic site and more. It only costs $75 for 6 hours of training and lunch is included.
Posted on Apr 01, 2013 by Ryan Irelan
John D. Wells found himself up against the almighty Parse Order:
Once again I’m shaking my fists at the impossible hoop-jumping gauntlet that is the ExpressionEngine Parse Order. This time I want to pass the result of an Advanced Conditional as a value to a module tag parameter. It’s been long said it can’t be done. It’s time to change that.
John found a work-around that includes some built-in EE functionality and a third-party plugin. I don’t want to spoil it here, so you’ll have to read the entire write-up to see his technique.
When I teach the Parse Order to students in my EE training classes, I try to give examples of where the Parse Order could bite them. This is one that I haven’t used but will now add John’s write-up as something they should read.
Posted on Mar 31, 2013 by Ryan Irelan