Wizard Steps

The installation process on a linux machine should be:

Steps in the Wizard

1. (Installation) Prepare webspace and install application

The Admin has to prepare the webspace and unpack the installation package. Since we don't support simple web spaces (where apache document_root must be the top level directory), the admin must be able to choose the extracted public directory as apache document_root directory. All other kind of installations are not supported.

2. (Update) application upgrade automatically

The application can upgrade itself. This is triggered by cron. Before it runs automatically, the application must know that this update is autoupdateable (Metadata from Update Server)! That means also, that the cron must not call upgrade automatically, but first has to check our server.
If the update is not autoupdateable, notify the admin.
Our update channel has to be secured against our Support ID, and the user count on the client side has to be sent to us. (Different support contracts).

3. (Installation) install wizard

Installation is started by browsing to a install URL, this is a dedicated install.php because on installation we don't have Zend.

3. (Update) initiate update wizard

Update Wizard shows an overview over installed updates (installed, manually).
Admin can choose the latest one to be installed. And a warning, that currently working users are going to be logged out.

4. (update) the application updates it self

The updater gets the newest version from our server, extracts it and installs the delivered files.

5. + 6. get and confirm external libs

We have to define our own fetch mechanism for the external libraries - which currently are: Horde, Zend, ExtJS and the TermTagger.
We have to get the licenses of the newly installed packages, and show them in the wizard to the admin.
The admin has to accept the licences, otherwise the update / install will fail. In the first case the application will be left in a inconsistent state. The installation should be restartable from this point on. (After downloading the externals, before confirming the licenses)
We have to implement somekind of checksum check of the desired and downloaded zip files.
For this mechanism we have to provide the metadata, and a mechanism to store which version is currently downloaded.

5. (Update) Fetch new and update other externals

We have to provide a way in our package updates to update these externals.

7. (Installation) enter installation specific config

The admin has to enter the DB credentials.
Installation.ini is created out of the given data.

8. requirements checker pre installation

If requirements are not met, we should provide a way to go back to an old version.
Requirements are checked with separately described requirements checker.

9. DB backup

We ask the admin if he wants to do an automatically db backup. (Only if there are changes to the db).
Best way would be using mysqldump through shell_exec. See:
http://davidwalsh.name/backup-mysql-database-php
http://www.a2zwebhelp.com/mysql-database-backup-php

10. DB installation / DB update

On installation we apply the latest delivered structure.sql.
After that, and on updates we apply all delivered delta.sql files.
For each delta we track the installation of this file in the dbversion table. This ensures that we can proceed after errors, and this features helps the developers keeping track of the installed sql files.

11. Optional Steps

We should provide a simple way to insert more, version specific wizard steps. For example a file conversion of the already stored task files. The admin will be warned that this is a irreversible step.
These steps should be after DB updates, since db updates are restorable through backups.
The optional steps should also be cumulative like the DB Updates. That means, we need a directory structure automatically created on building the app. The current steps are in a development directory.
The optional steps are more likely to be called update tasks.
The optional steps code should be designed, so that it is able to be run multiple times. That means, if the routine is started again, the code should do his task, or do nothing if the task was already done. This enables us to run the code multiple times, for example on devel machines. And if update fails to run update again.

12. Application Configuration

Provide a GUI to check all new configuration values.

13. RequirementsChecker Postinstallation Phase

Displays all check results affected by configuration. That means admin should be able to change the values again.

14. (Installation) Set the Manager user and support key

The admin should get a simple form to enter the application admins credentials and the support key to get automatic updates.

14. (update) send the installation user count to us

Since the support costs are user count dependent, we have to sent the actual user count of the installation to us. This should be done short directly after updateing.