drupal 8.8.0-alpha1

This is a alpha release for the next feature release of Drupal 8. Alpha releases are good testing targets for developers and site builders who are comfortable reporting (and where possible, fixing) their own bugs. Alpha releases are not recommended for non-technical users, nor for production websites. More information on alpha releases.

This minor release provides new improvements and functionality without breaking backward 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 backwards 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 prior to 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:

Critical note for sites using the Pathauto contributed module

Custom URL aliases are now provided by a new path_alias revisionable and publishable content entity type. The path.alias_storage service has been kept in place for backwards compatibility, and its hooks have been deprecated.

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.

As part of the change to path aliases, path alias administrative 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.

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 onwards (including Drupal 9). It may 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.

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 longer term. See the change record on the deprecated jQuery UI libraries and their replacement modules for more information.

• jQuery UI Sortable and jQuery UI Datepicker are not yet deprecated in 8.8.0-alpha1, but may be deprecated in 8.8.0-beta1.

• The Quick Edit module previously depended on the jQuery UI Position asset library. While jQuery UI Position cannot yet be deprecated as it's 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. It's recommended that any modules or themes that use jQuery UI position also update their code to use Popper.js. Any module extending QuickEdit 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-alpha1 because they are no longer required by any of the browsers supported by Drupal core:

  • html5shiv
  • matchMedia
  • 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 defaultkey). 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.

Changes to Media workflows and the Media Library

• 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 impact 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.

JSON:API changes

• In earlier releases, applications that altered user display names programmatically in PHP and also updated user entities via JSON:API were at risk of overwriting user names. JSON:API now serializes a user's display name under a read-only display_name attribute field, and the name field now contains the raw, unaltered user name in place of the altered display name. JSON:API applications that require the display name should be updated to use the display_name attribute field.

• JSON:API omission links are now keyed using a double-dash-separated syntax instead of a colon-separated syntax in order to be brought into compliance with the JSON:API specification on allowed member names. This may require changes to client applications that are parsing document omission links. See the change record on the change to object omission link serialization for an example.

• This release contains a security hardening feature to better support sites using the JSON:API module. Modules may now indicate that certain resources and fields representing their entity data should never be available over JSON:API. This can be implemented in a custom module for a specific site, or by a module that supplies an entity type. It is recommended to implement this API for any entity data that should never be exposed over JSON:API. See the JSON:API security considerations handbook page for more information on securing your site with JSON:API.

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 storageconfig.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.

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 if you are using core's root composer file. 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 from these changes, 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 impact 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.

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

  • Diactoros (from 1.4.1 to 1.7.2). Note: Both Diactors 1.4.1 and 1.7.2 include an unpatched security vulnerability that does not affect Drupal directly. Diactoros may be updated to a 1.8 version before Drupal 8.8.0's release. See the known issues for more information.
  • drupal/coder (to 8.3.6).
  • Symfony packages (from 3.4.26 to 3.4.32).
  • 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).
  • 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).

  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:

• #2587119: Form sets system.theme:admin to '0' breaking Quick Edit and making no sense
• #2869855: Race condition in file_save_upload causes data loss
• #2936365: Migrate UI - allow modules to declare the state of their migrations
• #2966327: Limit what can be called by a callback in render arrays to reduce the risk of RCE
• #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path
• #3051826: 8.7.0-rc1 database updates fail on media_library configuration dependencies due to missing form and view modes
• #3057175: Implementation of user name in JSON:API can result in overwriting data
• #3059332: Mark kernel tests that perform no assertions as risky
• #3082289: \\Drupal\\Core\\Field\\Plugin\\Field\\FieldType\\EntityReferenceItem::onDependencyRemoval() sets auto_create to an invalid data type

Known issues

• This release updates Diactoros to version 1.7.2, which is documented to be a long-term support release. However, despite that documentation, 1.7.2 does not include the most recent security fix to Diactoros for SA-CORE-2018-005. As documented in that advisory, Drupal core itself does not exercise the vulnerable code. However, security checking tools may still report an unpatched vulnerability. We are following up with the Zend Framework maintainers in an attempt to resolve this issue. See #3087531: Use Diactoros LTS version 1.7, not 1.8 which is out of security coverage.
• A data loss issue for path aliases has been reported in #3086638: Drupal 8 update failing on ddev builds. It appears this issue may have been due to a database misconfiguration, but we are tracking the issue to ensure it does not affect other users. Be sure to back up your data before upgrading, and report any issues with this update in the issue above.

Search the issue queue for all known issues.

All changes since the last minor release

Search the 8.8.x commit log.