FastCompany.com redesign is powered by Drupal

We'll definitely make an effort to release as much as possible back to the community - we are developers after all. :-) At the core, most of the work begins with contrib modules already on drupal.org (simplefeed, views_fastsearch, logintoboggan, usernode, am, just to name a few), so there's not a ton to be contributed for some of those. Most of the contrib modules provided a good basis - things started moving in the right direction - but didn't make it possible to achieve all - or in some cases even much - of the desired functionality, so they were tweaked or overridden in a multitude of areas to fulfill the needs of FastCompany. Other modules (things like the nodecluster module which the Lullabots developed and we simply helped flesh out and then utilized, and the asset manager (am) module which underwent a massive overhaul as we streamlined it based on our experience) are things that will, I'm sure, make their way in to drupal.org as soon as we possibly can. Many things are just customizations specifically for Fast company, important visual changes or organizational modifications that took time to develop, but aren't of great benefit to the community so probably won't be released since they probably wouldn't ever get used again. Know we'll do everything we can to turn around the modules that make sense to release, and we'll try and help develop patches for some of the other modules that proved to be a bit more difficult - or an absolute pain in the @$$ - with which to work so all of this is a tad bit easier the next time around!
--
William O'Connor
Achieve Internet + Lead Developer

that looks marvellous

This is neither a core hack nor a contrib module. There are probably a dozen or so ways to do this, and, in retrospect, some of them may have proven easier overall, but in this case it's mostly just theming away elements we don't need - basically the username - in such a way that the system won't complain immediately. After the post, we re-assemble the username as we need after the page has been submitted and store everything as normal. It's not one of the cleanest areas to work with, but it gets the job done without hacking away at core or replicating too much code.
--
William O'Connor
Achieve Internet + Lead Developer

The LoginToboggan module will allow your users to log in using their email address. However it doesn't amend the initial registration form.

--
Ixis (UK) providing Drupal consultancy and Drupal theme design. Check the portfolio.

I'm working on trying to put together a few articles about some of the technical details of various modifications. Some of the modifications are mundane - a lot of theming forms and theming lists of elements for display - so they don't really lend themselves to a good article - except maybe as a call to simplify the theming process - but some of the module development, the difficult spots, and the tweaks we provided to existing modules are worth exploring, in my opinion. I'll try and turn around a few of those articles over the course of the next few weeks giving a little more insight into some of the development on fastcompany.com.
--
William O'Connor
Achieve Internet + Lead Developer

Looks like the newsletter system is external, and written in JSP - the subscriptions to newsletters have a confirmation url of /newsletter/manage.jsp?email=xxxxx@xxxx

Drupal has a fairly stable SimpleNews module to do similar things.

--
Ixis (UK) providing Drupal consultancy and Drupal theme design. Check the portfolio.

but it really just provides an interface to hook into outside providers (like lyris). We just provide a simple table that holds all the list names we're interested in, and another one to manage subscriptions (on/off) per user. When a user subscribes or unsubscribes we make an external call to lyris to stay in synch.

--
AchieveInternet
http://www.achieveinternet.com

I didn't see a list of modules, so I couldn't really say whether or not it is alot of modules, or not that many.

Great, sharp looking site. I can only imagine what is under the hood.
Really like the simple and effective "search corner" along with main navigation. Trully speaks 'business'.
Inspirational work!
All the best!

Fast Company is running Drupal version 5.7. Now that Drupal 6.0 has been released aren't your clients expecting a conversion to it? How are you handling this issue with your clients given that some of the contributed mods of the current site (I have not looked) may not work in version 6.0?

The Mansueto Digital team is pretty plugged in with the Drupal community (they're now hosting NY area meetups, among other things!) and they've been watching the D6 news, too. They're looking at D6 as something great on the horizon that will be an important part of future upgrades, but not something to dive into lightly.

It's the approach I'd recommend to anyone. ;-) For the moment, D6 is most exciting for module developers who want to take advantage of its capabilities, and folks who are just beginning to put together plans for sites that will be started soon.

--
Lullabot! | Eaton's blog | VotingAPI discussion

Sites only get upgraded when they need to. It is good to plan future versions into your web application roadmap, but there is no knee jerk reason to upgrade a Drupal site except if a version is no longer supported by security, for example.

Another reason might be that new / better functionality is available in a newer version, and thus the cost / benefit of an upgrade makes that worthwhile.

Thanks for sharing. That's a sleek designer look.

subscribed

How is drupal itself for you? For me its very fast.

And drupal has very high traffic.

I don't know what makes alexa so dependable or how stats of one site makes a software/script not recommendable. ( And so far only one post by you, that also to say this :))

Site speed depends on the host, ded or vps or shared : even a good shared host provided it has its cpu resources and other specs well organized can run a drupal site with high traffic quite nicely.

Alexa's traffic stats are taken over time, and don't necessarily reflect the current state of any given site. FastCompany.com has been working through some performance hiccups since its launch, and some insights into the specifics -- as well as how they're being solved -- might be useful for others planning large-scale rollouts.

Drupal's core combined with popular modules like CCK and Views has proven very scalable. Whenever a large site grows, though, hot spots are found and have to be dealt with. The challenges with FastCompany are primarily a handful of third-party modules that have inefficient queries, and drag down site performance overall. Replacing a number of those third-party modules with more efficient custom code has been an important task for the FastCompany team, and performance has improved considerably. Anyone looking to build a large-scale Drupal site should carefully check out the code of the smaller/more obscure modules they're looking at using. Many are good, others work fine on small sites but drag when they are deployed with hundreds of thousands of nodes and millions of page views a day.

Drupal's built-in search system is the other fundamental bottleneck that's being worked on for the site. The default Drupal search system is one of the best built in search systems for any CMS, but it's still not as strong as a dedicated search engine like Solr/Lucene or the Google Search Appliance. The FastCompany.com site makes extensive use of searching and filtering (finding other users on the site with similar interests, that mention keywords in their profiles, etc...) and that puts quite a bit of stress on the built-in search system. This is exacerbated by the use of Views Fastsearch, a module that lets Views tie into the search system as well. It's very powerful, but it also multiplies the performance pitfalls in Drupal's core search.

Quite a few optimizations have been rolled out recently on FastCompany.com, and a secondary database server is planned to handle the search load without slowing down the rest of the site. Moving forward, the FastCompany team is also exploring the use of Solr/Lucene so search indexing and querying can be handled by a dedicated server rather than putting more load on the normal database and web servers. Most large scale sites use that approach; the relative strength of Drupal's core search made it possible to put off that step, but has proven too limited to use long-term.

At a high level, these are the kinds of issues that must be dealt with on any growing site and any web framework/system. It's important to assess Drupal's strengths and weaknesses for each project, but making sweeping generalizations about any system based on one data point is a recipe for misunderstanding.

--
Lullabot! | Eaton's blog | VotingAPI discussion