Running Diaspora on Your Server

A key part of Diaspora's design is the fact that anyone can run their own server. At present, though, installing the software is - in the developers' own words - "a bit complex".

This is because Diaspora isn't distributed in binary format: it comes as source code, which must be compiled for whatever system you're using. This means you'll need to install a number of development tools and libraries to get it working, including Ruby, MySQL, the OpenSSL encryption library and the ImageMagick image-processing library - plus a web server such as Apache if you plan to host a publicly accessible pod.

At the Diaspora website, you'll find a guide to installing and configuring these components under Windows. OS X and various distros of Linux, You'll also find instructions for downloading and compiling the Diaspora source and configuring your web server, SSL, the database and other services, such as the components that connect Diaspora to Twitter and Facebook.

If this sounds like a fun project, head over to https://github.com/diaspora/diaspora/wiki/Notes-on-Installing-and-Running-Diaspora and start compiling; the Diaspora team will doubtless be delighted to see a new pod open. But we suspect the majority of Diaspora users will prefer to use established servers, rather than administering a complex back-end system.

Read More

Doing it the Drupal Way

Official homepage of the open source content management system

There are many different ways to build a website these days. When I first started in this business, you wrote HTML files directly onto a local web server and, if it all looked good, then uploaded these files to the live web server. Later, the introduction of scripting languages made the need for such a staging server all the greater. If your clients wanted their site altered, they'd tell you what to change - in electronic form if you were lucky, but more often via a phone call - and you'd have to implement these as soon as you could.

As websites became more strategically vital to businesses, it became desirable for them to be able to update their sites for themselves. But giving inexperienced users a copy of an authoring tool such as Dreamweaver was a recipe for disaster. Far better to offer a controlled means for users to enter their own content - menus automatically updated, images re-sized according to prior settings. Enter the content management system (CMS).

A CMS is a combination of a database that holds all the content, and an engine that generates visible web pages from it according to pre-established settings. The most popular CMSes were invented by the open source community, using PHP and MySQL. Some people criticize this way of building websites as a "sausage machine", where you turn the handle and out comes yet another unremarkable website. In some cases this may be true, but it doesn't have to be. For sites with a lot of fast-changing content it's the best solution, as it would be impossible for a small group to maintain such sites without the help of a CMS back-end.

Almost all of the larger ISPs nowadays offer build-your-own-website packages based around customized CMSes, and offer hosting of various CMSes that can be installed with a single click. The route to getting started is easy, but as with most things technological, this is just where the fun starts. Most of my work involves building custom web applications using Microsoft technologies, but a while ago my company was asked to quote for a CMS for a new client, and we decided that this should become the new standard within our company for building all such sites. Accordingly, we put a lot of thought and testing into the task of deciding which CMS to adopt - our main criteria were performance, flexibility and ease of use for the end users when updating their own sites.

We spent some time looking at the .NET solutions available, and while Umbraco (http://umbraco.com) has its charms, there were problems between versions and the modules, and support via the forums seemed limited. On talking to our existing clients, they too were wary of using a CMS they hadn't heard of, and so we decided to take a longer, harder look at old favorites Joomla. Drupal and WordPress.

We had built sites with Joomla in the past, but discovered that clients found it confusing to use. WordPress is great for building blog-style sites, and while you can get it to do amazing things, we wanted a more basic framework to which we could add functionality depending on clients' needs. Performance was also an issue, and scouring the forums and blogs suggested that Drupal (http://drupal.org) was highly thought of in that respect. I'm sure many readers will have other equally justified views about this matter, and you could argue over it forever, much the way you argue over the best car to buy down the pub. Often, in the end, it comes down to "gut feeling": if you like a product yourself, then it's going to be far easier to sell it to your clients. I felt that Drupal's administrative front-end was clear and concise, and it didn't log me out every few minutes like some CMSes, which was a definite plus!

The major criticism of Drupal is its steep learning curve - it's a basic empty framework to which you have to add modules before it can do anything at all. By default, it doesn't even come with a Wysiwyg editor to enter content. Things like this can put off the casual user - it does mean, however, that you can choose your favorite editor and install that.

The time came for us to set up and test an installation of Drupal. Before you even start thinking about going live with a CMS, it's critical to have a local copy of it on which you can test modules and settings before exposing them to the public. Rather than going through the whole process of configuring web servers, databases and server scripting languages, it made sense to use one of the pre-rolled configurations. As we were running a Windows desktop, the easiest way to do this was by employing the usually excellent Microsoft Web Platform Installer, or the free Microsoft WebMatrix. However, I said "usually excellent" because this time I couldn't get the Drupal package to work correctly on either of two machines, one of which had a fairly clean Windows installation.

Another reason for giving up on this way of configuring is that I've found, while you can run packages such as Drupal. WordPress and Joomla under Windows with IIS and Microsoft SQL. the level of support for the Microsoft route is considerably weaker than for Linux with Apache and MySQL. If. like us. you decide it's better to go down the Linux route, your hosting will also be cheaper.

When it comes to hosting your Drupal site, most web houses will use the hosting provided by their ISP rather than configure their own server, so the choice of OS isn't really an issue, but it does make sense to use the same OS on your development box as a live server to avoid any strange compatibility problems. The easiest way to get a local Linux box up and running on your Windows desktop is to use a virtual machine pre configured for that purpose.

I found the free BitNami range (http://bitnami.org/stacks) particularly useful in this respect, as it will run in the free VMware player (www.vmware.com/products/ player), providing a Linux machine preconfigured with MySQL and Drupal for you to get cracking with.

You'll need to do some basic editing of a few text files to get FTP access running, after which you can access and edit any other files via an FTP client such as FileZilla (http://filezilla-project.org)or Notepad++ (http://notepad-plus-plus.org). You'll need Notepad++ or similar rather than the Windows-supplied version of Notepad, because the latter won't handle the end-of-line breaks in Unix text files. The current version is Drupal 7, for which the module installation process has been made extremely easy. Via a web page, you point to a previously downloaded module archive file (http://drupal.org/project/modules), and once a module has installed, you can enable and configure it via the same web interface, with no cryptic command-line stuff, nor wrestling with Unix's Vi Text Editor. Version 7 also uses a different database schema from previous versions, so it's important you download the correct version of any modules.

I found the online help to be excellent, most of my questions being answered via the official Drupal site with little need to traipse through lesser forums. It would be dishonest, however, to say that this process was completely without its frustrations. My first site took about two weeks to get to a level that we were happy with, but then our next site - which had an e-commerce element - took only two days to get to a stage good enough to show the client.

As with many CMSes, Drupal's content is structured into content types, which are categories such as "articles", "stories", "blogs" and 'books", plus any of your own devising you wish to add. These types determine what can be entered by the client, and the basic format of how it will be displayed. Where a piece of content will get displayed on the site is controlled by "blocks": normally your content will be displayed in the "content" area, but you can have versions that display the same content in different formats on different areas. A "page" is known as a "node", and its look is decided by the blocks and content types.

The final appearance of the site is decided by a template. Menus are generated automatically, but can of course be customized. Before your clients can edit the content, they'll need to log in to the site, but one pet peeve of mine is having login forms on publicly visible web pages: if you're not allowing the public to log in, then why display a visible page to tempt them? Far better to reserve a URL that you can give only to your clients, and this is easy to achieve in Drupal.

When developing a non-CMS-based website, it's usual to work on the design first and then add content afterwards, but when using a CMS it's often better to add content and get familiar with the structure of the data that you'll need to work with, and only then add design features to it. Of course, it's a good idea to achieve a reasonable-looking design before showing it to the client, as otherwise all the feedback you'll get from them will be about cosmetic matters, such as the colors being wrong and so on. Getting clients to understand this often isn't easy, but coming up with a new design and all the tweaking that follows can be time-consuming.

One useful ploy is to use the rather excellent Artisteer program (www.artisteer.com), which features not merely a vast number of pre-made designs, but shows the effect of any changes you may make to them immediately in its preview. You can literally sit with your client and show them what their site will look like, complete with curved boxes, graduated fills or any other of hundreds of "tweaks" you can apply.

It would be foolish to suggest that Drupal provides the answer to all the problems of building websites - far from it - but once you get your head around its basic concepts, it really is quite easy to use. The latest version has laid many of the previous Unix-related frighteners to rest.
 

Read More