tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity
8b28c5647b
silverstripe-framework/docs/en/04_Changelogs/4.8.0.md

3.6 KiB
Raw Blame History

4.8.0 (Unreleased)

Overview

New features

Support for silverstripe/graphql v4

The silverstripe/graphql module to drive various parts of the CMS UI, as well as building your own GraphQL APIs in Silverstripe projects.

The CMS currently ships with silverstripe/graphql:^3, which is stable but slow for larger schemas. The module was rewritten from scratch with performance in mind (see goals and pull request). The resultingsilverstripe/graphql:^4 release is currently in a alpha stage. We encourage everyone to get started, read our new GraphQL documentation, provide feedback and help us stabilise the module.

In order to facilitate the new module release, most GraphQL helper classes to drive the CMS UI have been marked as deprecated, and moved to GraphQL/_legacy folders within core modules. The GraphQL schema under admin/graphql has been altered slightly to enable forwards compability, with lower-camelcase field names, and a different filter argument structure. In the unlikely case that you are relying on those classes or queries directly, consider upgrading to silverstripe/graphql:^4. Your own GraphQL schemas outside of admin/graphql should not be affected by the changes if you choose to stay on silverstripe/graphql:^3 for the time being.

We are planning to require the use of silverstripe/graphql:^4 in a future CMS 4.x release.

GraphQL 3 code moved to _legacy folder

You will notice that many of the core modules now have a _legacy directory in their root. This is a temporary fix that we have applied to satisfy the competing interests of semver and PSR-4 autoloading.

Because the semver contract precludes changing the fully-qualified names of any classes, we need to keep GraphQL 3 code untouched. But GraphQL 4 code often contains classes of similar or identical names, e.g. "ReadFilesResolver", or something to that effect. Further, this backward compatibility creates a common demand for the canonical namespace "GraphQL.", e.g. SilverStripe\AssetAdmin\GraphQL. It didn't seem appropriate to put old code in the "GraphQL" space, and new code in a less obvious place, like SilverStripe\AssetAdmin\GraphQL4.

A simple fix would have been to stuff all the GraphQL 3 code into code/GraphQL/_legacy and use classmap to shim the PSR-4 autoloader, but this is no longer supported in Composer 2.0.

Thus, we ended up with the "least bad" solution, which was to create a parallel path resolution for GraphQL 3 code in the _legacy folder, alongside code/ / src/.

It is likely that in the future, we will mandate the use of GraphQL 4 in Silverstripe CMS, and remove this shim. We expect this happen within just one minor release, making _legacy/ a very short-lived workaround.

Enhancements

Default time period for log in form "remember me" checkbox reduced from 90 to 30 days

Based on feedback from users, we've reduced the time period of the "remember me" checkbox on the login form from 90 to 30 days. This value is configurable via SilverStripe\Security\RememberLoginHash::token_expiry_days.