Gábor Hojtsy devoted a special blog post to describe this innovation and called it “huge.”
So if anyone asks what’s new in Drupal 8.7.7, it’s the core versioning support that comes to mind first. Core version requirement key introduced in Drupal 8.7.7!Īs of Drupal 8.7.7, providing Drupal 9 readiness reaches a new level. And it's great to notice that more contributed projects are D9 compatible!Īccording to Gábor Hojtsy, the famous Drupal contributor and product manager, their number increased from 48% in March to 54% in July 2019. Among the examples are the drupal_set_message() function deprecation or the Drupal 8.8.x-dev compatibility with the new Symfony 4.3.3.īeing up-to-date with all of this means complete and instant Drupal 9 readiness for modules and themes. The community is gradually building D9 in D8 while deprecating older APIs and functions and supporting new releases of third-party dependencies. More details below! Drupal 9 readiness: how are things going for modules? It allows developers to declare their project compatibility with Drupal 8 and Drupal 9. The newly released 8.7.7 version introduced the core versioning support. We are glad to announce that there is one more big advancement in the Drupal 9 readiness field.
#Drupal core version upgrade#
One of the key points in this plan is to prepare for Drupal 9 with the Upgrade Status module to make sure the site uses no deprecated code. Website owners and developers start planning for Drupal 9. Review the release notes for your Drupal version if you have issues accessing files or image styles after updating.The news about the forthcoming Drupal 9 release in June 2020 is the hottest topic in the Drupal world. Some sites may require configuration changes following this security release. The recommended and default setting is FALSE, and Drupal core does not provide a way to change that in the admin UI. This vulnerability is mitigated by the fact that it only applies when the site sets (Drupal 9) $config or (Drupal 7) $conf to TRUE. However, some contributed modules provide additional file systems, or schemes, which may lead to this vulnerability. Access to a non-public file is checked only if it is stored in the "private" file system. In some situations, the Image module does not correctly check access to image files not stored in the standard public files directory when generating derivative images using the image styles system. If you do not require or expect redirects to be followed, one should simply disable redirects all together. Users unable to upgrade may consider an alternative approach to use your own redirect middleware, rather than ours.
#Drupal core version series#
Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any `Cookie` header manually added to the initial request would not be stripped. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the `Cookie` header on. In affected versions the `Cookie` headers on requests are sensitive information. Guzzle is an open source PHP HTTP client.
Alternately users may simply disable redirects all together if redirects are not expected or required. Users unable to upgrade may consider an alternative approach which would be to use their own redirect middleware.
Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host. This is much the same as to how we don't forward on the header if the host changes. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. In affected versions `Authorization` headers on requests are sensitive information.
0 kommentar(er)
