- 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>
Otherwise the code is output as html, and displays as a missing image. The alt attribute is required for image tags, whereas self closing is no longer required for html5.
- create a new documentation section explaining the "cached" block
- clean up the Performance documentation section,
moving explanations about "cached" block away,
adding new warnings and recommendations
The method of including a Layout template into a full template file isn't documented, and isn't intuitive especially if you have come from the SS3 way of doing it via $this->customise($data)->renderWith(['MyCustomTemplate', 'Page']); Adding this as an example will help people add layout templates to Controller actions, and form responses where a custom layout needs to inherit it's parent template.
See https://github.com/silverstripe/silverstripe-framework/issues/9232.
Also simplifies composer instructions a bit:
- Removes composer update --no-dev references, that's a bit of an edge case that people can just discover on getcomposer.org if they need it
- Changed example from the unused and oudated silverstripe/forum to silverstripe/blog
- Updated example versions to 4.x
- Remove "updating composer" section, it now tells you if its out of date
- Remove ss-auto-git-ignore module reference. The module hasn't been updated in ages, and it's much less necessary now that all relevant modules are on composer
- Add .env example config to getting started docs, I didn't realise it was stripped from the default --prefer-dist composer install
* 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)
