tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-06-26 06:29:24 +02:00
Code Issues Projects Releases Wiki Activity

Merge pull request #10339 from creative-commoners/pulls/4/graphql-generated-docs

Browse Source 
DOCS Correct references to graphql v4 schema build dir
This commit is contained in:
Maxime Rainville 2022-06-01 21:09:10 +12:00 committed by GitHub
commit 6c09173647
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/en/00_Getting_Started/00_Server_Requirements.md
View File

@ -92,14 +92,20 @@ also needs write access for the webserver user to the following locations:
[Manifests](/developer_guides/execution_pipeline/manifests), [Object Caching](/developer_guides/performance/caching)
and [Partial Template Caching](/developer_guides/templates/partial_template_caching).
See [Environment Management](/getting_started/environment_management).
* `.graphql-generated`: silverstripe/graphql version 4 introduces this directory. This is where your schema is
stored once it has been built. Best practice is to create it ahead of time, but if the directory doesn't exist
and your project root is writable, the graphql module will create it for you.
[info]
If you are still using silverstripe/graphql 3.x, you do not need the `.graphql-generated` directory.
[/info]
If you aren't explicitly [packaging](#building-packaging-deployment)
your Silverstripe CMS project during your deployment process, additional write access may be required to generate supporting
files on the fly. This is not recommended, because it can lead to extended execution times as well as cause
inconsistencies between multiple server environments when manifest and cache storage isn't shared between servers.
Note that permissions may be required for other directories for specific functionality - for example graphql v4 requires
write access to the special `.graphql-generated` directory by default, and if you use the
Note that permissions may be required for other directories for specific functionality - for example if you use the
[i18nTextCollector](api:SilverStripe\i18n\TextCollection\i18nTextCollector) you will need to provide write access to the
relevant i18n `lang` directories.
@ -162,10 +168,10 @@ noisy, here's some pointers for auto-generated files to trigger and include in a
* `public/_resources/`: Frontend assets copied from the (inaccessible) `vendor/` folder
via [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin).
See [Templates: Requirements](/developer_guides/templates/requirements#exposing-assets-webroot).
* `.graphql/` and `public/_graphql/`: Schema and type definitions required by CMS and any GraphQL API endpoint.
Generated through
[silverstripe/graphql v4](https://github.com/silverstripe/silverstripe-graphql). Triggered by `dev/build`, or
a [GraphQL Schema Build](/developer_guides/graphql/getting_started/building_the_schema).
* `.graphql-generated/` and `public/_graphql/`: Schema and type definitions required by CMS and any GraphQL API endpoint.
Generated by
[silverstripe/graphql v4](https://github.com/silverstripe/silverstripe-graphql). See
[GraphQL Schema Build](/developer_guides/graphql/getting_started/building_the_schema).
* Various recipes create default files in `app/` and `public/` on `composer install`
and `composer update` via
[silverstripe/recipe-plugin](https://github.com/silverstripe/recipe-plugin).

2
docs/en/02_Developer_Guides/19_GraphQL/01_getting_started/03_building_the_schema.md
View File

@ -89,7 +89,7 @@ Though it doesn't contain any highly sensitive data, we recommend you block this
### Viewing the generated code
By default, the generated code is placed in the `.graphql/` directory in the root of your project.
By default, the generated code is placed in the `.graphql-generated/` directory in the root of your project.
It is not meant to be accessible through your webserver (which is ensured by dot-prefixing)
and keeping it outside of the `public/` webroot.