Join 3,552 readers in helping fund MetaFilter (Hide)


Drupal best practice?
July 1, 2009 8:36 AM   Subscribe

I'm starting to work with Drupal. My plan is to build several newsy blog-style sites. I think I have a good handle on learning the framework, but I'm wondering if any Drupal vets have suggestions for avoiding pitfalls or maximizing the good stuff.

As background - I have a strong PHP skillset, and I plan on building some custom modules. I'll likely go with just tweaking existing themes rather than starting from scratch. And I'm hoping to run several sites from one install.

For bonus points, I plan on hosting all this on a managed 1and1.com server. Anyone have insight into Drupal hosting on 1and1?
posted by y6y6y6 to Computers & Internet (3 answers total) 9 users marked this as a favorite
 
The drupal.org forums have a lot of chatter about how specific hosting companies fare. I've had good luck with Site5 for low-traffic sites where I didn't care about occasional downtime, and I've recently migrated to Slicehost. The additional control is great but it also requires knowing your way around a server, so it's a toss-up to some extent.

WARNING: I'm about to firehose a fair bit of advice that may be overkill for you, but it's all good stuff to keep in mind. If you decide not to follow it, think hard about why.

One of the most important things you can do -- bar none -- is use your own version control repository. If you need a minimal setup for the short term, go to unfuddle.com and set up a free account. You get 200 megs of storage an an SVN repository, more than enough for the source code of a site, and issue tracking/basic project management tools.

Whenever possible, do development and testing on your local machine or a separate server. Test the changes, check them into SVN, and use SVN update on the *server* to push the changes upstream to the 'live' site rather than FTPing them or something like that. The ability to roll back to previous versions in case of problems, to run a quick 'diff' against the entire live site's codebase to check for out of date code or inconsistencies... those are all really, really important if you want to simplify the management/maintenance process.

A lot of Drupal's configuration lives in the database rather than in actual code. Did you add a custom content type? Its definition is in the DB. Did you build a View to list the top news stories? Its definition lives in the database, too. If you build stuff locally, you'll quickly run into the problem of trying to 'reproduce' all the steps you took, but this time "for real" on the live server. Whenever possible, do that work in a custom module's .install file. It's hook_install() and hook_update() functions can make your life much easier by automating grunt work.

"Keep as much of your configuration in code as possible" is a big help. If you're using a lot of custom Views (and you probably will be) learn how to export those views to code and put them in a custom module. hook_views_default_views() lets your module keep your custom views in an .inc file where it can ALSO live in source control where it's safe and testable, rather than in the database. If you need to do grunt work stuff like setting up user roles, adding menu items, creating imagecache presets and so on, check out the Install Profile API module. It's not just for install profiles: it's a huge collection of useful CRUD functions for various Drupally things, and it can help you automate a lot of routine configuration tasks.

I did a presentation last year about general deployment/production issues with Drupal and the slides are here, though the notes aren't that detailed.
posted by verb at 10:04 AM on July 1, 2009 [4 favorites]


I just started doing full-time Drupal work about 10 days ago, so here's what I've learned in that time:

- Use existing modules. A lot of general-purpose utilities have been written already, so avoid writing your own code until you're sure it's necessary.
- Checkout existing modules with CVS. If you download and upload via FTP, it'll be more difficult to update later. And you will want to update later, as Drupal is in constant flux.
- Extend existing modules. Most modules are extensible, so you shouldn't often need to edit other's code.
- Use IRC. #drupal and #drupal-support on freenode are full of hundreds of people who can help with pretty much anything Drupal-related.
posted by scottreynen at 11:26 AM on July 1, 2009


I created two sites in Drupal recently, and the first one was my first Drupal experience. The thing that immediately comes to mind that I did differently on #2 was to format things using Drupal's preferences rather than to rely too heavily on the HTML templates, CSS, and PHP (in the Content Template module). So it's easier for those who maintain the site to make updates. At least in my case, those who follow know little html/css/php.
posted by booth at 4:17 PM on July 2, 2009


« Older Do you know of any local bike ...   |  How might I disable or muffle ... Newer »
This thread is closed to new comments.