Morpht: Drupal 8 Configuration - Part 4: Extending the API with contributed modules

Planet Drupal - Wed, 2019/05/15 - 3:24am
Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, and Part 2 describes how the API works, and Part 3 explains how to use functionality provided by core, so they are worth a read before beginning this article. 

Read-only configuration

In some situations, site builders may want to prevent any configuration changes from being made on the production environment, preventing changes that may cause unexpected issues. For example, clients with admin access could log into the production server, and make what they think is an innocent configuration change, that results in unexpected and drastic consequences. Some site builders consider it to be a best practice to prevent configuration changes on the production server altogether, under the idea that only content should be editable on the production server, and configuration changes should only be made in development and/or staging environments before being tested and pushed to production.

The Config Readonly module, allows for configuration changes through the UI to be disabled on a given environment. It does this by disabling the submit buttons on configuration pages. The module also disables configuration changes using Drush and Drupal console.

A configuration form that has been disabled with the Configuration Readonly module

Note: some configuration forms may still be enabled when using this  module. Module developers must build their forms by extending ConfigFormBase for the Configuration Readonly module to do its magic. If the developer has built the form using other means, the form will not be disabled, and the configuration for that form can be changed through the admin UI.

To set up an environment as read-only, add the following line to settings.php, then enable the module:

$settings['config_readonly'] = TRUE;

After an environment is set as read-only, changes to configuration can only be made on other environments, then migrated and imported into the active configuration on the read-only environment.

Complete split (blacklist) configuration

Sometimes configuration needs to exist on some environments, but not exist in other environments. For example, development modules, like the Devel module, or UI modules like Views UI (Drupal core) and Menu UI (Drupal core) should not be enabled on production environments, as they add overhead to the server while being unnecessary since the production server should not be used for development.

A problem arises when configuration is exported from one environment, and imported into the production environment. All the configuration from the source environment is now the active configuration on the production environment. So any development modules that were enabled on the source environment are now enabled on the production environment. In the case of development modules like Devel, this may only add some overhead to the server, but imagine a module like the Shield module, which sets up environments to require a username and password before even accessing the site. If this module is accidentally enabled upon import on production, it will block the site from public access - a disaster!

The solution to this situation is to blacklist configuration. Blacklisted configuration is blacklisted (removed) from configuration upon export. This functionality is provided by the Configuration Split module. This module allows for black-listing configuration either by module, by individual configuration key(s), and/or by wildcard.

Note that more detailed directions for creating blacklists can be found on the documentation page. The following is meant to give an overview of how black lists work.

Blacklists are created as part of a configuration profile. Configuration profiles allow for 'splitting' (a divergence in) configuration between environments. Profiles may be created for environment types such development, staging and production allowing for configuration specific to those types of environments. Or profiles could be set up for public non-production environments, that would have the Shield module enabled and configured. While a development profile may apply to all development environments, not all development environments are on publicly accessible URLs, and therefore may not need the Shield module enabled.

When setting up a configuration profile, note that the folder name must be the same as the machine_name of the profile.

Configuration split profile settings

Note that you must manually create the folder specified above, and that folder can and should be tracked using Git, so it can be use on any environment that enables the profile.

Configuration can then be set up to be blacklisted either by module, by configuration key, or by wildcard:

Complete split (blacklist) can be set by module, configuration key, or by wildcard

Finally, environments need to be set up to use a given profile. This is handled by adding the following line to settings.php on the environment:

$config['config_split.config_split.PROFILEMACHINENAME']['status'] = TRUE;

Where PROFILEMACHINENAME is the machine_name from the profile you created.

Although blacklisted configuration does not become part of the exported archive, it is not ignored altogether. When an environment has the profile enabled, upon export, blacklisted configuration is extracted, then written to the folder specified in the profile. The remaining configuration is written to the default configuration directory. When importing configuration, environments with the profile enabled will first retrieve the configuration from the default configuration directory, then apply any configuration from the folder specified in the profile. Environments not set up to use the profile ignore the configuration in the blacklisted directory altogether on both import and export.

This means that a developer can enable the Devel module on their local environment, blacklist it, then export their configuration. The blacklisted configuration never becomes part of the default configuration, and therefore the module will not accidentally be installed on environments with the configuration profile enabled.

Conditional split (grey list) configuration

Grey lists, also provided by the Configuration Split module, allow for configuration to differ by environment. With a blacklist (previous section), the configuration only exists in the active database configuration for environments that are set up to use the configuration profile containing the blacklisted configuration. With a grey list, the configuration exists in the active configuration in all environments, but the configuration profiles can be set up to allow environments to use differing values for the configuration.

Imagine an integration with a remote API requiring a username, password, and endpoint URL. The production server needs integrate with the remote API's production instance, while other environments will integrate with the remote API's sandbox instance. As such, the values to be used will differ by environment:

Production Environment:

remoteapi.username: ProductionUsername
remoteapi.password: ProductionPassword
remoteapi.endpoint: https://example.com/api

Other Environments:

remoteapi.username: SandboxUsername
remoteapi.password: SandboxPassword
remoteapi.endpoint: https://sandbox.example.com/api

A grey list allows for the setup of these values by configuration profile.

You may be remembering that Part 3 of this series of articles discussed overriding configuration in settings.php, and thinking that a grey list sounds like the same thing. After all, the default values for the sandbox instance of the API could be set up as the configuration values, and the production values could be overridden in settings.php on the production environment, with the same end-result.

The difference is that with a grey list, the remote API values are saved to the configuration profile folder, which is tracked by Git, and therefore can be tracked and migrated between environments. When grey listed configuration is exported, the grey listed configuration is written to the configuration profile folder, in the same manner as blacklisted configuration. When configuration is imported, the default values are retrieved, and the grey list values are used to override the default values, after which the configuration is imported into active configuration.

With the configuration override method using settings.php, site builders need to store the various configuration values somewhere outside the project, communicating environment-specific configuration values to each other through some means, to be manually entered on the relevant environment(s). With a grey list, the configuration values are managed with Git, meaning site builders do not need to record them outside the project, nor communicate them to each other through some other means. Site builders simply need to enable the relevant configuration profile in settings.php, and the environment-specific values can then be imported into active configuration from the configuration profile directory. This means that the sandbox API values can be set up as the values used by default on all environments, and a production configuration profile can be enabled on the production environment using the values to connect to the production instance of the remote API.

Conditional split items can be selected either from a list, or by manually entering them into the configuration profile:

Conditional split (grey list) settings can be selected or manually entered

Finally, note that grey lists can actually be used in conjunction with configuration overrides in settings.php. Grey lists are applied during import and export of configuration from the database. Values in settings.php are used at runtime, overriding any active configuration. So a developer could choose to set up their local instance of the system to connect to an entirely different instance of the remote API altogether by overriding the values in settings.php.

Ignoring configuration (overwrite protection)

Sometimes developers will want to protect certain configuration items in the database from ever being overwritten. For example imagine a site named Awesome Site, with a module that supplies the core of the site, named awesome_core. Since this module provides the core functionality of the site, it should never be disabled under any circumstances, as that would disable the core functionality of the site. In this case, the configuration for this module can be set to be 'ignored'. Any attempts to import ignored configuration from the file system to the active configuration in database will be skipped, and not imported.

Configuration can be ignored using the Config Ignore module. The functionality this module provides is similar to the functionality provided by the Config Readonly module discussed earlier, however the Config Readonly module covers the entire configuration of an environment, while the Config Ignore module allows for choosing configuration that should be protected. This configuration is protected by ignoring it altogether on import.

Configuration can be ignored as follows:

  1. Enable Config Ignore module on all environments.
  2. Navigate to the config ignore UI page, and set the configuration item to be ignored. In the case of preventing the awesome_core module from being disabled, the following would be added:
    core.extension:module.awesome_core
    Configuration to be ignore is entered one item per line. Wildcards can be used.

This setting will ensure that any attempts to change or remove core.extension:module.awesome_core upon configuration import will be ignored. So if the module is enabled on production, and a developer pushes configuration changes that would uninstall this module, those changes will be ignored, and the module will still be set as enabled after import.

Summary

In this article, we looked at various modules that extend the Configuration API, use cases behind these modules, and how the modules worked. We looked at the Config Readonly module, the Configuration Split module, and the Config Ignore module, and how to use these modules to manage configuration differences between environments. In the next, final part of this series, we will look at configuration management for module developers, and how developers can define the schema for the configuration their module provides.

Categories:

PreviousNext: Why we no longer use Display Suite on new Drupal 8 projects

Planet Drupal - Wed, 2019/05/15 - 3:14am

Display Suite is a handy module we've used for a long time. However for new projects utilising Layout Builder we've found we don't need it. Swap out Display Suite for Drupal 8 core blocks with contexts!

by Saul Willers / 15 May 2019 Positioning fields

The main use case for Display Suite (DS) is to position fields into layouts. However, Layout Builder now offers a Drupal 8 core alternative to building layouts.

As DS utilises core's Layout Discovery module switching these layouts over to Layout Builder should be fairly straight forward. Having said that, so far we've only implemented this on new greenfield sites starting from scratch with Layout Builder.

Custom fields

One of DS's most useful features is defining custom fields as @DsField plugins.

Say we have a custom Event entity which needs custom output to format a map of that event.

DsField version

<?php

namespace Drupal\my_event\Plugin\DsField;

use Drupal\ds\Plugin\DsField\DsFieldBase;

/**
 * Plugin to render a map of an event.
 *
 * @DsField(
 *   id = "my_event_map",
 *   ...
 *   entity_type = "my_event"
 * )
 */
class EventMap extends DsFieldBase {

  /**
   * {@inheritdoc}
   */
  public function build() {
    /** @var \Drupal\my_event\Entity\Event $event */
    $event = $this->entity();
    
    // Logic here to build and format your map utilising $event.
  }

}

Block equivalent

This DsField converts directly to a Block plugin utilising context to get the entity.

<?php

namespace Drupal\my_event\Plugin\Block;

use Drupal\Core\Block\BlockBase;

/**
 * Block implementation to render a map of an event.
 *
 * @Block(
 *   id = "my_event_map",
 *   ...
 *   context = {
 *     "my_event" = @ContextDefinition("entity:my_event", required = TRUE),
 *   }
 * )
 */
class EventMap extends BlockBase {

  /**
   * {@inheritdoc}
   */
  public function build() {
    /** @var \Drupal\my_event\Entity\Event $event */
    $event = $this->getContextValue('my_event');
    
    // Logic here to build and format your map utilising $event.
  }

}

This block is then available for placement as per the usual Layout Builder techniques.

Controlling field markup

Another use for DS is to control the markup of and around fields.

As an alternative to DS we often use Element Class Formatter module to easily inject custom classes into fields. In combination with Twig templates utilising embeds and includes this should mostly do away with the need for DS.

Summing up

DS is a great module, full kudos to swentel, aspilicious and everyone else who's worked to make DS such a powerful UI based tool. However we don't really see a place for it looking to a world powered by Layout Builder.

Here's looking forward to a Drupal where all layout happens via Layout Builder!

Tagged Drupal Development, Drupal 8, Layouts, Display Suite
Categories:

Duo Consulting: Acquia Acquires Open Source Marketing Platform Mautic

Planet Drupal - Tue, 2019/05/14 - 4:43pm

When every business has a website, how do you stand out? Because customers expect so much more from digital brands, utilizing a marketing platform is essential. Marketing automation software enables businesses to deliver personalized engagement, strengthening customer bonds and driving new business.

Until recently, businesses have, by-and-large, had to rely on proprietary solutions like Marketo and Salesforce Marketing Cloud to handle their needs. Now, Acquia is looking to disrupt the marketplace. The Drupal SaaS giant has just acquired Mautic, an open-source marketing automation and campaign management platform. Now, Drupal users will have an open alternative to manage their customer experience needs.

This is the latest step Acquia has taken toward their vision for an Open Digital Experience Platform. The company has been working in the content management space for years and is now turning toward a data-driven, experience management approach. With their “API-first” philosophy, Acquia hopes to offer Drupal users maximum flexibility and the ability to meet any organizational needs that may arise. This level of freedom gives marketers the chance to customize every step of the customer cycle across channels.

While still a relatively young company, Mautic is a perfect fit for Acquia’s portfolio. While Acquia specializes in content management, personalization and commerce, Mautic will complement their offerings with their specialties in multichannel delivery, campaign management and journey orchestration. And with both Drupal and Mautic built on Symfony and PHP, collaboration and integration will be made easier. With 200,000 installations already, Mautic has already won over many marketers and, with Acquia’s expanded reach, will likely reach many more. Because of Mautic’s API-friendly build, our team at Duo can easily integrate the platform with a site.

On a more philosophical level, Mautic echoes Acquia’s (and the Drupal community’s) open-source ethos. Currently, Mautic is the only open source alternative to the aforementioned legacy marketing cloud ecosystems. This openness makes it easier for the development community to create marketing platforms built for a company’s specific needs. This ease of use extends to the marketing side, too. Where many proprietary marketing automation software have steep learning curves and are bundled with countless other products in their respective clouds, Mautic’s platform benefits from its ease-of-use and its modern, streamlined design - allowing anyone on a team to get their organization’s message out faster than ever. To take a look at the platform in action, watch the demo embedded below.

In addition to Mautic’s open offerings, the company also offers several commercial solutions. The first, Mautic Cloud is a fully managed SaaS version of the platform that includes some premium features not openly available. For enterprise clients, Mautic has Maestro. This product allows multinational organizations the ability to segment their marketing efforts by territory, while still allowing for sharing between regions. Campaigns can also be copied and repeated in different territories. These features will remain separate from Acquia Lift, though Duo can handle integrations with either service if needed.

So what does all of this mean for businesses using Drupal? This being an open-source community, it means more freedom! Rather than being locked into whatever is offered by legacy martech vendors, Drupal allows you to leverage best-of-breed services and solutions. At Duo, we’re always striving for more openness. Your solution should match your exact needs and the Drupal environment provides a vast range of solutions to make it your new site a reality. Now, Mautic joins those ranks, and can be used in conjunction with whatever other modules you opt to use. The open source ecosystem that makes Drupal so robust also gives Mautic more flexibility than other marketing automation platforms, and for a cheaper price tag, as well. Finally,

By 2023, spending on global marketing automation is expected to reach $25 billion. This software isn’t going anywhere, so why would you pay for a stale and outdated marketing suite that you may not be able to use to its full potential? With the acquisition of Mautic, Acquia has given marketers a whole new option when it comes to managing customer engagement. Duo can help you navigate the various marketing paths available while ensuring that whatever choice you make will exceed your expectations.

Categories:

OpenSense Labs: Drupal 8.7 Unleashes New Layout Builder

Planet Drupal - Tue, 2019/05/14 - 2:23pm
Drupal 8.7 Unleashes New Layout Builder Jayati Tue, 05/14/2019 - 17:53

Long awaited and much needed in the pipeline, the Layout Builder was finally launched in May 2019. With an ambition to create a content tool that can provide more power and flexibility than comparable systems, the Drupal community had been working on a super progressive visual tool for more than a year. Earlier, the digital marketers had restricted templates to work with and were not satisfied with clunky design experiences. However, in the recent launch of Drupal 8.7.0, Dries Buytaert stated that the new layout builder will be able to manipulate different types of content and unleash unique and trend setting features. The feature of layouts for templated and customised content is crucial for websites with large amounts of content. 

For websites with heavy content, the Layout Builder has enhanced Drupal’s ability to handle “structured content” now. 


Originally introduced as an experimental module in Drupal 8.5, the primary focus of the layout builder was to develop a drag and drop WYSIWYG tool. Relying on a third-party software was getting painstaking for many and Drupal became one of the first CMS to take this risk. This layout builder offers full compatibility with revisions, workflows, and in-context previews. It is a single, powerful and visual design tool that creates layout templates that can speed up the development process for the site builders. The accessible, mobile-friendly page building tool allows content authors to easily customise individual pages with unique layouts too.

With 123 individuals and 68 organisations contributing, the Drupal 8.7 comes with this promising layout builder. Advantages of Layout Builder

The shifting focus in the website development has lead to Layout Builder emerging as the most exciting CMS visual design tool. Let’s explore its reasons: 

  • You can create layout templates for a specific content type, such as blog posts, products pages, landing pages, etc. 
  • Layout builder empowers to customise the template layouts and override them on a case-by-case basis. 
  • It enables you to create custom landing pages that are not tied to a content type or structured content. 
  • The tool passes Drupal’s accessibility gate(Level AA conformance with WCAG and ATAG) with a stable state for production. 
  • The updated version in Drupal 8.7 allows streamlining mass-production while supporting unique creation.
  • The drag-and-drop management of your content blocks is now possible with the new layout builder 
  • Additionally, it supports keyboard controls and toggling the content preview on and off to give the content editor complete control of their experience while building their layouts.

With 123 individuals and 68 organisations contributing, the Drupal 8.7 comes with this promising layout builder. Moreover, 40 above individual contributors volunteered for the success of this release. 

Improved Layout Builder in Drupal 8.7 Translation Support

As the layout builder has improved features for translation, there are two approaches that can be taken here:

  • Synchronised approach translation: For multilingual sites that have the same layout, all the content and fields are automated. In other words, any text entered with layout builder is translated automatically for you. 
  • Independent approach translation: On the other hand, if you want different layouts for two different languages or take a localisation approach to the site, you can have independent and individual translations for them too.
Usability 

From Drupal 8.6 to Drupal 8.7, the usability has drastically improved:

  • You can now narrow down the list of block available and add several tweaks to it. 
  • Contextual links are used to add shortcuts. The Drupal community is re-evaluating the usage as it is essential from the UI point of view. 
  • Except for minor alterations, the layout builder now gives real-time updates based on changes made in sidebar.
Accessibility 

The usability is always inter-connected with accessibility. If it isn’t accessible, it is not usable for obvious reasons. The revamped version has features like:  

  • Improved usage of Drupal announce and ARIA attributes.
  • Now you can easily access the keyboard to action commands like save, discard, or revert from anywhere on the page. 
  • The tabledrag can get confusing for many. You can create a tabledrag-based UI to make all changes at once in the layout builder with Drupal 8.7. 
New Media Library

A new, stylish and with a handy user interface, Drupal 8.7 introduces us with numerous improvements in the Media Library:

  • The highlighted design and accessibility of the user interface makes way for inline media creation in the library itself. 
  • The process of searching the media items in the library, from bulk uploading them to the selection of media items and embedding them into the content is also a smooth run with the new version.
  • The Media module also allows reuse of images, documents, efficiently managed drag-and-drop function and provides a more flexible grid and table views. 
  • The media module in sync and stable with this media library and will further improve with the upcoming Drupal 8.8 release.
Revisions in Custom menu links & Taxonomy

The following revisions in the 8.7.0 release aim to enhance the overall performance of the Layout Builder:

  • It allows the Custom menu links and taxonomy terms to fully participate in the editorial workflows. 
  • They have been revised for improved integration and core support for the Workspaces module with a new Update API for help in conversion of further entity types. 
  • The schema of any content entity type can now be converted between non-revisionable or non-translatable and revisionable or translatable. 
Automatic Entity 

Among many additions, there has been few subtractions as well: 

  • The support for automatic entity updates was removed due to data integrity issues and its conflicts. 
  • The drush entity:updates (drush entup) command stands nullified and the entity changes will now be performed using standard update procedures.
Internet Explorer 9 and 10

The workaround that still existed in D8.5 and D8.6 also gets removed as the *.7.0 release says goodbye to Internet Explorer 9 and 10. The workaround used to allow the inclusion of 32+ stylesheets. 

Check out Buytaert’s demo video showing the Layout Builder in action with Drupal 8.7.0.  

On the way to Drupal 9

The major release of Drupal 9 planned for June 2020 will open new doors for the layout builder. It will update dependencies primarily on Symfony as the optional support for Symfony 4 is expected to complete by 8.8 version. Further, a better feedback on the compatibility can be obtained as we testing Drupal with updated third-party dependencies in this version. Drupal 8.7.0 also includes an optional support for Twig 2 (for sites that can patch their Composer configuration). 

Conclusion

New improvements in terms of keyboard navigation accessibility, precise permissions, layout overrides, and column width selection has given a stable outlook to the Layout Builder and it is ready to work on live sites. The process of constructing pages “brick by brick” with a combination of elements, configuration of blocks, and drag-and-dropping feature is an easy and enjoyable one. 

Check out the new Drupal 8.7.0 version and share your views with us in the comments! We’d also like to hear from you at hello@opensenselabs.com.

 

blog banner blog image Drupal 8 Layout Builder Drupal 9 Media Library Drupal accessibility Usability Blog Type Articles Is it a good read ? On
Categories:

mark.ie: A Very Simple PoC of Using Voice to Admin a Drupal Website

Planet Drupal - Tue, 2019/05/14 - 1:10pm
A Very Simple PoC of Using Voice to Admin a Drupal Website

I was playing around with the SpeechRecognition API last night and thought, "wouldn't it be cool if we could use voice to administer a website?". Then, I put together this tiny proof of concept module for use with Drupal.

markconroy Tue, 05/14/2019 - 12:10

Here's a short video of it in action.

Ok, that looks pretty cool. Show me the code.

  1. window.SpeechRecognition = window.SpeechRecognition || window.webkitSpeechRecognition;
  2.  
  3. const recognition = new SpeechRecognition();
  4. recognition.interimResults = true;
  5.  
  6. recognition.addEventListener('result', e => {
  7. transcript = Array.from(e.results).map(result => result[0]).map(result => result.transcript).join('');
  8. const statement = e.results[0][0].transcript;
  9. console.log(statement);
  10. if (statement === "voice admin new page") {
  11. window.location.href = "/node/add/page";
  12. } else if (statement === "voice admin new article") {
  13. window.location.href = "/node/add/article";
  14. } else if (statement === "voice admin log out") {
  15. window.location.href = "/user/logout";
  16. } else if (statement === "voice admin go home") {
  17. window.location.href = "/en";
  18. }
  19. });
  20.  
  21. // When we stop talking, start the process again, so it'll record when we start
  22. // talking again.
  23. recognition.addEventListener('end', recognition.start);
  24.  
  25. recognition.start();

WTF? That code is crap. You have hard-coded what you want the site do to. That's not going to work for all sites, only for your specific use case.

Yep, that's true at the moment. Like I say, it's just a proof-of-concept. We'd need to create a settings page for users to decide if they want it to be available or not. And we'd have to create a better parsing system that listens for "voice admin" and then starts recording. Then we'd need to make sure that it patches together the fragments of speech after this to construct the action that you want to perform. Following that, it would be really cool if on the settings page users could type in commands and responses that SpeechRecognition will listen for and then perform.

I think all this is very possible, and probably not too much work. It would be great to see more progress on this.

If you'd like to create a pull request, the code is available on GitHub.

Categories:

Electric Citizen: When to upgrade from Drupal 7

Planet Drupal - Mon, 2019/05/13 - 10:36pm

Drupal 7 was officially released in 2011, making it quite old in web years, though it still powers hundreds of thousands of websites worldwide.

Drupal 8 was released in 2015, but the path to upgrading has never been an easy one for Drupal websites (prior to 8). So our recommendation for most Drupal 7 site owners has been to wait– wait until you have the time, budget and other resources needed to do a full redesign and migration to Drupal 8.

But Drupal 7 isn’t going to last forever.

It’s official end of life has already been decided–November, 2021. A full ten years after its original release, Drupal 7 will no longer be officially supported. What this means is no more security patches or bug fixes.

It won’t just stop working, but without official support, Drupal 7 sites will become vulnerable to crashes, hacks and other vulnerabilities. There are private companies who will continue to support Drupal 7 sites after 2021 in exchange for a support contract. But officially, it will be unsupported and after 10 years of service, most sites could benefit greatly from a more modern CMS.

But when is the best time to upgrade? What will it take? What are potential problems, or gains? And why should you continue using Drupal in the future? Let’s break down these questions one by one.

Categories:

Phase2: Last Week’s DXP One-Two Punch

Planet Drupal - Mon, 2019/05/13 - 6:04pm

Digital experience platforms (DXPs) had a big moment this past week.

Categories:

clemens-tolboom opened an issue in groningenml/ktitanic

On github - Mon, 2019/05/13 - 4:52pm
clemens-tolboom opened an issue in groningenml/ktitanic May 13, 2019 How to install the requirements #2

pipenv pipenv install --requirements.txt anaconda conda install --yes --file requirements.txt This is not enough according to https://www.technolog…

clemens-tolboom commented on issue groningenml/ktitanic#1

On github - Mon, 2019/05/13 - 4:43pm
clemens-tolboom commented on issue groningenml/ktitanic#1 May 13, 2019 clemens-tolboom commented May 13, 2019

It's maybe better to split issues into separate ones so we can close each at will

clemens-tolboom commented on issue groningenml/ktitanic#1

On github - Mon, 2019/05/13 - 4:41pm
clemens-tolboom commented on issue groningenml/ktitanic#1 May 13, 2019 clemens-tolboom commented May 13, 2019

requirements.txt I've installed pipenv and you have probably installed anaconda. Both tools are environment tools to prepare before running code. I…

clemens-tolboom forked clemens-tolboom/drupal-admin-ui from jsdrupal/drupal-admin-ui

On github - Mon, 2019/05/13 - 1:41pm
clemens-tolboom forked clemens-tolboom/drupal-admin-ui from jsdrupal/drupal-admin-ui May 13, 2019 jsdrupal/drupal-admin-ui

This is an admin UI for Drupal, built with JavaScript & React. ⬅️✌️➡️

JavaScript 201 Updated May 11

Agiledrop.com Blog: Top Drupal blog posts from April 2019

Planet Drupal - Mon, 2019/05/13 - 12:39pm

Since last month a lot of Drupalists were busy preparing for and traveling to DrupalCon, we wanted to give everyone a chance to catch up with important news and goings-on in the Drupalverse. To this end, here’s a recap of our favorite Drupal-related posts from last month.

READ MORE
Categories:

Web Omelette: Using Drupal 8 filters to render the markup that you want in a clean way

Planet Drupal - Mon, 2019/05/13 - 9:00am

I’ve been working on a Drupal 7 to 8 migration of content and I encountered in the source body fields a bunch of tables which had a class that styled them in a certain way. One of the requirements was clearly to port the style but improve it using the Bootstrap tables styles and responsiveness. What to do, what to do.

In the source file I was encountering something like this:

<table class="some-class">...</table>

Which you can argue is not that bad, it only has one class on it and an external style does the job. But obviously it would be better if the stored data didn’t even have that class. So then in the migration I could just kill all the table classes from the body field and apply those stylings externally (all the tables inside the body field). This is a first good step. But what about Bootstrap?

I needed something like this instead to pick up Bootstrap styles:

<table class="table table-sm table-striped table-hover">...</table>

So to make the tables show up with Bootstrap styles I’d have to step on my earlier point of not storing the table classes in the body field storage. Even if I could somehow alter the CKEditor plugin to apply the classes from the widget. And not to mention that if I wanted responsive tables, I’d have to wrap the table element with a <div class="table-responsove">...</div>. So even more crap to store. No.

Then it dawned on me: why not just store the clean table elements and then, upon rendering, apply the Bootstrap classes, as well as wrap them into the necessary div? After replying Hold my beer to my self-challenging alter ego, I went and I did. So I came up with this little number (will explain after):

<?php namespace Drupal\my_module\Plugin\Filter; use Drupal\Component\Utility\Html; use Drupal\filter\FilterProcessResult; use Drupal\filter\Plugin\FilterBase; /** * Makes the tables in the content show up using Bootstrap styling. * * @Filter( * id = "table_style_filter", * title = @Translation("Table styles"), * description = @Translation("Adds the necessary markup to tables to render * them via Bootstrap styling."), * type = \Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE, * ) */ class TableStyleFilter extends FilterBase { /** * {@inheritdoc} */ public function process($text, $langcode) { $dom = Html::load($text); $elements = $dom->getElementsByTagName('table'); if ($elements->length === 0) { return new FilterProcessResult(Html::serialize($dom)); } /** @var \DOMElement $element */ foreach ($elements as $element) { $classes = explode(' ', $element->getAttribute('class')); $bootstrap_classes = [ 'table', 'table-sm', 'table-striped', 'table-hover' ]; foreach ($bootstrap_classes as $class) { $classes[] = $class; } $new_element = clone $element; $new_element->setAttribute('class', join(' ', array_unique($classes))); $wrapper = $dom->createElement('div'); $wrapper->setAttribute('class', 'table-responsive'); $wrapper->appendChild($new_element); $element->parentNode->replaceChild($wrapper, $element); } return new FilterProcessResult(Html::serialize($dom)); } }

So what do we have here? Well, it’s a Filter plugin that you can add to your text format and which processes the text before it’s rendered. And obviously gets cached after.

In the plugin annotation I used the type \Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE because this doesn’t seem to be skipped by core anywhere and its purpose is to generate HTML. Then I implement the process() method to achieve my goal. And I do this quite easily with the following steps:

  1. Find all the table DOM elements and return early if none are found
  2. Loop through all the table DOM elements, clone them and apply the classes to the clone
  3. Create a wrapper div DOM element with the Bootstrap responsive class and append the table element clone to it
  4. Replace the initial table DOM element with the new wrapper
  5. Profit

The return of the method needs to be a FilterProcessResult object that contains the HTML in the same format as the method receives it in. So I serialize the DOM object back into an HTML string and use that.

And that’s it. After clearing the cache you can add this to a text format and all the tables found in the content rendered using that format will be Bootstrap ready. And tables are just an example. Imagine all the possibilities you have to turn simple HTML tags into the markup required by your corner frontend framework. All the while keeping your data clean and not pissing off the developer that will have to migrate that content somewhere else or render it in some other place differently.

Categories:

Promet Source: Invent Your Own Development Methodology

Planet Drupal - Mon, 2019/05/13 - 8:14am
Having a process to follow when it comes to website planning and development is essential. The following considerations factor into successful development.  Choosing a Method Planning and Development Goals Choosing a Methodology Influencing Development Methodology   Choosing a Method  
Categories:

Morpht: Drupal 8 Configuration - Part 2: How the API works

Planet Drupal - Mon, 2019/05/13 - 1:04am
Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, so it's worth a read before beginning this article.

Active configuration is in the database

In Drupal 8, configuration used at runtime is stored in the database. The values in the database are known as active configuration. In Drupal 7, configuration was known as settings, and stored in the {variable} table. In Drupal 8, configuration is stored in the {config} table. The active configuration is used at runtime by Drupal when preparing responses.

Configuration is backed up to files

The Configuration API enables the ability to export the active database configuration into a series of YML files. These files can also be imported into the database. This means that a developer can create a new Field API field on their local development environment, export the configuration for the new field to files, push those files to to the production environment, then import the configuration into the production environment's active configuration in the database.

The configuration values in the database are the live/active values, used by Drupal when responding to requests. The YMLfiles that represent configuration are not required, and are not used at run-time. In fact, in a new system the configuration files don't even exist until/unless someone exports the active configuration from the database. The configuration files are a means to be able to back up and/or migrate configuration between environments. Configuration files are never used in runtime on a site.

Configuration architecture

Let's look at the Configuration API on a more technical level, using a real-world example. The Restrict IP module allows users to set a list of rules that whitelist or blacklist users based on their IP address. Upon visiting the module settings page, users are presented with a checkbox that allows them to enable/disable the module functionality.

From a data standpoint, checkboxes are booleans; they represent either a true or false value. When exporting the configuration of a site with the Restrict IP module enabled, the relevant configuration key will be saved with a value of either true or false to a .yml file. Modules are required to define the schema for any configuration the module creates. Developers can look at the configuration schema declarations to understand what file(s) will be created, and what values are accepted.

Modules declare the schema for their configuration in the [MODULE ROOT]/config/schema directory. In the case of the Restrict IP module, the schema file is restrict_ip/config/schema/restrict_ip.schema.yml. This file contains the following declaration:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'

Schema declarations tell the system what the configuration looks like. In this case, the base configuration object is restrict_ip.settings, from the first line. When this configuration is exported to file, the file name will be restrict_ip.settings.yml. In that file will be a declaration of either:

enable: true

Or:

enable: false

When the file restrict_ip.settings.yml is imported into the active configuration in another environment's database, the value for the enable key will be imported as defined in the file.

On top of this, enabled modules are listed in core.extension.yml, which is the configuration that tracks which modules are enabled in a given environment. When the Restrict IP module is enabled in one environment, and configuration files exported from that environment are imported into a different Drupal environment, the Restrict IP module will be enabled due to its existence in core.extension.yml, and the setting enable will have a value of either true or false, depending on what the value was exported from the original environment.

Note that if you were to try to import the configuration without having the Restrict IP module in the codebase, an error will be thrown and the configuration import will fail with an error about the Restrict IP module not existing.

Summary

In this article, we looked at how the Drupal 8 Configuration API works on a technical level. We looked at how active configuration lives in the database, and can be exported to files which can then be imported back into the database, or migrated and imported to other Drupal environments. In part 3 of the series, Using the API, we will look at how to actually use the Configuration API, as well as some contributed modules that extend the functionality of the Configuration API, allowing for more effective management of Drupal 8 projects.

Categories:

Matt Glaman: A proper introduction to Drupal Check

Planet Drupal - Sun, 2019/05/12 - 4:30pm
A proper introduction to Drupal Check Sunday 12, May 2019 mglaman You may have heard of Drupal Check. You may wonder what in the world it is or how it even came to be. I realized this went from an internal research and development task for a product, to open source contribution and then to an essential tool in the march toward Drupal 9. The timeline from January to DrupalCon in April has been pretty crazy, and I realized I have never done a proper blog post about Drupal Check.
Categories:

Matt Glaman: ContribKanban 2019 update

Planet Drupal - Sun, 2019/05/12 - 1:45am
ContribKanban 2019 update Saturday 11, May 2019 mglaman It seems that I do a roughly annual update for ContribKanban and what I plan on doing with it. This year I evaluated its future and roadmap and how it can be more useful for the community at large.
Categories:

Chapter Three: Gated resources forms with webform and token

Planet Drupal - Fri, 2019/05/10 - 10:24pm

On several occasions clients have come to us asking for a form with a gated resource. They want the  resource (.pdf, .doc, .xls etc.) to be available to download after the user fills a form. In exchange for the visitor's valuable information, we provide them a file.

This is easily achievable in Drupal 8 with the Webform and Token modules.  At the time of creation of this blog post, I used Drupal version 8.7.0.

Categories:

Vasily Yaremchuk: I have switched my Drupal 8 site to a static HTML site with Tome

Planet Drupal - Fri, 2019/05/10 - 9:00pm
I have switched my Drupal 8 site to a static HTML site with Tome

Many years ago I made my personal page on Drupal 7, as soon as Drupal 8 was released I have upgraded to this version. My personal site is just a page with my contacts and my blog. 

In truth, I do not always have enough time to write posts to my blog, as well as keep the core and modules up to date. Some times between the huge projects I have a frame to share my experience and to make some support tasks and improvements. 

So more than 99% of its life my personal site works as a simple static HTML site.

Does it make sense to use Drupal as a backend? 

Let's imagine the site is static at any time except the time when I want to edit it...

And it's possible with Tome. It's Drupal 8 module. You can get more information on the official site tome.fyi.

Let me show you my personal site abzats.com. It's a static HTML site. I don't have the permanent version of this site either hosted somewhere or locally. But I have a private repository of my Drupal site with configurations and content in flat files. 

Tome module allows exporting configurations in .yml files and content in .json files as well as install Drupal with those files without operating with the DataBase dump.

I have decided to put some changes on the site. I need to get the site locally, log in Drupal admin, make changes and generate a new version of my static site. That's it.  

Cloning the site:

$ git clone git@github.com:vasilyyaremchuk/personal.git

It's my private repository, that I have forked from https://github.com/drupal-tome/netlify-template

Coming to the folder:

$ cd personal

If you've taken a look at https://github.com/drupal-tome/netlify-template you could find that there is no core folder there. You have to run 

$ composer install 

to get all necessary dependencies. 

Install the site with drush:

$ drush tome:install

Run a local server with drush:

$ drush runserver

Make some changes in the admin area. A new password to login in admin provided after the previous action.

If all changes were done, we can stop the server and generate a static site:

$ drush tome:static --uri=http://abzats.com/

Attention! Don't forget to set the basic URL of your production site, otherwise, you can get incorrect links that point to your local environment in some places of the static site.

Now you have a new static version of the site and you can deploy it on your hosting.

Don't forget to update the repository with those changes:

$ git status

You can see that one file with content is changed. Let me commit those changes:

$ git add .

$ git commit -m "content changes"

$ git push

Finally, you can delete the local Drupal 8 site:

$ cd ..

$ rm -R personal

Vasyl Yaremchuk 05/10/2019
Categories:

wishdesk.com: New Drupal Media Library interface: managing media with joy

Planet Drupal - Fri, 2019/05/10 - 5:50pm

The blend of usability and attractiveness exists — this is Media Library in Drupal 8.7 core. That’s what comes to mind when we see Drupal Media Library’s updated UI. Managing media on websites will now be easier and more enjoyable than before!

Drupal Media Library allows you to:

Categories: