Jan 16 2019
Jan 16

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Eighteen years ago today, I released Drupal 1.0.0. What started from humble beginnings has grown into one of the largest Open Source communities in the world. Today, Drupal exists because of its people and the collective effort of thousands of community members. Thank you to everyone who has been and continues to contribute to Drupal.

Eighteen years is also the voting age in the US, and the legal drinking age in Europe. I'm not sure which one is better. :) Joking aside, welcome to adulthood, Drupal. May your day be bug free and filled with fresh patches!

Jan 16 2019
Jan 16

by David Snopek on January 16, 2019 - 12:47pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2019-002

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there was another Drupal core security release made today (SA-CORE-2019-001) but that one doesn't affect Drupal 6, because Drupal 6 doesn't bundle the Archive_Tar library. However, that vulnerability may affect custom or contrib modules on your site.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Jan 16 2019
Jan 16
Project: Drupal coreDate: 2019-January-16Security risk: Critical 16∕25 AC:Complex/A:Admin/CI:All/II:All/E:Theoretical/TD:AllVulnerability: Arbitrary PHP code executionCVE IDs: CVE-2019-6339Description: 

A remote code execution vulnerability exists in PHP's built-in phar stream wrapper when performing file operations on an untrusted phar:// URI.

Some Drupal code (core, contrib, and custom) may be performing file operations on insufficiently validated user input, thereby being exposed to this vulnerability.

This vulnerability is mitigated by the fact that such code paths typically require access to an administrative permission or an atypical configuration.

Solution: 
  • If you are using Drupal 8.6.x, upgrade to Drupal 8.6.6.
  • If you are using Drupal 8.5.x or earlier, upgrade to Drupal 8.5.9.
  • If you are using Drupal 7.x, upgrade to Drupal 7.62.

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Known issues

This fix introduced a fatal error for some Drush installations when updating a site with Drush. New releases (8.6.7, 8.5.10, and 7.63) have been issued to resolve this regression. See the release notes for additional details.

Update information

.phar added to dangerous extensions list

The .phar file extension has been added to Drupal's dangerous extensions list, which means that any such file uploaded to a Drupal file field will automatically be converted to a text file (with the .txt extension) to prevent it from being executed. This is similar to how Drupal handles file uploads with a .php extension.

phar:// stream wrapper disabled by default for Drupal 7 sites on PHP 5.3.2 and earlier

The replacement stream wrapper is not compatible with PHP versions lower than 5.3.3. Drupal 8 requires a higher PHP version than that, but for Drupal 7 sites using lower PHP versions, the built-in phar stream wrapper has been disabled rather than replaced. Drupal 7 sites using PHP 5.2 (or PHP 5.3.0-5.3.2) that require phar support will need to re-enable the stream wrapper for it; however, note that re-enabling the stream wrapper will re-enable the insecure PHP behavior on those PHP versions.

It is very uncommon to both be running a PHP version lower than 5.3.3 and to need phar support. If you're in that situation, consider upgrading your PHP version instead of restoring insecure phar support.

Reported By: Fixed By: 

Additional information

Note: Going forward, Drupal core will issue individual security advisories for separate vulnerabilities included in the release, rather than lumping "multiple vulnerabilities" into a single advisory. All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Jan 16 2019
Jan 16
Project: Drupal coreDate: 2019-January-16Security risk: Critical 16∕25 AC:Complex/A:User/CI:All/II:All/E:Proof/TD:UncommonVulnerability: Third Party Libraries CVE IDs: CVE-2019-6338Description: 

Drupal core uses the third-party PEAR Archive_Tar library. This library has released a security update which impacts some Drupal configurations. Refer to CVE-2018-1000888 for details.

Solution: 
  • If you are using Drupal 8.6.x, upgrade to Drupal 8.6.6.
  • If you are using Drupal 8.5.x or earlier, upgrade to Drupal 8.5.9.
  • If you are using Drupal 7.x, upgrade to Drupal 7.62.

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Reported By: Fixed By: 

Known issues

Users are reporting seeing a fatal error when updating their sites with Drush. Site owners may be able to run drush updb and either drush cc all or drush cr depending on the version to complete the update. Check the status report afterward to confirm that Drupal has been updated. See https://www.drupal.org/project/drupal/issues/3026386 for details.

Additional information

Note: Going forward, Drupal core will issue individual security advisories for separate vulnerabilities included in the release, rather than lumping "multiple vulnerabilities" into a single advisory. All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Jan 16 2019
Jan 16

Accidentally creating duplicate content in Drupal is like... a cold: 

Catching it is as easy as falling off a log.

All it takes is to:
 

  • further submit your valuable content on other websites, as well, and thus challenging Google with 2 or more identical pieces of content
  • move your website from HTTP to HTTPs, but skip some key steps in the process, so that the HTTP version of your Drupal is still there, “lurking in the dark”
  • have printer-friendly versions of your Drupal site and thus dare Google to face another duplicate content “dilemma”
     

So, what are the “lifebelts” or prevention tools that Drupal “arms” you with for handling this thorny issue?

Here are the 4 modules to use for boosting your site's immunity system against duplicate content.

And for getting it fixed, once the harm has already been made:
 

1. But How Does It Crawl into Your Website? Main Sources of Duplicate Content 

Let's get down to the nitty-gritty of how Drupal 8 duplicate content “infiltrates” into your website.

But first, here are the 2 major categories that these sources fall into:
 

  • malicious
  • non-malicious
     

The first ones include all those scenarios where spammers post content from your website without your consent.

The non-malicious duplicate content can come from:
 

  • discussion forums that create both standard and stripped-down pages (for mobile devices)
  • printer-only web page versions, as already mentioned
  • items displayed on multiple pages of the same e-commerce site
     

Also, duplicate content in Drupal can be either:
 

  • identical
  • or similar

And since it comes in “many stripes and colors”, here are the 7 most common types of duplicate content:
 

1.1. Scraped Content

Has someone copied content from your website and further published it? Do not expect Google to distinguish the copy from its source.

That said, it's your job and yours only to stay diligent and protect the content on your Drupal site from scrapers.
 

1.2. WWW and non-WWW Versions of Your Website

Are there 2 identical version of your Drupal website available? A www and a non-www one?

Now, that's enough to ring Google's “duplicate content in Drupal” alarm.
 

1.3. Widely Syndicated Content 

So, you've painstakingly put together a list of article submission sites to give your valuable content (blog post, video, article etc.) more exposure.

And now what? Should you just cancel promoting it?

Not at all! Widely syndicated content risks to get on Google's “Drupal 8 duplicate content” radar only if you set no guidelines for those third-party websites.

That is when these publishers don't place any canonical tags in your submitted content pointing out to its original source.

What happens when you overlook such a content syndication agreement? You leave it entirely to Google to track down the source. To scan through all those websites and blogs that your piece of content gets republished on.

And often times it fails to tell the original from its copy.
 

1.4. Printed-Friendly Versions

This is probably one of the sources of duplicate content in Drupal that seems most... harmless to you, right?

And yet, for search engines multiple printer-friendly versions of the same content translates as: duplicate pages.
 

1.5. HTTP and HTTPs Pages

Have you made the switch from HTTP to HTTPs?

Entirely?

Or are there:
 

  • backlinks from other websites still leading to the HTTP version of your website?
  • internal links on your current HTTPs website still carrying the old protocol?
     

Make sure you detect all these less obvious sources of identical URLs on your Drupal website.
 

1.6. Appreciably Similar Content 

Your site's vulnerable to this type of duplicate content “threat” particularly if it's an e-commerce one.

Just think of all those too common scenarios where you display highly similar product descriptions on several different pages on your eStore. 
 

1.7. User Session IDs 

Users themselves can non-deliberately generate duplicate content on your Drupal site. 
How? They might have different session IDs that generate new and new URLs.


2. 4 Modules at Hand to Identify and Fix Duplicate Content in Drupal

What are the tools that Drupal puts at your disposal to detect and eliminate all duplicate content?
 

2.1. Redirect Module

Imagine all the functionality of the former Global Redirect module (Drupal 7) “injected” into this Drupal 8 module!

In fact, you can still define your Global Redirect features by just:
 

  1. accessing the Redirect module's configuration page
  2. clicking on “URL redirects” 
     

How to Deal with Duplicate Content in Drupal: Global Redirect features
Image Source: WEBWASH.net

What this SEO-friendly module does is provide you with a user-friendly interface for managing your URL path redirects:
 

  • create new redirects
  • identify broken URL paths (you'll need to enable the “Redirect 4040” sub-module for that)
  • set up domain level redirects (use the “Redirect Domain” sub-module)
  • import redirects
     

Summing up: when it comes to handling duplicate content in Drupal, this module helps you redirect all your URLs to the new paths that you will have set up.

This way, you avoid the risk of having the very same content displayed on multiple URL paths.
 

2.2. Taxonomy Unique Module  

How about “fighting” duplicate content on your website at a vocabulary level?

In this respect, this Drupal 8 module:
 

  • prevents you from saving a taxonomy term that already exists in that vocabulary
  • is configurable for every vocabulary on your Drupal site
  • allows you to set custom error messages that would pop up whenever a duplicate taxonomy term is detected in the same vocabulary
     

2.3. PathAuto Module  

Just admit it now:

How much do you hate the /node125 type of URL path aliases?

They're anything but user-friendly.

And this is precisely the role that Pathauto's been invested with:

To automatically generate content friendly path aliases (e.g. /blog/my-node-title) for a whole variety of content.

Let's say that you want to modify the current “path scheme” on your website with no impact on the URLs (you don't want the change to affect user's bookmarks or to “intrigue” the search engines).

The Pathauto module will automatically redirect those URLs to the new paths using any HTTP redirect status.
 

2.4. Intelligent Content Tools      

Personalization is key when you strive to prevent duplicate content in Drupal, right? 

And this is precisely what this module here does: it helps you personalize content on your website.

How? Through its 3 main functionalities delivered to you as sub-modules:
 

  • auto tagging
  • text summarizing 
  • detecting plagiarized content 
     

Leveraging Natural Language Processing, this last sub-module scans content on your website and alerts you of any signs of duplicity detected.

Word of caution: keep in mind that the module is not yet covered by Drupal's security advisory policy!
 

3. To Sum Up

Setting a goal to ensure 100% unique content on your website is as realistic as... learning a new language in a week. 

Instead, you should consider setting up a solid strategy ”fueled” by (at least) these 4 modules “exposed” here. One that would help you avoid specific scenarios where entire pages or clusters of pages get duplicated.

Now, that's a far less utopian goal to set, don't you think?

Jan 16 2019
Jan 16

Happy 18th birthday to Drupal!

We’re all engrossed in the mode of celebration and the festive fly game was on point. In fact, everyone else was too painted in that mood, cheering and celebrating the spirit of flying. But our zest for celebration was a notch hire, for our reason for celebration was doubled. 15th January is not merely a date when the kite-flying festival falls but that’s the very day when our dearest of all - Drupal came into existence!

Eighteen years before this very day, the very first version of Drupal - 1.0.0 was released by its founder - Dries Buytaert. And just as it happens with all other path-breaking changes world, this one too came with a lot of faith but a humble approach towards its future. And look, how proficiently has it grown in all these years. Today, it’s one of the largest and most-trusted open-source community and the future looks even brighter.  

In the age of data-threats, Drupal is trusted for its security, worldwide. Constantly moving towards strengthening the open-source community, Drupal has never compromised on the security, content, and scope. Drupal is also known for its power of personalisation and flexibility. Drupal Commerce is also the preferred one when it comes to building an easy-looking e-commerce platform with complex functionalities. And if that was not enough, the launch of Decoupled Drupal has blown the tech world like a boss!

We might sound a little biased here, but we’re speaking nothing but the truth. Everyone from ‘The Beatles’ to ‘Estee Lauder’, ‘Columbia University’, ‘NBC Universal’, ‘NBA’, ‘Paramount’ and many more have trusted and adapted Drupal for years now. Dries has rightly quoted about it in his birthday note for Drupal and let us also conclude, our birthday note for Drupal, on the very same note -

“What do the biggest brands in the world have in common?” - ‘Powered by Drupal!’

 

Jan 16 2019
Jan 16

It is not uncommon for a Drupal 8 project, because it has structured content, to develop many content types, each with many fields, which are themselves rendered in a different way through no less than many display modes. One of the consequences is that the design phase known as site building can then become extremely time-consuming, or even a source of many small and even more time-consuming omissions to correct / adjust (use of the same fields, associated help text, configuration of the form mode, display modes, etc.). And this can make this design phase appear to be the least motivating, although essential, phase.

For those who have already produced an ambitious Drupal 8 project, this must certainly bring back some memories.

Fortunately, with Drupal 8 we have two modules that allow us to significantly simplify and accelerate this phase. These are the Entity Clone and Field Tools modules. Let us briefly present these two modules to be consumed without moderation.

Entity clone

Entity Clone is a module that allows you to clone any content entity (or almost), including node, taxonomy terms, etc., but also some entity types and therefore content types. Thus, duplicating a complex content type, with many fields, can be done with a simple click, in a few seconds, then allowing to customize on a common and identical basis the different fields of a new type of content.

Its use is very simple. One click on the Clone operation and that's it.

Entity clone operation

In addition to the usual case of accelerating the site building phase of an ambitious project, this module can also be particularly useful in the context of a native multi-site architecture to provide semantically different but extremely similar content types in terms of configuration. And also in the context of a Drupal web Factory based on the Micro Site module, where this module can help us this time to clone the Site content entity, allowing us to create a new site, pre-configured and with existing content, with a simple click.

Its dual use both on content entities (which can save considerable time in terms of initial content production when it is relatively structured and rich, especially with paragraphs) and on entity types makes it particularly useful from all points of view. And to complete the table it should be mentioned that the Entity Clone module (in its dev version to date) is able to clone (or not, depending on the configuration of the module) any entity referenced by the cloned source entity. This is particularly effective for any content using paragraphs. Note the existence of a module, Entity Type Clone, with a more limited functional scope, focused on entity types, which I have not had the opportunity to test yet.

Field tools

The Field Tools module plays in another register. It allows you to duplicate fields, their display configurations, as well as display modes from one content type (or entity type in general) to one or more other bundles. This is particularly useful if you already have the different content types (and therefore cannot clone them) and you want to duplicate a field, a display mode, very quickly to other bundles. 

Its use is also rather intuitive. You can access the configuration page for each entity type from the Clone fields link in the list of available operations (as for the Entity Clone module) or from the Tools tab of the entity type.

Field tools usage

We can select the field(s) to duplicate, then select the different bundles to duplicate these fields to. A dreadful efficiency for anyone who has forgotten to add a field on the fifteen content types of a project.

By way of conclusion

These two modules can be added to your base module list for any Drupal 8 project. They can save you a multitude of clicks, many hours and most certainly also some omissions and errors for those who want to optimize the use of fields by a maximum transversal use through the different entity types of a Drupal 8 project. Whether it is in terms of initial design, or in terms of project maintenance, or even the subsequent exploitation of these fields through a business module. In any case, they have already saved me a lot of time, and certainly also kept the motivation of a Drupal developer intact. 

Jan 15 2019
Jan 15

[embedded content]

Eighteen years ago today, I released Drupal 1.0.0. What started from humble beginnings has grown into one of the largest Open Source communities in the world. Today, Drupal exists because of its people and the collective effort of thousands of community members. Thank you to everyone who has been and continues to contribute to Drupal.

Eighteen years is also the voting age in the US, and the legal drinking age in Europe. I'm not sure which one is better. :) Joking aside, welcome to adulthood, Drupal. May your day be bug free and filled with fresh patches!

January 15, 2019

23 sec read time

db db
Jan 15 2019
Jan 15

Open Source

Open source and me

For the past two years, I have been blogging about my experience building and maintaining the Webform module for Drupal 8 and have had some lively discussions about them all. As the Webform module moved from beta or release candidates, I shared my experience in two posts titled Webform 8.x-5.x: Where Do We Come From? What Are We? Where Are We Going? and Webform, Drupal, and Open Source...Where are we going?. Throughout my blog posts, the question persists…

How is open source sustainable?

Open source and organizations

In 2018, open source has become a success story, particularly for large organizations. As someone who has been building websites since Microsoft Internet Explorer 4.0 (1997), I see the fact that Microsoft is going to use the open source Chromium rendering engine as an amazing achievement for open source and even Microsoft. Microsoft has transformed from calling Linux a cancer to fully embracing open source collaboration.

Open source allows organizations to make a collaborative investment that provides them with a large technical return.

Organizations sponsor open source, however, the work is done by individual developers who may work for an organization or independently within the open source community.

What about individual software developers who contribute to open source? At what point do we recognize their part?

Open source and individuals

I recently wrote about Why I am one of the top contributors to Drupal? which explains my motives for my contribution to Drupal and my commitment to maintaining the Webform Module for Drupal 8 for the foreseeable future. One key reason behind my contribution is…

Open source allows individuals to share their passion with a collaborative community which improves their professional profile/resume.

The lone software developer has become a thing of the past. Modern software is a collective and collaborative process. Many software developers’ first experience with software collaboration is when using or contributing to an open source project. Ideally, the lone software developer becomes a member of the open source software community.

That said, building, maintaining, and sustaining collaborative communities where organizations and individuals work together is challenging.

Open Source and community

Growing, nurturing and building anything comes with a set of challenges and difficulties - open source projects are no exception. And this is where structure comes in. Structure, a system, a framework - whatever you want to call it - helps us gauge where we’ve been, where we’re going and where we want to be. Communities need to have some system of governance and sustainability. Open source projects are built by a loosely knit community of developers working together and making decisions.

The most common decision making roles in open source is the 'maintainer' because they help make sure a project continues to grow and work.

Maintainers need to be able to maintain their projects. Projects need to be maintained.

Open source and sustainability

The discussion around open source sustainability is ongoing. Danny Crichton at TechCrunch recently wrote a comprehensive essay about the current state of open source sustainability. It is a worthwhile read with useful background information and references.

There are several approaches to funding/supporting open source developers. To me, the most appealing approach is Open Collective because it is exploring how to collect and distribute funds for an open source project in a completely transparent way.

Open source software is typically created using full transparency. The problem of open source sustainability may be best solved using full transparency.

Open Collective

Open source and Open Collective

Open Collective is a platform for global collaborations to transparently collect and distribute funds.

Open Collective is trying to solve the much larger issue of global collaboration, and open source is one type of collaboration. Besides an open source project, an Open Collective can be set up for a meetup, a political group, or even a Drupal Camp.

Persuading people to contribute funds to an Open Collective requires a mix of marketing, messaging and incentives.

Open Collective and incentives

The strongest incentive to get anyone to do something is to provide a tangible result. Tangible results can be elusive when fixing a bug or upgrading some code. Finding the right messaging and incentives requires experimentation. Incentives should help people get the most out of the software. Incentives could be bug fixes, feature requests, support requests, documentation. If these experiments are successful with organizations and individuals backing and funding an Open Collective; the Open Collective will face its next challenge which is spending the money.

Once a project has money, it is up to the maintainers of that community to decide how to spend it.

-- https://techcrunch.com/2018/06/23/open-source-sustainability/ 

Open Collective and money

It is doubtful that most open source maintainers and contributors can be fully compensated for their late night hours and weekends contributing code, design, documentation, project management, and other expertise to an open source project.

We need to figure how to best spend the money in ways that provide a high return.

In the Drupal, we like to say “Come for the code, stay for the community.” Communities require infrastructure to work and grow. Reinvesting an Open Collective's funds to grow a project's community could give everyone involved some incentive. For example, we could use Open Collective funds to make it more financially feasible for a project's maintainers to speak at events. Another concrete reinvestment of funds is paying for code sprints.

Open Collective is providing a tool which helps improves open source sustainability. It is up to each project's maintainer to determine how to use this tool and collected funds.

How can Open Collective directly benefit the Webform module and the Drupal community?

Webform

Open Collective and Webform

The goal of this blog post is to initiate the conversation around leveraging Open Collection within the Drupal community. Developing and refining the marketing and messaging for the Webform module's Open Collective is going to be an interactive process with some experimentation.

Webform and marketing

The success of the Webforms' Open Collective is going to hinge on the Webform module's project page on Drupal.org, the Webform module's page on Open Collective, and some callouts in the documentation, videos and maybe in the Webform module's user interface

Webform and messaging

After three years of working heavily on an open source project, I strongly feel that the most important message to new and even old people in the open source community is…

Everyone is welcome and we are here to help.

Gradually within the Webform module's Open Collective, we need to figure out how to talk to the consumer of the software by…

Communicating the value of contributing and providing incentives for people to contribute.

Webform and incentives

Support is the most immediate incentive to get people to pay for open source software. WordPress' plugin ecosystem openly asks and sometimes requires people to pay for support licenses. I never want to force or trick a user to pay for support. The Drupal community is passionately against paid modules. Nevertheless, it’s important to communicate to people that supporting an Open Collective will help support the Webform module and the Drupal community. There is no doubt they go hand in hand.

Frankly, I already escalate issue queue tickets created by people and organizations who are active contributors or sponsors in the Drupal community, especially if they are members of the Drupal Association. BTW, I also welcome and escalate tickets created by new members of the Drupal community. I have not publicly documented this policy, but it is worth asking "Should we be providing free software with free support?"

Webform and money

How the funds in Webform module's Open Collective are being distributed is tricky but not impossible. Initially focusing on reinvesting any funds back into the Webform and Drupal community and the software is a fair and reasonable approach. The collected funds should only be spent on event/speaking related costs and direct improvements to the Webform module's user experience, accessibility, and marketing.

Reinvesting funds for marketing might be the only controversial expense. I am going to tread lightly with spending money on marketing, but the Webform module needs a logo, maybe a better slide deck, and some SEO to compete with the 100's of other form builders on the market. BTW, Drupal's community is so awesome I would not be surprised if someone contributed a logo to the Webform module.

Webform and me

I am not going to get rich from the Webform module. I am incredibly fortunate to have steady consulting work, which allows me to contribute my time to the Webform module. The Webform module is a professional and intellectual challenge for me. The sustainability of the Webform module is part of this challenge.

What fascinates me most about the challenge of open source sustainability is the scale that our open source projects are benefiting everyone including large organizations. Large organizations have realized that they can tap in the power of open source software and its communities.

Open source needs to push back on organizations and ask them to give back.

Us and open source

“The culture of our community should be one that gives back and supports community projects with all that they can: whether with employee time or funding. Instead of just embracing the consumption of open source and ignoring the cost, we should take responsibility for its sustainability."

-- Henry Zhu of Babel
https://techcrunch.com/2018/06/23/open-source-sustainability

Open source is about us. Us is anyone that uses open source projects. Sometimes, we forget that even the individual or organization that uses the software without contributing back to open source are still peripheral members of our community. We need to explore how we are marketing open source projects, think about our messaging and provide some incentives to welcome and encourage everyone to get involved.

Join the Webform module's Open Collective

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Jan 15 2019
Jan 15

Let us invite you to an imaginary city that follows the Drupal Way! ;) Using the names of real Drupal modules, themes, and distributions, we at WishDesk team created the Drupal City map. Today we celebrate Drupal’s 18th birthday, so it’s a great opportunity to invite you there!

The idea and mission of Drupal City map

The world of Drupal modules is incredibly interesting, and we decided to show it to everyone. Our Drupal Map is much more than entertainment. It is meant to promote Drupal and give inspiration to developers, users, and customers.

And, of course, Drupal City will let anyone learn Drupal modules in a cheery and engaging way. You can click on the module images, see their brief descriptions, and visit their pages on​​​​​​​ drupal.org (then click again to close). Here and there, we also left little hints as to how these modules work. So the Drupal City map contributes to Drupal education.

Drupal City map

Welcome to Drupal City!

Just look around the​​​​​​​ Drupal City — it has everything you can imagine. You could walk along the Commerce CCAvenue, turn to the Beale Street, pass the Simple Columns and reach the Beach and the Sea, from which flows a mighty River of Tweets leading to the Waterfall Views.

It is possible to have a chat at the sociable Sticky Sharrre Bar, take a ride on the Owl Carousel, get some calories for Drupal ideas at the local Restaurant or Bakery, and lose extra calories in YG Fitness Gym.

You could also admire the Christmas Lights at the Commerce Square, visit the Open Church, and replenish your skills at the Library. And this is just the beginning!

The choice of modules for Drupal City

It was amazing to see how all these modules, themes, and distributions fit into the Drupal map like in a puzzle.

Some module names matched their map objects exactly, while for others we used a little wordplay. For example, the Commerce Square module does integration with the Square payment service — and it is a beautiful city square on the Drupal map. It makes the map even more interesting!

Drupal has so many fabulous modules that at some moments it was hard to choose between them. There were multiple awesome modules for particular objects — for example, carousels or fields. With real hard decisions to make, we chose the modules whose names better fit the map concept.

If you would like to see other Drupal modules, themes, or distributions on the Drupal City map, you are welcome to share your ideas, and we will consider adding them. Drupal City is truly welcoming, and it belongs to the Drupal world.

See you in Drupal City! It’s just an awesome little place on the Drupal Planet ;)

Created with love for Drupal by WishDesk team.

Jan 15 2019
Jan 15

Amongst ambitious brands and serious digital operators; Drupal adoption rate on the rise.

Governments and major brands across the globe are already testifying to the positive impact that Drupal has made on their digital business.

As a developer, you might be approached by a client that insists on developing their digital platform and/or experience using Drupal.

Here are 3 key reasons why Drupal distributions will make your life much easier:

1. Time

“How long do you need to complete the project? That long?!?”

Dealing with continuous amendments and changes to the project requirements is the bane of all developers.

Distributions feature tons of tried and tested best-in-class features, modules and components that are already integrated and tested together. This allows developers to successfully complete project tasks that normally consume a scary amount of time to build.

For example; should you be required to build a Media Entity Browser for a certain project may consume up to 6 to 8 hours from your time.

Varbase Media Entity Browser

Source: Varbase

Imagine it took you that long for project A... now you have to repeat the same process for project B.

However; with Drupal distributions such as Varbase, the Media Entity Browser is already built-in, optimized and integrated with other modules you might require.

Total time consumed on Media Entity Browser development: Zero.

Thanks to DRY (Don’t-Repeat-Yourself); Drupal distributions will shorten the project development time by hundreds of hours. You won’t ever have to repeat the same development process for any other project.

LEARN MORE ABOUT VARBASE

2. Efficiency

Not all programmers and web developers are equal in skill and expertise. But, we all face challenges and issues that might arise during the project development process.

Drupal distributions offer a wealth of solutions that fix issues you might not even realize you had. Why? Open-source.

For example; you are currently developing an e-commerce platform for a client and face an issue with a particular component.

The fact is that you weren’t the first developer to encounter this issue.

When using Drupal distributions, you will find almost all challenges and issues related to components or modules you may need have been solved and addressed by someone before you.

Working on almost ready-built websites not only saves time but also affords you the opportunity to personalize any ready-made component or feature based on your project requirements.

Take the aforementioned example; you already have a Media Entity Browser ready, but you wish to match it to your clients’ requirements. In no time at all, you can build upon the ready-made feature via customization or integration. Simples.

3. Standards

At Vardot, we refer to “websites” as digital experiences. The difference between them?

Standards.

Drupal has built a name for itself due to the focus on building the best user-friendly digital experiences possible and the fact that Drupal is open-source has enabled its evolution based on actual feedback from various practical perspectives.

Your ability to develop a website (e.g.) the best online equestrian market; depends entirely on the standards you apply throughout the development process.

For example; Varbase is an ideal distribution to develop platforms that rely on rich multi-media content such as Al Jazeera and Georgetown University. On the other hand, Drupal distributions such as Commerce Kickstart feature every possible component needed by a developer to build an e-commerce digital experience.

Of course, when we speak of standards; we are not referring solely to quality standards. You will be able to develop the best possible digital experience for any industry using Drupal distributions whilst maintaining all W3C standards and accessibility standards.

Bonus: Drupal Distributions Maintenance

Drupal distributions are rich in features that are all integrated with each other.

You will never have to scour for individual updates for each module you need. All you’ll ever possibly need is to update the distribution itself.

Since all modules and features are integrated. All would be updated and tested together.

If you are considering starting a Drupal project or to build a Drupal-based digital experience, let us know. We'd love to help.  Contact Us.

Jan 15 2019
Jan 15

Last month, Pune Drupal community conducted a Global Training Day event. It was a successful event and saw huge participation from Pune Drupal community.
Pune GTD reminded us that community is what makes Drupal so special and that interaction between the community members was somewhat missing from our Drupal life.

With the hope that we can change this, we had planned to increase the community participation by bringing back our monthly Drupal meetups.
And we did deliver on our plan! We had our first Drupal meetup of the year on Saurday, 12th Jan at SISCR, Pune.

The day started with a session on 'Docksal for Drupal' by Sharique.

Sharique preseting session on Docksal

The session covered the basics of containers and the difference between virtualization and containarization followed by a detailed demo of setting up a Drupal instance using Docksal and managing various configurations for Docksal.
Overall, this was a great introduction for developers & teams trying to adopt Docksal for their development environment.

Highlight of the day was the next session on the topic of Accessibility presented by Nikita, Ambuj & Sonal.

Nikita started the session by explaning basic concepts of Accessibility and day-to-day programming tips & tricks developers/teams can follow to make their site accessible.

Nikita presenting session on accessibility


It was followed by Ambuj's explanation of QA's perspective on Accessibility and what should be expected by users & testers for an accessible site.

Ambuj explaining QA's perspective on accessibility


Sonal concluded the session by going into the implementation details, specially the easy ways a developer/team can make their site accessible.

Sonal preseting session on accessibility.

We ended the day having by a general BoF on 'How to increase the community participation for Drupal meetups'.
This was a very productive discussion and the community identified the challenges of setting up a quality event and came up with action items for them.

  • Attendees want to see a variety of topics instead of just having them limited to Drupal Backend and Custom Module development. The session on Accessibility was much liked by the community and they'd love to see more such topics.
  • There's a need to streamline and improve the process of communicating Drupal events and their reporting.

We promise to work on the above and would love to see many of you join us in future meetups. Stay tuned to community updates for information on future events and topics!

Links to Session slides/resources:
1. Docksal: https://www.slideshare.net/safknw/local-drupal-development-using-docksal
2. Web Accessibility: https://bit.ly/2Dgw5P9

Jan 14 2019
Jan 14

We’re featuring some of the people in the Drupalverse! This Q&A series highlights individuals you could meet at DrupalCon.

Every year, DrupalCon is the largest gathering of people who belong to this community. To celebrate and take note of what DrupalCon means to them, we’re featuring an array of perspectives and fun facts to help you get to know your community.
 

Jan 14 2019
Jan 14

We’ve compiled all the blog posts we wrote in the final month of 2018. Besides continuing with our Community Interviews series, we also introduced a brand new series of posts - the Story of Agiledrop, in which we discuss our work practices and give you a glimpse into what it’s like to work as a member of our A-team. Have a look and stay tuned!

How to Create a Node in Drupal 8 using REST

The first blog post we wrote in December was a short tutorial on creating a node in Drupal 8 using RESTful web services. RESTful web services are the underlying principles that enable the concept of “headless Drupal”, and they bring about a plethora of possibilities for the customization of a Drupal site. This post takes you through the basic function of creating a node using these services and serves as a kind of demo of the feature.

Read more

The Story of Agiledrop: Introduction

Our next post was the first chapter of our new series, the Story of Agiledrop. Here we explained our workflow and the advantages it has had, both for our dedicated team and for our clients. Thanks to such a well-defined workflow, our A-team can keep improving and growing, professionally as well as personally. But, of course, we also encountered some obstacles when defining our workflow and putting it into effect - we discussed these in the series’ second chapter.

Read more

Interview with Kevin Kaland, aka wizonesolutions: Towards a more and more decoupled Drupal

The third post was part of our Community Interviews series. We talked with the digital wizard Kevin Kaland of WizOne Solutions, who revealed to us his thoughts on Drupal’s future as well as some more personal, non-Drupal related bits of information. Besides being actively involved in the community as the maintainer of the FillPDF module among other things, he’s also an avid traveler, hiker and language enthusiast. Take a look at what we talked about.

Read more

The Story of Agiledrop: Our Training Program

Finally, just before the holiday season, we wrote a blog post on our effective training program, the second chapter in Agiledrop’s story. While the first chapter concentrated on our workflow and its advantages, this second one dove into the challenges we faced when setting up such a unique workflow. We deal with the first of these challenges - providing a number of clients with proven and experienced developers - more thoroughly, and reveal how we succeeded in finding a very beneficial solution for it. 

Read more

That’s that for our blog posts from December. We hope 2018 was a successful year and the transition into 2019 a pleasant one for everyone. Check back later this month or keep following our blog for any new content!
 

Jan 13 2019
Jan 13

the Twig file

In the previous section we created the file that defines the widget formatter used to pre-format the data before passing it on to a twig file. In this part we will create the twig file that provides the markup for the viewed content.

name_field_type.html.twig

The file should be placed in the path <my module>/templates and be given the name used for #theme in the previous section with a .twig suffix.


{{ name }}

That's all the pieces. The complete tree for your module should look like this:


name_field_type/
├── name_field_type.info.yml
├── name_field_type.module
├── src
│   └── Plugin
│       └── Field
│           ├── FieldFormatter
│           │   └── NameFormatter.php
│           ├── FieldType
│           │   └── NameItem.php
│           └── FieldWidget
│               └── NameWidget.php
└── templates
    └── name_field_type.html.twig

Enable the module either through the Extensions (/admin/modules) page of the UI or using drush

drush en name_field_type

Select a content type to add the new field type. It should appear in the field type list 

Field type list with the new field type added

When creating a new piece of content for the content type, all of the sub-fields will appear for the new field

sub fields on node form

And finally, the rendering of the parts of our field:

Rendered name

The magic is that this widget can be used on any content type, and is easily moved from site to site, since it's wrapped in a module.

Jan 11 2019
Jan 11

I've been going kind of crazy covering a particular Drupal site I'm building in Behat tests—testing every bit of core functionality on the site. In this particular case, a feature I'm testing allows users to upload arbitrary files to an SFTP server, then Drupal shows those filenames in a streamlined UI.

I needed to be able to test the user action of "I'm a user, I upload a file to this directory, then I see the file listed in a certain place on the site."

These files are not managed by Drupal (e.g. they're not file field uploads), but if they were, I'd invest some time in resolving this issue in the drupalextension project: "When I attach the file" and Drupal temporary files.

Since they are just random files dropped on the filesystem, I needed to:

  1. Create a new step definition
  2. Track files that are created using that step definition
  3. Add code to make sure files that were created are cleaned up

If I just added a new step definition in my FeatureContext which creates the new files, then subsequent test runs on the same machine would likely fail, because the test files I created are still present.

Luckily, Behat has a mechanism that allows me to track created resources and clean up after the scenario runs (even if it fails), and those in Drupal-land may be familiar with the naming convention—they're called hooks.

In this case, I want to add an @AfterScenario hook which runs after any scenario that creates a file, but I'm getting a little ahead of myself here.

Create a new step definition

Whenever I want to create a new step definition, I start by writing out the step as I want it, in my feature file:

When I add file "test.txt" to the "example" folder

Now I run the scenario using Behat, and Behat is nice enough to generate the stub function I need to add to my FeatureContext in it's output:

--- Drupal\FeatureContext has missing steps. Define them with these snippets:

    /**
     * @When I add file :arg1 to the :arg2 folder
     */
    public function iAddFileToTheFolder($arg1, $arg2)
    {
        throw new PendingException();
    }

I copy that code out, drop it into my FeatureContext, then change things to do what I want:

  /**
   * @When I add file :file_name to the :folder_name folder
   */
  public function iAddFileToTheFolder($file_name, $folder_name) {
    $file_path = '/some/system/directory/' . $folder_name . '/' . $file_name;
    $file = fopen($file_path, 'w');
    fwrite($file, '');
    fclose($file);
  }

Yay, a working Behat test step! If I run it, it passes, and the file is dropped into that folder.

But if I run it again, the file was already there and the rest of my tests may also be affected by this rogue testing file.

So next step is I need to track the files I create, and make sure they are cleaned up in an @AfterScenario.

Track files created during test steps

At the top of my FeatureContext, I added:

  /**
   * Keep track of files added by tests so they can be cleaned up.
   *
   * @var array
   */
  public $files = [];

This array tracks a list of file paths, quite simply.

And then inside my test step, at the end of the function, I can add any file that is created to that array:

  /**
   * @When I add file :file_name to the :folder_name folder
   */
  public function iAddFileToTheFolder($file_name, $folder_name) {
    $file_path = '/some/system/directory/' . $folder_name . '/' . $file_name;
    $file = fopen($file_path, 'w');
    fwrite($file, '');
    fclose($file);
    $this->files[] = $file_path;
  }

That's great, but next we need to add an @AfterScenario hook to clean up the files.

Make sure the created files are cleaned up

At the end of my feature context, I'll add a cleanUpFiles() function:

  /**
   * Cleans up files after every scenario.
   *
   * @AfterScenario @file
   */
  public function cleanUpFiles($event) {
    // Delete each file in the array.
    foreach ($this->files as $file_path) {
      unlink($file_path);
    }

    // Reset the files array.
    $this->files = [];
  }

This @AfterScenario is tagged with @file, so any scenario where I want the files to be tracked and cleaned up, I just need to add the @file tag, like so:

@myfeature
Feature: MyFeature

  @api @authenticated @javascript @file
  Scenario: Show changed files in selection form using Git on Site page.
    Given I am logged in as a user with the "file_manager" role
    When I am on "/directory/example"
    Then I should see the text "There are no files present in the example folder."
    And I should not see the text "test.txt"
    When I add file "test.txt" to the "example" folder
    And I am on "/directory/example"
    Then I should see the text "text.txt"

And that is how you do it. Now no matter whether I create one file or a thousand, any scenario tagged with @file will get all its generated test files cleaned up afterwards!

Jan 11 2019
Jan 11

Drupal has everything to do with Community, the embodiment of vibrancy imbuing this Open Source project... so much so that the Community is justly touted as a factor differentiating it within the field of CMSs, and contribution to it is often used to measure a candidate's suitability for employment (a practice that makes sense on the surface but can be inherently biased).

Community is based on volunteerism, and while volunteerism is a great and noble thing with demonstrable successes, especially within the Drupal Community, there is a flip side to it: there is no accountability or surety, and that can be a large issue to the user community.

Let us consider the migration from D7 to D8. On the surface the process has come a long way, with the migration of fairly vanilla sites often being push-button. I posit that the problems, large costly and sometimes insurmountable problems, arise below that surface. One current glaring example is the Rules module, a top favorite in D7. It is still in alpha.

So, what about the multitude of sites that have a heavy investment in Rules, often as a result of their business needs being fulfilled by its use. There seems to be only a few choices for them of what to do, none of them pleasant or defensible, when looking in from the outside:

  • Remain on D7
  • Eliminate the need for the rule(s)
  • Absorb the cost of converting the rules to custom code

Certainly the fact that there is no production D8 rules module, yet, is not a matter of fault. Module migration is like the tripod of any project: it comes down to resources, time and scope. That said, in a volunteer network the availability of resources is indeterminate. 

We are now at the point of scheduling the arrival of D9 and the end-of-life of both D7 and D8, and still, there is a plethora of sites, enterprise sites, that make heavy use of Rules, or some other module not yet migrated, with a brick wall approaching and no brakes on the car.

At a minimum, I feel that mission-critical contributed modules and their migration need to be part of the release planning of a new version, rising to the level of blockers. We owe it to the clients whose use of Drupal means its success. After all, you can have "open source" music, but it means nothing if no one listens to it.

Jan 11 2019
Jan 11

Values & Principles Committee Update - November 2018

The first post we would like to highlight is Rachel Lawson’s update on the Drupal community’s Values & Principals Committee. Here, Rachel covers the basics of the committee: why it has been put together, how it will function and who its members are. She finishes with a powerful CTA to members of the community to contribute their own stories about Principle 8.

Read more

Drupal's Commitment to Accessibility

Next up, we have a post by Dries on Drupal's commitment to accessibility. He has made the realization that accessibility is not something that benefits only a small group of people and should as such be shrugged off and/or postponed, but rather something that promotes inclusion and can benefit everybody involved. So, the community as a whole should put more effort in making Drupal accessible, consequently benefiting each and every member.

Read more

A Visual Prototype of Drupal.org's Integration with GitLab

Early last month, Tim Lehnen, executive director of the Drupal Association, wrote a piece on Drupal.org's integration with GitLab. In this post, he goes through all the things needed to get the integration working and even includes a video outlining the migration phases for the project.

Read more

A Framework for Progressively Decoupled Drupal

When discussing the future of Drupal, a lot of talk revolves around “decoupled Drupal” or “headless CMS”. Malcolm Young of Capgemini offers his insights on what Dries describes as “progressively decoupled Drupal”, and introduces the so-called SPALP module together with the benefits of using this module.

Read more

The New Layout Builder’s Impact on Drupal’s Evolving Learning Curve

Ashraf Abed and Jack Garratt discuss Drupal’s new layout builder in this blog post by Debug Academy. They compare different ways of creating content and show how site building can be greatly facilitated when using the layout builder. Consequently, it makes Drupal more accessible to content editors and less experienced developers, giving them more reign in creating a website.

Read more

How to Automate Testing whether Your Drupal 8 Module Is Incompatible with Drupal 9?

In this blog post, Gábor Hojtsy takes us through how to automate testing the incompatibility of a Drupal 8 module with Drupal 9. With the release of Drupal 9 only about a year and a half away, it’s wise to check whether your module is compatible with Drupal 9 (or, at the very least, if it’s incompatible).

Read more

Improving Drupal and Gatsby Integration - Part 1 and Part 2

Jesus Manuel Olivas, Head of Product at weKnow, has started a series on improving Drupal and Gatsby integration. In December, he published the first two chapters of the series: part 1 focuses on two contributed Drupal modules that facilitate the usage of Drupal when working with Gatsby, while part 2 explains how you can really take advantage of the two modules using weKnow’s very own Gatsby plugin. 

Part 1

Part 2

Plan for Drupal 9

Last but not least comes a major post from Dries’ blog. He finally announces the release date for Drupal 9, which is planned for June 2020. This gives site owners more than enough time for a smooth and uncomplicated upgrade from Drupal 8 to Drupal 9. According to Dries, the upgrade will be easy and should as such not be considered a big deal.

Read more

This concludes our selection of the top blog posts from December 2018. We’re very excited to see what the new year will bring for Drupal; we’ll make sure to keep you informed of all the most important goings-on.
 

Jan 11 2019
Jan 11

Automate actions on your Drupal-based website. This will enable it to run even more independently from your input.

Automated mailing, publishing new content at a specified time and redirects after meeting certain conditions are only some of the functionalities featured in the Rules module.

Rules is a tool that enables you to define automatic, conditionally executed actions, triggered by various types of events.

What are some examples of such automated actions? For example:

  • redirecting the user after logging in;
  • sending an e-mail after adding content;
  • publishing content at a specific time.

At the foundation of the module lies the Event – Condition – Action rule, with one caveat – the CONDITION does not have to be a part of this scheme.
An example scheme could be as follows:

  1. A user adds an entry – that’s the event.
  2. The type of the added entry is “Article” – that’s the condition.
  3. Notify the admin about somebody adding an entry via e-mail – that’s the action.

Installing and setting up the Rules module

Currently (January 2019), the module is still available in alpha4 version only, which means that some of its functionalities and features might not work properly, there might also still be some errors and bugs.
For the purposes of this article, we used the DEV version of the module.

The below example works and was tested on the configuration outlined below:
Drupal : 8.6.5
Rules : 8.x-3.x-dev
Typed Data : 8.x-1.0-alpha2

Download the modules and unpack them in the /modules/contrib directory.
Rules – https://www.drupal.org/project/rules
Typed Data – https://www.drupal.org/project/typed_data

If you are going to create rules with user roles in the conditions, for example, if you want to redirect users with an “administrator” role who log in to a specific site, you will need to add a patch: https://www.drupal.org/files/issues/2816157-10.patch. It will probably not be needed in the future, but as it stands, it is still required for the user role condition to work properly.

How to apply patches? – https://www.drupal.org/patch/apply.

Creating and testing your rules

We are now going to show you how to add a new rule, step by step: Redirecting to the /admin/people page after a user with the administrator role logs in to the website.

Add a new rule - /admin/confg/workflow/rules.
Add new rule

Fill in the fields:

  • Name your rule using the label field.
  • From the drop-down menu, select the event that will trigger your rule. In our case it is going to be “User has logged in”.

Add a condition.
Select the appropriate value, in our case, it is going to be "User has role(s)”.

Select the right condition

Now, you are going to deal with the hardest part of creating a rule, namely selecting the appropriate objects that the condition will work on. You have to be really careful here, because despite this field being validated, sometimes you might set erroneous values that will cause problems down the road.
In the USER section, switch the field from the automatic filling mode to the selection mode. Switch to the data selection.

This condition concerns users, since it is their role that you have to check, so you need to type “account” in the field.

In the ROLES section, put in the roles that will fulfil the condition. You need to put in the machine name. You can view it at /admin/people/roles page by editing a selected role. In our case, it is going to be “administrator”. You can add more roles, just keep in mind to add just one role per line.

In the MATCH ROLES section, if you have selected more than one role, you can set whether the user must have each of these roles (AND) or any of them (OR).

In the NEGATE section, you can select whether this condition should be met when the above settings are NOT MET – in this case, the action will be executed when each user logs in, except for those who have an administrator role.

Rules module conditions

Add an action.

+Add action button of module shown

Select Page redirect from the System section.

"Page redirect"action selected

Enter the address (internal or external) to which the user should be redirected after logging in.

redirection address (internal)

Save and test the rule.

In order to ensure that the rule works, clear Drupal’s cache.

Now log in and check if the redirection is working.

My redirection for the admin role does not work. What do I do?!

PHP throws an error:

  • make sure you have applied the patch mentioned above;
  • make sure that you used the “account” object in the USER section of the rule condition.

Redirection does not work after logging in:

  • make sure that the rule is saved correctly;
  • clear Drupal’s cache;
  • make sure that the role name in the condition is correct.

Discover the many possibilities of the Rules module.

The Rules module is a really powerful tool which enables you to build complex rules that will automate your website.

If you have an idea for using this tool in your project, but you need help, do not hesitate to contact us.

Jan 10 2019
Jan 10

Website owners are often trapped inside an imaginary bubble where they make conclusions like “There are more valuable sites in the web world, why would mine be targeted by the hackers?” 

And Alas the bubble is busted when they observe that hackers have attacked their site because let's face it- they would never discriminate between any choice they are getting. They want a website to attack, and they have it.

For opensource CMS like Drupal, WordPress, and Joomla, the scenario is the same. As popular as these platforms are, they are the targets of all sorts of attacks. Cybercriminals discover the security loopholes and hack your website in no time.

A picture of a head of a man which is black in color who is wearing a grey hat which is on red background


Which leaves us with the assumption that these platforms ( which together conquer 68.5% of the CMS market) must be providing some form of protection. 

And yes, the assumptions are true.  

Birth of SIWECOS 

SIWECOS project or the “Secure Websites and Content Management Systems” project is the security project which is funded by the German ministry of Economics that desires to improve the security of the CMS based websites ( which of course includes Drupal, WordPress, Joomla, and many others)  

 Image of the logo of SIWECOS with an illustration showing a magnifying glass superimposed over concentric semicircles

The project was designed to help small and medium-sized enterprises (SMEs) identify and correct the security loopholes that they witness on their websites. It focused on concrete recommendations of action in the event of damage and also taking care of sensitizing SMEs to cybersecurity.

The utilization of the vulnerability scanner in the project helped SMEs to regularly check the server system and made them acquaint well with the vulnerability that might occur in a web application. Not only this but a service for web hosts were also presented which actively communicated with acute security vulnerabilities and offered filtering capabilities to prevent cyber attacks. 

The end users were also protected with potential data losses as well as financial losses. 

Initiative-S 

The aim of SIWECOS in longer run was to increase web security and raise a proper awareness of the relevance of IT security for SMEs. Thus, Initiative-S came out as a ray of hope for the support of the small and medium-sized enterprise. It was a government-funded project which was built by the initiative, the association of the German internet industry echo. 

The association built a web interface called “clamavi”. This was done for the users to grant them with the ability to enter their domain and conduct a malware scan of the source code once per day. Thus the website check of Initiative-S was integrated into the new project of SIWECOS. The proven Initiative-S technology now supplements the portfolio of the new SIWECOS service with a check for possible malware infestation.

logo of initiative-s where an arrow is pointing towards the magnifying glass of SIWECOS logo that is superimposed over concentric semicircles

Importance of the Project 

As mentioned, the whole project revolved around the security of the CMS platform, Since the time it was started, the project took 2 years to complete. The mission was to introduce the end users with:

  • Importance of security in cooperation and provided the end users with individual notifications and recommendation on security issue of a website.
  • Increase in web security for a longer period and to identify and address security vulnerabilities of their website.
  •  The project helped ordinary users patch more quickly. Patching is the application of updates (patches) to existing code that either increase the functionality or correct patch vulnerabilities.
  • It also scanned registered user websites. If any security vulnerabilities were found then the person in the field of IT security was contacted directly.
Screenshot of the homepage of SIWECOS website which shows the features of the security maintained in a table


What does SIWECOS have in General?

SIWECOS, in general, had three things 

Awareness Building

It is the detailed version of the introduction and the process on how to subscribe it. They reached out to the end users that not only included the site owners but also the ones that have to maintain it later. The major purpose of the awareness campaign was to influence the behavior of the users since improvements cannot take place without changes in their attitudes and perceptions.

Skinning Service

The whole scanning system in Skinning Service is based on an API which is an open source that is embedded inside. It gave the end users with score count between zero and hundred to give them an idea on how secure or insecure the setup is.

Behind the score, there were five scanners which were used to check malware in the HTML code. Scanners like:

  • HTTP Header Scanner

Ensures that your server conveys the browser to enable security features.

  • Info leak Scanner

Verifies if the site exposes security-relevant information.

  • TLS scanner

Checks the HTTPs encryption for known issues, outdated certificates, chain of trust etc

  • Initiative S Scanner 

This scanner checks the website for viruses or looks for third-party content such as phishing.

  • DOMXSS Scanner

This scanner verifies that the website is protected against DOMXSS attacks. 

Web Host

The companies that power the service behind the website are likely to be called as web hosts. Web hosts team generally should have all the basic technical knowledge, security awareness and should have an active communication of filter rules to defend against attacks.

The need for Filter rules - to limit the circle of recipients. 

Firewall rules made it easy for experienced attackers to build and exploit the website as they want. Thus, by filtering incoming and outgoing network traffic (based on the set of user-defined rules) there was a reduction in unwanted network communication.

Another reason to use web host was server-side protection. The server- side was protected against all these attacks on the web pages that were installed in the web hoster. This was done to protect web page operators.

Partner in the Project

SIWECOS project included four partners mainly that contributed highly to the project. The four partners were:

Eco

Eco or electronic commerce is the largest association of the internet industry in Europe. The association sees itself as the representation of the interests of the internet economy and has set itself with the goal of promoting technologies, shaping framework conditions and representing the interests of its members. The Eco group includes all the internet industry and promotes current and future internet topics. 

The awareness building section was mainly done by eco association because of the fact that they were really good at marketing and networking. 
 

Image of a square that is divided into two parts where the upper part has eco written on it and the below section has a red background where words are written in the German language

RUB 

The Ruhr-University Bochum, located on the southern hills of central Ruhr area Bochum, is one of the partners in the whole project. It has one of the greatest and most proven track records in the general IT security industry. They were included in the project with the agenda of building a scanning engine that gave the business owners feedback about potential security problems on their site such as SSL misconfiguration or vulnerability to cross-site scripting attacks.

Image of a square which is divided into two parts the left side is white in color where RUHR university is written in German and the right side is blue in color with RUB written in white

HACKMANIT

Hackmanit GmbH was founded by IT security experts that were from Ruhr University Bochum. They have an international publication of XML security, SSL/TLS, single sign-on, cross-site scripting, and UI redressing. The priorities of the company were designed by high-quality penetration testing, hands-on training, and tailor-made expertise. The organization has in-depth knowledge about the security of web application, web services, and applied cryptography. The team offers a white box and black box tests which protects the application from the effects of all sorts of hackers attack.

Image having HACKMANIT with an underline as it’s text. HACK is written in red color MANIT in black

CMS Graden 

The CMS garden is the umbrella organization of the most relevant and active open source content management system. In other words, the security team started with CMS planning in 2013 by making a shoutout to the CMS community to join the team. Surprisingly, there were CMS platforms which were interested. Thus, by 2013, there were 12 open source CMS systems in one place. 

CMS garden also contributes to a series of plugins for different open source CMSes that provides feedbacks from within the CMS management interface so that the site owners have the ability to act immediately when they encounter with any security vulnerability. 
 

 A stick image of a flower with 5 buds on it besides which CMS garden is written in black. The E in the garden is drawn in stick letter in green color

In the End 

Website attacks and cyber attacks are rapidly growing. These attacks cost the organizations millions of dollars, subject them to the lawsuit and ruin their lives. 

SIWECOS is like a shield for all the websites and the CMS platforms, it protects them against cyber attacks and hackers of all sort, helping in keeping up with the security and protection against vulnerabilities. 

We know how important web security is to protect your online identity and personal information. If you’re concerned about your web security for your business, or other network issues, our services can help. Contact us on [email protected] the professionals would guide you with all your queries and questions and help you leverage security for your website.

Jan 10 2019
Jan 10
Drupal. It’s been the foundation of our solutions for a few years now and it powers some of the top sites around the world in fields ranging from commerce to government. If you’ve ever been interested in getting your feet wet with the CMS, or…
Jan 10 2019
Jan 10

Preview

Introduction

Drupal Mountain Camp brings together experts and newcomers in web development to share their knowledge in creating interactive websites using Drupal and related web technologies. We are committed to unite a diverse crowd from different disciplines such as developers, designers, project managers as well as agency and community leaders.

Drupal Mountain Camp Group Picture

Keynotes

The future of Drupal communities

For the first keynote, Drupal community leaders such as Nick Veenhof and Imre Gmelig Meijling will discuss about successful models to create sustainable open source communities and how we can improve collaboration in the future to ensure even more success for the open web. This keynote panel talk will be moderated by Rachel Lawson.

Drupal Admin UI & JavaScript Modernisation initiative

In the second keynote Matthew Grill, one of the Drupal 8 JavaScript subsystem maintainers, will present about the importance and significance of the Admin UI & JavaScript Modernisation initiative and Drupal’s JavaScript future.

Drupal Mountain Camp Attendee

Sessions

In sessions, we will share the latest and greatest in Drupal web development as well learn from real world implementation case studies. Workshops will enable you to grow your web development skills in a hands-on setting. Sprints will teach you how contributing to Drupal can teach you a lot while improving the system for everyone.

Swiss Splash Awards

As a highlight, the Swiss Splash Awards will determine the best Swiss Drupal web projects selected by an independent jury in 9 different categories. These projects will also participate in the global Splash Awards at DrupalCon Europe 2019.

Splash Awards 2019

Location

Drupal Mountain Camp takes place at Davos Congress. As tested by various other prominent conferences and by ourselves in 2017, this venue ensures providing a great space for meeting each other. We are glad to be able to offer conference attendees high quality equipment and flawless internet access all in an inspiring setting. Davos is located high up in the Swiss alps, reachable from Zurich airport within a beautiful 2 hours train ride up the mountains.

The camp

The Drupal Mountain Camp is all about creating a unique experience, so prepare for some social fun activities. We’ll make sure you can test the slopes by ski and snowboard or join us for the evening activities available to any skill level such as sledding or ice skating.

Drupal Mountain Camp Davos

Tickets

Drupal Mountain Camp is committed to be a non-profit event with early bird tickets available for just CHF 80,- covering the 3 day conference including food for attendees. This wouldn't be possible without the generous support of our sponsors. Packages are still available, the following are already confirmed: Gold Sponsors: MD Systems, platform.sh, Amazee Labs. Silver: soul.media, Gridonic, Hostpoint AG, Wondrous, Happy Coding, Previon+. Hosting partner: amazee.io.

Key dates

  • Early bird tickets for CHF 80,- are available until Monday January 14th, 2019

  • Call for sessions and workshops is open until January 21st, 2019

  • Selected program is announced on January 28th, 2019

  • Splash Award submissions is open until February 4th, 2019

  • Regular tickets for CHF 120,- end on February 28th, 2019 after that late bird tickets cost CHF 140,-

  • Drupal Mountain Camp takes place in Davos Switzerland from March 7-10th, 2019

Join us in Davos!

Visit https://drupalmountaincamp.ch or check our promotion slides to find out more about the conference, secure your ticket and join us to create a unique Drupal Mountain Camp 2019 - Open Source on top of the World in Davos, Switzerland March 7-10th, 2019.

Drupal Mountain Camp is brought to you by Drupal Events, the Swiss Drupal Association formed striving to promote and cultivate the Drupal in Switzerland.

Jan 09 2019
Jan 09

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal's administration UI looks outdated.

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To be fair, Drupal's administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.

A visual comparison of Drupal 7 and Drupal 8's administration UI

A comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.

While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn't lie: we have not done enough to keep Drupal's administration UI modern and up-to-date.

This is something we need to address.

We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal's administration UI.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based administration UI.

A screenshot of the content administration using Drupal 8's Carlo theme

The content administration screen with the new design system.

As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..

A screenshot of the spacing guidelines of Drupal 8's Carlo theme

Sample space sizing guidelines from the new design system.

I also ran the new design system by a few people who spend their days selling Drupal and they described it as "clean" with "good use of space" and a design they would be confident showing to prospective customers.

Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.

Special thanks to Cristina ChumillasSascha EggenbergerRoy ScholtenArchita AroraDennis CohnRicardo MarcelinoBalazs KantorLewis Nyman,and Antonella Severo for all the work on the new design system so far!

We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.

Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.

Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.

How can I help?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri EskolaGábor Hojtsy and Jeff Beeman for their help with this post.

File attachments:  drupal-7-vs-drupal-8-administration-ui-1280w.png carlo-content-administration-1280w.png carlo-spacing-1280w.png
Jan 09 2019
Jan 09

Drupal 9 is coming. Even if it feels like you only just upgraded to Drupal 8, soon it’ll be time to make the switch to the next version. Fortunately, the shift from Drupal 8 to Drupal 9 should be relatively painless for most organizations. Here’s why.

A little background

Though tools were built in to make the upgrade from Drupal 6 or 7 to Drupal 8 run as smoothly as possible, it could still be a difficult or dramatic process. Drupal 8 marked a major shift for the Drupal world: it introduced major new dependencies, such as Symfony, and a host of new features in Core. The new structure of the software made it tricky to upgrade sites in the first place, which was complicated by the fact that it took a long time for a number of modules to be properly optimized and secured for the new version.

Drupal 9: A natural extension of Drupal 8

Fortunately, the large number of changes made to the Drupal platform in Drupal 8 have made it relatively simple to build, expand, and upgrade for the future. The new software has been designed specifically to make it simple to transition between Drupal 8 and Drupal 9, so that making the migration requires little more work than upgrading between minor version of Drupal 8.

In fact, as Dries Buytaert (the founder and project lead of Drupal) wrote recently in a blog on Drupal.org:

Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.

Planning for Drupal 9

As more information is released about the new features and updates in Drupal 9, organizations should consider their digital roadmaps and how the new platform will affect them. And regardless of what your plans are feature-wise, your organization should begin planning to upgrade to Drupal 9 no later than summer of 2021. The reason for that is because the projected end-of-life for the Drupal 8 software is November of 2021, when Symfony 3 (Drupal 8’s largest major dependency) will no longer be supported by its own community.

In the meantime, the best thing your organization can do to prepare for the launch of Drupal 9 is to make sure that you keep your Drupal 8 site fully up to date.

For help planning out your Drupal roadmap, and to make sure that you’ll be ready for a smooth upgrade to Drupal 9 when it releases, contact FFW. We’re here to help you plan out your long-term Drupal strategy and make sure that your team can make the most of your site today, tomorrow, and after Drupal 9 is released.

Jan 09 2019
Jan 09

Everyone loves attractive layouts for web pages. Luckily, Drupal has plenty of awesome page building tools. You will hear tool names like Panels, Panelizer, Paragraphs, Display Suite, Page Manager, Twig, and more. Our Drupal team loves to take the best of them from our arsenal, combine them when needed, to achieve amazing results for our customers. But today we would like to focus on a wonderful new tool, Layout Builder, that appeared in Drupal 8.5. We will take a closer look at creating layouts in Drupal 8 with its help.

Layout Builder in Drupal 8: let’s get acquainted

The Layout Builder module has already been compared to the Panelizer, Panels, or Display Suite modules in its capacities. This makes sense, because according to the Layout Initiative, it is meant to become the number one tool for creating layouts in Drupal 8 core. The module is currently experimental but is expected to reach stability in Drupal 8.7 in the spring of 2019.

The Layout Builder lets you define the layout of any fieldable entity type (content type, user, and so on), or its individual entity. You just select from the predefined sections and add blocks and fields to them as you wish.

The module’s UI is simple and intuitively understandable for administrators, as well as equipped with the drag-and-drop feature to swap the blocks and shape your page. Developers, in their turn, will appreciate that layouts can be defined in a module or theme and have Twig templates.

Creating layouts in Drupal 8 with the Layout Builder

Let’s take a look at Layout Builder in action. We will see how it works on this example of creating a layout for articles. We will begin with enabling the Layout Builder module in core.

Creating a layout for a content type

We go to our Article content type in Structure and select “Manage Display.” Instead of the traditional fields, we see “Manage Layout” button. We also make sure the “Use Layout Builder” option is checked in the “Layout Options.”

The “Manage Layout” button takes us to the page where we configure the article content type layout.

By clicking “Add Section”, we can select from the ready layouts with a different number of columns. The unnecessary sections can be removed.

By clicking “Add Block,” we can add standard Drupal blocks and content type fields (like “Authored by,” “Body,” “Image” etc.) from the list on the right, as well as create custom blocks. The blocks can be dragged anywhere you wish throughout the layout.

Every block has a “Configure” and “Remove” tabs in the right-hand corner next to it. Blocks can also be configured when clicked on the list to the right of the page. For example, we have just configured the article image by attaching a custom image style of 500x500 to it.

So here goes our simple two-column layout with the image and the author on the left and body on the right.

When everything is ready, we click “Save Layout.” After that, all articles will be created according to this pattern.

Creating a layout for an individual node

In many cases, you do not need the same layout for all content type items. Layout Builder lets you make every content item layout customizable by checking the appropriate option on the “Manage Display” tab.

The Layout Builder offers the handy “Layout” button near each node that leads you to its individual layout customization page. The procedure is the same as in creating a layout for a content type.

Creating different layouts within the same content type

We see how Layout Builder can build articles pages, but let’s now complicate things a little and review a special case. What if you are using the same content type for several actual types of content, and want your website to generate different layouts for them?

That was exactly the case with one of our customers. They wanted different layouts to be generated for every content type on the homepage and on the content listing page. A select list menu was used to switch between the actual types of content within the same content type, which was based on the “list” field. According to this field value, specific types of content were filtered out in Views for homepage and content listing page.

The Layout Builder could be helpful here. If the Views is based on ‘Content,” it can choose a specific view mode. And it is awesome that the Layout Builder module can create layouts for particular view modes within the same content type!

View modes can be registered in the “Manage Display” tab of the content type, and each of them needs to have the “Use Layout Builder” option enabled, and each will have its own “Manage Layout” button.

When we worked with this customer, the Layout Builder was in alpha and we successfully used a different solution, which involved Display Suite and Twig templates. Every case is unique, and deserves a special approach.

Let’s build the perfect layout for your website pages!

We have made a little overview of creating layouts in Drupal 8 with the Layout Builder. Let your website have beautiful and properly arranged layouts that work exactly according to your wishes. Just contact our Drupal development team, and we will select the optimal tools from Drupal’s “treasury,” as well as apply customization when needed, to build you the layouts that you will love!

Jan 09 2019
Jan 09

It's no secret that I find Composer a very troublesome piece of software to work with.

I have issues with Composer on two fronts. First, its output is extremely user-unfriendly, such as the long lists of impenetrable statements about dependencies that it produces when it tells you why it can't make a change you request. Second, many Composer commands have unwanted side-effects, and these work against the practice that changes to your codebase should be as simple as possible for the sake of developer sanity, testing, and user acceptance.

I recently discovered that removing packages is one such task where Composer has ideas of its own. A command such as remove drupal/foo will take it on itself to also update some apparently unrelated packages, meaning that you either have to manage the deployment of these updates as part of your uninstallation of a module, or roll up your sleeves and hack into the mess Composer has made of your codebase.

Guess which option I went for.

Step 1: Remove the module you actually want to remove

Let's suppose we want to remove the Drupal module 'foo' from the codebase because we're no longer using it:

$ composer remove drupal/foo

This will have two side effects, one of which you might want, and one of which you definitely don't.

Side effect 1: dependent packages are removed

This is fine, in theory. You probably don't need the modules that are dependencies of foo. Except... Composer knows about dependencies declared in composer.json, which for Drupal modules might be different from the dependencies declared in module info.yml files (if maintainers haven't been careful to ensure they match). UPDATE: I've been informed in comments that drupal.org's packaging process ensures these are kept in sync. So that's one less thing to worry about!

Furthermore, Composer doesn't know about Drupal configuration dependencies. You could have the situation where you installed module Foo, which had a dependency on Bar, so you installed that too. But then you found Bar was quite useful in itself, and you've created content and configuration on your site that depends on Bar. Ideally, at that point, you should have declared Bar explicitly in your project's root composer.json, but most likely, you haven't.

So at this point, you should go through Composer's output of what it's removed, and check your site doesn't have any of the Drupal modules enabled.

I recommend taking the list of Drupal modules that Composer has just told you it's removed in addition to the requested one, and checking its status on your live site:

$ drush pml | ag MODULE

If you find that any modules are still enabled, then revert the changes you've just made with the remove command, and declare the modules in your root composer.json, copying the declaration from the composer.json file of the module you are removing. Then start step 1 again.

Side effect 2: unrelated packages are updated

This is undesirable basically because any package update is something that has to be evaluated and tested before it's deployed. Having that happen as part of a package removal turns what should be a straight-forward task into something complex and unpredictable. It's forcing the developer to handle two operations that should be separate as one.

(It turns out that the maintainers of Composer don't even consider this to be a problem, and as I have unfortunately come to expect, the issue on github is a fine example of bad maintainership (for the nadir, see the issue on the use of JSON as a format for the main composer file) -- dismissing the problems that users explain they have, claiming the problems are by design, and so on.)

So to revert this, you need to pick apart the changes Composer has made, and reverse some of them.

Before you go any further, commit everything that Composer changed with the remove command. In my preferred method of operation, that means all the files, including the modules folder and the vendor folder. I know that Composer recommends you don't do that, but frankly I think trusting Composer not to damage your codebase on a whim is folly: you need to be able to back out of any mess it may make.

Step 2: Repair composer.lock

The composer.lock file is the record of how the packages currently are, so to undo some of the changes Composer made, we undo some of the changes made to this file, then get Composer to update based on the lock.

First, restore version of composer.lock to how it was before you started:

$ git checkout HEAD^ composer.lock

Unstage it. I prefer a GUI for git staging and unstaging operations, but on the command line it's:

$ git reset composer.lock

Your composer lock file now looks as it did before you started.

Use either git add -p or your favourite git GUI to pick out the right bits. Understanding which bits are the 'right bits' takes a bit of mental gymnastics: overall, we want to keep the changes in the last commit that removed packages completely, but we want to discard the changes that upgrade packages.

But here we've got a reverted diff. So in terms of what we have here, we want to discard changes that re-add a package, and stage and commit the changes that downgrade packages.

When you're done staging you should have:

  • the change to the content hash should be unstaged.
  • chunks that are a whole package should be unstaged
  • chunks that change version should be staged (be sure to get all the bits that relate to a package)

Then commit what is staged, and discard the rest.

Then do a git diff of composer.lock against your starting point: you should see only complete package removals.

Step 3: Restore packages with unrelated changes

Finally, do:

$ composer update --lock

This will restore the packages that Composer updated against your will in step 1 to their original state.

If you are committing Composer-managed packages to your repository, commit them now.

As a final sanity check, do a git diff against your starting point, like this:

$ git diff --name-status master

You should see mostly deleted files. To verify there's nothing that shouldn't be there in the changed files, do:

$ git diff --name-status master | ag '^[^D]'

You should see only composer.json, composer.lock, and the autoloader's files.

PS. If I am wrong and there IS a way to get Compose to remove a package without side-effects, please tell me.

I feel I have exhausted all the options of the remove command:

  • --no-update only changes composer.json, and makes no changes to package files at all. I'm not sure what the point of this is.
  • --no-update-with-dependencies only removes the one package, and doesn't remove any dependencies that are not required anywhere else. This leaves you having to pick through composer.json files yourself and remove dependencies individually, and completely obviates the purpose of a package manager!

Why is something as simple as a package removal turned into a complex operation by Composer? Honestly, I'm baffled. I've tried reasoning with the maintainers, and it's a brick wall.

PPS. Since writing this post, I’ve made Composer Manifest a small Composer plugin which makes it easier to see what Composer has decided to change behind your back. Every time you do a Composer update, install, or remove, it writes a YAML file that lists all the installed packages with their versions. Committing that to your repository means you have an easy way to see exactly what's been changed and when.

Jan 09 2019
Jan 09

It’s not easy to create a list of the most useful Drupal 8 modules because it really depends on the site you will create or manage. But there are some really helpful modules that you can use in almost all cases.

In this post, I will share a list of modules that I use on almost all my Drupal 8 projects. They aren’t specifically for a particular type of site, but I find that they are always helpful, both in development and production environments.

1. Admin Toolbar

(D8) - https://www.drupal.org/project/admin_toolbar

drupal-admin-toolbar

The Admin Toolbar module will save you a great deal of time. It provides a drop-down menu that extends Drupal built in menu. It allows you to perform various admin actions faster and easier.

The module works on the top of the default toolbar core module. It’s a very light module and keeps all the toolbar functionalities (shortcut / media responsive).

The module also provides a submodule called "Admin Toolbar Extra Tools," which adds extra links similar to Admin Menu module for Drupal 7 (flush caches, run cron, etc...).

2. Module Filter

(D7/D8) - https://www.drupal.org/project/module_filter

drupal-module-filter

The modules list page can become quite long and unwieldy as your site grows. To simplify your module administration, you can install the Module Filter module, which, as shown above, provides you a separate tab for each module / module package. This gives you two different ways (with the default filter textfield/by package) to quickly find and re-configure your modules.

3. Shield

(D7/D8) - https://www.drupal.org/project/shield

drupal-module-shield

This module helps you protect your development or staging site with HTTP authentication. Anonymous visitors and search engines won’t be able to reach your test environment, but you and your site users will.

4. Content Lock

(D7/D8) - https://www.drupal.org/project/content_lock

drupal-module-content-lock

This module prevents users from editing the same node. If another user is trying to edit the same node, he or she will be notified that the content is currently being edited.

The other great feature of this module is that it prevents users from leaving an edit form page without first saving it. They will be notified when attempting to close the browser window/tab, clicking on a link, etc. If the user confirms that he wants to leave without saving the node, the edit lock is automatically removed.

5. Environment Indicator

(D7/D8) - https://www.drupal.org/project/environment_indicator

drupal-module-environment-indicator

This module will help you stay sane while working in your different environments by adding a configurable color bar to each.

The Environment Indicator module adds a colored bar on the site that informs you which environment you're currently in (Development, Staging, Production, etc.). This is incredibly useful if you have multiple environments for each of your sites and are prone to forgetting which version of the site you are currently looking at.

6. reCAPTCHA

(D7/D8) - https://www.drupal.org/project/recaptcha

drupal-module-recaptcha

reCaptcha is a module built on top of the captcha module that implements the Google Captcha service to protect your site from spam. This web service shows a checkbox “I’m not a robot” at the bottom of your form. The service presents a challenge to the user where the user has to choose a particular set of images related to a subject.

Another option for protecting your site from spam is the Honeypot module.

7. Block Class

(D7/D8)  - https://www.drupal.org/project/block_class

drupal-module-block-class

This module allows users to add CSS classes to any block through the block configuration interface instead of to our twig templates. We just need to add our new classes to our CSS file.

8. Configuration Split

(D8) - https://www.drupal.org/project/config_split

drupal-module-config-split

This module filters the import/export of the configuration. It allows you to define sets of configurations that will get exported to separate directories when exporting from different environments. For example, you may need to have the devel module enabled or have a few blocks or views placed a certain way in the development environment, but not want that configuration to be exported to production. Using configuration split, you can specify both and thus easily share the development configuration with colleagues.

This module is also really useful with a multi-site installation.

9. RoleAssign

(D7/D8) -  https://www.drupal.org/project/roleassign

drupal-rol-asign

This module allows you, as a site administrator, to delegate the assignment of roles to another user without giving him or her the “Administer permissions” permission.

The module creates a new permission called “Assign roles”. Users with this permission are able to assign selected roles to other users. On the other hand, users with the “Administer permissions” permission may select which roles are available for assignment through this module.

For larger sites with multiple levels of administrators or whenever you need finer-grained control over which role can assign which other roles, check out Role Delegation.

10. Delete all

(D7/D8) - https://www.drupal.org/project/delete_all

drupal-module-delete-all

This is the module that I always install on my local or dev environment in conjunction with the Devel Generate module. It allows you to delete all content and/or users from a site with just one click.

This was particularly handy on a test site that one of my clients was using for a period of time when we needed to clean it up before starting with real data or when I tested imports and migrations of thousands of nodes. Really helpful!

Usage statistics of these modules.

The table below provides the usage statistics for these modules across all versions.

drupal-usage-statistics

Which Drupal 8 modules do you consider helpful?

I would love to hear about your “must install” Drupal 8 modules that are most helpful for your projects. Please leave a comment and share it with the community!

Jan 08 2019
Jan 08

There's a module for that. There is, it's called, obviously, addtocalendar. It works very well, if you:

If you don't want to use an external service for something as simple as adding an event to a calendar, then it looks like you'll need a custom solution. Their smallest plan only allows 2 events per month.

The PatternLab Part

Here's the custom solution I came up with (in the future, I'll look at creating a module for this with a settings/UI page for site builders). Note, it's a PatternLab implementation; if you don't use PatternLab and just want to work directly in your Drupal theme, it would be even easier.

Here's the code for the 'Add to Calendar' pattern in PatternLab (some classes and things are removed to make it easier to read):

What does the above code do?

  • Creates a Google Calendar variable and creates an iCal variable. Outlook will also use iCal.
  • Uses these variables as links to add the event to their respective calendars.

Within the variables, we have some more variables (start date, end date, etc), which we should probably wrap in conditional statements so that their clauses don't print unless they are present in Drupal (some fields might be optional on your event content type, such as end time).

These variables are:

  • atc_start_date: Start Date and time
  • atc_end_date: End Date and time
  • atc_title: the name of the event
  • atc_details: description for the event
  • atc_location: place of event

In our Event pattern in PatternLab, we then have a variable called 'add_to_calendar' so that events have the option to have this widget or not. In event.twig, we simply print:

The Drupal Part

In Drupal we create a boolean field on our event content type field_event_add_to_calendar, if this is ticked, we will display the Add to Calendar widget.

Here's the code from node--event--full.html.twig

To explain:

If the 'Add to Calendar' boolean is on, we set the add to calendar variable as true

This in turn tells patternlab to render the Add to Calendar component.

We then check if each field we might use has a value in it - such as a start date and end date

If so, we map the values from each of those fields to variables in our Add to Calendar component (such as atc_start, atc_title, etc)

Now, when you view a node, you will see your Add to Calendar widget on any nodes that the editors choose to put it. You can see a sample of the Add to Calendar widget in my PatternLab.

Simple, once I figured it out.

Got an improvement for this? The comments are open.

Jan 08 2019
Jan 08

A modern and fresh look is coming to the Drupal administration interface soon. Take a look!

Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal's administration UI looks outdated.

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To be fair, Drupal's administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.

A visual comparison of Drupal 7 and Drupal 8's administration UIA comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.

While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn't lie: we have not done enough to keep Drupal's administration UI modern and up-to-date.

This is something we need to address.

We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal's administration UI.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based administration UI.

A screenshot of the content administration using Drupal 8's Carlo themeThe content administration screen with the new design system.

As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..

A screenshot of the spacing guidelines of Drupal 8's Carlo themeSample space sizing guidelines from the new design system.

I also ran the new design system by a few people who spend their days selling Drupal and they described it as "clean" with "good use of space" and a design they would be confident showing to prospective customers.

Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.

Special thanks to Cristina Chumillas, Sascha Eggenberger, Roy Scholten, Archita Arora, Dennis Cohn, Ricardo Marcelino, Balazs Kantor, Lewis Nyman,and Antonella Severo for all the work on the new design system so far!

We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.

Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.

Administration themes must meet large and varied use cases. For example, accessibility is critical for the administration experience, and I'm happy to see that this initiative connected with and have taken feedback into account from the accessibility team.

Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.

How can I help?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri Eskola, Gábor Hojtsy and Jeff Beeman for their help with this post.

January 08, 2019

2 min read time

Jan 08 2019
Jan 08

Agiledrop is highlighting active Drupal community members through a series of interviews. Now you get a chance to learn more about the people behind Drupal projects. 

This time we had a chat with none other than Shawn McCabe, the CTO of Acro Media. In our interview, the avid Drupal contributor talked about his most memorable Drupal moments, his love for open source and his reasons to opt for a more sustainable lifestyle. Have a read!

1. Please tell us a little about yourself. How do you participate in the Drupal community and what do you do professionally?

I am the CTO at Acro Media, so I run our product development and R&D, which puts me pretty heavily into contributing to Drupal and working in the community. I do actually get to do a respectful amount of programming myself, which is nice and not something I always got to do as Acro was growing as a company. 

Thankfully now we have a head of operations for development who handles most of the day to day runnings and I get to run wild with awesome new tech while he does most of the actual work.

I also do architectural consulting and sales work for larger clients, a lot of which involves proselytizing about our lord and savior Drupal to anyone I get pointed in the general direction of.

2. When did you first come across Drupal? What convinced you to stay, the software or the community, and why?

I was aware Drupal existed, but my first actual work with it was when I was assigned to do a large Drupal/Ubercart site, back when Ubercart was still just in alpha. At the time we’d just started transitioning from our own proprietary stuff to Drupal. I’ve been an open source advocate pretty much since I got the internet, so I was all for the move in general.

Drupal ended up matching fairly well with my own preferences, it was open source, fairly developer focused and not controlled by a single company. I found it fairly similar to Linux in philosophy and that sat well with me. That whole “come for the code, stay for the community” thing that Drupal has never resonated with me, I keep working on Drupal because I like the direction and philosophy behind it.

Lots of Drupal events seem to focus on non-coding related activities as a big selling point, but I have little interest in doing non-Drupal activities as part of the community. I am not an isolated freelancer, so this isn’t one of my few times to hang out with other developers. I know other people in the community feel differently and we chatted about it on Slack and Drupal was literally the first time a lot of developers had a single other friend who was also a developer.

That’s a really rambly way of saying that I stay for the code, all the core developers are honestly working towards the best decisions for the project and even having larger corporate backers like Acquia I don’t think has affected that. People like Wim Leers, Gabor, Fabianx, Berdir, Daniel Wehner and Bojanz have done a lot of architectural work that I admire. Working with something like Magento I don’t get quite the same experience, they care primarily about only their own use cases and contribution efforts always feel like you’re the little brother tagging along.

3. What impact has Drupal made on you? Is there a particular moment you remember?

Haha, I remember meeting Dries for the first time and basically just getting all starry eyed and basically stammering at him. In person I swear he’s like 7 feet tall.

On a less embarrassing note, I was very proud to be on the list of the top 100 Drupal contributors at this year’s Drupalcon, as well as 4 other Acro employees. It’s been my goal to push Acro’s community involvement heavily over the last few years, so to see those efforts pay off was really great. As a company we’re also consistently in the Top 3, which I’d like to think I had a large part in. If anyone from Acquia is reading this, we’re coming for your #1 spot.

4. How do you explain what Drupal is to other, non-Drupal people?

Ha! Explaining it to people not in the industry is nearly impossible, usually I resort to “I make websites”. Even then people seem to get confused, it’s like “you know websites? You use them every day? Someone has to make those”. Drupal runs like 10% of the sites you go to, even if you don’t know it.

If they know web development I just say it is like wordpress with more flexibility and fewer security holes.

On a more serious note, I tend to pitch the philosophy of open source a lot when I talk about Drupal. I find most people grasp that fairly well and can see the advantages of having control over their own stuff. Somewhat ironically, I find developers who come from the proprietary side of things have the hardest time grasping open source, the concept of opening up the code is strange and terrifying. I’ve had calls with some very large companies who shall remain nameless who had to be given the ‘Explain it like I’m 5’ version of open source, which I found baffling.

5. How did you see Drupal evolving over the years? What do you think the future will bring?

I am a big fan of the direction of Drupal 8, I love the integration with the community and the adoption of many modern development practices. I think anyone still wishing for Drupal 7 to stay around is doing themselves a disservice instead of growing as a developer along with Drupal. I’ve been working with Drupal since late in the 4.7/early in the 5.x era and I think every version has been a clear improvement over the previous. 

6. What are some of the contributions to open source code or to the community that you are most proud of?

I’ve contributed around performance a lot at various times, I like to think those ones are the most useful since they help everyone. Drupal gets this bad rap for performance that I think is totally unjustified, install one bad module or make a poor caching choice and suddenly it seems like Drupal sucks, but it’s just a side effect of how much flexibility it gives you.

I always feel I’m 10 blog articles or videos behind though in sharing information, any time anyone else has to fix something I’ve already solved, I feel like I’ve wasted their time and they could have solved something new instead of the same thing twice. I’m mostly a “self taught” developer, which really means I’ve been taught by every kind soul who wrote a blog article or open sourced a project, which is a debt it doesn’t seem I can ever sufficiently pay back. So I’d guess I’d say I’m also proud of any content I’ve been able to give back, especially completely original work, then I’ve done my tiny bit to push society forward.

7. Is there an initiative or a project in Drupal space that you would like to promote or highlight?

We’ve done a ton of work on the Commerce POS module that I don’t think gets as much exposure as it should. It provides a wealth of functionality that integrates completely with commerce, providing a fully integrated setup that is usually only an option for expensive or enterprise setups. It even works with hardware you can build yourself like a Raspberry Pi, of which we’ve built some samples of already.

8. Is there anything else that excites you beyond Drupal? Either a new technology or a personal endeavorment. 

I am obsessed with renewable energy stuff lately, I built my own ebike last year and converted a Jeep Cherokee to full electric this year as well. Shameless plug for my youtube channel and blog, except they don’t have near as much content as they should. Our head office is in an area that has suffered from increasingly bad forest fires similar to California, so I’ve tried to take my reduction in greenhouse gases seriously.

I am a fanboy of Tesla for all the work they’ve done pushing the industry forward, but they’re not really my kind of cars as they’re very locked down against customization and filled with unnecessary gadgets, which as you can’t tell from my open source rantings, is pretty important to me. 

I’ve also converted to a vegan diet (aside from the occasional screw up, you wouldn’t believe how much stuff has milk powder in it!) for the same reason. Less for the cute little animals and more so I don’t die in a fire.

I also get super excited about OpenAI’s efforts to build DOTA bots, which seems like a real advancement from comparatively simple games like chess or go. 
 

Jan 07 2019
Jan 07

We recently published a blog post introducing our solution to Google Search Appliance being discontinued—an open source application we built and named Federated Search. If you haven’t already, we recommend checking out that first blog post to get the basics on how we built the application and why. Read on here to learn how you can see for yourself what the application does.

Search API Federated Solr is a complex application, and the best way to understand what's going on is to see it in action! Since the application requires a Solr instance in addition to a number of Drupal modules, we're not able to use Simplytest.me for demos. Instead, we've bundled all of the pieces together with Palantir's open source dev tools — the-vagrant and the-build — for a seamless demo experience that runs in a local virtual machine (VM) running on Vagrant. Head to GitHub to review the requirements, and then clone the repo and get started.

Setting up the environment

The-vagrant is a customizable vagrant environment that can be built into a project from scratch or easily retrofit an existing project (such as a new support client). On first setup, a handy install wizard takes users through a configuration process to choose hostnames, enable optional services like Solr, and enable further customization through Ansible tasks. The-vagrant is capable of handling single site, multi-site, or multiple-site (many docroot) setups in a single box, so it was a perfect match for our Federated Search environment.

The-build is a set of reusable phing targets for building Drupal projects. Once our VM is up and running, we use a standard set of these tasks to automate a number of complex tasks, such as:

  • Copying settings and services files into Drupal sites directories
  • Installing Drupal using an install profile and any existing config
  • Running post-install tasks like migrations
  • Running test suites
  • Importing databases from hosting environments
  • Deploying code to hosting environments

We have a shared set of phing targets that provide the foundation for many of these tasks, and each project extends them to meet their specific needs.

Building the demo

The Federated Search Demo repo builds a simulated multiple site environment, with a Solr server to boot, in the comfort of your own VM. Our demo site is expressly designed for both testing and development.

Because the application supports multisite, Domain Access, and standalone sites, we wanted to be able to demo (and develop for) all possible scenarios. To this end, the demo contains four docroots: Drupal 7 standalone, Drupal 7 Domain Access (coming soon), Drupal 8 standalone, Drupal 8 Domain Access. The D8 sites use the amazing core Umami profile to demo with real content, while the D7 site uses Devel Generate for some lorem ipsum-based content.

As of this writing, Domain Access is supported in the Drupal 7 module code, but not installed in the demo profile. The reverse is true for Drupal 8, and making the Drupal 8 version of Federated Search support Domain Access is under active development. We literally had to build the VM in order to finish those features!

There are a lot of dependencies involved, so let’s go to an application diagram:

Repo diagram

There’s a lot going on there, but we suggest grabbing the repo and seeing for yourself.

What to expect

Once you clone the demo repo, there are full instructions on getting the VM and Drupal up and running. After installing all of the sites, you can start by visiting http://d8.fs-demo.local and use the search box to test a search (maybe try mushrooms, yum). You should see the React-powered search page with your results and a number of filters on the left side which you can experiment with.

Search results page for mushrooms

Once you see the search results, you can dig in to how it works. In the Search App Settings (found at admin/config/search-api-federated-solr/search-app/settings) you can control a number of pieces of how the search page is displayed including it’s route and title. We set the page to default to ‘/search-app’ so as not to conflict with the default core configuration. Any changes made on this page should clear the cache for the search application and immediately be reflected on refresh.

Drupal interface

Next, you may want to see how data is indexed. The search index field config page (found at admin/config/search/search-api/index/federated_search_index/fields) will show a list of all of the mapped fields the site is sending to the index. Clicking on Edit will show you the details of each, showing each bundle in the site and how it’s being sent to the index. The Edit modal includes a token picker, showing the true power of this tool—the ability to use tokens or text at the bundle level to send data to our index.

Manage fields for search index

Edit field Federated Image

From this screen, try editing the config for a field, adding a token or changing a format. Once you do that, Search API will prompt you to re-index your data.

You can do so, then refresh the search results to see the changes. You might also want to inspect the raw data being sent to Solr. To do that, visit the Solr dashboard (at http://federated-search-demo.local:8983/solr/#/drupal8/query) and execute the default query. There you can see all of the fields being sent to the index.

Solr index

Coming back to the search page, inspecting the results with the React Dev Tools will help you understand how the application is handling data. Once you install the browser extension, you can inspect the app, view the React components, see props being passed through the stack, and more. For an even deeper dive into the React application, you can clone that project and build it locally.

Inspecting results

Contributing

In addition to providing a full demo environment, this repo also serves as a development environment for Search API Federated Solr and Search API Field Map. While those modules are installed by composer, the repo also links them into the ‘/src/’ directory for easy access. From there, you can add a GitHub remote or create patches for Drupal.org.

Issues for the demo can be raised on GitHub, and issues for the modules can be on either GitHub or Drupal.org. Be sure to read the handbook on Drupal.org for even more detail on how the system works.

Learn more about Federated Search in this presentation from Decoupled Days (or just view the slides).

Jan 07 2019
Jan 07

Last year, Google announced Google Search Appliance would be discontinued. This announcement means that enterprise clients needing a simple yet customizable search application for their internal properties will be left without a solution some time in 2019.

As the request of an existing client, Palantir has worked for the past year to produce a replacement for the GSA and other federated search applications using open-source tools. We abstracted this project into a reusable product to index and serve data across disparate data sources, Drupal and otherwise, and we’re now happy to share it with the community.

What is Federated Search?

We have created an application that allows you to index multiple Drupal (or other) sites to a single search application, and then serve the results out in a consistent manner with a drop-in application that will work on any site where you’re able to add a little CSS and JavaScript.

Federated Search is being released publicly as an open source solution to a common problem. It works out-of-the-box, and can also be customized. There are three main parts to the product:

  • Content indexing via Drupal integration (provided)
  • Result serving via React application (provided)
  • Data storage in a Solr backend (required; we can recommend SearchStax as an option.)

How was Federated Search built?

Every search application, no matter what the implementation, has three main parts: the source, the index, and the results.

Working from the results backward, we began with identifying a schema in which all of our source data would be stored. A basic review of search pages across the internet reveals a fairly common set of features. A title, some descriptive text, and a link are the absolute minimum for displaying search results. Some extra metadata like an image, date, and type are also useful to give the user a richer experience and some filter criteria. Finally, since we’re searching across sites, we’ll need some data about where the item comes from.

sitewide search results page from prototype

With that schema in mind, and knowing Drupal would be our data source, we identified a need to get data from some unknown structure in Drupal (because every site might have vastly different content types) into a fixed set of buckets. Since much of the terminology is the same, the Metatag module quickly came to mind — Metatag allows users to take data from Drupal fields using Tokens and output it into specific meta-tags on the site. With that same pattern in mind, we built Search API Field Map. This module allows us to use tokens to set bundle-level patterns, which all get indexed into the same field in our index.

At Palantir, search is part of every project. We’ve implemented numerous custom and complex search configurations, and almost every time we lean on Apache Solr for our backend. Solr is a CMS-agnostic search index that has a well-supported and robust existing toolchain for Drupal. Search API and Search API Solr provided a solid groundwork from which to build our source plugins, so then the last step was getting our data out. Solr comes out of the box with “Response Writers” that cover almost every known data format, so our options were wide open.

We knew we wanted to provide our client with a CMS-agnostic drop-in interface and that we had a data source that’s fluent in JSON, so that immediately pointed us in the direction of a Javascript framework. The JS space is incredibly dense at the moment, but after some investigation, we settled on React to provide us the robust data management and user interface for our search application.

We started with an existing framework to provide the query handlers and basic front-end components, then extended it with our own set of component packs to build out the user interface. Search API Federated Solr provides the React application as a Drupal library, adds a search block, and surfaces some custom per-site configuration for the search application.

A Flexible, Open Source Search Solution

With Drupal, Solr, and React working together, we’re able to index data from completely arbitrary sources, standardize it, and then output it in an easily consumable way. This approach means more flexibility for site administrators and a cleaner experience for users.

A number of commercial applications exist to provide this functionality, but our solution provides a number of benefits:

  • Keeping the data source tightly coupled with Drupal allows for maximum customization and access to the source content.
  • Providing a decoupled front-end allows us to surface results anywhere, even outside of Drupal.
  • Being built on 100% open-source code allows for community improvement and sharing.

How can you use this or download the code?

Between the Drupal modules and React code, there’s a lot going on to make this application work, and even with those, you’ll still need to bring your own Solr backend to index the data. Luckily, we’ve put all those pieces together into a fully functional demo box using Palantir’s open source Vagrant environment and build tasks.

If you’d like to inspect the pieces individually, here they are:

Palantir plans to maintain these projects as a cohesive unit moving forward, and pull requests or D.o issues on the projects above are always welcome.

Does it have to be a Drupal site?

No! While we provide everything needed to index a Drupal 8 or Drupal 7 site, there’s no reason you can’t configure an additional data source to send content to the same Solr index, as long as it conforms to the required schema. The front-end is also CMS-agnostic, so you could search Drupal sites from Wordpress, another CMS, or even from a statically generated site.

You can read how to see Federated Search in action in our Demo blog post or learn more about Federated Search in this presentation from Decoupled Days (or just view the slides).

Jan 07 2019
Jan 07

Pega Community Documentation Page

Book navigation is nested several levels

The import project is not yet complete, so I cannot give a live link, but here is a screenshot of the navigation. Notice that most of the navigation is collapsed, but enough of it is open to show the path to the current page.

,

Significant Numbers

  • 4472 pages in the book
  • 2.7 MB rendered (twice) for each page
  • 40-50 sec initial load
  • 6-9 sec load after caching

The navigation is rendered twice on every page: once for desktop and once for mobile. We should dos something about that, but not today.

After we did this work, the cached page loads in 2-3 sec. Normally, I would not brag about times like that, but it is a lot better than it was. (Also, the 6-9 seconds relied on some earlier caching work.)

I think that Emily Dickinson would understand how I feel about these load times:

The Heart asks Pleasure—first—
And then—Excuse from Pain—

,

Strategy

Cache the navigation once per book

If we cache each page of the book, that means about 10 GB of cache. It also means that we spend a lot more time generating the navigation menu than if we generate it once per book.

Set active trail with javascript

The problem with caching the navigation once per book is that we need to customize it for each page, opening up the path to the current page. So let’s customize it per page with javascript (client side).

,

Implementation

Here is a simplified version of the Twig Template that creates the navigation block:

{% if tree %} {{ top_book_title }} {{ tree }} {% endif %}

The important part is the Twig variable at the end: {{ tree }} is the part we have to compute and cache. Also notice that we already have some CSS classes that we can target with jQuery.

Hook Node View

From the screenshot above, you might think that the navigation is in a block, placed in the sidebar region. In fact, the caching would be a little simpler if that were the case. The way the site is built, it is actually in the main page array.

Here is the code that adds a render array for the book navigation. After a few checks to make sure that it should be added, it creates a simple render array with a custom #theme and a single parameter. That is, it depends on the current book ('#book_id' => $book_id) but not on the current page.

function pdn_book_node_view(array &$build, NodeInterface $node, EntityViewDisplayInterface $display, $view_mode) { if ($view_mode != 'full') { return; } if (empty($node->book['bid']) || !empty($node->in_preview)) { return; } $book_id = $node->book['bid']; $book_node = Node::load($book_id); if (!$book_node->access()) { return; } // Cache the navigation block once for the entire book. // We will set the active trail client-side. $build['book_nav'] = [ '#theme' => 'book_nav', '#book_id' => $book_id, '#weight' => 100, '#cache' => [ 'keys' => ['pdn_book_nav', $book_id], 'contexts' => ['languages'], 'tags' => ["node:$book_id"], 'max-age' => Cache::PERMANENT, ], ]; }

I will explain the #cache parameters below. (If you want, you can skip to the section “Tell Drupal how to cache the navigation”.)

Hook Theme

This is pretty standard, but for completeness here is the definition of the custom theme function. Again, there is only one parameter, the book ID. The Twig template is the one I showed above, book_nav.html.twig.

function pdn_book_theme($existing, $type, $theme, $path) { return [ 'book_nav' => [ 'variables' => [ 'book_id' => 0, ], ], ]; }

Preprocess Function

This function takes the single book_id parameter provided to the theme function and adds the other variables used in the Twig template, including $variables['tree']. This function was already in the code before we started working on it. It is based on some code already in the core Book module.

function template_preprocess_book_nav(&$variables) { /** @var \Drupal\book\BookManager **/ $book_manager = \Drupal::service('book.manager'); // Get the nested array (tree) of menu links. $book_tree = $book_manager ->bookTreeAllData($variables['book_id']); // Generate a render array from the tree of links. $tree_output = $book_manager ->bookTreeOutput(array_shift($book_tree)['below']); $variables['tree'] = $tree_output; $variables['book_url'] = \Drupal::url( 'entity.node.canonical', ['node' => $variables['book_id']] ); $book_node = Node::load($variables['book_id']); $variables['top_book_title'] = $book_node->getTitle(); $variables['top_book_empty'] = !$book_node->hasField('field_body') || $book_node->get('field_body')->isEmpty(); }

Javascript

Here is the javascript that opens up the path to the current page. Since jQuery is very good at traversing the DOM, this ends up being a lot simpler than the PHP code we used previously.

The second half of this snippet was already there. We just added the part that finds the , looks inside it for a link to the current page, and then adds class="active" to that link and its parents and class="c-book-nav--list-expanded" to the parent

  • elements.
  • Drupal.behaviors.bookNavExpand = { attach: function attach(context) { var bookNav = $('.c-book-nav', context); $('a[href="https://www.isovera.com/caching-large-navigation-menus-drupal/' + context.location.pathname + '"]', bookNav) .addClass('active') .parentsUntil(bookNav, '.c-book-nav--list-expandable') .addClass('c-book-nav--list-expanded') .children('a') .addClass('active'); $('.c-book-nav--list-expanded > .c-book-nav--list', context) .once('bookNavExpandInit') .css('display', 'block'); $('.c-book-nav--expand-arrow', context) .once('bookNavExpandClick') .on('click', function() { $(this).parent().toggleClass('c-book-nav--list-expanded'); $(this).siblings('.c-book-nav--list').slideToggle(); }); } };

    There is room for improvement here. It is a little inefficient to traverse the DOM twice (once to set class="c-book-nav--list-expanded" and a second time to set display="block" on those elements). We decided to KISS for now: just add our 7 lines of javascript and not touch what was already there.

    ,

    Tell Drupal how to cache the navigation

    Here again is the render element we added to the page.

    $build['book_nav'] = [ '#theme' => 'book_nav', '#book_id' => $book_id, '#weight' => 100, '#cache' => [ 'keys' => ['pdn_book_nav', $book_id], 'contexts' => ['languages'], 'tags' => ["node:$book_id"], 'max-age' => Cache::PERMANENT, ], ];

    Now let’s look at the four entries in the #cache sub-array.

    Cache Keys

    'keys' => ['pdn_book_nav', $book_id],

    We provide two cache keys:

    • A unique string to identify “our” cache entries.
    • The book ID.

    This is how we cache once per book.

    Without cache keys, any other cache data will bubble up to the page render array, but our render array will not be cached by itself, which is what we want. If the book navigation were in a block, then the block would be cached and we would not have to supply cache keys.

    Cache Contexts

    'contexts' => ['languages'],

    If the book is viewed in another language, then the link text will change, so we need to tell Drupal to store a separate copy for each language. Maybe the link URLs will also change, depending on how we manage languages.

    In fact, this site is not (yet) multilingual, so we are trying to be a little proactive.

    A drawback to the once-per-book strategy is that the navigation menu will not update if any individual page is updated, say with a new title. This is not a problem for books imported from an external system, but the site has other books as well. We may decide to add the 'route.book_navigation' cache context, if this does not affect performance badly. See Cache contexts in Drupal’s Cache API documentation.

    Cache Tags

    'tags' => ["node:$book_id"],

    This tells Drupal that when node/$book_id is updated, it should delete the entry from the cache. This is related to how many different variants should be cached. For example, we might want to cache once per book but invalidate it if any page in the book is updated. Then we would include the book ID in the cache keys and we would add cache tags for each node in the book.

    On my local copy of the site, the cache tags are stored in the database, where I can examine them. (See below.) On production, they might be handled by memcache. At the page level, cache tags are sent in HTTP headers, so that Varnish or a CDN can invalidate pages based on cache tags.

    Cache Max Age

    'max-age' => Cache::PERMANENT,

    This tells Drupal to keep the cached version until we say to clear it.

    ,

    Peek At the Database

    On my local copy of the site, the render cache is stored in the database, so we can see the results of these settings with a few queries. On production, this cache is handled by memcache.

    The cache_render Table

    Here is the relevant database table:

    mysql> DESCRIBE cache_render; +------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+---------------+------+-----+---------+-------+ | cid | varchar(255) | NO | PRI | | | | data | longblob | YES | | NULL | | | expire | int(11) | NO | MUL | 0 | | | created | decimal(14,3) | NO | MUL | 0.000 | | | serialized | smallint(6) | NO | | 0 | | | tags | longtext | YES | | NULL | | | checksum | varchar(255) | NO | | NULL | | +------------+---------------+------+-----+---------+-------+ 7 rows in set (0.01 sec)

    Query

    After clearing caches and viewing one page, there is just one entry matching the unique string we supplied as a cache key. I have added some whitespace to make this easier to read. I did not include the data column, since that would have been overwhelming. I skipped serialized: it is a boolean that says whether the data is a simple string or a serialized PHP variable.

    mysql> SELECT cid, expire, created, tags, checksum FROM cache_render WHERE cid LIKE 'pdn_book%' LIMIT 0,1\G ********************** 1. row ********************** cid: pdn_book_nav: 704369: [languages]=en: [theme]=pegawww_theme: [user.permissions]=4f64d6e20026c96e963d91bab0192f9824e8cb2e9352eb4c1ca18d78478abfdb expire: -1 created: 1543638198.782 tags: config:system.book.704369 node:704369 rendered checksum: 12 1 row in set (0.00 sec)

    Cache ID (cid)

    This identifies the cached item.

    • We specified pdn_book_nav in the cache keys.
    • The book ID (704369) also comes from cache keys.
    • languages comes from cache contexts.
    • theme and permissions are default contexts: see below.

    Cache Max Age (expire and created)

    Since we specified 'max-age' => Cache::PERMANENT, in the cache settings, the expire column is set to -1. If we had specified 86400 (one day) then the expire value would have been 86400 more than the created value. (I should check this.)

    Cache Tags

    Again the cache tags describe when this entry should be purged. I am happy to see node:704369 (the book ID), but I am not sure where the other tags are generated.

    Permissions Hash

    I am punting on some of the cache tags, but I promised to explain where two parts of the cache ID come from. See sites/default/services.yml:

    parameters: renderer.config: # Renderer required cache contexts: # # The Renderer will automatically associate these cache # contexts with every render array, hence varying every # render array by these cache contexts. # # @default ['languages:language_interface', 'theme', 'user.permissions'] required_cache_contexts: - 'languages:language_interface' - 'theme' - 'user.permissions'

    This shows that we did not have to specify 'languages' in the cache contexts: it is already added by default. It also explains why the theme and the user permissions appear in the cache ID.

    ,

    Conclusion

    Our main goal was to improve page-load times: they started out terrible and now they are merely bad, maybe even fair. As a bonus, I learned a little about how the cache system works in Drupal 8. Comparing the settings we provided in the render array to what gets stored in the database helped to de-mystify the system for me.

    Try it yourself! In order to experiment with the cache settings, you can skip the theme function and the Twig template; just build your render array directly. Try setting a different max age, or adding cache contexts, and see how it affects what is saved in the database.

    ,

    References

    I already mentioned one reference:

    • Cache contexts

    That is part of the Cache API guide on drupal.org.

    The other reference I found most helpful for explaining the importance of cache keys is

    • Render API overview: Caching

    in the API documentation.

    These two pages in the Render API guide are also useful:

    • Cacheability of render arrays
    • Render arrays
    Jan 07 2019
    Jan 07
    What we can learn from day one of legal online cannabis sales in Canada


    On October 17, 2018, Canada took a progressive step forward as the sale of recreational cannabis became legal for the entire country. It was the end of a prohibition, sparking a wave of new business opportunity. It’s hard to find official numbers for Canada as a whole, but it’s estimated that there were about 212,000 first-day sales across the country worth approximately $28 million! We thought it would be a good opportunity to show some of the benefits of open source vs. SaaS solutions for online cannabis.

    First off, It’s hard to say exactly how many transactions occurred online for Canada as a whole. It’s up to each province and territory to decide how they want sales to proceed and stats are quite limited at this point. We do, however, have solid information for a couple smaller provinces that we can start with. Then we can expand with speculation after that.

    What we know

    Cannabis Yukon

    Cannabis Yukon, the Yukon government run retail outlet, had a combined online and in-store sales totalling about $59,900 (source). About 25% of that number, roughly $15,000, was transacted online. The online retail outlet uses the open source platform Drupal.

    PEI Cannabis

    PEI Cannabis, the Prince Edward Island government run retail outlet, had a combined online and in-store sales totalling about $152,000 (source). About 7% of that number, roughly $21,000, was transacted online. The online retail outlet uses the SaaS platform Shopify. It’s interesting to note that Shopify also runs the provincial online pot shops for Ontario, British Columbia and Newfoundland.

    Functionality is the same

    All ecommerce cannabis outlets in Canada, government or private, are going to have the same features. They need to block access to minors, they need to sell products based on weight and they need to restrict the maximum amount of cannabis an individual can purchase at one time. All other functionality required is standard ecommerce. Functionality-wise, Cannabis Yukon and PEI Cannabis do the same thing. Whether it’s open source or SaaS, there isn’t an edge either way there.

    Where open source has the advantage

    Where it gets interesting, and where the Yukon Government is in a great position to succeed, is commerce architecture and service fees. These are a couple of big reasons why open source is really catching fire in the ecommerce marketplace.

    Commerce architecture

    Yukon Cannabis is built on the Drupal platform. It’s open source software meaning there are no service fees to use and anyone who uses it can customize and innovate the software however they like. Development can be done in-house or with any 3rd party development agency familiar with the underlying code, mainly PHP.

    An advantage to using a platform like Drupal is that it can integrate and talk to other services your operation may use for accounting, marketing, inventory, customer management, etc. Integrations and automation eliminate swivel chair processes that restrict business growth.

    PEI Cannabis, on the other hand, is somewhat vendor locked using the Shopify platform. Shopify does have a rich ecosystem of integrations, but if there’s ever a need to develop a new integration, PEI Cannabis is restricted to dealing with only Shopify or their small group of partners. That usually means high cost.

    Service fees

    When a sale is made using a SaaS platform, a certain percentage of the sale is lost to taxes and additional platform specific transaction fees. In the case of Shopify Plus, the enterprise fee structure is $2,000 per month + 0.25% per transaction, capping at a maximum of $42,000 per month (source). You can optionally use ‘Shopify Payments’ instead which carries a transaction fee of 1.6% + 30 cents per transaction. This would be a better way to go only if you don’t require any other payment gateways, but in our experience that isn’t the case. Finally, in addition to Shopify’s fees, the platform has an extension library to extend the functionality to your store. Most of these extensions carry their own monthly fee and there’s a very good chance you would need some of them.

    With SaaS ecommerce platforms like Shopify, year after year the cost of ownership increases. At minimum, the yearly fees paid to Shopify amount to $24,000 and can rise as high as $480,000. That doesn’t include any additional extensions that you use or any payment gateway fees. PEI Cannabis must pay these fees (and so do the governments of BC, Ontario and Newfoundland who also use Shopify).

    Open source ecommerce platforms, on the other hand, don’t necessarily have any of these additional fees. Aside from the standard payment gateway fees and hosting fees, Yukon Cannabis pays no additional monthly or yearly licensing fee to use their ecommerce platform. Whether they sell $15,000 or $15 million, the investment that they’ve made into the development of their website should pay for itself quite quickly, potentially within a year.

    Furthermore, provincial government cannabis retailers are essentially public companies. A large portion of the profit made is to be distributed at the provincial and federal levels to support various public services and initiatives. By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

    By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

    Service fee breakdown

    Here’s a rough breakdown of potential monthly and annual platform service fees based on some of the numbers we know. We know the combined (online and in-store) sales from day one were elevated due to the hype of legalization, and we know that BC sales dropped by 70% on day two. For our fee breakdown, we’ll take the 70% reduced amount from the combined total numbers we know and use that to calculate a 30 day monthly sales estimate. We’ll use the combined total because most ecommerce platforms also support an official in-store point of sale component. This is all speculation of course, but it still shows realistic ecommerce sales numbers and how service fees accumulate based on them.

    While the numbers shown below may appear to be quite large at first, Statistics Canada, the national statistics government agency, predicted back in September that legal cannabis sales for the first 3 months will be between $816 million and $1 billion nationwide. If that ends up being true, the numbers below would actually be grossly underestimated!

    Est. Monthly Sales
    Based on 30% of day one total x 30 days (XX/100 x 30) x 30 Open source
    Annual and Monthly Fee: 0% Shopify Plus
    Monthly including transaction fee
    (calculator) Shopify Plus
    Annual 
    (monthly x 12)Yukon Cannabis
    30 day est: $539,100
    Day one: $59,900$0$2,994.31$35,931.72PEI Cannabis
    30 day est: $1,368,000
    Day one: $152,000$0$4523.13$54,277.56Nova Scotia
    30 day est: $5,940,000
    Day one: $660,000$0$12,955.69$155,468.28Alberta
    30 day est: $6,870,000
    Day one: $730,000$0$14,670.97$176,051.64All of Canada *
    30 day est: $252,000,000
    Day one: $28,000,000$0$40,000 (cap)  $480,000 (cap)

    * The government agency Statistics Canada predicts that legal cannabis sales in Canada will be between $816 million and $1 billion (source).

    Where SaaS has the advantage

    The biggest advantage that SaaS such as Shopify has over open source is the speed at which you can get your product to market and the simplicity of use.

    If you’re just starting out and need to get an ecommerce site up and running quick, these services are turn-key and can get your product to market fast. The website management interface is clean and easy to use, and most people can do what they need to do with little to no training.

    There is a reason why companies like Shopify are quite dominant and it’s largely because of the simplicity. While we strongly believe that you shouldn’t choose your platform based on features, many people are willing to pay extra to be able to do it all themselves.

    Takeaways

    Watching a new industry unfold in Canada has been fun. It’s interesting to see that both open source and SaaS has found its way into the legal cannabis marketplace. Clearly both open source and SaaS work for this industry, it’s more about what you’re willing to pay and what ecommerce ecosystem you think is best for your business and its future growth.

    If you’re thinking about online cannabis retail (or any other online retail for that matter), Acro Media has the expertise and processes in place to help guide you to online commerce success. Try our Digital Commerce Assessment Tool to uncover problematic areas within your digital commerce operations.

    Complete Your Digital Commerce Assessment

    Jan 07 2019
    Jan 07
    The home automation system is a combination of software and hardware devices which handles home routine such as lights, temperature/humidity (microclimate) and entertainment systems (TV, audio etc.) automatically based on some scenarios. This post is about building such system based on Domoticz server, Xiaomi and Broadlink devices. I'll try to cover some topics such as system set up and useful scenarios. Agenda:
    1. Hardware
      1. Gateway
      2. Signaling sensors
      3. Data provider sensors
      4. Controlling sensors
      5. Smart lamps
      6. Server and wifi router
    2. Software
      1. Domoticz
      2. Mini DLNA
    3. Adding devices to Domoticz
      1. Gateway
      2. ZigBee devices
      3. Yeelight Smart bulbs
      4. Broadlink RM 3 mini and RM Pro+ remote controls
      5. Naming convention, groups, and scenes
    4. Network
    5. Scenarios
      1. Network devices state
        1. Are you at home?
      2. Notifications
        1. Motion activity detected
        2. Doors/windows activity detected
        3. Fire detected (high temperature)
        4. ZigBee devices batteries level report
      3. Room occupation
        1. Motion trigger
        2. Windows and doors trigger
      4. Room presence detection
        1. TV
        2. Laptop
        3. Room locking
      5. Light
        1. Room occupation trigger
        2. Button trigger
      6. Microclimate
      7. Alarm clock
    6. Remote access to your Domoticz
    7. Monitoring
      1. Service uptime
      2. Containers state
    8. Conclusion

    Hardware


    Let's overview hardware which will be used in the system. I distinguish 5 types of devices/sensors for building home automation systems: gateways, signaling sensors, data providers, controlling sensors and "smart" light. Most of Xiaomi/Aqara devices are working over ZigBee protocol, but there are some which are working over wifi like lamps. In a nutshell, a gateway is a central place of a smart home which receives all the data from other sensors/devices which are connected to it. Signaling sensors tell about some event. Data sensors provide environment information. Controlling sensors send commands to home devices. Smart lamps can be controlled over wifi in order to switch light.
    There are a lot more devices and sensors on the market for different purposes but in this post, I'll cover only that which are used for my basic scenarios.

    Gateway

    • Gateway (Xiaomi, WiFi/ZigBee) - a central point of ZigBee network. Receives events from other sensors. A system can run scenarios based on provided information.

    Signaling sensors

    • Motions sensor (Xiaomi or Aqara, ZigBee) - emits a signal when motion is detected.
    • Door/window state sensor (Xiaomi or Aqara, ZigBee) - emits a signal when door/window is being opened or closed.

    Data provider sensors

    • Temperature and humidity sensor (Xiaomi or Aqara, ZigBee) - provides current temperature and humidity.
    • Lux sensor (Aqara, ZigBee) - provides current luminosity. Usually, this sensor combined with a motion sensor (Aqara).

    Controlling sensors

    • Button (Xiaomi, ZigBee) - sends commands (single click, double click and long click).
    • Socket (Xiaomi or Aqara, ZigBee) - power control.
    • Remote control RM Pro + (Broadlink, WiFi) - sends commands to IR and RF controlled devices such as conditioner, TV etc.
    • Remote control RM Mini (Broadlink, WiFi) - sends commands only to IR controlled devices.

    Jan 07 2019
    Jan 07

    Note: This article is a re-post from Mateu's personal blog.

    I have been very vocal about the JSON:API module. I wrote articles, recorded videos, spoke at conferences, wrote extending software, and at some point, I proposed to add JSON:API into Drupal core. Then Wim and Gabe joined the JSON:API team as part of their daily job. That meant that while they took care of most of the issues in the JSON:API queue, I could attend the other API-First projects more successfully. I have not left the JSON:API project by any means, on the contrary, I'm more involved than before. However, I have just transitioned my involvement to feature design and feature sign-off, sprinkled with the occasional development. Wim and Gabe have not only been very empathic and supportive with my situation, but they have also been taking a lot of ownership of the project. JSON:API is not my baby anymore, instead we now have joint custody of our JSON:API baby.

    As a result of this collaboration Gabe, Wim and I have tagged a stable release of the second version of the JSON:API module. This took a humongous amount of work, but we are very pleased with the result. This has been a long journey, and we are finally there. The JSON:API maintainers are very excited about it.

    I know that switching to a new major version is always a little bit scary. You update the module and hope for the best. With major version upgrades, there is no guarantee that your use of the module is still going to work. This is unfortunate as a site owner, but including breaking changes is often the best solution for the module's maintenance and to add new features. The JSON:API maintainers are aware of this. I have gone through the process myself and I have been frustrated by it. This is why we have tried to make the upgrade process as smooth as possible.

    What Changed?

    If you are a long-time Drupal developer you have probably wondered how do I do this D7 thing in D8? When that happens, the best solution is to search a change record for Drupal core to see if it change since Drupal 7. The change records are a fantastic tool to track the things changed in each release. Change records allow you to only consider the issues that have user-facing changes, avoiding lots of noise of internal changes and bug fixes. In summary, they let users understand how to migrate from one version to another.

    Very few contributed modules use change records. This may be because module maintainers are unaware of this feature for contrib. It could also be because maintaining a module is a big burden and manually writing change records is yet another time-consuming task. The JSON:API module has comprehensive change records on all the things you need to pay attention when upgrading to JSON:API 2.0.

    Change Records

    As I mentioned above, if you want to understand what has changed since JSON:API 8.x-1.24 you only need to visit the change records page for JSON:API. However, I want to highlight some important changes.

    Config Entity Mutation is now in JSON:API Extras

    This is no longer possible only using JSON:API. This feature was removed because Entity API does a great job ensuring that access rules are respected, but the Configuration Entity API does not support validation of configuration entities yet. That means the responsibility of validation falls on the client, which has security and data integrity implications. We felt we ought to move this feature to JSON:API Extras, given that JSON:API 2.x will be added into Drupal core.

    No More Custom Field Type Normalizers

    This is by far the most controversial change. Even though custom normalizers for JSON:API have been strongly discouraged for a while, JSON:API 2.x will enforce that. Sites that have been in violation of the recommendation will now need to refactor to supported patterns. This was driven by the limitations of the serialization component in Symfony. In particular, we aim to make it possible to derive a consistent schema per resource type. I explained why this is important in this article.

    Supported patterns are:

    • Create a computed field. Note that a true computed field will be calculated on every entity load, which may be a good or a bad thing depending on the use case. You can also create stored fields that are calculated on entity presave. The linked documentation has examples for both methods.
    • Write a normalizer at the Data Type level, instead of field or entity level. As a benefit, this normalizer will also work in core REST!
    • Create a Field Enhancer plugin like these, using JSON:API Extras. This is the most similar pattern, it enforces you to define the schema of the enhancer.

    File URLs

    JSON:API pioneered the idea of having a computed url field for file entities that an external application can use without modifications. Ever since this feature has made it into core, with some minor modifications. Now the url is no longer a computed field, but a computed property on the uri field.

    Special Properties

    The official JSON:API specification reserves the type and id keys. These keys cannot exist inside of the attributes or relationships sections of a resource object. That's why we are now prepending {entity_type}_ to the key name when those are found. In addition to that, internal fields like the entity ID (nid, tid, etc.) will have drupal_internal__ prepended to them. Finally, we have decided to omit the uuid field given that it already is the resource ID.

    Final Goodbye to _format

    JSON:API 1.x dropped the need to have the unpopular _format parameter in the URL. Instead, it allowed the more standard Accept: application/vnd.api+json to be used for format negotiation. JSON:API 2.x continues this pattern. This header is now required to have cacheable 4XX error responses, which is an important performance improvement.

    Benefits of Upgrading

    You have seen that these changes are not very disruptive, and even when they are, it is very simple to upgrade to the new patterns. This will allow you to upgrade to the new version with relative ease. Once you've done that you will notice some immediate benefits:

    • Performance improvements. Performance improved overall, but especially when using filtering, includes and sparse fieldsets. Some of those with the help of early adopters during the RC period!
    • Better compatibility with JSON:API clients. That's because JSON:API 2.x also fixes several spec compliance edge case issues.
    • We pledge that you'll be able to transition cleanly to JSON:API in core. This is especially important for future-proofing your sites today.

    Benefits of Starting a New Project with the Old JSON:API 1.x

    There are truly none. Version 2.x builds on top of 1.x so it carries all the goodness of 1.x plus all the improvements.

    If you are starting a new project, you should use JSON:API 2.x.

    JSON:API 2.x is what new installs of Contenta CMS will get, and remember that Contenta CMS ships with the most up-to-date recommendations in decoupled Drupal. Star the project in GitHub and keep an eye on it here, if you want.

    What Comes Next?

    Our highest priority at this point is the inclusion of JSON:API in Drupal core. That means that most of our efforts will be focused on responding to feedback to the core patch and making sure that it does not get stalled.

    In addition to that we will likely tag JSON:API 2.1 very shortly after JSON:API 2.0. That will include:

    1. Binary file uploads using JSON:API.
    2. Support for version negotiation. Allows latest or default revision to be retrieved. Supports the Content Moderation module in core. This will be instrumental in decoupled preview systems.

    Our roadmap includes:

    1. Full support for revisions, including accessing a history of revisions. Mutating revisions is blocked on Drupal core providing a revision access API.
    2. Full support for translations. That means that you will be able to create and update translations using JSON:API. That adds on top of the current ability to GET translated entities.
    3. Improvements in hypermedia support. In particular, we aim to include extension points so Drupal sites can include useful related links like add-to-cart, view-on-web, track-purchase, etc.
    4. Self-sufficient schema generation. Right now we rely on the Schemata module in order to generate schemas for the JSON:API resources. That schema is used by OpenAPI to generate documentation and the Admin UI initiative to auto-generate forms. We aim to have more reliable schemas without external dependencies.
    5. More performance improvements. Because JSON:API only provides an HTTP API, implementation details are free to change. This already enabled major performance improvements, but we believe it can still be significantly improved. An example is caching partial serializations.

    How Can You Help?

    The JSON:API project page has a list of ways you can help, but here are several specific things you can do if you would like to contribute right away:

    1. Write an experience report. This is a Drupal.org issue in the JSON:API queue that summarizes the things that you've done with JSON:API, what you liked, and what we can improve. You can see examples of those here. We have improved the module greatly thanks to these in the past. Help us help you!
    2. Help us spread the word. Tweet about this article, blog about the module, promote the JSON:API tooling in JavaScript, etc.
    3. Review the core patch.
    4. Jump into the issue queue to write documentation, propose features, author patches, review code, etc.

    Photo by Sagar Patil on Unsplash.

    Jan 07 2019
    Jan 07

    Mateu, Gabe and I just released JSON:API 2.0!

    Read more about it on Mateu’s blog.

    I’m proud of what we’ve achieved. I’m excited to see more projects use it. And I’m confident that we’ll be able to add lots of features in the coming years, without breaking backwards compatibility. I was blown away just now while generating release notes: apparently 63 people contributed. I never realized it was that many. Thanks to all of you :)

    I had a bottle of Catalan Ratafia (which has a fascinating history) waiting to celebrate the occasion. Why Ratafia? Mateu is the founder of this module and lives in Mallorca, in Catalunya. Txin txin!

    If you want to read more about how it reached this point, see the July, October, November and December blog posts I did about our progress.

    Jan 07 2019
    Jan 07
    • Shefali Shetty
    • Date: 07-01-2019

    Did you know, on an average an adult makes about 35000 decisions each day?! And suddenly, life feels more difficult. Most are mundane but taking the right step towards an important decision can turn you into a winner. Since the release of Drupal 8 in November 2015, Drupal website owners have been in a dilemma. To upgrade or not to upgrade. To migrate to Drupal 8 now or simply wait till Drupal 9 releases and completely skip 8. And to make things more knotty, there are PHP, Symfony and other version upgrades to keep track of too.

    At this point, you might wonder why choose or stick with Drupal at all when everything seems so complex and tedious. Why shouldn’t I just switch to a rather simpler CMS where I can sit back and just let my content work its magic, you ask? Here’s the thing – Drupal is an open-source content management framework that is best known for the security, robustness and flexibility it offers. Without constant and consistent updates and patches, Drupal wouldn’t have been the relevant, dependable and trusted CMS that it is today. This continuous innovation approach has helped Drupal in offering new Drupal features, advanced functionalities and security patches with every minor release.

    Drupal’s Plan of Action

    Few months ago, during his keynote, Dries announced (and wrote) about Drupal’s structured release schedule. Although this clarity gave much relief to many, it also sent some of our Drupal 7 clients in a frenzy.

    Taken from https://dri.es/drupal-7-8-and-9

    Optimistically, Drupal 9 releases in June 2020. The initial plan, however, was to release it in December 2020 but that would give website owners only 12 months to migrate to Drupal 9. Hence it was decided that it would be best to have an 18-month window at the least or a smooth migration. Drupal 8 support will end in November 2021.

    Drupal 7 was expected to reach end-of-life by November 2020 initially but since several websites might still be running on Drupal 7 even by 2020, the community has decided to extend support to Drupal 7 till November 2021. Which means that both - Drupal 7 and Drupal 8, will reach end-of-life at the same time!

    The Dependence

    I believe PHP and Symfony are the heart and soul of Drupal. Every move Drupal makes depends on the release cycles of these two significant elements. Symfony releases a new minor version every six months and a major version every two years. In order to be compatible with Symfony’s releases, Drupal has timed its minor releases one month after every Symfony release. Because Drupal 8 depends on Symfony 3, which has an end-of-life in Nov 2021, Drupal 8 HAS TO end-of-life by Nov 2021.

    Security Support for PHP version 5.x and 7.0 have ended in December 2018. While Drupal websites can still continue to run on older PHP versions, upgrading the PHP version will not only receive active community support but also immensely improve site performance. Dries recommends updating the website’s PHP version to at least PHP 7.1 and ideally to PHP 7.2 (supported by Drupal 8.5). The latest PHP version 7.3 will be supported by Drupal 8.7 which is scheduled to be released by May 2019.

    So, why migrate my Drupal 7 websites to Drupal 8 now instead of simply migrating to Drupal 9?

    I concur. This is an extremely valid query which makes total sense. Yes, you can completely skip Drupal 8 and migrate to Drupal 9 before Drupal 7’s end-of-life (Nov 2021). If you plan to hang on to Drupal 7 till then, you have to make sure you update your PHP versions for better support and optimized performance. You could also hire a vendor who will provide you with a Long Term Support (LTS) for your Drupal 7 website beyond its end-of-life.

    Although, there are a few advantages of migrating to Drupal 8 now.

    Mark your calendars!

    Like everything else, Drupal too has evolved over the years and now has an extremely structured roadmap that can help tackle most of its obvious obstacles. With every release, Drupal is getting better while embracing its past and deprecating those outdated/unsecure elements. Drupal isn’t competing with anyone but itself – trying to outdo its past with every minor/major upgrade release. To upgrade to Drupal 8 now from Drupal 7 or to wait till Drupal 9 is out, is really a choice site owners need to make depending on their business goals, website complexities, budget and time constraints. Specbee is a Drupal development company and our Drupal experts can help you make a better decision.

     

    Huge shout out to @malavya88 for his very insightful inputs!

    Jan 06 2019
    Jan 06

    2018 was a big year for Webform CiviCRM module. I wanted to take a moment to highlight some of the new features that were added in 2018 (with some examples/screenshots) and take a look at what's to come in 2019!

    Webform CiviCRM Integration - what is this?

    Webform CiviCRM is a Drupal module that in a nutshell exposes CiviCRM APIs (with which you can create CiviCRM contacts, contributions, memberships, participant registrations, activities - just about any CiviCRM Entity programmatically) to the powerful Drupal Webform module - a very popular (over 450,000 Drupal sites are using it) and highly configurable drag and drop form builder. Webform CiviCRM itself is a popular module - over 3,000 CiviCRM projects are using it. That's more users/sites than the Mosaico Extension has! Webform CiviCRM was invented by Coleman Watts (of the CiviCRM Core Team) and is supported by the CiviCRM community:  https://www.drupal.org/project/webform_civicrm

    2018 - highlights

    is:pr is:closed updated:>2018-01-01 -> 88 closed! Some highlights include:
    • enhancements to recurring contributions via Webform CiviCRM (thanks to Biodynamics Association (USA) for co-funding this) - you can now configure your webform such that you can pay any amount (Event, Membership) in instalments as well as start a regular recurring open-ended Donation. An example of this would be swim club fees -> a full season is 10 months and costs $3,000 for the entire year. You can now configure your webform such that parents can sign up their child(ren) for Memberships/Events -> and select to pay all at once or in e.g. 10 instalments of $300/month.
    • Stripe support (thanks to contributions by Matthew Wire from MJW Consulting) - Matt has been doing a lot of work on the Stripe Extension and we've been supportive of changes he has PR-ed to Webform Civicrm module.  This means that Webform CiviCRM is now compatible with all major in-line Payment Processors: Stripe, iATS Payments and PayPal Pro.
    • being able to configure financial types (thanks to PEMAC (Canada) for funding this) - it is now possible to e.g. charge the correct Sales Tax [which is defined per Financial Type] based on a member's Province/location.

    • Membership Application
    • added line item support (thanks to Wilderness Committee (Canada) for funding this) - it is now possible to add up to 5 additional lineItems for one Contribution. So you can now do things like: make a donation, purchase a calendar, pay for postage - all on the same webform - and in combination with the financial type improvements - you can control the financial types for every line item, ensuring that (in our example) - the donation becomes eligible for Charitable Tax Receipting but the calendar purchase and the postage do not. 
    • numerous improvements re: cases, activities, memberships (thanks to people at Compucorp and Fuzion, and many others)
    • many other improvements - I apologize for missing anything/anyone!
    • Coleman and I ran a 2h sold-out Workshop on Webform CiviCRM at CiviCamp Calgary 2018. We covered lots of features and in-hindsight wished we had recorded it. Next time! Amongst many other items we covered how the Registration form for CiviCamp Calgary 2018 was built (allowing multiple participants to be signed up for multiple events and also including a Partner discount code field).

    • CiviCamp Calgary Registration

    Also filed under 2018 highlights: Jacob Rockowitz officially released his Drupal 8 version of Drupal webform module - it includes wicked new features that make webforms more portable than ever and new fields like signature fields and my favourite: automated country flags for phone numbers (see screenshot further down).

    Looking ahead at 2019

    D8WFC

    How can user organizations Contribute?

    D8WFC Buff
    Jan 06 2019
    Jan 06

    We've all been there, a node form with a number of related fields, such as name or address, again and again... and again. What if you could package those fields into a widget that can be reused just by adding it to a content type. Not only can it be easily be done, but I'm going to show you how.

    This tutorial will differ from most other custom field type tutorials, because we won't just be creating a field type, but the field type will be a widget with sub-fields.

    Let's first take a cursory look at why you might want to use this type of field type widget, using 'name' as an example, as we will in the tutorial. When working with multiple fields, you typically have two options:

    1. Add discreet fields to the content type, such as 'First name', 'Surname' and so on
    2. Create an entity and field it, then add an entity reference to the content type

    Both of these methods will work, but each has at least one drawback. With option 1, you would need to do the same thing with every content type using the same fields. With option 2, adding the entity reference doesn't necessarily provide you the rendering of its fields, nor CRUD (Create/Read/Update/Delete) services.

    Fortunately, there's a third option: a custom field type that creates a bundled (compound) field. Let's create one, and I'll leave it to you to decide if it's useful to you!

    The Concept

    What is a compound/bundled field? It is a field that contains sub-fields. You are probably familiar with this concept if you have ever looked inside the table that contains a node's body field:

    
    
    +--------------+------------------+------+-----+---------+-------+ 
    | Field        | Type             | Null | Key | Default | Extra | 
    +--------------+------------------+------+-----+---------+-------+ 
    | bundle       | varchar(128)     | NO   | MUL |         |       | 
    | deleted      | tinyint(4)       | NO   | PRI | 0       |       | 
    | entity_id    | int(10) unsigned | NO   | PRI | NULL    |       | 
    | revision_id  | int(10) unsigned | NO   | MUL | NULL    |       | 
    | langcode     | varchar(32)      | NO   | PRI |         |       | 
    | delta        | int(10) unsigned | NO   | PRI | NULL    |       | 
    | body_value   | longtext         | NO   |     | NULL    |       | 
    | body_summary | longtext         | YES  |     | NULL    |       | 
    | body_format  | varchar(255)     | YES  | MUL | NULL    |       | 
    +--------------+------------------+------+-----+---------+-------+ 
    
    

    Take a look at the last three columns: body_value, body_summary and body_format. These will be familiar to you from the node form. A summary, if provided for the body text, is stored in the body_summary sub-field. The body text is stored in body_value, and the text format selected, such as Basic HTML and Full HTML, is stored in body_format.

    That type of structure, in brief, is what we're aiming to create progammatically. We'll look closely at the results in our own table, later. 

    Another aspect of the concept of what we'll be doing that is worth knowing, up front: we're not actually creating a field, we're creating a field type. This, too, we'll take a closer look at, later.

    So, what will we be creating? A field type widget for a person's name, the sub-fields of which will be, as follows:

    • Title
    • First name
    • Middle name/initial
    • Last name
    • Maternal last name
    • Suffix

    The field type is constructed as a widget, which is a technical term for thingy, as in something tangible, but in a somewhat intangible sort of way. Yup, a thingy. The widget has the following components:

    • Module files - the files that define the module scaffolding that wraps the widget plugin
    • Field Type - defines the structure of the field type and how to determine if the field using it should be considered empty 
    • Field Widget - defines the structure of the content form field(s) that will accept values for the field, as well as any custom code needed to process the input
    • Field Formatter - formats the field data to pass to the twig file
    • Twig file - the default rendering of fields using the widget

    We will create each of these in this five-part tutorial series. Let's get started!

    the Module Files

    This widget is made available to Drupal as a plugin wrapped in a module. Let's start by creating the files that are typical for a module.

    name_field_type.info.yml

    
    name: 'Name'
    description: 'Provides a bundled name field.' 
    type: module
    core: 8.x
    package: 'Field types'
    dependencies:
      - field
      - node
      - text
    
    

    The info.yml file is required for Drupal to pay attention to the rest of the module's files. The contents of this one are vanilla, other than some enumerated core dependencies.

    name_field_type.module

    
    /**
     * @file
     * Contains name_field_type.module.
     */
    use Drupal\Core\Routing\RouteMatchInterface;
    /**
     * Implements hook_theme().
     */
    function name_field_type_theme($existing, $type, $theme, $path) {
        $theme = [
            'name_field_widget' => [
                'variables' => [
                    'title' => NULL,
                    'first_name' => NULL,
                    'middle_name' => NULL,
                    'last_name' => NULL,
                    'maternal_last_name' => NULL,
                    'suffix' => NULL,
                ],
            ],
        ];
        return $theme;
    }
    /**
     * Implements hook_help().
     */
    function name_field_type_help($route_name, RouteMatchInterface $route_match) {
      switch ($route_name) {
        // Main module help for the name_field_type module.
        case 'help.page.name_field_type':
          $output = '';
          $output .= '<h3>' . t('About') . '</h3>';
          $output .= '<p>' . t('Field type widget example.') . '</p>';
          return $output;
        default:
      }
    }
    
    

    The .module file contains an implementation of hook_theme. This will pave the way for the variables that will be passed to the twig file, which we'll create later.

    That's it for the module files. At this point we could do

    drush en name_field_type

    and enable the module, though of course the module won't do anything yet. In Part 2 we move on to the file that defines the widget field type.

    Part 2

    Pages

    About Drupal Sun

    Drupal Sun is an Evolving Web project. It allows you to:

    • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
    • Facet based on tags, author, or feed
    • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
    • View the entire article text inline, or in the context of the site where it was created

    See the blog post at Evolving Web

    Evolving Web