API: Add HTTPOutputHandler::setCLIFormatter
Fixes https://github.com/silverstripe/silverstripe-framework/issues/6835
This provides detailed errors (but not warnings or notices) in CLI calls
on live environments.
It does this by adding a 2nd argument to our output handler,
CliFormatter. This formatter will be used when Director::is_cli() is
true.
Was missed from the removal of PHPUnitWrapper:
a16588aac3
Original reason for this: Don't fail dev/build without phpunit
When you install a SilverStripe project with "composer install --no-dev",
the PHPUnit dependency gets skipped. Which means the PHPUnit_Framework_TestListener
interface doesn't exist. The SilverStripe Classloader might still include
SapphireTestReporter which relies on this interface, which then breaks execution.
SS3 fixed this by NOT defining the class in the first place.
This has been removed in 2fdc96a0de (diff-82b3f89e8e5ae090c93e9c3a2ba8aa36L3),
as part of a PHPUnit version upgrade - but without an apparent fix to replace this.
API Remove Director::$test_servers / $dev_servers
API Remove MODULES_PATH / MODULES_DIR constants
ENHANCEMENT Injector backtick syntax now supports environment variables as well as constants
Fixes#6588
- Amending best practices for secure coding to enforce HTTPS
- Add security headers to enforce HTTPS
- Ensure secure cookies are used.
- Added links for testing, changed documentation as part of peer review.
- Arrange headers to work with HTTP interface.
- fixed Cache-Control case
- Added reference to Secure Sessions.
- Replaced Cardinality with unique
- Fixed innacurate reference to decendant.
- Consistent spelling
- Databases over DBMSs
As of SS4 I recommend that we clarify the level of support we provide
for MSSQL. The testing coverage of MSSQL and production use of it in
systems supported by the core team both seems very low.
MSSQL support was a lot more important in a pre-cloud-hosting world, but
these days our recommendation is to run SilverStripe on a stack that its
designed to work with rather than trying to fit it into your existing
hosting infrastructure.
It's more standard to have this file in the webroot.
It's technically markdown compatible text (e.g. asterisk bullet points),
but there's not much point in rendering it via markdown.
If you use the Github "new repo" dialog, it'll create the file without
an extension, so that's pretty much considered the standard.
