Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 2 horas 34 mins

Srijan Technologies: Site Owner’s Guide to a Smooth Drupal 9 Upgrade Experience

Hace 6 horas 59 mins

While upgrading to the latest version is always part of the best practice, the process can be staggering.

Drupal 8.7 is already here and 9 will be released in a year, in June 2020.

Although a lot of discussion is happening around the upgrade and possibilities it brings along, the final product can only be as good as the process itself.

The good and important news is that moving from Drupal 8 to Drupal 9 should be really easy — radically easier than migrating from Drupal 7 to Drupal 8.

As a site owner, here’s what you need to know about the new release and what to take care of to make the process easier without many glitches.

Clemens Tolboom: Working on a Drupal module using composer

Sáb, 05/18/2019 - 06:10

Altering Drupals composer.json to fetch a particular Drupal module git checkout.

Lullabot: Introducing Support & Maintenance at Lullabot

Vie, 05/17/2019 - 15:33

In our booth during DrupalCon Seattle this year, we had the pleasure of speaking with people in the Drupal community about our new Support & Maintenance offering. The response we heard most often was, “Doesn’t Lullabot already do support and maintenance?” The short answer is yes.

Hook 42: Drupaldelphia: The Jawn That Never Disappoints

Vie, 05/17/2019 - 10:49
Drupaldelphia: The Jawn That Never Disappoints Lindsey Gemmill Fri, 05/17/2019 - 13:49

myDropWizard.com: Experimental Composer repository with CKEditor plugins

Vie, 05/17/2019 - 10:49

In my experience, a big part of making a Drupal 8 site usable for content editors is customizing the WYSIWYG, which usually includes adding a couple additional CKEditor plugins.

Of course, you can simply download the plugins into the 'libraries' folder, and that's fine. But these days, it's becoming best practice to pull in all of your site's dependencies using Composer.

Adding 'package' repositories to your composer.json for the CKEditor plugins (the current best practice) works fine - but only for your individual site.

It doesn't work so well if you want to install:

  • A Drupal "Feature" (like with the Features module) that configures the WYSIWYG, including adding some CKEditor plugins, or
  • A Drupal distribution (like Panopoly or Lightning)

In those cases, you can't depend on what the individual site may have in its top-level composer.json, and asking the user to manually copy-paste a bunch of 'package' repositories in there may create enough confusion or problems that potential users will just give up.

Well, I've got an possible solution to this problem: an experimental Composer repository which includes CKEditor plugins for use on a Drupal site.

It works better for Feature modules and distributions, but can also make life easier for individual sites too.

Read more to find out how it works and how to use it!

ThinkShout: The Problems In Tech Go Deeper Than ‘Hacking’

Vie, 05/17/2019 - 09:00

Earlier this week, The Cut ran a piece about a “Tinder Hacker” who created a fake profile with his roommate’s photos, then hooked a piece of code up to the Tinder API and did some very simple string substitutions so that men who messaged “her”–after “she” swiped right on them–were tricked into actually talking to other men who did the same. In brief, he put strangers in contact with each other under false pretenses, rerouted and surveilled their communications without consent, and proceeded to use this as a bragging point on dates and in interviews.

One might take exception to a number of elements of this story, but let’s start with its terminology. “Hacking” is a word whose meaning has broadened beyond all practical use, but in no sense did “Sean”, the pseudonymous subject of the story, “hack Tinder.” He relied on someone else’s reverse engineering to write some buggy code that ran against its API. That’s all.

The article itself seems confused about whether the Tinder API, or Application Program Interface, only exists to allow homebrew apps on Windows Phone. But an API is just a set of commands made available by a server, like the Tinder mothership, to accept instructions from client apps, like the many copies of the Tinder app that run on all kinds of phones. Almost all the apps on your phone are clients that work this way, and APIs are ubiquitous. Even the Drupal and Wordpress sites we build each have their own versions.

The code described in the article fits less within the definition of a hack than that of a bot. It would live on a server, persist as a service, wait for triggers–like incoming messages–and then respond to them according to certain rules. Some bots are used for automated customer service; some are used for art projects; some are used for jokes. Many, many, many bots are used for spam or other malicious purposes.

The ethics of bot development are not always simple, but they’re not new territory either. That’s the second and most glaring exception to be taken here: Sean’s assertion that his bot was at the “gray hat” level of malice in terms of its exploitation of code. Bot creator and Portland local Darius Kazemi wrote a thoughtful piece about considering and refining the possibility space of joke bots toward kindness in 2015. That in turn references fellow creator Leonard Richardson’s seminal 2013 post “Bots Should Punch Up”, which contains a telling bit with regard to the color of that hat:

“Hackers and comedians and artists are always attracted to the grey areas. But your bot is an extension of your will, and if you're a white guy like me, most of the grey areas are not grey in your favor.”

Perhaps it’s assuming too much to conclude that Sean, a San Francisco programmer whose race is not mentioned in the article, is a white guy. Perhaps not. Technology as a field in the US is overwhelmingly full of white men, offering most of the benefits of the biggest wealth creation engine in history to the people who were already granted our society’s highest levels of privilege. That privilege, and power, means that thoughtless choices have more potential to do harm: by default, they’re punching down.

But even if that weren’t the case, as an educated and socialized human adult, it shouldn’t have been hard to see that writing a service solely to entice, deceive, manipulate and mock people in a vulnerable space like a dating app might have consequences. That is, unless you’ve spent a career being rewarded for ignoring consequences, because you work in tech. That’s the third exception to be taken. For pulling a prank like this, many people would be fired or sued. Instead, Sean got a better job.

I can admit that this story struck me on a personal level. Back before I had to quit Twitter, I used to write bots using their API myself. One of them, which I created in 2014, worked on a similar principle to the Tinder bot: it would receive a person’s message, put it in holding, and send them back a random held message from someone else in response. The juxtapositions were surreal, delightful, and often rewarding. And everyone involved was informed, consenting, and able to make use of built-in safety tools to report bad actors.

I’m not an ethicist or a researcher by training, but I knew to consider those aspects of my work because I have an interest in the history of the internet. According to the article, Sean does too–I’m willing to bet he and I read the same books about phone phreaks, blue boxes and Captain Crunch.

The phreakers he admires, by the way, were indeed “punching up” with their pranks–using low-rent tools to get one back at Bell, an exploitative tech monopoly that would eventually be broken up. Hey, there’s an idea.

People have made infamously bad choices like Sean’s before, and one might expect creators here in the future to work at avoiding their repetition. But instead, his story reflects the broader attitude of a tech sector that is not just ahistorical, but willfully naive and ignorant of the lessons of its past. (If you only read one thing linked in this whole piece, make it that last one. Go ahead, I’ll wait.)

The things I value about working at ThinkShout stand in opposition to all of that. My colleagues here are technical experts, but they’re also widely read, deeply informed, and always working to expand our collective view of the world in inclusive and considerate ways. That’s why we take pride in supporting progressive organizations like the Campaign Legal Center and ChangeLab Solutions. That’s why we focus on accessibility for all users as a core concern and increasing equity in our own job pipeline. That’s why we’re fine with being located far outside the insular centers of big tech culture, where it seems like people would rather try to land on the Moon than make change on the ground.

Even if the article in The Cut highlights the deep problems in the technology sphere that engulfs us all, there are certainly worse things on the internet than a man getting his kicks by trolling a bunch of other men. But there are better things too. If you’d prefer to join us on that side, please get in touch! We’re hiring, and we’d be glad to hear about how your hobby project brought a little kindness and empathy to the world.

Duo Consulting: A Better Way to Search in Drupal

Jue, 05/16/2019 - 17:04

One of the best things about Drupal’s open-source ecosystem is that it empowers you to be open-minded. Given the vast array of solutions and modules available, users can customize their site to their whims. Alternatively, if you think up and code something new, your contributions can be shared online with other users. With all of the customization available, Drupal is a conducive platform for outside-the-box thinking.

Decoupling is a recent example of this philosophy. Where a standard Drupal website would feature a Drupal-powered front and backend, decoupling opens the door for a variety of possibilities. A decoupled site can utilize different platforms and technologies for both the front and backend. For example, a decoupled site could utilize Drupal’s backend CMS while running a React-powered frontend. Such is Drupal’s flexibility that it can power scores of different, user-facing channels from a single backend, including other sites, native apps, Internet of Things (IoT), and more.

This decoupled or “headless” concept has more applications than just for site design, though. The search function of a website, for one, can benefit from components that utilize this headless approach – and not a moment too soon. As Google has begun to sunset its Google Search Appliance offering, there is now a need for an open and flexible search tool with enterprise-level capabilities.

At this year’s Midwest Drupal Camp, the team from Palantir demonstrated that a decoupled approach to site search was viable. This solution, federated search, allows for indexing and searching across multiple sites. For organizations with a large web portfolio across different platforms, this open federated search solution can fill the gap left by Google.

Understanding why federated search for Drupal is important requires an understanding of how regular site search functions operate. At the core, the search feature is built from three different components: the source, index and results. The source simply refers to all of the searchable content on a given site, from blogs to landing pages. The index is a compilation of metadata that makes the content form the source easier to parse. At Duo, we often use Apache Solr, a platform-agnostic, open source solution for indexing, as it provides speed, power and its own server capabilities. Finally, the results refers to the front-end experience that compiles and delivers the search results to the user.

The above setup will work fine for most simple websites, but larger organizations often require a more robust solution. With federated search, users can query across multiple sites across different platforms without placing much strain on Drupal, since Apache Solr is handling generating the index and providing results. This is accomplished through some tweaking of the basic site search formula.

Part of what makes this search so powerful is that it takes advantage of Drupal’s backend without relying on its frontend. For that, Apache Solr’s dedicated servers empower this new search solution by shouldering the burden of indexing and providing the results. Before it can work, though, some configuration is needed. Based on this configuration, Apache Solr can encompass searches across different sites – including sites that aren’t built with Drupal. Creating this custom solution, in conjunction with the Search API and Search API Solr modules, will ensure that the different data types being indexed will be standardized.  

As for the results section, the best approach is a decoupled one. Building out the front-end component in the React JavaScript library allows for robust searches without slowing down the rest of the site. By using Drupal’s CMS, Apache Solr and React’s power in coordination, any organization can create a search feature that quickly indexes vast ranges of data and delivers it in an easily digestible manner. For a deeper dive, Palantir has made their demo of federated search available.

This powerful and streamlined take on site search has a variety of applications. Before releasing the solution, Palantir originally developed federated search for the University of Michigan, as each department ran their own sites on different platforms. Federated search now allows users to seamlessly search for information across the entire school’s network, regardless of the technology used to deliver the content. Beyond university ecosystems, federated search also presents an opportunity for eCommerce. Using this solution, products from different vendors can be consolidated into a simple search.

Thanks to Drupal being open source, organizations can utilize federated search and any other contributed solution at any time. This level of openness is what makes Duo such champions of the Drupal platform. At Duo, we’re committed to exploring new features like this and helping each of our partners think outside the box. If you’re ready to start rethinking your website or sites, we’re just a click away.

Srijan Technologies: Drupal and Accessibility: Does the Community Stand by What it Preaches?

Jue, 05/16/2019 - 08:46

“..an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.”

Agiledrop.com Blog: Interview with Tim Lehnen: When you're trying to make a mark in the digital space, Drupal is your best choice

Jue, 05/16/2019 - 05:42

We're very happy we got to speak with Tim Lehnen, the interim Executive Director of the Drupal Association. Tim is honored to be serving the Drupal community for the past 5 years and is looking forward to how Drupal will evolve alongside digital innovations.

READ MORE

Morpht: Drupal 8 Configuration - Part 5: Module developers and the API

Mié, 05/15/2019 - 23:14
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:

This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

Configuration Schema

Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'
    mail_address:
      type: string
      label: 'Contact mail address to show to blocked users'
    dblog:
      type: boolean
      label: 'Log blocked access attempts'
    allow_role_bypass:
      type: boolean
      label: 'Allow IP blocking to be bypassed by roles'
    bypass_action:
      type: string
      label: 'Action to perform for blocked users when bypassing by role is enabled'
    white_black_list:
      type: integer
      label: 'Whether to use a path whitelist, blacklist, or check all pages'
    country_white_black_list:
      type: integer
      label: 'Whether to use a whitelist, blacklist, or neither for countries'
    country_list:
      type: string
      label: 'A colon separated list of countries that should be white/black listed'

The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

The values can be retrieved from the restrict_ip.settings object as follows:

$enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
$mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
$log = \Drupal::config('restrict_ip.settings')->get('dblog');

Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

Default configuration values

If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

enable: false
mail_address: ''
dblog: false
allow_role_bypass: false
bypass_action: 'provide_link_login_page'
white_black_list: 0
country_white_black_list: 0
country_list: ''
 

As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

Debugging Configuration

When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

The Configuration Inspector module errors in configuration schema definitions

Clicking on 'List' for items with errors will give more details as to the error.

The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

Summary

In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

Promet Source: Digital Accessibility and the Common Good

Mié, 05/15/2019 - 16:54
  “Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”         - Margaret Mead   Today marks the 8th annual Global Accessibility Awareness Day.

Lullabot: Supporting Mental Health at Lullabot

Mié, 05/15/2019 - 14:46

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.

Nonprofit Drupal posts: May Drupal for Nonprofits Chat

Mié, 05/15/2019 - 14:43

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.

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

Mié, 05/15/2019 - 12:46
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.

Event Organizers: Seeking Event Organizers

Mié, 05/15/2019 - 11:39

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.

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

Mié, 05/15/2019 - 10:53

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.

Web Wash: Getting Started with Bootstrap in Drupal 8

Mié, 05/15/2019 - 08:15
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.

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

Mié, 05/15/2019 - 06:22
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!

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

Mar, 05/14/2019 - 22:24
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.

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

Mar, 05/14/2019 - 22:14

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

Páginas