Planet Drupal

Debug Academy: Would you rather: Early or late adopter of Drupal?

6 hours 56 minutes ago
Would you rather: Early or late adopter of Drupal?

What are the pros & cons of being an early adopter of a framework?

This can be a loaded question due to misaligned incentives. Projects need early adoption to be successful.

But what is best for your career and/or project? Let's discuss it honestly.

When is "early"?

In the context of software, "early adoption" has multiple meanings.

For the sake of this conversation, "early" specifically means at least one of the following is true:

  1. The software is not yet widely used (not many case studies)
  2. Best practices have not yet been established
  3. The software has not stabilized (alpha, beta, sometimes 1.0)

It's not always clear whether using software is early.

Let me give a few examples, one of which may be counter-intuitive:

ashrafabed Mon, 09/20/2021

Drupal Association blog: Meet one of our 2021 Discover Drupal Students, Abokar Botan

2 days 13 hours ago

The Discover Drupal 2021 recently began the next phase of their journey. This year we have eight students. After completing their prerequisite course in July, they have all started the course for their chosen pathway.  Each month we introduce a student, and this month, we welcome Abokar Botan!

Abokar was referred to the program by Genesys Works and is entirely new to Drupal. He currently resides in Minnesota.

Tell us a little about you. What are your hobbies and interests? My name is Abokar. I am majoring in computer science. One of my hobbies is coding. My interest is to become a Software Engineer.

What is your ultimate goal in learning Drupal? My ultimate goal is to learn front-end development.

What are you most excited about regarding this program? My most exciting thing in this program is having a mentor who listens to all your ideas and gives you great advice.

If you see Abokar online in Drupal Slack or at any upcoming Drupal events, please give him a warm welcome. His Slack user name is Abokar Botan.

Thank you to our Partners and Sponsors

We want to thank our founding partner, Kanopi Studios and especially Allison Manley for her hard work and dedication to the program. We also want to thank our platinum sponsors: Lullabot and Elevated Third for the financial support that has been instrumental in launching this program. Finally thank you to our excellent training partners, Drupal Easy, Evolving Web, Mediacurrent, and Drupalize.me.

If you’d like more information about the program or would like to become a supporting donor, please reach out to us a drupaltalent@association.drupal.org

File attachments:  IMG_2464 - ThinkFree Shopping.jpg

Nonprofit Drupal posts: September Drupal for Nonprofits Chat: Project Browser Initiative

2 days 14 hours ago

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

This month we'll be chatting about the Project Browser Initiative and anything else that might be on your minds at the intersection of Drupal and nonprofits. 

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

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

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

View notes of previous months' calls.

Specbee: An Easy Step-by-Step Guide to Writing Your Own Custom Drush 9 (and 10) Commands

2 days 16 hours ago
An Easy Step-by-Step Guide to Writing Your Own Custom Drush 9 (and 10) Commands Santhosh Kumar 16 Sep, 2021 Top 10 best practices for designing a perfect UX for your mobile app

If you’re a Drupal professional, Drush needs no introduction. But if you’re just starting out as a Drupal developer or keen on learning about Drupal, you should know that Drush is something you just CANNOT ignore. Short for “Drupal + Shell”, Drush is a Command Line Interface (CLI) tool made exclusively for Drupal. With Drush, you can set up new Drupal websites quickly and easily work with the Drupal installations. It helps you streamline your development and administrative tasks thus improving your productivity.

Drush 9 and Drush 10 core comes shipped with tons of helpful commands that helps you interact with themes, modules, profiles, etc. Some useful commands include – SQL commands, exporting or importing configurations, updates, migrations, cron or clear cache, and much more. It is also extremely extensible, in that you can create your own custom commands. In this article, you will find more information about how to create custom Drush 9 and 10 commands in an easy step-by-step process. 

Note: Drupal 8.4 and higher support Drush 9, while Drupal 8.8 and above support Drush 10.

Drush and Drupal Console

Although Drush and Drupal Console are both super useful CLI tools that make developers’ work easier, they are often used in different scenarios. With Drupal Console being the most recent addition to the Drupal world, it is a very useful tool for new developers to cope up with Drupal’s infamous learning curve. However, our take would be to use both Drush and Drupal Console as when put together they can do so much more in speeding up development and boosting productivity. 

While Drupal Console lets you create custom modules, services, entities, boilerplate content, debugging and more, Drush lets you perform more basic but foundational tasks. These tasks include installing Drupal, interacting with the installation, exporting and importing configurations, download and update contributed modules, Caching, update the database, run cron jobs and much more. For more details on each of their features, please refer to this guide.

When would we need to Create Custom Drush commands?

Although there are many Drush 9 commands that are ready to use for various functionalities, there are always times when they’re not adequate. We create custom Drush commands for many database related processes like entity field value updates, DB updates, importing or exporting data to and from Drupal, and other bulk processes. Also, when we have secure methods to be called, we can opt for Drush command implementation. 

How to Create a Custom Drush Command

The previous versions of Drush the implementation of Drush custom code followed different models. It was based on the hook_drush_command() and made use of .inc files.

In Drush 9, we will no longer use the .inc files or the hook_drush_command(). Drush commands will now be based on Annotated command format. This changed the fundamental structure of custom Drush commands.

Step 1: Create a module

Create a .info.yml file

  Step 2: Create a service using services.yml

Create a .services.yml file

  Step 3: Create a Drush service class

Now let’s extend the DrushCommands base class.

 

Path to the class file should be: 

/src/Commands/BatchCommands.php

 

Under this class, each method can be a command function if it is properly annotated.

Step 4: Create annotated methods

 

Here are a few of the common annotated commands:

@option 
@usage 
@command 
@param 
@process
@aliases 
@status
@extract

Step 5: Clear cache

Now let’s clear the cache to flush all caches with this command:

drush cr

Start using the new custom command you just created:

drush custom-message

 

Note: Multiple options added, as options is an array value.

The implementation of custom Drush commands will be useful in various scenarios like to run secure methods and bulk processes which exceed normal Drupal execution time and memory. For more complex and heavy processes, integrate Drupal batch API in the Drush command and execute it. If you found this useful, consider signing up to our newsletter to have our regular articles get delivered straight to your inbox.

Looking for assistance in building compelling Drupal websites that can deliver successful results? Get in touch with our Drupal experts today!

Drupal Drupal Development Drupal Module Drupal Tutorial Drupal 9 Drupal Planet Shefali ShettyApr 05, 2017 Subscribe to our Newsletter Now Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image An Easy Step-by-Step Guide to Writing Your Own Custom Drush 9 (and 10) Commands Image How Drupal Empowers Nonprofits in Achieving their Mission Image Content Personalization Made Easy with Drupal Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

A Drupal powered multi-site, multi-lingual platform to enable a unified user experience at SEMI.

link

Discover how our technology enabled UX Magazine to cater to their massive audience and launch outreach programs.

link

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

link

Droptica: Drupal 8 vs Drupal 9. Is it Time to Upgrade?

2 days 17 hours ago

The Drupal system can be classified as one of the safest CMSs on the market. It has a refined structure and a wide range of functions. In this text, we'll take a look at Drupal 8 first. We'll remind you when it was released and what changes it brought when compared to the previous versions. Next, we'll take a closer look at Drupal 9 and then compare both versions.

Drupal releases

Drupal 8 was released on 19 November 2015. Compared to the previous version, that is – Drupal 7, there were as many as 200 new built-in functions, the multilingualism of the platform was improved and, for example, the new page editor and the version for mobile pages were introduced (as a built-in function – no additional domain for the mobile version is required). In terms of differences from the previous version, we can also add the fact that Drupal 8 uses object-oriented programming, instead of the procedural approach used in the previous version. The new version of Drupal uses a different theme engine – Twig, which is based on PHP. This makes it easier for programmers creating new themes because of the simpler syntax.

Another additional feature in Drupal 8 is the ability to edit the content directly from the site's user interface. It's also worth mentioning that the newer version of Drupal has access to the views directly from several administration screens. There's no need to spend additional time on it anymore, as was the case with Drupal 7. Looking from the perspective of a person viewing the page, we can also notice that the page loading speed has significantly increased thanks to entity caching. In addition, the previously viewed content doesn't need to be reloaded because it remains in the system cache. Also, the JavaScript code isn't loaded until it's necessary. After updating Drupal to version 8, you should also pay attention to the new types of fields that can significantly simplify the work for programmers.

What's the difference between Drupal 8 and Drupal 9?

Drupal 9 was released on 3 June 2020. It was built on version 8, so the changelog is shorter and the update from version 8 to 9 is simpler. The most important differences are the removal of almost all deprecated functions. In version 9, they've been replaced by other ones, and those that remained will be removed in the next installment of Drupal. A list of deprecated functions is available at Drupal.org.

Also new in version 9 is the next version of Symfony. Drupal 8 used version 3, but now it's version 4. Additionally, the Twig theme engine version has been updated – has been changed from version 1 to 2. Another difference between Drupal 8 vs 9 is the fact that most of the jQuery UI library dependencies have been removed. In the case of performing tests, in the new version, we rely on the PHPUnit solution (previously, the SimpleTest framework could be used).

The next thing that was almost completely removed in Drupal 9 is the Simple Annotation Parser from Doctrine. However, the required elements were incorporated into the Drupal 9 core. We also need to pay attention to the Apache version, because in the case of Drupal 8 version 2.x was enough, but currently, Drupal 9 requires a min. version of 2.4.7. The situation is similar with PHP – this time a min. version of 7.3 is required, but version 7.4 and 8.0 are also supported (applies to Drupal 9.1.0). In terms of the database and the use of MySQL/Percona, Drupal 9 requires a min. version of 5.7.8; Drupal 8 worked with version 5.5.3. The same goes for using MariaDB and SQLite. These need to be min. versions of 10.3.7 and 3.26 respectively. The previous version of Drupal used version 5.5.20 for MariaDB and 3.6.8+ for SQLite.

Performance

According to the above description of the differences between Drupal 8 vs 9, we can certainly say that the newer CMS release is much better in terms of speed. Using a min. PHP version of 7.3 improved the page loading speed. We can see an example on the PHP Benchmarks page, where all PHP versions are listed – from 5.6 to 8.0. At the very first glance, we can already see that between Drupal 8 and 9 there was an increase in performance of over 10%. This is the perfect reason to consider an upgrade, as each new version of PHP causes an even bigger leap in performance.

The situation is similar with Symfony. Version 3 has been used so far, but Drupal 9 needs the newer, fourth version of the framework. Thanks to it, we can significantly reduce the working time the developers need to create a new module or improve an existing one. The results of comparing Symfony versions from 2 to 5 can be checked on the already mentioned PHP Benchmarks page.

 

Another point that we can refer to in the context of the performance comparison is the Twig version used. In the case of Drupal 9, the theme engine is about 15% faster than the one used in Drupal 8.

 

You may also be interested in: Why Drupal Is The Best Headless CMS?

Drupal 8 to Drupal 9 – upgrade

Upgrading Drupal 8 to Drupal 9 is much simpler and less time-consuming compared to the transition from version 7 to version 8. First, we need to verify that we are using the latest version of Drupal 8. It should also be noted that soon (November 2021) support for the older, eighth version of the described CMS will end, so soon we should carefully think over the update process and prepare for updating Drupal.

Once we are sure that we have the latest version of Drupal 8, we can start by updating all modules and skins. In this case, we also need to have their latest versions. At this step, we'll see that most of the modules already support Drupal 9. Next, it's worth using the tool provided by the authors of this CMS to prepare a checklist of things that need to be prepared, so that the update goes smoothly and without complications.

One of the last steps will be to check whether the server on which we plan to install Drupal 9 meets the requirements for PHP, Apache, and database engine versions. We've described the required versions in the previous paragraphs. At this point, we're one step away from using Drupal 9. It only takes a few clicks and some time to go through the entire update process.

Drupal 8 vs Drupal 9 – summary

Due to the upcoming end of support for Drupal 8, the significant increase in system performance, and the relatively simple means of updating to the latest version, we recommend that you complete this process as soon as possible. Thanks to this, you'll avoid any problems after support has ended and complications in the event of updating "real quick" in an environment that's not adapted to this. It's worth planning this process from start to finish and enjoy the much greater transparency of the code and the new possibilities offered by Drupal 9.

If you don't know how to properly update to the latest version, our experienced Drupal support team will be happy to help you.

Security advisories: Drupal core - Moderately critical - Access Bypass - SA-CORE-2021-010

3 days 13 hours ago
Project: Drupal coreDate: 2021-September-15Security risk: Moderately critical 12∕25 AC:Basic/A:None/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Access BypassCVE IDs: CVE-2020-13677Description: 

Under some circumstances, the Drupal core JSON:API module does not properly restrict access to certain content, which may result in unintended access bypass.

Sites that do not have the JSON:API module enabled are not affected.

This advisory is not covered by Drupal Steward.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core does not include the JSON:API module and therefore is not affected.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Access bypass - SA-CORE-2021-009

3 days 13 hours ago
Project: Drupal coreDate: 2021-September-15Security risk: Moderately critical 10∕25 AC:Basic/A:User/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Access bypassCVE IDs: CVE-2020-13676Description: 

The QuickEdit module does not properly check access to fields in some circumstances, which can lead to unintended disclosure of field data.

Sites are only affected if the QuickEdit module (which comes with the Standard profile) is installed.

This advisory is not covered by Drupal Steward.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core does not include the QuickEdit module and therefore is not affected.

Uninstalling the QuickEdit module will also mitigate the vulnerability. Site owners may wish to consider this option as the QuickEdit module will be removed from core in Drupal 10.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Access bypass - SA-CORE-2021-008

3 days 13 hours ago
Project: Drupal coreDate: 2021-September-15Security risk: Moderately critical 11∕25 AC:Basic/A:None/CI:None/II:Some/E:Theoretical/TD:UncommonVulnerability: Access bypassCVE IDs: CVE-2020-13675Description: 

Drupal's JSON:API and REST/File modules allow file uploads through their HTTP APIs. The modules do not correctly run all file validation, which causes an access bypass vulnerability. An attacker might be able to upload files that bypass the file validation process implemented by modules on the site.

This vulnerability is mitigated by three factors:

  1. The JSON:API or REST File upload modules must be enabled on the site.
  2. An attacker must have access to a file upload via JSON:API or REST.
  3. The site must employ a file validation module.

This advisory is not covered by Drupal Steward.

Also see GraphQL - Moderately critical - Access bypass - SA-CONTRIB-2021-029 which addresses a similar vulnerability for that module.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core is not affected.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Cross Site Request Forgery - SA-CORE-2021-007

3 days 13 hours ago
Project: Drupal coreDate: 2021-September-15Security risk: Moderately critical 14∕25 AC:Complex/A:None/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross Site Request ForgeryCVE IDs: CVE-2020-13674Description: 

The QuickEdit module does not properly validate access to routes, which could allow cross-site request forgery under some circumstances and lead to possible data integrity issues.

Sites are only affected if the QuickEdit module (which comes with the Standard profile) is installed. Removing the "access in-place editing" permission from untrusted users will not fully mitigate the vulnerability.

This advisory is not covered by Drupal Steward.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core does not include the QuickEdit module and therefore is not affected.

Uninstalling the QuickEdit module will also mitigate the vulnerability. Site owners may wish to consider this option as the QuickEdit module will be removed from core in Drupal 10.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Cross Site Request Forgery - SA-CORE-2021-006

3 days 13 hours ago
Project: Drupal coreDate: 2021-September-15Security risk: Moderately critical 10∕25 AC:Basic/A:User/CI:None/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross Site Request ForgeryCVE IDs: CVE-2020-13673Description: 

The Drupal core Media module allows embedding internal and external media in content fields. In certain circumstances, the filter could allow an unprivileged user to inject HTML into a page when it is accessed by a trusted user with permission to embed media. In some cases, this could lead to cross-site scripting.

This advisory is not covered by Drupal Steward.

Also see Entity Embed - Moderately critical - Cross Site Request Forgery - SA-CONTRIB-2021-028 which addresses a similar vulnerability for that module.

Updated 18:15 UTC to clarify text.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core is not affected.

Reported By: Fixed By: 

Tag1 Consulting: Serenity Notes: End-to-End Encrypted Collaborative Notes

3 days 16 hours ago

Serenity Notes is a new application that enables you to collaborate on Notes across devices, with multiple users, in real-time, using end-to-end encryption to keep all your data and info private and secure. It has a game changing SDK enabling the addition of e2e real-time collaboration to your applications, without the complicated underlying complexities. In this Tag1 Team Talk, Managing Director Michael Meyers interviews Nik Graf, the founder of Serenity Notes. Nik has worked for and with Tag1 on many occasions, and is a regular guest on our Tag1 Team Talks program. He’s also a regular contributor to open source projects, as an organizer of ReasonConf, a board member of the ReScript Language Association, and the co-creator of DraftJS Plugins, along with many other projects. For a transcript of this video, see Transcript: Serenity Notes - End-to-End Encrypted Collaborative Notes. ## Additional resources * matrix.org End-to-End Encryption implementation guide * https://www.reason-conf.com * ReScript Language Association * DraftJS Plugins * A Deep Dive Into End To End Encryption (E2EE) in Yjs - Part 1 * A Deep Dive Into End To End Encryption (E2EE) in Yjs - part 2 Photo by Kelly Sikkema...

Read more lynette@tag1co… Wed, 09/15/2021 - 06:06

ComputerMinds.co.uk: Get Hook-ed on Object-Oriented Programming

3 days 18 hours ago

When writing a hook implementation, for example of hook_cron, there's often a tendency to write purely procedural code, like this:

function my_module_cron() { $entity_type_manager = \Drupal::entityTypeManager(); $node_storage = $entity_type_manager->getStorage('node'); // More code goes here. }

If you've got one or two easily understandable lines of code, fine, but frequently you'll end up with a little mini-application jammed into a hook implementation and it can be very easy to end up with something that's not particularly readable, let alone maintainable.

In several articles I've read they mention that you 'cannot' use Object-Oriented Programming code in a hook, and while sort of technically true, there's several easy ways to get back into the OOP world from a Drupal hook:

Static method

This is sort of one for people who simply don't feel right unless they are programming in a class because it doesn't bring all that many advantages over just writing your code in a function, but your hook implementation could look like this:

function my_module_cron() { \Drupal\my_module\Utility\MagicalCronApplication::run(); }

And then you'd have a simple class in src\Utility\MagicalCronApplication.php:

namespace Drupal\my_module\Utility; class MagicalCronApplication { public static function run() { $entity_type_manager = \Drupal::entityTypeManager(); $node_storage = $entity_type_manager->getStorage('node'); // More code goes here. } }

So that gets you into an OOP landscape, but it's a static method, so not all that different from the function implementing the hook, we can do better.

Create an instance

We could do a little refactor and make it so that our hook implementation instantiates a class and then calls a simple method on it, this would help our code look a little more familiar and indeed allow breaking up our little application into more methods to aid readability.

function my_module_cron() { $instance = new \Drupal\my_module\Utility\MagicalCronApplication(); $instance->runApplication(); }

And then you'd have a simple class in src\Utility\MagicalCronApplication.php:

namespace Drupal\my_module\Utility; class MagicalCronApplication { /** * The node storage instance. * * @var \Drupal\Core\Entity\EntityStorageInterface */ protected $nodeStorage; public function __construct() { $entity_type_manager = \Drupal::entityTypeManager(); $this->nodeStorage = $entity_type_manager->getStorage('node'); } public function runApplication() { // More code goes here. } }

We've got more code than ever before, but it's going to be simpler to split up our mini-application and tightly couple the methods together into a single class now.

We could also go a bit further and use the dependency injection pattern to get:

function my_module_cron() { $instance = new \Drupal\my_module\Utility\MagicalCronApplication(\Drupal::entityTypeManager()); $instance->runApplication(); }

And in src\Utility\MagicalCronApplication.php:

namespace Drupal\my_module\Utility; use Drupal\Core\Entity\EntityTypeManagerInterface; class MagicalCronApplication { /** * The node storage instance. * * @var \Drupal\Core\Entity\EntityStorageInterface */ protected $nodeStorage; public function __construct(EntityTypeManagerInterface $entity_type_manager) { $this->nodeStorage = $entity_type_manager->getStorage('node'); } public function runApplication() { // More code goes here. } } Class resolver

Dependency injection is a lovely programming pattern that allows nice things like easily passing in mocked objects and if nothing else explicitly listing out our code dependencies. But if you don't have a Dependency Injection Container around, it can make instantiating classes pretty tricky/verbose, thankfully Drupal does and it has also has a super nifty class that'll help us access services in the container too. (Technically this is dependency container injection into a factory method, but hey!)

So we can rework our code to be like this:

function my_module_cron() { \Drupal::service('class_resolver') ->getInstanceFromDefinition(\Drupal\my_module\Utility\MagicalCronApplication::class) ->runApplication(); }

And in src\Utility\MagicalCronApplication.php:

namespace Drupal\my_module\Utility; use Drupal\Core\Entity\EntityTypeManagerInterface; use Drupal\Core\DependencyInjection\ContainerInjectionInterface; use Symfony\Component\DependencyInjection\ContainerInterface; class MagicalCronApplication implements ContainerInjectionInterface { /** * The node storage instance. * * @var \Drupal\Core\Entity\EntityStorageInterface */ protected $nodeStorage; public function __construct(EntityTypeManagerInterface $entity_type_manager) { $this->nodeStorage = $entity_type_manager->getStorage('node'); } public static function create(ContainerInterface $container) { return new static( $container->get('entity_type.manager') ); } public function runApplication() { // More code goes here. } }

Now we can write code that's much more familiar to the rest of Drupal and much more importantly we can copy/paste code from other classes as we need without having to think too much or doing various gymnastics to get the services we need, we can just add them nicely to the constructor and factory and we're away!

This approach also allows calling this code from multiple places much more easily, say if you want to provide a Drush command that calls this code or even a button in the web UI that runs the exact same code. These things are now super simple.

Bonus: If we happen to not actually need any services from the container, then we can actually drop the create factory method and the implements and the class resolver will basically call new for us, but the day we do want those things we can pop them back and we don't have to go around worrying that usages of our class will break.

We could stop there...and we probably should...but.

A service

We're now not actually that far away from creating a full-blown service, which essentially is only different from the last example in that the class is also made available in the dependency injection container for other code to use too.

For that we could declare our service in a my_module.services.yml file like so:

services: my_module.magical_cron_service: class: Drupal\my_module\Utility\MagicalCronApplication arguments: ['@entity_type.manager']

And then our hook becomes:

function my_module_cron() { \Drupal::service('my_module.magical_cron_service') ->runApplication(); }

We can then drop the factory static method from our class:

namespace Drupal\my_module\Utility; use Drupal\Core\Entity\EntityTypeManagerInterface; class MagicalCronApplication { /** * The node storage instance. * * @var \Drupal\Core\Entity\EntityStorageInterface */ protected $nodeStorage; public function __construct(EntityTypeManagerInterface $entity_type_manager) { $this->nodeStorage = $entity_type_manager->getStorage('node'); } public function runApplication() { // More code goes here. } }

Aside from probably now being really badly named, a service allows some other fun things, like other code could swap out the actual class instantiated when the service is requested. If you did really want to do something like that I'd argue that you can actually swap out the hook implementation itself using a module_implements_alter hook implementation instead, which is probably clearer as to what's going on (it's still not very clear, obviously).

If you are declaring a service you should probably also give the class an interface and because you are advertising to the world that they can call your code you should expect that to happen. You might now have to think about what issues you might cause if you change that code in the future. You might end up supporting an entire ecosystem of modules off of your service, that's a lot of potential code to break.

It's possible that a hybrid approach might be appropriate, whereby you declare some service that contains small, useful functions that other code from other modules might want to call, but that you keep your hook implementations either simply calling the methods on those simple services or where a little bit more logic is required: having a tightly coupled utility class, like in the 'Class resolver' example, that can do the work in a more OOP way.

Wrapping up

I'd argue that unless your hook implementation is no more than two or three lines, you might as well spin up a quick utility class and use the class resolver to instantiate the class. The future you will be grateful that you put in the extra minute to make your codebase more consistent, more copy/pasteable, and more flexible.

Additionally, if your utility class ends up with a lot of useful code in it I'd strongly consider refactoring it into a service so that other code can use your useful code too, but probably don't reach for the services.yml every time you need instantiate an object. But equally, you can use Object-Oriented Programming to implement a hook, almost.

Photo by James Harrison on Unsplash

Lullabot: How to Plan a Successful Design Handoff

4 days 8 hours ago

Too many design handoffs are treated like a relay race. The designers hand off the baton to the developers and then go home because they consider their part of the race done. This can create uncertainty, which means developers have to make assumptions about how things should work and look. 

Many of these assumptions will be inaccurate, leading to frustration, mismatched expectations, and wasted time. The bigger the project, the more these problems manifest.

OpenSense Labs: The State of Headless Architecture in 2021

4 days 14 hours ago
The State of Headless Architecture in 2021 Gurpreet Kaur Tue, 09/14/2021 - 19:47

Every year the technology trends keep on changing and every year it keeps on astounding us. And I believe it is these technological advancements that keep the world moving, and standstill isn’t something that any of us would like or even prefer.    

Today, I want to talk about one such technological advancement that has appeased the web developers, marketers and stakeholders beyond their expectations. And that is the headless architecture for web development

So, what is headless architecture?

Traditionally, when a website is built using content management systems, it is entirely encompassed within that CMS. That one software is the entire world of the website, it controls the presentation layer and the UI as well as manages content at the backend, there isn’t anything else for it. However, the headless solution can offer a website the chance to dip its toes into newer and more modern technologies. 

With the headless approaches, a website essentially separates its frontend from the backend. While the backend functionality is dependent on the CMS at work, the frontend could be any technology available to the developer. JavaScript and Static Site Generators are what are often chosen, with React, Angular, Vue, Gatsby and Metalsmith amongst the frontrunners. 

So, how does the site function with this separation of powers?

An application programming interface or an API to be short helps in that. It transmits information to and from both the ends, kind of like a middleman in sales. Because of the API, the content can be distributed on multiple channels with ease, making content creators extremely happy, an advantage the monolithic architecture does not offer. 


The headless or decoupled architecture is known for the freedom it gives to the developers, making it a trend that has been increasingly gaining grounds and that is what we are going to be analysing today. The reasons, the statistics, the headless domains, the constraints and of course, we can’t ignore Drupal. Let’s see the headless architecture trends in 2021

Has headless architecture become the next big thing in web development?

For me, the answer to that question is a big fat yes. And I have three words to justify my stance and those are superior digital experiences. Headless architectures have the potential to create digital experiences that are far more superior than a standalone, monolithic approach could ever conceive to build. It might seem a little unfair to say that the monolithic architecture is inept at what it does, that is certainly not the case, it's just that the headless architecture has a lot more to offer. For further understanding, read more about headless architecture and monolithic architectures and when to move from monolithic to headless architecture.

Now, let’s take a closer look at the paramount reasons for the significant state the headless architecture has found itself to be in 2021. When you ask yourself ‘Are headless CMS worth it,’ it’s these reasons that would give you an answer.

Headless for limitless technologies and limitless possibilities 

The prime reason for the elevated position of headless architecture is owed to the limitless technologies it allows the adapter to adopt. Headless has become the synonym for technological advancement in web development. A traditional CMS in the monolithic sense would always come with boundations, there would come a point where its abilities can no longer be extended, however, in the headless setup that point is quite far-fetched. More on whether choosing a headless CMS is right or not here.

You can use any technology you want and any feature you may want can be added to your project. 

What is the result?

An enhanced digital experience for your users. Here is what the WP engine’s 2021 survey found out. 

Almost 92% of the survey respondents believed that the headless architecture led to an enhanced digital experience for the users because of its content experience it provided.

You cannot deny the advantage the use of other technologies can give you. 

  • You get the best content experience that is omnichannel, you can reuse it on multiple platforms without it being scattered on multiple siloes; 
  • You get better aesthetics, better accessibility and better user experience for your project; 
  • You get better security as the codebase is less bulky because of the separation of concerns; 
  • You get more productivity out of your developers because they are going to be using technologies that they like and are comfortable with; 
  • You get independent marketers who do not have to rely on developers for simple tasks like creating and updating landing pages: 
  • You get to future proof your project because you aren’t going to be relying on one software that has the chance of becoming obsolete after some time.

Apart from these, you do get plenty of other benefits too, faster performance, faster innovation, faster marketing and a faster and seamless connection between all your digital touchpoints. And you can achieve all of this using React or Angular or Vue or a static site generator, that is your choice completely.

Headless for keeping users satiated 

So far, we’ve gathered that headless architecture is equipped with an exponential amount of possibilities to be created from an exponential number of technological choices.

As a result, web experiences are being able to provide solutions that were never before achieved through the monolithic architecture. Consequently, organisations are able to achieve their strategic goals through headless and become utterly satiated with their developments. 

The leadership in an organisation has become more likely to choose a headless approach and recommend it to its tech providers in the hopes of capitalising on the many choices the approach comes with. This incidentally keeps everyone satiated, including the stakeholders, the development and marketing team and the targeted audience and consumers.

Headless for all the right reasons 

According to a report by Kentico Kontent, here is the perception of the headless architecture straight from its users. 

Source: Kentico Kontent

Majority of the users, including the developers and the marketers, consider the headless approach to provide a considerable number of benefits, which makes us believe that this is a trend that is only going to boom in the near future.

Headless for better investment 

2.6 million USD

That is a substantial amount and that is the average investment organisations are making on headless technologies. 

Is it a better investment choice?

The preceding three points would be a clear indication of an affirmation of this question. Yes, the investment can seem a bit daunting, but it comes with its fair share of benefits that account to one satisfying outcome and that is better ROIs.

Okay, you tell me; 

Would better performance not bring in more rewards?
Would an agile workflow not lead to more productivity and better solutions?
Would a robust digital experience not be equivalent to happier consumers?

If yes, then the headless architecture is truly the next big thing in the world of web development and any other architecture would seem a little pale compared to it.

What do the numbers say about headless architecture?

The numbers are in favour of technology today and they definitely favour the headless approach. 

According to OC&C Strategy Consultants

  • 55% of US households will own a smart device; 
  • And the IoT market is expected to be valued at 520 billion USD by this year.

This is proof that technology is going to boom in the near future. As for the headless trend, here is a projection that shows tremendous growth.


With a CAGR of 22.6%, the headless architecture is bound to have an illustrious future. 

Now, let’s take a look at the usage of headless architecture and the interest it has garnered by enterprise organisations in 2019 in comparison with 2021.


What is also important to note is that now organisations have started associating digital experiences with business success. And since we have established a direct relationship between enhanced digital experiences and headless technologies, you can probably guess what the path to business success will entail. 

Referring to the WP engine report again, 

A vast majority of organisations, 92% of them, believe digital experiences become more powerful with headless technologies.

Now, you tell me, don’t you think the headless approach is only going to advance in the future? If you ask me, I certainly do.

What technological aspects are being capitalised with the headless architecture?

We’ve talked about how the headless architecture is being perceived in the present and looked at statistics that only show a growing trend. Now, let’s look at the technologies that are being capitalised to make this approach reach its true potential; it’s important because it's these technologies that encompass the majority of the benefits of headless architecture. 

JavaScript and all its virtues 

You can’t talk about headless architecture and not mention JavaScript. Ever since its release in 1995, it has evolved a great deal and become frontend developers’ holy grail, with two-thirds of them swearing by it. 

Here is a graph showing the popularity of JS frameworks over the years. 

Source: State of JavaScript 2020

Can’t forget JAMstack 

The mention of JavaScript brings us to JAMstack, that is JavaScript, API and Markup. It is an architecture that stands on pre-rendering and decoupling. Websites built on it are considerably faster, more secure and more scalable. With JS in play, the frontend is bound to offer more to the developers, thus enhancing their productivity and workflow. 

Focus on individual components while development

Next technicality often seen in the headless world is pertinent to the development of individual components. There are two variations in this.

Micro-frontend architecture 

This is a solution that works marvelously with the monolithic structure by breaking it down into individual components that essentially become independent applications. Although they are separate, the codebase remains the same. 

Component-driven development architecture

This is somewhat similar to the previous one. However, it emphasises on the principle of modularity. This means that the developed components have the benefit of being reused and composed.

Both of these architectures come with similar advantages; 

  • The development takes place faster with team focusing on only one feature or component working simultaneously; 
  • The integration goes smoothly; 
  • The code can be maintained with much more ease; 
  • The task of scaling the project becomes pretty straightforward;
  • And the chances of errors reduce drastically, making testing and updates a breeze.

To know more, read about designing component-based systems, a quick look at the world of web components and the principles of atomic design methodology.

The new API solution: GraphQL 

Going headless mandates an API, and RESTful APIs were the only resort. However, now GraphQL is seen to be taking over. Being a query language, it enhances the data retrieval process to be much more accurate by reducing the number of requests sent to the server. 

  • GraphQL has smaller payloads; 
  • It has a single graph for retrieving queries; 
  • It can efficiently handle errors; 
  • And most importantly, it has a stringent type interface that magnifies performance.

Owing to these reasons, it is considered to be the superior sibling of RESTful API. And major brands like Facebook, Lyft and even Audi are leveraging it. More on different web services implementations available here.

Progressiveness in app development 

By progressiveness, I mean the Progressive Web Applications or PWAs. These are a cross-breed of mobile applications and traditional websites, meaning they leverage the browser APIs and its features as well as a conventional progressive enhancement strategy. The result is a project that performs impeccably well, loading in mere seconds, across multiple devices. Their reliance on HTTP protocols also make them pretty secure.

What is more intriguing about this trend is the fact that these PWAs perform even when there is poor or no connectivity. Thus, equipping businesses to target a demographic that was often overlooked.

The headless trend is growing, but not fast enough, why?


The image above mentions the percentage of people using and not using the headless architecture. And if I’m being honest the numbers are a bit disappointing when you look at the true potential of the approach. 

So, why is that the case?

Let’s find out. 

The marketers’ and content editors’ underwhelming experiences 

One of the promises that the headless architecture often makes is that it eases the work of both the marketers and the content editors. While that may be true to some degree, it isn’t the complete truth. 

The Kentico Kontent survey’s respondents gave the most precise answer that hit on point when they highlighted the demerits as below.

Source: Kentico Kontent

If we consider these findings, three out of the top four challenges stated there are related to just that. Dependency on web developers and lack of marketing capabilities are proof enough. 

So, why aren’t the marketers and content editors not satisfied?

The major problem is related to control. The marketers and content editors do not have enough control over the visual layer as the presentation and content workflows are built from scratch by the developers. The access to the editorial interface isn’t as streamlined as the traditional setup.

I truly wondered as to why this was a problem. 

The answer lies in the universal nature of the headless content. Let me explain it. For a website or a mobile application, features like in-place editing and the famous drag-and-drop layout work pretty well. However, when you consider a smartwatch or say a voice assistant, can the same features be a possibility? 

Hence, the marketers and the editors have to compromise a little for the greater good, there is just no way around it. More on when and how to use headless CMS here.

The overwhelming concerns that won’t leave us alone

The headless architecture is still a novel concept for many of us. And like anything else that is new, there is some apprehension associated with it. You can say that it is because you would be parting with the out-of-the-box features that the monolithic structure may offer.

Security; 
Analytics; 
eCommerce; 
Monitoring and reporting; 
And CRM; 

These are genuine concerns regarding the headless approach since it would be you and your front-end developers who would be responsible for them, and not your CMS or its community support. And that is as intimidating as it is overwhelming. You would entrust your site’s entire front-end to your developers, there is bound to be some risk, so trust me I get the apprehension.

Of course, you can hire an agency to help you out with the right security API so that there aren’t any flaws and only be overwhelmed with the impressiveness of your site. More on the right skills you need to successfully deliver a headless project here.

The perception of the stakeholders

Finally, it is time to discuss the stakeholders and the role they play in holding back the headless architecture. 

If you ask a stakeholder in an organisation to give his take on this approach, you would probably not get a straight answer. When we understand their perception, you can’t really blame them for their opinion. 

For one, that person relies on his website for his livelihood and he wouldn't want to risk it. Therefore, he might not want to adopt the headless architecture before others because he isn’t familiar with the territory. Secondly, the website may have all the necessary features that it needs to satisfy its consumer base, at least in the present, through the traditional setup. 

Yes, technology might change in the future, the consumer needs would too, but where is it written that only headless architecture can fulfil those needs. The headless approach does have a lot to offer, but so does the conventional CMS. So, why risk it?

Where does Drupal fit in the headless movement of 2021?

I couldn’t write a blog about the headless approach and not mention Headless Drupal architecture, that would not be ideal at all as I personally feel that Drupal is one of the best headless CMS in 2021. So, let’s understand the role of Drupal and all of its offerings in the headless realm.

Drupal has an impressive headless architecture that allows its users to work with the most advantageous technologies today. It offers three ways to approach the headless architecture.

  • You can choose to fully decouple Drupal, this would completely separate your frontend from the backend, you’ll be free to build your presentation layer outside of Drupal, while the CMS would only act as a content repository.
  • You can choose decoupled Drupal for static sites with JAMstack at work and static site generators. More on leveraging static site generators and CMS here.
  • Finally, you can opt for progressively decoupled Drupal, wherein you can use other frontend technologies without losing Drupal’s functionality on the same end, the backend would only be empowered by the CMS.

Choosing between the three and the monolithic architecture can be a tricky choice, here is what Dries Buytaert had to offer in easing the choice. 

Source: Dri.es

To know more, read about the different options of decoupling CMS and best frontend technologies for your headless CMS development.

If you are familiar with Drupal, you may be familiar with all of what I have just mentioned. So, what is new? 

The answer is Decoupled Menus. The DrupalCon Global 2020 brought along the initiative of decoupled menus in Drupal

What is the Decoupled Menus Initiative about?

When you go the decoupled or headless route, you are going to be using JavaScript. Along with that you are going to have to create a custom code from scratch to make that feature using Drupal and JavaScript. 

The decoupled menus will come quite handy here. They are like pre-formed packages of JavaScript configurations that simply need to be implemented to make a headless feature work. These configurable menus can be placed in any JavaScript application and would be managed by Drupal with its community support.

You can also refer to them, if you do not want to use them as is, the documentation, packaging and security would be available to you for reference or implementation.

The decoupled menus are Drupal’s way of evolving itself and adapting into the headless world. It is evolving and making the headless architecture and Drupal combination seem less cumbersome. 

You may ask how? 

Aside from the obvious, there are a few reasons. Drupal architecture isn’t handling the work necessary for JavaScript packages, with decoupled menus, the bundling, testing and shipping via GitLab would be constantly updated. On top of this, the security issues pertaining to JS and the documentation for consumption of menus would be defined and updated. 

All of this means that a non-developer or content creator would get an intuitive UI that would allow him to configure the menus and turn them on or off with a few clicks and certainly without a developer. 

Here is a demo of the decoupled menus feature.


In essence, this is a feature that would lay the groundwork for code for JavaScript frameworks like React and Vue, so that the workload that comes with headless architecture is lessened. You will get a React based display link on your ecommerce site without having to do all the work to get it. 
To emphasize more upon the milestone which this initiative has achieved, take a look at the Decoupled Menus Initiative Keynote followed by an interesting Q & A session through the help of this video at DrupalCon North America 2021.

 
Concluding with the Future of Headless

Everything in this blog, the hesitation towards decoupled CMS aside, points to a clear and concise conclusion and that is the fact that the headless architecture will continue to expand in the coming years and may even overcome the resistance, making it future proof. 

New technologies would be looked into as part and parcel of the headless CMS, making the expectations seem rather high. Augmented reality, virtual reality, digital displays and kiosks, digital and voice assistants would not be a distant and rather tedious goal to achieve. 

According to the WP engine I’ve quoted a few times now, these advancements and inclination towards headless technologies would somehow vary depending upon geographic regions. Even the major tech hubs like the USA, the UK and Australia experience a variation in the expectation regarding headless. While e-commerce is a priority for the US and Australia, the UK focuses on websites and PWAs as their future expectations from the headless approach. 

Despite the differences, the world of headless is gaining traction and it is going to keep growing in the future as well, that is an irrefutable fact, if there was any. So, is headless CMS the future? It indeed is.

Let me end this blog with an interesting discussion on the state of headless through this YouTube video, enjoy!

blog banner blog image Headless Architecture Headless CMS Decoupled CMS Decoupled Drupal Headless Drupal Decoupled Menus Initiative Traditional CMS Blog Type Articles Is it a good read ? Off
Checked
18 minutes 58 seconds ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Planet Drupal feed