Planet Drupal

Dries Buytaert: Relentlessly eliminating barriers to growth

4 weeks 1 day ago

In my last blog post, I shared that when Acquia was a small startup, we were simultaneously focused on finding product-market fit and eliminating barriers to future growth.

Today, Acquia is no longer a startup, but eliminating barriers to growth remains very important after you have outgrown the startup phase. In that light, I loved reading Eugene Wie's blog post called, Invisible asymptotes. Wie was a product leader at Amazon. In his blog post he explains how Amazon looks far into the future, identifies blockers for long-term growth, and turns eliminating these stagnation points into multi-decade efforts.

For example, Amazon considered shipping costs to be a growth blocker, or as Wie describes it, an invisible asymptote for growth. People hate paying for shipping costs, so Amazon decided to get rid of them. At first, solving this looked prohibitively expensive. How can you offer free shipping to millions of customers? Solving for this limitation became a multi-year effort. First, Amazon tried to appease customers' distaste for shipping fees with "Super Saver Shipping". Amazon introduced Super Saver Shipping in January 2002 for orders over $99. If you placed an order of $99 or more, you received free shipping. In the span of a few months, that number dropped to $49 and then to $25. Eventually this strategy led to Amazon Prime, making all shipping "free". While a program like Amazon Prime doesn't actually make shipping free, it feels free to the customer, which effectively eliminates the barrier for growth. The impact on Amazon's growth was tremendous. Today, Amazon Prime provides Amazon an economic moat, or a sustainable competitive advantage – it isn't easy for other retailers to compete from a sheer economic and logistical standpoint.

Another obstacle for Amazon's growth was shipping times. People don't like having to wait for days to receive their Amazon purchase. Several years ago, I was talking to Werner Vogels, Amazon's global CTO, and asked him where most commerce investments were going. He responded that reducing shipping times was more strategic than making improvements to the commerce backend or website. As Wie points out in his blog, Amazon has been working on reducing shipping times for over a decade. First by building a higher density network of distribution centers, and more recently through delivery from local Whole Foods stores, self-service lockers at Whole Foods, predictive or anticipatory shipping, drone delivery, and more. Slowly, but certainly, Amazon is building out its own end-to-end delivery network with one primary objective: reducing shipping speeds.

Every organization has limitations that stunt long-term growth so there are a few important lessons that can be learned from how Amazon approached its invisible asymptotes:

  1. Identify your invisible asymptotes or long-term blockers for growth.
  2. Removing these long-term blockers for growth may look impossible at first.
  3. Removing these long-term blockers requires creativity, patience, persistence and aggressive capital allocation. It can take many initiatives and many years to eliminate them.
  4. Overcoming these obstacles can be a powerful strategy that can unlock unbelievable growth.

I spend a lot of time and effort working on eliminating Drupal's and Acquia's growth barriers so I love these kind of lessons. In a future blog post, I'll share my thoughts about Drupal's growth blockers. In the meantime, I'd love to hear what you think is holding Drupal or Acquia back — be it via social media, email or preferably your own blog.

Promet Source: How to Stop SPAM with Drupal 8's Recaptcha module

4 weeks 1 day ago
Have you ever tried logging in or registering to a website and you were asked to identify some distorted numbers and letters and type it into the provided box? That is the CAPTCHA system. The CAPTCHA helps to verify whether your site's visitor is an actual human being or a robot. Not a robot like you see in the Terminator movie but an automated software to generate undesired electronic messages (or content). In short, CAPTCHA protects you from SPAM.  

Flocon de toile | Freelance Drupal: Small sites, large sites, micro sites with Drupal 8

4 weeks 1 day ago

Drupal 8 is a tool designed to meet the needs of the most ambitious web projects. We hear a lot about the notions of headless, API first, decoupling, etc. that resolutely allow solid architectures for ambitious projects. But this does not mean that Drupal 8 no longer propels more traditional, and sometimes even much less ambitious sites: simple, small, and even large, websites, but for which we want to benefit from the modularity, flexibility and robustness of Drupal.

Gábor Hojtsy: How to automate testing whether your Drupal 8 module is incompatible with Drupal 9?

4 weeks 2 days ago

Drupal 9 is planned to be only 18 months away now, wow! It is already being built in Drupal 8 by marking APIs to be removed in Drupal 9 as deprecated and eventually upgrading some dependency version requirements where needed. Once the Drupal 9 git branch will be open, you will be able to test directly against Drupal 9. That should not stop you from assessing the compatibility of your module with Drupal 9 now. To prepare for compatibility with Drupal 9, you need to keep up with deprecated functionality and watch out for upgraded dependencies (when we know which are those exactly). Of these two, automation can go a long way to help you keep up with deprecated APIs.

DrupalCon News: DrupalCon Seattle: Sessions and Strides

4 weeks 2 days ago

DrupalCon Seattle is looking different than the DrupalCons of years past.

The overarching goal when planning DrupalCon Seattle 2019 was to expand both outreach and accessibility so that attendees would be representative of the community as a whole. The value of the conference is in the perspectives, energy and diversity of experiences participants share.

DrupalCon began setting goals to overtly increase diversity starting with DrupalCon Baltimore 2017. This continued in the planning of DrupalCon Nashville 2018, and is prioritized for DrupalCon Seattle 2019.

MidCamp - Midwest Drupal Camp: Summits: What to Expect?

4 weeks 2 days ago
Summits: What to Expect?

This year MidCamp will be including summits in addition to the regular programming that we have provided in the future. Here are some things we think you should know in order to prepare yourself:

A summit is a one-day topic-intensive meeting where people who share an industry or interest can come together to collaborate, share pain points and solutions, and meet like-minded individuals in a structured, safe environment.

Summits focus a full day unconference around a singular topic, in which different groups of interested parties collaborate, gather information and learn together. This programming is for focused discussion, planning, hacking and learning about the topic. 

We believe in facilitating like an unconference. On the day of, each summit group led by a facilitator will compile an agenda and create breakout groups on various subtopics of the overall summit topic.

Unlike training, attendees are generally still planning and information gathering. There won’t be any required deliverable, like code or documentation. Instead, summits focus on conversation and dialog. During a training, the focus is learning a thing, but summits encourage open idea sharing on a broad range of topics related to the overall theme. 
 

Takeaways from the Midcamp Team

Below are some stories from our team as they reflect back on their first summit.

“I felt like I was in a room full of rock stars. Angie Byron, Sam Boyer, Chris Vanderwater... I forget who else, but there were a fair number of big names. We were there to discuss the panels/blocks initiative. There was considerable brainstorming on various problems that were currently being solved in the initiative.”

- Andrea Soper

“I just attended my first summit at BADCamp this year. It was the front end summit and attendees were polled ahead of time to get an overall sense of what front end topics people were interested in discussing. At the summit, we used that list and then added to it via post-its to organize the topics into larger categories. Then throughout the day, we broke into smaller groups to discuss almost every topic that came up. The facilitators were good about keeping the discussion moving along and ensuring we covered everything. The day was also broken up with some fun group icebreakers and a talk from one of the creators of GatsbyJS.”

- Kevin Thull

DrupalEasy: DrupalEasy Podcast 213 - Ted Bowman - Layout Builder in Core

4 weeks 2 days ago

Direct .mp3 file download.

Ted Bowman, senior software engineer with the Drupal Acceleration Team at Acquia, joins Mike to discuss the game-changing work of the Layout Initiative. Sorry about the poor quality of part of Mike's side of the conversation (as well as the comical overdubbing of other portions of the conversation).

Discussion DrupalEasy News Upcoming Events Sponsors Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

OpenSense Labs: Breaking Down the Concept of Distributed Content Management System

4 weeks 2 days ago
Breaking Down the Concept of Distributed Content Management System Akshita Mon, 12/17/2018 - 19:40

Heading a multinational or location agnostic organization with complex content creation and publication needs while also keeping a track of the content can be a difficult task without the right content management system.

The number of bloggers is expected to reach 31.7 million in 2020 in the US alone. 

Imagine the number of blogs on the internet. The huge amount of information flowing online has brought us to the situation where the ever-flowing media content needs to be routinely stored and encoded. Networked storage and exchange of data allow content to be distributed making the task of content management all but impossible to deal, without a content management system.

Content and teams that interact in a distributed system need to be dealt intrinsically different from the ones that interact in a centralized system.

Considering the popularity of Drupal as the enterprise’s CMS, in this blog, we will explore how it can help in providing and managing the modern digital experience as a Distributed Content Management System.

 

Understanding the Concept

A distributed content management system can be difficult to comprehend to different people as it implies a different meaning to a different situation. 

To develop a better understanding of the distributed content management system, let’s understand with an example of a national daily which also publishes in different regional languages. 

The Distributed Management of Content or The Management of Distributed Content

The Distributed Management of Content deals with the workflow involved in the content creation with a decentralized approach. 

The Management of Distributed Content works around dealing with existing content from a variety of sources, involving input (from other websites/sources), output (to other websites) or both. 

By implementing Distributed Management of Content, organizations can eliminate the time and opportunity for error introduced when users enter content in multiple places. Unlike the first concept, the goals for Management of Distributed Content are generally around efficiency and control. 

Setting up An Example of a National Media House

Let’s call this media house - OneIndia News

One India news has 6 regional websites. Similar to many media institutions, the website channels are split into multiple categories (let’s say 5) and each of those categories further houses a number of sub-sections.  

Some of the regional websites may only have 2 to 4 categories depending on the demand, but others may have upwards of 10. 

Each category has an editorial team of its own.

Now the regional websites are handled by a number of different editors for each category and channel. Toss in the requisite assortment of content types and workflow hierarchy - you can see how quickly the web presence gets complex!  

Management of distributed content revolves around efficiency and control.

At this scale, we’re likely dealing with multiple websites of one media organization, all of which have requirements around content. This has now become the perfect use-case for Distributed Content Management!

  Use Case 1: Publishing Workflows For Individual Websites

For the main website of One India News, a central editorial team with defined roles and distributed content production would suffice.

Consideration of a content approval workflow is a critical part of the content strategy for any organization that employs distributed management.

Each news needs to be added and edited by different people. Editing the news on the live site can result in accidental publishing.

Be it living a number of articles at the same time, sending the final copy for the approval of different persons (without living them) or publishing articles on different subdomains. A robust virtual workflow and content staging and publishing without the requiring the editor to log into the target site is needed from the CMS. 

Publishing workflows will be tailored not only to the regional media house but to each channel and team that’s in charge of their regional website. The idea here is to manage the responsibilities across the organization while empowering the editors. 

Content to be published on the homepage of the website will likely require significantly more oversight than in the humor or offbeat channel. 
 

Use Case 2: Sharing Content Out - Centralized Content On A Distributed Web Platform

Copy-and-paste becomes a less efficient option when the content is further distributed to the workflow.

A distributed system must have a Pub-Sub (Publisher-Subscriber) feature to ensure the information is processed quickly across the different systems. The centralized system must allow editing and processing of the data while pushing the request to the subsystems. This needs to be done asynchronously so the results populate really fast, for the editor. 

Use Case 3: Sharing Content In - Decentralized Websites As Points Of Origin

Another interesting use case presents itself when we consider distributed websites as the starting point for content creation. One India, as any media houses maintain a central calendar of events, such as festivals and political events. 

In a well-formed distributed content model, with an appropriate CMS like Drupal, the same metadata that allows visitors to filter events - audience, department, program - can be easily used to syndicate those events to various other websites.  

Unfortunately, the same level of consideration is not always given to everyone outside the subset team with appropriate permissions. 

Content managers who are generally empowered to manage their own content may not have the same access to do so, or, in cases where they do have permission, find themselves needing to enter content into an entirely different website system to get it published to their site. But why should this be the case?  

By extending the same technologies that allow websites to receive events from a central calendar, in Drupal we can enable content managers to publish events to the calendar from within the same website they usually manage. (The same content approval and publishing workflow considerations apply, of course.)
 

Difference between Centralized and Distributed Content Management
 

Centralized Content Management

Distributed Content Management 

  • All content funneled through one group

  • Small individual workgroups responsible for respective areas

  • Central rules and procedures to ensure rules are followed 

  • The responsibility of individual groups to oversee content quality

  • One person authority - who is responsible for the rules and implementation

  • Each group may have one or more lead approvers. Workgroups leads handle process and rules

  • Advantage - Resulting process control without confusion

  • Advantage - Responsibility and the workload are distributed

  • Disadvantage - May result in a bottleneck

  • Disadvantage - Individual groups can interpret rules differently


Use Case 4: Multichannel Brand Content

Single-source content syndication also provides an opportunity for media companies to promote their brand across multiple mediums. Many companies choose to employ standalone, all-in-one news providers such as Reuters, rather than integrating a category for each of the news providers. 

This makes a tremendous amount of sense - these organization systems when merged with the own CMS can provide a number of compelling results such as quicker results and faster news publishing. 

By programmatically receiving the content from a content repository the organization can eliminate the risk of delayed news and perpetual loss of audience. 


Use Case 5: Content Delivery To Validated Audiences

In an attempt to decentralize content over the years, media organizations now allow users to add stories to the website. 

How they access, validate, identify the users is another key consideration for the company’s distributed content management strategy. 

A common approach is to segregate guest editor content into different regional “portals” - websites that require the editor to create accounts and login to see the information for their country or part of the world.  

To overcome the challenge of validating these accounts, companies often integrate with an Identity Provider (IdP) such as SAML 2.0 Single Sign On easy configuration & active support, in your Drupal website. 

At the far end of the Distributed Content Management spectrum are systems that need to publish consistent, controlled content to websites with no possibility for discrepancies across multiple sites.  

Drupal allows Distributed Content Management strategy to be applied to large volumes of content to facilitate efficient workflow. Specifically, the system allows different content and editors to be part of the same system without much replication. 

Finally, the modular design of the Drupal architecture allows both stand-alone and distributed realizations so that the system can be deployed in a variety of applications. Connect with us, drop a mail at hello@opensenselabs.com or tweet us @OpenSenseLabs

blog banner blog image Content Management System Distributed Management of Content Content sharing Decentralized Websites Drupal CMS Content Creation Content Marketing Distributed content management Blog Type Articles Is it a good read ? On

OpenSense Labs: Important OOP Concepts For Drupal Developers To Create Custom Modules

4 weeks 2 days ago
Important OOP Concepts For Drupal Developers To Create Custom Modules Vasundhra Mon, 12/17/2018 - 19:08

Modifying existing code might be all fun and games for a developer, but what about the time when you have to venture out to unknown shores and create your own custom modules? 

Scary, right? 

But you shouldn’t fear because Drupal 8 is here.

Drupal 8 uses a PHP framework called Symphony which relies heavily on Object-oriented programming.

It has been granting its users with benefits like code reuse and encapsulation, and these benefits allow users to maintain and structure code in a better way possible. 


Phew! 

However, this might leave you with a farrago of questions - What do I need to know in Drupal 8 to start developing? What is OOP? Why is it used in Drupal 8 to make modules? How does it create the custom modules? 

Thus, here is how you can do it all that might help make the OOP principle of PHP a little less daunting. 

Start With Prerequisites to Create Custom Modules

We all know that Object Oriented Programming has provided us with the power to create our desired objects and construct methods to handle them. And with the usage of various OOP principles and design patterns, Drupal 8 has brought about a much easier path in terms of development.  

Drupal 8 serves as a great introduction to PHP. Here are some of the design patterns which are important to understand to solve the basic object-oriented design problem. 

PHP Namespace (introduced in version 5.3)

In PHP you can’t have two classes that deal with the same name (they have to be unique). Therefore, PHP namespace allows you to dodge this issue by presenting a similar code into neat little packages, or even to determine ownership.

Drupal 8 consists of a number of files that declare the namespace in order to remain compatible with PHP 5.3. Therefore, with the help of two standards in Drupal, PHP interfaces and traits are easily namespaced.

Use statement

Classes and interfaces with a (\) backslash inside their fully qualified name should not use it inside the core. If it differs from the current file, then it can be solved by using the “use” statement on the top. For example

namespace Drupal\mymodule\Tests\Foo; use Drupal\simpletest\WebTestBase; /** * Tests that the foo bars. */ class BarTest extends WebTestBase {


And, for the file which does not declare a namespace has to specify with the use statement at the top of the file 
For the classes that are without backslash, they must be fully qualified when used in the namespace file.

Also, while you are importing a class with “use”, do not use the backslash. 

Aliasing the class 

PHP has allowed the classes to be aliased when they are being imported into a namespace. It is done to avoid the collision. But suppose the collision still happens, you can alias the classes by prefixing the next higher portion of the namespace.

use Foo\Bar\Baz as BarBaz; use Stuff\Thing\Baz as ThingBaz; /** * Tests stuff for the whichever. */ function test() { $a = new BarBaz(); // This will be Foo\Bar\Baz $b = new ThingBaz(); // This will be Stuff\Thing\Baz } Dependency Injections

Dependency Injections is that software design pattern that would allow you to remove hard-coded dependencies and also make it possible to change them either on runtime or at compile time.

Drupal 8 introduced the concept of services (object managed by service container) in order to decouple reusable functionalities. It creates the services pluggable and replaceable by registering them with the help of a service container.

These services are used to perform operations that include accessing of the database or sending up of an e-mail. Therefore, to let the code simply access the database (without worrying about whether the database is MySQL or SQLite), usage of core provided service via the service container is done.

These core services are defined in CoreServiceProvider.php and core.services.yml. Somewhat like:

... language_manager: class: Drupal\Core\Language\LanguageManager arguments: ['@language.default'] ... path.alias_manager: class: Drupal\Core\Path\AliasManager arguments: ['@path.crud', '@path.alias_whitelist', '@language_manager'] ... string_translation: class: Drupal\Core\StringTranslation\TranslationManager ... breadcrumb: class: Drupal\Core\Breadcrumb\BreadcrumbManager arguments: ['@module_handler'] ...


Each service depends on the other service. Like in the example above path.alias_manager is dependent on the path. crud, path.alias_whitelist and language_manager services specified in the arguments list.

Dependency injection is the preferred procedure for accessing and using services in Drupal 8. Services are transferred as an argument to the container or injected via setter methods.

Symfony 

Symfony is a PHP framework that Drupal borrows from in order to reduce codes duplication across various PHP projects. Much of the code that Drupal 8 uses to handle routing, sessions, and service container. These components are flexible and universal solutions. They are the stable ones and solves most the problems that aren’t good practice, to reinvent the wheel. Symfony follows the standards that adhere to PSR-5 and PSR-7

Annotations

Annotations are the comments in your code that contain meta information. The main advantage of annotations is that they improve performance due to the less memory usage and is placed in the same files as the class is. For example

/** * Provides a 'Custom' Block * * @Block( * id = "custom_block", * admin_label = "Custom block", * ) */


Drupal 8 uses PHP annotations for plugin discovery and to present additional context/meta-data for the codes that have to be executed. These are the read using Doctrine annotation parser (offers to implement custom annotation functionality for PHP classes.) and then they are turned into information that Drupal can use for better understanding on what your code is actually doing. 

Plugins 

Plugins are considered as a small piece of functionalities that can be swapped. Drupal consists of different plugins with different types. The CMS platform provides a set of guidelines and reusable code components that allows the developer to expose pluggable components within their code and manage these components with the user interface. Plugins have three basic elements namely.

Plugin type: It is a central controlling class that would define how the plugin of this type will be discovered and instantiated.

Plugin Discovery: It is the process of finding plugins within the code base that is qualified for the usage.

Plugin Factory: It is responsible for instantiating specific plugins.

Not to Forget the OOP Coding Standards 

If the end user is aware of key OOP principle and design pattern, then it becomes even more easy for them to use it with Drupal. For instance, different services become available when default container initializes while bootstrapping Drupal. In short, you have the power to build your own class, then define it as a service and make it available in the container. 

Drupal 8  has a set of coding standards just for object-oriented code and adheres to common PHP coding conventions. 

Thus, some of the common PHP conventions for OOP that Drupal follows for best practices would include:

  • Declaring a class in OOP. It is important that there should always be one interface or trait per file. The classes are autoloaded based on PSR-4 namespacing convention, and in the core, the tree under PSR-4 starts as core/lib/. For the modules that contain contrib, custom and those in the core, the PSR-4 tree starts under modulename/src. It should also be noted that it is only possible to define a class in a module if the class does not contain any superclass. 
  • Next in this coding standards would be whitespace or indentation method. Both of them leave an empty line between the start of the class definition and property definition. Just like this:
class GarfieldTheCat implements FelineInterface { // Leave an empty line here. public function meow() { ... ... ...

 For an empty space between property definition and method definition:

... ... ... protected $lasagnaEaten = 0; // Leave an empty line here. public function meow() { return t('Meow!'); }

And then for the space between the end of method and end of the class definition:

class GarfieldTheCat implements FelineInterface { ... ... ... public function eatLasagna($amount) { $this->lasagnaEaten += $amount; } // Leave an empty line here. }
  • Without basic naming conventions, coding standard for OOP is a void. These naming conventions (set of rules) would help you to choose the character sequence to be used for the identifier that denotes the variables, functions, types and other entities.  
  • There might be chances where you would also wish to extend your code. Thus the use of separate interface definition would help you by contributing highly in terms of flexibility and would also neatly centralizes the document, making it easier to read.  A class that has to be extended must always provide an interface that other class can implement rather than forming them to extend the base class.
  • Also, it is important for all the methods and properties of classes to specify the visibility (private, protected or public). The use of public properties is strongly discouraged. It allows the entry of unwanted side effects and exposes implementation specific details, which in turn makes swapping out of class (for another implementation) much more hard. 
  • Now comes the “Type Hinting” in PHP. It is basically used to specify the expected data type of an argument in a function declaration.  Although type hinting is optional, it is recommended for debugging.If an object of the incorrect type is passed, an error is shown. If the method’s parameter expects a certain type of interface, it is important to specify it. This would guarantee that you are checking for a type and also maintaining a fluid code.
  • Next is instantiation. It is basically the creation of a real instance or a single realization of an abstraction/template such as the class of object. Drupal coding standards look down upon directly creating classes. Rather it is better to create a function to instantiate the object and return it. It is because:
  1. The function which is written can be reused to return different objects with the same interface as it is needed. 
  2. You are not allowed to chain construct in PHP, but you are allowed to chain return object from the function. 
  • Last but not the least - Chaining.  Chaining is that blessing for you which allows you to immediately call a function on a return object. This is also known as “fluent interface”
// Unchained version $result = db_query("SELECT title FROM {node} WHERE nid = :nid", array(':nid' => 42)); $title = $result->fetchField(); // Chained version $title = db_query("SELECT title FROM {node} WHERE nid = :nid", array(':nid' => 42))->fetchField();

A method would return $this, and then would be chainable in a case where there is no other logical return value.

In cases that have a fluid interface of the classes, and code span of more than one line, the method calls should attend 2 spaces

$query = db_select('node') ->condition('type', 'article') ->condition('status', 1) ->execute(); Routing in Drupal 8 is Equally Important 

Drupal 8 routing system works with the Symfony HTTP kernel. The routing path has replaced hook_menu() in Drupal 7. Though in Drupal 8 heavy use of Symphony 2 components handle the routing part. Drupal 8 also uses YAML format. All the information about routes of a module is kept in the file MODULE_NAME.routing.yml. 

The routing system is responsible for matching paths to the controller and then you are allowed to those relations in routes. The additional information can also be passed to controllers in the router. 

Each route has to be described separately from one another with the involvement of these characteristics :

  • Name for identifying the routes 
  • Path beginning with a slash
  • A route’s processor
  • Condition managing the access to the route
example.my_page: path: '/mypage/page' defaults: _controller: '\Drupal\example\Controller\ExampleController::myPage' _title: 'My first page in Drupal8' requirements: _permission: 'access content'

Example.my_page is the route in the .routing.yml file. The route is the Symfony component which maps the HTTP request to set the configuration variable. Under path, we specify the path where route should be registered. This acts as the URL to route 

Creating “Controller Class”

It is important to build the ModuleController.php according to the PSR-4 naming standard. You just have to create a folder along with a file name with the following content. 

<?php /** * @file * @author Rakesh James * Contains \Drupal\example\Controller\ExampleController. * Please place this file under your example(module_root_folder)/src/Controller/ */ namespace Drupal\example\Controller; /** * Provides route responses for the Example module. */ class ExampleController { /** * Returns a simple page. * * @return array * A simple renderable array. */ public function myPage() { $element = array( '#markup' => 'Hello world!', ); return $element; } } ?>

A controller is a type of PHP function that you create. It takes the information from the HTTP request and creates or responds to an HTTP response.

Creating the “.module file”

In Drupal 8 hook_menu() is used to only define items. If you have a hook_menu() then make sure that route and path in example.module should match with example.routing.yml.

In the case of items and route example, .module should be on the same path.

<?php /** * @File * Example custom module for Drupal 8. * @author Rakesh */ /** * Implementing hook_menu(). */ function example_menu() { // The paths given here need to match the ones in example.routing.yml exactly. $items['/mypage/page'] = array( 'title' => 'First page', 'description' => 'This is a example page.', // The name of the route from example.routing.yml 'route' => 'example.my_page', ); return $items; } Conclusion

So here it is. Now, you know the concepts of OOP to create a custom module. Yes, it is important to know OOP, design patterns, Twig, and modern PHP trends for creating the modules, and Drupal makes this task even more easy for you. Isn’t it?

If you’re looking for more good resources and reference material, head over to OpenSense labs, where we provide services that develop complex web applications with relative ease. Whether it is the development of a new custom module or optimization of your new website, everything is handled and tailored according to your needs. 

So contact us at hello@opensenselabs.com for more information and reference on the same. 

blog banner blog image Drupal Drupal 8 Drupal Modules Object Oriented Programming Symfony PHP PHP Namespace Dependency Injections Annotations Plugins Chaining Routing Coding Standards design patterns Blog Type Tech Is it a good read ? On

Yuriy Gerasimov: Automating checking your Drupal's updates

1 month ago

Drupal updates can be very different. Some of them -- easy patches that you just roll out and forget. Some of them -- break your site. Tricky part is you never know how updates will behave on your site until you actually tried them out.

This is why it is very tricky to give estimates to clients how long it is going to take. They usually do not appreciate answer 1 to 20 hours depending on some random facts.

In this way rolling out updates got delayed and delayed. And then we get to situations after half a year or a year that we know for sure site will be broken after updates. And now hero time begins.

Would it be nice if site would tell you not only the fact that it needs updates but also if it is going to break or not after rolling them out.

Nowadays, thanks to Pantheon's multidev, it is technically possible to automate checking how your updates will behave on the site.

Main idea is to regularly check updates (using drush command) then if updates are found create a separate environment and roll updates there. Afterward to ensure that they didn't break the site (at least visually) we could run some visual regression testing. So in result we have way more predictable answer about "how much efforts it will take to roll updates out".





Here is a full article tutorial about how to set it up http://docs.diffy.website/tutorials/put-your-sites-updates-on-autopilot-with-pantheon-multidev-and-visual-testing.

For sure fixing smaller updates is much easier than fixing big break after year of delays.

Tags: drupal planetdrupal 8

Dries Buytaert: Optimizing your product strategy for the short- and long-term

1 month ago

Most products cycle through the infamous Innovation S-curve, which maps a product's value and growth over time.

Startups are eager to find product-market fit, the inflection point in which the product takes off and experiences hockey-stick growth (the transition from phase one to phase two).

Just as important, however, is the stagnation point, or the point later in the S-curve when a product experiences growth stagnation (the transition from phase two to phase three). Many startups don't think about their stagnation point, but I believe they should, because it determines how big the product can become.

Ten years ago, a couple years after Acquia's founding, large organizations were struggling with scaling Drupal. I was absolutely convinced that Drupal could scale, but I also recognized that too few people knew how to scale Drupal successfully.

Furthermore, there was a lot of skepticism around Open Source scalability and security. People questioned whether a community of volunteers could create software as secure and scalable as their proprietary counterparts.

These struggles and concerns were holding back Drupal. To solve both problems, we built and launched Acquia Cloud, a platform to build, host, and manage Drupal sites.

After we launched Acquia Cloud, Acquia grew from $1.4 million in bookings in 2009 to $8.7 million in bookings in 2010 (600% year-over-year growth), and to $22 million in bookings by 2011 (250% year-over-year growth). We had clearly found product-market fit!

Not only did it launch Acquia in rocket-ship growth, it also extended our stagnation point. We on-boarded many large organizations and showed that Drupal can scale very large. This helped unlock a lot of growth for both Drupal and Acquia. I can say with certainty that many large organization that now use Drupal would not have adopted Drupal without Acquia.

Helping to grow Drupal — or extending Drupal's stagnation point — was always part of Acquia's mission. From day one, we understood that for Acquia to grow, Drupal had to grow.

Launching Acquia Cloud was a great business decision for Acquia; it gave us product market fit, launched us in hockey-stick growth, but also extended our S-curve.

As I think about how Acquia has approached the Innovation S-curve, a few important lessons stand out. My recommendation is to focus on opportunities that accomplish two things:

  • Focus on business opportunities that serve a burning customer need that can launch or accelerate your organization.
  • Focus on business opportunities that remove long-term barriers to growth and push out the stagnation point.

OpenSense Labs: Cooking Drupal-based platform for food lovers

1 month ago
Cooking Drupal-based platform for food lovers Shankar Sun, 12/16/2018 - 23:50

Cooking something very delicious requires the right sort of ingredients and preparation. Serving delectable food can entice people and make them remember the taste for a long long time. Building a food-based website also requires the right platform that can engage people and offer ambitious digital experiences. This is where Drupal enters the scene.


As an open source CMS, Drupal is a reliable, secure and flexible platform and helps in creating the features that technology professionals want. It conforms with technical and business requirements and can be a great solution for powering the online presence of a food-based brand.

Drupal’s Greatness for Food-based Website

Drupal powers websites of some of the great names in the food industry like BBC Good Food, 24 Kitchen, Bosscaffe, Alevri among others. What prompts them to choose Drupal?

Drupal powers websites of some of the great names in the food industry Spectacular functionalities

Drupal offers a lot of modules, themes, and distributions that can help build a great food-based website.

For instance, a restaurant chain can use the make their Drupal website stylish with a free mobile-first, Bootstrap 3 based theme for Drupal called Restaurant Lite.

You can even leverage the benefits of Restaurant Zymphonies Theme which is another free mobile-first theme that can power the websites of restaurants, food stalls, hotels and other dining websites.

As a multifunctional, commercial profile created for intricate online stores, Food Delivery, a Drupal distribution, offers a complete starter pack for developing food-based websites.

Security

Drupal Security Team has been working round-the-clock validating and responding to security issues thereby making it one of the most secure open source CMS. Among the leading open source CMSs, it has been performing far better than Wordpress, Joomla and Magento.

Drupal is one of the most secure open source CMS Source: Alert LogicScalability

To help you cope with the busiest of days, Drupal can scale with your needs and can efficaciously handle a massive amount of traffic.

Multilingual

Drupal has out of the box support for building multilingual websites in the form of core modules that allows you to deliver localised digital experiences.

Mobile-responsive

Drupal helps in building responsive sites and web applications thereby allowing you to interact with your consumers on-the-go.


Speed

To run an agile team and ensure the continuous delivery of the web development project, Drupal’s pliable platform is superb. Furthermore, it helps in implementing performance optimisation techniques for building a high performing site.

Third-party integration

You can leverage the best tools outside the periphery of Drupal by integrating a variety of marketing technologies and business applications.

Content Workflow

Content authors can get awesome tools for creating and publishing content on the site. With the help of its preview feature, you can see how your content will look across various devices. Moreover, the authentication and permissions enhance the editorial workflow.

Content authors can get awesome tools for creating and publishing content on the site
Content architecture

Drupal lets you create the right content architecture and show appropriate content for each context with the help of great display mode tools, Views and a plentitude of media types.


Content-as-a-service

Its content as a service approach lets the front end developers build engaging customer experiences with Drupal’s presentation neutral content and RESTful API leveraging tools like Angular, Ember, Backbone and many more.

Multisite

Drupal’s immense capability in building a multisite architecture allows you to govern multiple websites across your enterprise brands, geographies and promotional campaigns on a  centralised platform.

Business-driven

You can build a solution that adheres to your business requirements and does things as your business demands.

Perfect tech stack

Drupal dwells on a modern LAMP technology stack comprising of Linux, Apache, MySQL and PHP which helps in fulfilling the needs of fast-moving, flexible, and agile enterprises in creating ambitious digital experiences.

Large community

Drupal’s vast community presence is one of its greatest strength as thousands of organisations create solutions with Drupal and in the process build Drupal itself.


Case study

24 Kitchen, one of the most popular platforms on food, cooking and lifestyle, has extracted the power of Drupal with the help of a digital agency to transform their presence in the digital landscape.

Search API Solr Search, a Drupal module for offering Solr backend, uses Apaches Solr servers for indexing and searching content and was utilised for related recipes in 24 Kitchen website development. The amazing capabilities of Fast Autocomplete module merged the extensive database of videos with the recipe’s database thereby allowing the retrieval of thousands of recipes that come with recommendations based on preference and user parameters.

Without any developer’s interference, the content editor could create flexible layout components, new pages and formats. This was made possible by paragraphs module. Through smart widgets, high-value content was disclosed which allowed other websites to directly query and present content from the 24 Kitchen within their own website. 

The Drupal website of 24 Kitchen has been very advantageous for marketing and sales with its boundless integration with the 24 Kitchen television format. It has paved the way for working with partners on promotional campaigns and cross-selling via numerous national news and lifestyle sites. The Drupal-powered website made it possible for content syndication and serving content to the consumers when relevant (for example, the Widgets and Facebook recipe bot). Ultimately, the redressal of 24 Kitchen website with the help of Drupal’s monumental capabilities resulted in staggering growth in page views.

Conclusion

Drupal offers a stupendous platform for building a powerful food-based website and allows the enterprises to grow as a brand.

We love Drupal and have been in our constant pursuit of delivering high quality and innovative solutions with our expertise in Drupal development.

Contact us at hello@opensenselabs.com to build a food-based site using Drupal.

blog banner blog image Blog Type Articles Is it a good read ? On

OpenSense Labs: Conversational Commerce: From a Whisper to a Roar

1 month ago
Conversational Commerce: From a Whisper to a Roar Shankar Sun, 12/16/2018 - 23:07

We are continuing our march towards becoming an AI-first world where the mobile centricity is getting replaced with personalised user-centricity. This is an age where conversational commerce and artificial intelligence (AI) as a utility are altering the way we communicate with brands and with each other. One of the great examples is the LivePerson’s LiveEngage. As a leading conversational commerce platform, it allows the students of Barry University to interact over popular messaging services. They can ask anything ranging from the application processes to the courses available in a convenient manner like they do with their friends and family.


Conversational commerce is already making great inroads and is revolutionising the way consumers and brands interact with each other. It has the potential of being a curator of services and experiences that can intelligently fulfill the needs and engage consumers emotionally anytime and anywhere. Drupal Commerce, an open source e-commerce solution, can help in implementing conversational commerce. Before we look at Drupal Commerce’s capabilities for this implementation, let’s explore conversational commerce first.

Conversational Commerce: Explained  Source: Mücke, Sturm & Company GmbH

From the traditional point of sale systems (POS) to mobile commerce, we have seen it all. They have paved the way for conversational commerce which can dramatically metamorphose out shopping experience by leading a new era of individualised shopping.

Chris Messina coined the term Conversational Commerce looking at the dominant trend of consumer computing apps which came to life in 2015 with Uber’s integration into Facebook Messenger. He described it as a solution that can deliver “convenience, personalization, and decision support while people are on the go with only partial attention to spare”.

Conversational commerce is about delivering convenience, personalization, and decision support while people are on the go, with only partial attention to spare. - Chris Messina

Conversational Interfaces leverages the power of AI whilst using the technologies that consumers relish using like messaging, voice interface or other natural language interfaces thereby enabling people to interact with brands or services through bots.

With the objective of delivering a top-of-the-line customer experience, it helps in replicating the one-on-one, in-store salesperson experience with the consumers. Whether you are buying clothes, ordering food from a hotel, or making a financial transaction, conversational commerce is here to revolutionise the business model.

Why is Conversational Commerce Important?

Comscore states that 85% of the smartphone time is being spent on social media, messenger and other media applications. Moreover, by 2021, the number of users using digital voice assistants is projected to reach 1.8 Billion.

Massive adoption of messaging applications along with the rise of conversational, AI-powered technology can streamline the process of making one-on-one conversations at scale. And as people distance themselves from clicks and taps and inch towards conversational UI, more adoption of conversational commerce can be witnessed in the coming years as it promises a slew of benefits which are stated below:

  • Driving customer satisfaction: Offering voice assistants can enhance brands’ Net Promoter Scores (NPS®) thereby driving customer satisfaction.

 

  • Generating more business: Enterprises will be able to generate more business and positive word-of-mouth

 

 

  • Increasing consumer spending: Consumers show the willingness to increase their spending with a brand when they receive a good voice assistant experience.

 

  • Focussing on priority consumer segments: Enterprises that emphasise on the segmentation of priority consumers like targeting users who prefer voice assistants for purchases will bring in great value.

How does Conversational Commerce Work?

There are different ways to look at conversational commerce in action. One of the types of experiences can be a proactive model. In this, the customer buys something for the very first time from a shop and receive an automated message with greetings and thanking them for shopping at that store. Another working model can be a reactive approach. In this, a customer buys a defective product from a shop and seek assistance. In response, the shop guides them through a solution.

Source: Chatbots Magazine

Furthermore, there can be one-to-one and one-to-many working models. If a shop sends a message and personalised offer to a customer who has applauded their service on Twitter, this comes under the one-to-one approach. Suppose a restaurant chain has opened a new store. They can send a custom message to a targeted audience segment who live nearby. This comes under the one-to-many approach.

Also, a digital voice assistant like Amazon Alexa and Google Home can assist the consumer in finding stores, hotels, events and much more. It can also recommend products, access customer care service, book a cab, or even control smart home devices.

Conversational Commerce with Drupal

Decoupled Drupal Days 2018 had a session which showed how to integrate bots in Drupal Commerce. When it comes to bot’s business logic, Drupal Commerce turned out to be a great solution in addition to its robust capabilities in storing content and product details. Moreover, Drupal, being an API-first CMS, offers a plethora of APIs out-of-the-box and the Commerce Cart API module makes it easy to interact with carts in Drupal Commerce.


It showed how decoupled Drupal Commerce, bot frameworks and Natural Language Understanding (NLU) can be leveraged for providing a boundless shopping experience to the e-commerce websites which are built on Drupal using Drupal services layer.

Decoupled Drupal Commerce, bot frameworks and Natural Language Understanding can be leveraged for providing a boundless shopping experience

The session focussed on Drupal 8 core services and the creation of custom REST APIs. It also laid emphasis on utilising decoupled Drupal Commerce APIs and using Node.js and Bot framework for building a chatbot.

In addition to this, it also talked about the bot frameworks and other cognitive services that can be used to develop bots for different use cases. Several bot frameworks were considered like Facebook Messenger (wit.ai), Google Dialogflow, IBM Watson, Microsoft Bot Framework and open source conversational AI like Rasa. Ultimately, it all started with a framework called Open Source Bot Builder SDK for Node.js which is used for building bots. The application was hosted on Heroku and the Microsoft Bot Framework was used to integrate with Facebook.

In the demonstration, some of the common e-commerce functionalities like search, exploring products and many more were exposed as REST APIs. The main idea was that the bots will enable search and explore the products by incorporating Drupal Commerce APIs. On the basis of message-based interaction, bots can also enable simple Add To Cart and Review Cart functionality among others and can offer relevant actions while looking for a product.

Conclusion

Conversational Commerce represents an astronomical opportunity for the brands and the retailers alike. It can enable them to interact with their consumers in a new and innovative way. Enterprises must extract the power of this interaction opportunity for building relationships of value with consumers across the lifecycle.

Conversational Commerce, along with Drupal Commerce, can help the organisations to offer a completely new and more instinctive way for consumers to engage with them.

We have been steadfast in our goals of powering digital innovation for the enterprises with our expertise in Drupal development.

Contact us at hello@opensenselabs.com to implement conversational commerce in your business.

blog banner blog image Conversational Commerce Drupal 8 Drupal Commerce Blog Type Articles Is it a good read ? On

OpenSense Labs: Creating a Custom REST Resource for GET Method in Drupal 8

1 month ago
Creating a Custom REST Resource for GET Method in Drupal 8 Anmol Sun, 12/16/2018 - 16:44

As the world gets more connected, web technologies too, need to get connected. RESTful web services can be used as an application program interface to connect various service.

This can be made possible by using HTTP requests to GET, PUT, POST and DELETE data. It is based on representational state transfer (REST) technology, an architectural style, and approach to communications often used in web services development. 

With decoupled development getting the ground, it has become important for the developers to understand teh REST technology better. Drupal provides its developers an in-house build method to use this REST technology. RESTful Web Services module, which is now a part of Drupal core, provides REST services to its developers. 

It allows users to read or update data on the site. 

Different verbs or request methods that are used for the approach are:

GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT and PATCH

The GET method allows the user to access various entities like Node, User, Taxonomy, Comments and even watchdog database log entries. GET method is a SAFE method as there is no database manipulation operation, it is a read-only request.

Unlike GET, in the POST method, database manipulation takes place. The user can update the database and create a node if need be. 

Creating REST Resource Plugins

REST resource plugins are important to expose additional resources over REST. In the steps below we will create a basic example for understanding the fundamental functionality of developing REST resource endpoint which takes a content type as argument and returns title and node ids of all nodes of that particular content-type.

  • Create the staging code for REST resource with the following Drupal console command:
drupal generate:plugin:rest:resource

You can also generate the staging code manually by creating a plugin file under src in the custom module > Plugin > Rest > Resource > {ResourceClassName}.php

Next, define the namespace, dependencies, and the plugin class as given in the example below.

  • Next, you need to create the @RestResource annotation. It helps you indicate the dependencies, and status of the class. Another important point to consider is that the URL mapping is case-sensitive.

    We must also be careful with the  @RestResource  annotation's urli_paths  which take link relation types as keys, and partial URIs as values. If you don't specify any, Drupal will automatically generate URI paths (and hence URLs) based on the plugin ID. 

    If your plugin ID is rest_example, you'll end up with/rest_example/{id}  for GET|PATCH|DELETE and /rest_example for POST . But, often, you'll want to specify your own paths: a canonical URI path (for example /todo/{todo_id}). For example:

* uri_paths = { * "canonical" = "/rest_example/{id}", * }

Here’s how to get the complete REST resource GET request

<?php namespace Drupal\rest_example\Plugin\rest\resource; use Drupal\rest\ModifiedResourceResponse; use Drupal\rest\Plugin\ResourceBase; use Drupal\rest\ResourceResponse; use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException; /**  * Provides a resource to get view modes by entity and bundle.  *  * @RestResource(  *   id = "rest_example",  *   label = @Translation("Rest example"),  *   uri_paths = {  *     "canonical" = "/rest/api/get/node/{type}"  *   }  * )  */ class RestExample extends ResourceBase {   /**    * Responds to GET requests.    *    * @return \Drupal\rest\ResourceResponse    *   The HTTP response object.    *    * @throws \Symfony\Component\HttpKernel\Exception\HttpException    *   Throws exception expected.    */   public function get($type = NULL) {     // You must to implement the logic of your REST Resource here.     // Use current user after pass authentication to validate access.     if (!(\Drupal::currentUser)->hasPermission('access content')) {        throw new AccessDeniedHttpException();      }     if($type) {       $nids = \Drupal::entityQuery('node')->condition('type',$type)->execute();       if($nids){         $nodes =  \Drupal\node\Entity\Node::loadMultiple($nids);         foreach ($nodes as $key => $value) {           $data[] = ['id' => $value->id(),'title' => $value->getTitle()];         }       }     }     $response = new ResourceResponse($data);     // In order to generate fresh result every time (without clearing      // the cache), you need to invalidate the cache.     $response->addCacheableDependency($data);     return $response;   } }

Output 

[   {     "id": "67",     "title": "Consectetuer Sits"   },   {     "id": "69",     "title": "Eum Paulatim"   },   {     "id": "70",     "title": "Tation"   } ]
Configuring the REST Resources

In the config file, we define which HTTP method, serialization format, and an authentication mechanism is supported by the plugin. 

This config file is necessary to use the REST resource plugin. There are two ways to configure the REST resource @RestResource plugin:

  1. REST UI Module
     
    • The REST UI module is not part of the core. So you have to download it and install it like any other module in your Drupal site.

       

    • Once installed, go to  /admin/config/services/rest and enable your REST Resource.

       

    • Select your desired settings. To have hal_json format, you can enable Drupal Core’s HAL module.
  2. Manually
    • Go to the config directory and create a config file with name as rest.resource.{resource id}.yml.
    • Add the following content.
langcode: en status: true dependencies: module: - rest_example - serialization - user id: rest_example plugin_id: rest_example granularity: resource configuration: methods: - GET formats: - json authentication: - cookie
  • Save this file as rest.resource.plugin_id.yml (rest.resource.rest_example.yml in this case) in your config directory and run config sync.

Defining your resource config:

Status: true/false ( enable or disable) Id: unique id Plugin_id: unique id configuration=>methods: Name all request method you want to use in this plugin configuration=>formats: Define all supported serialized format configuration=>authentication: Name all supported authentication method. By default, the REST module supports json and xml

Key Point: Each REST resource must be annotated with  @RestResource  annotation so they can be discovered by RESTful Web Services module.

Custom REST API is useful in sending data to third-party applications and for headless architecture. As of today, there is hardly any project or application that doesn't have a REST API. Connect with us at hello@opensenselabs.com to help you create

blog banner blog image Blog Type Tech Is it a good read ? On

Red Route: A framework for progressively decoupled Drupal: Introducing the SPALP module

1 month ago

This article was originally posted on the Capgemini Engineering blog

A lot of people have been jumping on the headless CMS bandwagon over the past few years, but I’ve never been entirely convinced. Maybe it’s partly because I don’t want to give up on the sunk costs of what I’ve learned about Drupal theming, and partly because I'm proud to be a boring developer, but I haven’t been fully sold on the benefits of decoupling.

On our current project, we’ve continued to take an approach that Dries Buytaert has described as "progressively decoupled Drupal". Drupal handles routing, navigation, access control, and page rendering, while rich interactive functionality is provided by a JavaScript application sitting on top of the Drupal page. In the past, we’d taken a similar approach, with AngularJS applications on top of Drupal 6 or 7, getting their configuration from Drupal.settings, and for this project we decided to use React on top of Drupal 8.

There are a lot of advantages to this approach, in my view. There are several discrete interactive applications on the site, but the bulk of the site is static content, so it definitely makes sense for that content to be rendered by the server rather than constructed in the browser. This brings a lot of value in terms of accessibility, search engine optimisation, and performance.

A decoupled system is almost inevitably more complex, with more potential points of failure.

The application can be developed independently of the CMS, so specialist JavaScript developers can work without needing to worry about having a local Drupal build process.

If at some later date, the client decides to move away from Drupal, or at the point where we upgrade to Drupal 9, the applications aren’t so tightly coupled, so the effort of moving them should be smaller.

Having made the decision to use this architecture, we wanted a consistent framework for managing application configuration, to make sure we wouldn't need to keep reinventing the wheel for every application, and to keep things easy for the content team to manage.

The client’s content team want to be able to control all of the text within the application (across multiple languages), and be able to preview changes before putting them live.

There didn’t seem to be an established approach for this, so we’ve built a module for it.

As we've previously mentioned, the team at Capgemini are strongly committed to supporting the open source communities whose work we depend on, and we try to contribute back whenever we can, whether that’s patches to fix bugs and add new features, or creating new modules to fill gaps where nothing appropriate already exists. For instance, a recent client requirement to promote their native applications led us to build the App Banners module.

Aiming to make our modules open source wherever possible helps us to think in systems, considering the specific requirements of this client as an example of a range of other potential use cases. This helps to future-proof our code, because it’s more likely that evolving requirements can be met by a configuration change, rather than needing a code change.

So, guided by these principles, I'm very pleased to announce the Single Page Application Landing Page module for Drupal 8, or to use the terrible acronym that it has unfortunately but inevitably acquired, SPALP.

On its own, the module doesn’t do much other than provide an App Landing Page content type. Each application needs its own module to declare a dependency on SPALP, define a library, and include its configuration as JSON (with associated schema). When a module which does that is installed, SPALP takes care of creating a landing page node for it, and importing the initial configuration onto the node. When that node is viewed, SPALP adds the library, and a link to an endpoint serving the JSON configuration.

Deciding how to store the app configuration and make all the text editable was one of the main questions, and we ended up answering it in a slightly "un-Drupally" way.

On our old Drupal 6 projects, the text was stored in a separate 'Messages' node type. This was a bit unwieldy, and it was always quite tricky to figure out what was the right node to edit.

For our Drupal 7 projects, we used the translation interface, even on a monolingual site, where we translated from English to British English. It seemed like a great idea to the development team, but the content editors always found it unintuitive, struggling to find the right string to edit, especially for common strings like button labels. It also didn't allow the content team to preview changes to the app text.

We wanted to maintain everything related to the application in one place, in order to keep things simpler for developers and content editors. This, along with the need to manage revisions of the app configuration, led us down the route of using a single node to manage each application.

This approach makes it easy to integrate the applications with any of the good stuff that Drupal provides, whether that’s managing meta tags, translation, revisions, or something else that we haven't thought of.

The SPALP module also provides event dispatchers to allow configuration to be altered. For instance, we set different API endpoints in test environments.

Another nice feature is that in the node edit form, the JSON object is converted into a usable set of form fields using the JSON forms library. This generic approach means that we don’t need to spend time copying boilerplate Form API code to build configuration forms when we build a new application - instead the developers working on the JavaScript code write their configuration as JSON in a way that makes sense for their application, and generate a schema from that. When new configuration items need to be added, we only need to update the JSON and the schema.

Each application only needs a very simple Drupal module to define its library, so we’re able to build the React code independently, and bring it into Drupal as a Composer dependency.

The repository includes a small example module to show how to implement these patterns, and hopefully other teams will be able to use it on other projects.

As with any project, it’s not complete. So far we’ve only built one application following this approach, and it seems to be working pretty well. Among the items in the issue queue is better integration with configuration management system, so that we can make it clear if a setting has been overridden for the current environment.

I hope that this module will be useful for other teams - if you're building JavaScript applications that work with Drupal, please try it out, and if you use it on your project, I'd love to hear about it. Also, if you spot any problems, or have any ideas for improvements, please get in touch via the issue queue.

Tags:  Capgemini development Drupal Javascript open source All tags

OpenSense Labs: SCORM and E-Learning. Can Drupal Fit In?

1 month ago
SCORM and E-Learning. Can Drupal Fit In? Vasundhra Fri, 12/14/2018 - 17:32

Referred to as the de facto standard of e-learning, Shareable Content Object Reference Model aka SCORM was sponsored by US Department of Defense to bring uniformity in the standards of procuring both training content and Learning Management Systems. 

Long gone but not forgotten are those days when learning was only limited to books and classrooms. With the development of technology, virtual learning has transformed into an approachable and convenient method.

Can Drupal, which is a widely popular CMS for education websites, conform to SCORM standards? How does it ensure that it remains SCORM compliant? 


In Details - What is SCORM?

SCORM is a set of standard guidelines and specifications for the programmers on how to create LMS and training content to be shared across systems. 

The agenda to bring SCORM was to create standard units of training and educational material to be shared and reused across systems. 
                           


Shareable Content Object refers to creating units of online training material that can be shared and reused across systems and contexts.

Reference Model refers to the existing standards in the education industry while informing developers on how to properly use them together.

Working with the authoring tools to design and produce the content, e-learning professionals, training managers, and instructional designers are the ones who typically use SCORM packages.

Content (used in courses and LMS) is exported to a SCORM package (.zip folder) to deliver the learners a seamless and smooth upload of the content.

The Evolution of SCORM

Since SCORM wasn’t built as a standard from the ground up and was primarily a reference to the existing ones, the goal was to create an interoperable system that will work well with other systems. 

Till date, there are three released versions of SCORM, each built on top of the previous one solving the problem of its predecessor.

SCORM 1.0 was merely a draft outline of the framework. It did not include any fully implementable specifications but rather contained a preview of work which was yet to come. 

SCORM 1.0 included the core elements that would become the foundation of SCORM.  

In other words, this version specified how the content should be packaged. How content should communicate to systems and how the content should be described.

  • SCORM 1.1

SCORM 1.1 was the first implementable version of SCORM. It marked the end of the trial implementation phase and the beginning of the application phase for ADL. 

  • SCORM 1.2

SCORM 1.2 solved the many problems that came along version 1.1. It provided with robust and implementable specifications, this version presented its end users with drastic cost savings. 

It was and still remains one of the most widely used version.

  • SCORM 2004 (1st - 4th edition)

The 2004 1st edition allowed content vendors to create navigation rules between SCOs. The 2nd edition covered the various shortcomings of the 1st. It brought with it Advanced Distributed Learning which focused on developing and assessing the distributed learning prototypes, enabling more effective, efficient, & affordable learner-centric solutions.

The 3rd edition removed any ambiguity, improving the sequencing specifications for greater interoperability.

The final and 4th edition was focused on disambiguation and addition of new sequencing specifications. These specifications widened the options available to the content authors which made the creation of sequenced content even more simple.
 


Why Should You Use SCORM?

Now that we have an idea about SCORM and its attempt of reducing chaos in the entire industry, let’s know what benefits it brings along. 

Here are some of the reasons that can contribute to a huge factor in terms of using SCORM.

  • It is a pro-consumer initiative. The online courses are eligible to be used on any compliant LMS vendor. You can alternatively upload the courses to LMS as long as you have a zip folder.
  • All the high-quality LMSs and the authoring tools are SCORM compliant so that they can build and be part of a great ecosystem of interoperability and reliability.
  • The introduction and evolution in SCORM have brought about a great reduction in overall cost of delivering training. The reason is that it has no additional cost for integrating any type of content. 
  • SCORM helps in standardizing eLearning specifications. SCORM provides a set of technical specifications that gives the developers a standard blueprint to work with.
How does SCORM Work?

Other than guiding the programmers, SCORM administers two main things, i.e packaging content and exchanging data at runtime to ensure workability. 

  • Packaging content or content aggregation model (CAM) defines how a piece of content should be presented in a physical sense. It is required by the LMS to export and import a launch content without the use of any human interventions
  • Runtime communication or data exchange helps in defining how the content is supposed to work with the LMS while it is actually being played. This is the part which describes the delivery and tracking of the content. Eventually, these are the things that include “request the learner’s name” or “tell the LMS that the learner scored 95% in a test”. 
“SCORM recommends contents to be delivered in a self-contained directory or a ZIP file.”
Working of SCORM Packages

SCORM recommends contents to be delivered in a self-contained directory or a ZIP file. These files contain content, defined by the SCORM standards and is called Package Interface File (PIF) or in other words SCORM packages. 

It contains all the files that are needed to be delivered in the content packages via SCORM runtime environment. 

Course manifest files are considered as the heart of the SCORM content packaging system. The manifest is considered as the XML file that describes the content. 

Some of the pieces involved in the packaging are:

  • Resources 

Resources are the list of parts that bundle up to be a single course. There are two types of resources that contribute to the course.

The first is the collection of one or more files that make up a logical unit presented to the users. The other is SCO or Sharable Content Object which is the unit of instructions that are composed of one or more files, to communicate with LMS. It mostly contains the instructional or static part of a content that is presented to the users via course. 

Resources should contain a complete list of all the files that are required for proper functionality of the resources. 

This is done to port the list to a new environment and function it the similar way. 

 

  • Organizations

Organizations are considered as the logical grouping of the parts of resources into a hierarchical arrangement. This is what is delivered to a particular learner when the item has been selected. 

  • Metadata 

Metadata are used to describe elements of a content package in its manifest file. They are important because they facilitate the discovery of learning resources across content package or in a repository. 

When a learning resource is intended to be reusable, it is a best practice to describe it with metadata. 

For describing learning content, Learning Object Metadata contains many predefined fields.   
  • Sequencing

Sequencing is responsible for determining what happens next when a learner exits an SCO. With navigational control, it orchestrates the flow and status of the course as a whole. 

However, it doesn’t affect how SCOs operate and navigate internally, that is defined by the content developer.

Drupal With SCORM 

Drupal is best at managing the digital content, but the task of planning, implementing, and assessing a specific learning process can be best done by an LMS.

How can Drupal become a platform for an organization that delivers effective training, manage learners, individual progress and record results?

Since Drupal is not an LMS, its distributions and modules help it become more effective. When it comes to SCORM compliance, Drupal has Opigno LMS as its core distribution.  

Opigno LMS is a Drupal distribution that integrates H5P technology (an open-source content collaboration framework based on javascript), which enable you to create rich interactive training content. It allows you to maintain the training paths that are organized in courses and lessons. 

This distribution includes the latest version of Opigno core that offers you effective and innovative online training tools.

Opigno LMS is fully compliant with SCORM (1.2 and 2004 v3) which offers a powerful editor for content management, in particular, to create course material. These courses can eventually be grouped into classes to provide easy and manageable training paths. It should also be noted that this distribution is the quickest way to present a functional e-learning platform out of the box, with the users, courses, certificates, etc. 

Based on this distribution, Opigno SCORM implements the SCORM feature in Opigno which allows you to load and play SCORM packages within Opigno training and is also responsible to handle and manage training paths that are organized in courses and lessons. 

Opigno LMS comprises an app store that also enables you to install latest features easily, without asking you to upgrade the current install. 

According to the requirements and expectations of the learners, Opigno LMS can be summarized by the following specification:

  1. Scalable to manage the hardships of a dynamic and modifying environment
  2. Safe and easy to update
  3. Support further development of customized functionalities with proper integration with the core solution in a modular way
  4. Open to letting each client be free and independent
  5. And most importantly, easy integration with other enterprise systems 

H5P javascript framework makes it easy to create, share and reuse HTML5 content and applications, allowing users to built richer content. With the use of H5P, the authors can edit and construct videos, presentation games, advertisement etc. To create an e-learning platform, the integration of HP5 framework and SCORM is essential.  


H5P SCORM/xAPI module allows to upload and view SCROM and xAPI packages. It uses two HP5 libraries namely (HP5 libraries are used to create and share rich content and applications)

  1. H5P SCORM/xAPI library to view SCORM package.
  2. H5PEditor SCORM library to upload and validate SCORM package.

You can create a new content type by uploading it in the preceding step of a process using the H5P editor.

In the nutshell

Different people adopt SCORM for different reasons. You and your team are the only ones that can decide whether sticking to SCORM is worthwhile or not. 

Depending upon the nature of your requirement and the course of action, it can be decided which platform is best for you. At OpenSense labs, we have been giving adequate solutions to our customers. Contact us on hello@opensenselabs.com to make the right decision on the correct choice of a platform. 

blog banner blog image Drupal Drupal 8 SCORM LMS Learning Management System Shareable Content Object Reference Model SCORM 1.0 SCORM 1.1 SCORM 1.2 SCORM 2004 E-learning Content Aggregation Model Organization Sequencing Resource Opigno LMS Blog Type Articles Is it a good read ? On

Capgemini Engineering: A framework for progressively decoupled Drupal

1 month ago

A lot of people have been jumping on the headless CMS bandwagon over the past few years, but I’ve never been entirely convinced. Maybe it’s partly because I don’t want to give up on the sunk costs of what I’ve learned about Drupal theming, and partly because I’m proud to be a boring developer, but I haven’t been fully sold on the benefits of decoupling.

On our current project, we’ve continued to take an approach that Dries Buytaert has described as “progressively decoupled Drupal”. Drupal handles routing, navigation, access control, and page rendering, while rich interactive functionality is provided by a JavaScript application sitting on top of the Drupal page. In the past, we’d taken a similar approach, with AngularJS applications on top of Drupal 6 or 7, getting their configuration from Drupal.settings, and for this project we decided to use React on top of Drupal 8.

There are a lot of advantages to this approach, in my view. There are several discrete interactive applications on the site, but the bulk of the site is static content, so it definitely makes sense for that content to be rendered by the server rather than constructed in the browser. This brings a lot of value in terms of accessibility, search engine optimisation, and performance.

A decoupled system is almost inevitably more complex, with more potential points of failure.

The application can be developed independently of the CMS, so specialist JavaScript developers can work without needing to worry about having a local Drupal build process.

If at some later date, the client decides to move away from Drupal, or at the point where we upgrade to Drupal 9, the applications aren’t so tightly coupled, so the effort of moving them should be smaller.

Having made the decision to use this architecture, we wanted a consistent framework for managing application configuration, to make sure we wouldn’t need to keep reinventing the wheel for every application, and to keep things easy for the content team to manage.

The client’s content team want to be able to control all of the text within the application (across multiple languages), and be able to preview changes before putting them live.

There didn’t seem to be an established approach for this, so we’ve built a module for it.

As we’ve previously mentioned, the team at Capgemini are strongly committed to supporting the open source communities whose work we depend on, and we try to contribute back whenever we can, whether that’s patches to fix bugs and add new features, or creating new modules to fill gaps where nothing appropriate already exists. For instance, a recent client requirement to promote their native applications led us to build the App Banners module.

Aiming to make our modules open source wherever possible helps us to think in systems, considering the specific requirements of this client as an example of a range of other potential use cases. This helps to future-proof our code, because it’s more likely that evolving requirements can be met by a configuration change, rather than needing a code change.

So, guided by these principles, I’m very pleased to announce the Single Page Application Landing Page module for Drupal 8, or to use the terrible acronym that it has unfortunately but inevitably acquired, SPALP.

On its own, the module doesn’t do much other than provide an App Landing Page content type. Each application needs its own module to declare a dependency on SPALP, define a library, and include its configuration as JSON (with associated schema). When a module which does that is installed, SPALP takes care of creating a landing page node for it, and importing the initial configuration onto the node. When that node is viewed, SPALP adds the library, and a link to an endpoint serving the JSON configuration.

Deciding how to store the app configuration and make all the text editable was one of the main questions, and we ended up answering it in a slightly “un-Drupally” way.

On our old Drupal 6 projects, the text was stored in a separate ‘Messages’ node type. This was a bit unwieldy, and it was always quite tricky to figure out what was the right node to edit.

For our Drupal 7 projects, we used the translation interface, even on a monolingual site, where we translated from English to British English. It seemed like a great idea to the development team, but the content editors always found it unintuitive, struggling to find the right string to edit, especially for common strings like button labels. It also didn’t allow the content team to preview changes to the app text.

We wanted to maintain everything related to the application in one place, in order to keep things simpler for developers and content editors. This, along with the need to manage revisions of the app configuration, led us down the route of using a single node to manage each application.

This approach makes it easy to integrate the applications with any of the good stuff that Drupal provides, whether that’s managing meta tags, translation, revisions, or something else that we haven’t thought of.

The SPALP module also provides event dispatchers to allow configuration to be altered. For instance, we set different API endpoints in test environments.

Another nice feature is that in the node edit form, the JSON object is converted into a usable set of form fields using the JSON forms library. This generic approach means that we don’t need to spend time copying boilerplate Form API code to build configuration forms when we build a new application - instead the developers working on the JavaScript code write their configuration as JSON in a way that makes sense for their application, and generate a schema from that. When new configuration items need to be added, we only need to update the JSON and the schema.

Each application only needs a very simple Drupal module to define its library, so we’re able to build the React code independently, and bring it into Drupal as a Composer dependency.

The repository includes a small example module to show how to implement these patterns, and hopefully other teams will be able to use it on other projects.

As with any project, it’s not complete. So far we’ve only built one application following this approach, and it seems to be working pretty well. Among the items in the issue queue is better integration with configuration management system, so that we can make it clear if a setting has been overridden for the current environment.

I hope that this module will be useful for other teams - if you’re building JavaScript applications that work with Drupal, please try it out, and if you use it on your project, I’d love to hear about it. Also, if you spot any problems, or have any ideas for improvements, please get in touch via the issue queue.

A framework for progressively decoupled Drupal was originally published by Capgemini at Capgemini Engineering on December 14, 2018.

Checked
1 hour 7 minutes ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Planet Drupal feed