Drush users: Update to Drush 8.1.12+ or higher
Versions of Drush earlier than 8.1.12 will not work with Drupal 8.4.x. Update Drush to 8.1.12 or higher before using it to update to Drupal core 8.4.x or you will encounter fatal errors that prevent updates from running.
- If Drush is installed globally (i.e., generally available on the web host), Drush 8.1.12 and higher will successfully update Drupal 8.3.x to 8.4.0, but users may still see other error messages after updates have run.)
- If the site is built with Composer and includes Drush as a local dependency (less common), you should update your
composer.json
file to require at least Drush 8.1.15. Drush 8.1.14 will not work in the same composer project as Drupal 8.4.
Updated browser requirements: Internet Explorer 9 and 10 no longer supported
In April 2017, Microsoft discontinued all support for Internet Explorer 9 and 10. Therefore, Drupal 8.4 has as well. Drupal 8.4 still mostly works in these browser versions, but bugs that affect them only will no longer be fixed, and existing workarounds for them will be removed beginning in Drupal 8.5.
Additionally, Drupal 8's browser requirements documentation page currently lists incorrect information regarding very outdated browser versions such as Safari 5 and Firefox 5. Clarifications to the browser policy and documentation are underway.
Known Issues
Drupal 8.4.0 includes major version updates for two dependencies: Symfony 3.2 and jQuery 3. Both updates may introduce backwards compatibility issues for some sites or modules, so test carefully. For more information, see the "Third-party library updates" section below. Known issues related to the Symfony update include:
See the '8.4.0 update' tag for a list of known issues across projects.
Search the issue queue for known issues.
Important fixes since 8.3.x
Translators should take note of several string additions and changes since the last release.
File usage tracking
Drupal 8 has several longstanding file usage tracking bugs. To prevent further data loss, Drupal 8.4 has disabled the automatic deletion of files with no known remaining usages. This will result of the accumulation of unused files on sites, but ensures that files erroneously reporting 0 usages are not deleted while in use. Additionally, an issue with validation errors when saving content referencing these files has also been resolved.
The change record explains how sites can opt back into marking files temporary. If you choose to enable the setting, you can also set "Delete temporary files after" to "Never" on /admin/config/media/file-system
to avoid permanent deletion of the affected files.
While the files will no longer be deleted by default, file usage is still not tracked correctly in several scenarios, regardless of the setting. Discussion on how to evolve the file usage tracking system is underway.
Configuration export sorting
Revision data integrity fixes
Other critical improvements
New stable modules
The following modules, previously considered experimental, are now stable and safe for use on production sites, with full backwards compatibility and upgrade paths from 8.4.0 to future releases:
Datetime Range
The Datetime Range module provides a field type that allows end dates to support contributed modules like Calendar. This stable release is backwards-compatible with the 8.3.x experimental version and shares a consistent API with other Datetime fields.
Future releases may improve Views support, usability, Datetime Range field validation, and REST support. For bugs or feature requests for this module, see the core Datetime issue queue.
Layout Discovery
The Layout Discovery module provides an API for modules or themes to register layouts as well as five common layouts. Providing this API in core enables core and contributed layout solutions to be compatible with each other. This stable release is backwards-compatible with the 8.3.x experimental version and introduces support for per-region attributes.
The new core Media module provides an API for reusable media entities and references. It is based on the contributed Media Entity module.
Since there is a rich ecosystem of Drupal contributed modules built on Media Entity, the top priority for this release is to provide a stable core API and data model for a smoother transition for these modules. Developers and expert site builders can now add Media as a dependency. Work is underway to provide an update path for existing sites' Media Entity data and to port existing contributed modules to the improved core API. Both versions cannot be used at the same time, so we also prevent the 1.x version of the contributed Media Entity module from being enabled at the same time as the core Media module.
Note that the core Media module is currently marked hidden and will not appear on the 'Extend' (module administration) page. (Enabling a contributed module that depends on the core Media module will also enable Media automatically.) The module will be displayed to site builders normally once user experience issues with it are resolved. Similarly, the REST API and normalizations for Media is not final and support for decoupled applications will also be improved in a future release.
The Inline Form Errors module provides a summary of any validation errors at the top of a form and places the individual error messages next to the form elements themselves. This helps users understand which entries need to be fixed, and how. Inline Form Errors was provided as an experimental module from Drupal 8.0.0 on, but it is now stable and polished enough for production use. See the core Inline Form Errors module issue queue for outstanding issues.
Workflows
The Workflows module provides an abstract system of states (like Draft, Archived, and Published) and transitions between them. Workflows can be used by modules that implement non-publishing workflows (such as for users or products) as well as content publishing workflows.
Drupal 8.4 introduces a final significant backwards compatibility and data model break for this module, moving responsibility for workflow states and transitions from the Workflow entity to the Workflow type plugin. Read Workflow type plugins are now responsible for state and transition schema for full details on the API and data model changes related to this fix. Now that this change is complete, the Workflows module became stable!
While the module can be installed as-is, it is not useful in itself without either Content Moderation and/or some other module that requires it.
Content authoring and site administration improvements
- The "Save and keep (un)published" dropbutton has been replaced with a "Published" checkbox and single "Save" button. The "Save and..." dropbutton was a new design in Drupal 8, but users found it confusing, so we have restored a design that is more similar to the user interface for Drupal 7 and earlier.
- Previously, deleting a field on a content type would also delete any views depending on the field. While the confirmation form did indicate that the view would be deleted, users did not expect the behavior and often missed the message, leading to data loss. Now, the view is disabled instead. In the future, we intend to notify users that configuration has been disabled (as in this fix) as well as give users clearer warnings for other highly destructive operations.
- The Drupal toolbar no longer flickers during page rendering, thus improving perceived front-end performance.
- Options in timezones selector are now grouped by regions and labeled by cities instead of timezone names, making it much easier for users to find and select the specific timezone they need.
- Both the "Comments" administration page at
/admin/content/comment
and the "Recent log messages" report provided by dblog are now configurable views. The "Comments" administration page also has some default filters added. - Useful meta information about a node's status is typically displayed at the top of the node sidebar. Previously, this meta information was provided by the Seven theme, so it was not available in other administrative themes. This meta information is now provided by node.module itself so other administration themes can access it.
- Views now supports rendering computed fields.
REST and API-first improvements
- Authenticated REST API performance increased by 15% by utilizing the Dynamic Page Cache.
- POSTing entities can now happen at
/node
, /taxonomy/term
and so on, instead of /entity/node
, /entity/taxonomy_term
. Instead of confusingly different URLs, they therefore now use the URLs you'd expect. Backwards compatibility is maintained. - There is now a dedicated resource for resetting a user's password.
- Time fields now are normalized to RFC3339 timestamps by default, fixing time ambiguity. Existing sites continue to receive UNIX timestamps, but can opt in. See the change record for more information about backwards compatibility and on how to opt in.
- Path alias fields are now normalized as well. See the change record for information about how this impacts API-first modules and other features relying on serialized entities.
- When denormalization fails, a 422 response is now returned instead of a 400, per the HTTP specification.
- With CORS enabled to allow origins besides the site's own host, submitting forms was broken unless the site's own host was also explicitly allowed. This is now resolved.
- Fatal errors and exceptions now show a backtrace for all non-HTML requests as well as HTML requests, which makes for easier debugging and better bug reports.
- Massive expansion of test coverage.
Developer experience improvements
Automated testing improvements
Third-party library updates
Experimental modules
Migrate provides a general API for migrations. It will be considered completely stable once all issues tagged Migrate critical are resolved.
- This release includes numerous developer experience improvements for Migrate and Migrate Drupal, including deprecating outdated references to "CCK", simplifying field type mapping, renaming several plugins to better capture their and many other API and documentation improvements. (Backwards compatibility is provided in each case Migrate is in beta.)
- Added the ability to provide the source module to migrations to help site owners review what data is being migrating, especially for cases where the source and destination module are not the same (for example if a new Drupal 8 module replaces old functionality.
Migrate Drupal and Migrate Drupal UI (alpha stability)
Migrate Drupal module provides API support for Drupal-to-Drupal migrations, and Migrate Drupal UI offers a simple user interface to run migrations from older Drupal versions.
Content Moderation allows workflows from the Workflows module to be applied to content. Notable improvements in this release:
As per the experimental module process, there were some backwards-incompatible changes since Drupal 8.3.x. Experimental modules do not offer a supported upgrade path, but an unofficial upgrade path is available.
This module provides the ability for site builders to rearrange fields on content types, block types, etc. into new regions, for both the form and display, on the same forms provided by the normal field user interface. Field Layout has had several bugfixes since 8.3.0, but no significant changes. See the entity display layout roadmap for the next steps for this module, which needs to become stable by 8.5.0 to remain in Drupal core.
The Settings Tray module allows configuring page elements such as blocks and menus from the frontend of your site. Settings Tray has improved significantly since Drupal 8.3.0, including numerous user interaction and accessibility fixes, better compatibility with stable core modules like Quick Edit and Contextual Links, added documentation, and a CSS reset for better themer experience.
The module reached beta stability following completion of moving the off-canvas dialog renderer into a core component, and renaming the machine name of the module to settings_tray, to match its user-facing name. We hope to make Settings Tray stable by 8.5.0. To track progress, see the "outside in" roadmap issue.
This feature allows the user to place a block on any page and see the region where it will be displayed, without having to navigate to a backend administration form. 8.4.0-alpha1 was the deadline for Place Blocks to stabilize, but the module's roadmap was not completed. Furthermore, the module is not intended as a standalone feature and should instead be a built-in part of the Block system. For these reasons, Place Blocks module has been marked hidden in this release (it can still be enabled with Drush). The Place Blocks module itself will be turned into an empty module in Drupal 8.5.x, since ideally the core Block system will offer the same functionality in 8.5.0 (though this depends on completion of a core patch for the feature.)