* DOCS: Add new graphql 4 docs
* Reorganise docs
* Docs done
* Basic graphql index page
* TOC for getting started
* show folders on graphql index page
* Add middleware note
* Docs update
* Update docs to reflect flushless schema
* Docs updates
* Docs for getByLink
* Query caching docs
* Docs on nested operations
* update docs for new graphql dev admin
* Docs for configurable operations
* Replace readSiteTrees with readPages
* Schema defaults docs
* Docs for inherited plugins
* Docs for customising *
* Docs for field whitelisting
* Change whitelist word
* New docs on modelConfig
* Document dev/build extension
* Document default/global plugins
* Document new input type fields config
* Apply suggestions from code review
Co-authored-by: Andre Kiste <bergice@users.noreply.github.com>
* Note about when procedural schema gets built
* Fix link
* Apply suggestions from code review
Co-authored-by: Andre Kiste <bergice@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Andre Kiste <bergice@users.noreply.github.com>
* DOCS Note about plugins in custom queries
* DOCS Note about filter and custom resolvers
* DOCS Note about canview paging
* DOCS Updated guidance on _extend
See https://github.com/silverstripe/silverstripe-graphql/issues/296
* Apply suggestions from code review
Co-authored-by: Andre Kiste <bergice@users.noreply.github.com>
* DOCS Pre-release warning
Co-authored-by: Ingo Schommer <ingo@silverstripe.com>
Co-authored-by: Andre Kiste <bergice@users.noreply.github.com>
Co-authored-by: Ingo Schommer <me@chillu.com>
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
DOC HistoryViewer: explain "magic names"
GraphQL scaffolding uses names consisting of the first part of the namespace and the classname, but to inject it to the HistoryViewer field you need to use the database table name.
Co-authored-by: Steve Boyd <emteknetnz@gmail.com>
- 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
* #3236 Added dev/config view
* Refactored use of echo to
* Added config/audit for matching missing property definitions in the current config
* Minor enhancements to dev/config implementation
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.
* DOC Add extra information on how to customise an file HTTP response
* Apply suggestions from code review
Co-authored-by: Robbie Averill <robbie@averill.co.nz>
* Add wildcard URL parameter matches for url_handlers
* Extra tests for wildcard parameters
* Add a PHP warning if more params appear after wildcard param
Silverstripe Forms allow malicious HTML or JavaScript to be inserted
through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting)
on some forms built with user input (Request data). This can lead to phishing attempts
to obtain a user's credentials or other sensitive user input.
There is no known attack vector for extracting user-session information or credentials automatically,
it required a user to fall for the phishing attempt.
XSS can also be used to modify the presentation of content in malicious ways.
I am not quiet sure if this is needed but if you want to only add the custom action to the GridField action menu than you need to add the extra classes otherwise it would add it to the action menu and to the gridfield.
Added a notice to the "Owner" section that will remind developers of the limitations of the owner system when it comes to private and protected properties and methods
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
As of SS4.0.0 and the introduction of TrustedProxyMiddleware, the default now if no trusted proxies are defined is that nothing is a trusted proxy, whereas in SS3 a missing declaration was treated as everything being allowed.
* 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)
We decided during implementation not to check permissions explicitly on cascading objects due to performance concerns.
For example, when publishing a page with embedded images, publish permissions on the image are implied - even if Image->canPublish() would return false for this author.
See https://github.com/silverstripe-security/security-issues/issues/57