Drupal

KnackForge: How to update Drupal 8 core?

Planet Drupal - 23 March 2018 - 10:01pm
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categories: Drupal

Valuebound: Drupal 8: How to create a custom block programatically

Planet Drupal - 18 December 2016 - 11:33pm
Drupal 8: How to create a custom block programatically Jaywant.Topno Mon, 12/19/2016 - 02:33
Categories: Drupal

Valuebound: Drupal 8: Custom Block Creation programmatically

Planet Drupal - 18 December 2016 - 11:33pm
Drupal 8: Custom Block Creation programmatically Jaywant.Topno Mon, 12/19/2016 - 02:33
Categories: Drupal

Evolving Web: Using Core Base Themes in Drupal 8

Planet Drupal - 15 hours 41 min ago

One of the first questions I get asked when teaching a Drupal theming class is which base theme to use. The answer has always starts with the unsatisfying: "It depends". Now that I'm teaching Drupal 8 theming, we have a couple new base themes in core added to the mix: classy and stable.

You can learn the difference between the two and how to use them in this previous post.

read more
Categories: Drupal

Mediacurrent: Friday 5: 5 Problems Large Enterprise Face in Their Digital Transformation

Planet Drupal - 15 hours 42 min ago

Give yourself a pat on the back for making it to the finish line of another busy work week!

Categories: Drupal

Farm Bee

New Drupal Modules - 15 hours 56 min ago

Features for beekeeping.

This module is an add-on for farmOS.

Description available on GitHub: http://github.com/farmOS/farm_bee

Categories: Drupal

Lullabot: Replacing the Body Field in Drupal 8

Planet Drupal - 16 hours 48 min ago

The body field has been around since the beginning of Drupal time. Before you could create custom fields in core, and before custom entities were in core, there was a body field. As it exists now, the body field is a bit of a platypus. It's not exactly a text field like any other text field. It's two text fields in one (summary and body), with a lot of specialized behavior to allow you to show or hide it on the node form, and options to either create distinct summary text or deduce a summary by clipping off a certain number of characters from the beginning of the body.

The oddity of this field can create problems. The summary has no format of its own, it shares a format with the body. So you can't have a simple format for the summary and a more complex one for the body. The link to expose and hide the summary on the edit form is a little non-intuitive, especially since no other field behaves this way, so it's easy to miss the fact that there is a summary field there at all. If you are relying on the truncated text for the summary, there's no easy way to see in the node form what the summary will end up looking like. You have to preview the node to tell.

I wanted to move away from using the legacy body field in favor of separate body and summary fields that behave in a more normal way, where each is a distinct field, with its own format and no unexpected behavior. I like the benefits of having two fields, with the additional granularity that provides. This article describes how I made this switch on one of my legacy sites.

Making the Switch

The first step was to add the new fields to the content types where they will be used. I just did this in the UI by going to admin > structure > types. I created two fields, one called field_description for the full body text and one called field_summary for the summary. My plan was for the summary field to be a truncated, plain text excerpt of the body that I could use in metatags and in AMP metadata, as well as on teasers. I updated the Manage Display and Manage Form Display data on each content type to display my new fields instead of the old body field on the node form and in all my view modes.

Once the new fields were created I wanted to get my old body/summary data copied over to my new fields. To do this I needed an update hook. I used Drupal.org as a guide for creating an update hook in Drupal 8.

The instructions for update hooks recommend not using normal hooks, like $node->save(), inside update hooks, and instead updating the database directly with a SQL query. But that would require understanding all the tables that need to be updated. This is much more complicated in Drupal 8 than it was in Drupal 7. In Drupal 7 each field has exactly two tables, one for the active values of the field and one with revision values. In Drupal 8 there are numerous tables that might be used, depending on whether you are using revisions and/or translations. There could be up to four tables that need to be updated for each individual field that is altered. On top of that, if I had two fields in Drupal 7 that had the same name, they were always stored in the same tables, but in Drupal 8 if I have two fields with the same name they might be in different tables, with each field stored in up to four tables for each type of entity the field exists on.

To avoid any chance of missing or misunderstanding which tables to update, I went ahead and used the $node->save() method in the update hook to ensure every table gets the right changes. That method is time-consuming and could easily time out for mass updates, so it was critical to run the updates in small batches. I then tested it to be sure the batches were small enough not to create a problem when the update ran.

The update hook ended up looking like this:

<?php /** * Update new summary and description fields from body values. */ function custom_update_8001(&$sandbox) { // The content types to update. $bundles = ['article', 'news', 'book']; // The new field for the summary. Must already exist on these content types. $summary_field = 'field_summary'; // The new field for the body. Must already exist on these content types. $body_field = 'field_description'; // The number of nodes to update at once. $range = 5; if (!isset($sandbox['progress'])) { // This must be the first run. Initialize the sandbox. $sandbox['progress'] = 0; $sandbox['current_pk'] = 0; $sandbox['max'] = Database::getConnection()->query("SELECT COUNT(nid) FROM {node} WHERE type IN (:bundles[])", array(':bundles[]' => $bundles))->fetchField(); } // Update in chunks of $range. $storage = Drupal::entityManager()->getStorage('node'); $records = Database::getConnection()->select('node', 'n') ->fields('n', array('nid')) ->condition('type', $bundles, 'IN') ->condition('nid', $sandbox['current_pk'], '>') ->range(0, $range) ->orderBy('nid', 'ASC') ->execute(); foreach ($records as $record) { $node = $storage->load($record->nid); // Get the body values if there is now a body field. if (isset($node->body)) { $body = $node->get('body')->value; $summary = $node->get('body')->summary; $format = $node->get('body')->format; // Copy the values to the new fields, being careful not to wipe out other values that might be there. if (empty($node->{$summary_field}->getValue()) && !empty($summary)) { $node->{$summary_field}->setValue(['value' => $summary, 'format' => $format]); } if (empty($node->{$body_field}->getValue()) && !empty($body)) { $node->{$body_field}->setValue(['value' => $body, 'format' => $format]); } if ($updated) { // Clear the body values. $node->body->setValue([]); } } // Force a node save even if there are no changes to force the pre_save hook to be executed. $node->save(); $sandbox['progress']++; $sandbox['current_pk'] = $record->nid; } $sandbox['#finished'] = empty($sandbox['max']) ? 1 : ($sandbox['progress'] / $sandbox['max']); return t('All content of the types: @bundles were updated with the new description and summary fields.', array('@bundles' => implode(', ', $bundles))); } ?> Creating the Summary

That update would copy the existing body data to the new fields, but many of the new summary fields would be empty. As distinct fields, they won't automatically pick up content from the body field, and will just not display at all. The update needs something more to get the summary fields populated. What I wanted was to end up with something that would work similarly to the old body field. If the summary is empty I want to populate it with a value derived from the body field. But when doing that I also want to truncate it to a reasonable length for a summary, and in my case I also wanted to be sure that I ended up with plain text, not markup, in that field.

I created a helper function in a custom module that would take text, like that which might be in the body field, and alter it appropriately to create the summaries I want. I have a lot of nodes with html data tables, and I needed to remove those tables before truncating the content to create a summary. My body fields also have a number of filters that need to do their replacements before I try creating a summary. I ended up with the following processing, which I put in a custom.module file:

<?php use Drupal\Component\Render\PlainTextOutput; /** * Clean up and trim text or markup to create a plain text summary of $limit size. * * @param string $value * The text to use to create the summary. * @param string $limit * The maximum characters for the summary, zero means unlimited. * @param string $input_format * The format to use on filtered text to restore filter values before creating a summary. * @param string $output_format * The format to use for the resulting summary. * @param boolean $add_elipsis * Whether or not to add an elipsis to the summary. */ function custom_parse_summary($value, $limit = 150, $input_format = 'plain_text', $output_format = 'plain_text', $add_elipsis = TRUE) { // Allow filters to replace values so we have all the original markup. $value = check_markup($value, $input_format); // Completely strip tables out of summaries, they won't truncate well. // Stripping markup, done next, would leave the table contents, which may create odd results, so remove the tables entirely. $value = preg_replace('/(.*?)<\/table>/si', '', $value); // Strip out all markup. $value = PlainTextOutput::renderFromHtml(htmlspecialchars_decode($value)); // Strip out carriage returns and extra spaces to pack as much info as possible into the allotted space. $value = str_replace("\n", "", $value); $value = preg_replace('/\s+/', ' ', $value); $value = trim($value); // Trim the text to the $limit length. if (!empty($limit)) { $value = text_summary($value, $output_format, $limit); } // Add elipsis. if ($add_elipsis && !empty($value)) { $value .= '...'; } return $value; } ?> Adding a Presave Hook

I could have used this helper function in my update hook to populate my summary fields, but I realized that I actually want automatic population of the summaries to be the default behavior. I don't want to have to copy, paste, and truncate content from the body to populate the summary field every time I edit a node, I'd like to just leave the summary field blank if I want a truncated version of the body in that field, and have it updated automatically when I save it.

To do that I used the pre_save hook. The pre_save hook will update the summary field whenever I save the node, and it will also update the summary field when the above update hook does $node->save(), making sure that my legacy summaries also get this treatment.

My pre_save hook, in the same custom.module file used above, ended up looking like the following:

<?php use Drupal\Core\Entity\EntityInterface; /** * Implements hook_entity_presave(). * * Make sure summary and image are populated. */ function custom_entity_presave(EntityInterface $entity) { $entity_type = 'node'; $bundles = ['article', 'news', 'book']; // The new field for the summary. Must already exist on these content types. $summary_field = 'field_summary'; // The new field for the body. Must already exist on these content types. $body_field = 'field_description'; // The maximum length of any summary, set to zero for no limit. $summary_length = 300; // Everything is an entity in Drupal 8, and this hook is executed on all of them! // Make sure this only operates on nodes of a particular type. if ($entity->getEntityTypeId() != $entity_type || !in_array($entity->bundle(), $bundles)) { return; } // If we have a summary, run it through custom_parse_summary() to clean it up. $format = $entity->get($summary_field)->format; $summary = $entity->get($summary_field)->value; if (!empty($summary)) { $summary = custom_parse_summary($summary, $summary_length, $format, 'plain_text'); $entity->{$summary_field}->setValue(['value' => $summary, 'format' => 'plain_text']); } // The summary might be empty or could have been emptied by the cleanup in the previous step. If so, we need to pull it from description. $format = $entity->get($body_field)->format; $description = $entity->get($body_field)->value; if (empty($summary) && !empty($description)) { $summary = custom_parse_summary($description, $summary_length, $format, 'plain_text'); $entity->{$summary_field}->setValue(['value' => $summary, 'format' => 'plain_text']); } } ?>

With this final bit of code I’m ready to actually run my update. Now whenever a node is saved, including when I run the update to move all my legacy body data to the new fields, empty summary fields will automatically be populated with a plain text, trimmed, excerpt from the full text.

Going forward, when I edit a node, I can either type in a custom summary, or leave the summary field empty if I want to automatically extract its value from the body. The next time I edit the node the summary will already be populated from the previous save. I can leave that value, or alter it manually, and it won't be overridden by the pre_save process on the next save. Or I can wipe the field out if I want it populated automatically again when the node is re-saved.

Javascript or Presave?

Instead of a pre_save hook I could have used javascript to automatically update the summary field in the node form as the node is being edited. I would only want that behavior if I'm not adding a custom summary, so the javascript would have to be smart enough to leave the summary field alone if I already have text in it or if I start typing in it, while still picking up every change I make in the description field if I don’t. And it would be difficult to use javascript to do filter replacements on the description text or have it strip html as I'm updating the body. Thinking through all the implications of trying to make a javascript solution work, I preferred the idea of doing this as a pre_save hook.

If I was using javascript to update my summaries, the javascript changes wouldn't be triggered by my update hook, and the update hook code above would have to be altered to do the summary clean up as well.

Ta-dah

And that's it. I ran the update hook and then the final step was to remove my now-empty body field from the content types that I switched, which I did using the UI on the Content Types management page.

My site now has all its nodes updated to use my new fields, and summaries are getting updated automatically when I save nodes. And as a bonus this was a good exercise in seeing how to manipulate nodes and how to write update and pre_save hooks in Drupal 8.

Categories: Drupal

OSTraining: Installing Drupal-VM on Windows

Planet Drupal - 19 hours 56 min ago

An OSTraining member asked how to use the Drupal VM environment on Windows.

In this tutorial, we will install D8 in a few simple steps.

Categories: Drupal

Frederic Marand: What to do when your Drupal site has been hacked

Planet Drupal - 22 hours 12 min ago

These are the slides of the presentation I gave yesterday at DrupalDevDays Milan.

Life after the hack from OSInet, for Drupal Project

read more

Categories: Drupal

Slack chat

New Drupal Modules - 23 June 2016 - 9:36pm
Categories: Drupal

Express Add Content

New Drupal Modules - 23 June 2016 - 8:01pm

Express Add Content provides a hook in which you can group content types and block types (provided by the bean module) into categories which you define. This module provides no user interface to group content types and block types - this can only be accomplished by adding the hook sin your own custom module.

Categories: Drupal

Hook 42: Block improvements in Drupal 8

Planet Drupal - 23 June 2016 - 5:53pm
Thursday, June 23, 2016

Blocks in Drupal 7 are pretty useful but, in practice, larger sites often have requirements that core blocks can't support like placing the same block in different regions for different content types. I’m happy to see core blocks have been improved in Drupal 8 to be much more practical and powerful.

I was fortunate to attend the Drupal North conference this month in Montreal. At Drupal North, Ted Bowman gave a nice presentation on the power of Drupal 8 blocks. Ted has also has created a helpful Drupal 8 contrib module called Block Visibility Groups that extends blocks even further.

In his talk, he explained some of the new abilities of blocks including:

  • Blocks can be exported
  • Blocks can be placed in different regions
  • Blocks can have fields

Let’s take a look at these new features and the Block Visibility Groups module in more depth.

Blocks can be exported

First, blocks are now exportable. In Drupal 7, block settings can be moved through the development workflow with Features, but it isn't always reliable. In Drupal 8, block settings are saved in core configuration files and these files can be checked into your favorite code repository such as git.

Example of a block configuration file in D8

Blocks can be placed in different regions

Another improvement in Drupal 8 is that a particular block can be in more than one theme region. For example, if a site needs to have the same block on two different pages in two different regions that is not possible with core blocks in Drupal 7. Site builders have to use other methods, such as using Panels or Context to achieve this.

Now, in Drupal 8, placing the same block in different regions for different pages (or even on the same page!) is possible. Let’s see how that looks.

Example of the "Help" block being placed in two regions

Blocks can have fields

Another important difference for Drupal 8 core blocks is that they can have fields. In Drupal 7, we have to use the Bean (Blocks Entities Aren't Nodes) module to have fields on our blocks.

In D8, you can add fields to blocks in the same way you add them to content types or other fieldable entities. This feature changes block versatility immensely! We can have block types of various flavors and use those in intelligent ways. For example, we could have a block type that has just links in it or one with a text blurb and an image. Using block types is much better for structured content (which is the basis of a solid content strategy).

Example of a custom block type with a custom field

Blocks are even better with contrib

The block system has improved with the help of D8 contributed modules as well. An excellent example of this is Ted Bowman’s Block Visibility Groups module. With this small module enabled, administrators can manage where all blocks are visible. This admin tool is a valuable UX improvement and an alternative to Panels for less complex sites in Drupal 8.

Have fun with your Drupal 8 blocks! Kristin Bradham - K2 Topics: Services:
Categories: Drupal

Acquia Developer Center Blog: Signal Flow, Understanding your Stack

Planet Drupal - 23 June 2016 - 12:20pm

One of the best troubleshooters we ever worked with is a former sound engineer. He taught us, “Follow the signal, it’s all signal flow.” Running a website, your stack is the combination of hardware and software that you use to deliver your website and the “signal” is a web request. To understand the “signal flow” of your site, you will need to understand your stack. Understanding how all of the pieces fit together lets you know where to start looking for the problems.

Tags: acquia drupal planetsupportdebugging
Categories: Drupal

Freelock : Ask Freelock: My host is shutting down! What should I do?

Planet Drupal - 23 June 2016 - 10:57am

It's really a shame. Drupal Gardens has announced to its users that it's shutting down completely on August 1, and users need to move away from the service before it disappears.

It's a shame because Drupal Gardens was the only low-cost way to run a Drupal site with somebody else handling maintenance for you.

But it's not really a surprise.

DrupalDrupal PlanetSaaSHosting
Categories: Drupal

Aten Design Group: Making region content available to node templates in Drupal 8

Planet Drupal - 23 June 2016 - 10:06am

Why would you need to render the content from Drupal’s block layout via a node template file? Normally, that is the territory of page templates. The use-case for me was a page where node-specific fields were mixed in with blocks to the extent that rendering region content in a page template file wasn't going to work.

I needed to be able to render my region content amidst field values in my node template files. Drupal doesn't let you do that out-of-the-box.

Superpower your Nodes

A region defined as ‘Primary Content’ (primary_content) in our theme can be printed in a page template like so:

{{ page.primary_content }}

Try that in a node template and you get a big fat nothing. Using THEME_preprocess_node we can change this, and superpower our node templates to be as capable as page templates.

Replace “THEME” with your theme name below:

/** * Implements hook_preprocess_node() for NODE document templates. */ function THEME_preprocess_node(&$variables) { // Allowed view modes $view_mode = $variables['view_mode']; // Retrieve view mode $allowed_view_modes = ['full']; // Array of allowed view modes (for performance so as to not execute on unneeded nodes)   // If view mode is in allowed view modes list, pass to THEME_add_regions_to_node() if(in_array($view_mode, $allowed_view_modes)) { // Allowed regions (for performance so as to not execute for unneeded region) $allowed_regions = ['primary_content']; THEME_add_regions_to_node($allowed_regions, $variables); } }   /** * THEME_add_regions_to_node */   function THEME_add_regions_to_node($allowed_regions, &$variables) { // Retrieve active theme $theme = \Drupal::theme()->getActiveTheme()->getName();   // Retrieve theme regions $available_regions = system_region_list($theme, 'REGIONS_ALL');   // Validate allowed regions with available regions $regions = array_intersect(array_keys($available_regions), $allowed_regions);   // For each region foreach ($regions as $key => $region) {   // Load region blocks $blocks = entity_load_multiple_by_properties('block', array('theme' => $theme, 'region' => $region));   // Sort ‘em uasort($blocks, 'Drupal\block\Entity\Block::sort');   // Capture viewable blocks and their settings to $build $build = array(); foreach ($blocks as $key => $block) { if ($block->access('view')) { $build[$key] = entity_view($block, 'block'); } }   // Add build to region $variables[$region] = $build; } }

After clearing caches, I can now print content specified in Drupal’s block layout using my node template files. For example, if I’ve specified primary_content in $allowed_regions, then I can access it via node--node_type.html.twig with:

{{ primary_content }}

Categories: Drupal

Drupal core announcements: Fabianx and stefan.r are now Drupal 7 co-maintainers

Planet Drupal - 23 June 2016 - 8:13am

Earlier this year, I announced that I was seeking additional Drupal 7 co-maintainers in order to help bolster the efforts of the indefatigable David Rothstein. Thank you very much to everyone who responded to the call; there were certainly some very eager and qualified applications!

I have selected Fabian Franz (Fabianx) and Stefan Ruijsenaars (stefan.r), which are also two of the names put forward by David himself. I recently asked them to apply to become Drupal 7 co-maintainers, and I am pleased to announce they both gave an enthusiastic yes!

Fabian will be a Drupal 7 Framework Manager, and Stefan will be a Drupal 7 Release Manager and Drupal 7 Product Manager. David will continue his role as a Framework Manager, Release Manager and Product Manager for Drupal 7.

Fabian is from Germany, and is a Senior Performance Engineer and Technical Lead at Tag1 Consulting. He is always up to a challenge, and has been a part of the Drupal community for over 6 years. He was already a subsystem maintainer for the Drupal core theme system, and he has done innovative work in terms of Scalability and High Performance for Drupal (BigPipe!). He is in general passionate about everything Open Source since GNU was born, which as it happens, is the same day as his birthday.

Stefan hails from the Netherlands, and is a freelancer currently working with Belgian government clients. He has been part of the Drupal community since his first Drupalcon in Szeged in 2008, and recently became a member of the Drupal Security Team.

Both Fabian and Stefan have ample experience contributing both to numerous contributed modules, and to Drupal core, being especially instrumental to squashing the last critical bugs prior to the Drupal 8 release.

Please join me in welcoming Fabian and Stefan to the Drupal 7 core committer team! (And if you happen to be at Drupal Developer Days Milan, you can high-five Stefan in person! :-))

Categories: Drupal

Deeson: 24 things about Drupal 8 every CTO should know

Planet Drupal - 23 June 2016 - 6:16am

Last updated 2nd December 2015

John Ennew, Drupal 8 contributor and Deeson technical lead has collected together the questions we’ve been receiving from clients about Drupal 8 into one handy list.

John is a speaker at DrupalCon and maintains Drupal modules used on thousands of websites throughout the world. He holds a Masters in Computer Systems Engineering and is an IET Chartered Engineer, in addition to winning ‘Techie of the Year’ 2015.

Do you have a question that we haven’t answered? Drop us an email at hello@deeson.co.uk or ask in the comments.

Contents

Planning for Drupal 8

 1. Why did Drupal 8 take so long?  2. When should I start building on Drupal 8?  3. How long until common contributed modules are going to be available?  4. How much do Drupal 7 developers have to learn?  5. Will Drupal 8 make Drupal builds cheaper?  6. Will Drupal 8 sites be quicker to build?

Implications for Drupal 7

 7. Is there an upgrade path from previous Drupal versions?  8. How long will Drupal 7 support last now Drupal 8 is out?

New functionality in Drupal 8

 9. Does Drupal Commerce feature in the Drupal 8 release?  10. Are multi-lingual sites handled differently in Drupal 8?  11. How is the content editor experience different in Drupal 8?  12. Does Drupal 8 handle complex user and content permissions any differently?

The front-end and Drupal 8

 13. Does Drupal 8 change the approach to theming and front-end standards?  14. How is accessibility handled in Drupal 8?

Drupal 8 in the enterprise

 15. Does Drupal 8 make enterprise development practices such as automated testing easier?  16. Is it easier to manage a large portfolio of sites with Drupal 8?  17. Has configuration management improved in Drupal 8?

Architecture changes

 18. What does Drupal 8 mean for ‘headless Drupal’?  19. Does Drupal 8 change how Drupal integrates with other systems?  20. Is the database abstraction layer any different?  21. I’ve heard Symfony is used heavily in Drupal 8 core, what are the implications?

Performance and security

 22. Are there performance improvements in Drupal 8?  23. Has High Availability (HA) improved in Drupal 8?  24. Does Drupal 8 have any major differences in its approach to security?

 

Planning for Drupal 8 1. Why did Drupal 8 take so long?

Drupal has been around for 15 years and Drupal 8 has been in development for 5 years. This sounds like a long time to produce a release.

Under the hood, Drupal 8 has lots of big changes from Drupal 7. Many new programming concepts and paradigms have been adopted which will make Drupal more standards-compliant. This has meant removing old, more Drupal specific ways of doing things and embracing more widely known standards and technologies.

The discussion plan in Drupal community is that in future there will be gradual, phased releases allowing feature development to proceed in separate branches, rather than waiting for other functionality to produce a single large release like Drupal 8.

2. When should I start building on Drupal 8?

Drupal 8 should be considered for all projects from now onwards. The decision on whether it’s the right time for a specific project will depend on the appetite for risk, the nature of the functionality and complexity of the project.

There are many contributed modules that don’t have a stable release yet. This means a project may end up building a Drupal 8 version of a particular tool which would be available ‘for free’ in Drupal 7.

However, this is likely to be outweighed by the long term advantages of choosing Drupal 8. We’d recommend that a project scheduled to launch in 6 to 12 months time should select Drupal 8 over Drupal 7.

The fundamental overhaul of the multilingual system in Drupal 8 means that multilingual sites should always choose Drupal 8.

A project with a close, hard release date may not want to take on the risk of an unexpected bug in Drupal 8 impacting development or causing post-launch issues. These issues are always more likely in a new product before it’s had widespread production use.

3. How long until common contributed modules are going to be available?

Deeson maintains a list of 52 modules which are used in a large number of our projects. 11 are now included in Drupal 8 Core so will be fully supported, 9 have community contributed releases in an alpha or beta stage of development and the rest, 32 modules, have no testable release as yet.

For simple brochure sites with limited functionality, Drupal 8 is ready now as some of the most important content management tools are now included in the core platform.

However, there are some significant omissions, e.g. Pathauto and Tokens which are used to automatically generate tags in emails or automatic URL aliases based on the title of content.

Our experience of Drupal 7 was that contributed modules started being usable one year after the initial Drupal 7 release. We expect the turnaround to be quicker this time because Drupal 8 core incorporates many of these modules and that key contributed modules will be stable by May 2016.

4. How much do Drupal 7 developers have to learn?

Some major changes to Drupal 8 are the introduction of the Twig templating system for the theme layer, the introduction of components of the Symfony framework into core, the plugin system and a general principle to move to an object-orientated style of programming from the previous, procedural style. Drupal 7 developers, therefore, have quite a bit of learning to do.

It is expected that over the next year interest in Drupal 8 will grow and more developers will begin learning the skills needed to work on a Drupal 8 project. The Drupal community has done an excellent job of providing support material on the Drupal.org website with better documentation than previous versions of Drupal had.

Development teams will need to start ramping up their training now to support the projects they will be taking on in the next 6 months or risk being left unprepared.

5. Will Drupal 8 make Drupal builds cheaper?

As with previous versions, Drupal 8 will have no license fee so is free to reuse.

The cost of projects built using Drupal 8 is unlikely to be significantly different compared with projects built with previous versions of Drupal.

However, we believe that there will be long term reductions in the total cost of ownership because of the improvements made under the hood in Drupal 8. Development best practices have been introduced including a new plugin system making it easier to extend and enhance Drupal 8 compared with previous versions.

6. Will Drupal 8 sites be quicker to build?

There has been significant improvements in what is known as DX, or developer experience. These should improve the abilities of the development team to develop sites and diagnose issues.

Examples include moving to Object-Oriented OO coding principles which organises code more logically and in a manner the developer tools understand. This means that code can autocomplete in their editing tools. Another example is the Twig templating layer which better organises the theme system in Drupal, meaning that it is harder for developers to create untidy code.

Of course, many development teams have been applying these practices on top of Drupal 7 already so are already getting the benefits of these tools and practices which are now in Drupal 8 core.

Implications for Drupal 7 7. Is there an upgrade path from previous Drupal versions?

The Migrate module is included in Drupal 8. Migrate provides a series of tools a developer can use to map content in a Drupal 6 or 7 website to its location within a Drupal 8 website.  Although not a simple process, it does mean the migration path from previous versions of Drupal is available.

8. How long will Drupal 7 support last now Drupal 8 is out?

The Drupal community is committed to supporting the previous version of Drupal. This means Drupal 7 will be supported until Drupal 9 is released. There is currently no official release date for Drupal 9 and so no end of life date for Drupal 7.

I expect support for Drupal 7 for many years, particularly considering the huge install base of Drupal 7 sites.

New functionality in Drupal 8 9. Does Drupal Commerce feature in the Drupal 8 release?

Drupal Commerce is not maintained by the Drupal core team but maintained by a company - Commerce Guys. They have a Drupal 8 version of the module in active development.

The new Drupal 8 version is described as offering significant improvements over the old versions of Drupal Commerce, including better add to cart facilities, faster product creation and more intuitive product administration.

10. Are multilingual sites handled differently in Drupal 8?

Previous versions of Drupal had only partial support for multilingual websites. Multilingual projects usually involved stitching together a number of contributed modules to provide support for various elements of Drupal to be translated and each worked in a slightly different way. This inconsistency caused many projects budget and deadline pressures.

There has been a significant overhaul of multilingual capabilities in Drupal 8. Translations of all core elements are done in a sane and consistent manner in Drupal 8 core.

The installation system natively supports 94 languages. There are simple processes for installing new languages and language updates. The administration interface is entirely translatable. Assets, such as files or images, can now be assigned to a language or shared between languages.

11. How is the content editor experience different in Drupal 8?

Drupal 8 ships with the popular CKEditor WYSIWYG web editor. This means this tool is supported as standard and so will be maintained to continue to integrate well with it.

The new NavBar module in Drupal 8 core offers a clean administration tool for accessing all sections of the administration interface.

Drupal 8’s quick edit feature allows content editors the ability to do simple editing and changes in the page instead of loading a form specially for editing content.

On the horizon there are improvements to media handling in Drupal 8 as well which will give Drupal 8 a superior interface for managing assets such as files and images but this did not make it into core.

12. Does Drupal 8 handle complex user and content permissions any differently?

Under the hood the content access permission system has been rewritten in Drupal 8 but the behaviour for content administrators is much the same as before.  

It is expected that contributed modules will be providing the fine grained additional permission control they did in previous versions of Drupal. The popular choice in previous versions of Drupal for this was Organic Groups, which hadn’t been refactored to match more recent core versions. To provide stable functionality in Drupal 7 we have been using the Group module instead, we are planning to create a Drupal 8 release too.

The front-end and Drupal 8 13. Does Drupal 8 change theming and front-end standards approach?

In Drupal 7 PHP based templates made it too easy for developers to place logic in their templates which should have been managed in modules. Over time, templating code which was not strongly controlled would become fragile and it would be hard to find bugs and add new functionality.

Theming has changed significantly with the introduction of the Twig templating system in Drupal 8. Developers will now be able to write almost all markup in Twig templates rather than PHP code in functions. Though there will be an initial investment in learning required by development teams, the long term results will be cleaner templates which are more maintainable.

14. How is accessibility handled in Drupal 8?

There have been some improvements made to accessibility in Drupal 8.

WAI-ARIA landmarks, live regions, roles & properties are included which improves the accessibility of dynamic areas of the page. Drupal’s Form API now puts errors in-line rather than having the errors displayed in different regions to the form element which had the input error.

There is a JavaScript alert for audible announcements allowing site builders to include timely messages specifically for aural users. A new Tabbing Manager ensures a logical ordering to accessing page elements for users not using a mouse.

A general approach in Drupal 8 is to use standardised libraries to deliver functionality rather than trying to develop well known and well developed functionality from scratch. By working with library developers, best-of-breed technologies can be developed in partnership with a larger community.

One of the effects of this is that accessibility for a particular function can be developed by teams of people who really understand that field. A good example here is using the jQuery UI library to provide autocomplete functionality in Drupal 8. The Drupal community can now help the jQuery UI community in producing a better, more accessible tool.

Drupal 8 in the enterprise 15. Does Drupal 8 make enterprise development practices such as automated testing easier?

Several improvements in Drupal 8 make it a more effective platform for practising continuous development. The configuration management system means configuration now lives in code in a standard way meaning code can be safely transferred between environments and its behaviour is now predictable.

Drupal 8 code makes more use of objects and PHPUnit is supported by the testing infrastructure within the core codebase, meaning all code can now be written with unit tests.

Drush, the Drupal CLI tool, has been updated to work with Drupal 8 already, and can be used to automate most deployment activities from testing the quality of the custom code using the coder module, to testing the functionality using PHPUnit.

Automated testing has also been improved with Drupal 8. The core product now includes PHPUnit which is a test runner which allows both Unit and Functional tests.  These are better tests which run much quickly than previous versions.

PHPUnit is a well recognised tool in the wider PHP developer community, hopefully meaning that finding people to write tests and finding resources to help developers get to grips with testing will be easier with Drupal 8.

Drupal 8 is also supported by the popular Behat testing framework for Symfony allowing well formed behaviour driven development practices (BDD).

16. Is it easier to manage a large portfolio of sites with Drupal 8?

Drupal 8 is a good choice for organisations maintaing large portfolios of sites. Drupal is the most flexible and extensible CMS and so can be used to develop both small, simple websites but also larger, more complex ones. By choosing to consolidate on Drupal you can reduce the development effort required in maintaining a large estate.

Drupal 8’s RESTful APIs allows you to develop the sorts of enterprise tools needed to manage an estate of sites. Features like Drupal’s multi-site and the Group module mean that you can also take a single Drupal codebase and use it to deliver multiple websites. There will always be complexities with such approaches but Drupal is flexible enough to alter it to your specific requirements.

17. Has configuration management improved in Drupal 8?

Configuration management is the ability to define the configuration of a software application like a Drupal website in a testable, versionable way. In Drupal 7 it was often the case that configuration had to be done in each environment after a release rather than defining the behaviour of the website in each environment within the code of the website.

Drupal 7 had some addons that made this possible such as the Features module, but these were never done in an entirely satisfactory manner and each module had to define its exportable behaviour to Features.  

In addition, the variable table in Drupal 7 became a dumping ground of both configuration and state for each environment which meant that determining what needed to be exported into configuration in code and what could be safely ignored on a per-environment basis was complicated, time consuming and could lead to errors during deployment.

The Configuration Management Initiative in Drupal 8 has brought a standardised way for modules to define their editable configuration. Site builders can then export the configuration for an environment into configuration files which can be put into the website’s version control system and changed on a per-environment basis. This allows configuration to be audited, rolled back and be testable.

Architecture changes 18. What does Drupal 8 mean for ‘headless Drupal’?

Headless Drupal or Decoupled Drupal are terms used to describe the system’s architectural practice of separating the back-end and theming components of Drupal. In such an architecture, Drupal is used as a Content Management System for data entry and retrieval, but the rendering of web pages of content to end users (the theming layer) is passed over to another tool.

This allows development teams to build rich internet applications, mobile applications or apps for devices such as smart TVs, watches or the next Google Glass. Each of these devices have their own theming mechanisms and all of them just want pure data from the Content Management System.

Drupal 8 is capable of outputting data not just as HTML but in many forms such as JSON or XML. How it delivers data depends on the device or application which is requesting the data.

Choosing Drupal 8 as the Content Management system is a good investment for the future. Initially it may just be a website delivering to traditional web browsers, but later other apps or dynamic internet applications may be built which use the same Drupal back-end for retrieving their data.

19. Does Drupal 8 change how Drupal integrates with other systems?

Drupal 8’s inclusion of standard PHP libraries means that for any particular application it is likely that a good external library already exists. There is less of a reliance on a single developer working inside of the Drupal ecosystem to meet your integration needs.

Drupal 8 also provides mechanisms for exporting its data via a RESTful API allowing it to easily integrate with other systems.

In addition, the new plugin system within Drupal means that extensions to Drupal can easily be developed. This technology maintains Drupal’s position as the most extensible and flexible CMS framework available.

20. Is the database abstraction layer any different?

The process of standardising on the Drupal Entity model began in Drupal 7 and has been extended in Drupal 8. Developers working on developing websites with Drupal 8 will work at the Entity level rather than the database level. This allows Drupal 8 websites to work agnostically with a larger number of database technologies, not just the traditional relational ones such as MySQL. For example, it is possible to use NoSQL solutions such as MongoDB as the database storage layer with a Drupal 8 website.

In Drupal 8, the database API is pretty much the same as Drupal 7, but developers should almost never be making database calls directly unless they are developing core APIs.

21. I’ve heard Symfony is used heavily in Drupal 8 core, what are the implications?

In previous versions of Drupal all the code within Drupal was built by members of the Drupal community. In Drupal 8, the developers have embraced other projects like Symfony, and are building libraries which can be reused in other projects. Rather than re-inventing the wheel, Drupal 8 includes components developed by a larger community to solve a problem.

This means that Drupal benefits from a more stable codebase used in more projects. In return, projects like Symfony also get the benefit of more people making use of their code and so becomes more robust in the process.

Developers familiar with Symfony and not Drupal will now be able to move into Drupal development. This opens up the pool of talent development teams can draw on.

Symfony is written using industry standards and best practices, such as PSR-4 name spacing of classes, these have been incorporated in Drupal 8.

Performance and security 22. Are there performance improvements in Drupal 8?

The caching system was completely re-written in Drupal 8. In Drupal 7, often when a cache needed to be cleared the only option was to clear all caches meaning that a small change could cause a greater strain on the website as all the caches had to refill.  

Caching usually occurred at the page level as well in Drupal 7, which meant that either the whole page was returned from cache or the whole page needed to be regenerated. For logged in users, generally no caching happened and the whole page was generated for every page request.

In Drupal 8 the caches are much more complex and caching can be defined and cleared with greater precision. The new Cache Tags system allows, for example, pieces of a page to be cached so that logged in users might receive most of a page from cache and just the link to their account is generated.

Cache Tags also allows the developers to define specific cache-clear scenarios for their sites based on the known behaviour of the site - for example, it is possible to clear all caches which contain information about user 300 following an update to their account without clearing every other user’s cached data.

In addition, the cache system, like much of Drupal 8, is pluggable which means that better caching tools can be plugged in at all levels. For large, complex site, much more precise selections of tools can be used to improve performance.

The way the page build pipeline works has been overhauled in Drupal 8 meaning that a web page is built in a much more efficient manner to previous versions of Drupal. There is also a general ‘fast by default’ principal used by the Drupal 8 developers which makes sure that nothing needs to be enabled to provide performance boosts for Drupal 8.

23. Has High Availability (HA) improved in Drupal 8?

Drupal has been used in HA environments for many years now and is a well understood problem. Drupal 8 is similar to Drupal 7 in this respect. The improvements to the caching layer means that more complex strategies are now possible with Drupal 8 and additional thought may optionally be put into the configuration of caching tools.

24. Does Drupal 8 have any major differences in its approach to security?

The Twig templating system is a major change from the old way of allowing PHP code within the template code. Twig is full of features for ensuring a secure theming layer, which has historically been a common source of security vulnerabilities.

Another common vulnerability was introduced by site builders manually configuring text filters for a variety of third party WYSIWYG editors. Such an editor is a must for a content management system but installing them wasn’t supported natively by Drupal core and was one of the more complex tasks of a site builder. In Drupal 8, the CKEditor editor is included as standard with sensibly configured defaults which will work for most cases and be secure.

The PHP module has been removed from core which allowed site builders to write PHP code in the browser. This led to bad practices and also allowed a way for a malicious user who gained higher privileges in the website due to poor configuration to execute code on the server.

All input variables from the URL are properly declared by the new routing system. This means bad or unexpected data types get filtered by default. The previous CSRF protection provided by Drupal 7’s core APIs are also still available in Drupal 8.

A team of volunteers called the Drupal security team have managed looking for security issues in Drupal core and managing the security issue queue and advisory notices.

With so much third party code now required for Drupal 8 to work, managing security advisories to external libraries is more important. Modules making use of external libraries can alert to security problems with their dependencies via the hook_requirements event.

In Drupal core, external code actually forms part of the Drupal 8 codebase. When security problems are found in that code, the security team must then work with the third party developers to fix the problems and ensure security advisories affecting both code bases are released together.

Drupal 8 doesn’t provide an automated way of applying updates out of the box. However it’s possible for companies using Drupal websites to do this via a continuous integration process using the drush command line tool, version control and automated tests.

Categories: Drupal

Arpit Jalan: GSOC 2016- Providing Web Tests for the Safe Search feature for the Google Vision module- Week 4

Planet Drupal - 23 June 2016 - 5:34am
TL;DR In my last post Avoid Explicit Contents in the images using Google Vision module, I had discussed about the services which “Safe Search” feature of the Vision API provides us, and how we have put this into use in the Google Vision module as a constraint to all the image fields which would be validated when the option is enabled. This week I have worked on developing simple web tests for testing this feature whether it gives us the results as expected.

Last week I had worked on developing the code to use the Safe Search detection feature as a constraint to the image fields which would validate the images for the presence of explicit contents, provided that the user enables the configuration for the concerned image field.

Besides the code, testing the functionality using simple web tests are equally essential to ensure that the feature executes perfectly when necessary steps are implemented.Hence, this week I have worked on developing simple web tests, which ensures that we have a fully functional feature.

I have tested both the conditions with safe search enabled and disabled to verify the results which should be obtained. When the safe search is enabled, any image containing any sort of  explicit content, is detected, and asked for moderation. If the image is not moderated, then the image is not saved. When the same image was passed through the second test, with safe search disabled, it was stored successfully, thus providing us the expected results.

To conduct the test successfully, I had to create a demo content type in my tests using drupalCreateContentType(), which would have an image field with the ‘Enable Safe Search’ option. This was something new to me to how to add an extra field to the default content type settings. The Drupal documentation on FieldConfig and FieldStorageConfig were of great help to understand the underlying concepts and functions which the field offers, and thus helping me to create custom fields programmatically. However, in order to perform the test, I had to call the API directly, which required a valid API key and an image which actually contains explicit content. Hence, my mentors asked me to override the functions of the class (mocking the services) in such a way that it removes the dependency from both the key and the image. Thus, I created a test module inside the Google Vision module, and override the function.

Summarizing the above, I can say that in addition to learning how to test the constraints and validators, I also came to learn about some really cool techniques, including the creation of custom fields in tests and mocking the services.
The lingotek_test of the Lingotek Translation module is a good reference to learn about how to override the services in web tests. Other references which are useful for mocking are ServiceProviderBase and Mocking for Unit Tests.
Categories: Drupal

Field Formatter Condition

New Drupal Modules - 23 June 2016 - 5:04am

Adds conditional functionality to fields.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal