Acro Media: The Case of reCAPTCHA Session Validation Errors | Acro Media

Planet Drupal - Thu, 2020/12/24 - 4:00pm

Happy holidays everyone. We’ve had three sites in the last two weeks that have reported reCAPTCHA problems. A captcha is the funny little thing at the end of forms that tries to prove you’re not a robot by having you spell out letters, or pick pictures with traffic lights. They’re annoying, but without them, many “contact us” forms and user registration forms can be hit with a crippling amount of spam submissions.

Newly discovered reCAPTCHA session validation errors (TL;DR)

One of our clients even recently called in for holiday support on this bug, so we’re pretty sure there are others dealing with this situation as well. They all have the same JS error and/or symptom:

CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if the problem persists.

Diagnosing the session validation error

The root of this error, at least for one of our sites using simple_reCAPTCHA, is pretty straightforward (but took us days to diagnose initially). There are two parts to the issue. A typical contact us page has 2-3 forms on the page: Search, Email Sign Up, and the contact form. The submit button for each one has the same HTML ID. That's not valid HTML; IDs have to be unique. There's code in the reCAPTCHA, captcha, and simple_reCAPTCHA modules that get tripped up because of caching.

Each part (block) on the page is cached separately, so when someone visits the homepage and that gets cached, Drupal also just pulls the search form from its cache for other pages instead of rendering it from scratch.

If rendering the whole page from scratch, Drupal uses unique IDs in every form. One's submit button has the id #edit-submit, another gets #edit-submit--2, the other #edit-submit--3. But due to the caching behaviour with reusing existing blocks, we end up with:

  1. If you visit the homepage, which just has the search form, its button gets #edit-submit.
  2. When you visit the contact page, which has 2 forms that need to be rendered, the Sign-Up and contact form, Drupal uses ids #edit-submit and #edit-submit--2. But the cached search form also ends up in the header with an id of #edit-submit too.

The simple_recaptcha module does something quirky. When you click the submit button it runs some javascript to get a token from the reCAPTCHA service, which is fine, but then it has to re-click the submit button, and it does that by looking up the button by ID again. Looking up by ID gives the first element with that ID, the search form's submit button.

Similarly, the captcha and reCAPTCHA module loads the token, but it gets stored in the cache and it causes the same or similar error that simple_recaptcha does.

Helping reCAPTCHA modules deal with Drupal caching

The real bug is challenging and not fixable within our support scope of practice. More on the accessibility concerns and other issues below.

  • The fix for the simple_captcha module is to modify the javascript as described in this bug write up.
  • If you’re using the captcha module, we recommend reviewing the discussion and various patches in #3089263.
  • For the reCAPTCHA module, perhaps consider using one of the other two modules instead.
Accessibility concerns

Even if you’re not using the reCAPTCHA module, your site may still have an adverse effect on accessibility as well as confusing any Javascript that is written. Here’s a quote from the linked accessibility issue:

“It may sound minor, but it's a major issue, as it is associating the search autocomplete functionality in the header with the views filters elements in the content. The end result is that JAWS thinks a regular select element in the views filters, is a combobox, which it is not, so it's pretty confusing to users.”

So it’s not just captcha related and is definitely going to need some real consideration from the caching experts that work on that piece of Drupal. Let us know on Twitter if you’re having the same issues and how you fixed them.

Categories:

mark.ie: Create View Mode Component and Views List in PatternLab and Drupal

Planet Drupal - Wed, 2020/12/23 - 11:15am
Create View Mode Component and Views List in PatternLab and Drupal

Here's two short, related videos demoing how I create a view mode component, use that view mode in a views list in Patternlab, and then integrate both with Drupal.

markconroy Wed, 12/23/2020 - 10:15
Categories:

joshics.in blog: Drupal 8: Writing your first Drupal 8 custom module -- info file

Planet Drupal - Wed, 2020/12/23 - 8:17am
Drupal 8: Writing your first Drupal 8 custom module -- info file

Drupal 8 has been rewritten from scratch and it heavily uses OOP. And this affects all the way we write code for Drupal 8, be it a custom module for your project or a contributed module that you want to publish on drupal.org

Categories:

Matt Glaman: JSON:API Resources is Drupal 9.1 compatible

Planet Drupal - Wed, 2020/12/23 - 6:24am

JSON:API Resources is now Drupal 9.0 and 9.1 compatible with the 8.x-1.0-beta4 release! If you are not familiar with this module, it is essentially the sandbox contributed project for building the extensibility layer for Drupal's JSON:API implementation. That is a fancy way of saying it lets you define custom endpoints that leverage the JSON:API specification.

We shipped the module with a requirement of drupal/core:^8.8@alpha as we required some code that would ship in Drupal 8.8.0. Howevever, we never released the fix for the composer.json file to allow installation of th module with Drupal 9!

Categories:

Mediacurrent: Making the Business Case for a New CMS

Planet Drupal - Tue, 2020/12/22 - 2:13pm

Have you ever decided on investing in a product or service, but require approval from executive sponsors before proceeding with your purchase? Or do you like a product or service, but are hesitant to make the investment in it because it’s costly?

If either of these scenarios describes the situation you’re in, a business case is an excellent thinking tool that can help you with your decision.  A business case articulates the rationale for investing in a product or service in terms of numbers. It is often presented in a formal document, but may also be presented through more informal methods like a spreadsheet or even a single slide in a slide presentation. It further provides a way to make your case to nontechnical decision-makers without needing to provide the specific intricacies about the method or approach to your desired product or service’s implementation. 

To build a business case, perform the following steps: 

  1. Define the options to evaluate
  2. Determine the costs of each option
  3. Determine the benefits for each option
  4. Recommend an option based on cost and benefits

Let’s look at each of these steps more closely.

Defining Your Options

When evaluating a new product or service, you instantly are faced with two options: purchase the new product or service, or stay with what you have. In many cases,  decision-makers start with a bias toward the status quo because there is no cost in transitioning to new technology and the business process that goes along with it. Further, if a new product or service is being considered, its competing options should be considered as well, for example, if you’re considering Drupal as a web content management platform, consider WordPress too.

Let’s illustrate with an example. Say you have a proprietary, licensed legacy content management system (CMS) that is poorly performing and difficult to maintain. You and your company are no longer happy with it and want to make a change. Your budget is limited, so an open-source solution is more attractive because it carries no licensing fees. Drupal is certainly an attractive option, but as just stated, add WordPress as an option. This brings our options to the following:

  • Drupal
  • WordPress
  • Status quo CMS

In a real-world scenario, it’s good practice to consider more options than this, including evaluating proprietary options like Sitecore and Adobe Experience Manager. For the sake of simplicity, however, let’s limit our example to the ones we’ve listed. 

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are approximations only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the three options. These entail the licensing and build estimates for each option. This illustration assumes a simple implementation with little to no customization. Please note that these numbers are for illustrative purposes only. Real-world figures, driven by project requirements, will certainly differ.

Cost

Drupal

WordPress

Status Quo CMS

Initial License

$0

$0

$0 (already paid)

Build

$100,000

$50,000

$0

Total

$100,000

$50,000

$0

 

It comes as no surprise that the implementation cost of the status quo CMS is $0, because, after all, it has already been bought and configured. The licensing costs of all three options are $0 because Drupal and WordPress are open source offerings, and the license fee of the status quo CMS has already been paid. Had Adobe Experience Manager or Sitecore been considered, their license costs would be non-zero. In our example, we budget more for the Drupal build than that of WordPress because in our experience, with Drupal’s greater power and flexibility comes greater complexity, and that typically translates to greater investment in development hours. 

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs. To reiterate, these numbers are for illustrative purposes only. 

Cost/year

Drupal

WordPress

Status Quo CMS

Maintenance and Support

$20,000

$10,000

$50,000

Ongoing License

$0

$0

$10,000

Total

$20,000

$10,000

$60,000

 

Factoring ongoing costs makes it immediately apparent that the status quo CMS is costlier in the long term, both in maintenance hours spent and in annual licensing.  As with their initial implementation costs, Drupal’s ongoing costs are greater than those of WordPress because, again, of Drupal’s greater complexity.

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue (again,  just an illustration), the following table summarizes the benefits of each option. 

Benefit/year

Drupal

WordPress

Status Quo CMS

Annual revenue

$200,000

$150,000

$100,000

 

Finally, we see where the investment in Drupal’s complexity pays off; its greater functionality typically means a greater ability to meet ever-evolving needs. We translate this in our example to a greater annual revenue than that of WordPress, and both CMSs, being more functional than the status quo CMS, are capable of generating more revenue. 

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison:

The above graph makes the following assumptions:

  • In Year 1, the Drupal and WordPress options earn no revenue because they’re being built
  • Likewise the status quo CMS is earning revenue in Year 1 because it has already been built

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, staying with the status quo CMS is the best option.
  • If your organization is willing to make a moderate up-front investment for moderate long-term benefit, WordPress is the best choice.
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, then Drupal is the way to go.

Admittedly, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

Categories:

Matt Glaman: PHPStan Drupal 0.12.7 released, latest PHPStan now supported!

Planet Drupal - Mon, 2020/12/21 - 7:21pm

PHPStan Drupal 0.12.7 was released this morning, with only one fix. But it's an important one. This post acts as a retrospective for diving into an obscure issue that took a few months to determine. It turns out that the Rector project had been facing this bug for weeks, as well.

Categories:

BADCamp News: San Francisco Drupal User Group welcomes in the new year

Planet Drupal - Mon, 2020/12/21 - 4:58pm
San Francisco Drupal User Group welcomes in the new year Mon, 12/21/2020 - 12:00 volkswagenchick Mon, 12/21/2020 - 07:58 Do you miss BADCamp and the rad community that comes along with it?? We do too!! But you know what?! We still get together at least once a month for San Francisco Drupal User Group (SFDUG)... and SFDUG is gearing up for the new year, and we want to introduce the exciting winter lineup!! Drupal Planet
Categories:

Jungle Ran: Drulibs.com: an easier way managing Drupal 3rd-party FE libraries with Composer

Planet Drupal - Mon, 2020/12/21 - 4:50pm

Currently, no recommended/better way for 3rd party FE libraries management with Composer in the Drupal land. But there is a ~4 years old issue: Implement core management of 3rd-party FE libraries, from which we can see the efforts from the community.

Categories:

Axelerant Blog: A Complete Overview of Drupal Migration & More

Planet Drupal - Mon, 2020/12/21 - 2:59pm

With the launch of Drupal 9 in June 2020, the topic of Drupal migration is fresh on everyone’s mind. We will be delving deeper into the nitty-gritty around the topic in this blog. 

Migration is the process where the content from the old site, converted into the desired format and is saved in the new site. Sometimes, migration is a simple activity of mapping the source content to the destination content types and sometimes, it is a bit more complicated.

Let's take a comprehensive look at the Drupal migration process in context to the recently launched Drupal 9, and what’s involved in migrating from different versions. Here's what we will be discussing about:

01. Drupal 7, 8, and 9

02. Migrating Then and Now

03. Drupal to Drupal Migration

04. Migration from external sources

05. What’s More?

Categories:

Mediacurrent: Making the Business Case For a New CMS

Planet Drupal - Mon, 2020/12/21 - 2:46pm

Have you ever decided on investing in a product or service, but require approval from executive sponsors before proceeding with your purchase? Or do you like a product or service, but are hesitant to make the investment in it because it’s costly?

If either of these scenarios describes the situation you’re in, a business case is an excellent thinking tool that can help you with your decision.  A business case articulates the rationale for investing in a product or service in terms of numbers. It is often presented in a formal document, but may also be presented through more informal methods like a spreadsheet or even a single slide in a slide presentation. It further provides a way to make your case to nontechnical decision-makers without needing to provide the specific intricacies about the method or approach to your desired product or service’s implementation. 

To build a business case, perform the following steps: 

  1. Define the options to evaluate
  2. Determine the costs of each option
  3. Determine the benefits for each option
  4. Recommend an option based on cost and benefits

Let’s look at each of these steps more closely.

Defining Your Options

When evaluating a new product or service, you instantly are faced with two options: purchase the new product or service, or stay with what you have. In many cases,  decision-makers start with a bias toward the status quo because there is no cost in transitioning to new technology and the business process that goes along with it. Further, if a new product or service is being considered, its competing options should be considered as well, for example, if you’re considering Drupal as a web content management platform, consider WordPress too.

Let’s illustrate with an example. Say you have a proprietary, licensed legacy content management system (CMS) that is poorly performing and difficult to maintain. You and your company are no longer happy with it and want to make a change. Your budget is limited, so an open-source solution is more attractive because it carries no licensing fees. Drupal is certainly an attractive option, but as just stated, add WordPress as an option. This brings our options to the following:

  • Drupal
  • WordPress
  • Status quo CMS

In a real-world scenario, it’s good practice to consider more options than this, including evaluating proprietary options like Sitecore and Adobe Experience Manager. For the sake of simplicity, however, let’s limit our example to the ones we’ve listed. 

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are approximations only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the three options. These entail the licensing and build estimates for each option. This illustration assumes a simple implementation with little to no customization. Please note that these numbers are for illustrative purposes only. Real-world figures, driven by project requirements, will certainly differ.

Cost

Drupal

WordPress

Status Quo CMS

Initial License

$0

$0

$0 (already paid)

Build

$100,000

$50,000

$0

Total

$100,000

$50,000

$0

It comes as no surprise that the implementation cost of the status quo CMS is $0, because, after all, it has already been bought and configured. The licensing costs of all three options are $0 because Drupal and WordPress are open source offerings, and the license fee of the status quo CMS has already been paid. Had Adobe Experience Manager or Sitecore been considered, their license costs would be non-zero. In our example, we budget more for the Drupal build than that of WordPress because in our experience, with Drupal’s greater power and flexibility comes greater complexity, and that typically translates to greater investment in development hours. 

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs. To reiterate, these numbers are for illustrative purposes only. 

Cost/year

Drupal

WordPress

Status Quo CMS

Maintenance and Support

$20,000

$10,000

$50,000

Ongoing License

$0

$0

$10,000

Total

$20,000

$10,000

$60,000

Factoring ongoing costs makes it immediately apparent that the status quo CMS is costlier in the long term, both in maintenance hours spent and in annual licensing.  As with their initial implementation costs, Drupal’s ongoing costs are greater than those of WordPress because, again, of Drupal’s greater complexity.

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue (again,  just an illustration), the following table summarizes the benefits of each option. 

Benefit/year

Drupal

WordPress

Status Quo CMS

Annual revenue

$200,000

$150,000

$100,000

Finally, we see where the investment in Drupal’s complexity pays off; its greater functionality typically means a greater ability to meet ever-evolving needs. We translate this in our example to a greater annual revenue than that of WordPress, and both CMSs, being more functional than the status quo CMS, are capable of generating more revenue. 

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison:

The above graph makes the following assumptions:

  • In Year 1, the Drupal and WordPress options earn no revenue because they’re being built
  • Likewise the status quo CMS is earning revenue in Year 1 because it has already been built

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, staying with the status quo CMS is the best option.
  • If your organization is willing to make a moderate up-front investment for moderate long-term benefit, WordPress is the best choice.
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, then Drupal is the way to go.

Admittedly, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

Categories:

ADCI Solutions: The must-have Drupal module Social Sharing

Planet Drupal - Mon, 2020/12/21 - 8:44am

The majority of modules for social sharing of web pages - are Drupal blocks that have these social media integrated by default. You don't have a chance to officially add any social service that you want to your site. A back-end developer of the ADCI Solutions web studio talks about his fundamentally different module for social sharing of web pages. Its name is Social Sharing.

Visit the link for the full essay. 

Categories:

Nuvole: CMI 2 at DrupalCon Europe 2020

Planet Drupal - Mon, 2020/12/21 - 8:30am
Configuration management initiative update and recap of DrupalCon Europe 2020

Last week was the virtual DrupalCon Europe and I had the pleasure to present CMI 2 updates together with Moshe Weitzman. Attached to this post are the slides.

It was a strange DrupalCon, no travelling and home made food and good coffee are of course a nice change but I am not sure it makes up for not meeting Drupal friends in person. I enjoyed the hallway track and visited the "virtual booth" of sponsors and it was a nice way to randomly meet people like one would at a in-person event. But presenting a presentation to just the screen without seeing the audience was a new experience.

I presented the CMI updates under the overarching goal of standardising the way configuration management is approached in Drupal. After the big API addition last year we focused on updating contrib to use this new API. A particular highlight is the testing framework for modules upgrading from config filter to the new core API.

Another highlight is of course the new drush deploy command which Moshe presented. It executes the steps to update a drupal site where new code has been pulled. In particular it executes a database update, config import and running of deploy hooks.

Deploy hooks are the same as post_update hooks, but they are meant to be run after the configuration is imported. But instead of putting them in your mymodule.post_update.php you put the code in mymodule.deploy.php. They are not meant for contrib modules, but rather for custom code that a site relies on. For example it allows you to add content to fields that you created via config. More information can be found in the deploy hook documentation

Lastly I attended a very interesting BOF around distributions. I did not initiate it but I was very happy to observe the exchange of ideas and approaches between maintainers of different distributions. I hope more collaboration will happen next year in this space and hopefully more distributions join forces to find a way core can assist the development of distributions.

Tags: DrupalConDrupal PlanetDrushDrupal 8Attachments:  CMI 2 at DrupalCon Europe 2020
Categories:

Nuvole: CMI 2 at DrupalCon Europe 2020

Planet Drupal - Mon, 2020/12/21 - 8:30am
Configuration management initiative update and recap of DrupalCon Europe 2020

Last week was the virtual DrupalCon Europe and I had the pleasure to present CMI 2 updates together with Moshe Weitzman. Attached to this post are the slides.

It was a strange DrupalCon, no travelling and home made food and good coffee are of course a nice change but I am not sure it makes up for not meeting Drupal friends in person. I enjoyed the hallway track and visited the "virtual booth" of sponsors and it was a nice way to randomly meet people like one would at a in-person event. But presenting a presentation to just the screen without seeing the audience was a new experience.

I presented the CMI updates under the overarching goal of standardising the way configuration management is approached in Drupal. After the big API addition last year we focused on updating contrib to use this new API. A particular highlight is the testing framework for modules upgrading from config filter to the new core API.

Another highlight is of course the new drush deploy command which Moshe presented. It executes the steps to update a drupal site where new code has been pulled. In particular it executes a database update, config import and running of deploy hooks.

Deploy hooks are the same as post_update hooks, but they are meant to be run after the configuration is imported. But instead of putting them in your mymodule.post_update.php you put the code in mymodule.deploy.php. They are not meant for contrib modules, but rather for custom code that a site relies on. For example it allows you to add content to fields that you created via config. More information can be found in the deploy hook documentation

Lastly I attended a very interesting BOF around distributions. I did not initiate it but I was very happy to observe the exchange of ideas and approaches between maintainers of different distributions. I hope more collaboration will happen next year in this space and hopefully more distributions join forces to find a way core can assist the development of distributions.

Tags: DrupalConDrupal PlanetDrushDrupal 8Attachments:  CMI 2 at DrupalCon Europe 2020
Categories:

Brian Osborne: How Drupal's Dynamic Page Cache Delivers Extremely Fast 404 Pages

Planet Drupal - Sun, 2020/12/20 - 6:10pm

Lately I've been working to improve the response time of 404 pages on some Drupal 8 sites I help maintain. Depending on the complexity of the site and the status of Drupal's various cache layers, Drupal can be quite slow to generate a full page response, even for a 404 page. These sites I maintain are occasionally subjected to aggressive security penetration scans which generate a ton of 404 responses for completely unique URLs. The scanner can send tens of requests per second like this which can quickly exhaust the resources of a web server.

Categories:

Jacob Rockowitz: Ozzy, the puppy, vs. Drupal, the open-source project

Planet Drupal - Sun, 2020/12/20 - 3:43pm

Ralph

Last June, after comforting my family while being sickened with COVID and then locked down for a few months in NYC, my coworker, Ralph, passed away.

For the 20 years I have worked remotely, Ralph laid beneath my desk for almost all of them. When my days started creeping toward the 12-hour mark, Ralph was there, urging me to take a break, forcing me out the door. When his age and increasingly poor health meant Ralph could no longer go for long morning walks in the park, I started spending my morning hours building and maintaining the Webform module for Drupal 8.

Drupal time

For the past few years, I’ve had the privilege of making a significant contribution to Drupal. My work and life aligned to make it feasible for me to have the “free time” to build and maintain the Webform module for Drupal 8/9.

In this context, my “free time” is defined with regard to two significant aspects of my life - my work and my family. Over the years, I’ve budgeted a considerable amount of my free time spent to the Drupal community for no pay/at no cost.

The fact that my work in Drupal is mostly unpaid and consumes my “free time” is one of the biggest challenges for me to continue to sustain my contribution to Drupal.

The fact that my contribution to open source is unpaid means my family and work should come first and that my open source contributions have to take the back seat. Simply put, family always comes first, and earning money helps my family. In the current pandemic, it’s even more clear that we need to keep our family safe, and with its economic impact, we also need to keep our jobs. In 2021, I am most likely going to have to focus more of my energy on work.

Fortunately, before I started working some long days, my family just adopted Ozzy, the puppy.

Ozzy the puppy

Once I realized that I would have a puppy to take...Read More

Categories:

JD Does Development: A Docksal Training -- ON DEMAND!

Planet Drupal - Sat, 2020/12/19 - 1:49am
A Docksal Training -- ON DEMAND! jflynn Fri, 12/18/2020 - 18:49

It has been quite a while since I last posted anything, mainly because 2020 has been 2020 and I haven't been in the best mindset for several months. I've had a lot of difficulty focusing on anything, and as a result, I've found my motivation has gone pretty much away.

However, last month I decided that lack of motivation be damned. I spent quite a bit of time converting a training that I had prepped to give at camps and conferences into a YouTube video series. This is a 12 lesson series that takes the viewer from a brief intro to Docker all the way up to building a custom Docksal application that combines 2 servers with a NodeJS backend and a PHP backend to simulate a production decoupled web application setup.

Here is a quick rundown of the videos and what you might expect from each:

Part 1 - Intro and Docker Basics

The first video is a starting point for someone who may or may not have much experience with Docker. I wouldn't recommend learning React without knowing some JavaScript, so I can't recommend using Docksal without having a bit of an understanding of Docker. 

Part 2 - The Gush

This second part is basically where I fanboy about Docksal and why I think it's great.  If you want to hear me ranting about the benefits of Docksal and everything it brings to the party, this is your clip!

Part 3 - Docksal Stacks

Docksal uses .yml files that define various stacks. Stacks are collections of services that make up an application. If you want to learn more, stop reading and check out the video!

Part 4 - Docksal Services

Remember way back under the last video when I used the word "services"? I remember. This video goes into what services are available to make up the stacks that are preconfigured or that you build on your own.

Part 5 -Getting Started with Docksal

 Yeah, I know... 5 videos in is a long time to wait for a "Getting Started" vid, but the wait is worth it. Get your editors ready, roll up your sleeves, and get learning!

Part 6 - Using a Boilerplate

It's not just for warming the kettle anymore! A boilerplate is a ready-to-go application that you just need to start and it works. In part 6 we're going to look at spinning up a project with one of these boilerplates.

Part 7 - Installing a Drupal Site

This is what we've been working up to. This video will show you how to use Docksal to install and run a brand new Drupal site on your local machine. It takes less time than you think!

Part 8 - Doing More with Docksal and Drupal

 Let's take it to 11. This tutorial goes over some of the ways we can further customize a local site, going so far as making the local Docksal environment actually mirror our hosting platform!

Parts 9, 10, 11 - Advanced Customization Projects

 

Each of these gets a little more in-depth with the customizations and they build off the previous for the most part.  I had a lot of fun coming up with Project 3.  What do you think?

Part 12 - Local Files

 Let's call this one a bit of housekeeping. It doesn't matter what you use Docksal for if you end up committing your API keys to a public repo. (Don't do that!) This one goes over how to use local Docksal files to keep your safe, secret info safe and secret.  

Conclusion

This is my first attempt at instructional videos, but hopefully not my last.  I'll be posting stuff as I can when I have time, but I'd really like to know what you all would like to see me cover. Feel free to comment on one of the videos above, on this post, on Twitter, or wherever else I might see it. Be sure to subscribe to my channel JDDoesDev on YouTube to get notified when I put new stuff up.  Until then, you're my favorite person.

Category Development Tags Docksal Drupal Drupal Planet Comments
Categories:

Drupal Association blog: Drupal Business Survey 2020: Drupal businesses experience opportunities, challenges and turning points in an extraordinary year

Planet Drupal - Fri, 2020/12/18 - 9:23pm

What is the vision of Drupal business leaders all around the world on Drupal in 2020? For the fifth year in a row Drupal agencies One Shoe and Exove, together with the Drupal Association, investigated how Drupal company leaders experience the current Drupal business ecosystem. Of course, the year 2020 is marked by the effects of the coronavirus but there’s much more to say about doing Drupal business.

Characteristics of the participants

This year, 83 people participated in the Drupal Business Survey. Out of all the participants, nearly 70 % had a CEO/CTO/COO role in their company. Other roles represented in this survey are mainly founders (15.7%), and Directors (7,2%). 

A majority of the Drupal centric businesses that participated in the survey are located in Europe (49,5%). The rest is located in:

  • North America (33%)
  • South America (3,7%)
  • Asia (12,8%) 
  • Africa (3,7%)

Almost half of the respondents were digital agencies, 20,5% software companies and 18,1% consulting agencies. As we can see from the graph below, most of the respondents are small to midsize companies. The majority of the companies that participated in the survey have been in business for over 8 years. Nearly 40% of all the respondents have been in business for over 14 years. 

We could therefore say that the opinions and experiences of people in this survey are based on years of experience with Drupal business!


Covid-19 impacts Drupal businesses in various ways

As this year comes to a close, we can only conclude that 2020 turned out differently than expected. It brought company leaders new challenges and opportunities. Generally, we can conclude (for now) that the impact of COVID-19 may be less than initially anticipated and entrepreneurs keep doing excellent Drupal business.

In the survey we asked Drupal agency leaders about their challenges and successes of this year. Many participants cited the coronavirus and its consequences as their top challenge: 

15% of the respondents named 'Covid-19 in general' as the main challenge without further explanation. To provide more detailed information, we have broken down the answers that provide better insight into the impact of the coronavirus on businesses:

  • Covid-19 affecting client projects (13%)

In some cases, the coronavirus outbreak has had an impact on clients and their projects. One leader tells us in the survey: “[Our biggest challenge this year was] covid and seeing a couple of our sectors getting hammered. Seeing projects put on the shelf, cancelled, etc“ But it does not always lead to this. Another participant tells: “We experience uncertainty around some client's future budgets. This has not resulted in any major reductions though.”

  • Covid-19 forces remote working (10%)

Working remotely is, and remains, a major challenge for a lot of companies. “Moving to 100% remote after the pandemic [was the biggest challenge]”. Someone else mentions “remote selling” specifically as a challenge. 

  • Covid-19 affecting (mental) health of employees (8.8%)

It won’t be surprising that another big challenge was “Staff falling ill with covid and/or having children at home so staff is pressured and unable to work”. It’s worth mentioning, though, that many company leaders indicate that covid-19 has a great impact on the mental well-being of their staff but at the same time they are very proud of their team. “We have kept our team together during the covid storm” says one leader in response to the question what their greatest success of the last 12 months is. Another one said: “[Our greatest success is] Outstanding leadership from the senior technical team members (non-exec level).” “Maintaining high morale and supportive culture” someone else adds. 

Many Drupal businesses do thrive in 2020

Doing Drupal business in 2020 is not only about facing challenges - not at all. 
Many participants told us their companies thrived even despite (or due to) the effects of the coronavirus. 

20% of the answers when asked about greatest success are about thriving despite Covid-19:
“We make it through the COVID months relatively well financially after pivoting to clients who luckily benefited from COVID (increased business).” Another agency leader adds: “[Our greatest success is] navigating my company successfully through a world pandemic with results that exceed the pre-covid prognosis!”.

The pandemic as a catalyst for investments in digital

What’s the success factor of these kinds of Drupal companies? Based on people’s comments, it seems there is a rapid digital adoption driven by covid-19: “[We see] increased demand due to companies going more digital during the pandemic”. Another one tells: “We launched a covid-19 site for a major healthcare client.” And: “We've won our biggest Drupal contract ever. We successfully launched our largest ever project despite coinciding with the early days of lockdown. We are educating our clients that the pandemic should be seen as a catalyst for investment in digital.”  

Another big success is launching successful Drupal projects (20%), such as: “We launched a big popular Drupal site (8.x) for German Government with integration (backend) of services” and “We have been building bigger and more complex websites with Drupal.” 

These findings correlate directly with the answers to the questions about the project pipeline, deal size, and win rate.

In the graph above you can see that Drupal project deal size has grown more in comparison with project pipeline or win rates. One business leader explains why: “We choose clients more carefully, because of that average deal size has grown significantly. On the other hand due to the more aggressive competitors sales, we have lost quite many large deals.” What this shift could mean for the future according to one respondent? “The traditional smaller scale Drupal projects are dwindling, of less value. The future is in large scale projects where Drupal is a component of a larger architecture.” Another one mentions the public sector as a profitable one: “Drupal has been "in vogue" in our market right now, especially in the public sector. We see a lot more RFQs compared to last year, and a lot of them are quite sizable.”

The project deal size growth is a very positive indicator and well in line with the Drupal’s growth to the enterprise market. As a part of the sales cost is always fixed and not dependent on the size of the deal, this will lead to bigger margins that will help the companies to develop themselves further.

Expectations for growth from 2021 onwards

The outlook for 2021 and onwards looks positive based on the survey answers. Despite the situation with COVID-19, almost half of the companies expect their business and on-going project situation to improve in the near future.

Only around 20% of the companies expect the situation to weaken in the forthcoming months, and only a fraction of them significantly. This resonates well with the earlier findings of the pandemia accelerating the need for digital services. Drupal being a versatile and flexible platform is gettings its fair share of the positive market development.

Profitable Drupal industries

So, Drupal business is still doing quite well. But in which industries? Each year the Drupal Business Survey asks respondents in which industries their company operates. This is the top 10 of 2020:

The most popular industry for Drupal projects is the same as in 2019: the Educational sector. With 61,4% this is the sector with the most Drupal projects. It should be noted that “Education” was added to the survey in 2019 and thus 2017 and 2018 show it blank. This is followed by Charities & Non-Profit (55.4%) and Government & Public Administration (50.6%). 

However, if you compare all the industries over the years, the number of Drupal projects in the Charities & Non Profit decreased significantly. This also counts for the Arts & Culture industry. The Drupal platform is evolving towards the higher end of the spectrum with each release adding new sophisticated features. This causes the project sizes to grow which explains the drop in industries that cannot invest heavily on digital platforms. Also, Arts & Culture has been hit by coronavirus this year.

Reasons for clients to choose Drupal, or not

Why is Drupal so often chosen for digital projects? When clients have previously worked with Drupal, they often choose the framework again (60% of the answers). It showcases the fact that Drupal is a good tool for solving their business problems.

It also appears that the consultancy role of the agency is significant in determining the client's choice of technology. In more than half of the answers given in the survey, the client follows the advice of the agency for choosing Drupal. Other major selling points for Drupal are its open source character, flexibility and security. 


The main reasons for clients not choosing Drupal are consistent with last year's survey - the same underlying issues still remain today. Main reasons for potential clients choosing other platforms instead of Drupal are: 

  1. Price. For example, prices can increase significantly because Drupal is used at the higher end of the CMS spectrum, and thus development is time consuming and therefore expensive. As one respondent said “Drupal practitioners can handle more complex problems, so they're more expensive”.
  2. Complexity. Wordpress is seen as more user friendly and easier to approach. 
  3. Familiarity. Potential clients don’t seem to know much about Drupal which makes it harder to sell.

Knowing why potential clients are choosing other platforms is key in further developing Drupal and meeting client needs. Reviewing the existing target audience and marketing Drupal for the right audiences, might be things to consider to tackle these obstacles.

Conclusion

One thing is certain: companies - both Drupal agencies and clients - have to adjust their strategy because of covid-19. But looking at the answers given in this study, it appears that Drupal projects are getting bigger and Drupal businesses are growing - provided they operate in the right industries and succeed in working remote. Or, as a Drupal agency leader puts it, "Despite the covid epidemic, we have managed to work together and increase transparency in the business - we are now in many ways better than March." And who knows, the effects of covid-19 may as well accelerate the demand for digital projects.

Categories:

Mediacurrent: Introducing Rain CMS for Drupal 9!

Planet Drupal - Fri, 2020/12/18 - 2:25pm

The Mediacurrent team is proud to introduce the latest version of our open source Rain CMS, now for Drupal 9. The latest version ships (currently in beta) with a brand new theme and admin experience. Make your move to Drupal 9 with speed and confidence. 

The New 'Nimbus' Theme


 

New Rain CMS theme homepage

The new base theme comes with a full Pattern Lab style guide to make development easier using a component-based theming approach. The new Rain CMS theme also adds color module support for in-browser color configuration. We wanted a great out-of-box experience for content authors and administrators so we pre-load the site with sample content to make it simple to get started.

Rain Admin 2.0

Rain CMS admin content edit page

With the latest version of Rain Admin, the content editing experience is more intuitive to use. A jump-navigation on the right hand side helped authors navigation different sections of the page. The UX for Paragraphs has also been improved to make it visually easier to manage components on the page.

Let’s Get Started

For developers, you can download and install Rain CMS 9 using our Drupal project template. Setup and installation remain the same as our previous version, with detailed instructions provided in the project README file.

For more information on the benefits of Rain CMS D9 and to schedule a free demo, please visit our contact page or chat with us right now (see bottom right corner of the page). We would be happy to talk more about your project or schedule a demonstration.

Categories:

Mobomo: A Look at Drupal’s New Layout Builder

Planet Drupal - Thu, 2020/12/17 - 7:40pm

Recently, Drupal has been on an update rampage. The introduction of the oh-so-beautiful Drupal 9 core has spurred a chain reaction of upgrades across the Drupal platform. Just this week, we’re getting a new default theme (which is hyper-minimalist and easy-on-the-eyes), a 20% reduction in install times, and automated lazy load for images. But let’s talk about the juiciest UI/UX update that came with Drupal 9 — the standardization of Drupal’s Layout Builder.

If you’ve built a pre-Drupal-9 website over the past few years, you probably dabbled with Panels/Panelizer, WYSIWYG templates, or even custom coding to set up your UX/UI. And that works. We did it for years. But you can throw that worn-out Panelizer module in the trash. The times, they are a-changing. Drupal’s new Layout Builder module combines the core functionality of Panelizer with an out-of-the-box WYSIWYG engine.

First hinted at in 2017, Drupal Layout Builder officially left the onerous Drupal testing pipeline last year as part of Drupal’s 8.7 updates. Despite circulating for a year now, the chaos of 2020 has overshadowed this potent and flexible tool. So, let’s talk about it. Here’s what you need to know about Drupal’s Layout Builder.

What is Layout Builder?

Layout Builder is a WYSIWYG page editing engine that lets you manipulate back-end features via an easy-to-use drag-and-drop interface. It’s difficult to overstate just how valuable Layout Builder is when it comes to time-savings. You can create templates in minutes, immediately preview and create content changes, and tweak page-by-page UI/UX features to create more cohesive and on-the-fly websites and landing pages.

At its core, Layout Builder is a block-based layout builder. You can create layouts for either a single page or all content of a specific type. In addition, you can jump in and create rapid-fire landing pages based on your existing design theme. There are three “layers” that Layout Builder operates on to help you build out holistic websites.

  1. Layout templates: You can create a layout template for all content of a specific type. For example, you can make a layout template for your blog posts or a layout template for every product page. This template will be shared across all pages, so you don’t have to go in and rebuild for each content type.
  2. Customized layout templates: You can also go in and make granular changes to a specific layout template. So, if you want a certain product page to be different than the layout template, you can make granular changes to just that page.
  3. Landing pages: Finally, you can create one-off pages that aren’t tied to structured content — like landing pages.

Important: Founder of Drupal — Dries Buytaert — dropped a blog post with some use cases for each of these layers.

To be clear, Layout Builder isn’t a WYSIWYG template. It uses your existing template. Instead, it allows non-developers (and lazy-feeling developers) to quickly make per-page changes to the website without diving into code. But these aren’t just simple changes. You can create a layout template for every page type (e.g., creating a specific layout for all the shoes you sell), and you can also dive into each of these layout pages to make custom changes. So, it really lets you get granular with your editing without forcing you to completely retool and redesign pages for each type of content. This gives Layout Builder a massive advantage over WordPress’s Gutenberg — which requires you to go in and re-lay elements for every page individually.

Here’s the kicker: you get a live-preview of all changes without bouncing between the layout and the front-end. Every block and field you place and every change you make to taxonomies or content is visible the second you make the change. The entire process takes place on the front-end, and changes are instantly visible. Remember, Layout Builder is part of Drupal’s Core, so you don’t need to implement new entity types of dig into third-party elements. It’s an out-of-the-box experience.

Advantages of Layout Builder

Last year, we got a gorgeous, picture-perfect demo of how Layout Builder would work. It’s beautiful, fast, and packs a punch that other leading layout builders are indeed missing. So, to help unpack the value of Layout Builder, let’s look at some of the advantages of Layout Builder:

Customization

Beyond Layout Builder’s incredibly powerful and customizable block-based design engine, it offers customization in usage. Let’s say you want to create an amazing landing page. You can start with a blank page that’s untied to structured content, drop in some hero images, a few pieces of text, some content, and a video. Suddenly, you have a custom landing page (complete with modules, blocks, and taxonomy) that exists in a separate ecosystem from your website.

Simultaneously, you can create a template for every blog post, then dive into a specific blog post and make on-time changes to just that page while still being tied to your structured content. Remember, you can make these changes nearly instantly, without touching code. And you’ll see a live preview of every change immediately without switching between interfaces.

Accessibility

Drupal is committed to accessibility. The second principle of Drupal’s Values & Principles page reads, “build software everyone can use,” and this rings true. Layout Builder meets Drupal’s accessibility gate standards (i.e., conforms to WCAG 2.0 and ATAG 2.0, text color has sufficient contrast, JavaScript is keyboard-usable, etc.)

Ease-of-use

Like many WYSIWYG editors, Drupal Layout Builder is all about “blocks.” But these aren’t your run-of-the-mill blocks. There are inline blocks, field blocks, global blocks, and system blocks. Each of these has its own use case, and you can combine these block types to create stellar pages in minutes. For example, global blocks are used to create templates, and inline blocks are used to create page-specific changes that don’t impact the layout. The combination of these block types makes Layout Builder a hassle-free experience.

Additionally, there are plenty of ease-of-use features built into the core. Layout Builder works with the keyboard, has plenty of usability features that tie to Drupal’s value statements, and allows nit-picky setups for customized workflows.

Creating a Drupal Website is Easier Than Ever

With Layout Builder, users can generate valuable content and pages without needing to patch together various WYSIWYG tools or Panel/Panelizer. At Mobomo, we’re incredibly excited for our clients to dive into Drupal Layout Builder and make actionable and memorable changes to their templates based on their in-the-moment needs and experiences.

But Layout Builder isn’t a replacement for a well-designed and well-developed website. We can help you build your next world-class website. Once we’re done, Layout Builder gives you the freedom to make substantial changes without the headaches, back-and-forth, or unnecessary touchpoints. Are you ready to create a customer-centric, experience-driven digital space? Contact us.

The post A Look at Drupal’s New Layout Builder appeared first on .

Categories:

Acro Media: Outgrowing Shopify: What Are The Signs? | Acro Media

Planet Drupal - Thu, 2020/12/17 - 4:00pm

You started your ecommerce site with Shopify, and you obviously did it right, because you are continually seeing growth. That’s fantastic! But you are starting to see areas where you are outgrowing Shopify. What are the signs you should be looking for to make sure that your business keeps growing and not be held back by your ecommerce platform?

Seven areas to look at if you think you are outgrowing Shopify:

In this blog, we will take a look at a few things you can do if you think you are starting to outgrow Shopify.

Look at your swivel chair processes.

Are you spending too much time every month manually inputting information into your CRM, ERP or inventory systems because there either isn’t an integration available for Shopify or it is not functional? Is there a platform that can automate some of those processes? The time you save can then be put back into important business tasks for strategic growth.

Look at all the 3rd party integrations your site needs.

Or will need to integrate with vendors to keep your ecommerce machine rolling. These integrations should enable you to more securely accept payments, provide more buying and delivery options for your customers, and more. Find an ecommerce platform that easily accepts these kinds of integrations and are securely developed so that you don’t wind up with a liability down the road.

Look at your user experience and how you want your brand to be perceived.

Does your site look and feel like the brand you want it to represent? Is there something missing that the Shopify themes are just not giving you? Does your brand stand out from the rest of the Shopify templated storefronts? Will you be able to make effective changes within the restrictions of Shopify’s templates?

Look at your analytics.

Are you getting the reporting you need? Limited reporting makes it hard to develop a long-term business strategy. Better reporting means better decisions and more growth.

Look at the costs of “renting” Shopify’s platform.

Adding plugins to your base Software as a service (SAAS) platform to add customer-friendly and value-add features come with a price. The costs of those modules add up and could seriously be eating away at your bottom line every month. Consider the long-term advantage of owning your ecommerce website by creating it with an open source platform like Drupal and Drupal Commerce.

Look at your data.

Did you know that your Shopify store is generating a ton of data, but that you don’t own it? Shopify ties up your data, known as service lock-in, so that transferring your data becomes a cumbersome process, especially if you have a lot of it.

Look at the effectiveness of your CMS.

Shopify is not meant to be a content management system, so when it comes to adding videos and rich media, linking pages with products, and managing large amounts of content like a blog, your customer engagement and SEO. Shopify can make it hard at times to properly implement search engine optimization (SEO) tactics that would contribute to your growth.

For small to medium-sized businesses, Shopify is the best in class for ease of getting online, standardization and generally doing the basics in ecommerce.

As your business grows you may quickly learn that the things that made Shopify so attractive in the first place are the elements that are holding you back. If you have taken the time to really look at the above items and find that Shopify still meets your needs, then great.

If you are in a position where you feel that you may be starting to outgrow your ecommerce platform, the sooner you start looking at other options, the better. Making changes away from a standardized platform will get more complicated the more and more data, plugins and services you add to your current site.

Does all of this information leave you feeling a little overwhelmed? Don’t worry, we get it.

For something as crucial as your ecommerce platform, you want to make sure you are doing the right thing. That is where we come in. We live and breathe this stuff. Our ecommerce consultants and subject matter experts are open source commerce pros and are always happy to give as much advice as you need. Reach out today and let’s talk about what your next ecommerce platform should be after Shopify.

Categories: