It’s been a while since anyone has written an updated tutorial on deploying ExpressionEngine site with Capistrano. Matt Fordham created a tutorial on just that topic.
Capistrano is a Ruby tool that makes deploying any kind of website (including ExpressionEngine) a piece of cake. Put simply, it allows you to run a simple command in your local dev environment that in turn executes a more complex series of commands on a remote server (via SSH), such as deploying a website. Capistrano also makes rolling back to a previous version of the site a relatively easy thing.
Capistrano’s rollback feature is what makes it so appealing to me (although I stopped using it in favor of the simpler deployment tools from Beanstalk).
Matt has a very detailed walk-thru, including a video and all of the configuration and commands you need to get started. Using Capistrano requires SSH access, so it might not be an approach for everyone.
Previous Capistrano/ExpressionEngine coverage: here, here, and here.
Over in the EE Forums, add-on developer Low proposed a new and better way to handle upload file paths when moving between server environments.
For us devs, working on local, staging and live environments of the same site is quite common. We can use the config.php file to set config items like Theme path or Template path based on the environment. This gets harder for file paths stored in the database, like File Upload Destinations. Making these relative like ../images/uploads/ kind of works, but only if you’re uploading from the CP.
Low proposes a solution that uses a base_path config variable that you can set to the actual path based on server environment.
Do you have a different idea? Want to add your support to Low’s proposal? Be sure to chime in on the forum thread.
If you were following along on Twitter, you might have heard about the 4-day long process that Ryan Masuga went through moving his EE add-on repository and storefront, Devot:ee, from EE 1.6.9 to the latest version of ExpressionEngine 2.
Because Devot-ee is such an important resource to the community, Masuga wanted to be as open and transparent as possible about the upgrade. He provided regular updates via their Twitter account and even detailed some of the problems he was running into. This long and tedious process was, unfortunately, taken by some to mean that upgrading a site from EE1 to EE2 is a messy process that takes 4 days.
I think Paulo Elias put it nicely:
I am puzzled at all of the negative “upgrade process’ tweets re the recent @devot_ee upgrade. Complex shit takes time to get right
Indeed it does.
According to Ryan, Devot:ee consisted of a lot of third party and custom add-ons. Every single one had to be updated and tested. Some of those were mission critical add-ons for e-commerce and other functionality that supported their business of giving add-on developers a place to easily sell their software. Ryan plans to eventually publish his log of what he had to do to make the upgrade happen.
I asked Ryan if he would spend a few minutes talking to EE Insider about the experience of upgrading a complex site like Devot:ee, what he learned and, most importantly: was it worth it? He obliged and below is a transcript of some of his answers during that conversation.
EE Insider: When did you start the upgrade process? There was probably a lot of planning that happened.
Ryan Masuga: We started in March and I wrote down every step because I knew that we had to do it all again in a final sweep to get any data we might have missed. Other client work got in a way, so it wasn’t like this was the only thing we were working on. We set it aside for weeks.
Was there one thing that you spent the most time working on?
RM: I spent a lot of time…on the sales reports for the developers because they need to be accurate.
The plan was to update Devot-ee over the weekend. Did you have a master plan?
RM: I ran through the 20-point checklist and it just didn’t work out that way. I thought the smart thing to do would be to make a static site first so people could still search. I set that up as a subdomain and checked out a branch that just had everything disabled, basically. You could still search the site, you could still download your stuff. You could do everything except buy stuff, really. I think that lessened the pain of our site being officially down for three or four days because people were able to, essentially, use the catalog. However, I was planning to be down maybe eight hours or something like that because I was taking my time with checklist.
When you were running the EE update wizard, were there any problems?
RM: I had zero errors going from 1.6.9 to 2, which was pretty wild. And then it was all about upgrading add-ons. Matrix, Cartthrob, Better Meta., converting Better Meta to NSM Meta, Favorites, Low Variables, Channel Ratings and then converting Solspace Ratings to Channel Ratings.
We spent a lot of time adjusting PHP in our templates and in our custom add-ons. [The extended downtime] had to do with that peripheral stuff.
Why didn’t you leave the site up and use a staging server, get everything upgraded and just flip the switch?
RM: We had to put a content freeze on the site…
Because of sales…
RM: Yeah, because of sales, rating, favorites, reviews…
And sales being the most critical.
RM: Yeah. We don’t want to recreate any of that stuff or merge data if we don’t have to. We ended up being down 4 days and we would’ve had to recapture 4 days worth of data from an EE1 database.
Was the upgrade and downtime worth it? What does it mean for Devot:ee going forward?
RM: The good work and the time [the community developers] are spending is on EE2 stuff. There are so many cool things out that we couldn’t use. I love Zenbu. I like Switchboard. None of this stuff was available for EE1, so it’s making my life easier in the Control Panel. The Control Panel seems nice and quick.
I know that EllisLab is putting a lot of dev time into EE2 and it’s just going to get better. We need to be there [on EE2] so we can take advantage of all of the stuff that EE2 provides.
And at some point if you wait too long the two versions of EE and any add-ons would be further apart and the upgrade would be even more difficult.
RM: Absolutely. We would be like a boat lost in the night with no paddles. Where do we go from here? We would be so far down a hole that we are basically going to have to rebuild the site rather than upgrade. Now we’re at a point that we’re at the latest of everything.
Now, it’s causing a couple of problems because we had some template syntax that needed to change but on the whole, it’s going to be better for everyone because we can make full use of SafeCracker. That’s a big part of the site because people can submit and edit their add-ons.
So now you can develop new features for the site without worrying that one day you’ll have to go back and redo everything for a big upgrade.
RM: Yep, we would try to keep new stuff to a minimum because we would have to do it in two places. We got a huge feature request list and stuff that we want to do. We want to vastly improve the image galleries on an add-on page. There are way too many clicks and it’s just lame. It takes the height of the highest image, adds a bunch of whitespace…it’s just kinda weird. We get a lot of emails about it. “Hey, we just want a previous and next button so I don’t have to close each one.” We can spend time on that stuff now without having to do it twice.
Thanks to Ryan for chatting with us. He’s inspired me to work on upgrading EE Insider to EE2.
Jamie Rumbelow posted the first part of a series he’s doing on covering the finer details of the ExpressionEngine 2 config file.
Configuring ExpressionEngine is a black art; the layout of configuration values in the control panel isn’t particularly well thought out. Some values are on one page, others are on a different page, and the whole thing needs much more logical grouping.
Additionally, storing configuration in the database has its own set of downfalls: deploying sites is a real pain because DB values need to be updated and some of them are even encoded in the database. Accessing and modifying them quickly becomes cumbersome.
Thankfully, EE can be configured through an alternative method. You can override pretty much any configuration value in ExpressionEngine in the expressionengine/config/config.php file.
A nice walk-thru of a simplified and cleaner config file. Another great how-to on this is Matt Weinberg’s multi-server config setup for ExpressionEngine 2.
Read Jamie’s full write-up: Getting to know ExpressionEngine 2’s config file - Part 1
I love Beanstalk. We use it at Happy Cog and I use it on my personal projects (like this site). Their deployment tool is easy to use and because it uses (S)FTP, you can deploy to any server.
Christopher Imrie at moresoda tweaked EE Beanstalk deployments a little with an add-on that empties the cache after a new deployment:
This can present a slight problem when you have enabled caching on your ExpressionEngine powered site, since the system will be unaware of changes to any templates since they are being served statically until the cache expires. ideally we would want ExpressionEngine to refresh its cache after each Beanstalk deployment.
Hence we use a small in house add-on that utilises Beanstalk’s “Web Hooks” feature. Web Hooks are simply web addresses that Beanstalk will send information to before and after each deployment. Our add-on places a script at the location of the Web Hook, which in turns instructs ExpressionEngine to delete its cache.
Read more about it and download the add-on: ExpressionEngine Beanstalk Web Hook Addon
I’ve often talked about MAMP here and how you can use it to easily localhost your EE site while it is under development. For those of you on Macs and using MAMP, here’s a nice tool for you to try.
While browsing the MAMP.info website the other day, tucked down at the bottom of the page, I noticed a tool I had not seen before: MY MAMP DUMP. Despite the funny name, MY MAMP DUMP is a small set of Automator workflows that allow you to easily (it prompts you for the information it needs) import and export databases with MAMP.
Screenshot of MY MAMP DUMP workflow.
The download comes with two workflows (one for export, one for import) and two application versions of those workflows. If you already use Automator to, well, automate some of your processes while migrating EE sites, this might come in handy.
As an aside: if you haven’t tried Automator yet, I think you should. It’s an easy way to make some of your mundane tasks faster and more efficient. Just one example is how I use it to automatically resize images for this website by dropping them in a folder on my desktop. I could further extend that by having Automator upload them to my s3 account. With shell script, applescript, Finder and tons of application support, there’s a lot you can do with it.
I just finished reading a great article from Doug Avery on Viget Inspire about running ExpressionEngine on Multiple Machines. They do a lot of things very similarly to how we do them at Happy Cog: Keeping everything in version control, everybody running the site on their local machines, and a heavilly modified config.php.
It will be awhile before I ever tire of seeing smart people write about how they do their group ExpressionEngine setups (famous last words).
There’s a lot of good info in this article, especially if you’re toying with the idea of getting a setup like this going. Right away, I downloaded the PHP scripts that Doug linked to for database management. I’ve long wanted to simplify that process. I also wrote a comment on the article, suggesting some possible changes to the config.php to make it even more location-aware.
Go check it out, it’s a good morning coffee read. If, that is, you like coffee and ExpressionEngine geek talk.
One of the highlights of the EECI conference for me was Jamie Pittock’s (Erskine Design) presentation on “How Erskine Rolls” when developing websites on ExpressionEngine. His talk was packed—from beginning to end— with great EE development tips and a bit of the funny for which the Erskine crew is known.
Jamie made his slides and materials available for download; he even included a sample path.php file, config.php file and some template components. There could be a book written on the material Jamie presented, so it’s worth your time to go through the slides and follow along (even better, you should buy the EECI 2010 DVD that should include Jamie’s talk).
How Erskine Rolls with ExpressionEngine (ZIP file)
Mr. Pittock, my hat is off to you.
Twit-ee, my favorite Twitter module, has been updated to 1.3.1. The updated now includes the home timeline tag recently added to the Twitter API. What is the home timeline?
Returns the 20 most recent statuses, including retweets, posted by the authenticating user and that user’s friends. This is the equivalent of /timeline/home on the Web.
Git is all the rage these days and Devot:ee has written a very in-depth article about version control with ExpressionEngine and Git. Why version control, Mr. Masuga?
Version control is something I felt I needed a handle on when developing with ExpressionEngine, so I recently starting looking for a solution I could use in my own workflow. Up until very recently, I’ve been working on projects myself (except for the occasional contractor who has helped migrate or enter content into EE while I’ve been working on the template side) but now I’m finding the need to do some collaborative work, and also want to make sure that my work is properly backed up and versioned—so I can roll back changes if something goes awry.
This is the first in a four-part series that, if continuing at its current depth, will be extremely informative and educational for our humble community.
Stephen Lewis of Experience Internet has been writing an excellent series on using ExpressionEngine with Git.
...I’ve yet to see a proper discussion about best practises for managing an ExpressionEngine site with git.
This series of posts is my attempt to fill that gap, by documenting how I use git to manage ExpressionEngine websites. My goal is to start a conversation on this topic, from which we can all (myself included) benefit.
The series so far is divided into three parts:
There’s more to come in the future, and we’ll be sure to post about it when they’re published. This is an excellent series by one of EE’s best extension developers.
Tired of copying sites via (S)FTP and then editing files directly on the server? Do you wish you could keep a current snapshot of the site files in a safe version control repository and then deploy out changes as needed?
Well, Hivelogic’s Dan Benjamin has written an exhaustive tutorial on how to deploy your ExpressionEngine websites with GitHub and Capistrano (a deployment tool created for deploying Ruby on Rails sites).
Here’s Dan’s summary:
Many people are familiar with the advantages of using Git and GitHub to manage their projects and source code, but deploying an ExpressionEngine installation for deployment in this way can be a bit tricky. This article details the Capistrano recipe I’ve created specifically for automating the management and deployment of an ExpressionEngine website, with provisions for maintaining uploaded content across deployments, omitting unwanted content from the repository, setting the correct permissions, and more. The recipe also handles creating the server-side directories you’ll need to accomplish these tasks in a completely automated way.
Go expand your EE toolbelt and deploy your sites in a powerful way!
While helping a colleague with an Multiple Site Manager issue on MediaTemple, I came across this thread in the EE forums: How-to setup the MSM on Mediatemple’s DV 3.0.
User “nek4life” wrote up some clear instructions on what you need to do to get up and running with the Multiple Site Manager. Essentially, you need to disable a couple of PHP options to get things working.
Hopefully anyone that is a customer of MediaTemple and runs EE MSM will find this helpful at some point.
Email
Comments
Post to Twitter
Post to Delicious