Drupal Install Humps

ThistleWeb's picture

I've been spending a few days immersed in the wonderful world of Drupal and something rather basic struck me. Drupal is an excellent piece of software. While it's intimidating at first, it's actually well designed after you get passed the initial hump. For end users Drupal is very easy to use when the site is set up. So why leave a rather obvious usability hump in peoples paths when they go to install it?

Why do we still need to copy the /sites/default/default.settings.php file and rename it to /sites/default/settings.php? Why is there no empty directory called "files" in the same directory? These would surely be needed in every install of Drupal, so why force the user to jump through these extra hoops?

The same applies with the themes, modules and libraries. When I first started playing with Drupal, I found it rather intimidating. While I'm still no expert, I'm now comfortable with it. I understand a lot more of how things work from a configuration standpoint. The Drupal ethos is a very light, slim, clean core install with some additional functions disabled but installed like Taxonomy or Forum.

You add functions and themes by downloading them from Drupal.org, uploading them to your server and ticking the button in the modules menu. New users looking at the file tree can see both themes and modules, inside which they see folders matching theme names or module names they saw in the administration pages. It's therefor only natural to assume this is the place for both. It's not. These are for core themes and modules only, they should be left alone.

You install your uploaded modules to /sites/default/modules if you want them available for only that site or /sites/all/modules if you want them available for every site running on that single Drupal install. The same applies to themes and libraries with /sites/default/themes etc. The problem is that none of these directories exist, you have to create them yourself. Why? Is there a reason why these folders are not already there? They'd be empty but at least it'd be a clue for those poking about the file structure to find where to install modules to that instructions on drupal.org telling them of a directory actually corresponds to an existing directory.

Do the Drupal devs know of any sites which don't use these directories? The only way that's possible is if the site is built and themed entirely from core. While that's possible, invaluable modules like CCK, Views and Pathauto are not yet in core, neither is spam protection.

There is two stages that I do see a need for however. The /sites/default/settings.php is not writable, so you have to jump back to FTP or SSH to make it writable for Drupal to install. Knowing what this means and how to do it means that you understand the post install message of "please remove write permissions" and what to do. As a security measure I very much see the need for these steps.

It's made me wonder if these steps are designed more as a competency test than anything else. If you are incapable of understanding messages and how to make your install pass them, then you're unfit to administer a Drupal site. These are pretty basic skills that any Drupal admin will do over and over and over again as they build and configure their sites.

The thing is that if they have uploaded Drupal to their site via an FTP client, they've already shown a basic level of competency in downloading the tar.gz file, extracting it, installing an FTP client, signing into their FTP account, finding their public_html folder and uploading the contents of the extracted tar.gz file to it, including the .htaccess file. They know how to right click on a file or folder and get context options, including the ability to change permissions for the settings.php file. Do they need to jump through the extra hoops of creating directories that all Drupal sites will need  too? There may be some very good reasons for requiring these extra steps but I can't think of any.

I've just gotten into the habit of creating these folders in the extracted tar.gz folder before I upload them. I shouldn't have to.

For those reading this who have Drupal installs and didn't have to jump through these hoops, this is the normal Drupal setup with a manual install. Many web hosts have automatic installer scripts like Instalatron which bypass all this and give you an insta-Drupal to play with. Try the manual way and you'll see exactly what I'm taking about.

Ideally you want to get to the stage where all (or most) of the install process happens in the browser. With the permissions changing that's not possible, but there may be a way round it. Think about first impressions however. If a user tries Drupal out, and the very first thing they see and have to fix is a few errors, with file permissions and missing files the obvious line of thought is "I'm just trying to install it, did I forget to upload a file? Was the download corrupted? Did it extract ok? If this is what Drupal is, then I think I'll pass. On the very first screen and I get several errors. Will I be constantly fighting with errors after it's installed?"

People who know Drupal know how good it is, they know it's only an installation hassle that's easy to get passed, but it does not send that message to first time users. Compare that experience to WordPress, MediaWiki, Joomla etc

Drupal 7 is better - sort of

In Drupal 7, you can install themes and modules directly by typing in a URL. The files are automatically uploaded to the right place.

However, I would prefer a browsable theme repository and just be able to click 'Install'.

Bizarrely, for a release that was supposed to focus on usability, usability and usability, yoor observations about the installation process (creating a 'settings.php') are still true.

Also, when you select SQLite as a target database, the MySQL credentials fields are still displayed which is weird.

I've been rather critical of the Habari installer in the past but even Habari 0.7 is much better than Drupal 7.

ThistleWeb's picture

Browsable Theme Repo

I liked that feature in WordPress, the ability to browse addons or themes and install them with a click from inside the adminstration pages. Drupal could certainly improve on that score. I've never tried to install to any other database than MySQL, so I don't know how that works or if there are issues. I'd hope that Drupal and it's modules play nice with Postgres, as that may well be the future.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer