DesignDivine Project Blog

WordPress automatic updates are awesome. When they work, they’re as easy as a click of a button. When they fail, however, you’re left either reconciling yourself to an eternity of manual updates, or troubleshooting your host–a process that routinely takes much longer than applying the update manually would’ve.

In this case, my VPS was running IIS 6 and the updates weren’t working. First, the update screen would merely say it was downloading the new version, and it would never make any progress. Then, when I extended PHP’s max_execution_time, I encountered a FastCGI internal error saying the process exceeded the configured activity timeout. When I corrected that, WordPress reported permissions errors while trying to move the new files into place. My full solution was as follows:

Backup Everything

Any time I’m updating anything; download a full & current copy of the site, and export all tables from the database.

Fix the FastCGI Timeout

Open \WINDOWS\system32\inetsrv\fcgiext.ini, and, in the section labelled PHP, add ActivityTimeout = X, where X is the desired number of seconds after which to terminate an unresponsive script. Restart IIS.

Fix Permissions

Much like how apache is often configured to run as “nobody” in order to prevent malicious scripts from modifying files, IIS (by default) runs as a user named IUSR_[hostname], where [hostname] will be a string you set up when initially configuring your site. Unlike apache, however, on IIS, 777 permissions don’t necessarily mean any user is permitted to write to a given file or directory.

To fix the problem I had to open up my web root in IIS, and give my IUSR_[hostname] full permissions. I was then able to run the update, after which for security purposes I reduced that users permissions to the original level.

My name is Alex and I’m a a reality TV addict.

Hi, Alex.

I admit my guilty pleasure and embrace it. My favorite show is Project Runway, because it neatly sidesteps most of the Real World-esque drama and focuses on the creative process. Truth be told, I’m probably more of a creative junkie than a reality TV addict but, either way, I’m not giving up my TV anytime soon.

What does this have to do with web design?

Watching the fashion designers create clothes made me reconsider my own process for designing websites. Here’s what web designers have been doing for quite a while now:

• Meet the client and chat about needs
• Write up a proposal to summarize the project
• Draw up wireframes and a site map
• Design the website in Photoshop or Illustrator
• Show the design to the client and get revisions
• Redesign the website in Photoshop or Illustrator
• Repeat the last two steps (sometime ad nauseam) until the design is finished
• Build the site using HTML, CSS, Javascript and possibly a Content Management System
• Show the design to the client and get revisions
• Rebuild the site
• Repeat the last two steps
• Get final approval
• Launch the site

A lot of that time is spent designing a flat image for the client to look at and try to imagine as a finished site. It can be hard to explain how a scrolling image gallery, randomized testimonials, or a navigation menu works just using images from Photoshop.

Designing in the browser

I’m a big fan of Andy Clarke and the growing movement of web designers who advocate designing in the browser. If you’re not familiar with the concept check out the lovely Meagan Fisher’s Make Your Mockup in Markup and Mr. Clarke’s original article that started all the buzz, Time to stop showing clients static design visuals. The basic idea is that instead of spending all that time designing in Photoshop and explaining your images to the client, you do the meat and potatoes of the design work with HTML, CSS, and Javascript. You still plan the site, create wireframes, and spend a little bit of time in Photoshop, but when you show the proof to the client it’s a functional website. This helps nip a lot of questions (like “what happens when I roll my mouse over the menu?”) in the bud. A functional website is easier to explain, it can (sometimes) be easier to revise, and if you got it right the first time you’re already 80% of the way there.

Designing in the browser isn’t for everyone, and there are certainly times to avoid it. That said, I think we’ve been avoiding it out of habit instead of necessity. As front-end development languages mature, designers are getting more and more options for creating visual effects using pure code instead of slicing images. CSS3′s support of RGBA/opacity, rounded corners, border images, box shadow, and text shadow are just a few examples of new enhancements. When you throw in the growing options for displaying fonts on the web and the jQuery UI library you’re not too far away from having access to all the tools you know and love in image editing software. Well, maybe that’s a stretch, but you get where I’m going.

So what does this all have to do with Project Runway?

In each challenge, the designers are given a set period of time to create a new outfit from scratch. Out of ten hours to complete the challenge they’re only allowed 30 minutes to sketch, the rest of the time is spent buying the fabric and working with the actual material. As web designers, we spend a massive amount of time sketching. It sometimes feels like we only work with the actual fabric (read: code) as an afterthought. If you compare web design to building a house it makes sense to draft that many blueprints before breaking ground, but the costs of starting over on the code isn’t equivalent to starting over on a house (thank god). Working with the code is more like re-draping the fabric on a dress; it’s something that benefits from being worked with instead of over planned. I think most craftsmen would laugh at the idea of drawing 30 sketches for a product before actually working with the materials involved, but that’s not unusual for web designers creating mock ups of multiple page sites. While I believe good planning is essential, I think we’ve got to remember our materials aren’t expendable and that our code is only limited by our time, training and imagination. Get your hands dirty sooner, and let the process of working on the actual site (instead of static visual proofs) inform the design decisions.

Either way you do it, “make it work.”

Further Reading

If you want to learn more about designing in the browser, I recommend reading Andy Clarke’s Walls Come Tumbling Down and Smashing Magazine’s great dissenting opinion, In Defense of Photoshop.

A VPS is the standard upgrade when conventional shared hosting won’t meet your needs. The catch, and most hosts try not to make this clear, is that you’re then on the hook for all configuration, upgrades, and maintenance. And as an added bonus, many hosts offer default VPS installs configured as though they’re deliberately trying to make administration difficult.

For a recent project hosted on one of our VPSes, I was planning to use Kohana, which requires PHP5. Despite the fact that PHP5 was released in 2004, it wasn’t installed on the VPS in question. As the VPS was running Plesk, any changes to the PHP installation would have to be made carefully so as not to demolish our hosted sites, but research revealed the Atomic Rocket Turtle Repository, designed exactly for upgrading machines such as mine. Except that yum wasn’t even installed.

The procedure was as follows:

Install yum

Note: If you’re following along at home, instead of just copy pasting my terminal commands, you should probably make sure your rpm -Uvh calls are requesting contemporary versions

First, install a key from the CentOS mirrors so rpm will work:
rpm –import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-4

Then, try and fail to install yum in order to get a full list of missing dependencies:
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-2.4.3-3.el4.centos.noarch.rpm

Next, install each listed dependency with a call to rpm -Uvh

Finally, install yum by re-running the rpm command above

(based on instructions here)

Set up the Atomic Rocket Turtle repository

wget -q -O – http://www.atomicorp.com/installers/atomic.sh | sh

Upgrade PHP

yum upgrade php

Reinstall Ioncube Loader

(Note: As we weren’t using the Ioncube Loader, everything worked without this step. Except that we were getting notices in our logs saying it was missing.)

yum install php-ioncube-loader

Set up new (default) php.ini

mv /etc/php.ini /etc/php.ini.php4
mv /etc/php.ini.rpmnew /etc/php.ini

Restart Plesk

/etc/init.d/psa stopall
/etc/init.d/psa startall
/etc/init.d/psa restart

Miraculously, Plesk restarted successfully and all my applications were fully functional under the new install of PHP5.

I could’ve stopped here, but because the VPS had been running for a few years, and yum hadn’t been installed, I knew that basically everything (if not literally everything) on the server was out of date. Research and testing aside, the above took less than 10 minutes. The below (upgrading everything) took several hours of troubleshooting.

Upgrade everything server-wide

yum upgrade

(Note: This might take a while. I made sure to archive the output, because when anything goes wrong, the clues will show up here.)

Set up new MySQL configuration

(Note: At this point, Plesk wouldn’t restart because MySQL (just upgraded from 4 to 5) was totally broken.)

mv /etc/my.cnf /etc/my.cnf.old
mv /etc/my.cnf.rpmnew /etc/my.cnf

Install new Plesk package to support openssl upgrade

(Note: Now MySQL worked, but Plesk was still broken.)

If you update from an old vesion of openssl, you’re probably going to run into a bug, the quick solution to which you can find here.

Update MySQL databases

(Note: Plesk would restart, but I couldn’t log in.)

mysqlcheck –check-upgrade –all-databases –auto-repair -uadmin -pyouradminpassword

Compared to WordPress’s automated self-updates, Drupal’s update process is something of a chore. This chore isn’t made any easier by Drupal’s documentation (also here), which at the time of writing takes up nine pages, is self-contradictory, unnecessarily time-consuming and somewhat paranoid. And it never offers a canonical pragmatic checklist.

After reading all the documentation I could stand and going through the process a number of times, this is the protocol I’ve developed for myself:

1. Make sure all your modules are compatible with the new version

If they aren’t, you should deal with this before the update, not after.

2. Back up all the files, and the database

If anything goes wrong, I need to be able to revert to a known-working state. This also serves as a useful archive, in case anything goes wrong with the site between updates.

3. Put the system in maintenance mode

This will prevent any visitors from potentially encountering a scarily-broken web site before you’re done upgrading.

4. Create a temporary folder, and move all the existing files in there

Don’t want to run the risk of overwriting anything important (especially .htaccess or /sites). Alternately, you could delete your whole site and then re-upload, but this is faster.

5. Upload the new version of Drupal

6. Replace the freshly installed /sites/all folder with the old one from your temporary directory or your backup

This should restore all modules and themes. You’ll notice that I haven’t disabled any modules or themes prior to the update: I only work with custom themes, and so far none have broken in an update. I try to use as few modules as possible on any given site, and always check to ensure essential modules are compatible prior to an update.

7. Move /sites/default/files from your temporary directory or backup to /sites/default/files.

You might need to change the permissions on the old /sites/default/files to do so.

8. Reconcile /sites/default/settings.php

Compare the old /sites/default/default.settings.php to new one. If they match, you can just move the old /sites/default/settings.php to the new /sites/default directory. If they don’t, you need to open the old /sites/default/settings.php, copy /sites/default/default.settings.php to /sites/default/default.settings.php,
and migrate all settings to the new /sites/default/settings.php we just
created.

9. Reconcile .htaccess

If I’m getting Internal Server Errors after the update, it’s nearly always because I missed something in this step. Compare your old .htaccess to your new .htaccess, and make sure to migrate any changes over. For me, this nearly always means enabling RewriteBase (to support pretty urls), and ensuring Drupal runs under PHP5 (required by many modules).

10. Run update.php

This will upgrade all your database tables to the new version.

11. Take the system out of maintenance mode

12. Visit /admin/reports/updates to make sure everything is ok there

13. Verify functionality

We  spent some time trying to remove a nasty bit of malware code from one of my client’s servers today.  On their windows server, this virus used javascript to create a list of invisible links (in an i-frame) to bugged websites in the page footer.  On their Unix/Linux accounts, the virus added redirects to .htaccess files which will send you to similar sites.  It also adds a nasty bit of javascript just after the header tag.

Webmasters, you may want to check the code on your index pages to see if anything unusual is lurking there.  From my research, it sounds like this was a client side security issue with the Chrome browser.

We received another inquiry this week regarding Drupal website maintenance — that was enough to get us motivated to learn the basics of the CMS system. We installed Drupal on our new testing site: www.websitedesigndenver.com, and we will be experimenting with the application over the next couple weeks. Feel free to take a look, but don’t be surprised if the whole site is down . . . hopefully we don’t bring the internet down with us.