created by: @sminnee (sminnee)
assigned to: @sminnee (sminnee)
created at: 2008-10-08
original ticket: http://open.silverstripe.org/ticket/2914
= Installer updates =
== Contact ==
- Sam Minnee (sam at silverstripe dot com)
== Status ==
Brainstorming
== Motivation ==
- The installer is a piece of code that we never use, and consequently is more at risk of bugs and usability issues.
- The installer doesn't take care of upgrading at all.
- For our own projects, we don't have any kind of environment checker - for instance, when new developers
- Distribution of our own projects (such as sscmap) is tricky because it really needs the installer.
== Spec ==
In essence, the installer is responsible for the following things:
- Database configuration
- .htaccess generation
- Running db/build
- Checking the build environment for all the dependencies
=== Installer re-bundling ===
Instead of setting the installer up as a separate package, it should be bundled into the Sapphire package, handled with a controller such as dev/install or dev/update. Obviously, there would be some work needed to ensure that the installer can successfully give a "your system isn't configured properly" line, but there are some techniques that we can follow.
- Redirect to sapphire/main.php?url=dev/update instead of just dev/update
- Tell Sapphire not to make a database connection if no database is configured.
- Avoid any memory-hungry activities; manifest creation might be an issue here. Perhaps an installer-only bypassing of the manifest & autoloader can be used.
Alternatively, we might have a sapphire/safe-mode.php, which runs a more conservative version of Sapphire.
As an alternative to RootURLController could perform this check: this would mean that if a SilverStripe developer checks out a project, it's going to automatically run db/build the first time they visit the site - could be very cool. You could even have some kind of system where the current svn revision was compared to the svn revision that a database update was last executed on - could be very powerful indeed!
=== _ss_environment.php
Management ===
Instead of updating mysite/_config.php, the installer should manage _ss_environment.php. It should let people manage an _ss_environment.php file for a single site, or a shared file for all sites.
The only thing that should be written to mysite/_config.php is the database name, and it should be done in a manner that preserves other content in the file.
=== .htaccess
Generation ===
Create a build task that is responsible for generating and/or updating a SilverStripe .htaccess file. This isn't needed just by the installer for 3rd parties; for example, .htaccess updates are required for static caching.
=== Module Manager ===
As part of all this work, a module manager for upgrading and installing modules would be particularly handy. You could use this to upgrade the version of SilverStripe you were using, as well as install modules.
== Results ==
- 3rd party developers will be taught to use _ss_environment.php from day one. Multiple SilverStripe installations will be easily set to use the same database config.
- SS developers can use dev/update as a more full featured replacement of db/build.
- SS developers have have their local environments tested to ensure that everything is working.
- The installer can be used for upgrades as well as installations: replace the files and then visit dev/update.
- SilverStripe staff will be making use of SilverStripe in the same way as the rest of the world.
== Plans ==
- Implement dev/update in trunk, bringing features from the installer one by one that.
- Once it's full featured and robust, look at refactoring the PHP installer to use.