-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove GraphQL from the CMS #1799
Comments
And asset-admin will still use it or also switch to standard controllers? |
Any supported module, including asset-admin, that uses some graphql for some of its functionality will standardise entirely on standard controllers for CMS 6 I've linked the PRs that were used in a POC to prove viability in the description - I'll continue using these same PR's in this issue. That includes a PR for asset-admin |
Webpack PR merged, reassigning to Steve to rebuild dist files |
@emteknetnz #1802 needs rebasing - after that everything is ready to go! |
@emteknetnz There's also an acceptance criteria I think might have been added after refinement:
Not sure what that's about... do you need to do anything more for this? |
Have rebased blog PR, and raised new CMS 5 PRs for asset-admin and versioned to use the correct version for deprecation notices |
PRs merged |
GraphQL is used inconsistently in the CMS for some of the XHR requests made by react components. The majority of XHR requests are currently made to "regular Silverstripe controller endpoints", which also includes "Form Schema" endpoints used to process Form requests.
This lack of standardisation has lead to inefficiencies in development an maintenance for the CMS Squad. There has also been a fair bit of negative feedback from several developers in the community who think they're supposed to do all admin XHR requests using GraphQL, which has proven to be very difficult for people to learn and use.
This card is about removing GraphQL from the CMS entirely and be replaced with "regular Silverstripe controller endpoints" in the name of standardisation.
Removing GraphQL from the CMS also means that projects no longer need to have the
.graphql-generated
directory by default.Acceptance criteria
or silverstripe/recipe-kitchen-sink(will probably still be created for recipe-sink because we're including the graphql module)New issues created
CMS 5 PRs
CMS 6 multi PR CI
CMS 6 PRs
Other PRs
Notes
The text was updated successfully, but these errors were encountered: