May 22 2019
May 22

Your browser does not support the audio element. TEN7-Podcast-Ep-060-Drupaldelphia-2019.mp3

In this week’s podcast TEN7’s DevOps Tess Flynn aka @socketwench is our guest, giving us her observations of the Drupaldelphia 2019 conference she recently attended, as well as a summary of her helpful session, “Return of the Clustering: Kubernetes for Drupal.”

Host: Ivan Stegic
Guest: Tess Flynn, TEN7 DevOps

In this podcast we'll discuss: 

  • What it takes to get a good Jedi costume
  • Tess’s Trilogy of Talks
  • Summary of Tess’s Kubernetes session
  • How camps are not just about Drupal and not just about developers anymore
  • Short camps = no keynote
  • Help desks at the conference - what a great idea!

Links:

TRANSCRIPT

IVAN STEGIC: Hey everyone you're listening to the TEN7 Podcast, where we get together every fortnight and sometimes more often, to talk about technology, business and the humans in it. I'm your host Ivan Stegic. Let’s talk about the Drupaldelphia 2019 conference that happened recently in Philadelphia. And, joining me to give her thoughts on the camp is Tess Flynn, a seasoned guest here on the TEN7 Podcast. @socketwench welcome back to the podcast.

TESS FLYNN: Hello.

IVAN: I’m going to have to make you the guest host when I’m out of town. [laughing]

TESS: [laughing] Sure, why not. We could do one on terrible movies. [laughing]

IVAN: [laughing] That would be actually awesome. We should totally do that. All right, Drupaldelphia. What’s in a name? So, this is the annual Drupal Camp in Philadelphia, Pennsylvania, and this year it was part of something called Philly Tech Week 2019. And you Tess, were there representing TEN7. What do you know about the relationship between Philly Tech Week and Drupaldelphia?

TESS: Not much, actually. I was so focused on other things during the week, I didn’t have any time to really investigate it deeply. But I noticed that some of the other attendees didn’t know that either, [laughing] so at least I was in good company.

IVAN: Okay. And were there any signs around that referred to Philly Tech Week, or was it kind of just insular?

TESS: No, not that I noticed. I think that it was just part of the longer weeklong event. Like, some organizations will have this kind of co-boosting agreement, where we’ll talk about your event and then you’ll talk about our event, and it’s good for both of us, and we don’t have any other commonality. And there’s nothing wrong with that. That’s good. 

IVAN: That is good. Have you been to Drupaldelphia before?

TESS: I have not. This is my first time. It just showed up across my board, and I went, Huh, I haven’t done that one before, sure, why not?

IVAN: And we have a great talk that you have produced, and so, as a company, we’re making sure you get out and tell that to as many people as possible. So, it was a good opportunity, I think.

TESS: It’s the first talk that I’ve been giving in costume, which is hilarious.

IVAN: Right, I heard about this, and you talk about it in the session, in the recording. So, tell us about the costume.

TESS: So, the thing is that, when you’re doing air travel, it’s always best to only have carry-on luggage, because you never know if you’re going to have a delay, or if your flight is going to get lost, or if your luggage is going to get lost, or something. So, you should restrict yourself to a roll-aboard and a backpack. Now, I’m an old hat toward business travel, so, I’m used to the standard, roll-aboard-backpack modality, but it does limit what you could bring with you when you’re traveling. So, the main concern for coming up with an outfit is: how can I do this so that I minimize the amount of potential luggage space that I take up, while still being evocative of the thing that I’m trying to riff on. And after thinking about this for a while, I actually did come up with something that was rather clever. The easiest thing to do was first find a plastic lightsaber. Not an electronic lightsaber, not one that lights up, not anything else.

The recommendation is that it has to be a lightsaber that’s made of plastic, that fully collapses into the hilt, and has no other electronics. Why is this important? Because air travel. Because we don’t want to have to pull the lightsaber out and put it on the scan deck for everyone else to look at. When it’s just plastic, it’s just plastic, no one cares about it, just put it in the bag and no one cares. Fortunately for me, I found one that was The Last Jedi  branded, but it’s actually a model of Luke Skywalker's lightsaber, that was fully plastic, no electronics, completely collapses into the hilt, on Amazon for 10 bucks.

IVAN: Nice.

TESS: And that was really as far as I was going to take it, because having a prop in the talk isn’t necessarily the worst thing. But then I started getting a little bit ahead of myself and I go, Well, what else can I do? And it occurred to me that one thing that I could do was, I should probably do up the outfit a little bit more. And, one of the things I decided I could do to do up the outfit a little bit more is, what is one thing that a lot of Jedi have going for them? And so, I thought back to all of those hours that I spent watching all of those movies, and all of the comics I read, and everything else, and go, They have this thing for cloaks. That’s it! They have this thing for cloaks and robe-like things. Well, I can’t really do a robe-like thing, because that would require a lot more layers in order to do everything. However, the problem is that, in order to really be evocative, I still need the exterior robe. So, I went again to Amazon, and I found a $20 brown cloak with a hood that looked pretty darn close to what a Jedi would normally wear [laughing], and that’s all I got.

And, so, I am out on stage wearing my normal talk outfit, the infamous skull dress, and wearing this huge brown cloak and carrying a plastic lightsaber. And, I actually stand in front of the room I’m giving the talk in before it starts, ushering people in, acting like a complete fool. Like, everyone going like, What am I getting into here? Why is this person in costume? And I’ll show up to the camp in costume for the entire camp [laughing] because it’s fun and it’s different and it’s weird, and one thing that is really kind of useful is, this is meant to be a fun thing. It’s meant to add more flavor to the talk, and the talk is full of my style of corny jokes. So there’s nothing wrong with me also amping up the corny the entire time. This whole thing about me amping up the corny, actually started in, I think 2015, in DrupalCon where I showed up with a giant inflatable whale, and I literally carried that around with me until the talk started and then I gave it away within the first few minutes. [laughing]

IVAN: I love how involved you get in your talks and how personal your slides are, and the comics that are hand drawn and the characters that you have, they just really make it a joy to listen to you speak. And, I wondered, because I haven’t actually seen you give this talk yet, I will absolutely be going to it at TC Drupal Camp when you give it, and in my mind I wasn’t sure if it was a black cloak or a brown cloak, but I was pretty sure you went with brown, so I’m glad to hear you went with brown. I guess the question I have is, did you have a hoodie?

TESS: I didn’t have a hoodie, but the cloak has a hood on it. So, when I’m outside the room ushering people in, I will put the hood up and start waving the lightsaber around, and usually that’s enough to let people get the idea of what I’m doing. [laughing]

IVAN: That’s really great. Ok, so let’s actually stay on this track. We’ll get to the details of Drupaldelphia in a sec here, but since we’ve already started talking about your session, let’s keep going. So, your session is called "Return of the Clustering, Kubernetes for Drupal", and it’s part of a trilogy, and I’m going to say I think first of all it’s amazing that it’s part of a trilogy. So I’d like you to kind of just tell us what Episode 1 and Episode 2 are about, and my very technical question thereafter is going to be a follow-up, because this is a trilogy of trilogies, but we can get to that in a second. Let’s set up the Episode 1, Episode 2 part of this.

TESS: So the whole, "it’s a part of a trilogy" thing was actually a bit of a joke on myself. One of the first talks that I started doing outside of Minneapolis was on "Ride the Whale: Docker for Drupalists", and the idea was to teach people how to build your own Docker-based local development environment, and how Docker in general worked. And, that was the first start of it. Then the next talk that I gave was “Avoid Deep Hurting! Deployments beyond Git,” which introduced how to build your own continuous integration system using just open source, free stuff. Free stuff like Ansible, free stuff like Gitlab CI, and the idea behind that is now you have these two different pieces that don’t seem related, but become related in this talk.

I kind of sat back and thought about all the talks I’d given over the last few years and realized, Oh, geez, I made a trilogy. Oh, God, what did I do? When that occurred to me, I also knew what the whole theme of the talk was going to be, and because it was a trilogy, I decided, Okay, fine we’ll call it "Return of the Clustering" and we’ll do a whole Return of the Jedi motif, because why not?  [laughing]

IVAN: Exactly. So, we’ve set up the trilogy, now "Return of the Clustering" is a wonderful evolution, in my opinion, from your very beginning of trying to figure out how the heck are we going to set up Drupal in an easy Docker container or set of containers locally, and basically fast forward to the real meat of what we’re trying to do, and that’s run Docker in production? Right? So, give us a high-level description of "Return of the Clustering."

TESS: So, we first start out with describing, Wouldn’t it be great if we ran Docker in production? And we dissect the various problems with that. There are security problems that come inherent with running a Docker-based workload that you have to be aware of, and most people who just use Docker out of the box might not have ever considered these facts. And, it’s different than traditional server management, because there are a few different additional factors that come into play with how Docker executes things. Then you also have to worry about how you’re going to actually get the workload onto the cluster as well, and how you’re going to orchestrate it. One of the biggest problems is, it’s really easy to stand up Docker on a single server and have that single server run an entire workload of multiple containers.

There’s nothing wrong with that. You install Docker, you install Compose, you write a Compose file, you stand it up, you do some security things to make sure everything is loaded correctly, and there you go, you’re done. But, the problem is that your scaling is only vertical. You can only make your server bigger. You really want to make your scaling horizontal and add more servers. And this makes things very complex, because if you have to coordinate multiple Docker hosts together, doing that manually is not fun, and it’s not DevOps either. It’s not automatable in a very easy way. Fortunately, there are container orchestrators out there that know how to do this for you. So we talk about Docker Swarm and what the advantages and disadvantages of that are, and then we introduce Kubernetes. We talk about how the Kubernetes model is different, then we architect out an architecture that will run a Drupal site in Kubernetes. And, this is actually a subtle point that I keep having to remind myself and others, is that the Kubernetes model is so complicated, with so many little details, and so many different things in it, that you really get lost very quickly. And it took me a year to figure out which bits of the Kubernetes’ model work for Drupal, and which bits we don’t need to talk about. Once I understood those parts, it was easy to build an architecture from those minimal amounts of pieces.

So, we review what those pieces are, and we describe them. Then we talk about how to technically implement them within Kubernetes, and why Kubernetes is kind of nifty through its use of YAML. So, what we’re going to do is, we build all of that out. But now we have another problem, which is, if we want to build the dynamic cluster which supports multiple clients, multiple sites, that’s a lot of YAML we have to manage and now we’ve just introduced a problem that I covered in Avoid Deep Hurting, which is, we have introduced humans back into the mix. We need to take the people out of the mix and let the technology handle it for us, because it doesn’t get tired, it doesn’t make typos, it doesn’t need three more coffees in order to get through the day—at least not most days. [laughing] So, we combine Ansible and Kubernetes and Docker to build out an entire cluster in an automated fashion, by just changing a few different variables, and we run that on Digital Ocean.

Then we also found out that the problem is, to really effectively leverage Kubernetes for Drupal, you can’t just put an Apache container out on Kubernetes and then throw the site on it, and then update it in place like you did with traditional server management. It’s not really the way that Kubernetes wants to do things. So, instead, we end up having to build a custom container that contains the site code already, and then run that on Kubernetes directly. And that’s a much more cloud-native workflow, and it’s a bit of a paradigm shift from what a lot of people are used to. But, each one of these pieces works well together to create an effective, open source, minimal Kubernetes production cluster for Drupal.

IVAN: I love that it’s minimal. I mean, you just put what you absolutely need out there. And that’s kind of the philosophy and it reduces your security work, quite honestly, and it also reduces the attack vector. So, I’m so glad to have heard this summary about the talk. I hope that people go out there and watch the recording, and if you have an opportunity to attend TC Drupal Camp or Flyover Camp in Kansas, you’ll be at both of those places giving the talk again.

We went through your talk, let’s talk a little bit more about Drupaldelphia 2019. So, it’s a one-day camp, and it kind of looks like there were six tracks, which is a large number of tracks for a camp.

TESS: It was a surprising amount of things you could do in every time slot.

IVAN: And it feels like the tracks weren’t just Drupal, right? I mean we talked about this with Chris and Dan [organizers of TC Drupal Camp]. It kind of feels like there is this conscious effort in the camps, at least the ones I’ve been paying attention to recently, to be not just about developers, and not just about Drupal. So, what do you think about that?

TESS: I think that’s really a good strategy and it’s a lot more holistic than we’re used to going forward. I think that our industry is still getting used to the idea that there is an internet that we can connect with each other and research things, even though we do it every day. I don’t think that the cultural and emotional impact of that has really entirely sunk in. And a lot of events are changing to reflect that attitude, that it’s not just one piece of technology that we need to deeply investigate anymore. It’s now: how does this one piece interact with a whole bunch of other pieces? And some of those pieces aren’t technology. A lot of those pieces are people.

IVAN: Yeah, the people aspect is so important as well, and I’m so glad to see those tracks are appearing on the local camps. And, so, one day, six tracks, five sessions in the days, so about 30 sessions total in the whole camp, which sounds about exactly the same as what we’re doing in TC Drupal this year on the one day of the camp. I didn’t see a keynote on the schedule, an official keynote. I didn’t see intro and outro, welcoming remarks and ending remarks. Is that right? There was no keynote?

TESS: There was no keynote. There was a brief intro, and then the session started. And I think that actually worked fairly well for this camp, because I think that the shorter the camps, a keynote is less effective. And, this is a bit of an attitude change, because I remember when TC Drupal first didn’t have a keynote, and I kind of missed it. I kind of wanted that back, because one thing that was kind of nifty about having a keynote is that, it’s there to introduce you to the talk, and get you excited, and get you ready for the day. But for a one day camp, it’s not really that necessary, is it?

IVAN: No.

TESS: You’re already there. You already are invested to do the day, and there doesn’t seem to be much of a need to really do that. It might be that keynotes are a thing that are best suited for multi-day events.

IVAN: Yeah, that’s kind of what I’m thinking as well, multi-day events that maybe need higher attendance, and so you almost use the keynote to attract attendees that you hope stay on. So, maybe there’s a celebrity, or someone who’s done an awful lot of contribution that has the keynote. And I’ve always thought of that as an attractor, but it almost eats into the day if it’s a one-day camp.

TESS: Yeah. It usually takes a good hour and a half, and you could get a whole entire slot and a break in otherwise. And from an organizer perspective, attracting a keynoter is often very difficult, because if you’re a keynoter you usually should compensate them in some way, even if it’s just paying for lodging and a flight. But that can be a bit of an impediment, especially if you’re a smaller event, or a less established event, you might not be able to get someone to do a keynote. And, I think it might just be not as necessary anymore. It might just be better to have everything else.

What was also kind of nifty about Drupaldelphia is that they had these help desks, as well. Every time slot had an accessibility lab, a Drupal and Composer help desk, and a contribution workshop room. And I thought that was spectacular, because it allows people to drop out of the sessions and work on other things or get directed help. And a Drupal and Composer help desk, I thought that was a brilliant idea, because wow Composer. Composer can really, really ruin your day. [laughing]

IVAN: Yeah, I agree. So, is that how BoFs and Contributions will handle theirs basically during the whole day and maybe as options and alternatives to the sessions that were already scheduled? Is that how it was handled?

TESS: No, there was also a distinct BoF room, but it did share with that particular room, which I think might not have been necessarily the best choice. I think that it would’ve been a bit better to have a dedicated BoF room, and then a dedicated help desk lab room, because that would allow people to be less interrupted by people who are doing a BoF. And sometimes BoFs end up being sessions that were submitted, but weren’t accepted for whatever reason, and those could be kind of distracting.

IVAN: And animated. Sometimes you get people who show up in cloaks and sabers in those BoF sessions too. [laughing]

TESS: Only if it fits in my carry on. [laughing]

IVAN: [laughing] It sounds like you had a good time there, Tess. That’s great. So, it was on a Friday at the end of the work week but in the middle of the day. What was attendance like?

TESS: There were about 250 people who attended. It was surprisingly packed. I think this is one thing that I noticed that a lot of these one-day events have kind of a side effect that they can concentrate their attendance. A multi-day event actually has kind of the reverse effect. It spreads out the attendance to multiple days and makes it more difficult to actually advocate it. Particularly if one of those days is a weekend. If one of those days is a weekend, a lot of developers, depending on the age

bracket of the segment that you’re going for, and Drupal is tending to get a little bit more middle-aged than it was like 10 years ago.

IVAN: Oh, come on. Come on. [laughing]

TESS: Hey, I’m being honest here. I’ve been to a lot of events and I’ve looked at the age of the people showing up and it’s like, Yeah, I’m seeing it.

IVAN: I know what you’re saying. People are little wiser, a little grayer, a little more family, families are attending. Yeah, it’s true.

TESS: And, as a result, having time on weekends is kind of a difficult call, even a difficult ethical call, because some people will do this for work. And now you’re asking them to do work on a Saturday. That could be a little bit of a difficult call, whereas if it’s a one-day event that’s during the week, then it’s fairly concentrated. And at that point you know that it’s just a workday that’s being used, and if this is aligned with your career, there’s nothing wrong with that. And, then it doesn’t interfere with your weekend and that critical amount of recovery time, that we all need at the end of a work week.

IVAN: I agree. I think it’s good for mental health to do it the way that it was done. What was the location of the camp? What was that event space like? Where was it located?

TESS: I think it was called The Hussian School of Art; I think. Originally when I found the building, I went to the wrong door and some very nice security people at the door were like, “Where are you going and what the hell is Drupal?” [laughing] So I had to give them my spiel really quickly and then they said, “Oh, oh, you want that? It’s probably around the corner. So, go down to the end of the block and take a left.” It was really helpful. And then later on when I went to get some coffee I passed by there and I found a door. I found a sign there that said that you should always go around the corner. So, no one else had to repeat what I did in the morning. [laughing]

IVAN: Okay, good. That’s called iterating, I think. Were you wearing your cloak at the time that the security guards were giving you directions?

TESS: I think that I stuffed it in my bag while I was taking the cab to the event, because the only hotel I could get was actually right next to the airport. [laughing] 

IVAN: Oh, my goodness.

TESS: And so, I had to take a cab ride to go into town and I didn’t want to seem weirder than I usually am to people. So, I stuffed the whole thing in my backpack and fortunately a plastic lightsaber and a cloak does not require that much space intentionally. We covered that already. So, it was kind of handy.

IVAN: So, a successful space then you felt. Was there kind of an atrium or a gathering space for everyone where there was lunch? Or, how did that work?

TESS: There was this semi-open area. We had the quick intro in that semi-open area. And then they pulled out some moveable walls to enclose that to make another room, which was nifty. And there was a nice little gathering spot where you could see the tables, and you could get lunch, and you could interact with different vendors that were at the event. That was all kind of nice, and then there was a couple rooms down some hallways, and yeah, it was a nice, cozy space and I rather liked it.

IVAN: So, overall impression of the event then, seemingly positive?

TESS: Yeah, I really enjoyed it. I thought that was a great event, and I think that more people should go to it.

IVAN: So, definitely a candidate for going to next year. We’ll have to wait and see what the next episode looks like of the series, I guess. And whether there will be a next episode?

TESS: We’ll find out. There might be a case study afterwards where we talk about what we actually did that might be a little bit more interesting to people than an intro to Kubernetes itself, but I think that it’s necessary.

IVAN: You know, that’s a great idea, to do a case study. I know we’re working through actually implementing something live right now, so be taking notes Tess, because it sounds like you already have an idea for the case study talk.

TESS: (laughing) All right.

IVAN: All right, all right. Well, thank you so much for spending your time with me today, again. It’s truly been my pleasure to have you on. Tess Flynn is the DevOps Engineer here at TEN7 and she was at Drupaldelphia 2019, giving her talk, "Return of the Clustering, Kubernetes for Drupal." The slides are online and a recording of the session itself is available as well. Just visit this episode's webpage for the links. The URL to this episode is t7.io/ep60.

And, don’t forget, if you’d like a credit towards your new Digital Ocean account, just go to ten7.com/digitalocean and follow the link on the page to redeem it.

You’ve been listening to the TEN7 Podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message, we love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.

May 22 2019
May 22

More and more users want the content to be available via a host of different devices. Various new interfaces and devices are thronging the technology landscape and are touted to bring about sweeping changes. There are even talks of website-less future. Smart wearables, Internet of Things, conversational user interface etc. have been gaining traction and are changing the way we experience the internet. New web-enabled devices need the content that the websites do but in a different format which creates complications in the way we develop. Disseminating content can have different needs from one setup to another.

Two coffee mugs placed diagonally opposite to each other and coffee beans scattered around one of the mugs


The content management system (CMS) is rife with labels such as ‘decoupled’ and ‘hybrid’ which requires to be dissected for a better understanding of their benefits. Decoupling the backend of a content management system (CMS) from the frontend can be a remarkable solution for a lot of issues that are caused when you move away from standard website-only deliveries. Decoupling the CMS streamlines the process of republishing the content across numerous channels ranging from websites to applications. Decoupled CMS is not new, but as the digital arena observes changes, it gets more and more important.

The Drupal Connect

Flowchart with boxes explaining decoupled DrupalSource: Dries Buytaert’s blog

As one of the leaders in the CMS market, Drupal’s content as a service approach enables you to get out of the page-based mentality. It gives you the flexibility to separate the content management from the content display and allows you the front-end developers to build engrossing customer experiences.

Decoupled Drupal implementations are becoming ubiquitous due to its immense capability in giving a push to digital innovation

Decoupled Drupal implementations, which involves a full separation of concerns between the structure of your content and its presentation, are becoming ubiquitous due to Drupal’s immense capability in giving a push to digital innovation and being a great solution in adopting novel approaches.

Drupal Community has been working on a plenitude of API-first architectures by utilising its core REST, JSON:API and GraphQL features. But there are alternative solutions, too, available in decoupled Drupal ecosystem that can be of great significance. Let’s explore them:

RESTful Web Services and others

While RESTful Web services module helps in exposing entities and other resources as RESTful web API and is one of the most important modules when it comes to decoupled Drupal implementation, there are several others that can come handy as well.

Implementing the Apache CouchDB specification and focussing upon content staging use cases as part of the Drupal Deploy ecosystem, RELAXed Web Services module can be of immense help. The CouchDB helps in storing data within JSON documents that are exposed via a RESTful API and unlike Drupal’s core REST API, it enables not just GET, POST, DELETE but also PUT and COPY.

There’s a REST UI module that offers a user interface (UI) for the configuration of Drupal 8’s REST module. You can utilise Webform REST module that helps in retrieving and submitting webforms via REST. For protracting core’s REST Export views display in order to automatically converting any JSON string field to JSON in the output, REST Export Nested module can be useful. By offering a REST endpoint, REST menu items module can be helpful in retrieving menu items on the basis of menu name. And when you need to use REST for resetting the password, REST Password Request module can be helpful. It is worth noting that Webform REST, REST Export Nested and REST Password Request are not covered by Drupal’s security advisory policy but are really valuable.

JSON:API and others

JSON: API module is an essential tool when you are considering to format your JSON responses and is one of the most sought after options in decoupled Drupal implementations. But there is, again, plenty of options for availing more features and functionalities. 

When in need of overriding the defaults that are preconfigured upon the installation of JSON: API module, you can leverage JSON: API Extras. By offering interfaces to override default settings and registering new ones that the resultant API need to follow, JSON: API Extras can be hugely advantageous in aliasing resource names and paths, modifying field output via field enhancers, aliasing field names and so on. There is JSON API File module that enables enhanced files integration for JSON: API module. And for the websites that expose consumer-facing APIs through REST, JSON: API or something similar, Key auth module offers simple key-based authentication to every user.

For streamlined ingestion of content by other applications, Lightning API module gives you a standard API with authentication and authorisation and utilises JSON: API and OAuth2 standards through JSON API and Simple Oauth modules.

GraphQL and others

GraphQL module is great for exposing Drupal entities to your GraphQL client applications. There are some more useful modules based on GraphQL. To enable integration between GraphQL and Search API modules, there is a GraphQL Search API module. Injecting data into Twig templates by just adding a GraphQL query can be done with GraphQL Twig module. To expose Drupal content entity definitions through GraphQL via GraphQL Drupal module and develop forms or views for entities via front-end automatically, you have GraphQL Entity Definitions module.

OpenAPI and related modules

OpenAPI describes RESTful web services on the basis of the schema. There is OpenAPI module in Drupal, which is not covered by Drupal’s security advisory policies but can integrate well with both core REST and JSON: API for documentation of available entity routes in those services. And for implementing an API to display OpenAPI specifications inside a Drupal website, you get OpenAPI UI module. And ReDoc for OpenAPI UI module offers the ReDoc library, which is an Open API/ Swagger-generated API reference documentation, for displaying Open API specifications inside Drupal website. Then there is Swagger UI for OpenAPI UI module that gives you Swagger UI library in order to display OpenAPI specifications inside Drupal site. You can also utilise Schemata module that provides schemas for facilitating generated documentation and generated code.

Contentajs and related modules

The need for a Nodes.js proxy that acts as middleware between Drupal content API layer and Javascript application can be addressed with the help of Contenta.js.  For Contenta.js to function properly, Contenta JS Drupal module is needed. This module is part of the Contenta CMS Drupal distribution. The Node.js proxy is essential for decoupled Drupal because of data aggregation, server-side rendering and caching. Contenta.js constitutes multithreaded Node.js server, a Subrequests server for the facilitation of request aggregation, a Redis integration and simple approach to CORS (Cross-origin resource sharing).

There are several effective modules that are part of the Contenta CMS decoupled distribution and integrates perfectly with Contenta.js. You have Subrequest module that tells the system to execute multiple requests in a single bootstrap and then return everything. JSON-RPC module offers a lightweight protocol for remote procedure calls and serves as a canonical foundation for Drupal administrative actions that are relied upon more than just REST. To resolve path aliases, Decoupled Router module gives you an endpoint and redirects for entity relates routes.

In order to enable decoupled Drupal implementations to have variations on the basis of consumer who is making the request, you can use Consumers module. You can use Consumer Image Styles that integrates well with JSON: API for giving image styles to your images in the decoupled Drupal project. And there is Simple OAuth module for implementing OAuth 2.0 Authorisation Framework RFC.

Of relating to JavaScript frameworks

Decoupled Blocks module is great for progressive decoupling and enables front-end developers to write custom blocks in whatever javascript framework that they prefer to work on. If you want to implement using Vue.js, you can use Decoupled Blocks: Vuejs. It should be noted that both of these are not covered by Drupal’s security advisory policies.

React Comments comes as a drop-in replacement for the Drupal core comment module frontend.

Also, there is a jDrupal module, which is a JavaScript library and API for Drupal REST and can be leveraged for Drupal 8 application development.

Conclusion

With Drupal as the decoupled web content management, developers can get to use a plentitude of technologies to render the front end experience.

RESTful web services, GraphQL and JSON: API are not the only resources that you get in the decoupled Drupal ecosystem. In fact, there are plenty of other alternatives that can be of paramount importance.

Drupal development is our forte and bringing stupendous digital experience to our partners has been our prime objective. Contact us at [email protected] and let us know how you want us to be a part of your digital transformation goals.

May 22 2019
May 22

Drupal allows to find the most effective solution for every business case. Large organizations often need more than one website but a collection of related sites, which would be easy to manage. To meet this need, there is the Drupal multisite feature that has become popular among education websites, government websites, corporate websites, and so on. Let’s explore what Drupal multisite is, how it works, and when it is the best choice.

What is Drupal multisite?

Multiple sites combined in the same Drupal installation — that’s the basic essence of Drupal multisite feature. Instead of one site, you have a collection of websites that are created, managed, deployed, and updated from one place because they share one codebase. They have different web addresses and also may differ in nuances according to your requirements.

Drupal multisite architecture

In the multisite setup, different Drupal sites share:

  • Drupal core
  • codebase
  • available modules
  • available themes

At the same time, they do not share:

  • base domains or URLs
  • databases
  • enabled modules
  • enabled themes
  • configurations
  • files
  • user profiles
  • content

Here is an example of Drupal multisite feature created by our company for a global retail chain of goods for home. Websites for different countries work from the same Drupal core and have different features enabled from the admin dashboard and saved in configuration.

Drupal multisite example

Drupal multisite benefits

For some companies, a strong multisite feature is one of the reasons they have chosen Drupal at all. Here’s why.

The Drupal multisite is valued for big savings in time, effort, costs, and resources. This applies to website development, installation, and management. Sites are hosted on the same server, have the same codebase, and all processes can be performed on them at once. This is especially noticeable when sites are numerous.

For example, updates and upgrades don’t have to be repeated for all websites — one action is enough. This includes core, module, and theme updates, as well as updates to the server OS, applications, and database software.

With multisite, it is also easy to introduce new features. Say, you create a new module for your site, and it is easy to share it across others.

Another benefit of Drupal multisite is the presence of useful solutions and tools. Among them:

Drupal multisite risks

In some cases, Drupal multisite can present risks that are “the other side” of its benefits. They have even caused hot discussions in the Drupal community.

Namely, if there are any traffic spikes or security issues on one site, this can potentially influence others. And any mistakes during website updates or changes can harm other websites as well and create a “mess.”

So Drupal multisite setup and maintenance is a responsible task for experienced teams with advanced technical skills. Websites should be managed with great care, best practices and tools, and always kept up-to-date.

And, of course, multisite should be chosen when it suits the use case, recommendations for which we will discuss next.

When Drupal multisite is the best choice

As usual with benefits and risks, they are relative, and depend on the situation. Here is when Drupal multisite is a good fit, smooth in management, and most beneficial:

  • First of all, a “rule of thumb” for choosing multisite is that functionality should be similar across websites.

They may look differently due to different enabled themes, or even represent completely different industries.

Alternatively, they may look similar (like in the case of departments for the same organization), and have similar functionality with slight differences necessary for specific departments.

  • You can consider multisite if you are not planning to introduce serious feature changes to selected sites from your “cluster.” If serious changes are planned, they should apply to all.
  • Multisite is most successful if sites in the collection are the responsibility of the same development and support team. And, remember, it should be a careful and experienced one.

If the functionality on websites is significantly different, it is better to use other approaches instead of multisite. It’s possible to considerably optimize codebase management using Git version control system, Composer package manager, and more. 

Let’s discuss multisite for your case

To decide whether you will benefit more from the multisite setup or from separate sites, from just multilanguage, and so on, you can always consult our development team. We will also be your development or optimization team to fulfil these ideas. Our 11 years of expertise let us do it perfectly.

Remember, we started this post by saying that Drupal has an effective solution for every business case. And it’s true. Let’s find one for you!

May 22 2019
May 22

There's this millennial phrase "You snooze, you lose" and nowhere is it more applicable than for enterprises today. Opportunities to engage with your audience pop up fast and disappear faster, and you have to act quickly if you wish to leverage any of it. 

You want to build rich online experiences and that's great. But how fast is your team in getting from ideation to roll out? Usually your marketing and digital experience team is brimming with ideas, but the development team is too backed up to work on any of it.

Enter Layout Builder.

Layout Builder is a module in Drupal 8 that became stable with its newest release, Drupal 8.7. It essentially allows content editors and other non-technical stakeholders to design and build custom pages, without waiting for the development team.

Now, all you need to do is download Drupal 8.7 and follow a set of few simple steps and your design is ready.

But was it always as easy as it's now? Let’s take a look at what Drupal offered before.

How It All Started

The Drupal 6 users configured the design by selecting/deselecting the items from the dropdown menu to include/exclude in the website design.

 drupal6-cck-display-fields-srijan-1

 After upgrading to Drupal 7, users managed the fields appearing on the UI in a similar fashion.

drupal7-image-display

With Drupal 8, things remained more or less the same, where developers were the sole owners of the website design.

drupal8-image-display-srijan-technologies

Until Drupal 8.6, the developers could choose templates and include them on the website.

powerful-customization-in-tempaltes-srijan-technologies

Developers could manage how the blocks appeared on the page by selecting the position from the drop-down menus, or, by selecting the options.

block-description-srijan-technologies-1

Developers often used “Panels”, which offered much of the same functionality as Layout Builder. However, in spite of their intuitive GUI and WYSIWYG editor, panels failed when it came to translations.

panels-srijan-technologies

What Went Wrong?

Here’s why the Panels was not a viable solution for long:

  • Difficult to learn
  • No provision to “Preview” the page
  • Could not custom design as per the requirement

Layout Builder - What and Why

As the name implies, the Layout Builder tool enables editors to have an easy-to-use page building experience. So, it’s more convenient if the editor tweaks the design and analyse the suitability of an image with the content, just by dragging and dropping the content.

The tool empowers content authors by leveraging them with the capabilities to:

  • easily adjust the design and format of a page by using drag-and-drop and WYSIWYG tools
  • make changes to the layout without involving developers every time
  • visually create a layout template that will be used for each item of the same content type
  • customize templated layouts on a case per case basis
  • create dynamic one-off custom pages which don’t come under any template like About Us page

For smaller sites where there may not be many pages or content authors, the unrestricted creative freedom seems to be compelling. However, on larger sites, when you have hundreds of pages or dozens of content creators, a templated approach is preferred.

layout builder infographic

Why Else Choose Layout Builder?

Simple Page Management

Layout Builder gives the content editors the capability to create a layout by inserting new blocks from the pop-out sidebar and rearranging them wherever they are needed. They can preview the entire layout instantly, allowing them to insert, replace or delete blocks, images, text and buttons. They can use ‘Content Preview’ checkbox to show small textual representations of the block instead.

Accessibility

With increasing collaboration, there’s a need to ensure that no one is excluded from enjoying the online experience with ease. Layout Builder conforms with the Drupal’s commitment to web accessibility. helps you use keyboard or screen reader to navigate - to conform to the Web Content Accessibility Guidelines recommended by World Wide Web Consortium. Considering the specific accessibility requirements, the drag-and-drop editor was designed to make it accessible for everyone to enable moving blocks, creating new sections and adding/moving content to the blocks.

Workflows

The Layout Builder supports essential activities such as adding, saving, previewing and publishing data. You can send layouts through a staging or approval workflow and then publish it right from the same interface after the team reviews a saved piece.

Templates

The Layout Builder also includes a templating feature, useful for sites with large quantities of content. Using the Layout Template, editors can edit collections of pages all at once and rearrange the structure while retaining the unique content. The ability to restructure multiple pages at once saves a huge amount of time when one block needs to be changed across multiple locations.

How to Work with Layout Builder?

Install the Devel module and enable both the Devel and Devel Generate parts of the plugin.
Click Install.

devel-srijan-technologies

 Source: OSTraining

  • Click Configuration > Generate content in order to generate content for an article. Click Generate.

content-type-srijan-technologies

Source: OSTraining

  • Click Content and you’ll see the generated article.

Configure the Layout of the Article Content Type
Go to Manage > Article and then select the checkbox “Use Layout Builder”. Click “Save”.

configure-the-layout-article-type-srijan-technologies

 

Upgrade to Drupal 8.7 without a doubt!

The newly stable Layout Builder is unique in a way that it supports templated layouts for hundreds of pieces of structured content as well as in designing custom one-off pages with unstructured content. Catch up with the latest upgrade and let your clients make the most of Layout Builder’s features. 

While your editors and authors get empowered to create rich experiences, there are other aspects of your Drupal implementation that could be optimized or transformed with an expert team. Srijan is working with leading global enterprises, leveraging Drupal, data science and analytics, AI, machine learning, and chatbots to create tailor-made business solutions. Let's start the conversation and explore how Srijan can help. 

May 22 2019
May 22

Drupal 8.7 was released with huge API-First improvements!

The REST API only got fairly small improvements in the 7th minor release of Drupal 8, because it reached a good level of maturity in 8.6 (where we added file uploads, exposed more of Drupal’s data model and improved DX.), and because we of course were busy with JSON:API :)

Thanks to everyone who contributed!

  1. JSON:API #2843147

    Need I say more? :) After keeping you informed about progress in October, November, December and January, followed by one of the most frantic Drupal core contribution periods I’ve ever experienced, the JSON:API module was committed to Drupal 8.7 on March 21, 2019.

    Surely you’re know thinking But when should I use Drupal’s JSON:API module instead of the REST module? Well, choose REST if you have non-entity data you want to expose. In all other cases, choose JSON:API.

    In short, after having seen people use the REST module for years, we believe JSON:API makes solving the most common needs an order of magnitude simpler — sometimes two. Many things that require a lot of client-side code, a lot of requests or even server-side code you get for free when using JSON:API. That’s why we added it, of course :) See Dries’ overview if you haven’t already. It includes a great video that Gabe recorded that shows how it simplifies common needs. And of course, check out the spec!

  2. datetime & daterange fields now respect standards #2926508

    They were always intended to respect standards, but didn’t.

    For a field configured to store date + time:

    "field_datetime":[{
      "value": "2017-03-01T20:02:00",
    }]
    

    "field_datetime":[{
      "value": "2017-03-01T20:02:00+11:00",
    }]
    

    The site’s timezone is now present! This is now a valid RFC3339 datetime string.

    For a field configured to store date only:

    "field_dateonly":[{
      "value": "2017-03-01T20:02:00",
    }]
    

    "field_dateonly":[{
      "value": "2017-03-01",
    }]
    

    Time information used to be present despite this being a date-only field! RFC3339 only covers combined date and time representations. For date-only representations, we need to use ISO 8601. There isn’t a particular name for this date-only format, so we have to hardcode the format. See https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates.

    Note: backward compatibility is retained: a datetime string without timezone information is still accepted. This is discouraged though, and deprecated: it will be removed for Drupal 9.

    Previous Drupal 8 minor releases have fixed similar problems. But this one, for the first time ever, implements these improvements as a @DataType-level normalizer, rather than a @FieldType-level normalizer. Perhaps that sounds too far into the weeds, but … it means it fixed this problem in both rest.module and jsonapi.module! We want the entire ecosystem to follow this example.

  3. rest.module has proven to be maintainable!

    In the previous update, I proudly declared that Drupal 8 core’s rest.module was in a “maintainable” state. I’m glad to say that has proven to be true: six months later, the number of open issues still fit on “a single page” (fewer than 50). :) So don’t worry as a rest.module user: we still triage the issue queue, it’s still maintained. But new features will primarily appear for jsonapi.module.

Want more nuance and detail? See the REST: top priorities for Drupal 8.7.x issue on drupal.org.

Are you curious what we’re working on for Drupal 8.8? Want to follow along? Click the follow button at API-First: top priorities for Drupal 8.8.x — whenever things on the list are completed (or when the list gets longer), a comment gets posted. It’s the best way to follow along closely!

Was this helpful? Let me know in the comments!

For reference, historical data:

May 21 2019
May 21

For website builders, the perennial debate between WordPress and Drupal rages on. As a Drupal-focused agency, it would be easy for us to promote Drupal’s benefits while badmouthing WordPress. Ultimately, though, that kind of thinking distracts form a more nuanced take on the debate: which CMS is best for you? While we’ve covered the comparisons between the two platforms before, it’s always worth revisiting the similarities and differences between them.

drupal-wordpress

Part of the reason why the “WordPress vs Drupal” narrative persists is because there is no definitive “winner.” Drupal and WordPress are both great tools that we’d have no problem recommending. In fact, the two platforms have more in common than you might realize. Both WordPress and Drupal are free, open source content management systems with vast ecosystems of contributed plugins and modules. Both are also sustained by communities of users and developers who continue to make each platform successful.

Ultimately, the choice between WordPress and Drupal comes down to you and your site’s requirements. Both platforms come with advantages and disadvantages depending on the task at hand, so it really is a case-by-case basis. Instead of boiling the matter down to “Drupal vs. WordPress,” consider the following comparisons against your needs to determine which platform is the best fit for your project.

Ease vs Order

Imagine that you want to publish a new piece of content on the site. If you’re just trying to, say, publish a blog on your site as quickly as you can, it’s hard to beat WordPress. With its simple-to-use interface, WordPress streamlines the content management process and makes it easier for editors to swiftly publish or edit a basic story.

On the other hand, if you have content originating from multiple sources and you want to be able to publish across channels, consider the Drupal CMS. While slightly more difficult to master, the Drupal back end can handle varying data types and keep them organized. Essentially, if you are managing multiple sites or are publishing more complex content types, Drupal’s has the power to deliver a robust, seamless experience.

Model vs. Building Blocks

Consider a model kit. If you follow the directions and don’t deviate, you’ll end up with a sleek and stylish figure. WordPress is very much the same. Sites built using WordPress are specially optimized for easy posting and content creation. If your needs are contained and fit within the boundaries of what WordPress was designed to do, it’s a perfect out-of-the-box solution.

Adding custom features to a WordPress site, however, can be complicated. This is not the case with Drupal, which is more akin to building blocks than to a model. Much like a field of Lego bricks strewn on the floor, Drupal allows for so much customization that you may not even know where to start. Once you have a plan, though, a Drupal site can be configured to your exact specifications while still leaving room for changes later.

Solo vs Team

Because of its aforementioned ease-of-use, WordPress gives plenty of power to content creators. If you stick to OOTB functionality, you can manage an entire WordPress site on your own. Even the plugins and themes that you can add to a site can be updated with a click of a button, making routine maintenance easier.

Given its enterprise-level capabilities, Drupal is better suited to a site run by a team. Different roles with custom permissions can be assigned to different team members inside a Drupal site. These hierarchies can make it easier to collaborate on a site and ensure that there’s accountability throughout the development process.

Pages vs. Architecture

Even without any technical experience, a content creator could easily design a page on a WordPress site. The OOTB editing suite allows you to build and layout rich pages with text, images and other assets that you can quickly deploy and publish.

Though Drupal has taken strides to make their page layout builder more accessible, creating pages in Drupal takes some practice. What Drupal has going for it is its structure. Drupal offers various levels of tagging and taxonomy that allow you to organize and repurpose content in endless permutations. Further, you can create custom content types in Drupal, expanding the possibilities of what kinds of content you can publish.  

What these comparisons illustrate isn’t that one platform is better than the other. Rather, they show that each tool has its own strengths and weaknesses depending on the situation. And in the end, your mileage may vary; our team has seen enterprise sites that run on WordPress and run on Drupal. It’s all about what each user wants and needs.

Duo specializes in Drupal because we like working with the CMS’s flexibility at an enterprise scale. If you think Drupal is right for you or if you still need help deciding, please feel free to reach out to us!

Explore Duo

May 21 2019
May 21

This is the first of a two part series discussing a couple of different platforms that we at Acro Media endorse for our clients. First up, I’ll talk about Drupal, a popular open-source content management system, and how it’s excellent content capabilities can be extended using an ecommerce component of your choice. For companies that require experience-led commerce architecture solutions, Drupal as an integration friendly content engine is an ideal open source choice.

A quick introduction

People who follow our blog will already know about open source technology and Drupal because we talked about them a lot. For those of you who don’t know, here’s a quick introduction.

Open Source

Wikipedia sums up open source software well.

Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is a prominent example of open collaboration.

Open-source software development can bring in diverse perspectives beyond those of a single company. A 2008 report by the Standish Group stated that adoption of open-source software models have resulted in savings of about $60 billion (£48 billion) per year for consumers.

While that describes open source software as a whole, there are many advantages of open source specifically for content creation and ecommerce. No licensing fees brings the total cost of ownership down, businesses are fully in control of their data, and integrations with virtually any other system can be created. If you like, you can read more about the advantages of open source for ecommerce via this ebook.

Drupal

Drupal is a leading open source content management system that is known for being extremely customizable and ideal for creating rich content experiences. In a CMS world dominated by WordPress, Drupal is often overlooked because of its complexity and somewhat steep learning curve. Don’t let that stop you from considering it, however, as this complexity is actually one of Drupal’s greatest strengths and the learning curve is continuously improving through admin-focused UX initiatives.

The platform can literally be made to do anything and it shines when very specialized or unique functionality is required. It has a rich ecosystem of extensions and is very developer friendly, boasting a massive development community ensuring that businesses using Drupal always have support.

On top of this, Drupal has various strategic initiatives that will keep it modern and relevant now and into the future. One of the initiatives is for the platform to be fully API-first, meaning that a primary focus of Drupal is to be integration friendly. Developers can integrate Drupal with any other software that has an API available.

Drupal for experience-led commerce

Drupal is suited for any of the three main architectures (discover your ideal architecture here), but experience-led commerce is where it’s most capable. Experience-led is for businesses who keep the customer experience top of mind. These businesses want more than to just sell products, they want to also tell their story and foster a community around their brand and their customers. They want their customer experiences to be personalized and content rich. It’s these experiences that set them apart from their competitors, and they want the freedom to innovate in whatever way is best for their business.

Click to discover your ideal architecture with our analysis.More often than not, SaaS ecommerce platforms alone just don’t cut it here. This is simply because they’re built for ecommerce, not as an engine for other content. Although there are a lot of benefits to SaaS for ecommerce, businesses using SaaS must conform to the limitations set by the platform and its extensions. Robust content is just not typically possible. Sure, a business may be able to maintain a blog through their SaaS ecommerce platform, but that’s about it.

Drupal, on the other hand, is a content engine first. It was built for content, whatever that content may be. If you can dream it, Drupal can do. On top of this, Drupal, being integration friendly through its API-first initiative, allows businesses the freedom to integrate any compatible SaaS or open source ecommerce platform. At this point, a complete content & commerce solution has been created and the only limitation is your imagination and available resources to implement it. Implementation can be done in-house with an internal IT team or outsourced to one of the many service providers within the Drupal marketplace, Acro Media being one of them.

Let’s look at three widely different examples of Drupal based experience-led commerce.

TELUS Mobility

Website: www.telus.com

TELUS Mobility is one of Canada’s largest telecommunications companies. Imagine the missed opportunities when a customer’s online billing isn’t connected to your latest promotions and customer service can’t quickly or easily get this information in front of them. This was a problem that they faced and business restrictions, one being that they need to own all of their code and data, required that they look outside of the SaaS marketplace for a solution. Drupal, combined with a Drupal-native Drupal Commerce extension, was the solution that they needed. The open source code base of both Drupal and the Commerce extension meant that TELUS Mobility had the control and ownership that they needed. The result was huge, many important customers and customer service UX improvements were made which enabled TELUS Mobility to outperform their competitors.

You can read the full TELUS Mobility case study here.

Bug Out Bag Builder

Website: www.bugoutbagbuilder.com

Bug Out Bag Builder (BOBB) is a content-rich resource centered around preparedness. They generate a lot of different types of content and needed a way to do it that is easy and reusable. They also had a very unique commerce element that needed to tie in seamlessly. Here’s how we did it.

First is the content aspect. BOBB is full of content! They maintain an active blog, continuously write lengthy product reviews and provide their readers with various guides and tutorials. They’re a one-stop-shop for anything preparedness and have a ton of information to share. As you can see, a simple blog wouldn’t be sufficient enough for this business. They needed a way to create various types of content that can be shared and reused in multiple places. The Drupal CMS was easily able to accommodate. All of the content has a specific home within the site, but each article is categorized and searchable. Content can be featured on the homepage with the click of a button. Various blocks throughout the site show visitors the most recent content. Reviews can be attached to products within their online custom bug out bag builder application (more on this below). All of this is great, but what makes Drupal a fantastic content engine is that if BOBB ever needs to use this content in another way, all of the saved data can be reused and repurposed without needing to recreate the content. Just a little configuration and theming work would need to be done.

Second is the commerce aspect. BOBB is not a standard ecommerce store. At their core, they’re actually an Amazon Associate. They’ve developed a trust with their readers by providing fair and honest reviews of preparedness products that are listed on the Amazon marketplace. If a reader then goes and buys the product, BOBB gets a cut since they helped make the sale.

That’s all pretty normal, but what makes BOBB unique is that they also have a web-based Custom Bag Builder application. This tool has a number of pre-built “BOBB recommended” bag configurations for certain situations. Customers can select these bags (or start from scratch), view/add/remove any of the products, and finally complete the purchase. Since BOBB doesn’t need the full capabilities of ecommerce, it didn’t make sense for them to be paying monthly licensing fees. Drupal Commerce was selected for this purpose. It’s used as a catalog for holding the product information and creating a cart. Then, an integration between Drupal Commerce and Amazon transfers the cart information to Amazon where the customer ultimately goes through checkout. Amazon then handles all of the fulfillment and BOBB gets the commission.

BikeHike Adventures

Website: www.bikehike.com

BikeHike Adventures was founded as a way of bringing like-minded adventurers together through the unique style of world travel that they promote – activity, culture and experience. They provide curated travel packages that customers enquire about through the BikeHike Adventure website. Travel is all about experience and they needed to share this experience through their website. They also needed more than just a standard article page to do it since there is a ton of information to share about each package. Furthermore, they wanted to give customers a way to reserve a trip for pre-selected dates or through a custom trip planner. Again, Drupal was a perfect fit.

When you visit the site, you’re immediately thrown into the world of active travel through a rich video banner followed by a series of travel packages, a travel blog and more. There is a lot of exciting locations and vibrant imagery throughout.

Clicking into a package, you’re again hit with spectacular photography and all of the information you would need to make a decision. You can read about the trip, view the itinerary and locations marked on a map, learn about what’s included and where you’ll be staying, read interesting and useful facts about the country and location, see a breakdown of day-to-day activities, read previous traveler review, and more. When a customer is ready to book, they can submit an enquiry which is then handed off to the BikeHike Adventures travel agents.

A commerce component isn’t actually being used in this site, but it’s just a great example of content and customer experience that is used to facilitate a booking with a travel agent. If BikeHike Adventures wanted to in the future, they are free to integrate the booking and payment platforms of their choice to automate some, if not all, of that aspect of this process. By utilizing the open source Drupal CMS, this is an option that they can exercise at any point in time.

Who is Drupal best suited for?

Drupal could be used for any business, but it’s typically best suited for ecommerce businesses:

  • Who want to differentiate their brand through personalized shopping experiences
  • Who want to showcase products outside of a standard product page
  • Who want the power to develop a content-rich experience AND have an industry standard checkout process
  • Who want to sell across multiple channels and third-party marketplaces
  • Who need to develop and execute cohesive and synchronized marketing campaigns across multiple channels
  • Who want the freedom to integrate and connect their CMS and commerce platform with other components within their overall architecture
  • Who want to limit platform fees and instead invest in their own commerce infrastructure

In closing, there’s a reason why the ecommerce market is open to open source more than ever. Businesses are increasingly seeing that open source provides a quality foundation for which to build and integrate the solutions they need for today's new-age ecommerce. Customer experience is now seen as a competitive advantage and there are a handful of options that can provide this experience, Drupal being one of them. If you’re looking experience-led ecommerce solutions, consider Drupal. It might just be what you need.

Additional resources

If you liked this article, check out these related resources.

Click to discover your ideal architecture with our analysis.

May 21 2019
May 21

Your current website/platform is built on Drupal 7 and news has hit your ears about 7’s end of life (EOL). Maybe your site is a Drupal 8 site and you want to know what the future has in store for you. Good news is, you don’t have to do anything immediately, but it is definitely a question that you want to start thinking about very soon.

This article is mainly aimed at Drupal 7 builds looking to upgrade to 8 or 9, and we will explore the pros and cons of each. However, if your current platform is based on Drupal 8 and you want to know what your options are with regards to Drupal 9, you can skip to here. Or, if like my fence (yes, that really is my fence and it is in desperate need of an upgrade), you require an upgrade, skip down to see what we can do for you.

Drupal 7’s EOL is November 2021, which is a little way off yet, but it’ll soon creep up on you (very much like my fast approaching wedding day… eek!)! So what does EOL mean? After End of Life in November 2021, Drupal 7 will stop receiving official support: this means no more security fixes and no more new features. Any new ‘Drupalgeddon’ security issues will be ignored, leaving Drupal 7 sites open to attack; we saw a minority of sites being used as bitcoin miners last year as a result of sites not being patched… this is just an example of what could/can happen!

There appear to be talks in the Drupal community about providing LTS (“Long Term Support”) programmes, offering continued support for Drupal 7. Community LTS tends to cover security issues mostly, with minor functionality updates. But if you want the longest term security support prospects, whilst also being on the platform best suited to growth, ongoing development and support we would advise that you don’t look to the D7 LTS programmes.

Crucially, a Drupal 7 to 9 upgrade will largely be the same as a 7 to 8 upgrade - you won’t be missing out on too much; you’ll just wait longer for the new goodness that 7 doesn’t have!

The best option, therefore, is to consider an upgrade. But which version do you go for? Should you go straight in for Drupal 8, or stay longer on your beloved Drupal 7 and switch over to 9 nearer 7’s end of life? Let’s look at the options.

Benefits of migrating to Drupal 8

Drupal 8 was a complete ground-up rewrite of Drupal 7. D7 was written without a known framework and without utilising Object Orientation, meaning a majority of Drupal 7 was written procedurally; this can make code hard to maintain and inefficient, resulting in a loss of page load performance. Using a framework that is built upon an OO philosophy ensures clearer code that it is easier to maintain, read, and modify - all of which results in a faster, more secure site.

Drupal 8 also runs on PHP 7 as standard; PHP 7 is *much* faster than its predecessor. In addition, D8 utilises a new theming engine called Twig - with benefits that include better security (Twig automatically sanitises user input, for example) and a big emphasis on separation of business logic and presentation as well as being fast and flexible. It also includes nice features such as inline editing, handy for those sites that have lots of ever changing content; this should save you a few clicks of a mouse and multiple page loads! Drupal 8 is also continuing to add new features, like the anticipated Layout builder (which you can read all about here), the newly incorporated media handling and big pipe!

Can’t I just upgrade straight to Drupal 9 when it is released?

Well you could, but we would recommend not to. Drupal 9’s release is only around the corner, much like Drupal 7’s EOL. 9 is due to be in our hands mid-late 2020. This overlap has been cleverly timed with Drupal 7’s EOL to allow Drupal 7 sites to upgrade to Drupal 9 with time to spare before EOL. So what is the difference between Drupal 8 and 9 and why do we recommend to upgrade to Drupal 8 first?

Drupal 9 - in Layman’s terms - will be a “cleaner” version of the latest Drupal 8 version; they’re essentially the same thing, minus some deprecated code that was present at the start of Drupal 8’s life. (Deprecated code is code that is due to be decommissioned and re-written/re-integrated at a later date. The code is still safe and usable, but if you upgrade in the future, you might have a job on your hands converting all the deprecated code with their replacements. Rule of thumb, always use the newer version if it’s available to avoid future headaches).

Crucially, a Drupal 7 to 9 upgrade will largely be the same as a 7 to 8 upgrade - you won’t be missing out on too much; you’ll just wait longer for the new goodness that 7 doesn’t have! Drupal 9 will also include updates to external libraries/dependencies, which it relies upon, not to mention any new features that’ll it have over 8. At time of writing, we are unsure of what these might be!

The only foreseeable benefit we can see for waiting for Drupal 9 (over 8) is that you get to stay on your tried and trusted Drupal 7 site for a year or two longer whilst giving you maximum time to plan for that eventual upgrade.

How easy is it to upgrade my site?

At the start of Drupal 8’s life, one of the major goals that 8 wanted to get right over D7 was migration. Therefore, a big emphasis was placed on making sure that migrations were easier and less painful to do, particularly since it (core) would have a completely different architecture. As a result, migrations from 7 to 8 (or 9) are somewhat nicer than those who upgraded from 6 to 7 (Checkout our Conservative Party case study where we migrated an entire Drupal 6 platform to 8)

Some of you who have been reading our articles for the last few years will notice we underwent a huge change - not only did we re-brand, but we also upgraded from 7 to 8 - all of which you can read about, including all the trials and tribulations we experienced.
Drupal 8’s built in migration tools are a huge improvement over 7 and the Drupal community has created some really neat modules too, some that will provide a good starting point for any migration mappings that you may need…  However, any custom code/custom field structures will need additional plugins and migration mappings without discounting an entire re-write of any HTML template files due to the new theme engine Twig.

As far as we are currently aware, a Drupal 8 to 9 migration will be *much* easier than a 7 to 8 migration. Those who have a Drupal 8 site see their minor version (8.5, 8.6, 8.7 etc etc) updated every 6 months with very little hiccups. A Drupal 8 to 9 migration will be not too dissimilar to the minor version updates that current Drupal 8 owners experience today. One of the very few exceptions being that any deprecated code (as explained above) will need converting; upgrading all contrib modules and performing a full custom code audit to make sure this works with the new version of Drupal. The data structures will remain intact as will the theme engine so no need to write new migration mappings or to convert any HTML templates - these tend to make up the bulk of the work for any Drupal migration.

What can ComputerMinds do for you?

We, at ComputerMinds, have experience of all the different types of upgrade paths that are available to you. Back in the day, we conducted full Drupal 6 to Drupal 7 migrations (no easy feat), but more recently, we have done Drupal 7 to Drupal 8 upgrades (as we mentioned before, in addition to upgrading some of our clients from 7 to 8, we also carried out our own upgrade for this very site) and even Drupal 6 to Drupal 8 upgrades. So we have a wealth of experience and skill.

Furthermore, choosing to upgrade your site is the perfect time to review your current brand, the look and feel of your site and to add any new features that may be in your pipeline. Any new/additional changes are a lot easier to incorporate during the upgrade phase than later down the line; it’s cheaper because we can do all the changes in development phase and it’ll also mean you’ll get shiny, new things quicker - so something definitely worth thinking about.

This article has been written to highlight what options are available now and in the future; we certainly won’t force anyone to upgrade their site, but will always do our best to make people aware of what is coming up in terms of Drupal’s life. With the e-commerce world always advancing, you definitely can’t stand still for long, so this topic will certainly need to be thought about. We also won’t be able to facilitate upgrading everyone in 2021, so please do plan ahead!

Drupal 8 is in the best possible place today. Most of the contributed modules have either been converted from 7 to 8, or brand new modules that have been created in emulate functionality from Drupal 7 that simply didn’t exist for 8. The webform module for example, a staple on 99% of our sites, wasn’t available for a long time due to the time it took to completely rewrite it - a worthwhile wait in our eyes as it is a big improvement over its 7 version. We are currently recommending any new site builds that come our way to start life as a Drupal 8 site. It gets a big thumbs up from us!

If you’ve liked what you’ve read and feel like you’re ready - or in a position - to start thinking about a site upgrade, why not start a conversation with us today either by way of live chat or using our contact form. We’d love to hear from you and look forward to seeing what benefits we can bring to your site.

May 21 2019
May 21

QED42 has always been an ardent participant in the Drupal community. We pride ourselves for contributing to the Drupal community via modules, code patches, Drupal initiatives, DrupalCons, DrupalCamps or hosting Meetups!

Drupal Meetups play an integral role in fostering community. Dries Buytaert was quoted on Drupal.org’s getting involved page:

It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.

We hosted the Pune Drupal Group monthly meetup on 18th May 2019 at our office. The healthy turnout to the local meetup was a reflection of how connected the Pune Drupal Community was.

Packed with people, plenty of snacks, and laptops our Meetup commenced. After a brief introduction from all the attendees, the lights dimmed and Meena Bisht from QED42 started her session ‘ Be Ready for Drupal 9!’

Pune Drupal Group monthly meetup 2019

 

 

 

 

 

 

 

It was a highly interactive session that pivoted around Drupal’s ever-evolving nature. She spoke about how long Drupal 7 will be supported, Drupal 8 end of life, and how it would impact businesses. Drupal 8.7 features - Layout Builder and Media Library and challenges faced while moving from Drupal 7 to Drupal 8.

Pune Drupal Group monthly meetup 2019

We welcomed the newest member to the family, Drupal 9.

Pune Drupal Group monthly meetup 2019

The session also covered the Drupal release cycle, which justified the difficulties faced while moving to Drupal 8. We were relieved to know that upgrading to Drupal 9 would be a lot easier thanks to the minor upgrades.

The session shed light on why an upgrade is required, and what to expect out of Drupal 9. We ended the session with useful tips on tools for checking our deprecated code while preparing for Drupal 9.

Pune Drupal Group monthly meetup 2019

Post session, we discussed the hurdles faced during the earlier version releases, our inhibitions, and expectations from Drupal 9.

After a quick break with refreshments and offline chats, we gathered back for the BoF session on the configuration management system. We discussed the origin of configuration management, as a Drupal initiative, the different configuration issues faced by us and identified solutions.

Pune Drupal Group monthly meetup 2019

Lastly, we chalked out a map for the DrupalCamp Pune. All the attendees brought helpful ideas to the table, location, sessions, sponsorships, etc.

After an informative and super lucrative agenda of sessions, BoF, and DrupalCamp Pune planning, we wrapped up our Meetup.


 

May 21 2019
May 21

Three years ago, I started to talk about "coming to an agreement within the Drupal community and sponsoring a Webform feature." In that blog post, I discussed creating a reusable and free-to-use agreement template with a defined process which could make it easier for organizations to sponsor feature requests. Now I want to share my current process for handling sponsored feature requests to the Webform module for Drupal 8.

For the past three years, organizations have reached out to me for paid support and feature requests. Adding the ability to import submissions was a feature request paid for by Kennesaw State University. Only two parts of my transaction with Kennesaw State University were publicly visible, the issue on Drupal.org (#2902977) and a blog post.

Sharing my process for handling paid feature requests will hopefully clarify how organizations can sponsor a feature for the Webform module and other Drupal and Open Source projects.

Steps for sponsoring a feature

Sponsoring a feature can be broken down into four key steps:

  • Communication

  • Documentation

  • Agreement

  • Payment

Communication

Good communication is one of the keys to the success of any Open Source project. Currently, there are several approaches to initiating the communication process for a sponsored feature.

The easiest and most immediate way to start a sponsored feature request is to create a user account on Drupal.org and then create a feature request in the Webform's issue queue. This feature request becomes that starting point for documentation. The act of creating this ticket begins a discussion, via comments, involving those interested in sponsoring the work and the initial requirements.

Sometimes, organizations are not exactly sure what the scope of work needs to be and may want to reach out to one of the project's maintainers or contributors via Drupal Slack or email using the maintainer or contributor's Drupal.org contact form. When reaching out to a maintainer/contributor, it helps to have written requirements in advance, even if it is a single paragraph or a one-page summary of the problem/challenge.

BTW, I am referring to the person doing the work as a maintainer/contributor because sponsored features don't have to be limited to only a project's maintainer. Open source software development relies on the maintainer-to-contributor relationship. Maintainers and contributors are entitled to be compensated for their contributions.

Once a method of communication is established, a sponsor and maintainer/contributor can begin to document the problem(s) that the feature request is intended to solve, the proposed solution, and the scope of work, all using an issue on Drupal.org.

Documentation

Using Drupal.org's issue queue to document a sponsored feature request allows us to leverage the community's standards and best practices for managing issues. The Drupal community has worked together to define and continually improve how we communicate within our issue queues. Creating a good issue is essential for paid and unpaid contributions. The issue summary template provides us with a starting point for documenting a feature request.

Aside from leveraging the Drupal's community's existing issue queue to collaboratively define the scope of work, there is another bonus to this public process: Transparency. Transparency makes it easier for everyone to collaborate - it provides the opportunity for various interested parties to weigh-in on a feature request's problem and solution.

Realistically, potential sponsors might decide not to pay for a feature. This frequently happens in private responses to proposals. When a publically-defined feature request is rejected, we do not have to throw it away into a digital trash bin. The hard work and collaboration between a sponsor, maintainers, and contributors can sit in the issue queue and be marked as postponed or even closed. In the future, it is not uncommon that another interested party or organization will have the same or a similar feature request. An individual or organization could review the postponed or closed feature request and decide to sponsor it or do the work themselves; ultimately sponsoring the feature.

Optimistically, a sponsor will agree to the scope of work and request a cost estimate with a timeline and agreement.

With Open Source and Drupal, community collaboration is built on mutual trust and goodwill. This is reinforced by the GPL license. Further, once the stakeholders have communicated and documented the nature of the paid feature, once it is built there is an explicit understanding that it must be contributed directly back to its Open Source project. Therefore, the general protections from GPL remain inherently applicable. The GPL, along with transparency, helps us to overcome some of the challenges for coming to an agreement. Since the work is publically available, and ownership, intellectual property, and even confidentiality clauses are not needed for the signed agreement, this streamlines the legal process. All that is required for a signed agreement is the scope of work, timeline, and payment.

The simpler the terms are for an agreement, the more likely people are to sign it. I found the most straightforward approach is to paste the entire issue from Drupal.org into a Google Document, add a summary, estimated cost, notes, timeline, payment, and very basic sign-off. Here is an example of a basic template with an example issue.

This basic template makes some assumptions with limited legal protections for both parties, with a fair assumption that both the sponsor and maintainer/contributors are good citizens with good intent.

Good intent has made it easy for me to build a few sponsored features because frankly, I have limited the scope and cost of paid features to reduce risks. No one has not paid me for a sponsored feature, and so far the worst case possible scenario is that I don't get paid for a day or two of work. That all said, the work is at least contributed back to Open Source.

Nonetheless, we want to ensure that we are paid for the work. Any standardized agreement template needs to continually be reviewed and improved. Finding and paying for a professional review and recommendations for a reusable creative commons scope of work and agreement template could be a good use of the Webform module's Open Collective funds, which are intended to help sustain, support, and improve the code and community around the Webform module and Drupal.

I have found the most significant challenge and hurdle to getting paid by a client is going through their payment processing. Everyone has different workflows for processing and paying invoices. A common and recommended approach is to get 50% at the start of a project and 50% at the completion. This is the best way to build trust and reduce risk.

At sign-off to an agreement, a simple 50% invoice can be emailed and processed. Here is the invoice template that I am currently using for sponsored features.

How payment should be handled depends on the client and maintainer/contributor. There are two possible approaches for processing payments. The more traditional method is a direct payment from the sponsor to the maintainer/contribute. A more transparent approach would be to use the Webform module's Open Collective as an intermediary.

Using the Webform module's Open Collective as intermediary might make organizations feel more comfortable sponsoring a feature because the funds are being transparently exchanged. There is the inherent benefit to a public transaction, which is that it reinforces the need for trust and good faith between the sponsor and maintainer/contributor. Some of us, including myself, also cringe at the potential conflicts that can happen during a paid project, which could then be compounded by a public dispute.

The notion that "funds are being transparently exchanged" can feel awkward and also uncomfortable. We also should not dismiss the fact that Open Collective retains 14% of every transaction as overhead. Personally, I prefer private transactions via my personal S-corp in order to retain as much of the revenue from my work as possible. I have built a fair amount of trust in the Drupal community and organizations currently seem more comfortable paying an individual company vs. transferring funds to an Open Collective, which is a new and unknown entity. However, there are conditions where participants in a feature request may not know each other and the Open Collective method will be preferred by both parties.

Giving back to the community​

The fact that the process and result of a sponsored feature are immediately contributed back to the project benefits all parties involved, including the community. Making it possible for an Open Source developer to be paid for their time makes their contribution more sustainable. Still, Open Source projects require infrastructure and money to succeed.

The process for sponsored features via a project's issue queue does rely on Drupal.org's infrastructure. Shouldn't the Drupal Association, which is responsible for Drupal.org's infrastructure, benefit from this transaction? Should both participants in this transaction be members of the Drupal Association? Should a small percentage of this transaction be contributed back to the Drupal Association? How we take paid transactions and properly give a share back to the community is not so simple.

Ideally, we should insist that anyone sponsoring a feature join the Drupal Association and back the Webform module's Open Collective. One concern with this approach is that requiring people and organizations - especially those new to the Drupal community - to do something like register for and pay for organizational memberships can discourage them from getting involved. For now, we should nudge them to be good citizens and establish trust within their Open Source community by supporting the software and community that they rely on.

Addressing some hesitations and concerns​

Sponsoring a feature is a paradigm shift; feedback is always welcomed. As I have talked about sponsored features and Open Collective with people, they have expressed a reasonable concern that Open Source is meant to be "free". The word "Free" in Open Source is open to many interpretations and I want to share my interpretations and thoughts.

Open Source software was never meant to be free software that’s built by developers working for free. Many people and organizations are paid to contribute to Open Source. Most of these transactions are happening behind closed doors with varying approaches. Many open source projects need to be supported and funded to succeed. Open Source started out, and still, is an evolving experiment and collaboration continuing to change the world. There is nothing wrong with paying people to do good work, especially if companies are benefiting from the use of that open source software.

Making it possible for anyone to be paid to contribute to an open source project will remove barriers and diversify our community. My goal is to strengthen our community and to make our collaboration more sustainable.

How do we get started?

The first step is figuring what you might need and then creating an issue on Drupal.org. From there we can start working through the process of documenting your requirements, coming to an agreement, and processing a payment using and improving these templates.

If you want to take a much larger, bolder, and significant first step that earns trust and shows good will, please join the Drupal Association and back 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

May 21 2019
May 21

To keep up with consumer demand, businesses need to tactically rethink and reform the way they produce and manage content. 

What you need is a way to stand out in the consistent content chaos. To make that happen, you need a strategy that can help:

  • push out content intuitively
  • transform disorganized assets into a comprehensive manner
  • manage real-time collaboration effectively

And that’s where the role of a CMS is important.

Here’s a comprehensive guide to building the right content strategy with Drupal, focusing primarily on the technological aspect, which will help you build and establish the right notes with your audience.

You Need to Have a Content Strategy. But Why?

With an increase in the number of content dissemination channels, it is easy to lose consistency and easier to lose track of the larger goal.

“Pushing out content without being focused on the goal, its relevance, distribution, or the target audience is a waste of time and money – even if your content is amazing!”

The 2018 Demand Gen Report revealed that buyers are becoming more discerning and selective in the content they decide to consume. 88% agree that content producers need to focus less on product specifics and more on the value that can be brought to their business.

Infographic with three hexagons and text on it on a blue background

These key findings from the audience can be harnessed only with a well-designed content strategy. Which means by doing as little as creating a persona you get ahead of 58% of your competition (2018, CMI Report).

According to the same study, a whopping 97% of top performing B2B marketers have a content marketing strategy, while 32% of (overall) B2B marketers do not have a documented plan. In most cases, this means that they really have no clue what they’re doing.

Some of the benefits of a digital content strategy are:

  • Aligns your team with the organization’s mission/goals
  • Helps you figure out which types of content to develop and which will work
  • Keeps your team focused on priorities
  • Helps you allocate resources for better results
  • Clarifies your target audience/s

Building Content Strategy With Drupal

Traditionally, the content strategy involves planning, creation, and governance of content. However, with an explosion of channels and proliferation of new devices, content strategy can not be limited to just website content.

One of the challenges is to remain engaging yet relevant on different channels.

This can be solved by bringing uniformity and consistency across the various touch points from which a user can access information and engage with the content.

“The goal of the content strategy must be to strategically fit the reader into the marketing funnel”

Drupal’s dynamic features at the core make it a perfect fit to cater to the needs of creating great digital experiences. Here’s how:

Unifying the Content Strategy Across Channels with Drupal

Content Governance

Often neglected, content governance is a detailed framework of content delivery and management which ensures consistent brand storytelling across all media.

Implementing a content governance framework requires different users (from the same or different teams) to collaborate with a distinct workflow and audit trail effectively. In the face of exponential growth in the variety and volume of content,  Drupal helps manage, organize, and secure the content with Workflow and Staging. 

Since editing the content on live site can also result in accidental publishing, Drupal’s Workflow module provides a separate staging environment . Drupal has an easy staging and preview of content in different environments anchoring full content staging capabilities.

You can define multiple workspaces such as "staging" and "live" which are copies of your site, to create content (or modify) and the changes are visible only within that workspace. Once the changes have been verified, you can "deploy" the content to another workspace.

User, roles, and permission: Security is important and that is why not every user can have permission to access the system of the website. Drupal offers a number of security modules which help manage and secure backend access. 

With User Access Control, site administrators on Drupal can work to provide unique user experiences and different access rights to writers, editors, marketers, and site visitors.

The Workflow module helps in creating arbitrary workflows and assigning them to entities. That's  important from a security perspective too. Workflow with the states like Draft, Review and Published can be assigned to Story node type.

Thus, only the users with ‘Editor’ permissions can set stories to the published state.

Some of the other Drupal modules which can be used are:

  • Workbench Access module: helps in creating editorial access control. Admin can grant access to the users and their content which can be found at My Workbench on Homepage. It harnesses content-focused features in one unified user interface.
  • Domain Access module: allows you to share users, content, and configurations across a group of sites.

Enterprise-wide password control systems

Password security is even more crucial and needs the right kind of strategic perspective with strong policies.Default password management could be considered good, but of course, it can be improved. Here’re some of the Drupal security modules that can be used to provide additional controls for password management:

  1. Password Strength: provides realistic password strength measurement and server-side enforcement for Drupal sites using pattern-matching and entropy calculation.
  2. Password Policy: provides a way to enforce constraints which must be met before a user password change will be accepted.
  3. Restrict Password Change: Adds a new permission 'change other users password'. When the user_profile_form is loaded it checks to see if the current user has the proper permission or if they are editing their own account, otherwise, it removes the password change option.
  4. Login Security: Login Security module improves the security options in the login operation of a Drupal site. By default, Drupal introduces only basic access control denying IP access to the full content of the site.
  5. Shibboleth Authentication: Provides user authentication as well as some authorisation features.
  6. Flood Control: Add an administration interface for hidden flood control variables in Drupal 7, like the login attempt limiters and future hidden variables.
  7. Secure Login: Ensures that the user login and other forms are submitted securely via HTTPS, thus preventing passwords and other private user data from being transmitted in the clear.

Digital Asset Management System: An important part of the governance is business workflow and common identity, which is significant for the smooth functioning of marketing. The CMS needs to provide the ability as a solid repository while also able to modify uploaded digital assets.

It should give editors the ability to make iterative changes to assets to enable promotion of products and brand across channels and devices. Digital Asset Management (DAM) smartly strategizes the way enterprises handle their digital assets.

The Acquia DAM Connector can sync your digital assets with your Drupal website, allowing editors to seamlessly use content from within all the websites you maintain. In order to ensure that the site is using the latest version of an asset stored, it periodically syncs assets from Acquia DAM via a cron job.

It also empowers editors to select Acquia DAM assets directly through a media field or through the WYSIWYG integration. Further, it enables the user to view asset metadata directly in the entity browser without importing the asset and provides a usage report of assets within Drupal.

“In the digital landscape, the creation of digital assets in large numbers is almost inevitable.”

Backup: Writing content is an intensive exercise. And so you need to have a backup to save yourself in case the website system crashes or is hacked.

Backup and Migrate: Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. Backup and Migrate supports gzip, bzip and zip compression as well as automatic scheduled backups.

Content Modelling with Drupal

Before you start building the site it is important to consider your content as a whole and work out a model that will guide you and the user to smoothly navigate through the website.

It entails detailed definitions of each content type’s elements and their relationships to each other. It also helps to identify the organization’s requirements, develop relevant taxonomy that meets those requirements, and consider where the content blocks and fields should be allowed or required. 

Content modelling is a critical starting point for website content.

Drupal is an incredible CMS for building a content-rich website. Built on its entity system and the variety of field types, Drupal can support a wide range of content models.

At core, it is built on View which can help sort out the default taxonomy/term view however you want. Let’s you want a way to display a block with the X most recent posts of some particular type.

It can be used for anything that handles the display of views, and the core Views UI module permits you to create and edit them in the administrative interface. When you define views, you are interested in taking data from your website and displaying it to the user.

Breaking content types into fields, it allows you to build structured content as well.

Modules like Paragraphs and Stacks let you build rich and dynamic content.

Layout Builder, a stabilized module, in Drupal 8.7, empowers you to build layouts with ready-to-use multi-column layouts and Drupal blocks without the intervention of a developer.

It is unique since it can support multiple and different use cases from templated layouts applied to dozens of pieces of structured content, to designing custom one-off pages with unstructured content.

Here’s how it can be used in three different use cases:

  1. Layouts for templated content: The creation of ‘layout templates’ can be used for a specific content type. Example, blog posts.
  2. Customizations to templated layouts: Can customize the layout templates on a case-by-case basis. Example, to override the layout of a standardized product page.
  3. Custom pages: The creation of custom landing pages which are not in sync to any particular content type or structured content. Example, a single ‘About us’ page.

The Layout Builder is more powerful when used with Drupal's other out-of-the-box features such as revisioning, content moderation, and translations.

Omnichannel Content Strategy with Drupal

Users are always at the centre. Therefore, the content strategy needs to be as dynamic as your user experiences across different channels, if it is to succeed. Omnichannel content strategy is a way to unify the experience across all the channels and touchpoints.

Irrespective of how and where the content/ products are being first consumed at, complete consistency and unified experience is expected.

API First Publishing with Drupal

Drupal 8 is API-first which means, it can power ambitious applications of all kinds, from behind-the-scenes systems written in languages like Python, Java or Go to rendered experiences using the latest frontend frameworks, like React, Vue and Ember.

Content touchpoints are proliferating at a fast clip. You now have conversational UI, digital signage, medical and healthcare devices, and it lets you integrate with other systems, use your content anywhere, display it as you please. API-First Drupal is well positioned for entire digital ecosystems.

[embedded content]

The JSON:API module, which is also now in core with Drupal 8.7, is meant for creating high-performance APIs to expose Drupal data in JSON. It works by creating API endpoints and requires no configuration and the module instantly accesses all Drupal entities.

It not only provides a great authoring experience but also a powerful, standards-compliant, web service API to pull that content into JavaScript applications, digital kiosks, chatbots, voice assistants and more.

This makes it easier for Drupal’s core ecosystem, of web services responsible for third-party content and application, to integrate.

Mobile-first and Out of the Box Responsive

Accessibility via any device needs to be useable too. Drupal 8 has been designed with a mobile-first strategy. The responsive design ensures that content and layout are scaled based on the viewport size available.

With  Breakpoint and Responsive Image, out-of-the-box Drupal 8 ships with two modules that ensure mobile-first behaviour .

Responsive content needs to be modular and readable so readers can easily consume it.

Drupal for mobile lets you easily define different pieces of content for different devices. Each field in the backend can be uniquely styled and prioritized according to its content type.

Personalization with Drupal

No matter how good your content is, no one will bother to read it if it doesn’t talk to them, in their own language. Every content piece needs to communicate with your audience and increase the relevance of product proposition, by addressing their unique fears, needs and desires.

This orchestrates customer experience and drive engagement.

Personalization brings familiarity, which brings strength to customer loyalty to your brand, helps track demographics and behavioural patterns and convert an anonymous user into a potential customer.

Acquia Lift solves the challenges for digital teams, by bringing together content and user profile data from any source to personalize the customer journey in ways not previously possible. More than a headline swap or banner choice, Lift presents wholly targeted experiences based on broadly observed visitor behaviors as well as specific user preferences and interactions in real time with the very first engagement across any device or channel.

“And 81% of B2B Marketers (2018, CMI Report) believe that building a content strategy makes it easier to determine which types of content to develop.”

Drupal in Other Marketing Technology

New technologies like artificial intelligence (AI), machine learning, Augmented Reality (AR), Virtual Reality (VR) among others are reshaping how users consume content. It’s a big opportunity for companies to produce and recycle the same content through different channels and mediums. All the while keeping people engaged.

Virtual Reality

Immersive experiences created by virtual reality is the “Next Big Thing” happening. Virtual reality has seen a surge lately, with constantly emerging in Gartner Hype Cycle. While it is rapidly approaching a much more mature stage, in the enterprise sector, virtual reality has already lots of scenarios where it gets employed with success.

For instance, educational purposes. VR can enable a lot of more experiences that in reality are not possible or too dangerous.

Here’s a demo video of a high school student, Jordan who explores Massachusetts State University (a fictional university, built on Drupal) from the comfort of his couch. Jordan is able to take a virtual tour directly from the university's website.

[embedded content]

 
Augmented Reality

Another part of the futuristic technology, AR can be used to superimpose useful information in a shopping experience.

[embedded content]


The demonstration shown in this video displayed a shopper interacting with the AR application. The mobile application of Freshland Market (a fictional grocery store), built on Drupal 8, guided the shopper through her shopping list.

Wrapping Up

Often, it can be a virtual nightmare for content producers and marketers trying to find the right piece at the right time. Even so, if the content is all in one place, time-consuming complicated systems can mess up really bad.

Drupal 8 provides a perfect foundation for the incorporation of technologies to enable a smart strategy for your brand, content, and digital marketing needs. Your organization might be at infancy or already up with your content strategy, you can always reach out to our experts who can help you deliver quality results with personalized experiences.

May 21 2019
May 21

Images are one of the most widely used assets on the web and with all the right reasons, but they may cause a slow loading time of your website if not included in the right way. There are a lot of things you have to consider while preparing images for the web, and in this post we’ll take a look at what those things are and how Drupal 8 can help you make this process automatic.

Optimized Image

First of all, let’s look at what makes an image optimized for the web. Web as a media is in fact a lot simpler in quality demand opposed to print media but it does have its own specialties. The biggest challenge here is to get the best possible image quality with the smallest possible file size by adjusting image dimensions and quality while also being able to serve each screen type and size just the right image. This may seem a bit overwhelming at first, but keep reading because in this post I’m going to show you how to achieve that step by step using Drupal 8 core features. 

Adjusting Image Dimensions

Out of the box, Drupal offers a really great tool for optimizing images called Image styles. In general, image styles are used to control the size of displayed images, although you can also do other cool stuff with them, such as making images black and white. Drupal allows us to set different image styles which we can then use in different areas of the page.

For example, an Article content type can use a bigger image for a detail page and a smaller one for a teaser display, usually used in the Articles list page. The great thing about image styles is that you only need to set them once and it will automatically display the right image size every time, no matter what the size of the originally uploaded image is.

An image style can be set in the ‘Manage display’ section of the content type setup. By clicking on the gear icon on the image field, the setting will be shown where you can assign any of the previously configured image styles to this field. If the image style you wish to assign is not available, you can create a new one by clicking on the ‘Configure Image Styles’ next to the image style dropdown.

Configure image styles

This will take you to the Image Styles configuration page. Click on the ‘Add image style’ button. First of all, you’ll have to give a name to the new image style. You can choose whichever name you would like but it is recommended that you add image dimensions to it. 

After the name is set up, you can add different effects to the image style. A few effect options are given, but for our purposes, the two most important ones are:

  • Scale: this effect allows you to only specify the width or height of an image, and the one that is not given will be automatically set to keep the original image ratio.
  • Scale and crop: this effect scales an image, but it also crops it so that it always fits the given ratio.

Choose the effect you want for your image style, set the properties and save it. In the example below, I chose Scale effect and only specified a width of 970px (based on the design, I calculated that the image using this image style will never be wider than 970px), letting the height adjust to the original image ratio.

Create image styles

Now the only thing left to do is to assign the new image style to the image field. Go back to the ‘Manage Display’ section of your content type setup, click on the gear icon, choose the new image style and hit save.

To see how much effect image styles have on the actual file size and loading time, we need to do some testing. First of all, let’s see what happens when no image style is assigned to the image. For this example, I used an image with an original file size of 6.7MB, meaning it is way too big to be used on our website because it took 2.08s for this image to load.

No image style

The second test I ran is with image style assigned to the image. The results show great improvement of the file size, as well as loading time, because, using the same original image, the file size is now 956KB and it loads in only 487ms. 

Image style 970

This is all very exciting - but there’s one more question that needs to be answered: did we sacrifice any of the quality to achieve this result?

Image style 970 comparison

I took a screenshot of an image without image style (on the left side) and compared it to the screenshot of an image with image style (on the right side). I noticed that the quality is a bit lower on the scaled image.

The root of this problem, however, is not the image style per se. These tests and screenshots were taken on a MacBook Pro which has a retina display, meaning that one actual pixel of an image is seen as half of a pixel on this device, and this is why the image got upscaled, making it look a bit blurry. To test it out, I created a new image style that is twice as big (Image Scale 1940 x ...). Now we can see that the image using the new image style looks just as sharp as the original one. 

Image style 1940 comparison

This, however, opens up a new question for us. Which image should we use? The first one is smaller and looks great on normal displays but makes images a bit blurry on retina displays. The second one, on the other hand, looks great on all devices but is bigger than the first one. Luckily Drupal 8 has another tool that will help us get out of this dilemma, but before we take a look at what it is and how it works, let’s try to optimize those images of ours a bit more. 

Defining Image Quality

In the first part, we took care of adjusting the image size; but there’s one more thing we can control in order to get the file size smaller - adjust the image quality. Drupal 8 has a perfect tool for that and it is very simple to use.

All we have to do is go to the Admin > Configuration > Media > Image toolkit.
Here we can adjust the quality of the image. The best results are given if the number is between 60 and 80. In the example below, I set the number to 75. In order to see the changes on the previously uploaded pictures, we need to delete all ‘styles’ folder content in the Drupal directory.

Folders that need to be deleted are located in ‘sites/default/files/styles’. Delete everything in there but leave the styles folder. After that go to your Drupal site and clear cache (Configuration > Development > Performance). When the page reloads, all images that you have uploaded before will be regenerated and they will all have the specified image quality.

Now we’re ready to run some tests and see how much of an impact this has on the file size. The first test I ran was using the image style for retina (1940 x …). Before that, the image file size was 3.2MB.

Image style 1940 toolkit

This time around we can see that the file size dropped to 383KB which is a great improvement. Even better are the end results for the image using the smaller image style. Let’s take a look at this one as well. Remember that previously the file size of this image was 956KB.

Image style 970 toolkit

This time the file size is only 126KB and it loads in 35ms. The result is impressive but let’s see what this did to the actual image quality. Let’s keep in mind that these tests are run on MacBook Pro that has a retina display and therefore images need to be twice as big to be displayed as they would have to be on a regular screen. 

Image style 970 toolkit comparison

With the image quality set to 75 we can now really see the difference in the smaller image style. This image would look great on normal displays and the file size is just right but the image still doesn’t look so good on the retina screen. Using the bigger image style, however, we get a better result in the said case.

Image style 1940 toolkit comparison

The file size is now 383KB and the look is almost identical to the original image. Now we can say that images have the optimal file size if we compare them to the actual quality, but one problem still remains - we have two image styles, each one optimal for a different screen type.

Responsive Images

Nowadays we have to consider many things when we’re making a website and amongst them, different screen types and sizes are one of the most important ones. Responsive design has become a standard in today's web development practice and images are no exception. We don’t really need an image that is 970px wide on a mobile screen that is 500px wide, but we do need an image that is 1970px wide on a retina display of a screen that is 1000px wide.

As we can see in the examples above, it really does matter what we serve to what screen - and no, we do not need to load the biggest image on all screens so that the image would look nice and sharp. This would increase the loading time of our website and that is also something we don’t want. What we do need to do is play it smart - serve every screen type and size exactly what it needs to display an image in its best light. Again, lucky for us, Drupal 8 has just the right tool for that and that tool is called Responsive images.

Responsive images are a Drupal 8 core module, meaning that Drupal 8 already comes with it, all you have to do to use it is enable it. To do that, go to Admin > Extend, then search for the module and enable it. We have already talked about how to use this module in this blog post, so I will not go into too much detail here. I will, however, explain how to solve the dilemma with retina displays that we have previously encountered.

Following the instructions in the link above you should be able to change image styles (sizes) or even the entire image depending on the screen size - for example, a mobile display can use a different, smaller image than a laptop display.

This module, however, also lets us set a different image style according to the retina display value. There is one requirement though - the theme you are using needs to have those multipliers values defined in theme.breakpoints.yml file. If the multiplier of 2x is defined for each breakpoint, then you will see it in the backend as an option to which you can assign an image style to.

Retina settings

Here you can assign a retina image style for a specific breakpoint - making the image adjust to a screen size and display type. For the example above it would mean that on a laptop that is not retina, the browser would render an image with Image scale (970 x …) style, but on a laptop with retina display, it would render an image with Image scale (1940 x …), making it truly the optimal choice.

In case you’re wondering - there is no magic to it. This module uses a HTML5 picture tag to change the image src depending on the screen size and type. There is, however, a downside - some browsers, including IE, do not support this HTML5 tag which means you’ll have to use a picturefill solution.

Conclusion

In this post, we’ve taken quite a deep look into how to make image optimization automatic with Drupal 8 and how to successfully decrease an image file size from 6.7MB to as low as 126KB. If a website you’re building has a lot of images per page, then this optimizing process may lower the loading time, but it can still be above the average. If this is the case then I would advise some extra steps to solve the problem, and your best bet in this case would most definitely be to include lazy loading functionality to your website.

May 20 2019
May 20

The Drupal Community Working Group (CWG) consists of volunteers who help promote the health of the Drupal community; maintain and uphold the Drupal Code of Conduct; and act as an escalation point to help mediate conflict between community members.

In December of 2018, following extensive input and feedback from the community, the CWG proposed a new charter to Dries and the board of the Drupal Association. This new charter changed the oversight of the group from the project lead (Dries) to a three-person Review Panel consisting of the two community-elected members of the Drupal Association Board along with an independent representative from a different open source project who is appointed by the full Association Board. The new charter also included an expanded mandate to focus on proactive measures for community health. Dries supported these changes as did the Association Board.

An important next step following these changes was to fully appoint the CWG Review Committee. The Drupal Association worked in the first part of 2019 to identify candidates for the third party seat of this panel.

At DrupalCon Seattle we were pleased to announce that the Review Panel is fully staffed. The current members are now:

Suzanne Dergacheva

Member of the Drupal Association Board. Elected by the community to a two-year term in 2018, Suzanne is a community leader and co-founder of Evolving Web.

Ryan Szrama

Member of the Drupal Association Board. Elected by the community to a two-year term in 2017, Ryan is a longtime community member and contributor to Drupal, as well as the founder and CEO of Centarro.

Jono Bacon

Jono Bacon is an experienced community strategist, speaker, author, and podcaster —and has consulted with a number of proprietary and open source organizations on community strategy and culture. The third seat of the panel has a term set by the board of the Drupal Association upon appointment, typically lasting 2 years.

What is the role of the Review Panel?

The Review Panel's mandate includes approving the appointment of new members of the CWG and acting as the escalation point for Community Working Group issues. The CWG Review Panel serves as the final escalation point for CWG matters, though in exceptional cases where an issue may represent a significant concern to the whole project, the panel may escalate an issue to the full Drupal Association Board.

The Review Panel’s mandate only extends to issues that are appealed to it if one of the involved parties feels a decision of the CWG is unreasonable. The Review Panel is not responsible for reviewing decisions that take place outside of the CWG process (such as Drupal.org terms of service violations, DrupalCon Code of Conduct violations resolved directly by Association staff, or other issues that have been escalated to the full board of the Drupal Association). Requests to review those decisions must be referred to the party that made the decision.

The Review Panel is not involved in the CWG’s day-to-day activities; only matters that are brought to it as part of the appeals process, or at the discretion of the CWG. The Review Panel may, however, consult with the members of the Community Working Group to help them develop programs for proactively supporting community health.

How do the Drupal Association and the CWG work together?

Under its new charter, the CWG is able to draw upon the resources of the Drupal Association, including legal advice and protection. It is also better equipped to proactively address the needs of the Drupal community.

For example, at DrupalCon Seattle the CWG presented a workshop on developing strategies for effective and inclusive group communication with the help of funding from the Drupal Association. The CWG is also currently soliciting feedback from the community as it prepares to review and update the Drupal Code of Conduct.

These are among the first of what we hope will be many initiatives to promote the health and well-being of the Drupal community, and to enhance volunteer leadership skills and sustainability as we continue to help make the Drupal community one of the most compassionate, inclusive, and intentional communities in open source.

May 20 2019
May 20

We are on our journey to master the Drupal performance, after having our previous Part 1: Caching published a couple of weeks ago, we've been lucky enough to get into Issue 386 of TheWeeklyDrop newsletter, Planet Drupal, and got much love and good feedback on Twitter.

If you haven't already read the first part of the series, the ultimate guide for faster Drupal: Part 1 Caching, please feel free to read that article too.


Note: You don't necessarily have to do all of these, some items listed here are replaceable with each other as well, so proceed with caution!

Faster Drupal - Part 2: Aggregation and CDN

  • The one and the only holy grail: Advanced CSS/JS Aggregation
    On every Drupal optimization post you’d read you have to setup and configure AdvAgg module, but you gotta do what you gotta do!
    AdvAgg features and core benefits are listed on the module page completely, so go ahead and read them all, configure it the way that works best for you and move on
    Advanced CSS/JS Aggregation Drupal module

    Note: If you have Mod Pagespeed you might not need AdvAgg module, make sure that you don't overlap your own work

    But that’s not all, if you are on Drupal 7, you should consider checking Speedy module as well, in some areas, this might work a bit better so make sure to check it out as well
    Speedy module

  • For good JavaScript minification in Drupal, you can use modules such as minify but we’d like to recommend minifyJS instead, they listed the differences and benefits on their module page so check it out
    Drupal MinifyJS module

  • CDNize the whole project, as much as you can! You may use CDN module too

  • Move JavaScript to the footer if necessary, some JS files need to be rendered in the head based on the use case and what does the JS do! Also in Drupal 8, it’s quite easy to append your necessary library (Read it JS files) in the footer in twig template files

  • Consider if you can make your own scripts defer/async (a new challenge when it comes to Drupal js aggregation)

Okay, this round was much easier thanks to AdvAgg module for taking care of half of the things we need to do for us! Note that on the frontend side you can Uglify, Minify and make sure everything that you code, will become compressed, whether it’s CSS, JS or even images or SVG files! Now let's get to it, Image optimization. 

Image optimization

  • Drupal 8: Use the Responsive Image module wherever possible and create the appropriate styles. It uses the <picture> tag which is what we really want

  • One might say we have one too many image optimization modules in Drupal, which is a good thing! For that we tested some, experienced with some of them and here’s what we suggest: Use blazy and lazyload_images (Drupal 8 that uses IntersectionObserver instead of scrolling events), Also consider: lazyloader and image_lazy_loader when using the picture module for responsive images in Drupal 7. There is also a lazy loading option that works well

  • Image optimization: for main images/icons used in the design (Yes you can optimize SVG files as well), also the best tool for that is not in Drupal, try ImageOptim desktop app, Also there’s an API-based service available with a Drupal 7 module, take a look here, might worth setting/selling this up to clients

    Also in the same context, we can use ReSmush.it which is free (But should donate some beer to them)
    Drupal 7 Module, Drupal 8 Module

  • Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. There's a really good module that help you serve WebP, it's called, you guessed it; WebP.

  • Serve WebP images with your web server with the MOD PageSpeed by Google for Apache and Nginx.
    Or conditionally serving WebP images with Nginx.
     

Bonus tip: Even favicons should be optimized. Sometimes people ignore the weight of a favicon file. You shouldn’t! 

 

For the next week, we will be covering subjects regarding Drupal database/web server tweaks & improvements, stay tuned.

 

Written by Sohail LajevardiSohail Lajevardi
Developer at Ramsalt Lab

 

May 20 2019
May 20

When you’re surrounded by a team of awesome developers, you might think that a statement such as, “Great Websites are Created before the First Line of Code is Written,” isn’t going to be met with a lot of enthusiasm.

As it turns out, our developers tend to be among the greatest supporters of the kind of Human-Centered Design engagements that get all stakeholders on the same page and create a roadmap for transformative possibilities. 

The point of the above statement, which is also the title of a presentation that Promet’s Chris O’Donnell has been delivering at DrupalCamp events all over the country, is not to downplay the importance of the impeccable coding that makes great websites work. No one doubts that. Our point is that when web development is fueled from a foundation of: 

  • collaborative problem solving, 
  • elimination of  assumptions,
  • deeper knowledge transfer, 
  • empathy for users, 
  • early stakeholder alignment, and 
  • excitement about what’s possible,

everyone benefits and work is a lot more fun.

Getting it right at the start makes sense for a lot of reasons. Teams are happier and work proceeds with a higher degree of efficiency. At the same time, the impact on cost is a factor that is seldom acknowledged to the degree that it needs to be. Consider the following observation from noted software engineer Tom Gilb:

“Once a system is in development, correcting a problem costs 10 times as much as fixing the same problem in design (concept). If the system has been released, it costs 100 times as much…”

The Luma Institute graphic below powerfully illustrates the difference in the relative cost of getting it right in the concept phase, vs. fixing during the build phase, vs. fixing after release.

Pyramid that depicts the cost difference between getting software right during the concept phase vs. making a change during development vs. making a change once it has hit the market

Human Centered Design vs. Agile Development

Questions concerning “agility” frequently emerge in our conversations with clients, and offer an excellent opportunity to clarify some important issues. Human-Centered Design initiatives focused on getting it right, right from the start, are in no way at odds with the idea of agile development. 

The clear vision and collaborative energy that emerges from Human-Centered Design activities often helps to inform and enhance agile development. 

An all-to-common misunderstanding about agile development is that it’s about avoiding the discipline of an actual plan. Not true. Agile development is a real-world development methodology that does not close off the possibility for mid-course refinement. An agile plan plays out within a series of sprints. Each sprint is reviewed before moving on to the next one. If the review reveals an oversight or issue, it can be quickly addressed. 

Prioritization is key with Agile for sprint planning, and Human-Centered Design helps gain consensus on what is important.

The world’s most agile process, however, is up against an uphill battle in trying to reset the course of a project that was based on inadequate or faulty information from the start. Ensuring that projects get off to an excellent start is at the core of what Human-Centered Design is all about.

Going Wider, Digging Deeper 

The activities within a Human-Centered Design workshop continuously build upon knowledge collected and insights gained for purposes of:

  • Identifying stakeholders
  • Prioritizing stakeholders
  • Identifying strengths, problems, and opportunities in current system
  • Grouping strengths, problems and solutions within agreed-upon categories 
  • Identifying solutions 
  • Prioritizing solutions

Let’s take a look at a few components  of a Human Centered Design workshop.

Stakeholder Mapping

Stakeholder mapping results in what is essentially a network diagram of people involved with or impacted by the website. Typically, there are a lot more stakeholders than the obvious end users and stakeholder mapping evaluates all the possible users of a system to then identify the key target audiences and prioritize their needs and expectations. 
 
Stakeholder mapping is an excellent activity for:

  • Establishing consensus about the stakeholders,
  • Guiding plans for user research, and
  • Establishing an empathetic focus on people vs. technology.
An illustrated example of stakeholder mapping for a Drupal siteAn example of a stakeholder mapping exercise for Promet's upcoming web redesign illustrating people with an interest in the project.

Persona Development

The next step following stakeholder mapping is the creation of persona information in order to understand the range of differing needs from the site for purposes tailoring solutions accordingly. 
 
Defining the distinct personas for whom the website is being designed serves to clarify the mindset, needs and goals of the key stakeholders. Giving each persona group a name provides a quick reference of key stakeholders and serves as a constant anchor for conversations moving forward.

Drupal-Specific Rose-Thorn-Bud

Adopted from a Luma Institute collection of exercises, the goal of Rose-Thorn-Bud is to quickly gather a significant amount of data in response to a specific question or the current system in general. During a Rose-Thorn-Bud activity every individual’s opinion ranks equally as responses are gathered on colored Post-it Notes for labeling attributes as positive (rose), potential (bud), or problems (thorns).

The Post-It Notes are gathered and grouped on a white board according to identified categories. The collection and organization of large amounts of data in this manner serves to highlight prevalent themes and emergent issues, while facilitating discussion. 

During Chris O’Donnell’s “Great Websites are Created before the First Line of Code is Written” presentation at Drupaldelphia, attendees were invited to respond to the following problem statement: 

Drupal 8 as a viable CMS for small business / small organization needs.

Each participant was encouraged to contribute ideas to 10 Post-its -- within any of the three color categories. All of the contributions were then  “voted up” in order to poll attendees and achieve a level of consensus among the group. Results of that exercise can be found here

Drupal-Focused Statement Starter

Statement Starters are evocative phrases to ignite problem solving within teams and challenge teams to restate the problem from differing perspectives within a framework of “We could …” and “We will …” 
 
The way a statement starter is worded is important. It needs to be an open-ended question that requires more than a yes or no answer. Effective statement starters such as, “How might we…”, “In what ways might…”, “How to…”, and “What might be all the …” help to encourage the generation of explicit problem statements.
 
Conversely, closed-ended statement starters such as: “Should we…” and “Wouldn’t it be great if… tend to yield a yes or no answer” or less specific responses.

The statement starter presented to attendees at the Promet-led Drupaldelphia event, was:

How can we increase Drupal 8 adoption outside of the “enterprise” space?

Their responses are recorded here.

Importance / Difficulty Matrix

Inevitably, some of the ideas that emerge will spark excitement for the strategic leap forward that they could represent. The required time and resources to move forward with them, however, might exceed current capabilities. Other ideas might fall into the category of Low Hanging Fruit -- initiatives that can be achieved quickly and easily.

Plotting every idea on an Importance / Difficulty Matrix is an essential group activity that sparks conversation and accountability concerning Who, How, and When -- transforming good ideas into action items.

Illustration of an Importance/Difficulty Matrix


Why Human-Centered Design?

In the current environment, organizations tend to be defined by their digital presence. The stakes for getting it right are high and the margin for error is low. Optimizing ideas and perspectives at the outset, and continuing to iterate with feedback creates a strong foundation that serves as a superior foundation for web solutions that are capable of heavy lifting over the long haul. 

Interested in learning more about the possibilities for a Human-Centered Design workshop in your organization? Contact us today.

May 19 2019
May 19

While upgrading to the latest version is always part of the best practice, the process can be staggering.

Drupal 8.7 is already here and 9 will be released in a year, in June 2020.

Although a lot of discussion is happening around the upgrade and possibilities it brings along, the final product can only be as good as the process itself.

The good and important news is that moving from Drupal 8 to Drupal 9 should be really easy — radically easier than migrating from Drupal 7 to Drupal 8.

As a site owner, here’s what you need to know about the new release and what to take care of to make the process easier without many glitches.

The Drupal 9 Release and Timeline

The goal of Drupal 9 is to make it an easy upgrade as much as feasible from Drupal 8. Unlike most of the previous upgrades, D9 will be different in terms of:

  • Updates of dependencies to versions that stay supported.
  • Removal of our own code that we deprecated with removal before Drupal 9's release.

The new release will be a cleaned-up version of Drupal 8. Built on the same code base with deprecated code removed and third-party dependencies updated, Drupal 9 is not a reinvention of Drupal.

a horizontol table with Drupal versions

The next question is what happens to Drupal 7 and 8, then?

One of the major dependencies of Drupal 8 is on Symfony 3. Since Symfony 3 enters the end of life in November 2021, Drupal 8 support will be lifted around the same time. A long-term-support (LTS) minor release of Drupal 8 will be released alongside Drupal 9 and supported until November 2021.

No new features will be added to Drupal 8 and no new minor releases will be made available of Drupal 8. It will only receive patch releases after which.

Drupal 7 will also stop receiving community support after November 2021.

Data migration features in Drupal core to move from Drupal 7 to Drupal 9 will be active until then since they are required for a stable migration. 

The Upgrade and The Tips

The only caveat is that you need to manage is the "deprecated code". Here’s what you need to take note of, for an easiest upgrade experience to Drupal 9:

Text on left with a blue table in centre and left

  1. Keep Core Up-to-Date: As mentioned above, Drupal 9 is Drupal 8.9 - deprecated parts plus dependencies updated.

    If your site doesn't use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).

  2. Keep Modules Up-to-Date: Although Drupal 9 will not have new features (other than those provided by updated dependencies). While most modules will improve Drupal 9 compatibility, to ensure you don’t lose them in the upgrade, keep them updated.

    The key benefit of Drupal 9 over previous versions is that the platform will be supported with security fixes much later after support is lifted from 8. For contributed modules, the pace of Drupal 9 updates will depend on the module maintainers.

  3. Check Custom Codes for Deprecation: In case of any custom code on the site, you can use the deprecation checking and correction tools and fix issues locally. Tools you can use to check code depreciation:
    1. Drupal Check (read more her about PHP version compatibility check
    2. Rector (Read more about Rector here)

      Further, you can also use an IDE or code editor that understands deprecations (@deprecated annotations particularly) or Drupal 8’s branch of Upgrade Status for full site reporting.

What is Deprecated Code?

Deprecated code is referred to as the functions and API’s which are being replaced with new and better versions. In the journey from Drupal 8 from Drupal 9, you will experience API changes, with the new implementation is already present in core along with older one. We have to replace older code/API usage with the new.

Here is an example of the deprecated function:

* @deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. * Use \Drupal\Core\Messenger\MessengerInterface::addMessage() instead. */ function drupal_set_message($message = NULL, $type = 'status', $repeat = FALSE) { @trigger_error('drupal_set_message() is deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. Use \Drupal\Core\Messenger\MessengerInterface::addMessage() instead. See https://www.drupal.org/node/2774931', E_USER_DEPRECATED); $messenger = \Drupal::messenger(); if (isset($message)) { $messenger->addMessage($message, $type, $repeat); } return $messenger->all(); }

In above example the function drupal_set_message is deprecated and has to be replaced with:

\Drupal\Core\Messenger\MessengerInterface::addMessage()

Ways to Find and Fix Deprecated Code in your Drupal Project

As mentioned above , you can find and fix your deprecated code in the following ways:

  1. Drupal Check: It's a library developed by Matt Glaman. Check the git code here. For installation and usage, you can refer to the readme. 
    In case you want to install using Composer, prepare using composer global require mglaman/drupal-check. You can also read more about the composer check
    1. Get into your project/Drupal root directory
    2. Choose the module you want to check for deprecations
    3. Run drupal-check --help for help items. Here, I am using watchdog_prune module for demonstration.
      run : drupal-check -d watchdog_prune
      The output will be something similar to the image shared below:

      deprecated-code-1-srijan

    4. You will, now, have the report of deprecated code to fix.
    5. Let say it is giving us File src/Form/WatchdogPruneSettings.php containing issue : Call to deprecated function drupal_set_message(). In this case just navigate to the body of function as in this case drupal_set_message()

      You will notice that the the documentation under red box reads that the function is deprecated and what we need to do instead
       
       

      Now replace the current code with the recommendation and you are done.

  2. Drupal Upgrade Status Module: This module checks the list of projects you have installed and shows their availability for newer versions of Drupal core.
    1. Use the Upgrade Status module form
    2. Download and install module using composer: composer require drupal/upgrade_status
    3. Install the module and navigate to URL using admin user: /admin/reports/upgrade
    4. You can run a complete project/ individual module scan
    5. Fix the deprecated code in the same way as mentioned above.

Wrapping Up

Because Drupal 9 is an extended version of Drupal 8, for site owners, this means that it should be much easier to upgrade. But keeping custom codes and module updated needs to be meticulously planned.

Have questions around Drupal 9 upgrade and how it might impact your site? Experts at Srijan are all ears, connect with us to chalk out the right course to Drupal 9.

May 19 2019
May 19

Do try this at home!

Check out my repository on GitLab:

If you already have Lando installed, then all you have to do is

  1. Download the repository: git clone https://gitlab.com/benjifisher/lando-gatsby-drupal.git
  2. Change to the new directory: cd lando-gatsby-drupal
  3. Start Docker (on Mac or Windows).
  4. Start Lando: lando start

File a bug report or help with one of the existing issues!

,

Umami home page

In a few minutes you should have Drupal and Gatsby running together. Here is what the Drupal home page (using the Umami demo) looks like, at https://drupal.lgd.lndo.site/:

,

How Drupal works with Gatsby

There are a few ways to get Drupal to work with Gatsby. One way is to expose a JSON endpoint with all the information that Gatsby needs. With the release of Drupal 8.7.0, we can do this just by enabling the JSON:API module. Until that release, the JSON:API was available as a contrib module.

  1. Enable the JSON:API module in Drupal.
  2. Add the Drupal source plugin to Gatsby.
  3. Profit.
,

JSON:API

Here is what the JSON endpoint looks like, at https://drupal.lgd.lndo.site/jsonapi. I have a browser plugin that prettifies the JSON.

,

Gatsby home page

The home page of the standard Gatsby starter (nothing to do with Drupal) is at https://gatsbydrupal.lgd.lndo.site/:

,

Gatsby blog list

It is not much to look at, since there is no styling yet, but you can see that Gatsby is getting all the Articles from the Drupal site and listing them at http://gatsbydrupal.lgd.lndo.site/blog/:

,

Gatsby blog page

Follow a link, and you will see a similarly un-styled blog page, for example http://gatsbydrupal.lgd.lndo.site/blog/let-s-hear-it-for-carrots/:

,

GraphQL queries

You can also run Gatsby in “develop” mode: see the GitLab repo for instructions. Once you do that, you can explore the JSON feed the same way Gatsby does, using the GraphQL explorer at https://gatsby.lgd.lndo.site/___graphql:

,

Drupal and Gatsby configuration

The Drupal and Gatsby configuration are pretty standard. The drupal/ subdirectory has an installation based on the Composer template for Drupal projects.

The gatsby/ subdirectory has some code based on Ryan Bateman’s blog post.

,

Lando configuration

The fun part of this project is the way it configures Lando to run both sites. There are a couple of nginx configuration files, but the interesting part is the file .lando.yml:

name: lando-gatsby-drupal recipe: drupal8 config: via: nginx webroot: drupal/web php: 7.2 database: mariadb proxy: nodejs: - gatsby.lgd.lndo.site:8000 appserver_nginx: - drupal.lgd.lndo.site - gatsbydrupal.lgd.lndo.site services: appserver: build: - cd drupal && composer install run: - echo "Install Drupal with drush." - cd drupal/web && drush --yes site:install demo_umami --db-url=mysql://drupal8:[email protected]:3306/drupal8 --account-pass=admin --site-name='Drupal-Gatsby' - cd drupal/web && drush --yes pm:enable jsonapi - cd drupal/web && drush --yes pm:uninstall contact nodejs: type: node ssl: true globals: gatsby-cli: "2.5.12" yarn: "1.15.2" run: - echo "Installing Gatsby with yarn." - cd gatsby && yarn install appserver_nginx: type: nginx build_as_root: - cp /app/conf/nginx/drupal.lgd.lndo.site.conf /opt/bitnami/nginx/conf/vhosts/. - cp /app/conf/nginx/gatsbydrupal.lgd.lndo.site.conf /opt/bitnami/nginx/conf/vhosts/. events: post-start: - nodejs: echo "Building the Gatsby site from Drupal." - nodejs: cd gatsby && gatsby build - nodejs: rm -rf gatsbydrupal/* && cp -R gatsby/public/* gatsbydrupal tooling: npm: service: nodejs node: service: nodejs gatsby: service: nodejs yarn: service: nodejs ,

What's new?

Here are the minimal requirements to get this all to work together:

  • 2018-09-17: Gatsby 2.0.0
  • 2019-01-07: JSON:API module for Drupal 8.x-2.0
  • 2019-01-11: [email protected]
  • 2019-02-01: Lando v3.0.0-rc.2

All of these projects have more recent releases.

As I said before, the JSON:API module is now part of Drupal core, so consider 2019-05-01 (the release of Drupal 8.7.0) as part of that timeline.

May 18 2019
May 18

So I needed the latest git checkout of the source code from external entities Drupal module. Its latest is 8.x-2.x

Using composer require drupal/external_entities is not enough as that will download the latest released version in this case 8.x-2.0-alpha1

Using composer require drupal/external_entities:8.x-2.x is not a valid version for composer as Drupal versions are not semantic versioned.

We should use as version 2.x which is a Drupal 8 compatible branch . SemVer can work with dev versions using 2.x-dev so using composer require drupal/external_entities:2.x-dev we get the latest dev. But still as zip

By altering composer.json setting a preferred-install for the module we finally get the latest git checkout.

"config": {
    "preferred-install": {
        "drupal/external_entities": "source",
        "*": "dist"
    },
    "autoloader-suffix": "Drupal8"
}

After running ``composer require drupal/external_entities:2.x-dev` we get a git checkout but it is a detached head.

cd modules/contrib/external_entities
git status
HEAD detached at 809e275
nothing to commit, working tree clean

The final step is to do git checkout origin and you can create patches.

Refs

May 17 2019
May 17

Although web accessibility begins on a foundation built by content strategists, designers, and engineers, the buck does not stop there (or at site launch). Content marketers play a huge role in maintaining web accessibility standards as they publish new content over time.

“Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.” - W3

Why Accessibility Standards are Important to Marketers

Web accessibility standards are often thought to assist audiences who are affected by common disabilities like low vision/blindness, deafness, or limited dexterity. In addition to these audiences, web accessibility also benefits those with a temporary or situational disability. This could include someone who is nursing an injury, someone who is working from a coffee shop with slow wifi, or someone who is in a public space and doesn’t want to become a nuisance to others by playing audio out loud.

Accessibility relies on empathy and understanding of a wide range of user experiences. People perceive your content through different senses depending on their own needs and preferences. If someone isn’t physically seeing the blog post you wrote or can’t hear the audio of the podcast you published, that doesn’t mean you as a marketer don’t care about providing that information to that audience, it just means you need to adapt in the way you are delivering that information to that audience.

10 Tips for Publishing Accessible Content

These tips have been curated and compiled from a handful of different resources including the WCAG standards set forth by W3C, and our team of accessibility gurus at Palantir. All of the informing resources are linked in a handy list at the end of this post. 

1. Consider the type of content and provide meaningful text alternatives.

Text alternatives should help your audience understand the content and context of each image, video, or audio file. It also makes that information accessible to technology that cannot see or hear your content, like search engines (which translates to better SEO).

Icons to show image, audio, video

Types of text alternatives you can provide:

  • Images - Provide alternative text.
  • Audio - Provide transcripts.
  • Video - Provide captions and video descriptions in action.

This tip affects those situational use cases mentioned above as well. Think about the last time you sent out an email newsletter. If someone has images turned off on their email to preserve cellular data, you want to make sure your email still makes sense. Providing a text alternative means your reader still has all of the context they need to understand your email, even without that image.

2. Write proper alt text.

Alternative text or alt text is a brief text description that can be attributed to the HTML tag for an image on a web page. Alt text enables users who cannot see the images on a page to better understand your content. Screen readers and other assistive technology can’t interpret the meaning of an image without alt text.

With the addition of required alternative text, Drupal 8 has made it easier to build accessibility into your publishing workflow. However, content creators still need to be able to write effective alt text. Below I’ve listed a handful of things to consider when writing alt text for your content.

  • Be as descriptive and accurate as possible. Provide context. Especially if your image is serving a specific function, people who don’t see the image should have the same understanding as if they had.
  • If you’re sharing a chart or other data visualization, include that data in the alt text so people have all of the important information.
  • Avoid using “image of,” “picture of,” or something similar. It’s already assumed that the alt text is referencing an image, and you are losing precious character space (most screen readers cut off alt text at around 125 characters). The caveat to this is if you are describing a work of art, like a painting or illustration.
  • No spammy keyword stuffing. Alt text does help with SEO, but that’s not it’s primary purpose, so don’t abuse it. Find that happy medium between including all of the vital information and also including maybe one or two of those keywords you’re trying to target.
Illustration of red car with flames shooting out of the back, flying over line of cars on sunny roadway.Example of good alt text: “Red car in the sky.”
Example of better alt text: “Illustration of red car with flames shooting out of the back, flying over line of cars on sunny roadway.”

3. Establish a hierarchy.

Upside down pyramid split into three sections labeled high importance, medium importance, low importance

Accessibility is more than just making everything on a page available as text. It also affects the way you structure your content, and how you guide your users through a page. When drafting content, put the most important information first. Group similar content, and clearly separate different topics with headings. You want to make sure your ideas are organized in a logical way to improve scannability and encourage better understanding amongst your readers.

4. Use headings, lists, sections, and other structural elements to support your content hierarchy.

Users should be able to quickly assess what information is on a page and how it is organized. Using headings, subheadings and other structural elements helps establish hierarchy and makes web pages easily understandable by both the human eye and a screen reader. Also, when possible, opt for using lists over tables. Tables are ultimately more difficult for screen reader users to navigate.

If you’re curious to see how structured your content is, scan the URL using WAVE, an accessibility tool that allows you to see an outline of the structural elements on any web page. Using WAVE can help you better visualize how someone who is using assistive technologies might be viewing your page.

5. Write a descriptive title for every page.

This one is pretty straight forward. Users should be able to quickly assess the purpose of each page. Screen readers announce the page title when they load a web page, so writing a descriptive title helps those users make more informed page selections.

Page titles impact:

  • Users with low vision who need to be able to easily distinguish between pages
  • Users with cognitive disabilities, limited short-term memory, and reading disabilities.

6. Be intentional with your link text.

Write link text that makes each link’s purpose clear to the user. Links should provide info on where you will end up or what will happen if you click on that link. If someone is using a screen reader to tab through 3 links on a page that all read “click here,” that doesn’t really help them figure out what each link’s purpose is and ultimately decide which link they should click on.

Additional tips:

  • Any contextual information should directly precede links.
  • Don’t use urls as link text; they aren’t informative. A
  • void writing long paragraphs with multiple links. If you have multiple links to share on one topic, it’s better to write a short piece of text followed by a list of bulleted links.

EX: Use "Learn more about our new Federated Search application" not "Learn more".

7. Avoid using images of text in place of actual text.

The exact guideline set forth by W3 here is “Make it easier for users to see and hear content including separating foreground from background.” 

There are many reasons why this is a good practice that reach beyond accessibility implications. Using actual text helps with SEO, allows for on-page search ability for users, and creates the ability to highlight for copy/pasting. There are some exceptions that can be made if the image is essential to include (like a logo). Providing alt text also may be a solution for certain use cases.

8. Avoid idioms, jargon, abbreviations, and other nonliteral words.

The guideline set forth by W3 is to “make text content readable and understandable.” Accessibility aside, this is important for us marketers In the Drupal-world, because it’s really easy to include a plethora of jargon that your client audience might not be familiar with. So be accessible AND client-friendly, and if you have to use jargon or abbreviations, make sure you provide a definition of the word, link to the definition, or include an explanation of any abbreviations on first reference.

Think about it this way: if you are writing in terms people aren’t familiar with, how will they know to search for them? Plain language = better SEO.

9. Create clear content for your audience’s reading level.

For most Americans, the average reading level is a lower secondary education level. Even if you are marketing to a group of savvy individuals who are capable of understanding pretty complicated material, the truth is, most people are pressed for time and might become stressed if they have to read super complicated marketing materials. This is also important to keep in mind for people with cognitive disabilities, or reading disabilities, like dyslexia.

I know what you’re thinking, “but I am selling a complicated service.” If you need to include technical or complicated material to get your point across, then provide supplemental content such as an infographic or illustration, or a bulleted list of key points.

There are a number of tools online that you can use to determine the readability of your content, and WebAIM has a really great resource for guidelines on writing clearly.

10. Clearly label form input elements.

If you are in content marketing, chances are you have built a form or two in your time. No matter whether you’re creating those in Drupal or an external tool like Hubspot, you want to make sure you are labeling form fields clearly so that the user can understand how to complete the form. For example, expected data formats (such as day, month, year) are helpful. Also, required fields should be clearly marked. This is important for accessibility, but also then you as a marketer end up with better data.

Helpful Resources

Here are a few guides I've found useful in the quest to publish accessible content:

Accessibility Tools

May 17 2019
May 17

In my experience, a big part of making a Drupal 8 site usable for content editors is customizing the WYSIWYG, which usually includes adding a couple additional CKEditor plugins.

Of course, you can simply download the plugins into the 'libraries' folder, and that's fine. But these days, it's becoming best practice to pull in all of your site's dependencies using Composer.

Adding 'package' repositories to your composer.json for the CKEditor plugins (the current best practice) works fine - but only for your individual site.

It doesn't work so well if you want to install:

  • A Drupal "Feature" (like with the Features module) that configures the WYSIWYG, including adding some CKEditor plugins, or
  • A Drupal distribution (like Panopoly or Lightning)

In those cases, you can't depend on what the individual site may have in its top-level composer.json, and asking the user to manually copy-paste a bunch of 'package' repositories in there may create enough confusion or problems that potential users will just give up.

Well, I've got an possible solution to this problem: an experimental Composer repository which includes CKEditor plugins for use on a Drupal site.

It works better for Feature modules and distributions, but can also make life easier for individual sites too.

Read more to find out how it works and how to use it!

This all started with porting the Panopoly WYSIWYG (panopoly_wysiwyg) feature module to Drupal 8...

Panopoly WYSIWYG provides a highly usable (and re-usable!) WYSIWYG configuration, originally based on Wordpress's WYSIWYG. It's part of the Panopoly distribution, but can be used on vanilla Drupal sites, or in other distributions.

In order to work, it needs a number of CKEditor plugins. In the old world order, we used Drush .make files to pull in any necessary plugins, and this is how it still works for Drupal 7. However, with Drupal 8, this needs to be done via Composer.

We could put a requirement into panopoly_wysiwyg's composer.json, like:

    "require": {
        "drupal-ckeditor-plugin/colorbutton": "4.*"
    }

However, unless the user first added the necessary 'package' repository to their top-level composer.json, the installation will fail, because there isn't any package on Packagist called 'drupal-ckeditor-plugin/colorbutton'.

Adding those 'package' repositories would work, but it poses a number of problems...

For an individual site - nothing!

But there's a few issues for a reusable module:

  1. 'package' repository definitions are long and contain a lot of stuff. This may sound like a minor thing, but if you're asking your users to copy-paste something into their composer.json, the smaller and simpler the content can be, the harder it'll be to mess it up and lead to bad experiences and support requests. Panopoly WYSIWYG uses 6 plugins, and all the necessary 'package' repositories definitions amount to like 2 pages of text. :-)
  2. Different people may do them differently, either on purpose or accident. Since this would need to be defined in each and every site's composer.json, it can be made different. Maybe one site owner decides to pull in a different version of a plugin, or name it differently, or give it a different 'type' (to control where it goes in the code base). This creates inconsistency, which can, again, lead to bad experiences and support requests.
  3. We can't change them over time. If we find out that there was a better way to do the definition, well, then we have to tell everyone to go update their composer.json files in a specific way. Most people probably won't get the message, and it's another error prone step where the site owner could make a mistake.
  4. We can't add to them over time. Panopoly WYSIWYG currently uses 6 plugins - what if we want to add another? Well, 'composer update' will fail until the user adds the new 'package' repository to their composer.json.
  5. The plugin versions need to match the CKEditor version in Drupal core. Drupal core frequently updates the version of CKEditor in minor releases. For example, Drupal 8.6 uses CKEditor 4.10.1 and Drupal 8.7 uses CKeditor 4.11.3. If you're using a "core" CKEditor plugin (one that's bundled in the CKEditor source code) you should use the same version of the plugin as CKEditor. This means you need to update the versions in your 'package' repositories when updating to a new Drupal core minor, and creates challenges for a package like panopoly_wysiwyg that aims to work with either version.

So, in the context of a reusable feature or distribution, this is definitely not ideal.

A Composer repository is basically a remote collection of package definitions.

Packagist.org is the main Composer repository where package definitions are pulled from by default, but it's also possible to use additional repositories. For example, Drupal.org provides a Composer repository that includes all Drupal modules, themes, etc from Drupal.org.

Pointing your composer.json to an additional Composer repository, involves either (a) adding about 4 lines to your composer.json, or (b) running a single 'composer config' command.

It's easy to explain, simple to do, and hard to get wrong.

Also, since the the actual data is stored remotely, that means:

  1. Lots of people can share this same repository
  2. We can update it over time, adding or removing CKEditor plugins, or changing how they are defined
  3. We can add multiple versions of the same plugin with different requirements, for example, declaring which version of Drupal core they work with.

So, we created an experimental Composer repository with package definitions for CKEditor plugins, which is hosted on GitLab pages here:

https://panopoly.gitlab.io/drupal-ckeditor-plugins/

This is generated using satis, based on some simple configuration files stored in this GitLab repository:

https://gitlab.com/panopoly/drupal-ckeditor-plugins

Using GitLab CI, any time we commit a change to that repo, it'll regenerate the Composer repository. So, if you want to see any CKEditor plugins added or contribute to this project, please submit an MR to that project. :-)

So, while the idea for this came from wanting a better solution for Feature modules or distributions, it can also be used on an individual site to install CKEditor plugins, and it is easier than the old recommended way.

To add the repository, run this command:

composer config repositories.drupal-ckeditor-plugins composer https://panopoly.gitlab.io/drupal-ckeditor-plugins

And to install a CKEditor plugin - for example, the 'colorbutton' plugin - run this command:

composer require drupal-ckeditor-plugin/colorbutton:4.*

This will put the right plugin version for your version of Drupal core into your 'libraries' folder, and you didn't have to manually edit your composer.json at all.

And, if you update your Drupal core version, composer will know that you also need to update your CKEditor plugins to match.

To use with a Feature module or distribution, you need to do only two things:

  1. Add a requirement on a CKEditor plugin from the repository, like "drupal-ckeditor-plugin/colorbutton" (for the 'colorbutton' plugin, for example)
  2. Tell your users to run this command before installing your module or distribution:
composer config repositories.drupal-ckeditor-plugins composer https://panopoly.gitlab.io/drupal-ckeditor-plugins

Optionally, if you provide a Composer project template for starting new sites (like the panopoly-composer-template), you can add the repository to that composer.json, so that new users don't need to follow any steps at all!

Every time I've referred to this Composer repository above, I've called it "experimental".

This is because, while this seems to work, we haven't really used it in practice yet. After spending some weeks or months using this with real modules and sites, we may find out that there was a better solution.

So, while I really encourage you to try it out, please know that this is the early stages, and doesn't (yet) change any of the best practices.

However, I will say that I don't ever intend to take this down.

It's hosted on GitLab Pages, so as long as GitLab.com continues to exist, this Composer repository will also exist. So, if you start to depend on it, it isn't going to go away.

But, just a warning: at some point, it could become deprecated if a better solution to these problems is found.

Please let me know your thoughts in the comments below or in issues/MRs for the project on GitLab!

May 17 2019
May 17

Earlier this week, The Cut ran a piece about a “Tinder Hacker” who created a fake profile with his roommate’s photos, then hooked a piece of code up to the Tinder API and did some very simple string substitutions so that men who messaged “her”–after “she” swiped right on them–were tricked into actually talking to other men who did the same. In brief, he put strangers in contact with each other under false pretenses, rerouted and surveilled their communications without consent, and proceeded to use this as a bragging point on dates and in interviews.

One might take exception to a number of elements of this story, but let’s start with its terminology. “Hacking” is a word whose meaning has broadened beyond all practical use, but in no sense did “Sean”, the pseudonymous subject of the story, “hack Tinder.” He relied on someone else’s reverse engineering to write some buggy code that ran against its API. That’s all.

The article itself seems confused about whether the Tinder API, or Application Program Interface, only exists to allow homebrew apps on Windows Phone. But an API is just a set of commands made available by a server, like the Tinder mothership, to accept instructions from client apps, like the many copies of the Tinder app that run on all kinds of phones. Almost all the apps on your phone are clients that work this way, and APIs are ubiquitous. Even the Drupal and Wordpress sites we build each have their own versions.

The code described in the article fits less within the definition of a hack than that of a bot. It would live on a server, persist as a service, wait for triggers–like incoming messages–and then respond to them according to certain rules. Some bots are used for automated customer service; some are used for art projects; some are used for jokes. Many, many, many bots are used for spam or other malicious purposes.

The ethics of bot development are not always simple, but they’re not new territory either. That’s the second and most glaring exception to be taken here: Sean’s assertion that his bot was at the “gray hat” level of malice in terms of its exploitation of code. Bot creator and Portland local Darius Kazemi wrote a thoughtful piece about considering and refining the possibility space of joke bots toward kindness in 2015. That in turn references fellow creator Leonard Richardson’s seminal 2013 post “Bots Should Punch Up”, which contains a telling bit with regard to the color of that hat:

“Hackers and comedians and artists are always attracted to the grey areas. But your bot is an extension of your will, and if you're a white guy like me, most of the grey areas are not grey in your favor.”

Perhaps it’s assuming too much to conclude that Sean, a San Francisco programmer whose race is not mentioned in the article, is a white guy. Perhaps not. Technology as a field in the US is overwhelmingly full of white men, offering most of the benefits of the biggest wealth creation engine in history to the people who were already granted our society’s highest levels of privilege. That privilege, and power, means that thoughtless choices have more potential to do harm: by default, they’re punching down.

But even if that weren’t the case, as an educated and socialized human adult, it shouldn’t have been hard to see that writing a service solely to entice, deceive, manipulate and mock people in a vulnerable space like a dating app might have consequences. That is, unless you’ve spent a career being rewarded for ignoring consequences, because you work in tech. That’s the third exception to be taken. For pulling a prank like this, many people would be fired or sued. Instead, Sean got a better job.

I can admit that this story struck me on a personal level. Back before I had to quit Twitter, I used to write bots using their API myself. One of them, which I created in 2014, worked on a similar principle to the Tinder bot: it would receive a person’s message, put it in holding, and send them back a random held message from someone else in response. The juxtapositions were surreal, delightful, and often rewarding. And everyone involved was informed, consenting, and able to make use of built-in safety tools to report bad actors.

I’m not an ethicist or a researcher by training, but I knew to consider those aspects of my work because I have an interest in the history of the internet. According to the article, Sean does too–I’m willing to bet he and I read the same books about phone phreaks, blue boxes and Captain Crunch.

The phreakers he admires, by the way, were indeed “punching up” with their pranks–using low-rent tools to get one back at Bell, an exploitative tech monopoly that would eventually be broken up. Hey, there’s an idea.

People have made infamously bad choices like Sean’s before, and one might expect creators here in the future to work at avoiding their repetition. But instead, his story reflects the broader attitude of a tech sector that is not just ahistorical, but willfully naive and ignorant of the lessons of its past. (If you only read one thing linked in this whole piece, make it that last one. Go ahead, I’ll wait.)

The things I value about working at ThinkShout stand in opposition to all of that. My colleagues here are technical experts, but they’re also widely read, deeply informed, and always working to expand our collective view of the world in inclusive and considerate ways. That’s why we take pride in supporting progressive organizations like the Campaign Legal Center and ChangeLab Solutions. That’s why we focus on accessibility for all users as a core concern and increasing equity in our own job pipeline. That’s why we’re fine with being located far outside the insular centers of big tech culture, where it seems like people would rather try to land on the Moon than make change on the ground.

Even if the article in The Cut highlights the deep problems in the technology sphere that engulfs us all, there are certainly worse things on the internet than a man getting his kicks by trolling a bunch of other men. But there are better things too. If you’d prefer to join us on that side, please get in touch! We’re hiring, and we’d be glad to hear about how your hobby project brought a little kindness and empathy to the world.

Get In Touch

Questions? Comments? We want to know! Drop us a line and let’s start talking.

Learn More Get In Touch
May 16 2019
May 16

One of the best things about Drupal’s open-source ecosystem is that it empowers you to be open-minded. Given the vast array of solutions and modules available, users can customize their site to their whims. Alternatively, if you think up and code something new, your contributions can be shared online with other users. With all of the customization available, Drupal is a conducive platform for outside-the-box thinking.

federated search

Decoupling is a recent example of this philosophy. Where a standard Drupal website would feature a Drupal-powered front and backend, decoupling opens the door for a variety of possibilities. A decoupled site can utilize different platforms and technologies for both the front and backend. For example, a decoupled site could utilize Drupal’s backend CMS while running a React-powered frontend. Such is Drupal’s flexibility that it can power scores of different, user-facing channels from a single backend, including other sites, native apps, Internet of Things (IoT), and more.

This decoupled or “headless” concept has more applications than just for site design, though. The search function of a website, for one, can benefit from components that utilize this headless approach – and not a moment too soon. As Google has begun to sunset its Google Search Appliance offering, there is now a need for an open and flexible search tool with enterprise-level capabilities.

At this year’s Midwest Drupal Camp, the team from Palantir demonstrated that a decoupled approach to site search was viable. This solution, federated search, allows for indexing and searching across multiple sites. For organizations with a large web portfolio across different platforms, this open federated search solution can fill the gap left by Google.

Decoupled Drupal Facts & Myths

Understanding why federated search for Drupal is important requires an understanding of how regular site search functions operate. At the core, the search feature is built from three different components: the source, index and results. The source simply refers to all of the searchable content on a given site, from blogs to landing pages. The index is a compilation of metadata that makes the content form the source easier to parse. At Duo, we often use Apache Solr, a platform-agnostic, open source solution for indexing, as it provides speed, power and its own server capabilities. Finally, the results refers to the front-end experience that compiles and delivers the search results to the user.

The above setup will work fine for most simple websites, but larger organizations often require a more robust solution. With federated search, users can query across multiple sites across different platforms without placing much strain on Drupal, since Apache Solr is handling generating the index and providing results. This is accomplished through some tweaking of the basic site search formula.

Part of what makes this search so powerful is that it takes advantage of Drupal’s backend without relying on its frontend. For that, Apache Solr’s dedicated servers empower this new search solution by shouldering the burden of indexing and providing the results. Before it can work, though, some configuration is needed. Based on this configuration, Apache Solr can encompass searches across different sites – including sites that aren’t built with Drupal. Creating this custom solution, in conjunction with the Search API and Search API Solr modules, will ensure that the different data types being indexed will be standardized.  

As for the results section, the best approach is a decoupled one. Building out the front-end component in the React JavaScript library allows for robust searches without slowing down the rest of the site. By using Drupal’s CMS, Apache Solr and React’s power in coordination, any organization can create a search feature that quickly indexes vast ranges of data and delivers it in an easily digestible manner. For a deeper dive, Palantir has made their demo of federated search available.

This powerful and streamlined take on site search has a variety of applications. Before releasing the solution, Palantir originally developed federated search for the University of Michigan, as each department ran their own sites on different platforms. Federated search now allows users to seamlessly search for information across the entire school’s network, regardless of the technology used to deliver the content. Beyond university ecosystems, federated search also presents an opportunity for eCommerce. Using this solution, products from different vendors can be consolidated into a simple search.

Thanks to Drupal being open source, organizations can utilize federated search and any other contributed solution at any time. This level of openness is what makes Duo such champions of the Drupal platform. At Duo, we’re committed to exploring new features like this and helping each of our partners think outside the box. If you’re ready to start rethinking your website or sites, we’re just a click away.

Explore Duo

May 16 2019
May 16

“..an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.”

Calling accessibility as one of Drupal's core values and principles, the Drupal community has always stood to comply with web accessibility standards. Although with an absence of hard and fast rules to adhere to, the community has faced backlash in recent times.

First, with adopting Gutenberg (editor) and second with the release of Layout Builder, there have been some important questions and concerns about accessibility in the community.

This Global Accessibility Awareness Day, an awareness day to focus on digital access and inclusion for the more than one billion people with disabilities and impairments, let's take a look at how close is Drupal to its commitment towards web accessibility.

The Accessibility Controversy

a black and white design with G written in centreIn 2018, with WordPress 5.0 prepared to be released, the Gutenberg editor, a decoupled React based editing experience, was out for testing. Among other concerns like inconsistent user interface behaviour, difficulties with keyboard navigation through blocks ( far too heavily reliant on hover-based functionality), complexity to use it, the assessors were quick to call it inaccessible.

Drupal’s adoption of Gutenberg, got it in the fallout.

In another instance, when Drupal 8.5 released Layout Builder, the lack of accessibility in the feature brought the community into the topic of debate - how strongly does Drupal commit to accessibility?

How Does Drupal Ensure Web Accessibility?

Accessibility is about promoting inclusion than benefitting a small set of people with disabilities. It is about ensuring equal and inclusive access to the web resources, for the widest possible audience, without any bias.

And this has been reiterated in the Web Content Accessibility Guidelines (WCAG), that explains how web content can be made more accessible to people.

Drupal, in its Values and Principles, effectively lays down their commitment towards creating software which conforms to the accessibility guidelines. It conforms to the World Wide Web Consortium (W3C) guidelines which address:

  • Authoring tools, as part of the Authoring Tool Accessibility Guidelines (ATAG 2.0)
  • Web content, as part of the Web Content Accessibility Guidelines (WCAG 2.0)

As a result, it can be used both by developers as well as the site visitors.

Drupal has its own accessibility team, which helps identify the barriers occurring at the code level and the awareness level, and also resolves them. A number of such issues in the core have been identified and resolved, while also creating awareness within the community.

Some of these improvements included: Search engine form and presentation, drag and drop, color contrast, image handling, form labelling and so on.

Accessibility for developers is another added feature in Drupal, and through D7AX, it is an easy job to find contributed modules and themes which also support the development of accessible websites.

Let’s take a deeper dive into the key modules and features of Drupal that help overcome web compatibility issues, and ensure easier web accessibility:

Key Modules

Automatic Alt text It automatically generates an alternative text for images when no alt text has been provided by the user.  Block ARIA Landmark Roles  It adds additional elements to the block configuration forms that allow users to assign an ARIA landmark role to a block.  CKEditor Abbreviation  It adds a button to CKEditor which helps in inserting and editing abbreviations in a given text.  CKEditor Accessibility Checker  It enables the Accessibility Checker plugin in your WYSIWYG editor, which then helps inspect the content accessibility level; and solve them.  High Contrast  It allows the user to quickly switch between the active theme and a high contrast version of it.  htmLawed  It utilizes the htmLawed PHP library to limit and filter HTML for consistency with site administrator policy and standards and for security.  Style Switcher  Themers can provide a theme with alternate stylesheets. Allowing special styling for some part of the site, the module presents all those styles as a block with links. So any site user is able to choose the style of the site he/she prefers.  Text Resize  It provides the end-users with a block for changing the font size of text on your Drupal site.  Accessibility  It gives a list of available Accessibility tests, aligned to guidelines like WCAG 2.0 or Section 508.


Key Features:

  1. Semantics in the Core

Drupal has been built to encourage and support the proper use of semantic markup. Thus composing semantically correct HTML informs the browser and the assistive technology about the type of content it is managing with, and how this relates to other content.

This helps the assistive technologies carry out its activity effortlessly since they now have a structure to work with.

 2. Aural Alerts

Drupal provides a method called “Drupal.announce()” which helps make page updates obvious, in a non-visual manner. This method creates an aria-live element on the page.

 3. Controlled Tab Order

Drupal’s TabbingManager is an awesome medium to direct both non-visual and non-mouse users on the page, to access the prime elements in a logical order. And thus permits more control while exploring complex UIs.

 4. Accessible Inline Form Errors

Drupal forms are now more open to the expansion of available inline form errors. So now, it is easier for everyone to identify what errors made while filling in a web form.

 5. Fieldsets

Fieldset labels are utilized as systems for gathering related segments of forms. When effectively implemented, these labels give visual diagrams around the shape field gathering.

Presently, Drupal uses fieldsets for radios & checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal.

What was the Outcome of the Controversy?

As always, the community has stood by accessibility as one of the core tenets. In a blog, Drupal's commitment to accessibility, Dries Buytaert - Drupal Founder - writes on the issue and how seriously the community takes the commitment to accessibility.

With that said, he announced that the Layout Builder functionality would be in a "stable" state for production use after ensuring that it passes the accessibility gate (Level AA conformance with WCAG and ATAG). This holds for both the authoring tool itself, as well as the markup that it generates.

With accessibility maintaining team, it has been jointly agreed that:

  • The first priority is WCAG 2.0 AA conformance. This means that in order to be released as a stable system, the Layout Builder must reach Level AA conformance with WCAG. Without WCAG 2.0 AA conformance, a stable version of Layout Builder won’t be released. This happened with a stable release of Layout Builder in 8.7.
  • The next priority is WCAG 2.1 AA conformance. Because these guidelines are still new (formally approved in June 2018), the stable version of Layout Builder won’t be held on them but are committed to implementing them as quickly as possible, even if some of the items are after the initial release.
  • While WCAG AAA conformance is not something currently being pursued, there are aspects of AAA that we are discussing adopting in the future. For example, the new 2.1 AAA "Animations from Interactions", which can be framed as an achievable design constraint: anywhere an animation is used, it will be ensured that the designs are understandable/operable for those who cannot or choose not to use animations.

The commitment to this ideal, by the leadership at Drupal and by the larger community, has remained steadfast despite challenges. The announcement and commitment to conform to AA level has reinstated the faith in the community towards its values.  

Ready to build digital experiences that are truly great for your customers - frictionless, accessible, and inclusive? Drop us a line, and our Drupal experts will be in touch.

May 16 2019
May 16

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.

We're very happy we got to speak with Tim Lehnen, the interim Executive Director of the Drupal Association. Tim is honored to be serving the Drupal community for the past 5 years and is looking forward to how Drupal will evolve alongside digital innovations. Read on to revisit a touching moment from a past DrupalCon and find out more about some of the Association's notable recent accomplishments. 

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

My name is Tim Lehnen, and I'm the interim Executive Director for the Drupal Association. Prior to that I was the Director of Engineering for the Association. The board has just recently announced that we've appointed a new executive director - so I'll be happy to be returning to my role on the engineering team in June. 

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

I first found Drupal in around 2006, around the time of the Drupal 4.7.0 release. At that time I was a student building websites as a freelancer to help pay for my education. I didn't know all that much about open source communities and collaboration at the time, and my early career actually diverged from Drupal quite a bit. However, even during that time I observed and admired the community the Drupal project had built.

In 2014 when I saw that the Drupal Association was hiring, I jumped at the opportunity to come home. Being able to engage with such a passionate (and compassionate) open source community has been very rewarding - and being able to do it for a living is a humbling privilege. 

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

Having spent just about the last 5 years working full time to serve the Drupal community there are many, many moments I could point to. 

In particular, though, I'd like to highlight the #DrupalThanks campaign at DrupalCon Baltimore, where one of our partners and sponsors EvolvingWeb chose to use their sponsorship time at the keynote not for commercial promotion, but instead to give flowers to DrupalCon attendees to present to anyone else in the community that had made an impact on them and say 'Thank you.' 

It's all too easy to get caught up in what is difficult and hard about the work we do, and moments like these are wonderful reminders why it is worth it. 

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

I echo the words of project founder Dries Buytaert. Drupal is a platform for ambitious digital experiences. That doesn't mean it's only for enterprise, or only for large end users. If you are a scrappy non-profit or start-up or really anyone with an ambitious idea for your digital presence - ambitious means you! 

And yes, this means websites, but increasingly it also means other kinds of digital experiences like voice-assistant interfaces, kiosks and information displays, in-flight entertainment - and even AR and VR experiences. 

On the flip-side, Drupal is not a platform for simple blogging or brochure-ware. If your needs are simple, a less sophisticated platform might serve you well. But when you're really trying to make a mark in the digital space, Drupal is your best choice. 

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

I feel that Drupal will continue to hone in on its strengths - its highly engaged and expert community, the quality of its underlying architecture, and its pivot towards web services and decoupled architecture. 

Drupal is years ahead of other solutions when it comes to robust omnichannel and decoupled solutions - and as our digital interaction models evolve further and further away from traditional keyboards and screens, I think we'll see Drupal evolve to be used in ways that couldn't have been predicted when Dries first built the platform in his dorm room 18 years ago. 

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

I've never been more than a mediocre developer, but I've always tried to find ways to contribute my project management skills. My team at the Drupal Association is the best in the world, and together we've done some amazing things for the community. 

I'm particularly proud of the team's work to create the Drupal contribution credit system. It's an industry first in open source, and as far as I know we're still one of the only open source communities that allows our contributors to attribute their work as a volunteer, sponsored by an organization, or on behalf of a client customer. It's given us tremendous insight into the lifecycle of contribution for the Drupal project. 

I'm also very proud of the team's recent work to move the Git tooling for the Drupal project to GitLab. I think that's going to enable a lot of new collaboration tools and reduce friction for contributors to Drupal. 

As far as my own independent contributions, I was very happy to work on defining the JSON feed for the Open Demographics Initiative, to support our work to improve representation on Drupal.org user profiles. 

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

There are few initiatives I'd love to give a shout out to: 

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

I'm an avid geek when it comes to virtual reality and augmented reality. I think I have four or five different headsets right now. The ability to actually inhabit a virtual world and feel present in it is something I've dreamed about since childhood.

At the same time, it feels like a very dystopian technology, and I can see how people perceive it as being yet another layer of technological isolation and alienation. On the other hand, it also has tremendous potential to help people who might be otherwise unable to travel or even leave their homes take part in new experiences, both solo and socially. 

We'll have to see where it goes! As with every new technology I imagine we'll have to take the bad with the good. 
 

May 16 2019
May 16

We are on our journey to master the Drupal performance, after having our previous Part 1: Caching published a couple of weeks ago, we've been lucky enough to get into Issue 386 of TheWeeklyDrop newsletter, Planet Drupal, and got much love and good feedback on Twitter.

If you haven't already read the first part of the series, the ultimate guide for faster Drupal: Part 1 Caching, please feel free to read that article too.


Note: You don't necessarily have to do all of these, some items listed here are replaceable with each other as well, so proceed with caution!

Faster Drupal - Part 2: Aggregation and CDN

  • The one and the only holy grail: Advanced CSS/JS Aggregation
    Ok I know on every Drupal optimization post you’d read you have to setup and configure AdvAgg module, but you gotta do what you gotta do!
    AdvAgg features and core benefits are listed on the module page completely, so go ahead and read them all, configure it the way that works best for you and move on
    Advanced CSS/JS Aggregation Drupal module

    Note: If you have Mod Pagespeed you might not need AdvAgg module, make sure that you don't overlap your own work

    But that’s not all, if you are on Drupal 7, you should consider checking Speedy module as well, in some areas, this might work a bit better so make sure to check it out as well
    Speedy module

  • For good JavaScript minification in Drupal, you can use modules such as minify but we’d like to recommend minifyJS instead, they listed the differences and benefits on their module page so check it out
    Drupal MinifyJS module

  • CDNize the whole project, as much as you can! You may use CDN module too

  • Move JavaScript to the footer if necessary, some JS files need to be rendered in the head based on the use case and what does the JS do! Also in Drupal 8, it’s quite easy to append your necessary library (Read it JS files) in the footer in twig template files

  • Consider if you can make your own scripts defer/async (a new challenge when it comes to Drupal js aggregation)

Okay, this round was much easier thanks to AdvAgg module for taking care of half of the things we need to do for us! Note that on the frontend side you can Uglify, Minify and make sure everything that you code, will become compressed, whether it’s CSS, JS or even images or SVG files! Now let's get to it, Image optimization. 

Image optimization

  • Drupal 8: Use the Responsive Image module wherever possible and create the appropriate styles. It uses the <picture> tag which is what we really want

  • One might say we have one too many image optimization modules in Drupal, which is a good thing! For that we tested some, experienced with some of them and here’s what we suggest: Use blazy and lazyload_images (Drupal 8 that uses IntersectionObserver instead of scrolling events), Also consider: lazyloader and image_lazy_loader when using the picture module for responsive images in Drupal 7. There is also a lazy loading option that works well

  • Image optimization: for main images/icons used in the design (Yes you can optimize SVG files as well), also the best tool for that is not in Drupal, try ImageOptim desktop app, Also there’s an API-based service available with a Drupal 7 module, take a look here, might worth setting/selling this up to clients

    Also in the same context, we can use ReSmush.it which is free (But should donate some beer to them)
    Drupal 7 Module, Drupal 8 Module

  • Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. There's a really good module that help you serve WebP, it's called, you guessed it; WebP.

  • Serve WebP images with your web server with the MOD PageSpeed by Google for Apache and Nginx.
    Or conditionally serving WebP images with Nginx.
     

Bonus tip: Even favicons should be optimized, sometimes people ignore the weight of a favicon file, You shouldn’t! 

 

For the next week, we will be covering subjects regarding Drupal database/web server tweaks & improvements, stay tuned.

 

Written by Sohail LajevardiSohail Lajevardi
Developer at Ramsalt Lab

 

May 16 2019
May 16

“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”
        - Margaret Mead

Today marks the 8th annual Global Accessibility Awareness Day.

GAAD was inspired by a blog post written in November 2011 by Joe Devon, a Los Angeles based web developer who was frustrated about an overall lack of awareness about accessibility. He called for a day devoted to building a more inclusive digital world. 

About six months later, on May 9, 2012, the first Global Accessibility Awareness Day occurred with about a dozen virtual and in-person events. 

Today, there will be hundreds of GAAD 2019 events celebrated in every corner of the world. 

It’s wonderful that digital accessibility is inching it’s way into mainstream thinking, but too often, the time and resources associated with making sites and apps accessible is viewed as a burden -- a legal requirement that would gladly be avoided, if possible. The fact is, expanding digital accessibility represents a profound opportunity to take a more expansive, empathetic, and inclusive view of our world and that always leads to good.

Into the Light

Digital accessibility is emerging from a code-related "have-to" that happens behind the scenes. We need to talk about it more and see it as an opportunity. 

We are living in a digital world that shuts out or limits the ability to engage for an estimated 15 percent of the population -- customers, constituents, audiences. 

This translate into business. The disabled represent $490 billion in buying power. And millennials, who value inclusivity and social responsibility more than any generation that preceded them represent $3.28 trillion in buying power. 

Once we get it -- that ensuring digital accessibility is not only a legal requirement, it’s the smart thing to do and the right thing to do -- our passion for accessibility moves up several notches. And just as accessible ramps at entrances to public buildings serve far more than the wheelchair bound, it’s helpful to understand that accessibility is not just for the “disabled.”  Let’s consider some ways that accessibility modifications make digital experiences more engaging and flexible for people of all abilities.

  • Logical layouts and engaging designs are not just pleasant to look at. Any user can get annoyed when needed information is difficult to find and interactions are complicated, but users who have cognitive difficulties or limited computer skills can be frustrated beyond all measure. Be sure to evaluate the user experience from multiple perspectives and angles. 
  • Adequate color contrast is essential for enabling users with a wide range of visual impairments, such as color blindness, to read, navigate, or interact with a site. Low-contrast sensitivity becomes more common with age, but good contrast also ensures accessibility in low-lighting conditions and for users who could be experiencing any number of temporary visual challenges. 
  • Video captions are, of course, essential to enable the hearing impaired to understand the meaning of a video. They also enable videos to be accessible to viewers who are in particularly loud environments, or in settings where silence is required. 
  • Alternate text for photos makes a site more accessible for the visually impaired. It can also bring additional context and clarity to digital experiences.
  • Technology that converts text to speech is viewed as a requirement for the visually impaired. It’s also helpful for dyslexic users, people who prefer not to read, as well as people who want to multi-task. Coding websites and apps to convert text to speech has the added benefit of helping search engines to detect content.
  • Customizable text capabilities enable users to adjust the size spacing and color or text without loss of function or clarity. There are a wide range of visual impairments that make small text unreadable, and difficulties in reading small type inevitable accompany the aging process for everyone. 
  • Clear language is key to accessibility. Industry jargon and acronyms always need to be explained. Run-on sentences and paragraphs can frustrate users of all abilities and in particular those who have cognitive impairments or learning disabilities. In the current environment, there is no patience or inclination for unraveling complicated text. 

This is a lay person’s look at digital accessibility -- an issue in our modern world that’s inherently tied to the common good. 

Do you agree? Join the conversation and let us know how you have discovered digital accessibility to be a means to broaden outreach and build bridges.   

May 16 2019
May 16

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

Configuration Schema

Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'
    mail_address:
      type: string
      label: 'Contact mail address to show to blocked users'
    dblog:
      type: boolean
      label: 'Log blocked access attempts'
    allow_role_bypass:
      type: boolean
      label: 'Allow IP blocking to be bypassed by roles'
    bypass_action:
      type: string
      label: 'Action to perform for blocked users when bypassing by role is enabled'
    white_black_list:
      type: integer
      label: 'Whether to use a path whitelist, blacklist, or check all pages'
    country_white_black_list:
      type: integer
      label: 'Whether to use a whitelist, blacklist, or neither for countries'
    country_list:
      type: string
      label: 'A colon separated list of countries that should be white/black listed'

The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

The values can be retrieved from the restrict_ip.settings object as follows:

$enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
$mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
$log = \Drupal::config('restrict_ip.settings')->get('dblog');

Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

Default configuration values

If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

enable: false
mail_address: ''
dblog: false
allow_role_bypass: false
bypass_action: 'provide_link_login_page'
white_black_list: 0
country_white_black_list: 0
country_list: ''

 

As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

Debugging Configuration

When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

The Configuration Inspector module errors in configuration schema definitions

Clicking on 'List' for items with errors will give more details as to the error.

The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

Summary

In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

May 15 2019
May 15

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

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

We have an hour to chat so bring your best Drupal topics and let's do this thing!

Some examples to get your mind firing: how do I recreate [feature] on my Drupal 7 site in Drupal 8? I need to explain [complicated thing] to a non-technical stakeholder -- any advice? How can I get Drupal and my CRM to play nicely?

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

View notes of previous months' calls.

May 15 2019
May 15

Acquia acquires Mautic

Recently, Acquia has acquired Mautic, an open source marketing automation platform. With this acquisition, Acquia is planning on disrupting the market and its closed technology stack competitors in the automation market. Acquia is a leading provider of digital experience solutions based on open source software Drupal. Now, Acquia product offering will be complemented by the newly acquired automation and campaign management platform, further adding more value proposition to the solutions offered by Acquia. This will provide marketers with a seamless experience, from designing and managing websites, to managing and tweaking communication campaigns across different platforms and digital channels. It seems that Acquia is dead set on making the future of marketing open source.

Here at Sooperthemes we're very excited about this move, because we've been interested in Mautic's development from the beginning and are looking forward to a closer Drupal integration.

Marketing automation is an emerging term in the marketing community. It promises solutions to age-old challenges that marketers face in their daily jobs. But what exactly is marketing automation?

What is marketing automation?

Marketing automation refers to software that aims to automate repetitive tasks. For example marketing involves a lot of repetitive tasks such as qualifying leads, emailing, social media posting and other editorial actions. Marketing automation helps to reduce the workload and makes it easier to bring those tasks to completion in a fast and efficient way.

Reasons for using marketing automation

Marketers can use automation paired with inbound marketing to increase the amount of qualified leads. Furthermore, it is easier to drive qualified leads through the sales funnel. Qualified leads have a lower churn rate than unqualified ones. Moreover, when it comes to nurturing these leads, it can involve loads of mundane tasks, which takes time and is inefficient. However, by using marketing automation, it frees precious time for the marketer to be able to undertake more strategic tasks.

Comparison of marketing automation software

HubSpot, Marketo, Pardot and Mautic are major players in the marketing automation market. In this article, there is going to be presented a comparison between the 4 automation platforms.

HubSpot

Hubspot Screenshot

HubSpot is a sales and marketing automation platform that is an all-rounder right out of the box. Out of the box, HubSpot is checking all the requirements for the most common tasks. Furthermore, it has unrivaled training, support and content. It also offers an easy to use interface for marketers, which is easy to use for even the most non-tech savvy of employees. A drawback of using HubSpot is that the contract is for at least 12 months, essentially locking up the customers to use the product. Furthermore, the pricing is also based on contacts, which can increase steeply. On top of that it also has some social media limitation when posting or tagging.

Marketo

Marketo Screenshot

Marketo is the marketing automation solution from Adobe. It was acquired by Adobe in October 2019. Marketo has a starting price of $895 per month. It is a great mid-range solution for companies which require a robust solution but don’t want to spend more than necessary. As its drawbacks, it has a poor landing page and form builder. On top of that, it has limited reporting and analysis functionality. Furthermore, there are steep increases in prices for just some added features.

Pardot

Pardot Screenshot

Pardot is the marketing automation and lead management solution from Salesforce. It has a starting price of $1250 for the most basic package. It allows marketing and sales teams to create and deploy online marketing campaigns in an easy and intuitive way. On top of that, Pardot brings the power to visually test the campaigns that are built, from the perspective of the client. On top of that, with the power of automation and segmentation, Pardot brings the power of smart lead management and generation to the table. Essentially giving the user the capability to nurture a lead based on different triggers that are activated during his customer journey on your website. Drawbacks of the platform include the fact that it lacks the tools for social media management. Furthermore, for A/B testing, user have to get the PRO subscription starting at 2000$ per month that is billed annually.

Mautic

Mautic Screenshot

Mautic has recently been acquired by Aqcuia. The goal here is to deliver the first ever open source marketing cloud to the market. Mautic is an open source software with that has self hosting capabilities. What this means is that companies that are using it, will not have to outsource the servers from the software providing company. This gives the users an increased sense of security, since the data will not be stored on different servers other than their own. On top of that, being open source, the code is available for everyone to see. This means that people have the flexibility to contribute and adapt the code to best suit their business or personal needs. On top of that, Mautic has a great degree of integration, making it easy to integrate with different content management systems such as Drupal, WordPress, Joomla, TYPO3, etc.

One drawback that Mautic encounters is the fact that the installation process can be tricky for a person that is not working in the IT department. This coupled with the fact that Mautic does not have the best available documentation to guide the user to the process, can result in a frustrating experience.

Here is a visual comparison of the features provided by each platform:

Features

HubSpot

Marketo

Pardot

Mautic

Starting price

$200/month

$895/month

$1000/month

Free

Lead scoring

Yes

Yes

Yes

Yes

Lead segmentation

Yes

Yes

Yes

Yes

SMS marketing

Yes

Yes

No

Yes

Personalize web content

Yes

Yes

Yes

Yes

Predictive analytics

Yes

Yes

Yes

No

Event management

Yes

Yes

Yes

Yes

Sales reports

Yes

Yes

Yes

Yes

Bi-directional CRM syncing

Yes

Yes

Yes

No

Create invoices

Yes

No

No

No

Split testing

Yes

Yes

Yes

Yes

Social CRM

Yes

Yes

Yes

Yes

Future-proofing Marketing

Given the fact that the forecast for the marketing automation market is going to grow and reach $32.6 billion by 2024, it’s safe to say that marketing automation is a growing trend. What this means is that more and more companies will start adopting marketing automation means in order to better and more efficiently fulfill daunting marketing task. Now, with the knowledge of the most important players in the field, you have taken the first step towards an automated future.

May 15 2019
May 15

The Drupal Event Organizers Group had a very productive DrupalCon Seattle (look for a blog post soon) and is taking the momentum from our in-person meetings to keep the initiative moving forward. Our next step is to create an official charter (similar to that of the CWG) to solidify our mission, process, and membership.

To that end, the Event Organizers Group is putting out a call for members of our Formation Board. This small group will be tasked with drafting a charter, reviewing it with the larger group, and then getting approval from Dries, the Drupal Project Lead, within the next few months.

We have representation from the US, and our immediate need is for members across the globe. If you're passionate about event organizing in your area and would like to be involved, please reach out to Avi Schwab on the Event Organizers Slack. We'll be having meetings at least bi-monthly and working asynchronously between them to develop the charter. We're committed to ensuring global accessibility, and as such will be alternating meeting times across the globe.

May 15 2019
May 15

There are Drupal modules loved by both developers and content editors. One of them is Layout Builder. It allows to create page layout templates of various complexity via a handy drag-and-drop interface. The chance to do it with a built-in user-friendly tool is among best Drupal 8 benefits.

So we celebrate the news that Layout Builder in Drupal 8.7 core has become stable, which means it is officially ready for production sites. Let’s take a closer look at layout creation with this tool.

Layout Builder in Drupal 8 core: stable and feature-rich

Up to this moment, Layout Builder has gone a great path from an experimental module in Drupal 8.5 core. After a number of significant improvements and fixes related to keyboard accessibility, permission granularity, layout storage, translations, usability, and more, we now see Layout Builder in Drupal 8.7 core as a stable module.

Layout creation functionality is also found in popular contributed modules like Panels, Panelizer, Paragraphs, and Display Suite. Layout Builder inherits the best practices from them, and resembles them in many ways, while staying unique. So let’s review this intuitively understandable and powerful module has to offer.

Main features of Layout Builder

Layout Builder works with fieldable Drupal entities like content, users, comments, taxonomy, and so on. This “Lego box” allows you to:

  • compose the page layout with predefined sections
  • populate the sections with blocks that are various Drupal elements
  • configure each block
  • drag and drop the blocks to rearrange them

and much more.

The module can be used for these scenarios:

  • creating a layout for all entities of a certain type (e.g. all blog posts)
  • creating different layouts for different display modes (e.g. blog post’s teasers)
  • overriding the layout just for one entity of a type (e.g. just one blog post)
  • creating a layout for an individual entity (e.g. one landing page)

The last point deserves a special note. As Drupal creator Dries Buytaert wrote in his article “Why Layout Builder is so powerful and unique,” many of competing CMSs don’t offer a templated approach to layout creation from the browser. They only allow layouts for individual pages — in other cases developer input is needed. Drupal’s Layout Builder allows to do both from the UI, and this really makes Drupal stand out!

A tour on layout creation with Layout Builder

Let’s now have a look at how to create a simple layout with Layout Builder in Drupal 8.7.

1) Enabling the necessary modules

The layout creation story starts with enabling the stable Layout Builder and Layout Discovery modules in Drupal 8 core. 

enabling layout builder and layout discovery modules drupal core
2) Enabling Layout Builder for a content type

We want to create a template for all items of a content type. In our case, this is the “Tour” content type.

tour content type drupal8

In Structure — Content types — Tour, we select the “Manage display,” check “Use Layout Builder,” and click “Save.” 

enabling layout builder for drupal8 content type


Note: If we wanted to make each content item individually customizable, we would also check the other option “Allow each content item to have its Layout customized."

We no longer see content type fields, but no worries — they will be available in the Layout Builder UI where we now move by clicking “Manage Layout.”

manage layout of content type drupal8
3) Composing our Layout with sections

Once moved, we can already see some sections made of existing “Tour” content type fields. We can use these or add new sections for 1, 2, 3, or 4 number of columns by clicking “Add section.” We can also add a couple of sections if we want to combine them vertically.

сompose layout with sections drupal8

When choosing the section, we can set the width proportion of its columns.

set column width layout builder drupal 8

4) Populating the Layout sections with blocks

Each section can be populated with blocks. These are not (or not only) Drupal blocks in the usual meaning — these are actually all Drupal website elements that are the building bricks for our Layout.

By clicking “Add block”, we see our content fields, lists (views), users, user fields, forms, menus, system elements, and so on. Blocks can be found by name. Custom blocks can also be created.

We have chosen a two-column section and we would like it to have the following blocks:

  • “Tour” image, “Tour” body, as well as Footer block for contacts (in the left column)
  • The “Venice stories” View that we have prepared (in the right column)

adding blocks to layout sections drupal 8

5) Configuring the Layout blocks

The familiar quick edit pencil above each block offers us to configure, move, or remove it. By choosing to configure, we see a configuration tray to the right. It has options according to the formatters that the block already has. For example, we can select the image style for our Tour image or hide the label in the “Venice stories” block.

configuring layout blocks drupal8

6) Brushing up the Layout structure

The blocks are draggable throughout the layout if we want to rearrange them. We then look through the page to see if it only has the needed sections and blocks, and remove the extra ones.

7) Saving the Layout and viewing our content

When we are done, there is no forgetting to click “Save layout” and then we can go and see how our content looks in our new template.

layout builder drupal 8 example

Get attractive Drupal 8 layouts!

We can all enjoy great opportunities for layout creation with the stable Layout Builder in Drupal 8.7 core. In our today’s example, we have just touched the tip of the iceberg of its capabilities.

Ask our Drupal development team to create magnetically attractive layouts for your Drupal 8 website. And let your users enjoy working with your site and your conversions grow!

May 15 2019
May 15

Drupalcamp Spain 2019 took place last week in the beautiful city of Conil, in the South of Spain. We had not only great weather, food, company… but also great sessions! This year’s schedule also included the Spanish Splash Awards, Business Day and even a side-event for those accompanying attendees, called Family in Drupal, where they did activities such as yoga, surfing, horse-riding, etc.

Drupalcamp Spain was a great gathering of people from not only Spain but many other countries. In fact, they offered two separate tracks, one in Spanish and one in English. As usual, it was difficult to choose which sessions to attend, but I think I got a really good mix and enjoyed them all thoroughly.

It’s also worth mentioning the registration bag that included a (very discreet) T-shirt, a bottle of wine (so my wife would be okay with me leaving her with the kids), a bottle of olive oil, some local tuna (Conil is a fishing town) and some other goodies.

Conil

I especially enjoyed the Friday afternoon English-track, which was “all about decoupled”. We saw an example of a project which started as a Drupal commerce site with some React components, which eventually became an app built in React native, integrating seamlessly with Drupal via GraphQL.

That was the perfect introduction to my talk, which was up next, about “GraphQL and Twig”, where I went through the whole process of installing, configuring and using GraphQL queries in your Twig templates, as a way of soft-decoupling some parts of your site. You can view the slides here: https://slides.com/fjgarlin/graphql-twig-drupalcamp-spain-2019.

Presentation

Fran

I was very glad to see that my session seemed interesting and useful to attendees and I enjoyed getting to answer some questions right after the session and the following day. People were surprised about how easy it is to get up and running and how powerful this combination can be as well. The closing session on Friday afternoon was about Drupal + GatsbyJS, showing how easy it is to connect those two technologies and doing a live demo about it.

Group photoGroup photo - Jorge Caspio

Saturday was also loaded with interesting content, and I ended up going to sessions on topics ranging from QA, SEO, UX, Migrations, Continuous Integration, Content architecture… that’s a good mix for a day, isn’t it? The speakers were really engaging and I must say that I learned a lot on that day. I also enjoyed learning how other agencies work, how we all face similar problems and solve them in different (or sometimes similar) ways. It’s always refreshing to listen to other people's experiences. I must say that most of these learnings happened in-between sessions, chatting and walking around Conil, etc.

I want to give a big, big thanks to all the people who made this event possible: organizers (Ruben Tejeiro, 1xInternet, Drupal association Spain), speakers, photographer (Jorge Carpio), volunteers and attendees from all over.

Looking forward to next year’s edition, ¡muchas gracias por todo!

May 15 2019
May 15

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, and Part 2 describes how the API works, and Part 3 explains how to use functionality provided by core, so they are worth a read before beginning this article. 

Read-only configuration

In some situations, site builders may want to prevent any configuration changes from being made on the production environment, preventing changes that may cause unexpected issues. For example, clients with admin access could log into the production server, and make what they think is an innocent configuration change, that results in unexpected and drastic consequences. Some site builders consider it to be a best practice to prevent configuration changes on the production server altogether, under the idea that only content should be editable on the production server, and configuration changes should only be made in development and/or staging environments before being tested and pushed to production.

The Config Readonly module, allows for configuration changes through the UI to be disabled on a given environment. It does this by disabling the submit buttons on configuration pages. The module also disables configuration changes using Drush and Drupal console.

A configuration form that has been disabled with the Configuration Readonly module

Note: some configuration forms may still be enabled when using this  module. Module developers must build their forms by extending ConfigFormBase for the Configuration Readonly module to do its magic. If the developer has built the form using other means, the form will not be disabled, and the configuration for that form can be changed through the admin UI.

To set up an environment as read-only, add the following line to settings.php, then enable the module:

$settings['config_readonly'] = TRUE;

After an environment is set as read-only, changes to configuration can only be made on other environments, then migrated and imported into the active configuration on the read-only environment.

Complete split (blacklist) configuration

Sometimes configuration needs to exist on some environments, but not exist in other environments. For example, development modules, like the Devel module, or UI modules like Views UI (Drupal core) and Menu UI (Drupal core) should not be enabled on production environments, as they add overhead to the server while being unnecessary since the production server should not be used for development.

A problem arises when configuration is exported from one environment, and imported into the production environment. All the configuration from the source environment is now the active configuration on the production environment. So any development modules that were enabled on the source environment are now enabled on the production environment. In the case of development modules like Devel, this may only add some overhead to the server, but imagine a module like the Shield module, which sets up environments to require a username and password before even accessing the site. If this module is accidentally enabled upon import on production, it will block the site from public access - a disaster!

The solution to this situation is to blacklist configuration. Blacklisted configuration is blacklisted (removed) from configuration upon export. This functionality is provided by the Configuration Split module. This module allows for black-listing configuration either by module, by individual configuration key(s), and/or by wildcard.

Note that more detailed directions for creating blacklists can be found on the documentation page. The following is meant to give an overview of how black lists work.

Blacklists are created as part of a configuration profile. Configuration profiles allow for 'splitting' (a divergence in) configuration between environments. Profiles may be created for environment types such development, staging and production allowing for configuration specific to those types of environments. Or profiles could be set up for public non-production environments, that would have the Shield module enabled and configured. While a development profile may apply to all development environments, not all development environments are on publicly accessible URLs, and therefore may not need the Shield module enabled.

When setting up a configuration profile, note that the folder name must be the same as the machine_name of the profile.

Configuration split profile settings

Note that you must manually create the folder specified above, and that folder can and should be tracked using Git, so it can be use on any environment that enables the profile.

Configuration can then be set up to be blacklisted either by module, by configuration key, or by wildcard:

Complete split (blacklist) can be set by module, configuration key, or by wildcard

Finally, environments need to be set up to use a given profile. This is handled by adding the following line to settings.php on the environment:

$config['config_split.config_split.PROFILEMACHINENAME']['status'] = TRUE;

Where PROFILEMACHINENAME is the machine_name from the profile you created.

Although blacklisted configuration does not become part of the exported archive, it is not ignored altogether. When an environment has the profile enabled, upon export, blacklisted configuration is extracted, then written to the folder specified in the profile. The remaining configuration is written to the default configuration directory. When importing configuration, environments with the profile enabled will first retrieve the configuration from the default configuration directory, then apply any configuration from the folder specified in the profile. Environments not set up to use the profile ignore the configuration in the blacklisted directory altogether on both import and export.

This means that a developer can enable the Devel module on their local environment, blacklist it, then export their configuration. The blacklisted configuration never becomes part of the default configuration, and therefore the module will not accidentally be installed on environments with the configuration profile enabled.

Conditional split (grey list) configuration

Grey lists, also provided by the Configuration Split module, allow for configuration to differ by environment. With a blacklist (previous section), the configuration only exists in the active database configuration for environments that are set up to use the configuration profile containing the blacklisted configuration. With a grey list, the configuration exists in the active configuration in all environments, but the configuration profiles can be set up to allow environments to use differing values for the configuration.

Imagine an integration with a remote API requiring a username, password, and endpoint URL. The production server needs integrate with the remote API's production instance, while other environments will integrate with the remote API's sandbox instance. As such, the values to be used will differ by environment:

Production Environment:

remoteapi.username: ProductionUsername
remoteapi.password: ProductionPassword
remoteapi.endpoint: https://example.com/api

Other Environments:

remoteapi.username: SandboxUsername
remoteapi.password: SandboxPassword
remoteapi.endpoint: https://sandbox.example.com/api

A grey list allows for the setup of these values by configuration profile.

You may be remembering that Part 3 of this series of articles discussed overriding configuration in settings.php, and thinking that a grey list sounds like the same thing. After all, the default values for the sandbox instance of the API could be set up as the configuration values, and the production values could be overridden in settings.php on the production environment, with the same end-result.

The difference is that with a grey list, the remote API values are saved to the configuration profile folder, which is tracked by Git, and therefore can be tracked and migrated between environments. When grey listed configuration is exported, the grey listed configuration is written to the configuration profile folder, in the same manner as blacklisted configuration. When configuration is imported, the default values are retrieved, and the grey list values are used to override the default values, after which the configuration is imported into active configuration.

With the configuration override method using settings.php, site builders need to store the various configuration values somewhere outside the project, communicating environment-specific configuration values to each other through some means, to be manually entered on the relevant environment(s). With a grey list, the configuration values are managed with Git, meaning site builders do not need to record them outside the project, nor communicate them to each other through some other means. Site builders simply need to enable the relevant configuration profile in settings.php, and the environment-specific values can then be imported into active configuration from the configuration profile directory. This means that the sandbox API values can be set up as the values used by default on all environments, and a production configuration profile can be enabled on the production environment using the values to connect to the production instance of the remote API.

Conditional split items can be selected either from a list, or by manually entering them into the configuration profile:

Conditional split (grey list) settings can be selected or manually entered

Finally, note that grey lists can actually be used in conjunction with configuration overrides in settings.php. Grey lists are applied during import and export of configuration from the database. Values in settings.php are used at runtime, overriding any active configuration. So a developer could choose to set up their local instance of the system to connect to an entirely different instance of the remote API altogether by overriding the values in settings.php.

Ignoring configuration (overwrite protection)

Sometimes developers will want to protect certain configuration items in the database from ever being overwritten. For example imagine a site named Awesome Site, with a module that supplies the core of the site, named awesome_core. Since this module provides the core functionality of the site, it should never be disabled under any circumstances, as that would disable the core functionality of the site. In this case, the configuration for this module can be set to be 'ignored'. Any attempts to import ignored configuration from the file system to the active configuration in database will be skipped, and not imported.

Configuration can be ignored using the Config Ignore module. The functionality this module provides is similar to the functionality provided by the Config Readonly module discussed earlier, however the Config Readonly module covers the entire configuration of an environment, while the Config Ignore module allows for choosing configuration that should be protected. This configuration is protected by ignoring it altogether on import.

Configuration can be ignored as follows:

  1. Enable Config Ignore module on all environments.
  2. Navigate to the config ignore UI page, and set the configuration item to be ignored. In the case of preventing the awesome_core module from being disabled, the following would be added:
    core.extension:module.awesome_core
    Configuration to be ignore is entered one item per line. Wildcards can be used.

This setting will ensure that any attempts to change or remove core.extension:module.awesome_core upon configuration import will be ignored. So if the module is enabled on production, and a developer pushes configuration changes that would uninstall this module, those changes will be ignored, and the module will still be set as enabled after import.

Summary

In this article, we looked at various modules that extend the Configuration API, use cases behind these modules, and how the modules worked. We looked at the Config Readonly module, the Configuration Split module, and the Config Ignore module, and how to use these modules to manage configuration differences between environments. In the next, final part of this series, we will look at configuration management for module developers, and how developers can define the schema for the configuration their module provides.

May 14 2019
May 14
May 14 2019
May 14

When every business has a website, how do you stand out? Because customers expect so much more from digital brands, utilizing a marketing platform is essential. Marketing automation software enables businesses to deliver personalized engagement, strengthening customer bonds and driving new business.

acquia acquires mautic open marketing platform

Until recently, businesses have, by-and-large, had to rely on proprietary solutions like Marketo and Salesforce Marketing Cloud to handle their needs. Now, Acquia is looking to disrupt the marketplace. The Drupal SaaS giant has just acquired Mautic, an open-source marketing automation and campaign management platform. Now, Drupal users will have an open alternative to manage their customer experience needs.

This is the latest step Acquia has taken toward their vision for an Open Digital Experience Platform. The company has been working in the content management space for years and is now turning toward a data-driven, experience management approach. With their “API-first” philosophy, Acquia hopes to offer Drupal users maximum flexibility and the ability to meet any organizational needs that may arise. This level of freedom gives marketers the chance to customize every step of the customer cycle across channels.

While still a relatively young company, Mautic is a perfect fit for Acquia’s portfolio. While Acquia specializes in content management, personalization and commerce, Mautic will complement their offerings with their specialties in multichannel delivery, campaign management and journey orchestration. And with both Drupal and Mautic built on Symfony and PHP, collaboration and integration will be made easier. With 200,000 installations already, Mautic has already won over many marketers and, with Acquia’s expanded reach, will likely reach many more. Because of Mautic’s API-friendly build, our team at Duo can easily integrate the platform with a site.

Open Marketing (YouTube)

On a more philosophical level, Mautic echoes Acquia’s (and the Drupal community’s) open-source ethos. Currently, Mautic is the only open source alternative to the aforementioned legacy marketing cloud ecosystems. This openness makes it easier for the development community to create marketing platforms built for a company’s specific needs. This ease of use extends to the marketing side, too. Where many proprietary marketing automation software have steep learning curves and are bundled with countless other products in their respective clouds, Mautic’s platform benefits from its ease-of-use and its modern, streamlined design - allowing anyone on a team to get their organization’s message out faster than ever. To take a look at the platform in action, watch the demo embedded below.

[embedded content]

In addition to Mautic’s open offerings, the company also offers several commercial solutions. The first, Mautic Cloud is a fully managed SaaS version of the platform that includes some premium features not openly available. For enterprise clients, Mautic has Maestro. This product allows multinational organizations the ability to segment their marketing efforts by territory, while still allowing for sharing between regions. Campaigns can also be copied and repeated in different territories. These features will remain separate from Acquia Lift, though Duo can handle integrations with either service if needed.

So what does all of this mean for businesses using Drupal? This being an open-source community, it means more freedom! Rather than being locked into whatever is offered by legacy martech vendors, Drupal allows you to leverage best-of-breed services and solutions. At Duo, we’re always striving for more openness. Your solution should match your exact needs and the Drupal environment provides a vast range of solutions to make it your new site a reality. Now, Mautic joins those ranks, and can be used in conjunction with whatever other modules you opt to use. The open source ecosystem that makes Drupal so robust also gives Mautic more flexibility than other marketing automation platforms, and for a cheaper price tag, as well. Finally,

By 2023, spending on global marketing automation is expected to reach $25 billion. This software isn’t going anywhere, so why would you pay for a stale and outdated marketing suite that you may not be able to use to its full potential? With the acquisition of Mautic, Acquia has given marketers a whole new option when it comes to managing customer engagement. Duo can help you navigate the various marketing paths available while ensuring that whatever choice you make will exceed your expectations.

Explore Duo

May 14 2019
May 14

Long awaited and much needed in the pipeline, the Layout Builder was finally launched in May 2019. With an ambition to create a content tool that can provide more power and flexibility than comparable systems, the Drupal community had been working on a super progressive visual tool for more than a year. Earlier, the digital marketers had restricted templates to work with and were not satisfied with clunky design experiences. However, in the recent launch of Drupal 8.7.0, Dries Buytaert stated that the new layout builder will be able to manipulate different types of content and unleash unique and trend setting features. The feature of layouts for templated and customised content is crucial for websites with large amounts of content. 

For websites with heavy content, the Layout Builder has enhanced Drupal’s ability to handle “structured content” now. 

A man climbing a ladder in the sky


Originally introduced as an experimental module in Drupal 8.5, the primary focus of the layout builder was to develop a drag and drop WYSIWYG tool. Relying on a third-party software was getting painstaking for many and Drupal became one of the first CMS to take this risk. This layout builder offers full compatibility with revisions, workflows, and in-context previews. It is a single, powerful and visual design tool that creates layout templates that can speed up the development process for the site builders. The accessible, mobile-friendly page building tool allows content authors to easily customise individual pages with unique layouts too.

With 123 individuals and 68 organisations contributing, the Drupal 8.7 comes with this promising layout builder.

Advantages of Layout Builder

The shifting focus in the website development has lead to Layout Builder emerging as the most exciting CMS visual design tool. Let’s explore its reasons: 

  • You can create layout templates for a specific content type, such as blog posts, products pages, landing pages, etc. 
  • Layout builder empowers to customise the template layouts and override them on a case-by-case basis. 
  • It enables you to create custom landing pages that are not tied to a content type or structured content. 
  • The tool passes Drupal’s accessibility gate(Level AA conformance with WCAG and ATAG) with a stable state for production. 
  • The updated version in Drupal 8.7 allows streamlining mass-production while supporting unique creation.
  • The drag-and-drop management of your content blocks is now possible with the new layout builder 
  • Additionally, it supports keyboard controls and toggling the content preview on and off to give the content editor complete control of their experience while building their layouts.

With 123 individuals and 68 organisations contributing, the Drupal 8.7 comes with this promising layout builder. Moreover, 40 above individual contributors volunteered for the success of this release. 

Improved Layout Builder in Drupal 8.7

Translation Support

As the layout builder has improved features for translation, there are two approaches that can be taken here:

  • Synchronised approach translation: For multilingual sites that have the same layout, all the content and fields are automated. In other words, any text entered with layout builder is translated automatically for you. 
  • Independent approach translation: On the other hand, if you want different layouts for two different languages or take a localisation approach to the site, you can have independent and individual translations for them too.

Usability 

From Drupal 8.6 to Drupal 8.7, the usability has drastically improved:

  • You can now narrow down the list of block available and add several tweaks to it. 
  • Contextual links are used to add shortcuts. The Drupal community is re-evaluating the usage as it is essential from the UI point of view. 
  • Except for minor alterations, the layout builder now gives real-time updates based on changes made in sidebar.

Accessibility 

The usability is always inter-connected with accessibility. If it isn’t accessible, it is not usable for obvious reasons. The revamped version has features like:  

  • Improved usage of Drupal announce and ARIA attributes.
  • Now you can easily access the keyboard to action commands like save, discard, or revert from anywhere on the page. 
  • The tabledrag can get confusing for many. You can create a tabledrag-based UI to make all changes at once in the layout builder with Drupal 8.7. 

New Media Library

A new, stylish and with a handy user interface, Drupal 8.7 introduces us with numerous improvements in the Media Library:

  • The highlighted design and accessibility of the user interface makes way for inline media creation in the library itself. 
  • The process of searching the media items in the library, from bulk uploading them to the selection of media items and embedding them into the content is also a smooth run with the new version.
  • The Media module also allows reuse of images, documents, efficiently managed drag-and-drop function and provides a more flexible grid and table views. 
  • The media module in sync and stable with this media library and will further improve with the upcoming Drupal 8.8 release.
Screenshot of how to add new media in Layout Builder

Revisions in Custom menu links & Taxonomy

The following revisions in the 8.7.0 release aim to enhance the overall performance of the Layout Builder:

  • It allows the Custom menu links and taxonomy terms to fully participate in the editorial workflows. 
  • They have been revised for improved integration and core support for the Workspaces module with a new Update API for help in conversion of further entity types. 
  • The schema of any content entity type can now be converted between non-revisionable or non-translatable and revisionable or translatable. 

Automatic Entity 

Among many additions, there has been few subtractions as well: 

  • The support for automatic entity updates was removed due to data integrity issues and its conflicts. 
  • The drush entity:updates (drush entup) command stands nullified and the entity changes will now be performed using standard update procedures.

Internet Explorer 9 and 10

The workaround that still existed in D8.5 and D8.6 also gets removed as the *.7.0 release says goodbye to Internet Explorer 9 and 10. The workaround used to allow the inclusion of 32+ stylesheets. 

Check out Buytaert’s demo video showing the Layout Builder in action with Drupal 8.7.0.  

[embedded content]

On the way to Drupal 9

The major release of Drupal 9 planned for June 2020 will open new doors for the layout builder. It will update dependencies primarily on Symfony as the optional support for Symfony 4 is expected to complete by 8.8 version. Further, a better feedback on the compatibility can be obtained as we testing Drupal with updated third-party dependencies in this version. Drupal 8.7.0 also includes an optional support for Twig 2 (for sites that can patch their Composer configuration). 

Conclusion

New improvements in terms of keyboard navigation accessibility, precise permissions, layout overrides, and column width selection has given a stable outlook to the Layout Builder and it is ready to work on live sites. The process of constructing pages “brick by brick” with a combination of elements, configuration of blocks, and drag-and-dropping feature is an easy and enjoyable one. 

Check out the new Drupal 8.7.0 version and share your views with us in the comments! We’d also like to hear from you at [email protected].

 

May 14 2019
May 14

Here's a short video of it in action.

Ok, that looks pretty cool. Show me the code.

WTF? That code is crap. You have hard-coded what you want the site do to. That's not going to work for all sites, only for your specific use case.

Yep, that's true at the moment. Like I say, it's just a proof-of-concept. We'd need to create a settings page for users to decide if they want it to be available or not. And we'd have to create a better parsing system that listens for "voice admin" and then starts recording. Then we'd need to make sure that it patches together the fragments of speech after this to construct the action that you want to perform. Following that, it would be really cool if on the settings page users could type in commands and responses that SpeechRecognition will listen for and then perform.

I think all this is very possible, and probably not too much work. It would be great to see more progress on this.

If you'd like to create a pull request, the code is available on GitHub.

May 13 2019
May 13

Drupal 7 was officially released in 2011, making it quite old in web years, though it still powers hundreds of thousands of websites worldwide.

Drupal 8 was released in 2015, but the path to upgrading has never been an easy one for Drupal websites (prior to 8). So our recommendation for most Drupal 7 site owners has been to wait– wait until you have the time, budget and other resources needed to do a full redesign and migration to Drupal 8.

But Drupal 7 isn’t going to last forever.

It’s official end of life has already been decided–November, 2021. A full ten years after its original release, Drupal 7 will no longer be officially supported. What this means is no more security patches or bug fixes.

It won’t just stop working, but without official support, Drupal 7 sites will become vulnerable to crashes, hacks and other vulnerabilities. There are private companies who will continue to support Drupal 7 sites after 2021 in exchange for a support contract. But officially, it will be unsupported and after 10 years of service, most sites could benefit greatly from a more modern CMS.

But when is the best time to upgrade? What will it take? What are potential problems, or gains? And why should you continue using Drupal in the future? Let’s break down these questions one by one.

When is the best time to upgrade?

In our opinion, the best time to upgrade is the next time you fully redesign your website. While smaller, ongoing updates and improvement are critical to maintaining a vital and effective website, at some point site owners should look at conducting a full redesign.

The general recommendation is for organizations to conduct a full redesign every 2-5 years, depending on your resources, audience, content, and budget. While there’s no one-size-fits-all, anyone still running the same website after 5 years is risking their ability to stay relevant.

So much may have changed since you last redesigned–user expectations, the way people access the web, how you reach your audience. It is worth revisiting your overall strategy. Certainly the way a site is produced in Drupal 8 is also different than Drupal 7. Only focusing on a version upgrade may be a lost opportunity to take advantage of all the new features Drupal 8 has to offer.

What if I just redesigned, or don’t have the budget for a full redesign?

If you aren’t interested in a full redesign, or unable to consider that option, you have a few options. The first, as stated earlier, is to wait. Start budgeting for a redesign and version upgrade today, knowing you still have at least 2 years before you have to make your move.

The second option is to keep your current site as close to the same as possible, but upgrade to Drupal 8. I would love to tell you exactly what this will take. But like many things in life, it just depends.

The lowest cost scenario for an upgrade is a very simple Drupal 7 website, one that relies on minimal content types with few fields, very few contributed (non-core) modules, and nothing in the way of custom modules or templates. It our experience, however, this isn’t a very common scenario for all but the most basic of websites. The more complex sites depend on an array of custom and contributed modules and custom templates which make upgrading a more… nuanced experience.

Drupal 8 does have a great suite of Migrate modules in core that an experienced developer can use for when updating a site from Drupal 7 to 8 (or migrating from other content management systems). There are, unfortunately, quite a few areas where a versions upgrade runs into trouble, however.

Why can’t I just easily upgrade from Drupal 7 to 8?

As great as Drupal is, its Achilles heel has been version upgrades. They've been historically difficult and time consuming. The good news is, from Drupal 8 to 9 and beyond, this has been addressed and fixed! But if you’re in Drupal 7,  the upgrade path is still a hard one.

There is a good reason for this, of course. With Drupal 8, the entire system was rearchitected. Unlike an upgrade from WordPress 4 to 5, for example, where the overall system remained the same, Drupal 8 changed everything. It introduced the use of Symphony, Composer, Twig templating and a greater reliance on object-oriented programming (OOP).

Extremely popular modules like Views became part of Core, which is great moving forward, but (as of now) requires users to completely rebuild any Views used on their Drupal 7 sites for Drupal 8. Themes in Drupal 7 relied on PHP Template Engine but now use the more modern Twig language for templating.

Popular methods of staging sites via the Features module were replaced by new techniques such as Configuration Management. Photos and videos are now "entities" managed by the Media module, which itself is part of the core install. These were all extremely valuable improvements, but at the cost of making version upgrades difficult.

So what does it cost?

If you’re able to follow our original recommendation, and upgrade to Drupal 8 as part of an overall redesign, the cost is wide-open and not really dependent on the software upgrade. While some or all of your content might be migrated, and modules replaced with the latest versions, often times it’s faster and easier to recreate the entire site from scratch.

This approach, however, means budgeting a lot more than you might have planned for a ‘simple software update.’ Instead you budget for a full redesign and all the work that entails.

Whether you are pursuing a full redesign, or “simply” a version upgrade, the first step in estimating the cost is to conduct a site audit. Using spreadsheets or documents, start collecting data on all of your site content, asking questions such as:

  • How many content types do you have? What fields are in use?
  • How many users and user roles do you have?
  • How many Views are in use? These will need to be recreated by hand
  • How are you going to map existing URLs to content on Drupal 8? What redirects are in place?
  • How many site menus do you use? Menus will need to be recreated
  • What theme are you using? Whether it’s custom or not, it will have to be rebuilt
  • How many blocks do you have, and where are they used?
  • Are you using Field Collections? These will need to be replaced
  • How much Media do you use (images, video, etc.)? These will need to be mapped to entities
  • What contributed modules do you use? Is there a corresponding Drupal 8 version, and if so, does it offer an upgrade path?

Planning for a version upgrade requires a close look at everything your site does, all the users and content, and identifying all the series of steps required to not lose functionality, content, or search engine placement.

TLDR; the cost depends on the size and complexity of your existing site. Plan on 70-100 hours of work at the low end, to well over 200 hours for more elaborate sites.

Why should I bother with Drupal 8?

Considering all the complications and expense with upgrading to Drupal 8, a natural reaction might be to not bother at all. Why not move your site to WordPress, for example? There are, however, more than a few important reasons to consider staying with Drupal.

Drupal 8 is so much better

We’ve talked about how the rearchitected Drupal 8 made version upgrades difficult. But you can’t do that without also talking about much was gained in Drupal 8.

  • More in Core – Views, Media, WYSIWYG, Layout Builder and more
  • Improved Editorial Experience – CKEditor, drag and drop, inline editing
  • Improved Media Management – including new Media library tools
  • Accessibility improvements
  • HTML 5
  • Mobile first and responsive
  • Data integrations – API-first platform with RESTful services and JSON:API in core
  • Configuration Management – easier and faster for developers
  • Improved multilingual support for over 100 languages
  • Security and performance improvements

Future updates are so much easier

Even though the Drupal 7 to 8 process can be long and cumbersome, the future is bright! Drupal 8 was designed for ease of version upgrades. It relies on a new release cycle and semantic versioning for more predictable update schedule. Minor releases come out every 6 months (e.g. 8.6 to 8.7) allowing every site owner to keep their site up to date.

Even better, each minor release contains new and sought-after features, meaning you don't have to wait years between release cycles. Patches and bug fixes get released as needed, until the next stable release of Drupal comes out. Updating to Drupal 9.0 won’t be any different than updating from 8.6 to 8.7!

Even now, every Drupal 8 module is being tested for compatibility with Drupal 9, and the great news is that many of them are already there. As long as you’re keeping your Drupal 8 site up to date, the next full version upgrade should be a piece of cake.

Drupal is ready for the future

Thanks to Drupal’s API first initiative, Drupal 8 (and beyond) is positioned as a powerful platform that makes it easy to integrate with other systems. This includes the increasingly common need for tight integration with existing applications and tools, plus the ability to use and display your content any where you like.

Drupal can now be easily used to power mobile applications, digital signage, voice controlled skills, the Internet of Things (IoT) or as an API that other applications can communicate with directly. The world is quickly moving in this direction, and Drupal 8 is ready for it now.

Familiar with the software

In addition to gaining all the features mentioned prior, it’s worth putting in a plug for the advantage of familiarity. As much as things have changed, there is still a core experience that you will find the same. Content types still power how your content gets entered, Views still drive your database queries, Users can still be managed through powerful Roles and Permissions. Blocks are still a key element of building out your pages.

If you’ve built up years of experience and know-how working with Drupal 7, why throw that all away? Get to know the new features which will improve your site experience, while taking advantage of all that historical knowledge.

And most importantly, the community that makes Drupal so great is still here. That means all the help and knowledge sharing you found on Drupal.org, the online tutorials and articles throughout the web, the agencies and developers who worked with you before, and conferences and meet-ups dedicated to Drupal–we’re all here to help you move to Drupal 8!

Worried about the future of your Drupal 7 site? Thinking about an upgrade? We can help you audit your current build and identify what’s possible. Contact us for a conversation about your upgrade.

May 13 2019
May 13

Since last month a lot of Drupalists were busy preparing for and traveling to DrupalCon, we wanted to give everyone a chance to catch up with important news and goings-on in the Drupalverse. To this end, here’s a recap of our favorite Drupal-related posts from last month.

VideoDrupal.org: A new site of Drupal videos tutorials

The first post from April we want to highlight is Karim Boudjema’s introduction of VideoDrupal.org, a new resource for the Drupal community to easily find videos from various Drupal events. The idea for the website was born out of Karim’s desire to give something back to the community who is doing so much, but often has no lasting value to show for it.

VideoDrupal.org is essentially a curated collection of videos found on YouTube that aim at either promoting or educating people on Drupal. To be as helpful as possible both to beginners as well as more seasoned Drupal developers, the site is divided into two sections: one that focuses on the basics of Drupal theming and site building, and one that’s dedicated to more specific topics. 

Read more

A Series Of Unfortunate Images: Drupal 1-click To Rce Exploit Chain Detailed

This next post, written by Zero Day Initiative’s Vincent Lee, relates the discovery of a set of bugs in the recent critical patches for supported versions of Drupal 7.x and 8.x. These two bugs enable remote code execution through uploading three malicious files to the target server and then persuading the admin to click on a crafted link. 

While the exploit is not exactly smooth and involves the attacker(s) having to set up a profile on the site (which means that any site which doesn’t allow visitors to create accounts is automatically safe), it is still interesting and useful to be aware that the possibility of such an attack exists.

(By the way, the song in the video of the two bugs in action is really great - if anyone knows what it is, please let us know!)

Read more

The privilege of free time in Open Source

In the third post on this month’s list, Dries touches upon the problematic of open source contribution of underrepresented and less privileged groups. Because of their social and/or economic status, e.g. women must dedicate a lot of time to childcare and housework, these groups don’t have as much time to do unpaid work on open source. 

In contrast, privileged groups have much more time to contribute, which results in a lack of diversity in tech and open source in particular. But time constraints are not the only issue here; people from underrepresented groups are often subject to hostility and discrimination, which makes them that much more reluctant to continue contributing to open source. 

So, as individuals, we need to be more welcoming and not succumb to our biases. As for organizations, sponsoring your employees’ work on open source so that they don’t have to do it in their limited free time can really go a long way. 

Read more

State of Drupal presentation (April 2019)

Next up, we have another post written by Dries, this one essentially a recap of his annual State of Drupal presentation which he gave at DrupalCon Seattle. The post actually opens with the topic of the previous post mentioned here, that is, fostering diversity and inclusion in open source by giving underrepresented groups better opportunities to contribute. At this year’s ‘Con, nearly 50% of the speakers were from such groups, which shows that we’re on the right track. 

The rest of Dries’ keynote was dedicated to Drupal’s (at the time) upcoming release, the preparation for Drupal 9 and Drupal 7’s end of life. Drupal 8.7, released on May 1st, brought important updates such as a stable Layout Builder and JSON:API in core. With Drupal 9 just a little over a year away, it’s wise to start preparing for the upgrade now - one of the first things you can do, if you haven’t yet, is to upgrade from Drupal 7 to 8.

Read more

A Proposed Drupal privacy initiative and the Cross CMS privacy group.

With privacy becoming a key concern in software development, it’s important for Drupal as well as other CMS to focus on privacy. For this purpose, members of the Drupal, WordPress, Joomla! and Umbraco communities have formed a Cross-CMS privacy group whose goal is to establish a common set of principles that all these technologies can rely on.

In this blog post, Jamie Abrahams of Freely Give discusses the work of the Cross-CMS privacy group, listing a number of the group’s achievements since its formation last year, as well as some points on privacy not just as a legal, but an ethical obligation. Finally, he enumerates the goals of a proposed Drupal privacy initiative and concludes the post with next steps for the Cross-CMS privacy group to take.

Read more

Enabling headless Drupal Commerce while improving its core

In the next post on our list, Matt Glaman of Centarro (formerly Commerce Guys) writes about decoupling Drupal Commerce and how this can actually improve Drupal’s core. The basis for this post is the recent trend of decoupling, or “going headless”, which has been particularly talked about in the Drupal community.

As Matt points out, the work on the API-first initiative and decoupled Drupal is very beneficial to the modules in question and Drupal in general. He gives a few examples, such as a smooth coupon redemption via the Cart API module

This post, then, shows how a decoupled architecture and ecommerce can work perfectly well together. It finishes with some examples of successful uses of decoupled commerce, such as 1xINTERNET’s React-based solution which they presented at DrupalCon Seattle.

Read more

Learn to Theme with Hands-On Exercises

Since part of our mission at Agiledrop is spreading Drupal awareness and training new generations of Drupalists (we just held our second free Drupal course of the year this weekend), we also make it a point to promote other endeavors of educating people on Drupal. 

In this respect, we wanted to highlight this post by Amber Matz introducing Drupalize.Me’s new hands-on workshop for learning Drupal 8 theming. This is a 7-week course perfect for Drupal beginners who want to get practical experience with theming. At the end of each week, participants test their newly acquired skills through hands-on exercises accompanied by helpful videos. 

Another important novelty is Drupalize.me’s partnership with Stack Starter, which enables web-based development environments and consequently allows participants to focus on learning rather than having to set up their own local environment. 

Read more

Drupal Association appoints Executive Director

We conclude April’s list with some important news for Drupal and its community. At the very end of April, Interim Executive Director Tim Lehnen announced in a blog post that the Board of Directors of the Drupal Association have appointed Heather Rocker the new Executive Director of the Association. 

As a former executive director of the Women in Technology foundation and CEO of Girls Incorporated of Greater Atlanta, as well as due to her experience in robotics and other fields, Heather is the ideal choice for leading the organization that aims to increase Drupal adoption and unite a diverse community of Drupalists. 

We’d like to give a warm welcome to Heather and join Dries and the entire community in the excitement of beginning the next chapter of Drupal under her guidance!

Read more

We hope you enjoyed our selection and were able to either revisit some of last month’s blog posts or learn something you may have missed. Tune in next month for an overview of the top Drupal posts from May!
 

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