You are here:

Drupal 7.0 was officially released on Jan 5, 2011, yet there is still no Ubuntu package available. There is a Debian package available for Sid, but attempts to incorporate it into a TurnKey LAMP appliance proved problematic. I can understand concerns about relying on upstream developers for support, but in this case the availabilty of Drupal 7's built-in updates and Drush's site-install, provide the ability to obtain updates directly from the source.

A new strategy of installing Drush first using git, and then using the power of Drush to download, install, and configure the Drupal site has proven effective. A TKLPatch to add Drupal 7 to the TurnKey LAMP appliance is now available in the Development Wiki, turnkey-drupal7-11.x-lucid-x86-patch-beta1 and also on GitHub.

<snip>

Moved the remainder of the original post to the Development Wiki where it probably should have been all along.

I don't use Drupal myself but this looks fantastic! And the beauty of someone such as yourself taking this initiative is that it frees up the core devs for other stuff (because no doubt they would've been planning on releasing a Drupal 7 appliance in the next release anyway).

The core developers are currently maintaining the Drupal 6 TurnKey
appliance. But we're in the process of building out a community
development infrastructure that we hope will eventually allow trusted
community members to adopt the maintenance of specific appliances like
Debian developers adopt packages.

With the community's support we could scale TurnKey into hundreds, maybe
even thousands of pre-integrated open source solutions...

I'll take a look at the PEAR installation of Drush. I choose the git installation method because it clearly has long term support from Drupal.org. I'm not thrilled, however, that git clone stores a complete copy of the git repository in the appliance; for Drush that's about 3.6 MB of extra data. I'm a git noob, so if there is a better way to download a specific version without cloning the repository, please let me know.

I'm puzzled by your reference to 2 versions of Drush. I choose to use the latest stable release which is currently 4.5. Now that I'm planning to add drush_make, I'm reconsidering and may use a 5.0 dev release instead to simplify the update process. If I install Drush 4.5 + drush_make now, then the update scripts have to detect when 5.0 is released and remove drush_make. Overall, it may simpler to start with 5.0 dev which includes drush_make and use Drush's self-update to handle updates.

Happy new year John and sorry for the late response. I've been following
the work you've been doing for the TurnKey Drupal 7 tklpatch (on the
wiki) and it seems to be really good stuff. When we come out with Drupal
7 officially in the next release this will be a big help and we'll give
you credit for pushing Drupal 7 forward.

We're a bit swamped with everything we have going on at the moment so it
sometimes takes us a bit of time to get a response out of us but we
still stand up and take notice when community members contribute back to
the project. Many many thanks!

I started the project because I needed a Drupal 7 base to start experimenting with Drupal's VoIP module. I decided that if I were doing the work for my personal use, I should release it back to the community as a way of saying thanks for all that the TurnKey developers and community have contributed.

I must say that I deeply appreciate the openness and willingness to accept input that I find here. Examples include adding Drush to the Drupal appliance and reworking TKLPatch to meet some of my earlier requirements. What goes around, comes around and so I predict good things for TurnKey's future.

I think most people would agree that Drupal has a steep learning curve that often discourages potential users. My vision for the Drupal appliance is to collect best-practices from the Drupal.org community and package them in an easy to use appliance that will encourage a wider audience to give Drupal a try.

I'm currently working on a beta2 release of the Drupal 7 patch, which will add drush_make and the ability to select from a list of profiles during firstboot. In the spirit of openness, I'm still looking for suggestions about which modules and themes should be included in the appliance.

Don't worry too much about bundling modules. You can do something simple like that if you want, but there are some great Drupal distrobutions out there which can really help speed up the process both of choosing good combinations of modules but also allowing for optimized configurations.

You could possibly include all of these distrobutions re-using the same base Drupal code base:

For the list of packages, you can use drush_make to generate a makefile specific to your site.

drush generate-makefile yoursite.make

That gives you a makefile that can be used by drush_make to install the same packages, libraries, and patches on another site. Unfortunately, it does not include configs that are stored in the database. For those, you will have to consider the context and features modules. For more details see the Development Seed Blogs:

For years, drush download is the method I've used to build websites and it's the method used in the beta1 version of the Turnkey Drupal7 patch. In the past several weeks, I've been experimenting with an alternative method of building sites using features, profiler, and drush_make described by Dmitri Gaskin at DrupalCon Chicago, "From Zero to Distribution using Features, Profiler, and Drush Make". Dmitri is the author of Drush Make. Drush Make has been adopted by the Drush team and is part of Drush 5.0 core, so it's safe to assume it will be around for the long term. I thought it would be useful to document here some of the differences between the two methods.

Downloading and unpacking Drupal core and the desired contrib modules using drush download or drush make is only the first step in building a Drupal site. Next the database must be created, populated with data, and the initial configuration applied. Once again we have two choices, Drupal's built-in install.php or Drush's site-install.

install.php

prompts user for information about the site and the site administrator

allows user to chose from a list of profiles

install.php cannot create the site database and dbuser

settings.php must exist and be writable during install and manually changed to read-only after

webserver must have write access to sites/default/files

drush site-install

information about site, profile, and site administrator input via command-line

can create the site database and dbuser, if supplied the MySQL root password

creates settings.php from information supplied on command-line

leaves settings.php world readable

creates sites/default/files owned by the uid running drush, usually root

For the past several weeks, I've been working on a site-builder script based on 'drush make' and 'drush site-install'. The strategy was to move all the site building parts from the TKLpatch scripts of beta1 into a common script that could be called during firstboot. As the script began to take shape, I realized that with a few changes, it could be structured to handle multi-site installations and perhaps a mix of Drupal 6 and Drupal 7 sites.

Initially I had hoped it would be as simple as:

drush download profile
drush site-install profile ...

but of course reality is never that easy.

Currently, the core of site-builder has been tested on several profiles and is able to deliver a complete functioning website. It does, however need some work on handling error cases. I also have to learn enough python to write the user interface which I've been avoiding until now. I hope to have this completed and rolled into a beta2 patch in about two weeks. I thought I should post a progress report just in case anyone is wondering.

I am trying to use your Drupal TKL patch on the Turnkey-lamp appliance. It typically fails with a "no such directory error". I have tried patching an exiting installation and an iso file with similar results.

I am using the root id in the /tmp directory. What can I do different? Thank you for your help.

My fault for not catching this. In my development environment, I keep all my patches in /opt/patches/... and the iso files in /opt/iso/... While testing I used the patch directory, /opt/patches/drupal7, instead of the tar.gz file which I didn't create until ready to release and apparently didn't test the final time. The problem is that the tar.gz is extracting to tmp.0GlHPQqfUG/drupal7 instead of tmp.0GlHPQqfUG/turnkey-drupal7-11.x-lucid-x86-patch-beta1 where tklpatch expects to find the extracted patch.

Probably the easiest workaround is to create /opt/patches and manually extract the patch file there. Then issue the tklpatch command as

/tmp# tklpatch turnkey-lamp-11.3-lucid-x86.iso /opt/patches/drupal7

If that doesn't work, let me know. In the meantime I'll try to rework and test the patch and issue a new release.

Actually I did create the patch using tklpatch-bundle as you suggested, but that resulted in a patch named drupal7.tar.gz. I didn't like the fact there was no version information so I renamed the file to fit what looked like a standard way of naming patches, i.e. turnkey-drupal7-11.x-lucid-x86-patch-beta1.tar.gz. Unfortunately, I never thought to test after making the name change.

I use git for tracking changes so renaming the folder for each release isn't an attractive option. I'd like to have tklpatch-apply ignore the name of the patch folder.

/usr/bin/tklpatch-apply:

add
name="$(basename $patch_tmp/*)"
before
patch_dir=$patch_tmp/$name

This assumes that the patch tarball will always have exactly one base folder that contains the patch files. I thought about eliminating the base folder entirely, but that would break compatibility with older patches. This worked for the one test case I tried, which was to apply my renamed patch.

Perhaps the larger question is there a preferred naming scheme for patches that indicates which core or appliance they should be applied to, and what is the version of the result? The name I chose doesn't effectively convey that the patch should be applied to a turnkey-lamp-11.x-lucid-x86 appliance and results in a turnkey-drupal7-11.x-lucid-x86-beta1 appliance. Should a patch specify which appliance(s) and versions it can be applied to, and how could tklpatch make use of that information?

I too use git for tracking patches, but I copy the patch folder when I create a patch to share. To use your example as an example:

cp -r drupal7/* turnkey-drupal7-11.x-lucid-x86-patch-beta1/

then:

tklpatch-bundle turnkey-drupal7-11.x-lucid-x86-patch-beta1

But I quite like your workaround.

On the other hand, another way would be to include a switch in tklpatch-bundle which copies the patch folder to a (temp) folder of the desired name prior to bundling. It's usage might look something like:

Regardless, TKLPatch is on the TKL GitHub account so feel free to have a play. If you have a GitHub account then you can fork it, then issue a pull request and if the core devs like you're work they'll probably include it in future releases of TKLPatch.

As for naming convention, there certainly isn't an official one. Many people have simply named there patches like 'drupal7.tar.gz' (to use your example). I too like to include some version info, however mine has been lazier than yours. Mine have been more along the lines of 'drupal7-0.1.tar.gz'. Your more extensive naming is definately superior as you can see at a glance what it is intended for (and hence get a good idea off the bat whether it should work or not).