silverstripe/silverstripe-installer

The installer for Silverstripe CMS and Framework. Check out this repository to start working with Silverstripe!

Overview

Base project folder for a Silverstripe (http://silverstripe.org) installation. Required modules are installed via http://github.com/silverstripe/recipe-cms. For information on how to change the dependencies in a recipe, please have a look at https://github.com/silverstripe/recipe-plugin. In addition, installer includes theme/simple as a default theme.

Installation

composer create-project silverstripe/installer my-app

See Getting Started for more information.

Bugtracker

Bugs are tracked on github.com (framework issues, cms issues). Please read our issue reporting guidelines.

Development and Contribution

If you would like to make changes to the Silverstripe core codebase, we have an extensive guide to contributing code.

Links

• Changelogs
• Bugtracker: Framework
• Bugtracker: CMS
• Bugtracker: Installer
• Forums
• Developer Mailinglist
• License

silverstripe-installer's Issues

Add installer warning about always_populate_raw_post_data=0

See silverstripe/silverstripe-graphql#48 (comment) for context. This became an issue since starting to use POST bodies for GraphQL, but is a general problem which we can't solve directly for the user. For example, any API modules installed into an SS install might cause similar issues.

Add a warning (not an error) to the installer, tradeoff between being proactive about potential problems the dev might encounter, without forcing a php.ini change for virtually every PHP 5.6 install out there (and hence creating a barrier of entry/upgrade).

Document this new default in the 4.0.0 changelog as well.

PR: silverstripe/silverstripe-framework#6507

stop install by web

Hi,

why web installer disallow installation process after warning (only) occurs (Debian)?

composer create-project should set up _ss_environment.php

This follows on from #116 to focus on environment set-up.

Right now, the canonical way of running composer create-project silverstripe/installer <foldername>. This does part of the install process, but requires further set-up.

Specifically, you need to visit install.php in a web-browser to populate _ss_envrionment.php. Instead of this, it would be best if the CLI-based installation interactively asked the user for database credentials and other details of the new environment, and populated _ss_environment.php for us.

https://github.com/axyr/silverstripe-cli-installer is a start on this, but it requires a separate CLI tool, which shouldn't be necessary, and it duplicates a lot of core functionality. Instead, post-install hooks in silverstripe/installer should check to see if the environment requires configuration, and if so, run an install process based on code provided by framework.

In the first instance, a minimal adaptation of the web installer to CLI execution is probably appropriate.

References:

• https://github.com/axyr/silverstripe-cli-installer
• https://groups.google.com/d/msg/silverstripe-dev/YQ9ru7UuUV0/zWc-1pvwCQAJ

[4.0 alpha 2] jquery missing from installer

The installer is looking for framework/thirdparty/jquery/jquery.js however the path/file doesn not exist. It probably needs to reference framework/admin/thirdparty/jquery/jquery.js

Composer issues with 3.2 / self.version

At the moment running composer create-project on 3.2.x creates a repo with a detached head (but at the right commit). This doesn't break the initial install (which evaluates self.version as 3.2.x-dev) but further operations cannot determine the correct version.

This seems to have been traced to an issue in composer setting up an incorrect root branch.

[4.0] Use dev-master for silverstripe/asset-admin

Related: silverstripe/silverstripe-asset-admin#235

It looks like the only "official" module that's using a tag from a fresh 4.0 dev-master install.

Could we use dev-master for this during the development phase as well?

[4.0] Block access to uploaded error-\d.html files

See #113

This opens a risk of users uploading error-*.html files and having them presented by the site as legitimate pages which could be used for nefarious purposes.

This needs preventing.

min-stability dev should be stable

Setting min-stability = dev breaks developer expectations and makes the use of composer more error prone.

A couple of examples of the issues this causes:

• You can't install silverstripe/translatable without specifying a version explicitly, as it will try and grab the 4.0-only version of the module. Although this is a bug in composer (composer/composer#4181) I think that one of the reason the bug slipped through is that most people don't set min-stability = dev. We're being unorthodox and our users are paying the price.
• Our projects frequently run with dev versions of composer/installers and phpunit. This makes no sense.
• Feedback from someone at DPC conference today: "I keep being asked to install SilverStripe 4.0, it was very confusing, why are you recommending the development version?"

The reason we've selected min-stability = dev is because so many addons don't produce stable modules. We should address that problem head-on, and get stable releases out for more modules.

A "stable release" can be as simple as creating the tag—I think it's counterproductive to say that we need to keep installing dev modules because there's no time to create stable releases. If we're seriously unsure about stability, we could create a 0.x.y release.

We'll need to put out some comms to module developers. In my view, 3.2 stable would be a good time to do this.

There's an open question with pre-release versions: arguably, it makes sense to install pre-release packages of modules in pre-release versions of SilverStripe. I'm not sure of the best way to manage this.

Fatal error: Access level to *****::$db must be public

When using Composer with the 3.1.1 or 3.1.2 builds, when doing an initial dev/build I keep getting these errors relating to the following classes:

• /cms/code/model/ErrorPage.php
• /cms/code/model/RedirectorPage.php
• /cms/code/model/VirtualPage.php

I have to manually update all of the private fields to public. Very frustrating.

Problem with missing package "php-intl"

Silverstripe 4.0 alpha 6 seems to need php-intl but there is no info in the installer. Installing php-intl let you install SilverStripe, but without php-intl it causes ugly PHP error :)

mysite should have a sample test that works out of the box

When you want to create tests for a clean install of Silverstripe with this installer, there are quite some steps necessary before you can run tests.

This might be combination of documentation, unclear requirements and operator error.

These are the steps I needed to perform before being able to run some UnitTests for a module in a clean SS install :

1. Install Silverstripe
   • composer create-project silverstripe/installer myproject
   • running myproject.dev/install.php
2. Adding required files
   • phpunit.xml.dist
     • I did not got that file with the installer
     • This is required to find SapphireTest
   • _ss_environment.php
     • This is also needed to find SapphireTest
     • You need to add a $_FILE_TO_URL_MAPPING
     • Here I add define('SS_ENVIRONMENT_TYPE', 'dev'); as well
3. Again set dev mode in mysite/_config.php
   • I already have set dev mode in _ss_environment.php, but need to set it again?
4. Run cli commands
   • php framework/cli-script.php dev/build flush=all
     • needed even when the installation has created a manifest file.
   • vendor/bin/phpunit mymodule/tests
     • Yes, we got green!
   • php framework/cli-script.php dev/tests/cleanupdb
     • Ever seen like 500 ss_tmpdb123456xx databases pop up in your mysql browser, because you did not know there is a db create every testrun but not cleaned up?

Now, there might be some issues/comments due to operator error. Above steps are done on a vanilla MAMP PRO environment. And yes I read the documentation.

But when you do a clean install of Laravel, testing just works out of the box with nice config settings for testing like selecting another (type of) database.
And it has a SampleTest present from where you can go on and create your own tests.

I really think everyone will benefit if testing is working out of the box and there will be a sample test in mysite for newcomers to see how easy it is to add tests to their project.

I would really like to help with this, but I think there are some framework core inner workings that might make this work not very easy?..

3.2 Beta 1 Install with MySQL warns Silverstripe cannot alter tables

install.php from downloaded Silverstripe 3.2 Beta1 tar.gz
PHP 5.4, MySQL 5.5.42-37.1

Database User was created with "All Permissions"

On checking database connection, install reports Warning:
"Can I ALTER tables - Silverstripe cannot alter tables. This won't prevent installation, however it may cause issues if you try to run a /dev/build once installed."

During lesson 4 build/dev worked OK.

.htaccess should wrap SetEnv calls

The current .htaccess file (https://github.com/silverstripe/silverstripe-installer/blob/master/.htaccess) wraps one of the SetEnv calls in a <ifmodule mod_env.c> check, but doesn't wrap the one inside the mod_rewrite section.

We could either move the SetEnv HTTP_MOD_REWRITE On line up to sit under the other SetEnv call that is properly wrapped, or also wrap this line in the same <IfModule mod_env.c> check as the previous one.

Whitelist GPX and KML files for asset upload

For a website dealing with geographical data it would be useful for .gpx and .kml files to be whltelisted. Can this be added by default in the core build?

"Installing SilverStripe" page doesn't stream

The successful installation page....

Gives the impression it is supposed to stream over the bulleted list ("I am now running through the installation steps"). What actually happens is that the install completes and then displays the list. Since there is no "done!" response either there is no indication that the install has actually succeeded.

PROPOSED: Remove tutorial theme?

Is there any reason to keep the tutorial theme in the installer?

composer/installers change breaks composer create-project and update

The change at composer/installers@316656d40baba4d46ff60f9fc64c52e5ce6b4849 breaks composer create-project and composer update in existing projects. This is the error that is thrown:

[ErrorException]
Argument 1 passed to Composer\Installer\LibraryInstaller::__construct() must implement interface Composer\IO\IOInterface, n  
one given, called in phar:///Users/fred/bin/composer/src/Composer/Plugin/PluginManager.php on line 250 and defined

A temporary workaround is to edit composer.json to require version 1.0.21 of composer/installers or to invoke composer with the "--no-plugins" option. I'm not sure which is worse.

BUG _config/config.yml - After value is not a sequence

Name: mysite
After: 'framework/','cms/'

Results in:

[name] => mysite
[after] => Array(
    [0] => Array([module] => framework, [file] => *, [name] => *)
)

Should be:

Name: mysite
After: ['framework/','cms/']

[name] => mysite
[after] => Array(
    [0] => Array([module] => framework, [file] => *, [name] => *)
    [1] => Array([module] => cms, [file] => *, [name] => *)
)

Redirects to handle direct URI passthroughs are not working on Windows/Apache

In /index.php:56

if($url && file_exists($fileName)) {
    $fileURL = (dirname($_SERVER['SCRIPT_NAME'])=='/'?'':dirname($_SERVER['SCRIPT_NAME'])) . '/' . $url;
    if(isset($_SERVER['QUERY_STRING'])) {
        $fileURL .= '?' . $_SERVER['QUERY_STRING'];
    }
    header($_SERVER['SERVER_PROTOCOL'] . ' 301 Moved Permanently');
    header("Location: $fileURL");
    die();
}

On Windows, line 57 breaks because the file path ends with \ instead of /. I've replaced that line with:

$fileURL = (in_array(dirname($_SERVER['SCRIPT_NAME']), array('/', '\\'))?'':dirname($_SERVER['SCRIPT_NAME'])) . '/' . $url;

and it works beautifully. Sorry I haven't got time to write a full patch for this.

3.2 Beta1 Installation Page Web Links targets

install.php from downloaded Silverstripe 3.2 Beta1 tar.gz

Several information web links do not open in new _blank browser resulting in user moving away from installer and losing values entered in form. (Some links do open in _blank, so behaviour is inconsistent).

Examples:

1. Warning message - "Server requirements" "There are some issues that we recommend you look at before installing, however, you are still able to install the software. Please see below for details. If you are having problems meeting the requirements, see the server requirements."
2. Theme section links:
3. Theme "download another" "You can change the theme or download another from the SilverStripe website after installation"
4. "Simple " and "tutorial" links "Simple - our default theme ready to use, or begin the tutorial."
5. http://docs.silverstripe.org/suggested-web-hosts is a broken link in the first paragraph "Thanks for choosing to use SilverStripe! Please follow the instructions below and you should be up in running in no time.If you get stuck, head over to the installation forum, or check out our list of suggested web hosts known to work with SilverStripe."
6. (FYI) Links are pointing to 3.1 Docs not 3.2 docs. http://doc.silverstripe.org/framework/en/tutorials links to http://docs.silverstripe.org/en/3.1/tutorials/ which reports "These tutorials are deprecated, and have been replaced by the new Lessons section."

Add a RewriteBase to .htaccess

Adding RewriteBase '/' to the htaccess makes sure the system works as planned. Often, without the rewritebase, main.php can't be found due to the nature of PHP basedir.

[4.0.0-alpha3] Uncaught 'ReflectionException' after composer create-project

Hey all,

Just thought I'd try out the latest alpha, and installed it locally using:

composer create-project silverstripe/installer htdocs 4.0.0-alpha3

However, when I bring up the vhost in the browser, I receive a blank page, and PHP's error log reports:

[09-Nov-2016 14:50:23 Australia/Sydney] PHP Fatal error:  Uncaught exception 'ReflectionException' with message 'Class ErrorHandler does not exist' in W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Injector\InjectionCreator.php:13
Stack trace:
#0 W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Injector\InjectionCreator.php(13): ReflectionClass->__construct('ErrorHandler')
#1 W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Injector\Injector.php(558): SilverStripe\Core\Injector\InjectionCreator->create('ErrorHandler', Array)
#2 W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Injector\Injector.php(889): SilverStripe\Core\Injector\Injector->instantiate(Array, 'ErrorHandler')
#3 W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Core.php(103): SilverStripe\Core\Injector\Injector->get('ErrorHandler')
#4 W:\Sites\ss-alpha.dev\htdocs\framework\main.php(148): require_once('W:\\Sites\\ss-alp...')
#5 [internal function]: {closure}(Object(SilverStripe\Core\Startup\ErrorControlChain))
#6 W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Startup\ErrorControlChain.php(216): call_user_ in W:\Sites\ss-alpha.dev\htdocs\framework\src\Core\Injector\InjectionCreator.php on line 13

Perhaps there is a problem with the composer.json version constraints? I managed to get it working just fine with dev-master, so I suspect therein lies the answer. 😉

Add PHP7 builds to all 3.6 compatible core modules

Sorry, couldn't find a better place to add this on a public repo.
Now that we're supporting PHP7 in 3.6, we should consistently run builds against it. Framework already does (https://github.com/silverstripe/silverstripe-framework/blob/3/.travis.yml), but cms, reports, blog etc don't.

Strictly speaking we only need to add PHP7 builds to core modules (since that's the declared support), but ideally we'll test all commercially supported modules against it.

I could imagine PHP7 in 3.x will become popular over the next months, given the massive performance gains. And we should be proactive about this in our modules. I don't expect much work to reach compatibility, it's just a matter of editing a whole bunch of travis.yml files.

URL segments that match folder names don't get re-written

I was creating a test VM so that I could test some code in the blog module like so:

composer create-project silverstripe/installer:3.1.* www
cd www
composer require silverstripe/blog:dev-master

When navigating to the blog page (/blog/) I found that I was just getting directory listing of the blog directory.

I turned off Indexes in the http.conf and it then started to be captured by the rewrite rule after that.

I was using Apache 2.2.15

Is this expected behaviour or a bug?

Assets are not accessible due to 500 error

Apache 2.4.10
PHP 5.5.15

composer create-project silverstripe/installer ssbase

Trying to access assets/Uploads/SilverStripeLogo.png results in a 500 - as would every other item in assets.

[Sat Aug 16 22:14:37.822485 2014] [core:alert] [pid 1848] [client ::1:39063] /home/nightjar/public_html/ssbase/assets/.htaccess: php_flag not allowed here, referer: http://localhost/~nightjar/ssbase/admin/assets/show/1

The offending line is one of the directives attempting to disable the php engine. Commenting allows the asset to load.

Making an issue rather than a PR because not sure that this isn't just a configuration issue (I'm using my distro's defaults, but that doesn't mean all that much).

Update or remove TeamCity references

We’ve a file named phpunit.teamcity.mssql.xml, which I’m guessing doesn’t actually work as the paths contained inside it look wrong. The naming of that file suggests that it serves a very specific setup... does it still add value, or should it be removed?

We do still have a TeamCityListener class in framework.

Call to undefined method SilverStripe\Config\Collections\CachedConfigCollection::setPool()

This is the error i get when i try to install on a Google Instance with Debian 8 and Mysql 5.6 "
Fatal error: Call to undefined method SilverStripe\Config\Collections\CachedConfigCollection::setPool() in /var/www/html/framework/src/Core/Config/CoreConfigFactory.php on line 51"

index.php causes silverstripe to fall back to no mod_rewrite

If you're using mod_rewrite with dynamic URL's index.php causes issues and tries to hijack the urls. To reproduce:

1. install fresh silverstripe instance with default theme

2. click some links

3. eventually links will become index.php/about, etc. Links stop working and resources (css, js etc) stop loading

Perhaps it might be best to check during install if you're using mod_rewrite and remove/rename index.php.

Revert the ext-tidy fix

bb24a91 needs to be reverted as it prevents anyone from using SilverStripe without the tidy PHP extension, which was previously optional

Here's the error you get now, when running our recommended install process.

    sminnee@leon ~/Sites> composer create-project silverstripe/installer ss4-test dev-master
    Installing silverstripe/installer (dev-master 1a5652d81cac41cf9b0d768dd480dad68eca5f02)
     - Installing silverstripe/installer (dev-master master)
       Cloning master

    Created project in ss4-test
    Loading composer repositories with package information
    Installing dependencies (including require-dev)
    Your requirements could not be resolved to an installable set of packages.

     Problem 1
       - The requested PHP extension ext-tidy * is missing from your system. Install or enable PHP's tidy extension.

We need to be clear that the require-dev section of silverstripe/installer applies to all users of SilverStripe and act accordingly.

Sorry for merging the offending PR, I'll create a reversion.

[3.6.0] Web install is missing Database configuration for PHP7

1. composer -s dev create-project silverstripe/installer ~3.6.0
2. continue with Web installation

Web installer reports that MySQLi and PDO extensions are missing for PHP7 (7.1.3)

web install Installing SilverStripe...

I found another problem on win 7 x64.
Composer create-project path 3.1.x-dev --no-dev
It ends with error code 267. OK, all downloaded, I hope.
Fill screen, click Install
Ends, look at screen, please.

3.2.0-rc1 webinstaller deletes "DirectoryIndex disabled" from .htaccess hence breaks URL rewriting

@dhensby

When installing 3.2.0-rc1 WITHOUT using _ss_environment.php, the webinstaller overwrites the following lines:

https://github.com/silverstripe/silverstripe-installer/blob/3.2/.htaccess#L36-L38

As a result, URL rewriting does not work properly.

When using _ss_environment.php, these lines are not overwritten during an install and URLs rewriting works.

See #58.

Cannot create project with the latest SS version

I've always installed SS with the latest version with this command (docs):

composer create-project silverstripe/installer ./httpdocs/

But now it does not work:

[InvalidArgumentException]
Could not find package silverstripe-installer with stability stable.

My installation process is automated (it creates new database, adds additional modules and more) so it is very handy to have ability to install SS with the latest version.

[proposal] deny access to README.md via htaccess

Since Silverstripe installs fully in the web root all files are theoretically accessable.
Wouldnt it be good to deny access to the README.md via htaccess by default then.

You might want to add specific project documentation to the README.md to describe some hacks or specialities to the colleagues.
This renders nice in your private repo but the information is sometimes/often not suited for public, so you would have to deny access yourself, which can be forgotten.
To have this protection by default would be nice, wouldnt it?

Btw, even this: http://www.silverstripe.org/README.md which is currently accessable, i rather find sketchy ;)

Combined build: Add "--no-dev" build

silverstripe/silverstripe-framework#6833 was kind of annoying and painful and I'd like to cover it with an automated test.

In my view it's more of an edge-case and can sit on our combined nightly build, rather than on the framework build executed with every PR.

I would probably describe this as "production smoke test", since it's designed to replicate a production environment, and it doesn't need to cover all unit tests.

I think this test pattern makes the most sense.

• Install packages with --no-dev
• Run dev/build
• Validate that apache can deliver the homepage

The first 2 steps would have covered our failure case, but the 3rd is probably useful too. I expect that some of the test harness can be gleaned from the behat suite.

If you wanted, this could be structured as a behat test:

Given I execute "composer install --no-dev" on the command-line
Then I can execute "framework/sake dev/build" on the command-line
When I visit "/"
I see the text "Welcome to SilverStripe! This is the default homepage."

Pull requests

• #219

RedirectMatch blocking some Themes files

The addition of the RedirectMatch rules by 2352317 mainly RedirectMatch 403 /vendor(/|$) blocks any files in a vendor folder. This cause issues for example in themes where JS files for example could be served from a vendor subfolder.

An example is for a Themes using the HTML5 Boilerplate where JQuery and Modernizer are saved in a vendor folder.

Maybe a better solution is to use something like ^/?vendor(/|$) filtering only request starting with vendor?

web installation ss 3.1.7

Hi,

I don't understand, I don't understand, I don't understand!
Last version and again and again still base web install problems!

[17-Nov-2014 11:43:47 Europe/Bratislava] PHP Fatal error: Call to undefined method stdClass::write() in D:\Www\www.ss317.sk\framework\dev\install\install.php5 on line 1426

Windows 64 bit, Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.23

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 130968 bytes) in /var/www/vhosts/sendasoft.com/httpdocs/framework/core/manifest/ConfigManifest.php on line 490

Plesk
CentOS 5.9
php.ini memory_limit 128M

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 130968 bytes) in /var/www/vhosts/sendasoft.com/httpdocs/framework/core/manifest/ConfigManifest.php on line 490

Increasing memory_limit (php.ini) does not solve the problem.

If I try to install 3.0.3 this problem does not occur.

Regards,
Jose A.

SS4 installer: environment variables help link incorrectly routes to SS3 docs

Quick note: In the Database Configuration section of the installer, the help link associated with the "Use environment variables for configuration" checkbox routes user to old SS3 _ss_environment.php docs.

web installation ss 3.1.8

It's shame! It's shame! It's shame!

I think, it must be reopened for ss 3.1.8.
It has still error: never ending loop after last redirect (I think at line: 1462).
Loop ends after 6 mins.
After entering url, css not loaded.

Maybe to add to _config.php file can help with css:
............
i18n::set_locale('sk_SK');
Config::inst()->update('Director','alternate_base_url','/');
...........

Windows 64 bit, Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.23

[4.0 alpha 2] Requirements Failure in install.php

I was trying to install a fresh copy SS4 alpha 2 and the requirements section of the install screen shows an unhelpful failure

I'm using an ss_enviroement file, but this is still an issue even if I uncheck that option.

Block dev/test configuration files?

In addition to blocking common log files (#153) I would like to discuss also blocking all files in the webroot that do not need to be public (including php unit files, markdown files, .gitignore, build.xml) and so on.

Some developer, not knowing the ramification, might accidentally expose sensitive information through one of those files.
One might argue that it's the developers job to take care of blocking files that should not be public. But considering that this repository is primarily intended for people getting started with SilverStripe, I think more secure and restrictive defaults are appropriate.

Add combined build.

See silverstripe/silverstripe-framework#6758 for context.

Acceptance criteria

On the master branch...

• silverstripe/installer has a travis run that executes all PHPUnit & Behat tests from all modules within it
• Only PHP 5.6 + MySQL and PHP 5.6 + PostgreSQL need be run: the full gamut of combinations can be left to the individual module builds.
• This build is triggered to run daily, unless it has otherwise been run in the last day (travis now has this feature)

Once this is done, the CMS tests in framework can be removed.

Tasks

• At least one PGSQL build
• Add framework behat tests to installer
• Add cms behat tests to installer
• Add asset-admin behat tests to installer
• setup travis artifacts upload to installer

PRs:

• silverstripe/silverstripe-asset-admin#484
• silverstripe/silverstripe-graphql#99
• #178
• silverstripe/silverstripe-framework#6962
• silverstripe/silverstripe-graphql#101

index.php does not redirect properly when positioned in the server's webroot

From http://open.silverstripe.org/ticket/3953

Needs to be tested with latest implementation. If useful use.

=== modified file 'index.php'
--- index.php 2009-04-17 15:36:30 +0000
+++ index.php 2009-04-29 20:14:35 +0000
@@ -54,7 +54,10 @@

• Very quickly pass through references to files
  */
  if($url && file_exists($fileName)) {
  • $fileURL = dirname($_SERVER['SCRIPT_NAME']) . '/' . $url;
  • $baseURL = dirname($_SERVER['SCRIPT_NAME']);
  • if($baseURL == "" || $baseURL == "/") $baseURL = "";
  • $fileURL = "$baseURL/$url";
    header($_SERVER['SERVER_PROTOCOL'] . ' 301 Moved Permanently');
    header("Location: $fileURL");
    die();

Revert #78

This causes all http requests (on mod_php) to only work through index.php. Removing index.php breaks the site.

Ignoring assets/* means .htaccess file is not retained

Ignoring the entire contents of assets means that the .htaccess and web.config files are not retained in repos that use the installer.

These files should be retained.

Releases don't pass tests

I continually struggle to get framework and CMS to pass tests on my own deployments of websites.

To check the issue I've created a project as so:

mkdir ~/test
composer create-project silverstripe/installer:3.1.* ~/test
cd ~/test
composer require phpunit/phpunit:~3.7@stable --dev
./vendor/bin/phpunit

Output:

WARNING: Manifest not flushed. Add flush=1 as an argument to discover new classes or files.

PHPUnit 3.7.37 by Sebastian Bergmann.

Configuration read from /var/www/test/phpunit.xml.dist

..I.EE..EEE.EEEE........E....EE....E.....E.EE.....EE..EEEEEE.   61 / 1603 (  3%)
....................EE.....EE..E.............................  122 / 1603 (  7%)
.......................................................EE....  183 / 1603 ( 11%)
...............EE.EEE.E...............E......................  244 / 1603 ( 15%)
........I...........E....................................I...  305 / 1603 ( 19%)
.............................I...............................  366 / 1603 ( 22%)
..S..........................................................  427 / 1603 ( 26%)
..................................E..........................  488 / 1603 ( 30%)
...................................................EE.....EE.  549 / 1603 ( 34%)
.E...................................E....EEEEEEEE.E.........  610 / 1603 ( 38%)
.................EE...........................EE..EE.........  671 / 1603 ( 41%)
.......................IEEFE..................EE.......EE....  732 / 1603 ( 45%)
..............EE.............E...EEEEEE........EE..........EE  793 / 1603 ( 49%)
.EEEEEEEE..EEE....EEE.EE..EEEEEE........EE...EEE.EEE.........  854 / 1603 ( 53%)
......................E......................................  915 / 1603 ( 57%)
...I.........................................................  976 / 1603 ( 60%)
............................................................. 1037 / 1603 ( 64%)
............................................................. 1098 / 1603 ( 68%)
............................................................. 1159 / 1603 ( 72%)
............................................................. 1220 / 1603 ( 76%)
.........SSSSSSSSSE.......................................... 1281 / 1603 ( 79%)
S............................................................ 1342 / 1603 ( 83%)
............................................................. 1403 / 1603 ( 87%)
.....................E....................................... 1464 / 1603 ( 91%)
...................I................S..EEEEEEEEEEE........... 1525 / 1603 ( 95%)
..........................EE.................EE.....EF...E.EE 1586 / 1603 ( 98%)
................

Time: 9.94 minutes, Memory: 306.50Mb

There were 133 errors:

For reference see https://github.com/BetterBrief/silverstripe-test/ for a travis implementation of my script.

Is there any kind of release script that ensures that the tagged CMS/Framework actually pass tests together?

Apply "DirectoryIndex disabled" only to root directory

If you have a subfolder with a separate script (non-Silverstripe), you can add for example RewriteRule ^shop - [L] to make requests pass through to there, avoiding getting handled by SilverStripe.

However, the current DirectoryIndex disabled rule in .htaccess prevents index pages in such subdirectories from working.

Could that rule be changed so that it only applies to the root of the SilverStripe installation?

Document common YAML config options

From http://open.silverstripe.org/ticket/2577#no3,

Drupal and Wordpress include a few common options in the config file by default commented out so users can easily make changes. We could include common yaml configuration files in the installer with options. Director::addRules(), Environment configuration.. Might also help users migrate to the new system.

Silverstripe install and display_errors option problem

CentOS 5.9

SilverStripe install:

PHP Configuration Show All Requirements All Requirements Pass but 1 Warning

display_errors option display_errors is set to 'on' in php.ini. Unless you're in a development environment, this should be turned off, as it can expose sensitive data to website users.

phpinfo() return:

default_mimetype text/html text/html
disable_classes no value no value
disable_functions no value no value
display_errors Off Off
display_startup_errors Off Off

What can happen?

Regards,
Jose A.