I first went into my web hosting control panel, and added a new mysql instance. Since the Drupal 6 beta 1 page says this beta version should not be used on production sites. We've resolved most errors reported so far, but there are outstanding known issues in bold letters, I'm not converting a production site (yet). Instead it's a test site on one of the "spare" (unused) domains I own.
Installation steps were:-
- Download the distribution to my web hosting account, and unpack it like so:
506 wget http://ftp.drupal.org/files/projects/drupal-6.0-beta1.tar.gz 507 gunzip -c drupal-6.0-beta1.tar.gz | tar xvf - 508 ls -a 509 mv drupal-6.0-beta1/* . 510 ls -a drupal-6.0-beta1 511 mv drupal-6.0-beta1/.htaccess .
- Visit http://example.com and I'm greeted by the installer screen.
- I filled in database information and answered a few questions. These questions took about 3 browser pages, and the most complex was where it asked for my initial site characteristics like site name, site email, webmaster email, webmaster password, etc. During the process the installer figured out the "Clean Url" setting automatically.
- After answering the last page, I'm brought directly into a working site.
In all the process was as slick as the wordpress install. Very nice.
The next was to visit the administration area. The layout is very familiar. Starting with Drupal 5 the admin area changed layout to be orientated to clusters of tasks. Rather than admin being just a list of modules to configure, it's now oriented to major topics with individual sections within each. This makes it easier to find what you're looking for, and the Drupal 5 organization has been carried forward to Drupal 6.
I went into the modules administration and see some familiar modules and a couple new ones:
- OpenID Allows users to log into your site using OpenID: OpenID is a brand newfangled protocol for distributed authentication and allows for a single-sign-on experience. Rather than require people to remember passwords for each and every sundry website out there, OpenID allows them to be authenticated by an OpenID site, and use that authentication to authenticate with cooperating sites.
- Syslog Logs and records system events to syslog: There's also a companion database logging module, and together these seem to make it more configurable how activities on the site are logged. I know on my sites the slow table is watchdog so I suspect this will help reduce database load.
- Content translation Allows content to be translated into different languages: ?? Don't know yet, but probably a connection to a translation service ??
- Trigger Enables actions to be fired on certain system events, such as when new content is created: From the release announcement: A new Trigger module has been added to core. The Trigger module lets you assign flexible configurable actions to several events happening on your site (eg. send an email when a post gets published).
- Update status Checks the status of available updates for Drupal and your installed modules and themes: This was a contributed module developed during Drupal 5, and has been promoted direct to core because it's so cool. It regularly consults the mothership (a.k.a. drupal.org) to see which modules have been updated, and sends you a nastygram, er, pleasant note saying that your site is out of date and you should update it. This is really helpful in case there are security fixes, for instance, which must be fixed or else.
Next, I've gone to create a blog entry. I'd enabled several modules including Blog and Blog API and Book. The blog creation page looks normal but there are a few new things I see:-
- A button marked Split Summary at Cursor.. eh? I clicked on that and the textarea to enter the body content split so it became two textarea's.
- A form section named Book Outline... In the release notes says the book and forum modules have been reworked, with both being made far more flexible. It appears that blog posts can be put directly into a book now. After you finish creating the blog posting the Outline tab is still there, and performs the same function.
I'm looking in the administration section to see what's new.
A whole new area exists named Translate Interface whose purpose is making it easier to localize Drupal to a new language. What that means is there are various strings used throughout the Drupal software which end up being displayed on the screen, and the software allows you to install new versions of those strings for your language. You can export all these strings and they're given to you in a format which the 'Gettext' editor can manage. You edit the strings, and then can import them into one of the languages. Unfortunately they don't seem to allow you to define a new language, meaning you can update only one of the languages they've defined. While they've defined a large number of languages, what if someone wants to translate Drupal so it supports Klingon or Tolkein's Elvish? Neither of those languages are in the list. In any case this is really cool and should make Drupal much more accessible to non-English audiences.
Oh, I later found a Languages section which lets you add a new language, including one defined to your suite. You can configure how to treat visitors who are native to other languages, such as giving them a subdomain (de.example.com or es.example.com) or to insert their language into the path (example.com/de/node/12345 or example.com/es/node/12345).
I found an Actions section as predicted above. The description says: Actions are individual tasks that the system can do, such as unpublishing a piece of content or banning a user. Modules, such as the trigger module, can fire these actions when certain system events happen; for example, when a new post is added or when a user logs in. Modules may also provide additional actions. There is not a configuration section for the trigger module, so it must be purely an API module rather than exposing an admin UI. This looks more complex than a quick breeze through the admin screen, so will require later exploration.
A welcome addition to long admin screens is that the table header stays pinned at the top of the page when you've scrolled it off the top. What happens in Drupal 5 and prior, you'll have long tables such as the access control admin area. You'll scroll down the table and then forget which column is what, especially in the access control page since there are likely to be many roles, and likely to be lots of access rights to control. If the table headers scroll off the top of the page it can be real easy to get lost as to which column is what, but in drupal 6 the column header stays at the top of the page even when scrolled down. This is real slick.
I turned on the OpenID module to take a looksee. First, there didn't seem to be any admin option to control OpenID authentication. Firing up a second web browser I find that the site now has, in the login box, a linked labeled Log in using OpenID. Clicking on the link makes the login box change to one requesting your OpenID. I provided one, and it went to my OpenID provider, clicked Trust to enable my site to be allowed to use my OpenID, and then was transferred back to an error message page on my site. Somehow the OpenID was not recognized. Probably a bug, eh?
The next module I turned on is Triggers. Remember that above I said there wasn't a Triggers admin area? Well, duh, that's because I hadn't turned on the module. Anyway this looks really cool, but not quite straightforward. It seems vaguely like the workflow module, but far more understandable, while still being not quite straightforward.
A trigger is an event which happens on the site, and you can configure an action to take based on the events which happen. Some example triggers are:
- When either saving a new post or updating an existing post
- After saving a new post
- After saving an updated post
- After deleting a post
- When content is viewed by an authenticated user
Clearly those are important actions which can occur to a node. In each of those sections there are a list of actions which could be performed, and you can configure just which actions are taken. One action when saving a new post is to unpublish the post, which might be useful if you want all posts to go to a moderation queue before being published. Another option is to promote the post to the front page, presumably it will be published and this would be helpful to make sure it goes to the front. There are other triggers on adding comments, and one of the available actions is also to promote the post to the front page. You can imagine this action to promote things to the front page could help keep active content at the front of the site, while inactive content sinks towards the end.
I turned on the Content Translation module but haven't figured out what difference that made.
I turned on the Aggregator module, and was displeased to see it is the same old Aggregator module. There has been much work on alternate Aggregator modules, which appear to be better, but this same funky one is being used. Why? Well, perhaps the alternate modules have not been improved enough to be suitable as a replacement.