Newsfeeds

Pagination Page Titles

New Drupal Modules - 6 June 2018 - 6:56pm

This module addresses an SEO issue involving duplicate titles created by Drupal on pages that are derived from pagination. For example /blog?page=1, /blog?page=2 both have the same page title and gets flagged by Google, SEM Rush, etc.

The Pagination Page Titles module adds unique text to page titles on paginated lists to avoid issues with duplicate title tags to perform better in SEO. Titles are updated to have the original title tag with the addition of some text with URI information in it along with the word page and page number.

Categories: Drupal

orkjerns blogg: Creating services with optional dependencies in Drupal 8

Planet Drupal - 6 June 2018 - 1:54pm
Creating services with optional dependencies in Drupal 8 admin Thu, 06/07/2018 - 11:08

Today I encountered a problem I did not think about earlier. After I pushed a fix to a project I am working on, the CI builds started showing errors. And the problem was coming from a message like this:

The service "mymodule.attachments_manager" has a dependency on a non-existent service "metatag.manager".

In many cases when you see that, it probably means your module was installed before a module it depends on. For example, in this case, it would seem that this module depends on metatag, and so declaring it as a dependency would fix the issue. And for sure, it would. But sometimes dependencies are not black and white.

This particular service does some handling of the attachments when used together with metatag. It does so, because it is a module we use across projects, and we can not be sure metatag is used in any given project. So it's only used in a way that is something like this:

/** * Implements hook_page_attachments(). */ function mymodule_page_attachments(array &$attachments) { if (!\Drupal::moduleHandler()->moduleExists('metatag')) { return; } \Drupal::service('mymodule.attachments_manager')->handlePageAttachments($attachments); }

Now, what this means, is that for the attachments manager to be useful, we need metatag. If we do not have metatag, we do not even need this service. So basically, the service depends on metatag (as it uses the service metatag.manager), but the module does not (as it does not even need its own service if metatag is not installed).

Now, there are several ways you could go about fixing this for a given project. Creating a new module that depends on metatag could be one way. But today, let's look at how we can make this service have an optional dependency on another service.

At first the service definition looked like this:

mymodule.attachments_manager: class: Drupal\mymodule\MyModuleAttachmentsManager arguments: ['@current_route_match', '@module_handler', '@metatag.manager', '@entity.repository']

This would contruct a class instance of MyModuleAttachmentsManager with the following function signature:

public function __construct(RouteMatchInterface $route_match, ModuleHandlerInterface $module_handler, MetatagManager $metatag_manager, EntityRepositoryInterface $entity_repo) { }

Now, this could never work if this module was installed before metatag (which it very well could, since it does not depend on it). A solution then would be to make the metatag.manager service optional. Which is something we can do by removing it from the constructor and create a setter for it.

public function __construct(RouteMatchInterface $route_match, ModuleHandlerInterface $module_handler, EntityRepositoryInterface $entity_repo) { // Constructor code. } /** * Set meta tag manager. * * @param \Drupal\metatag\MetatagManager $metatagManager * Meta tag manager. */ public function setMetatagManager(MetatagManager $metatagManager) { $this->metatagManager = $metatagManager; }

OK, so far so good. It can now be constructed without having a MetaTagManager. But how do we communicate this in the service definition? Turns out the documentation for Symfony service container has the answer.

When you define a service, you can specify calls to be made when creating the service, which would be ignored if the service does not exist. Like so:

mymodule.attachments_manager: class: Drupal\mymodule\MyModuleAttachmentsManager arguments: ['@current_route_match', '@module_handler', '@entity.repository'] calls: - [setMetatagManager, ['@?metatag.manager']]

So there we have it! The service can be instantiated without relying on the metatag.manager service. And if it is available in the service container, the method setMetatagManager will be called with the service, and our service will have it available in the cases where we need it.

Now let's finish off with an animated gif related to "service container".

Categories: Drupal

Vardot: Why Choose Drupal 8 to Migrate from your Legacy CMS?

Planet Drupal - 6 June 2018 - 1:21pm
Ahmed Jarrar June 6, 2018

If your business has been around for a while, there’s a fair chance that your site is running on a Legacy CMS. These outdated frameworks were a step above hardcoding (literally writing the entire site using, say, HTML), but don’t do the modern business any favors in the way of swift and cost-effective site design.

The challenge for enterprises still running on a Legacy framework is clear: “Which modern CMS will help us make things easier for ourselves?”

This article will cover what seems to us like the clear contender for the best of today’s CMS solutions --Drupal 8. We’ll cover the ease with which companies can migrate their content to Drupal 8, the thriving community around it, and other reasons why leading companies across various industries trust the platform to power their websites.

 

Top Organizations Run with Drupal 8

 

Drupal 8 is the preferred framework for a significant number of the world’s most influential brands. Pinterest, The Economist, Tesla, Al Jazeera --and countless other industry leaders prefer Drupal 8 for its agility and scalability.

If belonging to a wide group of peers isn’t enough to prove the platform’s reliability, then trust in the fact that the open market is more than happy to throw its weight behind the product-of-choice for its biggest spenders. Thanks to its prominence among elite organizations and businesses, over a million developers have flocked to Drupal --making Drupal-based designs highly accessible for those with a relatively smaller pool of resources.

 

Drupal 8 is Supported by a Thriving Community

 

Thanks to the framework’s prominence among big businesses, migrating to Drupal 8 means gaining access to a wide network of developers and innovators building additions to a single product. As a result, the options available to a business are staggering: e-commerce sites can choose from thousands of templates for their online storefronts, news sites can integrate chatbots, and services can manage volumes of content across multiple channels.

Since its foundation, Vardot has been an active member of this community. We can say with confidence that the platform has been crucial in our mission: to help the world’s most influential companies accomplish their own missions.

 

Drupal 8 Offers Risk-Free Migration

 

A major concern for people and organizations looking to modernize their digital assets is the fear of losing content while switching to a new CMS. The process is supposed to reduce cost and boost convenience --so it’s only natural to worry about having to restructure an entire network of websites or reproduce existing content.

This concern is a thing of the past for Drupal users since the platform was designed for high flexibility. Essentially, it allows users to import vast and complex site architecture from legacy systems, removing the need to play around with a sales funnel that already works for you, or rebuild your site’s blog from scratch.

If anything, making the move might actually increase the performance of your website. It takes the liberty of mapping out your existing URLs and updating them to meet the standards of the best SEO practices --meaning users will have a much easier time discovering your content and, hopefully, develop into sales-ready leads. Likewise, it eliminates redundant modules left over from your initial infrastructure and offers a clean database system right out of the box, meaning your site load times will be faster than ever (great for SEO, and great for generating conversions!)

 

Drupal 8 Offers Easy-to-Use Solutions

 

Legacy CMS platforms often demand much from users looking to update their websites. Since most new tools don’t bother aiming for compatibility with legacy systems, organizations looking to take advantage of AI, voice search, and other top-of-the-line innovations will have to build them up from scratch.

Drupal 8, on the other hand, offers plenty of valuable features right out of the box. These core features allow businesses and organizations of all kinds design powerful and functional websites suited to achieve whatever goals they’ve set. Even better, Drupal is open to 3rd party integrations like Salesforce, chatbots, and tools for both social media and customer support.

Businesses shouldn’t have to fall behind in an age when software is growing exponentially. With all the technology available to grow your sales and revenue, you don’t want to lag behind for a second.

 

Drupal is Perfect for Your Non-Technical Staff

 

We’ve mentioned that Drupal is scalable --meaning it can grow as big as your company needs it to grow in as fast of a time as your company needs. The developers you’ve hired are guaranteed a simple time with it, and so are the people responsible for populating your site: your marketers, writers, and designers.

The best websites are mentally and visually stimulating, which is why people pay so much to keep them looking pretty. Migrating to Drupal 8 allows you to scale back on training hours (no more need for your new hires to learn clunky, outdated systems) and put your I.T. team to more productive use.

 

Case Study - American University of Cairo (AUC)

 

The AUC website was first to build using the iAPPS CMS: a Sharepoint content hub for microsites OpenAm, and other features. The result was a confusing hodgepodge of unnecessary applications that clashed to produce a fractured website. AUC, as you can imagine, didn’t thrive in the digital world under these conditions.

When Vardot helped AUC migrate from Sharepoint to Drupal, the institution felt the changes instantly. Their website had a much stronger impact from that point forward and stopped being a headache for the university’s administrators to update. In short, migrating to Drupal helped AUC run a much better website.

 

Conclusion

Drupal 8 is, by all accounts, vastly superior to legacy CMS platforms. It’s arguably superior to CMS platforms that came much later --and the thriving community behind it is unlikely to stop broadening the limits of what the framework is capable of any time soon.

For a good investment in your organization’s future, make the move away from your legacy system and switch to Drupal. You’ll find it highly secure, cost-effective, and easy to set up.

Categories: Drupal

Carpe Omnis Games Announces No Honor Among Thieves Card Game

Tabletop Gaming News - 6 June 2018 - 1:00pm
What’s mine is mine and what’s yours is mine. That’s the code of the thieves. If anything’s able to be taken, it should be. Sure, they might band together in order to get into someplace none could, individually, but at the end of the day, he who gets away with the most loot is the […]
Categories: Game Theory & Design

Field Pager

New Drupal Modules - 6 June 2018 - 12:37pm

A pagination system for the element of multiple values fields.

Categories: Drupal

Valve: We shouldn't be choosing what you're allowed to create or play

Social/Online Games - Gamasutra - 6 June 2018 - 12:33pm

In a post shared to the Steam Blog today, Valve details why its official stance is to offer devs systems and tools while leaving the content-policing to players and devs. ...

Categories: Game Theory & Design

Fantasy Flight Games Previews Podracing in Star Wars: Destiny

Tabletop Gaming News - 6 June 2018 - 12:00pm
“Objection, your honor! The podrace was pretty cool.” Generally the only thing that most people can agree on that was cool in the Prequel trilogy for Star Wars, Podracing (that seems to have about a 50% mortality rate per race, which makes you wonder how there’s ever enough racers to hold an event, but that’s […]
Categories: Game Theory & Design

Community: Looking back at the first-ever DrupalCon Teamwork and Leadership Workshop

Planet Drupal - 6 June 2018 - 11:59am

The Drupal Community Working Group (CWG), with support from the Drupal Association, organized and held the first-ever Teamwork and Leadership Workshop at DrupalCon Nashville on April 10, 2018. The goal of the three-hour workshop was to explore teamwork, leadership, and followership in the context of the Drupal community as well as to help provide support and resources for people in the Drupal community who work alongside others in teams and/or may find themselves in positions of responsibility or leadership. Additionally, we hoped to expand the base of people who can step into leadership positions in the Drupal community, and to help those who may already be in those positions be more effective.

The workshop was led by Drupal Association board chair Adam Goodman, who generously donated his time. Adam is the head of Northwestern University’s Center for Leadership, and he works as an executive coach and advisor to senior executives and boards of directors at dozens of companies and organizations around the world. 

As part of the planning for the workshop, Adam asked us to enlist a number of facilitators to help with the various workshop exercises. In addition to three CWG members (Jordana Fung, George Demet, and Mike Anello), the following community members also facilitated: Donna Benjamin, Shyamala Rajaram, Gábor Hojtsy, Angie Byron, and Tiffany Farriss. The facilitators met with Adam prior to the workshop to understand what would be expected of them. 

We wanted to make sure that we invited a diverse range of people to the workshop who are doing awesome work with Drupal around the world, including those whose efforts may not be as well-known or recognized (yet).  We set an internal goal of at least 50% of attendees to be from populations historically underrepresented at DrupalCon, including those who self-identify as women, non-gender binary, people of color, and/or people who are not from Europe, the United States, or Canada.. To this end, prior to the public registration period, we sent out invitations to 64 community members, 75% of whom were from an under-represented cohort. We invited people who are involved in all aspects of the community including (but not limited to) event organizers, sprint organizers, project maintainers, as well as past and current Aaron Winborn Award nominees. At the workshop, there were a total of 50 attendees (there were a total of 60 seats available), with approximately 64% from underrepresented cohorts. 

Attendees were seated at round tables of approximately 10 people per table. The first half of the workshop was focused on large group exercises that focused on helping attendees think about what it meant to be a leader and a team member. We talked about keeping perspective as team members and not jumping to conclusions about each other's behaviors based on an often (extremely) limited set of data. The second half of the workshop focused on smaller group exercises in which individuals responded to various prompts and then discussed them as a small (table-sized) group. 

A few days after the workshop, we asked the attendees to complete an 11-question follow-up survey. Of the 50 attendees, we had 17 responses for a 33% response rate. We asked what their expectations were for the workshop; representative responses included:

I thought it would be a workshop on leadership, but I was surprised by the approach to the Drupal community.

Didn't know what to expect. So...none

The fact that we had multiple responses indicating that the expectations were not clear tells us that we need to do a better job in communicating exactly what the goals and activities of the workshop will be in the future. 

On a scale of 1-5, 73% of respondents indicated that the workshop met their expectations (via a rating of 4 or 5). 

We also asked respondents to share an insight from the workshop. Responses included:

Transition planning for responsibilities you take on and having a plan in place before even taking on the responsibility.

The need to know why each person on the team is present (their motivation) and the importance of unified movement toward a goal.

I hadn't written out what leadership looked like to me before, so I found that part of the exercise to be quite helpful.

The survey also found that the attendees found more value in the smaller group exercises than the large group exercises (81.3% vs. 60%), with 81.3% indicated they'd be interested in attending future similar workshops.

Many of the open ended responses indicated that some attendees were hoping for more practical, hands-on advice for specific situations. In addition, several of the responses felt that parts of the exercises felt rushed, and wished there was more time. Finally, several attendees commented on the appropriateness of some of the imagery used in one of the workshop exercises, for which the CWG made a public apology following the event. We have gone through all of the comments relating to aspects of the event that were considered negative or unhelpful and will take this into consideration on how we can improve the workshop for the future.

Overall, we feel the workshop was a success, and something that has been long overdue for the Drupal community. We've been discussing how we can make similar content available to everyone in the community, not just DrupalCon attendees. We're open to ideas for future workshops on these topics (and format), let us know if you have any ideas.
 

Categories: Drupal

Midweek Snippets

Tabletop Gaming News - 6 June 2018 - 11:00am
This “it’s a regular week again” continues along. Actually, so far, it doesn’t feel as long as last week felt. Granted, I’ve found Wednesday tends to be the long day out of the bunch, so we’ll see how this one continues along. But if we’re going to make the long slog back to the weekend, […]
Categories: Game Theory & Design

The Board Game Book Up On Kickstarter

Tabletop Gaming News - 6 June 2018 - 10:00am
Confession: I prefer non-fiction to fiction, especially when it comes to reading. I would much rather read a history book than a story. So some novel series that’s catching everyone’s attention never catches mine. However, when I see something that’s an analysis of board games of the recent year, I’m like, “Oooh, that’s something I’d […]
Categories: Game Theory & Design

Drupal blog: Virtual reality on campus with Drupal

Planet Drupal - 6 June 2018 - 9:16am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

One of the most stressful experiences for students is the process of choosing the right university. Researching various colleges and universities can be overwhelming, especially when students don't have the luxury of visiting different campuses in person.

At Acquia Labs, we wanted to remove some of the complexity and stress from this process, by making campus tours more accessible through virtual reality. During my presentation at Acquia Engage Europe yesterday, I shared how organizations can use virtual reality to build cross-channel experiences. People that attended Acquia Engage Europe asked if they could have a copy of my video, so I decided to share it on my blog.

The demo video below features a high school student, Jordan, who is interested in learning more about Massachusetts State University (a fictional university). From the comfort of his couch, Jordan is able to take a virtual tour directly from the university's website. After placing his phone in a VR headset, Jordan can move around the university campus, explore buildings, and view program resources, videos, and pictures within the context of his tour.

All of the content and media featured in the VR tour is stored in the Massachusetts State University's Drupal site. Site administrators can upload media and position hotspots directly from within Drupal backend. The React frontend pulls in information from Drupal using JSON API. In the video below, Chris Hamper (Acquia) further explains how the decoupled React VR application takes advantage of new functionality available in Drupal 8.

It's exciting to see how Drupal's power and flexibility can be used beyond traditional web pages. If you are interesting in working with Acquia on virtual reality applications, don't hesitate to contact the Acquia Labs team.

Special thanks to Chris Hamper for building the virtual reality application, and thank you to Ash Heath, Preston So and Drew Robertson for producing the demo videos.

Categories: Drupal

CMON Posts New Cthulhu: Death May Die Preview

Tabletop Gaming News - 6 June 2018 - 9:00am
In Cthulhu: Death May Die, the cultists are winning. They have started their ritual. The Old Ones are waking up. The Earth will surely plunge into chaos and disorder… or will it? Yes, it might be too late to fully stop the ceremony, but that doesn’t mean all hope is lost. It’s just, like, 99% […]
Categories: Game Theory & Design

oil.js

New Drupal Modules - 6 June 2018 - 8:46am

tbd;

Categories: Drupal

Drupal Association blog: Email news after GDPR

Planet Drupal - 6 June 2018 - 8:09am

GDPR took effect last month, and many organizations sent policy updates to your inbox. We took action on our email lists to acquire explicit consent from all subscribers. You can read about other action we took to prepare for GDPR, but this post is all about what we communicate about through the Drupal email list.

The Drupal email list had almost 64,000 subscribers receiving various newsletters from our programs, and we knew running a re-consent campaign would have an impact on the number of subscribers in each of our newsletter groups. It seemed worth the potential loss, because numbers don't always tell the full story of the impact communications can, and do, make for an organization.

There were two problems with our list that kept us from delivering tailored messages with the Drupal community: old or insufficient data on subscribers and limited newsletter options. To make the list more effective, we changed the structure of our subscriptions to focus on the type of message we're sending, rather than being aligned with Drupal Association programs.

By using Mailchimp's GDPR tools and suggestions to run a re-consent campaign, we asked for explicit consent to this new subscription structure. We enabled the Marketing Preferences section provided by Mailchimp, and now in order to get email, you must select Email within that section of the form. This has been confusing for some people. Here is an easy way to look at it: The top section, where you choose your lists, is simply choosing the topics that interest you; the bottom section, where you click “email” in marketing preferences gives us explicit permission to email you about these topics.

The impact of running the re-consent campaign has been a loss of a vast majority of our list. Is this a problem? It depends. Ideally, only people who want to read our news are now subscribed and we will see an increase in open rates. And hopefully community members won’t be hearing about updates or announcements from other sources, rather than from our newsletters first - if you do, please let us know.

Please take a moment and check that your subscription settings are how you want them. If you want to receive news, check the Email box under Marketing Preferences. (Enter your email address in this form and you'll get a message to update your subscription)

If you are in any way interested in Drupal, you don't want to miss our messages. In particular, Bob Kepford (kepford) does a fantastic job of curating content for the Drupal Weekly Newsletter. There's something for everyone, every Thursday. Likewise, the special offers messages from our partners can help you learn about and save money on services. Thanks for keeping informed!

There are some communications which are not impacted by our subscription structure change. These include security notifications, blog post notifications, Drupal.org system messages, and any transactional messages - for instance, if you register to attend DrupalCon, we will still email you about DrupalCon.

Categories: Drupal

Plaid Hat Games Posts New Ashes Preview

Tabletop Gaming News - 6 June 2018 - 8:00am
Two new decks are soon to be hitting shelves for Ashes: Rise of the Phoenixborn. What new options will be made available? What new characters can you play? In this preview, we get a small taste of both of those. Harold Westraven is the Phoenixborn in Darmas, and it’s his deck and play style that […]
Categories: Game Theory & Design

Lullabot: Will JavaScript Eat the Monolithic CMS?

Planet Drupal - 6 June 2018 - 7:59am

We’ve all been hearing a lot about JavaScript eating the web, but what does that mean for traditional content management systems like Drupal and Wordpress? In many ways, it’s a fatuous claim to say that any particular language is “winning” or “eating” anything, but if a different approach to building websites becomes popular, it could affect the market share of traditional CMS platforms. This is an important topic for my company, Lullabot, as we do enterprise software projects using both Drupal, a popular CMS, and React, a popular JavaScript framework.

At our team retreat, one of Lullabot’s front-end devs, John Hannah, who publishes the JavaScriptReport, referred to Drupal as a “legacy CMS.” I was struck by that. He said that, many in the JavaScript community, PHP CMSes like Drupal, WordPress and Joomla are seen this way. What does he mean? If these “monolithic” CMS platforms are legacy, what’s going to replace them? Furthermore, PHP, the language, powers 83% of total websites and plays a large part in platforms like Facebook. That’s not going to change quickly.

Still, JavaScript’s surging popularity is undeniable. In part, this is due to its ubiquity. It’s a law-of-increasing-returns, chicken-and-the-egg, kind of thing, but it’s real. JavaScript is the only programming language that literally runs everywhere. Every web browser on every device has similar support for JavaScript. Most cloud providers support JavaScript’s server-side incarnation Node.js, and its reach extends far beyond the browser into the internet of things, drones and robots. Node.js means JavaScript can be used for jobs that used to be the sole province of server-side languages. And isomorphism means it can beat the server-side languages at their own game. Unlike server-side applications written in PHP (or Ruby or Java), an isomorphic application is one whose code (in this case, JavaScript) can run on both the server and the client. By taking advantage of the computing power available from the user’s browser, an isomorphic application might make an initial HTTP request to the Node.js server, but from there asynchronously load resources for the rest of the site. On any subsequent request, the browser can respond to the user without having the server render any HTML, which offers a more responsive user experience. JavaScript also evolved in tandem with the DOM, so while any scripting language can be used to access nodes and objects that comprise the structure of a web page, JavaScript is the DOM’s native tongue.

Furthermore, the allure of one-stack-to-rule-them-all may attract enterprises interested in consolidating their IT infrastructure. As Hannah told me, “An organization can concentrate on just supporting, training and hiring JavaScript developers. Then, that team can do a lot of different projects for you. The same people who build the web applications can turn around and build your mobile apps, using a tool like React Native. For a large organization, that’s a huge advantage.”

Node.js Takes a Bite Out of the Back-end

Tempted to consolidate to a single stack, one of Lullabot’s largest digital publishing clients, a TV network, has begun to phase out Drupal in favor of microservices written in Node.js. They still need Drupal to maintain metadata and collections, but they’re talking about moving all of their DRM (digital rights management) content to a new microservice. This also provoked my curiosity. Is the rapidly changing Node.js ecosystem ready for the enterprise? Who is guaranteeing your stack stays secure? The Node foundation? Each maintainer? Drupal has a seasoned and dedicated security team that keeps core and contrib safe. Node.js is changing fast, and the small applications written in Node.js are changing faster than that. This is a rate of change typically anathema to enterprise software. And it’s a significant shift for the enterprise in other ways, as well. While Drupal sites are built with many small modules that together create a unique application, they all live within one set of code. The Node.js community approaches the same problem by building small applications that communicate with each other over a network (known as microservices). The preferred approach of most within the Node.js community is to build applications using a microservices architecture. Does that work in the context of a major enterprise publisher? Is it maintainable? AirBnB, Paypal and Netflix have proven that it can be, but for many of our clients in the digital publishing industry, I wonder how its use within these technology companies pertains. Arguably, Amazon pioneered the modern decouple-all-the-things, service-oriented architecture, and, well, you, dear client, are not Amazon.

In this article, I’ll explore this question through examples and examine how JS technologies are changing the traditional CMS stack architecture within some of the client organizations we work with. I should disclose my own limitations as I tackle an ambitious topic. I’ve approached this exploration as a journalist and a business person, not as an engineer. I’ve tried to interview many sources and reflect the nuances of the technical distinctions they’ve made, but I do so as a technical layperson, so any inaccuracies are my own.

The Cathedral and the Bazaar

How is the JavaScript approach different than that of a CMS like Drupal? In the blogosphere, this emerging competition for the heart of the web is sometimes referred to as “monolith vs. microservice.” In many ways, it’s less a competition between languages, such as JavaScript and PHP (or Ruby or Python or Java), but more the latest chapter in the dialectic between small, encapsulated programs with abstracted APIs as compared to comprehensive, monolithic systems that try to be all things to all people.

The JavaScript microservices approach—composing a project out of npm packages—and the comparatively staid monolithic approach taken by Drupal are both descendants of open source collaboration, aka the “bazaar,” but the way things are being done in Node.js right now, as opposed to the more mature and orderly approach of the Drupal community, make Node.js the apparent successor of the bazaar. Whereas Drupal—with 411,473 lines of code in the current version of core—has cleaned up its tents and begun to look more like a cathedral, with core commits restricted to an elite priesthood.

Drupal still benefits from a thriving open-source community. According to Drupal.org, Drupal has more than 111,000 users actively contributing. Meaning, in perhaps the most essential way, it is still benefiting from Linux founder Linus Torvald’s law, “Given enough eyes, all bugs are shallow.” Moreover, the Drupal community remains the envy of free software movement, according to Google’s Steve Francia, who also guided the Docker and MongoDB communities following Drupal’s lead.

Nevertheless, JavaScript and its server-side incarnation are gaining market share for a reason. JavaScript is both accessible and approachable. Lullabot senior developer Mateu Aguiló Bosch, one of the authors of Contenta CMS, a decoupled Drupal distribution, describes the JavaScript ecosystem, as follows: “there’s an open-script vibe in the community with snippets of code available everywhere. Anyone, anywhere, can experiment with these snippets using the built-in console in their browser.” Also, Bosch continues, “Node.js brings you closer to the HTTP layer. Many languages like PHP and Ruby abstract a lot of what’s going on at that layer, so it wasn’t until I worked with Node.js that I fully understood all of the intricacies of the HTTP protocol.”

Furthermore, thanks to the transpiler Babel, JavaScript allows developers to program according to their style. For instance, a developer familiar with a more traditional nomenclature for object-oriented classes can use TypeScript and then transpile their way to working JavaScript that’s compatible with current browsers. “Proposals for PHP have to go through a rigorous process, then go to binary, then the server has to upgrade, and then apps for Drupal have to support this new version,” says Sally Young, a Lullabot who heads the Drupal JavaScript Modernization Initiative. “With transpiling in JS, we can try out experimental language features right away, making it more exciting to work in.” (There is precedence for this in the PHP community, but it’s never become a standard workflow.)

However, JavaScript’s popularity is attributable to more than just the delight it inspires among developers.

Concurrency and non-blocking IO

I spoke with some of our clients who are gradually increasing the amount of JS in their stack and reducing the role of Drupal about why they’ve chosen to do so. (I only found one who is seeking to eliminate it all together, and they haven’t been able to do so yet.) Surprisingly, it had nothing to do with Hannah’s observation that hiring developers for and maintaining a single stack would pay dividends in a large organization. This was a secondary benefit, not a primary motivation. The short answer in each case was speed, in one case speed in the request-response sense, and in the other, speed in the go-to-market sense.

Let’s look at the first example. We work with a large entertainment media company that provides digital services for a major sports league. Their primary site and responsive mobile experience are driven by Drupal 8’s presentation layer (though there’s also the usual caching and CDN magic to make it fast). Beyond the website, this publisher needs to feed data to 17 different app experiences including things like iOS, tvOS, various Android devices, Chromecast, Roku, Samsung TV, etc. Using a homegrown system (JSON API module wasn’t finished when this site was migrated to D8), this client pushes all of their content into an Elasticsearch datastore where it is indexed and available for the downstream app consumers. They built a Node.js-based API to provide the middleware between these consumers and Elasticsearch. According to a stakeholder, the group achieved “single-digit millisecond responses to any API call, making it the easiest thing in the whole stack to scale.”

This is likely in part due to one of the chief virtues of Node.js. According to Node’s about page:

As an asynchronous event-driven JavaScript runtime, Node is designed to build scalable network applications…many connections can be handled concurrently. Upon each connection, a callback is fired, but if there is no work to be done, Node will sleep. This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use.

Multiple core CPUs can handle multiple threads in direct proportion to the number of CPU cores. The OS manages these threads and can switch between them as it sees fit. Whereas PHP moves through a set of instructions top to bottom with a single pointer for where it’s at in those instructions, Node.js uses a more complex program counter that allows it to have multiple counters at a time. To roughly characterize this difference between the Node.js asynchronous event loop and the approach taken by other languages, let me offer a metaphor. Pretend for a moment that threads are cooks in the kitchen awaiting instructions. Our PHP chef needs to proceed through the recipe a step at a time: chopping vegetables, and then boiling water, and then putting on a frying pan to sauté those veggies. While the water is boiling, our PHP chef waits, or the OS makes a decision and moves on to something else. Our Node.js chef, on the other hand, can handle multi-tasking to a degree, starting the water to boil, leaving a pointer there, and then moving on to the next thing.

However, Node.js can only do this for input and output, like reading a database or fetching data over HTTP. This is what is referred to as “non-blocking IO.” And, it’s why the Node.js community can say things like, “projects that need big concurrency will choose Node (and put up with its warts) because it’s the best way to get their project done.” Asynchronous, event-driven programs are tricky. The problem is that parallelism is a hard problem in computer science and it can have unexpected results. Imagine our cook accidentally putting the onion on the stove to fry before the pan is there or the burner is lit. This is akin to trying to read the results from a database before those results are available. Other languages can do this too, but Node’s real innovation is in taking one of the easier to solve problems of concurrent programming (IO), designing it directly into the system so it’s easier to use by default, and marketing those benefits to developers who may not have been familiar with similar solutions in more heavyweight languages like Java.

Even though Node.js does well as a listener for web requests, the non-blocking IO bogs down if you’re performing CPU intensive computation. You wouldn’t use Node.js “to build a Fibonacci computation server in Node.js. In general, any CPU intensive operation annuls all the throughput benefits Node offers with its event-driven, non-blocking I/O model because any incoming requests will be blocked while the thread is occupied with your number-crunching,” writes Tomislav Capan in “Why the Hell Would You Use Node.js.” And Node.js is inherently single-threaded. If you run a Node.js application on a CPU with 8 cores, Node.js would just use one, whereas other server-side languages could make use of all of them. So Node.js is designed for lots of little concurrent tasks, like real-time updates to requests or user interactions, but bad at computationally intensive ones. As one might expect, given that, it’s not great for image processing, for instance. But it’s great for making seemingly real-time, responsive user interfaces.

JavaScript Eats the Presentation Layer

There’s an allure to building a front-end with just HTML, CSS, and JavaScript since those three elements are required anyway. In fact, one of our largest clients started moving to a microservices architecture somewhat by accident. They had a very tight front-end deadline for a new experience for one of their key shows. Given the timeline, the team decided to build a front-end experience with HTML, CSS, and JavaScript and then feed the data in via API from Drupal. They saw advantages in breaking away from the tricky business of Drupal releases, which can include downtime as various update hooks run. Creating an early decoupled (sometimes referred to as “headless”) Drupal site led them to appreciate Node.js and the power of isomorphism. As the Node.js documentation explains, “after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication.”

After hacking together that first site, they found React and began to take full advantage of stateful components that provide real-time, interactive UX, like AJAX but better. Data refreshes instantly, and that refresh can be caused by a user’s actions on the front-end or initiated by the server. To hear this client tell it, discovering these technologies and the virtues of Node.js led them to change the role of Drupal. “With Drupal, we were fighting scale in terms of usage, and that led us to commit to a new, microservices-oriented stack with Drupal playing a more limited role in a much larger data pipeline that utilizes a number of smaller networked programs.” These included a NoSQL data-as-a-service provider called MarkLogic, and a search service called Algolia, among others.

So what started as the need for speed-to-market caused this particular client to discover the virtues of Node.js, and then, subsequently React. Not only can libraries like React provide more app-like experiences in a browser, but tools like React Native can be used to make native apps for iOS and Android. PWAs (progressive web apps) use JavaScript to make web applications behave in certain respects like native applications when they’re opened on a mobile device or in a standard web browser. If there was ever a battle to be won in making the web more app-like, JavaScript won that contest a long time ago in the days of jQuery and Ajax. Heck, it won that battle when we all needed to learn JavaScript in the late 90s to swap navigation images using onMouseOver.

Is JavaScript taking over the presentation layer? Only for some. If you’re a small to medium-sized business, you should probably use the presentation layer provided by your CMS. If you’re a large enterprise, it depends on your use case. A good reason to decouple might be to make your APIs a first-class citizen because you have so many downstream consumers that you need to force yourself to think about your CMS as part of a data pipeline and not as a website. Moreover, if shaving milliseconds off “time to first interactive” means earning millions of dollars in mobile conversions that might otherwise have been lost, you may want to consider a JS framework or something like AMP to maximize control of your markup. Google has even built a calculator to estimate the financial impact of better load times based on the value of a conversion.

That said, there are some real disadvantages in moving away from Drupal’s presentation layer. (Not to mention it’s possible to make extensive use of JavaScript-driven interactivity within a Drupal theme.) By decoupling Drupal, you lose many of Drupal’s out-of-the-box solutions to hard problems such as request-response handling (an essential component of performance), routing, administrative layout tools, authentication, image styles and a preview system. Furthermore, you now have to write schemas for all of your APIs to document them to consumers, and you need to grapple with how to capture presentational semantics like visual hierarchy in textual data.

As Acquia CTO Dries Buytaert wrote in The Future of Decoupled Drupal,

Before decoupling, you need to ask yourself if you're ready to do without functionality usually provided for free by the CMS, such as layout and display management, content previews, user interface (UI) localization, form display, accessibility, authentication, crucial security features such as XSS (cross-site scripting) and CSRF (cross-site request forgery) protection, and last but not least, performance. Many of these have to be rewritten from scratch, or can't be implemented at all, on the client-side. For many projects, building a decoupled application or site on top of a CMS will result in a crippling loss of critical functionality or skyrocketing costs to rebuild missing features.

These things all have to be reinvented in a decoupled site. This is prohibitively expensive for small to medium-sized businesses, but for large enterprises with the resources and a predilection for lean, specific architectures, it’s a reasonable trade-off to harness the power of something like the React library fully.

JavaScript frameworks will continue to grow as consumers demand more app-like experiences on the web and that probably means the percentage of websites directly using a CMS’s presentation layer will shrink over time, but this is going to be a long-tail journey.

JavaScript Eats the Admin Interface

PHP CMSes have a decade lead in producing robust editorial experiences for managing content with a refined GUI. Both WordPress and Drupal have invested thousands of hours in user testing and refinement of their respective user interfaces. Well, wait, you say, aren’t both Drupal and WordPress trying to replace their editorial interfaces with decoupled JavaScript applications to achieve a more app-like experience? Well, yes. Moreover, Gutenberg, the new admin interface in WordPress built on React, is an astonishing evolution for the content authorship experience, a consummation devoutly to be wished. Typically, editors generate content in a third-party application before moving it over to and managing it in a CMS. Gutenberg attempts to create an authorship experience to rival that of Desktop applications typically used for this purpose. At Word Camp 2015, Matt Mullenweg issued a koan-like edict to the WordPress community “learn JavaScript, deeply.” He was preparing the way for Gutenberg.

Meanwhile, on Drupal island, the admin-ui-js team is at work building a decoupled admin interface for Drupal with React, code-named the JavaScript Modernization Initiative. In that sense, JavaScript is influencing the CMS world by beginning to eat the admin interface for two major PHP CMSes. As of this writing, neither interface was part of the current core release.

JavaScript Replaces the Monolithic CMS?

Okay, great, developers love JavaScript, JavaScript devs are easier to hire (perhaps), Node.js can handle concurrency in a more straightforward fashion than some other languages, isomorphic decoupled front-ends can be fast and provide interactivity, and the Drupal and Wordpress admin UIs are being rewritten in React, a JavaScript library, in order to make them more app like. But our original question was whether JavaScript might eventually eat the Monolithic CMS. Looking at the evidence I’ve produced so far, I think you’d have to argue that this process has begun. Perhaps a better question is what do we, the Drupal community, do about it?

A sophisticated front-end such as a single-page application, a PWA, or a React application, let’s say, still needs a data source to feed it content. And while it’s possible to make use of different services to furnish this data pipeline, editors still need a place to edit content, govern content, and manage meta-data and the relationship between different pieces of content; it’s a task to which the PHP monolithic CMS platforms are uniquely suited.

While some JavaScript CMSes have cropped up—Contentful (an API-first CMS-as-a-service platform), CosmicJS, Prismic, and ApostropheCMS— they don’t have near the feature-set or flexibility of a Drupal when it comes to managing content. As head of Drupal’s JavaScript initiative, Sally Young says, “the new JS CMSes do less than Drupal tries to do, which isn’t necessarily a bad thing, but I still think Drupal’s Field API is the best content modeling tool of any CMS by far.” And it’s more than the fact that these CMSes try to do less, it’s also an issue of maturity.

“I’m not convinced from my explorations of the JS ecosystem that NPM packages and Node.js are mature enough to build something to compete with Drupal,” says senior architect Andrew Berry. “Drupal is still relevant because it’s predicated on libraries that have 5-10 years of development, whereas in the Node world everything is thrown out every 6 months. In Drupal, we can’t always get clients to do major releases, can you imagine if we had to throw it out or change it every 6 months?” This was echoed by other experts that I spoke with.

Conclusion

The monolithic web platforms can’t rest on their laurels and continue to try to be everything to everyone. To adapt, traditional PHP CMSes are going to require strong and sensible leadership that find the best places for each of these tools to shine in conjunction with a stack that includes ever-increasing roles for JavaScript. Drupal, in particular, given its enterprise bent, should embrace its strengths as a content modeling tool in an API-first world—a world where the presentation layer is a separate concern. As Drupal’s API-First initiative lead, Bosch said at Drupalcon Nashville, “we must get into the mindset that we are truly API-first and not just API compatible.” Directing the formidable energy of the community toward this end will help us remain relevant as these changes transpire.

To get involved with the admin-ui-js initiative, start here.

To get involved with the API-first initiative, start here.

Special thanks to Lullabots Andrew Berry, Ben Chavet, John Hannah, Mateu Aguiló Bosch, Mike Herchel, and Sally Young for helping me take on a topic that was beyond my technical comfort zone.

Categories: Drupal

Blair Wadman: How do you add a class to a Twig template in Drupal 8?

Planet Drupal - 6 June 2018 - 7:54am

Adding CSS classes to templates allows you to target templates or parts of the template in your CSS files.

Categories: Drupal

TEN7 Blog's Drupal Posts: Animal Humane Society Dog Habitat Kiosk

Planet Drupal - 6 June 2018 - 7:40am

The Animal Humane Society (AHS), in Minneapolis, Minnesota is the leading animal welfare organization in the Upper Midwest, helping 25,000 dogs, cats and critters in need find loving homes each year, while providing a vast array of services to the community, from low-cost spay and neuter services to dog training and rescuing animals from neglectful and abusive situations.

Categories: Drupal

WizKids Announces Seal Team Flix

Tabletop Gaming News - 6 June 2018 - 7:00am
While Gaia’s Hope might seem like just a bunch of tree-hugging hippies, they’re really an eco-terrorist organization looking to solve things their way. They’ve gotta be dealt with, and the SEALS are just the team to do it. But the operations aren’t going to be easy. SEAL Team Flix is a new dexterity-based cooperative game […]
Categories: Game Theory & Design

Image Background Formatter

New Drupal Modules - 6 June 2018 - 6:58am

This module adds new formatter for image field, print div with the image background.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator