Drupal development

There is perhaps no other Drupal-related issue which commands so much attention from site admins, Drupal developers, and Drupal core alike, as the subject of Drupal updates/upgrades.

The Players

Site admins typically want to have the 'latest and greatest' version just for general purposes. This is, of course, very understandable, all other things being equal.

Drupal developers like to be able to keep up with the latest release for various reasons: a) to take advantage of new features, b) to keep their skills current, b) because their clients want it, c) as any bonafide geek knows, it's alway fun to check out the new toys.

Drupal core is always concerned about Drupal updates, well because...it's Drupal core. The project and Drupal itself is dead, or at least frozen in time, if it ceases to innovate at semi-consistent intervals.

It's been a couple weeks since we posted part one of our look at optimizing a Drupal site to withstand large amounts of traffic,
and since that time it happened again - a site we host, got "Farked" (an inbound link from Fark.com) even bigger than it did last time. In the 8 short hours since the link to the client's site went up, and as I write this - the site has received 27,000 + unique viewers. When I logged in there to the site there actually were 1850 users online at the same time.

We just about fell out of our chair when we saw that...

...after all this is a site is that's on a shared server - not a dedicated one. And those kind of numbers would even give some dedicated servers a thorough workout. In the meantime, it was operation 911. Forget the long term issue of finding a larger server space for this site which clearly is outgrowing it's enviroment - that could be handled afterwards. Right now, we had to get the server and site back pronto.

Recently we had the pleasure of developing a very cool intranet for a group associated with the United Nations. They desired an online space within which they can privately share articles, comments, and files with each other.

Our mission was to make a site that would:

• Not let anonymous users view any content
• Enable varying levels of viewing, adding, and editing rights across differing authenticated user roles - on a per page/node basis
• Enable different/custom menu configurations based upon user role
• Redirect users after a successful login attempt to a front page which is unique to user role

If you have never used Drupal before you may not know that the above functionality is not available out-of-the-box. However, with a little research we found some contributed modules which helped us to achieve a totally customizable intranet:

• front page
• login destination
• menu per role
• nodeaccess

(This article is made specifically for showing how to get raw content into Drupal, but the methods below can likely be adapted for other use cases [we also imported a list of users using these techniques for instance].)

Importing raw content into Drupal, can be, well let's just say it's not always easy. In two years of experience with Drupal we've imported a MoveableType site, a Blogspot site, content from one Drupal site to the other, and now raw data from a csv file (raw meaning that it did not come from some other CMS/website), and we've used everything from custom scripts, several different Drupal modules along the way including import-exportapi.module, userimport.module, nodeimport.module, WordPresstoDrupal.module.With the exception of the WordPresstoDrupal.module we've been mostly disappointed with the results of our experiments with the Drupal based import options. That said, this may not be the best method to start off with if you can find a ready-made solution that works for you, since it is somewhat time consuming.

Besides being a somewhat complex thing to begin with, the issues around importing content into a Drupal installation are exacerbated by the wide array of variables any point and click solution has to contend with. It's impossible for any module developer to be able to keep up with the number of different/custom Drupal content types for even one version of Drupal, let alone for all new versions of Drupal.

In short, for the serious site-operator/Drupal developer getting raw content imported to Drupal is always going to be a problem because one size is never going to fit all (the 'bad' side of such a customizable platform). This is important to understand in order to fully appreciate the workaround below, which is not particularly easy or fast, but is 99.9% reliable from a data integriy standpoint.

Here are links to some of the finer examples of many different site types, nationalities, big sites, smaller sites, and notable, as well as not-so-notable, companies/agencies/people who all have one thing in common. They are powered by the Drupal CMS.