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.
API Add HasRequestHandler interface
API Refactor Link() and url handling behaviour from Controller into RequestHandler
API RequestHandler classes now must define url_segment to have a default Link()
API Clean up redirectBack()
This page (currently) for example breaks the code block whenever you mix spaces and tabs for indentation (which is currently part of the 3.x style guideline) - it makes updating existing code examples in the docs quite difficult: https://docs.silverstripe.org/en/3/developer_guides/templates/requirements/
GFM isn't as picky - this PR replaces with it.
API Substitute Zend_Locale with Locale / NumberFormatter
API Substitute Zend_Date with IntlDateFormatter
API Added DBTIme::Nice12, FormatFromSettings
API Added Short() method to DBDate / DBTime / DBDatetime
API Add Date::getTimestamp()
API Added setSubmittedValue api for FormField
API Add second arg to base FormField::setValue()
API Major refactor of i18n into component data parts
API Implement Resettable interface to reset objects between tests
ENHANCEMENT Changed DBField::create_field return type to `static` to support better type hinting
ENHANCEMENT i18nTextCollector supports __CLASS__
* Remove module specific subthemes documentation as it's removed
* Added notes about cascading theme configuration
* Update links to Themes listing to point to addons
* Remove references to tarballs, and put composer publishing instructions in place instead
API Implement enhanced pluralisation
Remove Zend_Translate and all Zend dependencies from i18n
Deprecated $context from i18n::_t()
Warn on missing default string for i18n::_t()
SQL Server is still community supported, and we have IIS 7+ in our “server requirements”, which won’t change.
But the WebPI installer is rarely used in practice, and doesn’t provide the best user experience for Windows users
compared to other installation options. Given it sucks up time on every release process. this should be removed.
The role moves around based on current availability.
@tractorcow has done most of the last releases,
but a separate team (headed by @dhensby) will be
responsible for 3.x releases.
There's not really much point to declaring a release maintainer,
unless there's disagreements in the core team where we need
an arbitrator. So far those conflicts have been resolved
on individual tickets (e.g. what should go into a release),
and the process for that seems to work well.
* API Replace existing Email and Mailer classes with SwiftMailer powered email system
* DOCS New Email docs
* Initial feedback from Damian
* Making Mailer an interface
* Templates relocated
* Round of feedback
* More robust approach to plain parts
* Revert changes to TestMailer
The "repositories" key makes "composer update" ridiculously slow with the amount of tags and branches we have in core,
so unfortunately we can't rely on it. I've also removed the thinkapp-based instructions about working with git,
since it's now fairly widespread knowledge, and better documented elsewhere.
Note that I've chosen to rename the "origin" remote to "upstream" in order to keep in line with
the contribution documentation on help.github.com (even if it's a bit more clumsy to explain upfront)
Now that Mandrill has become a paid part of Campaign Monitor it makes sense for us to recommend the free alternative SparkPost.
The package I've linked to is by the same author as the original Mandrill package.
Created a generic DataObject FormFactory interface that can be substituted in place of getCMSFields. Different FormFactories can depend on different kinds of context, such as
'Record' or 'Controller' - it's the responsibility of the code calling the factory to interpret and
supply this context.
The expected use-case is that rather than overriding getCMSFields(), developers can
change CMS UIs by manipulating the FormFactory associated with the given DataObject.
This is an experimental UI and may change before 4.0 stable is released.
API Remove DataObject::validateModelDefinitions, and move to DataObjectSchema
API Remove deprecated 3.0 syntax for addSelect()
API made DataList::createDataObject public
API Move component parsing logic to DataObjectSchema
API Remove support for triangular has_many / belongs_many relationships
SCSS linting now uses the node-based sass-lint tool, since we’re
shifting away from CodeClimate.
This has the benefit of not requiring a ruby gem on dev tools -
everything is provided as npm dev dependencies.
This was also necessary to run the linting inside travis.
The 'admin' module will be split off from 'framework',
where 'framework' only provides (mostly) frontend-agnostic PHP classes.
For example, HTMLEditorField.php has a TinyMCEConfig.php driver,
but doesn't come with its own JS includes.
The JavaScript i18n functionality in SilverStripe is used in the CMS as well as form field implementations.
Form fields used to include their own JavaScript for usage outside of CMS. This now requires custom build tooling in a project.
Hence there's no need for an i18n shim (i18nx.js), since the CMS always uses i18n support.
We've removed the ability to directly reference JS and CSS files
for form fields and other SilverStripe features in favour of a common bundle built by Webpack.
The logical next step is to make the framework module free of frontend dependencies,
which should simplify its operation, and avoid another time intensive "npm install" on a module.
This has been made obsolete, since those files are all included in the main bundle (see bundle-lib.js).
They should not be referenced individually (e.g. through Requirements::block() or Requirements::javascript()).
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Workaround for bad font path in bundle.css:
ExtactTextPlugin didn’t work as well with a subfolder reference in the
filename. This is just a short-term fix and could probably be improved
to put bundle.css back in the styles subfolder.
Webpack handles images & fonts:
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Clarify docs on spriting and webfonts:
We've decided to remove sprity since it comes with hundreds of dependencies,
and needs compilation within the "npm install" - dragging out the already overweight
install process, and making the resulting node_modules/ folder less portable between systems.
The bundle is generated by running “webpack” directly - gulp is no
longer needed as an intermediary. The resulting config is a lot shorter,
although more configuration is pushed into lib.js.
Modules are shared between javascript files as global variables.
Although this global state pollution is a bit messy, I don’t think it’s
practically any worse than the previous state, and it highlights the
heavy coupling between the different packages we have in place.
Reducing the width of the coupling between the core javascript and
add-on modules would probably be a better way of dealing with this than
replacing global variables with some other kind of global state.
The web pack execution seems roughly twice as fast - if I clear out my
framework/client/dist/js folder, it takes 13.3s to rebuild. However,
it’s not rebuilding other files inside dist, only the bundle files.
CSS files are now included from javascript and incorporated into
bundle.css by the webpack. Although the style-loader is helpful in some
dev workflows (it allows live reload), it introduces a flash of
unstyled content which makes it inappropriate for production.
Instead ExtractTextPlugin is used to write all the aggregated CSS
into a single bundle.css file. A style-loader-based configuration could
be introduced for dev environments, if we make use of the webpack live
reloader in the future.
Note that the following features have been removed as they don't appear to be
necessary when using Webpack:
- UMD module generation
- thirdparty dist file copying
LeftAndMain.js deps: Without it, ssui.core.js gets loaded too late,
which leads e.g. to buttons being initialised without this added behaviour.
