webschuur.com

Good news. My servermanager and Drupal host, just announced they are moving their infrastructure to PHP5. Entirely. PHP5 is really important if you want a future-proof hoster.

If you are looking for a Dutch host for your Drupal sites, I can advice you either one of the cheaper Vhosts, or, in case you decide to go for more Drupal sites, to mail for a reseller of colocation contract.

I have partnered up with them and give advice about Drupal hosting.

Lighthttp is a very good alternative for Apache. The exact details on why, how and when are outlined on lighttpd’s website, but I choose it for my development environment; because it is light: having five forked apache processes idling around, merely to develop a simple module is way OTT, I think.

There are many tutorials on getting lighttpd up and running, including a nice, yet complex one special for Drupal.

There, got your attention. Still, this is an often heard complaint, most of the times in nicer words though. Just look at the large amount of requests (with patches) for the statistics module. Nearly all of them cover things such as ‘don’t track this and that’, or ‘also track foo’. And apparently, it seems even Dries agrees. Or at least he seems to need more statistics then only those provided by Drupal:

<!-- Begin W3Counter Tracking Code -->

Drupal has a fantastic feature, the hook_auth to allow any third party to interact in the authentication process. This is used to authenticate against other Drupal sites over XMLRPC, it is used in the experimental openID integration, to allow authentication against any database, and so on. And off course to authenticate against an LDAP directory, using the ldapauth module. This HOWTO helps you on the track for the LDAP coupling. We use ldapauth.module, userprotect.module and Sympal Password Hijack to mould our Drupal site into an authenticate-only site.

This is a morphological overview, to display all te options for deploying a Drupal (and/ or Joomla!! or any other CMS) hosting system.

The way one should read it

In the first vertical column all “tasks” we need to perform are listed, chopped up into the smallest possible unit. Then next to each of these we render all possible tools and solutions for each task, without taking in consideration how ill-suited these tools may be, nor how well they can, or will co-operate. By refusing to look at possible solutions yet, we can make sure that we actually list all options.

Sympal Scripts Premature manual

It is a bit strange to write a manual before the features in that manual are all implemented, but I think it is an interesting workflow, to start off with documentation, because it gives me (developer) and my audience (potential users) a clear view of what Sympal Scripts will do. And it shows a clear todo for me too. Below are the common usage parameters and usage concepts. In reality some of the commands can take a lot of advanced parameters in addition to the listed command parameters.

Usage:

install.php        Install new features in a multisite, or a new site.
 --type [site|module|theme]        Site installs a new multisite. Module installs a new module
 --variables site=example.com user=Joe email=joe@example.com etc.
                             A name=value list of variables needed for installation of the module or site. Provide none to see a list of required values.
 --fixtures directory-name   Use the fixtures in the directory directory-name to preconfigure the site.
 --dry-run                   Don't write anything, just output information
 --verbose                   Be more verbose