Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 8 hours 47 min ago

Lullabot: Supporting Mental Health at Lullabot

15 May 2019 - 10:46am

Before I dive into our Mental Health Initiative, I'll tell you how it came to exist. Leading up to our annual team retreat, I send a team survey to discover what excites or worries people. The questions change year to year, but here are what appear to be the perennial questions. I'll include the majority response from the team to each item as well.

Categories: Drupal

Nonprofit Drupal posts: May Drupal for Nonprofits Chat

15 May 2019 - 10:43am

Our normally scheduled call to chat about all things Drupal and nonprofits will happen tomorrow, Thursday, May 15, at 1pm ET / 10am PT. (Convert to your local time zone.)

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

We have an hour to chat so bring your best Drupal topics and let's do this thing!

Some examples to get your mind firing: how do I recreate [feature] on my Drupal 7 site in Drupal 8? I need to explain [complicated thing] to a non-technical stakeholder -- any advice? How can I get Drupal and my CRM to play nicely?

This free call is sponsored by NTEN.org but open to everyone.

View notes of previous months' calls.

Categories: Drupal

Sooper Drupal Themes: Acquia Acquires Mautic. Mautic vs Marketo vs Pardot vs HubSpot

15 May 2019 - 8:46am
Acquia acquires Mautic

Recently, Acquia has acquired Mautic, an open source marketing automation platform. With this acquisition, Acquia is planning on disrupting the market and its closed technology stack competitors in the automation market. Acquia is a leading provider of digital experience solutions based on open source software Drupal. Now, Acquia product offering will be complemented by the newly acquired automation and campaign management platform, further adding more value proposition to the solutions offered by Acquia. This will provide marketers with a seamless experience, from designing and managing websites, to managing and tweaking communication campaigns across different platforms and digital channels. It seems that Acquia is dead set on making the future of marketing open source.

Here at Sooperthemes we're very excited about this move, because we've been interested in Mautic's development from the beginning and are looking forward to a closer Drupal integration.

Marketing automation is an emerging term in the marketing community. It promises solutions to age-old challenges that marketers face in their daily jobs. But what exactly is marketing automation?

What is marketing automation?

Marketing automation refers to software that aims to automate repetitive tasks. For example marketing involves a lot of repetitive tasks such as qualifying leads, emailing, social media posting and other editorial actions. Marketing automation helps to reduce the workload and makes it easier to bring those tasks to completion in a fast and efficient way.

Reasons for using marketing automation

Marketers can use automation paired with inbound marketing to increase the amount of qualified leads. Furthermore, it is easier to drive qualified leads through the sales funnel. Qualified leads have a lower churn rate than unqualified ones. Moreover, when it comes to nurturing these leads, it can involve loads of mundane tasks, which takes time and is inefficient. However, by using marketing automation, it frees precious time for the marketer to be able to undertake more strategic tasks.

Comparison of marketing automation software

HubSpot, Marketo, Pardot and Mautic are major players in the marketing automation market. In this article, there is going to be presented a comparison between the 4 automation platforms.

HubSpot

HubSpot is a sales and marketing automation platform that is an all-rounder right out of the box. Out of the box, HubSpot is checking all the requirements for the most common tasks. Furthermore, it has unrivaled training, support and content. It also offers an easy to use interface for marketers, which is easy to use for even the most non-tech savvy of employees. A drawback of using HubSpot is that the contract is for at least 12 months, essentially locking up the customers to use the product. Furthermore, the pricing is also based on contacts, which can increase steeply. On top of that it also has some social media limitation when posting or tagging.

Marketo

Marketo is the marketing automation solution from Adobe. It was acquired by Adobe in October 2019. Marketo has a starting price of $895 per month. It is a great mid-range solution for companies which require a robust solution but don’t want to spend more than necessary. As its drawbacks, it has a poor landing page and form builder. On top of that, it has limited reporting and analysis functionality. Furthermore, there are steep increases in prices for just some added features.

Pardot

Pardot is the marketing automation and lead management solution from Salesforce. It has a starting price of $1250 for the most basic package. It allows marketing and sales teams to create and deploy online marketing campaigns in an easy and intuitive way. On top of that, Pardot brings the power to visually test the campaigns that are built, from the perspective of the client. On top of that, with the power of automation and segmentation, Pardot brings the power of smart lead management and generation to the table. Essentially giving the user the capability to nurture a lead based on different triggers that are activated during his customer journey on your website. Drawbacks of the platform include the fact that it lacks the tools for social media management. Furthermore, for A/B testing, user have to get the PRO subscription starting at 2000$ per month that is billed annually.

Mautic

Mautic has recently been acquired by Aqcuia. The goal here is to deliver the first ever open source marketing cloud to the market. Mautic is an open source software with that has self hosting capabilities. What this means is that companies that are using it, will not have to outsource the servers from the software providing company. This gives the users an increased sense of security, since the data will not be stored on different servers other than their own. On top of that, being open source, the code is available for everyone to see. This means that people have the flexibility to contribute and adapt the code to best suit their business or personal needs. On top of that, Mautic has a great degree of integration, making it easy to integrate with different content management systems such as Drupal, WordPress, Joomla, TYPO3, etc.

One drawback that Mautic encounters is the fact that the installation process can be tricky for a person that is not working in the IT department. This coupled with the fact that Mautic does not have the best available documentation to guide the user to the process, can result in a frustrating experience.

Here is a visual comparison of the features provided by each platform:

Features

HubSpot

Marketo

Pardot

Mautic

Starting price

$200/month

$895/month

$1000/month

Free

Lead scoring

Yes

Yes

Yes

Yes

Lead segmentation

Yes

Yes

Yes

Yes

SMS marketing

Yes

Yes

No

Yes

Personalize web content

Yes

Yes

Yes

Yes

Predictive analytics

Yes

Yes

Yes

No

Event management

Yes

Yes

Yes

Yes

Sales reports

Yes

Yes

Yes

Yes

Bi-directional CRM syncing

Yes

Yes

Yes

No

Create invoices

Yes

No

No

No

Split testing

Yes

Yes

Yes

Yes

Social CRM

Yes

Yes

Yes

Yes

Future-proofing Marketing

Given the fact that the forecast for the marketing automation market is going to grow and reach $32.6 billion by 2024, it’s safe to say that marketing automation is a growing trend. What this means is that more and more companies will start adopting marketing automation means in order to better and more efficiently fulfill daunting marketing task. Now, with the knowledge of the most important players in the field, you have taken the first step towards an automated future.

Categories: Drupal

Event Organizers: Seeking Event Organizers

15 May 2019 - 7:39am

The Drupal Event Organizers Group had a very productive DrupalCon Seattle (look for a blog post soon) and is taking the momentum from our in-person meetings to keep the initiative moving forward. Our next step is to create an official charter (similar to that of the CWG) to solidify our mission, process, and membership.

To that end, the Event Organizers Group is putting out a call for members of our Formation Board. This small group will be tasked with drafting a charter, reviewing it with the larger group, and then getting approval from our BDFL within the next few months.

We have representation from the US, and our immediate need is for members across the globe. If you're passionate about event organizing in your area and would like to be involved, please reach out to Avi Schwab on the Event Organizers Slack. We'll be having meetings at least bi-monthly and working asynchronously between them to develop the charter. We're committed to ensuring global accessibility, and as such will be alternating meeting times across the globe.

Categories: Drupal

Drudesk: Stable Layout Builder in Drupal 8 core: a tour on layout creation

15 May 2019 - 6:53am

There are Drupal modules loved by both developers and content editors. One of them is Layout Builder. It allows to create page layout templates of various complexity via a handy drag-and-drop interface. The chance to do it with a built-in user-friendly tool is among best Drupal 8 benefits.

Categories: Drupal

Web Wash: Getting Started with Bootstrap in Drupal 8

15 May 2019 - 4:15am
Bootstrap is a front-end framework for building websites. It ships prebuilt CSS and JavaScript components that make building sites fast. It comes with all sorts of common components that every website needs such as a grid system, buttons, drop-down, responsive form elements, carousel (of course) and so much more. As a developer I don't want to spend time styling yet another button. I just want to know which CSS class to add to an "a" tag so it looks like a button and I'm good to go. One complaint about Bootstrap is you can spot it a mile away because a lot of developers use the default look-and-feel. When you see the famous Jumbotron you know it's a Bootstrap site. But with a little bit of effort you can make your site look unique.
Categories: Drupal

Amazee Labs: Drupalcamp Spain 2019 - sessions, surf, food and community

15 May 2019 - 2:22am
Drupalcamp Spain 2019 - sessions, surf, food and community

Drupalcamp Spain 2019 took place last week in the beautiful city of Conil, in the South of Spain. We had not only great weather, food, company… but also great sessions! This year’s schedule also included the Spanish Splash Awards, Business Day and even a side-event for those accompanying attendees, called Family in Drupal, where they did activities such as yoga, surfing, horse-riding, etc.

Fran Garcia-Linares Wed, 05/15/2019 - 11:22

Drupalcamp Spain was a great gathering of people from not only Spain but many other countries. In fact, they offered two separate tracks, one in Spanish and one in English. As usual, it was difficult to choose which sessions to attend, but I think I got a really good mix and enjoyed them all thoroughly.

It’s also worth mentioning the registration bag that included a (very discreet) T-shirt, a bottle of wine (so my wife would be okay with me leaving her with the kids), a bottle of olive oil, some local tuna (Conil is a fishing town) and some other goodies.

I especially enjoyed the Friday afternoon English-track, which was “all about decoupled”. We saw an example of a project which started as a Drupal commerce site with some React components, which eventually became an app built in React native, integrating seamlessly with Drupal via GraphQL.

That was the perfect introduction to my talk, which was up next, about “GraphQL and Twig”, where I went through the whole process of installing, configuring and using GraphQL queries in your Twig templates, as a way of soft-decoupling some parts of your site. You can view the slides here: https://slides.com/fjgarlin/graphql-twig-drupalcamp-spain-2019.

I was very glad to see that my session seemed interesting and useful to attendees and I enjoyed getting to answer some questions right after the session and the following day. People were surprised about how easy it is to get up and running and how powerful this combination can be as well. The closing session on Friday afternoon was about Drupal + GatsbyJS, showing how easy it is to connect those two technologies and doing a live demo about it.

Group photo - Jorge Caspio

Saturday was also loaded with interesting content, and I ended up going to sessions on topics ranging from QA, SEO, UX, Migrations, Continuous Integration, Content architecture… that’s a good mix for a day, isn’t it? The speakers were really engaging and I must say that I learned a lot on that day. I also enjoyed learning how other agencies work, how we all face similar problems and solve them in different (or sometimes similar) ways. It’s always refreshing to listen to other people's experiences. I must say that most of these learnings happened in-between sessions, chatting and walking around Conil, etc.

I want to give a big, big thanks to all the people who made this event possible: organizers (Ruben Tejeiro, 1xInternet, Drupal association Spain), speakers, photographer (Jorge Carpio), volunteers and attendees from all over.

Looking forward to next year’s edition, ¡muchas gracias por todo!

Categories: Drupal

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

14 May 2019 - 6:24pm
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: Drupal

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

14 May 2019 - 6:14pm

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

Duo Consulting: Acquia Acquires Open Source Marketing Platform Mautic

14 May 2019 - 7:43am

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

OpenSense Labs: Drupal 8.7 Unleashes New Layout Builder

14 May 2019 - 5:23am
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: Drupal

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

14 May 2019 - 4:10am
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: Drupal

Electric Citizen: When to upgrade from Drupal 7

13 May 2019 - 1: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: Drupal

Phase2: Last Week’s DXP One-Two Punch

13 May 2019 - 9:04am

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

Categories: Drupal

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

13 May 2019 - 3:39am

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

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

13 May 2019 - 12: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: Drupal

Promet Source: Invent Your Own Development Methodology

12 May 2019 - 11:14pm
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: Drupal

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

12 May 2019 - 4:04pm
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: Drupal

Matt Glaman: A proper introduction to Drupal Check

12 May 2019 - 7:30am
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: Drupal

Matt Glaman: ContribKanban 2019 update

11 May 2019 - 4:45pm
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: Drupal

Pages