Quantcast
Channel: Releases for Drupal core
Viewing all articles
Browse latest Browse all 584
↧

drupal 8.8.0

December 4, 2019, 1:06 am
$
0
0

Release notes

This is a minor version (feature release) of Drupal 8 and is ready for use on production sites. Learn more about Drupal 8 and the Drupal 8 release cycle.

This minor release provides new improvements and functionality without breaking backwards compatibility (BC) for public APIs. There may be changes in internal APIs and experimental modules that require updates to contributed and custom modules and themes per Drupal core's backward compatibility and experimental module policies.

Minor releases may include string changes and additions. Translators can review the latest translation status on localize.drupal.org.

Important update information

Site and module owners planning to update to this release should take note of the following important information. If you encounter any issues when updating to this release, review the known issues below as well. The known issues will be updated if any regressions are discovered.

Drupal 8.8 is the last minor version of Drupal 8 before the earliest targeted release date for Drupal 9.0.0. For this reason, any new deprecations added to Drupal 8.9.x or later will be targeted for removal in Drupal 10.0.x instead, and numerous significant deprecations and other changes preparing the codebase for Drupal 9 have been added in this release.
Site update and module owners planning to update to this release should take note of the following important changes:

Changes to path aliases and a critical note for sites using the Pathauto contributed module

  • If you have the contributed Pathauto module enabled, you must update to the latest version of Pathauto before you update to Drupal 8.8.0. Failure to update Pathauto before updating core could result in data loss. Drupal 8.8.0 declares a conflict with Pathauto 8.x-1.5 or lower for this reason.

  • The Path Alias core subsystem has been moved to the path_alias module. An upgrade path is provided from Drupal 8.7 for this change.

  • Custom URL aliases are now provided by a new revisionable and publishable path_alias content entity type. Path alias services have been kept in place for backwards compatibility, and path alias hooks have been deprecated.

  • As part of the change to path aliases, path alias administration forms have been converted to generic entity forms. This means form IDs and form class names have changed, so custom code needs to be updated for any hook_form_alter() or hook_form_FORM_ID_alter() implementations that were using the previous form IDs. Additionally, some path routes have been deprecated and replaced by generic entity route.

For more information on the changes to path aliases including update instructions for developers, see the change record on the path alias entity conversion and the change record on moving the subsystem to a module.

Updating Drupal is no longer supported for sites on PHP 5.5 or 5.6

PHP 5.5 and 5.6 support was officially removed in 8.7, but Drupal still allowed sites to apply security updates on those PHP 5 versions. Drupal 8.8.0 ends that support and updates will now fail if servers are not updated to at least PHP 7.0.8.

The recommended PHP version is now PHP 7.2, as PHP 7.0 and 7.1 will no longer receive security coverage from the PHP maintainers. See the Drupal 8 PHP requirements documentation for more information.

New info file key for Drupal 9 and semantic versioning compatibility

A new core_version_requirement has been added to info.yml files. This key replaces the core key for projects that only support Drupal 8.8 onward (including Drupal 9). It can be used in addition to the core key for projects that want to both specify compatibility with Drupal 9 and remain compatible with Drupal 8.7.6 and earlier. Read more in the change record for the new core_version_requirement key.

New browser support policy

Drupal core's browser support has been updated and support for some uncommon older browser versions has been removed. See the browser requirements handbook page for the current policy.

Deprecated core modules

  • The SimpleTest module (labeled Testing in the Drupal core user interface) has been deprecated in Drupal core. Developers are encouraged to run tests via run-tests.sh or the PHPUnit CLI, or to use the SimpleTest contributed module in Drupal 9.

    Note that the final decision to deprecate SimpleTest still has some dependencies on the in-progress Drupal 9 issue, so exact details of the deprecation may be revised.

  • The Place Blocks module (already hidden in previous releases of Drupal core) has been deprecated and will be removed in Drupal 9.0.0. See the change record on the Place Blocks module for alternatives.

Changes to JavaScript dependencies and new JavaScript deprecations

  • *.libraries.yml files now support marking asset libraries as deprecated, and tests that use deprecated libraries will now fail unless they are marked as @group legacy. Read more in the Drupal deprecation policy for libraries.

    Numerous dependency libraries provided by core are deprecated in 8.8.0 and removed in Drupal 9.0.0. These libraries are listed below.

  • jQuery UI is end-of-life, so most jQuery UI libraries are being deprecated in 8.8 for removal in 9.0.x. The deprecated libraries have been made available as contributed projects so that modules and themes that depend on them can upgrade easily to Drupal 9, but where possible, it is recommended to find a replacement for the unsupported libraries. See the change record on the deprecated jQuery UI libraries and their replacement modules for more information.

  • The jQueryUI Datepicker library has been deprecated. Browsers that support native datepickers are unaffected; browsers that do not will instead provide text inputs to enter dates starting in Drupal 9. More information can be found in the change record on Datepicker.

  • The CKEditor, Layout Builder, and Media Library modules previously depended on the jQuery UI Sortable asset library. Since jQuery UI is end-of-life, we've removed the dependency on jQuery UI sortable and added a dependency on the SortableJS library instead. It is recommended that any modules or themes that use jQuery UI sortable also update their code to use SortableJS. Modules extending CKEditor, Media Library, or Layout Builder may also require small changes.

    The Paragraphs contributed project uses an older version of Sortable for its experimental widget. There is a chance that this could lead to version conflicts when both the Paragraphs experimental widget and the core library are used on the same page (for example, on a form with the Media Library). If you notice JavaScript issues when using the Paragraphs experimental widget in 8.8, report them in the Paragraphs issue queue.

  • The Quick Edit module previously depended on the jQuery UI Position asset library. While jQuery UI Position cannot yet be deprecated because it is required by other jQuery UI libraries still used by core, Quick Edit in Drupal 8.8 removes the dependency on jQuery UI position and adds a dependency on the Popper.js library instead. Any modules or themes that use jQuery UI position should also update their code to use Popper.js. Any module extending Quick Edit may also require small changes. Read the Popper.js added to Drupal core to replace jQuery UI Position for more information.

  • The following browser support polyfill libraries are deprecated in Drupal 8.8.0 because they are no longer required by any of the browsers supported by Drupal core:

    • html5shiv
    • matchMedia
    • classList
    • domready (Replaced by a single simple function that will now work in all supported browsers. See domready is deprecated for more information.)

    If you require support for older browsers, contributed projects are also available to provide the html5shiv and matchMedia libraries in Drupal 9.

  • An official deprecation policy has been established for JavaScript, with an @deprecated JSDoc tag similar to the tag used for PHP deprecations. JavaScript code can now also trigger deprecation errors using newly added APIs (Drupal.deprecationError and Drupal.deprecatedProperty). JavaScript deprecation errors are exposed using console.warn. By default, JavaScript deprecation errors are suppressed. Read more in the Drupal deprecation policy for JavaScript.

Testing system changes

  • \Drupal\simpletest\TestBase and its descendants, including WebTestBase, are deprecated. Contributed and custom module tests should be converted to PHPUnit-based tests in preparation for Drupal 9.0.0. See the handbook page on converting SimpleTests to PHPUnit tests for more information.

  • Tests using the testing install profile (which is the default) are now required to specify which theme they're testing. The same is true for tests using any other install profile that does not specify a default theme (i.e. that does not come with system.theme config with a value for the default key). Read more in the change record for deprecating the use of Classy as the default for the testing profile.

  • Previously \Drupal\KernelTests\KernelTestBase always made one assertion that would hide tests that did not perform any assertions themselves. KernelTestBase will now no longer perform one assertion by default, which means that kernel tests that don't perform any assertions will now be marked as risky and will fail on DrupalCI.

New stable core module: Media Library

Media Library provides content editors and site builders an interface to visually browse and manage media in their sites. It also provides an intuitive modal dialog for reusing media in entity reference fields and text editors. Users with appropriate access can also add new media from directly within the library.

This module was introduced as an experimental core module in Drupal 8.6.0, but is now stable and ready for production use! For sites using the experimental module prior to 8.8.0 there are some important changes:

  • The Media Library view is now integrated with Content Moderation. The view will only list unpublished media items to users that have explicit permission to access them. This is accomplished via the addition of a Media-specific "Published status or admin user" filter, which is also available to any views displaying media entities. Note that this may result in unpublished media entities no longer being visible to users that do not have permission to access them. Their permissions should be adjusted if they continue to need access. Read Changes to Media Library's default view in order to respect published/unpublished access permissions for more information.

  • Changes have been made to the Media list (table) and Media Library (grid) default views for better consistency and to better support multilingual sites. The media overview page now defaults to a table view and is filterable by language. The 'widget' view, which gets invoked from a media field or a WYSIWYG's media embed button, now displays in the current user's interface language, falling back to the site's default language if this is unavailable. These changes may affect modules that alter or add to the Media Library view, and will cause the view to return different results than before. See the change record for more details on the updates to the default Media Library views.

  • In Drupal 8.6 and 8.7, Media Library would take over the /admin/content/media path when installed, changing the original administrative table view's path to /admin/content/media-table and replacing the content at /admin/content/media with the Media Library grid view. This could lead to data loss if the site had customized the default table view before installing Media Library.

    In 8.8, the /admin/content/media path has been restored to show the table view, as it does without Media Library installed, and user's customizations will not be overwritten. Sites that installed Media Library in 8.6 or 8.7 and left the listing at /admin/content/media-table will now have that table restored to its original location at /admin/content/media, with the grid at /admin/content/media-grid. This fix might break hardcoded links to either view, or require changes to any modules that further customize them.
    The same change record on the updates to the default Media Library views listed above has more detail.

  • In Drupal 8.7, the Media Library provided two save buttons to users: "Save and select" (which returns the user to the Media Library to select more items, for bulk uploads) and "Save and insert" (which would close the library immediately insert the selected items in the field or text editor). This proved confusing to users. In 8.8, by default there is now simply a "Save" button that returns the user to the library. The previous workflow is still available as an optional advanced configuration and can be enabled in a new settings page under Configuration / Media / Media Library settings.

  • By default, image media items from media fields and in the WYSIWYG editor will now use the ‘large’ image style that ships with the image module. Before this change, media images used the ‘Full’ display, which by default rendered the original image.

  • All of Media Library's styling and associated CSS classes were moved into Classy and Seven. Classy provides a very minimal amount of basic layout for the media library; Seven provides a more complete experience. If you are not using Seven to display the media library, you may need to add code to your theme to ensure that the moved CSS classes are applied to the media library in the correct places. See Media Library exposes templates for theming and Media Library no longer applies presentational CSS classes by default for more information, and refer to core/themes/seven/seven.theme for examples of how to apply the required CSS classes in your theme.

  • The "add" forms provided by the Media Library module now have two different form IDs. Previously, both shared the same form ID (media_library_add_form). This is now their shared base form ID. Their individual form IDs are now media_library_add_form_upload and media_library_add_form_oembed. Any code altering either of these forms will require updates, and any custom form extending \Drupal\media_library\Form\AddFormBase will need to be changed as well. See Media Library's AddFormBase now requires subclasses to provide a form ID for more information.

  • The media library's administrative grid interface is no longer exposed at /admin/content/media. That path now shows the administrative table listing of media items, as it does without Media Library installed. The grid interface is linked from there, and exposed at /admin/content/media-grid. An update path for this is provided; no further action is needed from existing sites.

JSON:API changes

Views changes

  • Views now adds a ENTITY_TYPE_ID_access query tag to all its queries by default. This means that any implementations of hook_query_TAG_alter(), where TAG is of the pattern ENTITY_TYPE_ID_access -- for example, user_access if user accounts are being queried -- will now run on views queries as well. Modules implementing such hooks should ensure that this change does not result in unwanted side effects.

  • Validation for allowed characters in Views filter identifiers was more lenient than intended. If any of your views currently uses a character in the identifier that is other than letters, digits, the dot (.), hyphen (-), underscore (_), or tilde (~), you will need to reconfigure the exposed filters without them. Read the change record on how Views exposed filters identifiers are now validated correctly for more information.

Configuration system changes

  • Code that exports configuration should use the new read-only configuration export storage config.storage.export instead of exporting configuration directly from the active storage. Exporting directly from the active storage will lead to unexpected behavior when using features that use the new configuration transformation API.

  • Previously, modules could make changes to configuration a profile is overriding during their install. This has changed in 8.8 and profile configuration overrides are now installed at the end of an installation. Any profiles that previously modified their configuration during installation must update their configuration so that it contains the final configuration that is desired at the end of installation. Refer to the change record for more information and suggestions for updating your profile's configuration.

Other important update information

  • The security fixes required for SA-CORE-2018-002 and SA-CORE-2018-004 as well as publicly disclosed security issues all indicate that the render system needs to be stricter about what may be called by a callback. If you have code that adds a render callback (#access_callback, #lazy_builder, #pre_render or #post_render), it might need to be updated to work in Drupal 9. Read more in the change record for limitations on what can be called by a callback in render arrays.

  • New revisions are created every time an entity or revision is updated, if that entity is being moderated with content moderation. Previously there was no way to opt out of this. By using SynchronizableInterface, users can now mark an entity as 'syncing' to indicate changes are being made to the entity that do not reflect a typical content/editorial field based change and thus should not be subject to the entity lifecycle rules content moderation enforces. If you are using SynchronizableInterface in custom code for content entities and also depend on Content Moderation forcing the creation of new revisions, you may need to update your code to manually call $entity->setNewRevision(TRUE).

  • In Drupal 8, if a theme does not specify a base theme, Stable is used automatically. Starting with Drupal 9, a new stable base theme will be added to each major version with the latest markup provided by modules, and the old stable base theme will be deprecated. To facilitate this and avoid unintended regressions, the automatic base theme fallback is now deprecated and the base theme property will be required starting with Drupal 9.0.0. To remain compatible with Drupal 9, themes that use Stable as their base theme should now explicitly add a base theme to their info files. See the change record on requiring the base theme property for examples.

  • SimpleAnnotationReader, which has been dropped from the master branch of Doctrine Annotations, has been forked into Drupal core to maintain the same functionality. This prepares Drupal core for a future update to the Doctrine library. Contributed modules should not be relying on this library directly, but if some application does use SimpleAnnotationReader directly, it should update to use Drupal's forked copy of the API in order to remain forward-compatible.

  • The temporary file path is now a setting in settings.php, and is no longer stored in configuration. If your site is not using /tmp, you must update settings.php before running database updates:

    $settings['file_temp_path'] = '/path/to/your/temporary/folder';

Changed coding standards

CSS standards for ordering is now enforced using the stylelint-order plugin.

Dependency updates

  • Drupal 8.8.0 will require PHP 7, which means that it can no longer support PHPUnit 4. All compatibility layers for supporting PHPUnit 4 alongside PHPUnit 6 have been removed. See the change record on the end of PHPUnit 4 support for details.

    Drupal 8 now supports PHPUnit 6.5+ and PHPUnit 7 instead. PHPUnit 6 will be used by default, but PHPUnit 7 is required for testing on PHP 7.4. If you are using core's root composer file, you can update to PHPUnit 7 by running composer update phpunit/phpunit symfony/phpunit-bridge phpspec/prophecy symfony/yaml --with-dependencies. PHPUnit 7 is required for testing on PHP 7.4.

  • The wikimedia/composer-merge-plugin has been deprecated and replaced with a Composer path repository. It will remain in the root composer.json of Drupal until it is removed in Drupal 9. Most users should not notice any change in behavior as a result, but see the notes at the end of the change record for the deprecation of the Composer merge plugin about downgrading, core development, and contributed and custom modules that are currently using the composer-merge-plugin. Following this change, core developers creating patches that update core's dependencies must set COMPOSER_ROOT_VERSION explicitly to avoid unexpected results (including possible accidental deletion of the core directory). Read Managing Composer updates for Drupal core for more information.

  • Drupal core now explicitly requires Guzzle 6.3 or higher for the end of PHP 7.0's official security support and for forward compatibility Drupal 9's increased PHP version requirements. This may affect sites built with Composer that were using a lower version.

  • typo3/phar-stream-wrapper has been updated to 3.1.2 (a major version update for PHP 7). As a result the brumann/polyfill-unserialize dependency has been removed. Any modules depending on brumann/polyfill-unserialize should declare their own dependency.

  • jQuery has been updated from version 3.2.1 to version 3.4.1.

  • CKEditor has been updated from from 4.11.4 to 4.13.0, which includes numerous bug fixes and improvements.

  • The following other Drupal core PHP dependencies have also been updated:

    • Diactoros has been updated from 1.7.2 to 1.8.7, a long-term support version which will receive security coverage until Drupal 8's end-of-life. Note that the above documentation incorrectly indicates that 1.7 is the long-term support version, but we have confirmed with the Diactoros maintainers that 1.8 will continue to receive security coverage until 2022.

    • drupal/coder (to 8.3.6).
    • Symfony packages (from 3.4.26 to 3.4.35).
    • Twig (from 1.38.4 to 1.42.3).
    • Guzzle (from 1.4.2 to 1.6.1).
    • Email validator (from 2.1.7 to 2.1.11).
    • PSR Logging Library (from 1.0.2 to 1.1.0).
    • PHP Codesniffer (from 3.4.2 to 3.5.0).
    • Doctrine packages (to the latest minor versions).
    • Pear packages (to the latest minor versions).
    • Pear Archive_Tar (from 1.4.5 to 1.4.8).
    • TYPO3 Phar Stream Wrapper (from 3.1.2 to 3.1.3)
    • Zend Escaper, Zend Feed, and Zend stdlib (to 2.6.1, 2.12.0, and 3.2.1, respectively).
    • Composer Installers (from 1.6.0 to 1.7.0).
    • composer/composer has been updated from 1.8.5 to 1.9.1 (and 1.9 or higher is now explicitly required for sites managed with Composer).

    The following PHP 5 polyfills have been removed: ircmaxell/password-compat, brumann/polyfill-unserialize, and paragonie/random_compat (technically updated to an empty version which will remain in place until Drupal 9).

    Finally, ralouphie/getallheaders has been added as a dependency because the latest version of Guzzle requires it.

Important bug fixes

The following other critical issues have also been fixed in Drupal 8.8.0-alpha1:

Beta testing

The Drupal Association and Drupal core maintainers have partnered with agencies and site owners in an official beta testing program for Drupal core minor releases. A number of issues were identified and resolved directly and an update guide for composer-based projects was published as a result of this initiative. Participating in the beta program is an important way to contribute to the Drupal project. Special thanks to the following individuals and organizations for participating, and directly contributing to the quality of this release:

Known issues

Search the issue queue for all known issues.

All changes since 8.8.0-rc1

The packaged tar and zip files changed on Thu Dec 5 00:24:03 UTC because they were rebuilt to be composer ready.

Download Size md5 hash
drupal-8.8.0.tar.gz 18.56 MB fe6cf51411bfb0ae9cf9e8d6f3df0f87
drupal-8.8.0.zip 29.52 MB 37d1e23bbb42881cabb65ec37957353f
Last updated: 4 Dec 2019 at 09:08 UTC
Official release from tag: 
8.8.0
Core compatibility: 
8.x
Release type: 
Bug fixes
New features
Short description: 
Actively maintained with new features and backwards-compatible improvements every six months. Use this version for the best compatibility with future releases.
Packaged Git sha1: 
f2b59e3ae8097ea01d15c708f1267b73794399c0
↧
Search
Viewing all articles
Browse latest Browse all 584
Search