IT Infrastructure and Software Development from the Customer's Perspective
I can’t claim to be the world’s Drupal expert yet, but I’m learning some interesting tricks that are worth documenting and sharing.
First, my Drupal installations typically include a lot of contributed modules. They’re distributed as .tar.gz files, which you upload to your server and unpack in the appropriate place. This can get tedious and error prone (e.g. I forget to unpack one).
I built a template directory with a complete Drupal install on a Linux box (you could do something similar with Windows if you had cygwin or a similar set of Linux-like tools). I unpacked the Drupal version, then went into the modules directory and unpacked all the modules I typically use. That was easy to do with a script like this:<pre>for f in module_directory/*.gz; do tar -xzf $f; done</pre>Your mileage may vary with that script, depending on where you put the tar’d modules.
This allows a couple of nice things:
Then, tar and gzip the resulting directory tree. There’s one big trick to this step. You need to make sure you get the .htaccess file, so I include it explicitly:<pre>tar -czf ../drupal-6.10-template.tar.gz * .htaccess</pre>There’s a reason I don’t just tar the template directory. That would give me a tar file that would create a directory and expand into it. On my hosting service, it’s more convenient for me to expand into the existing “public_html” directory.
The other “trick” isn’t so much a trick yet, as it is thoughts on running several Drupal sites from one installation. It seems to be a Drupal pattern to create “multisite” configurations where you have sub-domains running from the same Drupal source code (PHP files), but with different databases, and different configurations and themes.
This sounds good, and you would only have to update the files once for all your sites. However, I think it also causes some problems:
With the template approach, the pain of uploading the files is gone. The rest of the work you have to do for each site anyway, so it becomes almost the same amount of work to just run each site as a completely independent Drupal installation.
I’m going to try my template based upgrade and will post about the experience then.
I’ve gone from being a shell/make/rcs guy to quite liking IDEs, or at least useful IDEs. I find NetBeans to be a pretty nice, light-weight (in the good sense) IDE, but it has some issues on Ubuntu and other properly secured OSs. Here’s how I’ve got it to work. This applies to NetBeans 6.1 and 6.5, I believe.
First, you have to set up your Ruby platforms so they keep their gems in writable directories. Go to Tools-> Ruby Platforms. On NetBeans 6.5 (at least), the jRuby gems are in a writable, per user path by default. If you click on the “Autodetect Platforms” button and get the native Ruby platform, change the “Gem Home:” and “Gem Path:” directories to somewhere writable, like /home/reid/ruby/gems/1.8.
While you’re here, make sure the version of /usr/bin/gem is 1.3.1 or higher. If it isn’t, I think you have to upgrade from a shell. I did that upgrade a while ago, so I don’t remember how to do it, but you can find out easily through Google. (Ubuntu users may want to look here.)
It should all look like this:
catch(e) {}”}
Now go re-install all the gems you need through Tools-> Ruby Gems.
At this point, you still may not be able to install plugins. You’ll get the following message: “Missing the Rails 2.2.2 gem” (or whatever version NetBeans installed for you). Rake from within NetBeans seems to look at the system rails executable, and not the one installed through the NetBeans’ own gem installer. But the environment.rb generated for a new application does use the version of Rails installed by NetBeans. What I did (yuck, because there’s some redundancy here) is manually install the appropriate Rails version: <pre>sudo gem install rails</pre>I’m sure there’s a better way, but I can’t think of it right now and I really want to write some Rails code instead of fighting with NetBeans.
In an earlier post I described how I was running out of memory in PHP using a moderate set of Drupal contributed modules.
It turns out I was able to increase the PHP memory on my HostPapa hosted site. The method to use it to add the following line to Drupal’s “settings.php” file in each site’s “files” directory:<pre>ini_set(‘memory_limit’, ‘48M’);</pre>Or if the line already exists, make sure the amount is ‘48M’.
One of the problems I think I had earlier is not changing the right settings.php file. I have multiple sites in multiple sub-domains, because the main purpose of this host is to do proofs-of-concept for clients. I probably thought changing the settings.php file didn’t work because I changed the wrong one.
Suppose you installed Drupal under public_html. You have to change settings.php in public_html/sites/default to change the memory limit on your main domain (for example, “example.com”). For a sub-domain “test.example.com”, you have to change settings.php in public_html/sites/test.example.com. And so on for any other sub-domains you have.
As a follow-up to an earlier post, I should mention that part of the reason I had healthcare data on my personal laptop was to do some data analysis with MySQL. Between MySQL and the command line tools, it was very easy for me to load data from other sources and run queries to monitor or predict the amount of medication we were packaging.
When I was done doing the data analysis, I wanted to scrub the data off my hard drive. On the version of MySQL that was installed via Synaptic on Ubuntu 8.10, the default database engine was MyISAM. When a table is dropped, it deletes the MyISAM file. No need to worry about deleted records retaining data in a “tablespace” file that one might have to worry about in other RDBMSs.
Then all I had to do was scrub the hard drive as I described in my earlier post.
(For an update, read this post.)
I’ve been working on a few websites: One for my son’s school’s parent advisory council (PAC) and one for some community health centres. It gives me a chance to get to know what’s out there in the open source world for content management, wikis, and other collaboration tools that we’re supposed to be using to make ourselves more effective and productive.
The first step was to find a hosting provider that let me run PHP, as the free hosting I get from my ISP is for static pages only. I was pleasantly surprised to find very cheap hosting with PHP, MySQL and everything I needed, many for less than C$10 per month. I chose HostPapa – despite the somewhat odd name, they seemed to have a good reputation.
There’s a catch, it turns out. I’m using Drupal 6, a well-established and widely used content management system. When I build a site with a reasonable set of contributed modules (calendars, translations, FAQs), it needs more than 32MB of memory in PHP (I get a white page with a message saying “memory exhausted”). And I’d like to add a number of other modules.
My hosting provider doesn’t let me change the amount of PHP memory, so the whole hosting arrangement is mostly useless. (There are good instructions for how to increase the PHP memory in Drupal here, but not surprisingly the cheap providers don’t allow you to take too much memory.)
I also originally considered using Joomla!. Once I ran into the problem with Drupal I did some searching of the Internet and found that it seems to be an issue with Joomla! as well. Neither runs comfortably in 32MB if you have a reasonable selection of add-on modules. (Instructions to increase PHP memory exist with Joomla! with the same caveat that the provider can prevent you from doing it.)
It’s rather unfortunate. My idea was to have this space to be able to do proofs of concept or show potential clients what could be done with modern collaboration tools. It would be likely that any serious customer would be able to host their own server, or at least pay for a slightly more expensive hosting provider. I don’t need a high volume website, but I do need a space where I can show the capabilities of the tools. I hate to have to pay more money on pure speculation that this will lead to work, but it looks like that’s the case.
I don’t know whether to be annoyed with the content management systems for being memory hogs, or the hosting providers for setting unreasonably low limits on accounts on which they should fully expect people to use a modern content management system. By the way, I’m not really annoyed at either. I can see their point of view: HostPapa is really cheap and they need to control costs somehow, and serious Drupal users will find the difference of $10 per month for better hosting to be inconsequential, or will be paying for a dedicated server anyway because they get so much traffic.
The obvious lesson: One of the big things to look at when evaluating hosting services is how much PHP memory they give you. It’s easy to offer unlimited database space, unlimited sub-domains, and other such goodies when you know that no one can use serious website management tools anyway.
Anne Thomas Manes published a great post about how the economic downturn means the end of big IT projects being done for some vaguely defined “value”. There’s a good podcast about it here.
I think the key messages are:
There’s a great bit starting at minute 28:00 where she says, “Go take a look at the SOA success stories and invariably there’s a new CIO in place. And it only happens because the CEO recognizes that he needs to fix IT, and he knows his current CIO isn’t fixing it.”
I’m using Drupal to put together a site for my son’s school’s Parent Advisory Committee (PAC). I’m impressed at how quickly you can get something up on Drupal. Getting something the way you want it is a little harder, as is always the case with computers.
One stumbling block has been the favicon. First, it appears that the HTML that Drupal generates requires a Windows Icon file type (favicon.ico). I’ve used favicon.png in other sites, but in Drupal it has to be a .ico file.
Also, the directory where you put the favicon.ico is write protected, and the file manager I was using on my hosted service didn’t tell me I was trying to upload a file to a write protected directory. That resulted in another 10 minutes of muttering and fooling around trying to figure out where the file was going.
I’m using TikiWiki to propose to REACH Community Health Centre an idea about prescribing guidelines. I tried adding the search module. It would appear for the admin user but not for anyone else.
It turns out there is also a permission to allow users or groups to search. The module doesn’t display unless you enable search for the users or groups. Judging by the name of some of the other permissions, there may be other modules that also require a permission to be set.