Drupal News

Drupal News

Come for the software, stay for the community Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.
  • Drupal looking to adopt React

    This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

    Drupal looking to adopt React

    Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

    As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

    Two years ago, it was premature to pick a JavaScript framework

    Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

    1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
    2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
    3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

    (For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

    By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

    At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

    Focusing on Drupal's web services instead

    By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

    I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

    The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: "I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

    The current state of JavaScript in Drupal

    Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

    Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

    There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

    1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
    2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
    3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

    One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

    Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

    My recommendations at DrupalCon Vienna

    Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to talk bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

    • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
    • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
    • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
    • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.

    Selecting a JavaScript framework for Drupal's administrative UIs

    In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

    As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

    There was unanimous agreement that:

    1. Adding a JavaScript framework to Drupal core is a good idea.
    2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
    3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
    4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

    We created an issue on the Drupal core queue to discuss this more.

    Conclusion

    Drupal supporting different javascript front ends

    Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

    In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

    After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

    Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.

  • Progress on the Salesforce Suite for D8 and a Call for Participation

    The following blog was written by Drupal Association Premium Supporting Partner, Message Agency.

    After months of work, hundreds of commits, and lots of new thinking, the Salesforce Suite for Drupal 8 is reaching maturity.  There is tremendous interest in these modules, and many enterprises are waiting for this milestone to integrate D8 sites with Salesforce. In an effort to accelerate refinement and adoption of this important contribution, the module’s developers are raising awareness about the release and asking the community to start downloading and contributing.

    A few months ago at Drupalcon Baltimore, Message Agency announced a release candidate (8.x-3.0-rc1) for the Salesforce Suite in Drupal 8.  This collection of modules supports integration with Salesforce by mapping Drupal entities with standard or custom Salesforce objects and pushing Drupal data to Salesforce as well as pulling Salesforce data into Drupal.

    Since then, we've continued to expand the Suite and build out critical features. We've also continued to groom the 8.x roadmap, solicit community participation through webinars, and build awareness about how to use the modules. With a solid foundation and full functionality, the Suite is beginning to gain traction and see increasing adoption as projects switch to Drupal 8.

    What’s new in the Suite?

    The modules are a complete rewrite of the Suite for Drupal 8, and they fully leverage Drupal core’s object-oriented code patterns.  Message Agency’s senior software engineer, Aaron Bauman, was the original architect of the Suite for 6.x in 2009 and has continued to support this important tool ever since. He took the lead in porting the modules for Drupal 8, based on feedback from the community, clients, and nearly a decade of experience integrating these two powerful platforms.

    There is much to be excited about in this new version. There have been a number of updates from Drupal 7.x:

    • Queue on failure. There is now an attempt to push synchronization immediately on entity save and enqueue for asynchronous push only on failure. This feature idea is a great compromise between the previous binary sync/async decision point.
    • Test coverage.  Testing 3rd-party web services can be tricky, and requires careful planning and mocking. This Salesforce 8.x release includes test coverage for push and pull operations using mock REST features, allowing for proper regression testing and test-driven development.
    • Push queue overhaul, and cron-based push.  Drupal 7's asynchronous push left a lot to be desired. Lack of error handling made debugging and troubleshooting difficult to impossible. Lack of optimizations burned unnecessary API calls. Both of these limitations were imposed by Drupal Queue API's fundamental nature. In Drupal 7, our options for extending the Queue system were limited. In Drupal 8, we've implemented a Salesforce Push Queue service, building on Drupal core's overhauled Queue API. We've taken the opportunity to normalize queue items, optimize queue operations, and implement error handling and recovery.
    • Objectification of Salesforce resources. Moving in the direction of a proper REST PHP SDK, we now have proper classes for Query Result, SObject, Salesforce ID, various REST Responses, and others. This not only allows for simple type-hinting across other classes, but also gives developers consistent and reliable interfaces, and paves the way for even greater extensibility in the future.
    • Queue settings per mapping. The Suite now allows administrators to assign sync intervals per-mapping, instead of running all sync operations on every cron run. This feature idea will allow administrators to tweak their synchronizations according to business needs, without the need to implement extensive hook-based logic.

    Several new features for Drupal 8 also have been developed:

    • Goodbye hooks, hello events. Leveraging Salesforce.api.php, we mapped old hooks onto new events—a key advantage for folks already familiar with the 7.x version.
    • A new plugin system for mapping fields.  There has been a mapping UI overhaul.  Salesforce Mapping Fields now enjoy their own plugin system, allowing for maximum extensibility. For example, "Record Type" is now its own mapping field plugin type, rather than receiving special treatment in the push and pull systems.
    • Pluggable everything. including the REST Client itself, thanks to Drupal services and Dependency Injection.  
    • Examples module.  There is now a working examples module with an event subscriber, exported mapping config, and demonstration of using the  REST client to connect to an Apex endpoint.

    The new version also builds in some important re-includes from 7.x - 2.x branch.

    • Mapped Objects are tied to Mappings
    • Custom push queue
    • Re-attempt on failure
    • Encryption support

    What is the current status? And how can you help?

    The Suite has advanced to 8.x-3.0-rc6 and is nearing a stable release.  It’s time to start downloading and using the modules to help us identify and smooth out the rough spots.

    For a quick start overview, watch this Acquia webinar, delivered by Aaron Bauman on how to install and configure the Suite.

    https://youtu.be/9tKrpxW1sMk

    https://www.acquia.com/resources/webinars/how-use-salesforce-suite-drupal-8-quick-start-guide?r=735547932

    Keep those issues coming in the queue!

    The Heavy Lifting

    This amount of work is never done alone.  By the numbers, so far:

    • 5 contributors including 2 Message Agency staff.  (Shout out to evanjenkins, bezhermoso, and gcb for their contributions.)
    • Merged 7 major branches.
    • More than 200 commits.
    • Nearly 400 hours logged across 5 Message Agency dev and PM staff, and 3 drupal.org users

    Also, major thanks to Acquia's Drupal 8 Module Acceleration Program for connecting us with clients to fund and advance module development.

  • An update on projects created for Drupal

    About six months ago we made a significant change to the way that modules, themes, and distributions are created on Drupal.org.

    In the past, contributors had to first create a sandbox project, and then request manual review of their project in the Project Applications issue queue. The benefit of this community-driven moderation process was that modules were vetted for code quality and security issues by a group of volunteers. Project maintainers who completed this process also received the benefit of security advisory coverage from the Security Team for stable releases of their projects.

    Unfortunately, the rate of project applications outpaced what volunteers could keep up with, and many worthy projects were never promoted to full project status, or moved off of Drupal.org to be hosted elsewhere.

    To ameliorate this issue, we changed the process so that any confirmed user on Drupal.org may now make full projects.

    To mitigate the risks of low code quality or security vulnerabilities we added new signals to project pages: including highlighting which release is recommended by the maintainer, displaying recent test results, and indicating whether the project receives security coverage both on the project page and in the composer 'extra' attribute. We're continuing to work on identifying additional signals of project quality that we can include, as well as surfacing some of this information in Drupal core. We also converted the project applications issue queue into a 'request security advisory coverage' issue queue.

    What we hoped to see

    We knew this would be a significant change for the project and the community. While many community members were excited to see the gates to contribution opened, others were concerned about security issues and Drupal's reputation for code quality.

    Our prediction was that the lower barrier to contribution would result in an increase in full projects created on Drupal.org. This would indicate that new contributors or third party technology providers were finding it easier to integrate with Drupal and contribute those integrations back for use by others.

    At the same time, we also expected to see an increase in the number of full projects that do not receive coverage from the security team. The question was whether this increase would be within an acceptable range, or represent a flood of low quality or insecure modules.

    The results

    The table below provides statistics about the full projects created on Drupal.org in the 5 months before March 17th, 2017 - when we opened the creation of full projects to all confirmed users.

    Full projects created from 2016-10-16 to 2017-03-17…

    #

    % of projects created in this period

    … without stable release

    431

    55.76%

    … with stable releases

    342

    44.24%

    … with usage >= 50 sites

    237

    30.66%

    … with usage >= 50 sites and without stable release

    68

    8.80%

    … with usage >= 50 sites and with stable release

    169

    21.86%

    … with an open security coverage application*

    18

    2.33%

    Sub-total with security coverage

    342

    44.24%

    Sub-total without security coverage

    431

    55.76%

    Sub-total with security coverage and >=50 usage

    169

    21.86%

    Sub-total without security coverage and >= 50 usage

    68

    8.80%

    Total

    773

    * note: full projects that did not have stable releases were not automatically opted in to security coverage when we opened the full project creation gates.

    … and this table provides statistics about the projects created in the 5 months after we opened the creation of full projects to all confirmed users:

    Full projects created from 2017-03-17 to 2017-08-16…

    #

    Diff

    % of projects created

    Diff %

    … without stable release

    851

    +420

    69.53%

    +97%

    … with stable releases

    373

    +31

    30.47%

    +9%

    … with usage >= 50 sites

    156

    -81

    12.75%

    -34%

    … with usage >= 50 sites and without stable release

    64

    -4

    5.23%

    -6%

    … with usage >= 50 sites and with stable release

    92

    -77

    7.52%

    +46%

    … with an open security coverage application

    62

    +44

    5.07%

    +344%

    Sub-total with security coverage

    182

    -160

    14.87%

    -53%

    Sub-total without security coverage

    1,042

    +611

    85.13%

    +242%

    Sub-total with security coverage and >=50 usage

    54

    -115

    4.41%

    -32%

    Sub-total without security coverage and >= 50 usage

    102

    +34

    8.33%

    +150%

    Total

    1,224

    +451

    +58%

    As you can see, we have an almost 58% increase in the rate of full projects created on Drupal.org. We can also see a significant proportional increase in two key areas: projects with greater than 50 site usage and no security coverage(up 150% compared to the previous period), and projects that have applied for security coverage(up 344% compared to the previous period). Note: this increase in applications is for projects *created in these date ranges* not necessarily applications created overall.

    This tells us that reducing friction in applying for security coverage, and encouraging project maintainers to do so should be a top priority.

    Finally, this last table gives statistics about all of the projects currently on Drupal.org, regardless of creation date:

    Full projects (7.x and 8.x)

    #

    % of Total

    Rate of change after 2017-03-17

    … with the ability to opt into security coverage

    8,718

    36.15%

    -1.33%

    … with security coverage and stable releases

    8,377

    34.74%

    -1.49%

    … without security coverage

    15,396

    63.85%

    +1.33%

    … without security coverage and with stable releases

    464

    1.92%

    +1.04%

    … with security coverage and >=50 usage
     

    6,475

    66.91 / 26.85%

    -0.54%

    … with security coverage and stable releases and >=50 usage

    6,308

    65.19 /26.16%

    -0.65%

    … without security coverage and >=50 usage

    3,202

    33.09 /13.28%

    +0.54%

    … without security coverage and with stable releases and >=50 usage

    130

    1.34 /0.54%

    +0.51%

    Sub-total with >=50 usage

    9,677

    40.13%

    -1.72%

    Total

    24,114

    From the overall data we see approximately what we might expect. The increase in growth of full projects on Drupal.org has lead to a modest increase in projects without security coverage.

    Before the project application change, all full projects with stable releases received security advisory coverage. After this change, only those projects that apply for the ability to opt in(and then do so) receive coverage.

    What has this meant for security coverage of projects hosted on Drupal.org?

    1.92% of all full 7.x and 8.x projects have stable releases, but do not receive security advisory coverage. It is likely no accident that this translates into 464 projects, which is nearly equivalent to the number of projects additional projects added compared to our old growth rate.

    Of those only 130 of those projects report more than 50 sites usage(or .54% of all 7.x and 8x full projects).

    Next steps

    From this analysis we can conclude the following:

    1. The opening of the project application gates has dramatically increased the number of projects contributed to Drupal.org.

    2. It has also increased the number of projects without security coverage, and the number of applications for the ability to opt in to coverage among new projects.

    In consultation with the Security Working Group, we recommend the following:

    • For now, leave the project creation projects as it stands today - open to contribution from any confirmed user on Drupal.org.

      • Less than 2% of all Drupal projects with stable releases currently lack security coverage. The rate at which this is increasing is significant (and in the wrong direction) but not rapid enough to merit changing the project application policy immediately.

    • Solve the problem of too many security advisory coverage applications. The security advisory application queue has the same problem that the old project applications queue had - not enough volunteers to manually vet all of the applications - and therefore a significant backlog of project maintainers waiting on the ability to opt into coverage.

      • Recommendation: Implement an automated best practices quiz that maintainers can take in order to be granted the ability to opt into security advisory coverage. If this process is as successful as we hope, we may want to consider making this a gate on stable releases for full projects as well.

    We look forward to working with the Security Working Group to implement this recommendation and continue to improve the contribution experience on Drupal.org, while preserving code quality and security.

  • Drupal 8.4.0 is now available

    What's new in Drupal 8.4.0?

    This new version is an important milestone of stability for Drupal 8. It adds under-the-hood improvements to enable stable releases of key contributed modules for layouts, media, and calendaring. Many other core experimental modules have also become stable in this release, including modules for displaying form errors inline and managing workflows.

    The release includes several very important fixes for content revision data integrity as well as an update to stop the deletion of orphaned files that was causing data loss for many sites, alongside numerous improvements for site builders and content authors.

    Download Drupal 8.4.0

    Important: If you use Drush to manage Drupal, be sure to update to Drush 8.1.12 or higher before updating Drupal. Updating to Drupal 8.4.0 using Drush 8.1.11 or earlier will fail. (Always test minor version updates carefully before making them live.)

    Inline Form Errors

    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.

    Screenshot showing form error displayed with the field rather than at the top of the form.

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

    Screenshot showing form elements to specify start and end dates.

    Layout Discovery API

    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 like Panels and Display Suite 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.

    Media API

    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 refined core API.

    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 once related user experience issues are resolved in a future release.

    Similarly, the REST API and normalizations for Media are not final and support for decoupled applications will be improved in a future release.

    Content authoring and site administration experience 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.

    Both the "Comments" administration page at `/admin/content/comment` and the "Recent log messages" report provided by dblog are now configurable views. This allows site builders to easily customize, replace or clone these screens.

    Updated migrations

    This release adds date and node reference support for Drupal 6 to Drupal 8 migrations. Core provides migrations for most Drupal 6 data and can be used for migrating Drupal 6 sites to Drupal 8, and the Drupal 6 to 8 migration path is nearing beta stability. Some gaps remain, such as for some internationalization data. The Drupal 7 to Drupal 8 migration is incomplete but is suitable for developers who would like to help improve the migration and can be used to test upgrades especially for simple Drupal 7 sites. Most high-priority migrations are available.

    Moderation and workflows

    The Workflows module is now also stable, however it only provides a framework for managing workflows and is not directly useful in itself. The experimental Content Moderation module allows workflows to be applied to content and is now at beta stability. Content moderation workflows can now apply to any entity types that support revisions, and numerous usability issues and critical bugs are resolved in this release.

    Platform features for web services

    Drupal 8.4 continues to expand Drupal's support for web services that benefit decoupled sites and applications, including a 15% performance improvement for authenticated REST requests, expanded REST functionality, and developer-facing improvements.

    Further details are available about each area in the 8.4.0 release notes.

    What does this mean for me?

    Drupal 8 site owners

    Update to 8.4.0 to continue receiving bug and security fixes. The next bugfix release (8.4.1) is scheduled for November 1, 2017.

    Updating your site from 8.3.7 to 8.4.0 with update.php is exactly the same as updating from 8.3.6 to 8.3.7. If you use Drush, be sure to update to Drush 8.1.12 or higher before using it to update Drupal 8.3.7 to 8.4.0. Drupal 8.4.0 also has major updates to several dependencies, including Symfony, jQuery, and jQuery UI. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site.

    Drupal 7 site owners

    Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

    Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

    Drupal 6 site owners

    Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

    Translation, module, and theme contributors

    Minor releases like Drupal 8.4.0 include backwards-compatible API additions for developers as well as new features. Read the 8.4.0 release notes for more details on the improvements for developers in this release.

    Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.3.x and earlier will be compatible with 8.4.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.4.0 release candidate for more background information.

  • State of Drupal presentation (September 2017)

    This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

    Group photo

    Yesterday, I shared my State of Drupal presentation at DrupalCon Vienna. In addition to sharing my slides, I wanted to provide some more detail on how Drupal is evolving, who Drupal is for, and what I believe we should focus on.

    Drupal is growing and changing

    I started my keynote by explaining that Drupal is growing. Over the past year, we've witnessed a rise in community engagement, which has strengthened Drupal 8 adoption.

    This is supported by the 2017 Drupal Business Survey; after surveying 239 executives from Drupal agencies, we can see that Drupal 8 has become the defacto release for them and that most of the Drupal businesses report to be growing.

    Drupal 8 Agency Adoption

    Drupal Agency Growth

    While the transition from Drupal 7 to Drupal 8 is not complete, Drupal 8's innovation continues to accelerate. We've seen the contributed modules ecosystem mature; in the past year, the number of stable modules has more than doubled. Additionally, there are over 4,000 modules in development.

    Drupal 8 module readiness

    In addition to growth, both the vendor and technology landscapes around Drupal are changing. In my keynote, I noted three primary shifts in the vendor landscape. Single blogs, portfolio sites and brochure sites, which represent the low end of the market, are best served by SaaS tools. On the other side of the spectrum, a majority of enterprise vendors are moving beyond content management into larger marketing suites. Finally, the headless CMS market segment is growing rapidly, with some vendors growing at a rate of 500% year over year.

    There are also significant changes in the technology landscape surrounding Drupal, as a rising number of Drupal agencies have also started using modern JavaScript technologies. For example, more than 50% of Drupal agencies are also using Node.js to support the needs of their customers.

    Changing technology stack

    While evolving vendor and technology landscapes present many opportunities for Drupal, it can also introduce uncertainty. After listening to many people in the Drupal community, it's clear that all these market and technology trends, combined with the long development and adoption cycle of Drupal 8, has left some wondering what this all means for Drupal, and by extension also for them.

    Drupal is no longer for simple sites

    Over the past year, I've explained why I believe Drupal is for ambitious digital experiences, in both my DrupalCon Baltimore keynote and on my blog. However, I think it would be valuable to provide more detail on what I mean by "ambitious digital experiences". It's important that we all understand who Drupal is for, because it drives our strategy, which in turn allows us to focus our efforts.

    Today, I believe that Drupal is no longer for simple sites. Instead, Drupal's sweetspot is sites or digital experiences that require a certain level of customization or flexibility — something I refer to as "richness".

    Who is Drupal for?

    Ambitious is much more than just enterprise

    This distinction is important because I often find that the term "ambitious" becomes conflated with "enterprise". While I agree that Drupal is a great fit for the enterprise, I personally never loved that categorization. It's not just large organizations that use Drupal. Individuals, small startups, universities, museums and nonprofits can be equally ambitious in what they'd like to accomplish and Drupal can be an incredible solution for them.

    An example of this could be a small business that manages 50 rental properties. While they don't have a lot of traffic (reach), they require integrations with an e-commerce system, a booking system, and a customer support tool to support their business. Their allotted budget is $50,000 or less. This company would not be considered an enterprise business; however, Drupal would be a great fit for this use case. In many ways, the "non-enterprise ambitious digital experiences" represent the majority of the Drupal ecosystem. As I made clear in my presentation, we don't want to leave those behind.

    Drupal is for ambitious digital experiences

    Addressing the needs of smaller organizations

    The Drupal ecosystem majority are organizations with sites that require medium-to-high richness, which SaaS builders cannot support. However, they also don't need to scale at the level of enterprise companies. As the Drupal community continues to consider how we can best support this majority, a lot of smaller Drupal agencies and end-users have pointed out that they would benefit from the following two things:

    1. Powerful site building tools. They want easy-to-use site building tools that are simple to learn, and don't require dozens of contributed modules to be installed and configured. They would also prefer to avoid writing a lot of custom code because their clients have smaller budgets. Great examples of tools that would improve site building are Drupal's upcoming layout builder, workspaces and media library. To make some of Drupal's own administrative UIs more powerful and easier to use, I proposed that we add a modern JavaScript to core.
    2. Easier updates and maintenance. While each Drupal 8 site benefits from continuous innovation, it also needs to be updated more often. The new Drupal 8 release cycle has monthly patch releases and 6-month minor releases. In addition, organizations have to juggle ad-hoc updates from contributed modules. In addition, site updates has often become more complex because our dependency on third-party libraries and because not everyone can use Composer. Many smaller users and agencies would benefit tremendously from auto-updates because maintaining and updating their Drupal 8 sites can be too manual, too complex and too expensive.

    The good news is that we have made progress in both improving site builder tools and simplifying updates and maintenance. Keep an eye on future blog posts about these topics. In the meantime, you can watch a recording of my keynote (starting at 22:10), or you can download a copy of my slides (56 MB).