
























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Drupal 8 Ultimate Guide for users
Typology: Study Guides, Projects, Research
1 / 32
This page cannot be seen from the preview
Don't miss anything!
Authoring Experience
A major area of focus in Drupal 8 was around the out-of-the-box experience for content authors and editors—the folks who actually use a Drupal website every day. Here are some of the changes you’ll see.
Spark is an Acquia initiative created by Dries Buytaert to improve Drupal core’s default authoring experience. The Acquia development team for Drupal core analysed both proprietary and open source competitors to Drupal and worked hard to make usability enhancements to Drupal core over the course of the release in collaboration with other Drupal core contributors. They also created back ports of key Drupal 8 UX improvements for Drupal 7 , which allowed them to be tested and improved under everyday, real use even before the release of Drupal 8.
Drupal 8 ships with the CKEditor WYSIWYG editor in the default installation. In addition to supporting what you’d expect in a WYSIWYG editor—buttons for bold, italic, images, links, and so on—it supports extras, such as easily editable image captions, thanks to CKEditor’s new Widgets feature, developed specifically for Drupal’s use. It is fully integrated into Drupal 8, from user roles and permissions to image management, and it ensures that we keep the benefits of Drupal’s structured content concepts in our WYSIWYG implementation.
Drupal 8 also sports a drag- and-drop admin interface for adding and removing buttons in the WYSIWYG toolbar, which automatically syncs the allowed HTML tags for a given text format, vastly improving usability. Buttons are contained in “button groups” with labels that are invisible to the naked eye, but that can be read by screen readers, providing an amazing, accessible editing experience for visually impaired users.Though core will only support CKEditor, Drupal 8’s Editor module wraps around the WYSIWYG integration, so other libraries and contrib modules can be tightly integrated as well.
In Drupal 7, if you need to make a correction on a website—for example, a typo, or a missing image—you must use a back-end form, which is visually separated from the front-end website where content will appear. The Preview button doesn’t help, because the results of preview are shown in the administrative theme (twice, in case you missed it the first time).
Drupal 8’s in-place editing feature allows editors to click into any field within a piece of content, anywhere it appears on the front-end of the site and edit it right there, without ever visiting the back-end editing form. Full node content, user profiles, custom blocks, and more are all editable in-place as well.
To replace Drupal 7’s default editing behavior, which required a more time-consuming visit to the administrative back-end of the site, this in-place editing feature has been backported to Drupal 7 as the Quick Edit module.
A community-led effort from Drupal’s Usability team resulted in a redesigned content creation page in Drupal 8. It contains two columns: one for the main fields (the actual “content” part of your content) and another for the “extras”—optional settings that are used less often. The new design lets content authors focus on the task at hand while having important publishing options just a click away.
The administrative theme in Drupal 8 is a visually refreshed version of Drupal 7’s, based on a formal style guide which can also be used by module developers and others concerned about backend usability.
A draft revision-state for content is now has API support under-the-hood in Drupal 8 core. This will make publishing-workflow modules, like Workbench , much easier to implement in Drupal 8 and beyond.
The Responsive Bartik and Responsive Tables modules can make Drupal 7 behave similarly. Numerous responsive base themes for Drupal 7, including Omega and Zen , help you build a responsive design for your website.
Drupal 8 sports a responsive administrative toolbar that automatically expands and orients itself horizontally on wide screens and collapses down to icons and orients itself vertically on smaller screens. Like all new front-end features in Drupal 8, this one was designed with accessibility in mind. The toolbar allows screen-reader users to easily navigate to various parts of a site.
If you’re interested in this feature for Drupal 7, check out the Mobile Friendly Navigation Toolbar module.
One of the biggest factors that can make or break the mobile experience is the raw performance of a website. As a result, a lot of work went into minimizing Drupal 8’s front-end footprint. Page loads were sped up by replacing jQuery with efficient, targeted, native JavaScript in many cases and out-of-the-box Drupal 8 loads no JavaScript files at all for anonymous visitors. Drupal 8’s caching is a big advance over Drupal 7’s. It includes entity caching and powerful, granular cache tags which allow for targeted cache clearing so pages stay fast longer. Drupal 8.1 also introduces BigPipe page delivery as an experimental core module in Drupal 8.1. See the Backend Developer Improvements chapter of this ebook for more on caching and BigPipe’s effect on user experience thanks to faster perceived loading. Additionally, lighter-weight, mobile-friendly alternatives replaced JavaScript-intensive features like the Overlay module. Drupal 8 uses a simple “Back to site” link in the admin toolbar while in an administrative context. See Escape Admin for a Drupal 7 equivalent.
Multilingual++
The Multilingual Initiative (D8MI), led by Acquia’s own Gábor Hojtsy with the participation of over 1,000 contributors , was a major development focus for Drupal 8. Check out Gábor’s excellent Drupal 8 Multilingual Tidbits series if you’re interested in all the details about D8MI.
Drupal 8 is a CMS built from the ground up for multilingual use. You can perform your entire site installation and setup in your language of choice. Right on the installer page, it auto-detects your browser’s language and auto-selects that language for installation in the drop-down for your convenience. When you install Drupal in any language other than English (or later add a new language to your site), Drupal 8 automatically downloads the latest interface translations from localize.drupal.org in your language, too. This works for right-to-left languages, such as Arabic and Hebrew, too. Drupal’s interface translations are dependent on local communities for accuracy and completeness, so some translations may be missing some strings. On localize.drupal.org , you can always contribute those yourself and help your language community take advantage of Drupal. Drupal 8 does away with the previous Drupal-concept of English as a “special” language. If you select a language other than English on installation, the English option will no longer show in
your site configuration unless explicitly turned on. Also, you can make English itself “translatable” so that you can convert strings to something more tailored to your users. For example, you can change “Log in / Log off” to “Sign in / Sign off.”
Drupal’s international community put a lot of effort into the user experience of Drupal 8’s multilingual functionality. You’ll see well-integrated and streamlined translation interfaces throughout Drupal 8.
One really handy addition to Drupal 8 is the inclusion of the Transliteration module in core. It automatically converts special characters like “ç” and “ü” to “c” and “u” for friendlier, more human-readable machine names, file uploads, paths, and search results.
Here are some extras for site builders that are worth mentioning:
Several of the pages in core that are using Views allow for much easier language-based customization, especially the admin views, where adding language filters, a language column, and so on, are easy to put together. The Drupal 8 core Content Translation module is well-integrated with Search in core and the Search API can access language information as well. The language selection system now supports one or more separate admin languages, for easier management of multilingual sites by site admins who might speak different languages.
Site Builders FTW
Although the authoring experience improvements and mobile improvements in Drupal 8 tend to focus on end users and content authors of Drupal websites, Drupal 8 also includes a huge push to improve the site building tools.
The Views module, the most frequently used contributed module in Drupal , is now part of Drupal 8 core and is more tightly integrated into Drupal then ever before. Beyond providing a query-builder UI and serving up the results in a variety of formats for site visitors, baking Views into Drupal core allowed core developers to replace numerous previously hardcoded admin pages with Views listings. This removed thousands of lines of boilerplate code from Drupal core and more importantly, gives site builders the power to customise most of the main administrative listings (or even build brand new ones!). The Content, People, and Files admin pages, as well as various sidebar blocks, several RSS feeds, and the default front page have been converted to Views. Almost everyone who has built a site of any complexity in Drupal knows how to use Views. This makes customizations of these pages—for example
to add a “Full name” search to the People listing, or thumbnails next to items in the Content listing—just a few clicks away.
Everything you know and love from Views is included in Drupal 8 core—and even a few extras such as mobile-friendly administration, some user experience and accessibility improvements, the ability to create responsive table listings, and the ability to turn any listing into a REST export that can be consumed by a mobile application or other external service.
In Drupal 8, you’ll notice a few new features as they relate to blocks. First, just like with Views replacing admin pages, several previously hard-coded site components have been converted to blocks, including breadcrumbs, site name, and slogan. This makes it easier to adjust page organization in the user interface, and enables in-place editing, and makes for easier theming.
Drupal 8’s new Tour module lets site builders create contextual, step-by-step tooltip-style walkthroughs of your site. It can help with overviews of administrative interfaces, introduce new terminology, and walk through the steps involved in configuring components of your site.
You’ll find Drupal 8 missing some modules that shipped with Drupal 7, namely Blog, Dashboard, Open ID, Overlay, PHP filter, Poll, Profile, and Trigger (as well as the Garland theme). You’ll find several new modules in which functionality has been split out into more granular chunks, such as Menu Links/Menu UI, Block/Custom Block, Ban/History/Actions (formally baked into User/Node/System module), and so on.
Heather James’s “Drupal 8 Site Building Preview—Less Is More” has a great rundown of the state of modules, including contrib modules that are now rendered obsolete due to the functionality that ships with Drupal 8 core.
The bottom line: Drupal core ships with enough functionality out-of-the-box that for the first time site builders should be able to create fairly sophisticated sites without having to install 30+ contributed modules. Hooray!
Drupal’s major version upgrade path has been replaced with a migration path, courtesy of a D8 port of the Migrate and Migrate Drupal-to-Drupal modules. As of Drupal 8.1, there is also a Migration UI in core, which allows major Drupal version migrations without resorting to command-line tools. Both a migration path from Drupal 6 (already in Drupal 8.x) and Drupal 7 (partially in 8.x and under development) are supported. The migration path allows you to keep your Drupal 6/7 site running while you build your new Drupal 8 site, greatly minimizing downtime over the old update.php method.
For more on Drupal 8’s improved major version upgrade process, check out Moshe Weitzman’s “Drupal 8—Improved Upgrade Process” blog from December 2013.
.
Front-end Developer Improvements
Drupal 8 contains a lot of improvements for front-end developers, including HTML5, additional helper libraries, accessibility enhancements, new themes and UI elements, and faster performance, to name a few.
All of Drupal’s output has been converted to use semantic HTML5 markup by default, as part of an overarching effort to clean up Drupal’s default markup. This means you’ll find tags such as
HTML5 also brings new form input types, such as date, tel, and email, that can provide targeted user interfaces on mobile devices (for example, only showing the number pad when entering phone numbers) to help streamline data entry. Drupal’s Form API provides these additional types so you can easily create these new types of fields. The Drupal 7 equivalent can be found in the Elements module.
Drupal has shipped with jQuery since Drupal 5 and jQuery UI since Drupal 7. Drupal 8 brings with it an expanded array of front-end libraries. Together, these additional libraries allow for creating mobile-friendly, rich front-end applications in Drupal, and they’re used by several of the Authoring Experience and Mobile feature improvements to Drupal 8. These include:
The following is an excerpt from page.html.twig (the equivalent of page.tpl.php in Drupal 7), showing off some Twig features, some HTML5 tags and native ARIA support as well:
{# link is in html.html.twig #}How do you provide those variables if you can no longer use PHP in templates directly? With THEME_preprocess_HOOK() functions, you do it the same way you’ve always done (although they are in a file named THEME.theme instead of template.php).
Twig effectively forces a separation of presentation and business logic, and all variables going into template files are automatically escaped, far reducing the risk of dangers like XSS vulnerabilities and making theming in Drupal 8 more secure than ever before.
Another nice tidbit from Twig is that if you turn on debug mode using debug: true; in your site’s services.yml file, helpful code comments will be displayed throughout Drupal’s generated markup to inform you where to find the template for the markup you’re trying to change, and which particular “theme suggestion” is being used to generate the markup. These also allow you to create alternate templates and have them override the main one based on the specificity of their name (like CSS selectors) and use case. It’s a bit like having the fabulous Theme developer module baked into core! For example:
Acquia’s own llama-loving performance guru Wim Leers posited that the best way to make the Internet as a whole faster is to make the leading CMSes fast by default. This means that CMS’s need to have their high-performance settings enabled out-of- the-box rather than require users to be savvy enough to find them in all their various locations. And in Drupal 8, that’s exactly what we’ve done. You’ll notice that Drupal 8 ships with features such as CSS and JavaScript aggregation already turned on for a much faster default installation. Huzzah!
What this means to you as a front-end developer is that by default Drupal is not immediately in a good place to start theming, unless you manually turn off those performance settings one by one (even hacking core’s CSS directly will show absolutely no changes). Fortunately, Drupal 8 ships with a sites/example. settings. local.php file for exactly this purpose. It hard codes the performance settings to off, which is extremely useful in a development environment. Simply copy it, rename it as sites/default/settings.local.php, and uncomment the following lines in sites/ default/settings.php:
Your new settings.local.php file points to development.services.yml, which contains some disabled-by-default settings about Twig specifically, for example ones for turning on debug mode and turning off caching. Changing these settings to true will definitely make your dev site slower but will also make theming much easier, because you’ll be able to see the results of your changes to Twig templates immediately, without having to clear the cache.
In other front-end performance-related news, while Drupal 8 still ships with the latest versions of jQuery and jQuery UI, a lot of movement is going away from using libraries like this in favor of run-of-the-mill JavaScript to keep front-end performance as quick as possible, which is especially important for mobile devices. The default install of Drupal 8 actually doesn’t load any JavaScript for anonymous users!
Drupal 8 ships with several new UI elements that you can use in your own admin screens, including modal dialogs and drop buttons, which were part of the Chaos tool suite (ctools) module in Drupal 7 and below. Drupal 8 introduces the concept of “button types,” “primary” (the default form action; styled blue in the default admin theme), and “danger” (styled as red links) to help users recognize and make correct choices when confronted with multiple options on a form.
Back-end Developer Improvements
Drupal 8 gives you lots of back-end developer improvements, including an API for configuring your system. All entities are now classed as objects. You also get improved caching, better integration with third-party services, and lots of built-in web services features. It just keeps getting better.
Probably the most looked-forward-to change in Drupal 8, for both developers and site builders, is the new configuration management system. In Drupal 7 and below, both content and configuration were saved to the database (sometimes with a mix of both in the same table), making deploying configuration changes from one environment to another (for example, development to production) very tricky. A variety of workarounds emerged for this, including hook_update_N() , Features module , and of course the old standby: carefully writing the configuration changes you made in development on a napkin and then manually repeating them in production. However, all these were attempting to circumvent the fundamental problem that Drupal core didn’t properly support configuration deployment natively—until Drupal 8, that is.
In Drupal 8, all configuration changes (both standard admin settings forms, such as site name, as well as any ConfigEntity including Views, user roles, and content types) run through a unified configuration API. Each environment has a “sync” directory to hold configuration changes from other environments that are about to be imported for review. For performance, active configiration is stored in a config table in the database, though the storage location is swappable (e.g. to something like Redis or Cassandra).
Drupal 8 also ships with a basic UI to do both single and full configuration imports and exports, and configuration can also be moved around via the command line with Drush’s config-* commands, which is handy when using version control systems such as Git.
The basic workflow (after making whatever configuration changes to your Drupal 8 site) is:
Of course, there are some settings that are specific to a given environment that you don’t want to be deployed across environments; for example, the timestamp storing the last time cron ran. For these more ephemeral settings, there’s a “sister” API to the configuration API named the State API. There’s also the Configuration Development module, which automatically exports/imports active configuration in files and is handy during development.
What About Content Deployment? Drupal 8.1 core ships with alpha-stability-support for migrating content such as nodes, users, and taxonomy terms between sites via the Migrate, Migrate Drupal, and the Migrate Drupal UI core experimental modules. Nonetheless, one welcome addition to Drupal 8 has been the introduction of UUIDs (universally unique identifiers) to every piece of content. These UUIDs can be used to determine whether a piece of content from a source site exists on a given destination site. This makes content imports/exports infinitely easier because even if source and destination sites have a node/100, for example, if the content is different, each will have a unique (obviously!) UUID. Keep your eyes on the Deploy module for a Drupal 8 version that provides this feature. If you’re still on Drupal 7, you can get similar functionality to what core offers via the Universally Unique IDentifier module.
Entities were a key new feature and concept in Drupal 7, abstracting the ability to add fields to other types of content than just nodes, such as users and taxonomy terms.
In Drupal 8, the Entity API has been completely overhauled to greatly improve the developer experience and fill in the gaps in functionality compared to the Drupal 7 core API. All entities are now classed objects that implement a standard EntityInterface (no more guessing which of the 100 entity hooks you’re required to implement), with baked-in knowledge about the active language (to aid in translation and localization). Compare and contrast how this is done in D7 and D8:
Drupal 7
title $node->body[$langcode][0][‘value’] ?>Drupal 8
get(‘title’)->value $node->get(‘body’)->value ?>