SoC install script revisited

This project was implemented in the 2008 Google Summer of Code. The improvements to the install script will be available as of Geeklog 1.6.0. This project outline is therefore only of historical interest and you can not apply for this project in future instances of the Google Summer of Code. Please see our ideas page for a current list of GSoC project ideas.

Incentive

As part of the 2007 Summer of Code, Geeklog's crude install script received a major overhaul and is now much more userfriendly and easy to use.

In this project, we would like to add some additional features to the install script.

Goals

Bundling plugins

The default install of Geeklog ships with 5 plugins (Static Pages, Spam-X, Polls, Links, Calendar). While all of them have separate install scripts (so they can be uninstalled and reinstalled individually), in the initial install of a Geeklog site, they are hard-coded in the install process.

The goal here would be to develop ways to untangle the plugin install from the install of the core Geeklog site so that

• The user can choose which plugins to install
• Plugins can easily be added to or removed from the tarball

In order not to make the easy install more complicated again, the option to deselect plugins should not be offered by default but should be an "advanced" option linked from one of the install script's screens.

The option to add or remove plugins from the tarball does not need a user interface. This option should allow creation of Geeklog distributions that include certain plugins, e.g.

• A minimal package: Download the official tarball, remove unwanted plugins, create new tarball from the remaining files then use that tarball for a fresh Geeklog install.
• Add "most wanted" plugins: Download the official tarball, add popular plugins (e.g. Forum, Media Gallery), create new tarball and use that for a fresh install that has the additional plugins installed and enabled by default.

Assist in Migration

Every once in a while, a Geeklog site will have to be moved to a new server (with or without a change of the site's URL). The install script should assist the user in this migration process as much as possible.

• Option to import a database backup
• Check for missing plugins
• When the URL changed: Update config settings
• Check for other missing files, e.g. images

So instead of populating a new database, the "migration assistant" should offer to import a database backup that was created on the old server (note: need to handle timeout issues with big databases on shared hosting).

There are also a couple of sanity checks that should be implemented. Additional plugins that were installed on the old site but haven't been uploaded to the new site yet would stop the site from working. The install script could check which plugins are missing and offer the user to either disable them or install them and try again.

Images in articles and userphotos may easily be forgotten to copy over from the old site. Again, this is something the install script could check for.

When the URL of the site changed, several of the config options in the database will have to be updated. Also, some URLs are also stored elsewhere in the database and need to updated or contents need to be refreshed (e.g. the Older Stories block).

Level of Difficulty

relatively easy

The most complicated part of this project will be the untangling of the plugin install code and coming up with a generic way to bundle/unbundle plugins. Other than that, this project will require much attention to details and lots of testing.

Ideally, a student should have access to more than one platform or setup to test on (e.g. shared hosting vs. root server access, Linux vs. Windows). We can, of course, provide test access to more platforms.