- Remaining Developer Guides and Upgrading
- SilverStripe in a namespace or api has not been change
- To keep PRs easier no formatting was changed
Update merge conflics with two files
Update Silverstripe Ltd, Silverstripe Cloud and Silverstripe CMS
Silverstripe CMS Ltd > Silverstripe Ltd
Silverstripe CMS Platform > Silverstripe Cloud
Silverstripe CMS Framework > Silverstripe CMS
Resolve merge conflict
Remove Framework from Silverstripe CMS Framework
- 3 files
Change SilverStripe CMS to Silverstripe CMS
* DOCS Clearer sysadmin guidance for "packaging"
We have all kinds of fun fallbacks that attempt to create supporting files in production environments.
The latest point of contention is dev/build automatically creating files in .graphql/ and public/_graphql/
if those don't exist. That should be regarded as a last resort option to allow introduction of GraphQL v4 in the CMS 4.x release line.
At least since CMS 4.1, we need some form of "packaging" for generated files (public/_resources),
or committing these into the codebase, so let's call that out for anyone running CMS infra.
* Add trailing slash
Co-authored-by: Aaron Carlino <unclecheese@leftandmain.com>
This was previously documented in the 4.7.0 changelog, but will be an ongoing
concern for developers, so it makes sense to replicate in a more obvious place.
Note that it's currently unclear whether Silverstripe Cloud or CWP support this,
but it shouldn't block us from recommend this in the open source project.
It's documented in the "server requirements", which should make it pretty
clear that this requires you to have control over server configuration (or check with those that have).
See https://github.com/silverstripe/silverstripe-framework/issues/7710
* Remove installer
* Remove exposed install files
* Replace Dev/Install classes still in use
* Update changelog
* FIX make the grid field actions consistent to what they look like on pages
Resolves https://github.com/silverstripe/silverstripe-admin/issues/904
* Docs changes
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
This was discussed and agreed in #8556. The two changes are
composer.json and travis. The docs have also been updated. No other
code changes have been made.
Too icky to keep updated as version numbers change. It's really just a matter of what PHP version supports which OS, from a SilverStripe side we don't have any constraints there. Well, technically Windows 3.11 won't work because the filesystem will fall over, but otherwise LAMP/WAMP is pretty forgiving.
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.
- Removes thirdparty dependency History.js
- Adds thirdparty dependency Page.js to manage client-side routing
- Adds a wrapper around Page.js for SilverStripe specific behaviour
- Increased minimum browser requirement to IE10. Native HTML History API routing requires IE10 or newer (necessitated by removal of History.js)
- PJAX pannel loading via now uses promises rather than callbacks
- Adds getClientConfig method to LeftAndMain which can be used to pass config from to the front-end client
