Sam/Andrew,

I was coming up with specific ideas for the installer. This would sort out all my large concerns...

1. The installer would have mysite containing the "blackcandy" theme, and another folder called "tutorial" which is the existing mysite. I name it tutorial to emphasise purpose.

2. Inside the tutorial folder, _config.php is renamed to _config.php.disabled, thereby excluding its inclusion.
In /mysite/ there would already be _config.php with defaults.

3. Both have defaults, so again, you can manually just edit that file if need be.
- "root" user, blank password, database called "SS_silverstripe"
- show fatal errors to the screen until overridden to be sent via email

4. allow SendErrorsTo email to be set in the installer

5. The installer would ask if you want a normal skin or to start with a blank one and work on the tutorial. If tutorial, it just would:
mv /mysite/_config.php /mysite/_config.php.disabled
mv /tutorial/_config.php.disabled /tutorial/_config.php

6. A new file, /tutorial/README would contain
"To begin your SilverStripe tutorial, follow the instructions at http://doc.silverstripe.com
Ensure /tutorial/_config.php.disabled has been renamed to /tutorial/_config.php and that /mysite/_config.php has been renamed to /mysite/_config.php.disabled"

7. The php installer already contain /.htaccess, which is commented out. The installer just removes the comments. The reason I say to do this is that you can easily manually uncomment it yourself if something goes awry AND that by writing to a file rather than creating or renaming it, you no longer need directory creation permissions on base folder.

8. already have a folder called 'assets' so you don't need directory creation permissions on base folder.

9. This leave us with the following file permission requirements
a) chown www-data .htaccess mysite/_config.php assets
b) to allow the installer to begin the tutorial, "chown www-data mysite tutorial" (because directory permissions are needed to rename the _config files, but this need not be set recursively; you don't need write permission on the _config files itself. I've tested this on Debian.)

... where "chown www-data" could also be chmod or chgrp depending on your server permission configuration

...I'd allow installation to proceed if the check for (b) failed if the person was not wanting to do the tutorial....

This all sounds good; Andrew, this covers story cards 1 and 2, which you can get on with once we've made some progress on the documentation.

As an additional feature if we have time...

Currently a lot of user sites are being detected as "live", because the environment-type-checking code is too SilverStripe specific.

Add a textarea to the installer, called "live domain names". Add an explanation along the lines of:

"Enter the domain names that should be interpreted as being the live site, 1 per line. Error messages won't be shown when you're site is accessed using these domain names. This means that you can copy your site to your live server, and it will automatically turn the error messages off, without you having to change your code."

Use this value to create an entry in _config.php something like this:

$liveDomains = array('silverstripe.com','www.silverstripe.com');
if(in_array($_SERVER['HTTP_HOST'], $liveDomains)) Director::set_environment_type("live");
else Director::set_environment_type("dev");

Just about enabling and disabling sites by "_config.php" and "_config.php.disabled":

IMHO the better solution is, to have a file in the root, where will be a list of directories included. E.g. something like:

Loader::addDir('cms');
Loader::addDir('saphire');
Loader::addDir('mysite');
...

And autoload function will load only from these directories. Then you also solve the possible conflict with other PHP5 programs in the same directory as SS. These programs can have their own config.php.

Andrew... also don't forget to make the database password field a password field, so you don't see the value you type on screen ;)

xmedeko... your idea has been thought about and we just wonder if its nicer to have the ability to install a module simply by putting in there. Jury's not decided I guess yet... :)

xmedeko: Your idea has its own set of merits and disadvantages, but ultimately it's a move away from a trend we already have started in SilverStripe development. Many of the modules already have _config.php files, as this is where you can put Director::addRule() directives for the module. Further tweaking this to enforce the inclusion of an _config.php file is a small step.

One potential issue is the existence of other applications with _config.php files. For this, and also to facilitate the easy enabling / disabling of modules, we could add a Loader::disable() style function. That is, all modules containing and _config.php file are included by default, but you have the option to disable them.

xmedeko - do you have any feedback on this idea?

I'll add a note to add the stuff listed in here to the Windows installer during my SS time next week. Shouldn't take too long (but then, we are talking Pascal here...)

I think xmedeko's ideas have merit - it's currently really hard to installer SilverStripe in the root/home directory of a website because you can't put any files other than SilverStripe files inside it. For example, you can't put phpMyAdmin in a sub-directory, or some file lister, because they all have code outside of a class/function definition which is executed (and output) by PHP when the class auto-loader kicks in.

Maybe we add some detection where the class auto-loader looks for the presence of a _config.php file (or some other silverstripe-identifier) and if it doesn't find it, skips that directory.

Sam: The idea to have a list of live URLs is a good one, but it might make more sense to have development urls specified as opposed to live ones - it wouldn't do to have error messages show up on live websites because the site was moved to a new host which is no longer in the $liveDomains array.

I suppose all this begs the question - do we need to make a php-based Windows installer - where the InnoSetup executable only puts files in some place and runs a web browser, then the user is taken through the rest of the setup process (which could be almost identical to the PHP installer, with fields removed) or is there merit in separating them entirely?

I personally like more if I I have to enable things, then when everything is enabled and I have to disable what I do not want. But it is not important.

If you are going to make everything enabled by default, then there should be a config file, or some tool, how to disable certain directories. Not only for PHP autoloader, but to tweak .htaccess for mod_rewrite, too.

I think, however you make it, just make a good documentation and mention it in the installation guide.