Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 27 2017
Nov 27

This month’s Drupal meetup in Bangalore was held this weekend, on 25th November. Specbee Consulting office kindly provided us with a venue for the meetup and helped organise the event. This meetup happened after a period of six months, and the motive was to get the meetup activities started again in Bangalore.

We are hoping to make organising the meetups and all related activities much more easy and sustainable for everyone involved in Bangalore. A full discussion of these initiatives should probably happen elsewhere, but by starting off with this meetup this month, we hope to keep this running in a more stable manner with minimal load on the organisers. If you’d like to stay updated on when meetups are announced, join us on Meetup.

The day started at around 10:30 AM with a round of introduction of everyone present. The first presentation of the day was by Parvateesam Konapala and Rakesh James who introduced Symfony Components to everyone. They introduced various components used in Drupal such as Event Dispatcher, Dependency Injection, Serializer, etc… The discussion ended with a talk of tools like Drupal Console.

This was followed by a small break with refreshments provided by Specbee Consulting.

After the break, Taher Jodhpurwala spoke about quickly starting with Drupal development. In the presentation, Taher shared ways in getting started with Drupal development with minimum effort using tools like composer, Lando, etc…

Lastly, I discussed a bit of how we use CI systems like Gitlab and Circle CI to manage, test, and deploy our Drupal websites. The meetup ended at 1:30 PM with a group photo.

I’d like to thank Specbee Consulting for providing a venue for the meetup and all the support and, of course, refreshments. Photos from the meetup are below.

Drupal Meetup Bangalore - Nov 2017

Nov 18 2017
Nov 18

The VIPS image processing system is a very fast, multi-threaded image processing library with low memory needs. And it really is pretty fast, the perfect thing for rokka and we'll be transitioning to using it soon.

Fortunately, there's a PHP extension for VIPS and a set of classes for easier access to the VIPS methods. So I started to write a VIPS adapter for Imagine and came quite far in the last few days. Big thanks to the maintainer of VIPS John Cupitt, who helped me with some obstacles I encountered and even fixed some issues I found in a very short time.

So, without much further ado I present imagine-vips, a VIPS adapter for Imagine. I won't bore you with how to install and use it, it's all described on the GitHub repo.

There is still some functionality missing (see the README for details), but the most important operations (at least for us) are implemented. One thing which will be hard to implement correctly are Layers. Currently the library just loads the first image in for example an animated gif. Not sure, we will ever add that functionality, since libvips can't write those gifs anyway. But with some fallback to imagick or gd, it would nevertheless be possible.

The other thing not really well tested yet (but we're on it) are images with ICC colour profiles. Proper support is coming.

As VIPS is not really something installed on many servers, I don't expect a huge demand on this package, but it may be of use for someone, so we open sourced this with joy. Did I say, that it's really fast? And maybe someone finds some well hidden bugs or extends it to make it even more useful. Patches and reports are of course always welcome.

Nov 14 2017
Nov 14

A website that makes complicated features easy to use is critical for healthcare companies. Patients expect to be able to access information easily and securely. Drupal development firms have the ability to maximize Drupal modules and features to create websites that provide a superior user experience. This is where a great Drupal development firm comes in.

Sites that run on Drupal platforms get consistently higher ratings and reviews from users. The Northwestern International Health website is one of the top 12 best healthcare websites worldwide, and they aren’t the only healthcare organization getting higher user experience ratings.

There are thousands of healthcare sites operating on Drupal platforms. These sites serve a variety of functions:

  • They enhance patient services
  • They are available to users on multiple devices with excellent responsiveness
  • They accommodate multiple languages and workflows

Drupal is the choice for a range of organizations from Florida Hospital to Mayo Clinic’s Health Sciences Research Intranet.

Three Amazing Drupal Healthcare Sites

1. Chesapeake Regional Healthcare

Chesapeake Regional Healthcare is a family of providers that serves residents in southeast Virginia and northeast North Carolina. The website houses one of the most impressive ‘Find a Physician’ features anywhere. The search and filter options are styled similarly to Amazon’s, and are broken up into different categories that include: Speciality, Location, Keyword and Language. Most conveniently, there is an option to find doctors that are accepting new patients, a feature not found on nearly enough healthcare sites.

2. DentaQuest Institute Online Learning Center

The DentaQuest Institute Online Learning Center is an online education and resources hub for dental care professionals. When they hired Thinkbean, DentaQuest wanted to reduce page load times for all users and create a notifications system for group members based on user preferences. Page load times for existing Drupal features, like the online courseware, instructional webinars and resource library, are 2-4 times faster. The site now boasts a notification system that allows users to opt in/out of a group discussion, and choose what notifications they’d like to receive (if any).

3. Humana

Humana is a health insurance company that uses its website to promote well-being and lifestyle services. Humana users can go to the ‘My Well Being’ site to get information that is uniquely relevant to them, based on their past experience with network physicians and user interests. The site provides games, videos and photos, to inform and increase patient engagement.

Thinkbean is a Boston Drupal industry leader and contributor to Drupal 8. Talk to a web development expert today about what Thinkbean can do for you.

Drupal Development’s Contribution to Healthcare

Medical professionals have been pleased and impressed by Drupal’s ability to support moving healthcare platforms online. Drupal supports healthcare projects that (among other things) include:

  • Open source clinical trial management systems
  • Platforms for interdisciplinary collaborations of healthcare professionals
  • Patient and healthcare information aid websites
  • Healthcare conference platforms and paper submission systems

There are over 5,000 Drupal 8 modules that have been designed and tested by programmers and developers all over the world. Expert Drupal developers, like those sponsored by Thinkbean, have the ability to integrate these modules with Drupal core to create seamless ecosystems that have limitless applications. This superior functionality ensures a better experience for site visitors and frequent users.

It’s essential to find the right Drupal Developer the first time. Thinkbean’s advanced Drupal development skills allow businesses to establish a user-friendly web presence, achieve business goals, and exceed the needs and expectations of their clients.

Read case studies of our most interesting Drupal 8 projects to discover how we can help you reach your goals or talk to a Drupal expert today.

Nov 09 2017
Nov 09

This post was originally published on Medium.

Ah, the config system. Crown jewel of Drupal 8, amirite?

Well, yeah, it’s fantastic and flexible (as is most of Drupal). But if you have advanced use cases — such as building a system that alters config dynamically — there are traps you should know about.

Config is normally a fairly static thing. Your module/theme/profile (“extension” from here on out) has some configuration in its config/install sub-directory, and when the extension is installed, that config is imported. Once it’s imported, that config is owned by your site and you can change it in any way you see fit.

That’s the simplest, and most common, use case in a nutshell. Let’s talk about some other ones.

Optional config

In some extensions’ config directory, you will see an ‘optional’ directory alongside ‘install’. If you look in there, you see…some YAML files. What’s all this, then?

Optional config is normal config, but it’s treated differently. When an extension is installed, each piece of optional config it provides is analyzed, then imported only if all of its dependencies are fulfilled. A piece of config can declare, for example, that it depends on a view called ‘content’. That’d be expressed thusly in code:

    - views.view.content

If that piece of config is optional, then it will only be imported if, well, a view called ‘content’ exists in the system. That view might have been shipped with another extension, or maybe you created it manually. It makes no difference. As long as a view called ‘content’ is present, any optional config that depends on it will be imported as well.

Neat, yes? This comes in quite handy for something like Lightning, which allows you to create an install profile which “extends” Lightning, yet only installs some of Lightning’s components. Optional config allows us to ship config that might be imported, depending on what parts of Lightning you have chosen to install. Hooray for flexibility!

Optional config whilst installing Drupal

But wait, there’s more.

When you’re doing a full site installation (i.e., install.php or drush site-install), optional config is treated a little bit differently. In such a case, all extensions are installed as normal, but their optional config is ignored initially. Then, at the end of the installation process1, once all extensions are installed (and their default config has been imported), all2 the optional config is imported in a single batch.

I don’t think this is documented anywhere, but it can have major ramifications. Consider this piece of code — let’s say it’s part of a module called fubar, which provides some default config and some optional config. This hook will be invoked while fubar is being installed, but after its default config has been imported:

setDescription('The force will be with you, always.');

fubar_view is optional config, so will entity_load() return a view entity, or will it return NULL? What do you think?

The maddening answer is it depends. It depends on when fubar is being installed. If Drupal is already installed, and you’re just adding fubar to your site, then $view will be a view entity, because the optional config will be imported before hook_install() is invoked. But if you’re installing fubar as part of a full site install — as part of an installation profile, say — $view is going to be NULL, because optional config is imported in a single batch at the end of the installation process, long after all hook_install() implementations have been invoked.

Yeah, it’s a WTF, but it’s a justifiable one: trying to resolve the dependencies of optional config during Drupal’s install process would probably have been a colossal, NP-complete nightmare.

Dynamically altering optional config

So let’s say you need to make dynamic alterations to optional config. You can’t do it in hook_install(), because you can’t be sure that the config will even exist in there. How can you do it?

The easiest thing is not to make assumptions about when the config will be available, but simply react when it is. If the optional config you’re trying to alter is an entity of some sort, then you can simply use entity hooks! Continuing our fubar example, you could add this to fubar.module:

isNew() && $view->id() == 'fubar_view') {
    $view->setDescription('Do, or do not. There is no try.');

This ensures that fubar_view will contain timeless Yoda wisdom, regardless of whether fubar_view was imported while installing Drupal. If fubar_view is created at the end of the installation process, no problem — the hook will catch it and set the description. On the other hand, if fubar_view is installed during drush pm-enable fubar, the hook will…catch it and set the description. It works either way. It’s fine to dynamically alter optional config, but don’t assume it will be available in hook_install(). Simply react to its life cycle as you would react to any other entity’s. Enjoy!

Moar things for your brain

  • hook_install() can never assume the presence of optional config…but it can assume the presence of default config (i.e., the stuff in the config/install directories). That is always imported before hook_install() is invoked.
  • In fact, you can never depend on the presence of optional config. That’s why it’s optional: it might exist, and it might not. That’s its nature! Remember this, and code defensively.
  • The config_rewrite module, though useful, can throw a monkey wrench into this. Due to the way it works, it might create config entities, even optional ones, before hook_install() is invoked. Even during the Drupal installation process. Beware! (They are, however, working to fix this.)
  • The config system is well-documented. Start here and here. This post is only one of tons of other blog posts about config in D8.
  • This blog post came about because of this Lightning issue. So hats off to Messrs. mortenson and balsama.
  • Thanks to dawehner for reviewing this post for technical accuracy.
  • “NP-complete”, as I understand it, is CompSci-ese for “unbelievably hard to solve”. Linking to the Wikipedia article makes me seem smarter than I really am.

1 The reason this happens at the end is because any number of things could be changing during installation (who knows what evil lurks in hook_install()? Not even the Shadow knows), and and trying to solve multiple dependency chains while everything is changing around you is like trying to build multiple castles on a swamp. (Only one person has ever accomplished it.) Don't think about this stuff too much, or it will melt your brain.

2 “All”, in this case, means “all the optional config with fulfilled dependencies,” not all-all.

Nov 06 2017
Nov 06
Thunder Day am 20.11.2017 Quelle: thunder.org

The first Thunder Day will take place on 20th November 2017 in Hamburg at the Wälderhaus. The free event starts at 10:00 am and serves the exchange of experiences in working with Thunder. The day should also show users the benefits of Thunder with showcases.

The Guests

The event's guests include not only publishers, but also agencies that have successfully implemented projects with the help of Thunder. Therefore, members of the undpaul team will also be present and share their experiences at the event with others. Johannes Haseitl will present a case study on our most recent project ISPO.com together with Peter Bilz-Wohlgemuth (CTO of Deutsche Telekom subsidiary The Digitale). A customer representative will share her view of the project with the participants: Saskia Rettenbacher, Senior Manager Messe München GmbH.

Get together

The day will be aligned by Hubert Burda Media, who developed the content management system Thunder for publishers. Starting at 6 pm, a casual get together is planned, where further networking is on the agenda.

We are happy to meet old and new faces on the Thunder Day. Come and get your ticket here

Nov 03 2017
Nov 03

Choosing a website development company is a tricky business. Businesses can be helped, or hindered, significantly by a functional website that makes it easy for their audience to connect with them.

5 Tips for Choosing a Drupal Web Development Firm

  1. Hire with purpose: Know what you want. The scope of the project is important. Prospective partners need to know exactly what you want, what features you need, what you’re starting with and how you’ll measure success. The Request for Proposal (RFP) is one of the two primary ingredients in the Secret Recipe for a Successful Drupal Site. Meet with your team and iron out a solid RFP before taking any steps to hire a development firm.
  2. Hire for personality: How compatible is the web development firm with your organization? Research their background and examine early communication exchanges to make that assessment. Pay particular attention to compatibility during website discovery, the first stage of the partnership process.
  3. Hire for aptitude: Tech moves fast. That’s why Nelly Yusupova, founder of Techspeak for Entrepreneurs, recommends hiring a developer who learns quickly. Drupal core updates are usually released once a month, and the best development firms create, follow and provide feedback on those updates. Ask questions about how much time the prospective development firm spends on professional development, training and independent study.
  4. Hire for priority: The best development firms prioritize the user experience (UX) because it’s a basic requirement for any website. UX is crucial to delighting visitors who come to a website, meeting their needs and keeping them coming back. Look at the user reviews for websites that your potential partner has created, and ask questions about what the development firm does to create the best possible user experience.
  5. Hire for Communication: You have a solid website RFP. The teams really hit it off. The organization is passionate about UX and keeping ahead of the technological curve. Now, can you really communicate? The greatest challenge facing collaborating teams with different expertise is effective communication. Without making the effort to ensure clear understanding of unanimous goals and the collective journey to meet them, it’s a near certainty that neither organization’s goals will be met.

Thinkbean is a Boston Drupal industry leader and contributor to Drupal 8. Talk to a web development expert today about what Thinkbean can do for you.

Choose a Drupal Web Development Firm Wisely

Websites are far more than an indicator of a company’s presence in the digital space. Thousands of businesses provide a significant amount of their service offerings online. Rather than just providing up-to-date information, websites are now places where consumers take classes, schedule appointments, pay bills, file claims and register for services. Many of these services require personally identifiable information and have to be protected by layers of up-to-date security protocols, as a best practice and by law.

The City of Boston recently chose Drupal to launch Boston.gov, a site that provides an unprecedented number of services to Boston residents through local government. The core programming used in the most up-to-date version of Drupal is contributed to by programmers sponsored by industry leaders like Thinkbean.

Whether you require the aforementioned features or not, there are still many questions to be asked before hiring your Drupal web development firm. Before the beginning of the vetting process, consider the following:

  • Do you need to hire a Boston Drupal development firm? There are a lot of advantages to hiring locally. Not only does it support the local business community, it also gives your organization the opportunity for more face-to-face communication with the new web developer.
  • What worked for other organizations? Get a feel for the kind of work and partner you’ll need by exploring the experiences of similar organizations. Use your network to learn about what worked for industry peers during this process.
  • Do I really know what I need? Is the first part of your recipe solid? Have you got your website RFP ready to release? Meet internally as many times as necessary to avoid rework and renegotiation in the future.

It’s essential to find the right Drupal development firm the first time. Thinkbean’s advanced Drupal development skills allow businesses to establish a user-friendly web presence, achieve business goals, and exceed the needs and expectations of their clients.

Read case studies of our most interesting Drupal 8 projects to discover how we can help you reach your goals, or talk to a Drupal expert today.

Oct 31 2017
Oct 31

Step aside Betty Crocker, the successful website has officially become more important than the perfect dinner. The website is the virtual representation of a physical organization for billions of users who visit daily, and it has to function that way. The success of a website is not determined by resources spent building it or budget compliance, but by whether or not the end user is happy with the website’s functionality and user experience (UX). These goals can only be achieved with a strong Request for Proposal (RFP) and the right development partner.

Poor Website Construction Leads to Boston Resident Frustration

When Ben Simo, former president of the Association for Software Testing, attempted to utilize Healthcare.gov shortly after its launch in 2013 he discovered that part of the website’s code was compromising the site’s ability to accept his login information. Problems like this were experienced by 20 million Americans, and temporarily decimated public opinion about the Affordable Care Act.

Problems with the Healthcare.gov website lasted for months. Very little information was released about what the problems were and how long it would take for them to be fixed. The project’s budget jumped from $93.7 million to $292 million and it was recommended that additional contractors be asked to contribute to or take over the project.

Less than a year later, the Boston Globe reported Massachusetts finally had to scrap their own dysfunctional health insurance website. The website was originally created in 2006, but had to be revamped to meet the demands of the Affordable Care Act. Despite the $15 million paid by the state for the work, the site did not function the way it was supposed to, leaving many Boston residents frustrated and uninsured until the state enacted a different system.

Both of these sites failed to deploy successfully because they did not test for basic requirements of functionality and user experience.

Talk to a Drupal expert today to design a successful new website

Boston Launches New Drupal Website With UX in Mind

The City of Boston recently completed deployment of a brand new Boston.gov on Drupal. The process involved far more feedback than any website project effort made before by local government, and is still collecting feedback from residents so that continuous improvements can be made to optimize UX.

From Boston.gov’s homepage, users can search for property information, pay their real estate taxes, apply for a city job, pay a parking ticket, view the schedule for Boston food trucks, get a resident parking permit, learn how to vote by absentee ballot and report non-emergency issues. That’s just on the home page.

A Successful Drupal Website Does More Than Transact

Negative reviews of a website's features have a higher impact on a consumer than positive reviews. Social media engagement and independent review sites have become a way for consumers to control their experience. If a website’s features do not empower the user with a satisfactory level of control, it will often result in a negative review.

Websites are more than digital storefronts. They are places where consumers take classes, schedule appointments, pay bills, file claims and register for services. It’s important for organizations to incorporate the user experience into their end game, by working with a platform and a developer that prioritizes their clients.

Recipe for a Successful Drupal Website


  • RFP: Strong project plan with organizational website requirements, written with the end-user in mind
  • Development Team: Has the skills to tailor the platform to custom specifications with an optimized user experience


  • Choose Drupal 8 for modules, features and potential for integration
  • Choose Drupal Website Development Company for aptitude and capability, in addition to unique characteristics agreed upon by the internal team
  • Preheat the workspace with discussion of priorities, timeline and the goals set forth in the RFP
  • Bake together at a comfortable level of heat, with frequent temperature checks to ensure the website will meet expectations
Oct 31 2017
Oct 31

To achieve the first, we had a strict policy on "no case studies, no sales pitches". Instead we specifically asked for people to propose talks about migration, multilingual, headless Drupal, test driven development, component-based theming, etc. Naturally, the Drupal community didn't let us down and provided two days of very high-level sessions on these and more topics. (As an aside, one attendee told me he didn't get to DrupalCon, but did manage to get to four DrupalCon sessions at Drupal Camp Dublin.)

To achieve the second, we deliberately scheduled our camp for 2 months after DrupalCon. This would allow us to talk to people at DrupalCon and encourage them to come along. Added to that, we contacted people we knew from other Drupal communities outside of Ireland and asked them if they would like to come to our camp and to promote a tweet or two for us. This was a successful endeavour with about 33% of attendees at Drupal Camp Dublin coming from overseas, mostly the UK and Belgium.

So, what was talked about? We'll here's a lightning talk blogpost of each topic (yes, I managed to get to every session across two tracks, except for one session that was on the same time as one of my own).

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

This was a shortened version of Stella's talk from DrupalCon. A fascinating look at the quirks of building a website with localised content, rather than just multilingual content. For example, showing a blog post to users in Europe, but not to users in Asia; an English language report in US English for the US audience and UK English for the rest of the world. There are more pitfalls than you might think, but Stella covered them all.

Surviving your job when having ADD

Levi Govaerts gave a wonderful talk on how having ADD affects his life and work and strategies for coping. I tweeted to him later to say I'd love to see such a talk given to a larger audience, such as a DrupalCon audience. I hope this happens. Very insightful.

Lean Web Operations — Planning for the unpredictable

This was a talk from Jochen from FreistilBox. As usual, Jochen delivered a very engaging talk on "getting things done" with his typical humour and deep knowledge. In short - stop starting and start finishing.

A Headed Goal for SSE Airtricity League with Headless Drupal!

This talk wasn't so much a headless goal as it was a triple header. There was so much to get through here it took three very capable developers from Monsoon Consulting to deliver it, the talk focussed on building a Drupal backend for a headless Angular JS frontend for the Football Association of Ireland.

Clearing out the cruft - Using Migrate API to migrate a 12 year old site

Alan, from Annertech, has been maintaining the Athenry running club website for a long time, starting with Drupal 4.7. Each new major release of Drupal allows Alan to see what has changed about Drupal migration from version to version. In this talk he looked at the workflow needed and how to migrate from media in Drupal 7 to Media Entity Embed in Drupal 8 as well as migrating to paragraphs.

Estimates are dead, long live forecasting!

I apologise for turning this well-prepared talk into a discussion. But I couldn't stop asking inline questions because what Mike King was talking about had such a resonance for how developers work. Basically, we need to use data to let our clients know our 'forecast' of work completion. We cannot estimate with any accuracy.

One-click automated builds

Luis Rodriguez from Capgemini gave this talk on making your development workflow easier by automating as much as possible. I wish I knew as much as Luis about this kind of stuff.

Case study : making Commerce, Webform & Group play nicely together

Okay, we said strictly no case studies, but this one was worth it. Chandeep Khosa gave a great overview of how he has used webform and Drupal commerce along with the group module to allow quite complex pricing rules to deliver products to clients.

Live Performance Workshop: A top-to-bottom performance overhaul

Anthony Lindsay, from Annertech, shocked us all with some terribly bad code that would make a site very slow (the type of code we have seen and fixed for some of our clients). After we got over the shock, we set about fixing it, together, as a team with everyone giving whatever knowledge we had until we got the site from a 5 minute page load to a 2 second  page load.

Deploying Drupal (and anything else) with Fabric

This was the first  of Oliver Davies's talks, in which he demoed some very clever things he has been doing with Fabric to help his deployment workflow.

Back to the Future: No More Static Mockups!

Without doubt the best talk of the weekend, not just because it was by me! This was a version of the talk I gave at DrupalCon, where I go on my usual rant about why we need to stop sending clients photoshop mockups of their websites and start using PatternLab (or at least design in the browser).

Teaching Development via Drupal

I missed this talk because I was giving mine at the same time. From comments from people who were at it, I'm sorry I missed it. Apparently a great talk along the lines of "I am teaching CMS developer at a third level institute. What should I be teaching about Drupal".

There's more to code reviews than you might think

This was a great introduction from Daniel Shaw about how to get started with code reviews, why code reviews are not supposed to be scary, and how they can make your developers even better developers.

Drupal 8 Sitebuilding with Paragraphs, Display Suite & Configuration Management

Chandeep's second session. This time he gave a preview of how he uses paragraphs and display suite to allow him to deliver complex requirements without writing code, and also give the editor as good a user experience as possible.

TDD - Test Driven Drupal

This was Oliver Davies' second session. in this one, he expounded on why we should write tests, how to get started writing them, and - crucially - why using TDD can help you work faster and find bugs sooner.

A foundation in Drupal development with Docker

This was one of those sessions where I know very little about the topic but like to attend so I can at least gain some vocabulary about it. Ed Crompton didn't disappoint, and now at  least I know the difference between a Docker image and a container.

Growing an Agency Business: Tactics Vs Strategy

Bharat Sharma from Monsoon Consulting stepped in to give this talk when another speaker had to cancel. In it he dissected the process his company went through a few years back to re-shape themselves and the type of client they wanted to work with. There was a lot to take away from this talk for any company looking to scale.

A New Theme for Drupal Core?

I gave this presentation as the last one of the weekend. It was a short and simple overview of the work we are doing as the 'Out of the Box"' initiative for Drupal Core - building a demo installation profile for an imaginary food publishing magazine called Umami, which will become part of Drupal Core 8.5.x (if we meet our deadlines).

And that was it. Drupal Camp Dublin 2017 - in my opinion the best Drupal Camp we have had so far in Ireland.

Oct 25 2017
Oct 25

It's here! Lightning 2.2.1 provides a migration to the core media system that was introduced in Drupal 8.4.0.

This is a major milestone for us. One of the big advantages of using Lightning over vanilla Drupal or a roll-your-own solution is that as underlying modules evolve, Lightning maintains an update/migration path. This effectively creates a facade in front of media, workflow, and layout functionality. That functionality remains stable no matter what. Of course, this is in addition to the fact that Lightning provides all of that functionality out of the box. (Even though Media is now a part of core, it still doesn't provide the out of the box configuration, experience, and add-ons that Lightning does.)

Core Media migration was #2 in our list of major migrations. It was preceded by a migration from Layout Plugin to the core Layout Discovery module. Next up is Workflow which will involve migrating from Workbench Moderation to core's Workflows and Content Moderation modules.

Special thanks to phenaproxima who is at the intersection of the core, contrib, and Lightning work. To say the migration wouldn't have been possible without him is an understatement.

Want to try it out?

Update your existing codebase:

composer update acquia/lightning --with-dependencies
composer update drupal/core

Then check out our 2.2.0 -> 2.2.1 update instructions.

Or build a fresh codebase:

composer create-project acquia/lightning-project MY_PROJECT
Oct 14 2017
Oct 14

Metatag cannot directly extract an image url from a media field referenced by another entity.

I upgraded my site from Drupal 7 to Drupal 8 this week (yes, that's why it's running on Bartik - a PatternLab developed theme will be installed in time).

This morning I enabled the Metagtag module and set some defaults for page title, description, image, etc. The help notes on the image metatag field says "An image associated with this page, for use as a thumbnail in social networks and other services. This will be able to extract the URL from an image field." This is true, except in my case, all the image fields on the site use the Media Entity module, so they are entity reference fields rather than image fields.

When I put in a token of [node:field_main_image], the result in the outputted metatags was:

In that case, "Mark Conroy | DrupalCon Dublin 2017" is the name of the referenced media. I needed to output the image field of the referenced media.

After a little trial and error, I came up with this:


which outputs:

In this case, "field_main_image" is the name of the image field on my content type, and "field_m_image_image" is the name of the image field on my image media bundle.

If you wish to output a specific image style, you can append :default:url to the token like so:




To use the image media item's alt tag for your Twitter alt tag, you can do this:


I hope that helps!

Oct 11 2017
Oct 11

Seems like just yesterday since we held DrupalCon in Dublin, now we're back with our annual Drupal Camp Dublin.

This year's Drupal Camp Dublin has a great line up of speakers from Ireland and abroad, covering such topics as:

  • Building multi-lingual, multi-region websites (Stella Power)
  • Working as a developer with attention-deficit disorder - add (Levi Govaerts)
  • Planning for disruptions (Jochen Lillich)
  • Migrating from Drupal 4 to 5 to 6 to 7 to 8 (Alan Burke)
  • Automating deployments (Luis Rodriguez)
  • Working webform and commerce and paragraphs and display suites and more (Chandeep Khosa)
  • Live debugging a site that's giving issues (Anthony Lindsay)
  • Stop estimating, start forecasting (Mike King)
  • Deploy with Fabric, and test driven development (Oliver Davies)
  • Design in the Browser (yours truly, me, Mark Conroy)
  • Teaching web development at third level (Ruairi O'Reilly)
  • The QA process (Daniel Shaw)
  • Getting started with Docker (Ed Crompton)
  • The new theme coming to Drupal core (Mark Conroy)

And then there's some socials, and our Drupal Ireland AGM, and at least one other talk not announced yet, and ... you get the idea.

The full schedule is available on our website. There are some tickets left (only €20), get them before they are all gone.

Oct 08 2017
Oct 08

Have you been to an event recently involving free software or a related topic? How did you find it? Are you organizing an event and don't want to fall into the trap of using Facebook or Meetup or other services that compete for a share of your community's attention?

Are you keen to find events in foreign destinations related to your interest areas to coincide with other travel intentions?

Have you been concerned when your GSoC or Outreachy interns lost a week of their project going through the bureaucracy to get a visa for your community's event? Would you like to make it easier for them to find the best events in the countries that welcome and respect visitors?

In many recent discussions about free software activism, people have struggled to break out of the illusion that social media is the way to cultivate new contacts. Wouldn't it be great to make more meaningful contacts by attending more a more diverse range of events rather than losing time on social media?

Making it happen

There are already a number of tools (for example, Drupal plugins and Wordpress plugins) for promoting your events on the web and in iCalendar format. There are also a number of sites like Agenda du Libre and GriCal who aggregate events from multiple communities where people can browse them.

How can we take these concepts further and make a convenient, compelling and global solution?

Can we harvest event data from a wide range of sources and compile it into a large database using something like PostgreSQL or a NoSQL solution or even a distributed solution like OpenDHT?

Can we use big data techniques to mine these datasources and help match people to events without compromising on privacy?

Why not build an automated iCalendar "to-do" list of deadlines for events you want to be reminded about, so you never miss the deadlines for travel sponsorship or submitting a talk proposal?

I've started documenting an architecture for this on the Debian wiki and proposed it as an Outreachy project. It will also be offered as part of GSoC in 2018.

Ways to get involved

If you would like to help this project, please consider introducing yourself on the debian-outreach mailing list and helping to mentor or refer interns for the project. You can also help contribute ideas for the specification through the mailing list or wiki.

Mini DebConf Prishtina 2017

This weekend I've been at the MiniDebConf in Prishtina, Kosovo. It has been hosted by the amazing Prishtina hackerspace community.

Watch out for future events in Prishtina, the pizzas are huge, but that didn't stop them disappearing before we finished the photos:

Oct 03 2017
Oct 03

October 03, 2017

This article is about serving your Drupal Docker container, and/or any other container, via https with a valid Let’s encrypt SSL certificate.

Edit: if you’re having trouble with Docker-Compose, read this follow-up post.

Step one: make sure you have a public VM

To follow along, create a new virtual machine (VM) with Docker, for example using the “Docker” distribution in the “One-click apps” section of Digital Ocean.

This will not work on localhost, because in order to use Let’s Encrypt, you need to demonstrate ownership over your domain(s) to the outside world.

In this tutorial we will serve two different sites, one simple HTML site and one Drupal site, each using standard ports, on the same Docker host, using a reverse proxy, a container which sits in front of your other containers and directs traffic.

Step two: Set up two domains or subdomains you own and point them to your server

Start by making sure you have two domains which point to your server, in this example we’ll use:

  • test-one.example.com will be a simple HTML site.
  • test-two.example.com will be a Drupal site.

Step three: create your sites

We do not want to map our containers’ ports directly to our host ports using -p 80:80 -p 443:443 because we will have more than one app using the same port (the secure 443). Port mapping will be the responsibility of the reverse proxy (more on that later). Replace example.com with your own domain:

docker run -d \
  -e "VIRTUAL_HOST=test-one.$DOMAIN" \
  -e "LETSENCRYPT_HOST=test-one.$DOMAIN" \
  -e "[email protected]$DOMAIN" \
  --expose 80 --name test-one \
docker run -d \
  -e "VIRTUAL_HOST=test-two.$DOMAIN" \
  -e "LETSENCRYPT_HOST=test-two.$DOMAIN" \
  -e "[email protected]$DOMAIN" \
  --expose 80 --name test-two \

Now you have two running sites, but they’re not yet accessible to the outside world.

Step three: a reverse proxy and Let’s encrypt

The term “proxy” means something which represents something else. In our case we want to have a webserver container which represents our Drupal and html containers. The Drupal and html containers are effectively hidden in front of a proxy. Why “reverse”? The term “proxy” is already used and means that the web user is hidden from the server. If it is the web servers that are hidden (in this case Drupal or the html containers), we use the term “reverse proxy”.

Let’s encrypt is a free certificate authority which certifies that you are the owner of your domain.

We will use nginx-proxy as our reverse proxy. Because that does not take care of certificates, we will use LetsEncrypt companion container for nginx-proxy to set up and maintain Let’s Encrypt certificates.

Let’s start by creating an empty directory which will contain our certificates:

mkdir "$HOME"/certs

Now, following the instructions of the LetsEncrypt companion project, we can set up our reverse proxy:

docker run -d -p 80:80 -p 443:443 \
  --name nginx-proxy \
  -v "$HOME"/certs:/etc/nginx/certs:ro \
  -v /etc/nginx/vhost.d \
  -v /usr/share/nginx/html \
  -v /var/run/docker.sock:/tmp/docker.sock:ro \
  --label com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy \
  --restart=always \

And, finally, start the LetEncrypt companion:

docker run -d \
  --name nginx-letsencrypt \
  -v "$HOME"/certs:/etc/nginx/certs:rw \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --volumes-from nginx-proxy \
  --restart=always \

Wait a few minutes for "$HOME"/certs to be populated with your certificate files, and you should now be able to access your sites:

A note about renewals

Let’s Encrypt certificates last 3 months, so we generally want to renew every two months. LetsEncrypt companion container for nginx-proxy states that it automatically renews certificates which are set to expire in less than a month, and it checks this hourly, although there are some renewal-related issues in the issue queue.

It seems to also be possible to force renewals by running:

docker exec nginx-letsencrypt /app/force_renew

So it might be worth considering to be on the lookout for failed renewals and force them if necessary.

Edit: domain-specific configurations

I used this technique to create a Docker registry, and make it accessible securely:

docker run \
  --entrypoint htpasswd \
  registry:2 -Bbn username password > auth/htpasswd

docker run -d --expose 5000 \
  -e "VIRTUAL_HOST=mydomain.example.com" \
  -e "LETSENCRYPT_HOST=mydomain.example.com" \
  -e "[email protected]" \
  -e "REGISTRY_AUTH=htpasswd" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ 
  --restart=always -v "$PWD"/auth:/auth \
  --name registry registry:2

But when trying to push an image, I was getting “413 Request Entity Too Large”. This is an error with the nginx-proxy, not the Docker registry. To fix this, you can set domain-specific configurations, in this example we are allowing a maximum of 600M to be passed but only to the Docker registry at mydomain.example.com:

docker exec nginx-proxy /bin/bash -c 'cp /etc/nginx/vhost.d/default /etc/nginx/vhost.d/mydomain.example.com'
docker exec nginx-proxy /bin/bash -c 'echo "client_max_body_size 600M;" >> /etc/nginx/vhost.d/mydomain.example.com'
docker restart nginx-proxy

Edit: Reverse proxy on Drupal 8 or 9

Thanks to @wells on this issue and nitin.k on this issue for pointing me in the right direction on how Drupal can know its base url should be HTTPS. In order to use modules such as social_auth_google and metatag which require Drupal to know its public URL even if it is behind a reverse proxy, you need to figure out the reverse proxy IP.

To do so temporarily install devel_php on your site, and then go to /devel/php and enter dpm($_SERVER['REMOTE_ADDR']);. This will give you a result such as It is not the same IP as what you get when you ping your URL, or when you inspect the headers the reverse proxy sends to Drupal.

Then add this to your settings, and clear your cache:

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = [''];


You can now bask in the knowledge that your cooking blog will not be man-in-the-middled.

Please enable JavaScript to view the comments powered by Disqus.
Sep 28 2017
Sep 28

Do you remember, I recently wrote about implementation of a small but handy extension for config search in Magento1? I have become so used to it, that I had to do the same for Magento 2. And since I heard many rumors about improved contribution process to M2, I also decided to make it as a contribution and get my hands “dirty”.

Since the architecture of the framework has drastically changed, I expected many troubles. But in fact, it was even a little bit easier than for M1. From the development point of view it was definitely more pleasant to work with the code, but I also wanted to test the complete path to the fully merged pull request.

Step #0 (Local dev setup)

For the local setup I decided to use Magento2  docker devbox, and since it was still in the beta state I ran the first command without any hope for smooth execution. But surprisingly I had no issues with the whole set up. By executing few commands in terminal and cup of coffee, Magento 2 was successfully installed and ready to use. Totally positive experience.

Step #1 (Configuration)

All I had to do is to declare my search model in di.xml, not too hard, right ?)



Step #2 (Implementation)

Implementation of search itself was trivial, we just have to look for matches for a given keyword in the ConfigStructure object using  mb_stripos().



Step #3 (View)

The same as for M1, the result of the search is a list of URLs to the matched configuration label. When the user clicks the selected URL, they are redirected to the config page and the searched field is highlighted.

That would be it regarding the implementation :)

Step #4 (Afterparty)

Too simple to believe? You are right. I thought that it is enough for submitting the PR. But I completely forgot about tests :) This one of main requirements for accepting pull request by Magento Team.

Since all implemented code was well isolated (had no strict dependencies), it was pretty easy to write tests. I have covered most of the code with unit tests, and for the main search method I wrote the integration test.


I would like to point out that during the whole cycle of the pull request, I had fast and high-quality support from the Magento team. They were giving useful recommendations and consulted me sometimes even during their vacations. This is what I call outstanding interaction with the community!

My special thanks to  Eugene Tulika and  Igor Miniailo, and of course Dmitrii Vilchinskii for the idea for creation this handy feature.

Sep 25 2017
Sep 25

Estimates are dead, long live forecasting!

Tuesday, 26th September, 11:20-11:45

Speaker: Mike King
Track: Project Management

In his session, Mike will outline the good, the bad and the downright wasteful aspects of estimates and how they’re used, before contrasting it all with the positive benefits of using forecasting to communicate a range of outcomes and how this can be communicated with the wider team. There will also be a follow-up BoF to share open source tools so that everyone can take home this new set of skills.

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

Tuesday, 26th September, 14:15-15:15

Speaker: Stella Power
Track: Site Building

Thinking of adding multilingual functionality to your Drupal 8 site? Then this is the session for you. Here Stella will take you through the fundamentals of configuring your content to be multilingual and the various pitfalls and lessons learned along the way.

Core Accessibility: How are we doing, and what can we do better?

Wednesday, 27th September, 10:45-11:45

Speakers: Andrew Macpherson (and Théodore Biadala and Kristen Pol)
Track: Core Conversations

In Drupal core, we've been making great strides incorporating accessibility best practices into the UX and markup. It’s not only important to help increase Drupal product adoption in some markets (e.g. the public sector) that have strict accessibility requirements, but accessibility is important to make Drupal sites reach the most people with varying backgrounds and abilities. This can be good for business. It is certainly good for our humanity.

Back to the Future: No More Static Mockups!

Wednesday, 27th September, 15:45-16:45

Speaker: Mark Conroy
Track: Front End

This presentation will be an easy-going rant about how to make things better for frontend developers and will start by taking a look at Photoshop, SketchApp and InVision and how these tools fail to deliver. We will then move on to talking about designing in the browser and how tools such as PatternLab and Fractal can help solve these problems. Finally, we'll look at how we can (easily) integrate PatternLab with Drupal, thereby going 'Back to the Future'.

Live Performance Workshop: A top-to-bottom performance overhaul

Thursday, 28th September, 13:00 - 13:25

Speaker: Anthony Lindsay
Track: Performance and Scaling

Come participate in an interactive performance workshop. Here you'll get to view a broken site and all the awful performance blunders that were made, and more importantly how to fix them.

There's a brief overview of each of our speaking slots. Be sure not to miss them, and don't forget to come say hello to us afterwards!

Photo credit: Franz Jachim

Sep 24 2017
Sep 24

While the Drupalcon webseite has a good few pointers to the well-known major tourist attractions, as locals we'd like to share our knowledge about some of our favourite places with you! So here a few recommendations:

Viennese Wine and Heurige

If you stay for the weekend after the Con, you can join the Vienna Wine Hiking day, which I can highly recommend. There are 3 possible easy hikes through the vineyards with lots of options to stop for tasting gorgeous wine directly from the producers. Furthermore you may enjoy great views of the city even if the wheather is not that great!

If you stay long enough, don't miss it! You can find details and options at https://www.wien.info/en/shopping-wining-dining/wine/wine-trail

If you cannot join the wine hiking day, be sure to visit some Viennese "Heurige" (wine taverns). Good options would be the Schreiberhaus or a little bit closer to the city-center Sissy-Huber.

Otto Wagner Buildings

The famous Viennese Jugendstil architect Otto Wagner (and friends) has left lots of traces back in the city. Apart from some of the subway stations (you won't be able to miss them) we'd recommend looking at the following buildings at least from the outside:

Cafés & Restaurants

Kaffee Alt Wien: An interesting mixture between a traditional Vienese Cafe and a "Beisl" (pub). The food can be recommended too, simple but authentice Viennese dishes, like Gulasch, Schnitzel and a variety of sausages. Although the Kaffee Alt Wien is mentioned in travel guides, it has not lost its athmosphere and is visited by tourists and locals alike.

Flatchers: Great steaks for a reasonable price. There are two restaurants in the same street: A French bistro with georgous French athmosphere and a larger one in American style.

Brunnenmarkt: A local market in one of the lesser known districts, lots of immigrants of south-eastern Europe and Turkey run market booths and Cafés around a nice plaza. You'll find great athmosphere and good food options: Kent, Cafe Ando, Cay Cafe am Yppenplatz

Barfly's: A cuban style cocktail bar with authentic athmosphere and music!

Wolfgang Ziegler

On drupal.org:


Drupal evangelist since 2005, Drupal Core contributor & contrib maintainer, TU-Vienna graduate (Information & Knowledge Management)

Sep 24 2017
Sep 24

Over the years Drupal distributions, or distros as they’re more affectionately known, have evolved a lot. We started off passing around database dumps. Eventually we moved onto using installations profiles and features to share par-baked sites.

There are some signs that distros aren’t working for people using them. Agencies often hack a distro to meet client requirements. This happens because it is often difficult to cleanly extend a distro. A content type might need extra fields or the logic in an alter hook may not be desired. This makes it difficult to maintain sites built on distros. Other times maintainers abandon their distributions. This leaves site owners with an unexpected maintenance burden.

We should recognise how people are using distros and try to cater to them better. My observations suggest there are 2 types of Drupal distributions; starter kits and targeted products.

Targeted products are easier to deal with. Increasingly monetising targeted distro products is done through a SaaS offering. The revenue can funds the ongoing development of the product. This can help ensure the project remains sustainable. There are signs that this is a viable way of building Drupal 8 based products. We should be encouraging companies to embrace a strategy built around open SaaS. Open Social is a great example of this approach. Releasing the distros demonstrates a commitment to the business model. Often the secret sauce isn’t in the code, it is the team and services built around the product.

Many Drupal 7 based distros struggled to articulate their use case. It was difficult to know if they were a product, a demo or a community project that you extend. Open Atrium and Commerce Kickstart are examples of distros with an identity crisis. We need to reconceptualise most distros as “starter kits” or as I like to call them “puppies”.

Why puppies? Once you take a puppy home it becomes your responsibility. Starter kits should be the same. You should never assume that a starter kit will offer an upgrade path from one release to the next. When you install a starter kit you are responsible for updating the modules yourself. You need to keep track of security releases. If your puppy leaves a mess on the carpet, no one else will clean it up.

Sites build on top of a starter kit should diverge from the original version. This shouldn’t only be an expectation, it should be encouraged. Installing a starter kit is the starting point of building a unique fork.

Project pages should clearly state that users are buying a puppy. Prospective puppy owners should know if they’re about to take home a little lap dog or one that will grow to the size of a pony that needs daily exercise. Puppy breeders (developers) should not feel compelled to do anything once releasing the puppy. That said, most users would like some documentation.

I know of several agencies and large organisations that are making use of starter kits. Let’s support people who are adopting this approach. As a community we should acknowledge that distros aren’t working. We should start working out how best to manage the transition to puppies.

Sep 19 2017
Sep 19

I got a request today from a former colleague:

@marky I need some quick practical selling points why our designers should stop using dedicated design programs and design in the browser instead. 2 or 3 should do!

I guess he had to add in the "2 or 3 should do" knowing I'd go off on a long rant. In either case, I gave him 5, here they are:

1) Don't Build Up Expectations for Your Client

When you use a static tool such as Photoshop, you build up expectations for your client. What usually happens is that all titles are the same length, all images have the same crop proportions, etc. But when your client adds real content, the rendered page looks like an approximation of the design.

With design in the browser, what you show to your client is what your client will get.

2) Quicker for Implementing Change Requests

If changes are needed, they can very quickly implemented by editing classes in CSS (for example, the new theme for Drupal core has a base font size of 15px. We’ve decided to up that to 16px - which means one line of code in CSS - instead of redoing all the Sketch files). The same is true if you want all image in a teaser list to position on the right hand side of the text instead of the left. Doing this in Phhotoshop is a pain.

3) QA Starts Sooner

QA testing can start waaaay sooner than using Photoshop or Sketch. As the client is signing off the designs (or each component) they are also signing off the frontend QA. Using something like PatternLab with Twig you can have almost the whole Drupal theme developed in this design phase, and then get the backend developers to output the HTML that will match it.

4) Signoff is on Real Devices

Client will see the designs in a real device and how they will render on that device - not looking at a mobile design on a desktop screen. When a client looks at a pdf of their new site, they will zoom out until the text is unreadable to see the whole page on one screen. No one will ever view the site like that though. Design in the browser forces your client to view the site as it will finally be viewed, in whatever browser/device they choose.

5) Multiple Variations is a Breeze

It’s very easy to show different variations of the same design (e.g. blog post with short title, long title, no image, etc) to see how the design stacks up against these real-world scenarios. This takes much longer in Photoshop or Sketch if you need to create individual mockups for each. Again, using PatternLab for this, you can have a base blog.json file (with the data for the blog component) and then extend that with each variation you need blog~long-title.json (with just the title variable changed), blog~long-title-no-image.json (you get the idea).

Okay so, at this stage it looks like I'm not a fan of Photoshop (I'm not) or InVision (I'm definitely not), or Sketch (I am! I love Sketch). So is there are place for these tools? Well, yes. If you designer likes to use them, and can work quicker with them (maybe he/she is not a frontend developer), then by all means they should use them. As each component is designed, they can then hand them over to the frontend team to implement them as HTML/CSS/JS, and it's these files that are sent to the client for signoff.

Won't that take longer? Initially, yes - it'll take a little longer to get the designs to the client, but the payoff is in how much sooner QA is done, how the client doesn't expect a unicorn to eventually be delivered as that is not what they signed off, and ... at some stage you are going to have to write the necessary HTML/CSS/JS, so why not early on?

After all that, what was the response from the person who said "2 or 3 should do"?

/me has started wondering how to turn @marky off now that he has started him...

I'll be speaking about this at DrupalCon Vienna on Wednesday 27th September at 15:45. My talk is titled: "Back to the Future: No More Static Mockups!" I'd love to chat with you there.

Here's a video of a similar talk from Frontend United in Athens this year:

Sep 16 2017
Sep 16

While preparing for my DrupalCamp Belgium keynote presentation I looked at how easy it is to get started with various CMS platforms. For my talk I used Contentful, a hosted content as a service CMS platform and contrasted that to the “Try Drupal” experience. Below is the walk through of both.

Let’s start with Contentful. I start off by visiting their website.

Screenshot: Contentful homepage

In the top right corner is a blue button encouraging me to “try for free”. I hit the link and I’m presented with a sign up form. I can even use Google or GitHub for authentication if I want.

Screenshot: Contentful sign up page

While my example site is being installed I am presented with an overview of what I can do once it is finished. It takes around 30 seconds for the site to be installed.

Screenshot: Contentful installer page

My site is installed and I’m given some guidance about what to do next. There is even an onboarding tour in the bottom right corner that is waving at me.

Screenshot: Contentful dashboard

Overall this took around a minute and required very little thought. I never once found myself thinking come on hurry up.

Now let’s see what it is like to try Drupal. I land on d.o. I see a big prominent “Try Drupal” button, so I click that.

Screenshot: Drupal.org homepage

I am presented with 3 options. I am not sure why I’m being presented options to “Build on Drupal 8 for Free” or to “Get Started Risk-Free”, I just want to try Drupal, so I go with Pantheon.

Screenshot: Try Drupal landing page

Like with Contentful I’m asked to create an account. Again I have the option of using Google for the sign up or completing a form. This form has more fields than contentful.

Screenshot: Pantheon signup page

I’ve created my account and I am expecting to be dropped into a demo Drupal site. Instead I am presented with a dashboard. The most prominent call to action is importing a site. I decide to create a new site.

Screenshot: Pantheon dashboard with no sites

I have to now think of a name for my site. This is already feeling like a lot of work just to try Drupal. If I was a busy manager I would have probably given up by this point.

Screenshot: Pantheon create site page

When I submit the form I must surely be going to see a Drupal site. No, sorry. I am given the choice of installing WordPress, yes WordPress, Drupal 8 or Drupal 7. Despite being very confused I go with Drupal 8.

Screenshot: Pantheon “Choose your upstream page”

Now my site is deploying. While this happens there is a bunch of items that update above the progress bar. They’re all a bit nerdy, but at least I know something is happening. Why is my only option to visit my dashboard again? I want to try Drupal.

Screenshot: Pantheon Drupal 8 installer

I land on the dashboard. Now I’m really confused. This all looks pretty geeky. I want to try Drupal not deal with code, connection modes and the like. If I stick around I might eventually click “Visit Development site”, which doesn’t really feel like trying Drupal.

Screenshot: Pantheon dashboard for new site

Now I’m asked to select a language. OK so Drupal supports multiple languages, that nice. Let’s select English so I can finally get to try Drupal.

Screenshot: Drupal installer language selection

Next I need to chose an installation profile. What is an installation profile? Which one is best for me?

Screenshot: Drupal installer select installation profile

Now I need to create an account. About 10 minutes ago I already created an account. Why do I need to create another one? I also named my site earlier in the process.

Screenshot: Drupal configure site form part 1

Screenshot: Drupal configure site form part 2

Finally I am dropped into a Drupal 8 site. There is nothing to guide me on what to do next.

Screenshot: New drupal site home page

I am left with a sense that setting up Contentful is super easy and Drupal is a lot of work. For most people wanting to try Drupal they would have abandoned someway through the process. I would love to see the conversion stats for the try Drupal service. It must miniscule.

It is worth noting that Pantheon has the best user experience of the 3 companies. The process with 1&1 just dumps me at a hosting sign up page. How does that let me try Drupal?

Acquia drops onto a page where you select your role, then you’re presented with some marketing stuff and a form to request a demo. That is unless you’re running an ad blocker, then when you select your role you get an Ajax error.

The Try Drupal program generates revenue for the Drupal Association. This money helps fund development of the project. I’m well aware that the DA needs money. At the same time I wonder if it is worth it. For many people this is the first experience they have using Drupal.

The previous attempt to have simplytest.me added to the try Drupal page ultimately failed due to the financial implications. While this is disappointing I don’t think simplytest.me is necessarily the answer either.

There needs to be some minimum standards for the Try Drupal page. One of the key item is the number of clicks to get from d.o to a working demo site. Without this the “Try Drupal” page will drive people away from the project, which isn’t the intention.

If you’re at DrupalCon Vienna and want to discuss this and other ways to improve the marketing of Drupal, please attend the marketing sprints.

Sep 09 2017
Sep 09

In a current project, I had to generate PDF documents based on custom entities on a Drupal 8 page. Obviously I decided to use the great Entity Print module together with the very popular Dompdf library. Formatting PDF has always been an annoying task, even if you use HTML and CSS based library. But they are getting better and better. After I have been using MPDF quite a long time in the past, I now tried Dompdf, as it seems to have the better CSS support, and it's also the chosen default library of Entity Print and gets shipped with it (when you do Composer installation). And I must say, it really works great. In combination with the Entity Print's debug view, you can get rather quick results, when building a PDF template.

Unfortunately, two problems cost my quite a lot of time to find out. And they are quite easy to trigger, so I'll share it with you now:

1. Tiny images in tables

I've made good progress in styling the PDF output, until I've inserted images and tried to render the PDF then: the images were even tinier than Donald's hands! ;)

I've finally found a bug report on Dompdf's Github page, telling that images inside tables can get really very small. Another user reported the same problem, while the project maintainer couldn't find a way to reproduce the problem. I was rather guessing that this has to do with different system environment, especially different PHP versions. My first reaction was to work around the problem and change the HTML markup because in this place I've decided to use a table for getting a two-column layout, as this has always been the easier approach when dealing with e-mail or PDF templates. However I knew, that I'll add a "real" table containing images later on. So I reported that I encountered the problem too. After quick response by the maintainer, I've decided to have a closer look on the problem.

Finally I've found out that it wasn't the alone inside a table that is causing the problem. It's finally triggered, when you have set a max-width CSS property on the image. Unfortunately Entity Print was shipping with a default CSS (which you can disable though) containing a "max-width: 100%" rule on elements - which is generally a good option (and the result of the solution for this issue).

Knowing this, it was easy to fix the problem by overriding the max-width property for images inside tables and setting the max-width to "none". I've opened up an issue for Entity Print and my fix has already been committed :)

2. Header and/or footer on every page

Adding a page header or footer on every page is basically very easy with Dompdf just by setting the position of the element to "fixed" - at least theoretically. Because there are at least two preconditions that must be met  and are not so obviously documented (or not at all):

  • The element(s) have to be part of the first rendered page. So adding a footer to the end of your markup is a bad idea. You should do it at the beginning. Since it's positioned fixed, there's no optical difference. However DomPdf needs this information during the rendering of the first page, otherwise it'll be too late (to have it on every page).
  • This one was hard to find out, haven't found it on any Stackoverflow page or Github issue or elsewhere, only by debugging: the footer or header must be a direct child of the body element in order to get it on every page!

I had to fight with the second requirement until I found out. I've added the footer information directly inside the entity template, while I left entity_print's page template as is. And there we have the div.page element per default. So you either have to add your header/footer in the entity-print template before div.page, or if you wanna render it in your node/entity template directly, you have to take care to override the entity-print template to not having any wrapper element!

Besides of these problems, it was really great to work with the library. The combination Drupal + Twig + Entity Print + Dompdf is a really powerful one :-)

Sep 08 2017
Sep 08

Vagrant 2.0 has just been released. Being who I am, I jumped at trying this out and testing if it worked well with my vagrant setup. I have entirely moved to DrupalVM since some time and wanted to see if it worked properly.

TL;DR, the DrupalVM part works fine, but there are other issues. I read the changelog to see what would break and the breaking change section only lists one change related to Ansible. Since DrupalVM is built with Ansible, I was not very sure but gave it a try anyway. Anyway, considering that it was only one breaking change, I thought the problems, if any, should be easily fixable.

I downloaded the MacOS build of Vagrant 2 and installed it normally. I confirmed the update by running vagrant version.

~/w/test > vagrant version Installed Version: 2.0.0
Latest Version: 2.0.0

You're running an up-to-date version of Vagrant!

Okay, all good. I tried running vagrant plugin update and the problem appeared.

~/w/test > vagrant plugin update \Updating installed plugins...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

conflicting dependencies rb-fsevent (= 0.9.8) and rb-fsevent (= 0.10.2)
Activated rb-fsevent-0.10.2
which does not match conflicting dependency (= 0.9.8)

Conflicting dependency chains:
rb-fsevent (= 0.10.2), 0.10.2 activated

rb-fsevent (= 0.9.8)

Gems matching rb-fsevent (= 0.9.8):

I was a little concerned but ignored this for the time. I tried a vagrant plugin repair and it said it was successful, but didn’t fix the problem. Anyway, moving on…


I tried DrupalVM next. I used my setup-drupalvm script to quickly setup DrupalVM. I just had to change default.config.yml to remove vagrant-hostsupdater from automatic installation. (I prefer vagrant-hostmanager). Running vagrant up, and it all went through smoothly. There was only one change from the usual output I see on a fresh vagrant up (which is related to the breaking change I mentioned above):

==> test: Checking for guest additions in VM...
==> test: Setting hostname...
==> test: Configuring and enabling network interfaces...
==> test: Exporting NFS shared folders...
==> test: Preparing to edit /etc/exports. Administrator privileges will be required...
==> test: Mounting NFS shared folders...
==> test: Configuring cache buckets...
==> test: [vagrant-hostmanager:guests] Updating hosts file on active guest virtual machines...
==> test: [vagrant-hostmanager:host] Updating hosts file on your workstation (password may be required)...
==> test: Running provisioner: ansible...
Vagrant has automatically selected the compatibility mode '2.0'
according to the Ansible version installed (

Alternatively, the compatibility mode can be specified in your Vagrantfile:

After the machine was provisioned (which happened smoothly), I opened up dashboard.test.dev in my browser and everything looked perfect.

Drupal VM dashboard

I cross-checked it with phpinfo() output and verified PHP 7.1.9 was installed and as FPM.

The only problem which now remains is to do with plugins and I am going to ignore it for now. Future versions of Vagrant might fix the version constraint that causes the problem. For now, the plugins themselves are working.

vagrant-auto_network (1.0.2)
- Version Constraint: > 0
vagrant-bindfs (1.0.8)
- Version Constraint: > 0
vagrant-cachier (1.2.1)
- Version Constraint: > 0
vagrant-hostmanager (1.8.7)
- Version Constraint: > 0
vagrant-share (1.1.9, system)
- Version Constraint: > 0
vagrant-vbguest (0.14.2)
- Version Constraint: > 0

Please let me know in comments if there is a way I can fix the version constraint problem. I hope you found the post useful.

Aug 31 2017
Aug 31

The web has no shortage of digital trends that will pop up on your radar, and one whose momentum has increased over the last couple years is decoupling. In simple terms, the concept of decoupling means separating the frontend of your website from the backend. This means the components of a site that a visitor sees and interacts with (menus, page content, widgets) are built and displayed by software running in the web browser. The backend software, running on the server, accepts requests from the frontend for these different page components and returns them as essentially raw data.

With this full separation of concerns, each half of the website can focus on what it does best; the backend focusing on business logic and retrieval of data, the frontend focusing on display and user experience.

How Do We Achieve This?

This is where JavaScript frontend frameworks come into play. Popular ones include Angular, which we at FFW have used quite successfully on projects, or React, Ember, and many others too numerous to count. These frameworks enable a skilled developer to build a complex and highly interactive frontend without constant page refreshes that require the full attention of the backend.

To do this, it helps to have a powerful and flexible content management system, which doesn’t require lots of custom programming and reinvention of the wheel. This is where Drupal comes in. We’ve done this quite successfully with Drupal due to its robust and flexible API. Drupal 8 pushes this even further with its API first approach, and superior set of APIs.

Drupal 8 Services

Things like the built-in RESTful web services and superior content modeling tools do most of the work of building that backend system. Eventually the backend will communicate effortlessly with frontend systems and other applications and third-party service. This makes Drupal an effective content hub for distributing your content to any application that needs it.

Pros and Cons

When introducing anything new there are various factors to consider. A decoupled fronted can improve perceived performance and enhance interactivity. It can also do something very difficult with a fully baked content management system, where all rendering is handled by the backend. It enables developers and development teams to design and build a frontend almost completely independently from how the backend is developed. Your templating system, how CSS is built and managed, preferred methods for design components, all this can be treated like a separate project. Your designers and frontend developers don’t even have to have skills specific to the CMS you are using.

Life, of course, is never perfect. The main drawbacks become apparent when really thinking about how all this affects the way your site is built and managed. When using a CMS like Drupal, you start losing a lot of the key features that make it the tool it is. Can you use Drupal’s site building tools to, for example, change the order of fields displayed on a page? Things like that are now being hard-coded into the frontend. We also start losing some of the multilingual features, it plays less nice with metatags and other SEO features, and potentially increases the amount of work and skills needed to build your website. Those aren’t all unsolvable problems, but you’ll need to consider them when deciding where you are willing to devote the development time to building a decoupled site.

Two Approaches

If you understand the concept of separating your frontend and backend, you’ll start seeing two approaches while doing your research. “Headless” Drupal, which just means a fully decoupled frontend. The other is “progressive” decoupling. “What the heck is that?” you might say. Progressive decoupling blurs the line between what the frontend and backend are doing, rather than fully decoupling the two.

Progressive decoupling starts with a traditional website approach, with no decoupling, and the backend doing most of the work to produce the web page. Then, individual components that are deemed more interactive or take longer to produce are handled by the frontend. This approach plays a little more nicely with tools already present in your CMS, and is easier to implement on any existing website.

New Hotness Can Burn

Decoupling a website is a great way to solve some problems of the traditional website module. We certainly advocate it for projects suffering from those problems. But, as with all technology, make sure your use case has the need before forcing technology onto it. The decoupling approach can revolutionize your site visitor’s experience, but if forced to fit it can create new problems, increase development time, and inflate your costs.

A simple site, with few frontend performance problems, largely static content, and little need for things like user- or region-specific content, is not likely to need something like a decoupled frontend. My advice: Let your requirements always inform your solution. Technology is great at solving problems, but don’t let it create them by misapplying it to your project. If you want to talk about whether decoupled Drupal might be right for you, please contact us.

Aug 23 2017
Aug 23

[Photo credits: Ben Finklea, Jan 2017. Photos captured from iPhone video shot at Texas Grappling Challenge Brazilian Jiu-Jitsu tournament in Cedar Park, Texas.]

My Drupal developer friends and I (like any friendship) don’t always see eye-to-eye. While we have much in common—we both want stylish, high-performing websites—in some areas our goals are different. This can create the appearance of conflict. However, after working through the issues (or hitting the mats, as they say in Brazilian Jiu-Jitsu), we can find common ground and mutual respect.

In Drupal 8 SEO, I lay out a list of modules that should be installed on your Drupal website to enhance SEO. I wrote this book for marketers and provide the step-by-step details you need to increase Google ranking, website traffic, customers, and revenue. While most of these activities can be completed without a developer, there are times when more expertise is needed.

Recently, one of my readers contacted me with a problem: his developer was pushing back on SEO recommendations with “I don’t see anything here that looks critical to your SEO activities.” Respectfully, I disagree. I’ve done hundreds of Drupal SEO projects and have the results to prove that these methods work.

Who’s right? You decide. Read on as a Drupal Developer and the Drupal SEO Guy spar. This blog post is based on a real email exchange and includes pushbacks and recommendations for one particular project.

Common Drupal 8 SEO Pushbacks: “You don’t really need it.”

Drupal Developer: The Admin Toolbar is totally not related to SEO. If there is something you can’t find, just use the “Go To” link on the toolbar and type to search admin pages.

Ben Finklea, the Drupal SEO Expert: I agree that this is not *necessary* for SEO. It's necessary to make Drupal easier to use, though. The problem with using the toolbar is that it's difficult to know what to search for if you don't know Drupal well. In fact, I'm experienced in Drupal 4, 5, 6, 7, and 8 and still don't always know where to look. I use the Coffee module when I know exactly where I want to go and Admin Toolbar when I don't.

Drupal Developer: I’m skeptical of the benefits of using RDF UI.

Ben: RDF UI simply exposes the existing RDF. I have used RDF with much success. Every product you have on your site should have this. You can display ratings, reviews, price and more in google listings. It's amazing. The added product information gives your search listing more presence and searchers are more likely to click through to your website.

Drupal Developer: Linkit and D8 Editor Advanced Link are helper modules and aren’t relevant.

Ben: Internal linking is important for SEO. The only reasons you don’t need these modules is if you will never publish content on your site, never write blog posts or articles, or never create special listing pages for products or promotions. These modules make linking easier and more accurate. Linkit makes it easy to link on important keywords across the site. Is it necessary? No. But with Linkit, you reduce the time spent adding those links to your body content. D8 Editor Advanced Link prevents a problem that new sites won’t have right away. As sites grow and age, content is moved around (in Drupal parlance: the path is changed) and that breaks links and causes redirects. Redirects are bad for SEO. This module makes sure that links are formed properly so that they don't break even when content is moved.

Drupal Developer: Creating a sitemap isn’t useful for our platform. We don’t want to expose our human visitors to this.

Ben: Sitemaps can be very useful for bots and spiders (although not all of them use it), and it can also be helpful to site visitors if configured properly. I wouldn't put thousands of products on it. Instead, put your product category pages, taxonomies, tags, etc.

Drupal Developer: Scheduler isn’t relevant unless you feel the need to put front page callouts on a rotation.

Ben: This module works great for product promotions and blog posts, or a product released on a certain day or time. Leave it off until you need it.

Drupal Developer: AdvAgg is relevant to performance but not SEO specifically. I don’t think it makes a perceivable difference for users on high-speed connections but could save some seconds for mobile users on slow connections.

Ben: Speed is very important to great SEO results and the user experience. I talk about speed and Google SEO in this article: How to Improve Drupal 8 Website Performance. But you don’t have to take my word for it, Google has indicated the speed matters in this blog. You can also learn more at moz.com.

Google has also placed high significance on quality mobile interactions. That’s not surprising given that mobile devices have overtaken desktops as the primary search device.

“Mobile has grown so fast that it’s now the leading digital platform, with total activity on smartphones and tablets accounting for two-thirds of digital media time spent…”

Source: comScore

Having a slow page speed can cause higher bounce rates and lower average time on page. It can also mean that search engines crawl fewer pages which can lower your SEO results.

Common Drupal 8 SEO Pushbacks: “It’s too much work.”

Drupal Developer: The Easy Breadcrumb module would require a rework of our theme and will cause too many problems.

Ben: If you have a budget to make the changes, I highly recommend it. Easy Breadcrumb helps with SEO especially when you tag the breadcrumbs using Schema.org's RDF or JSON-LD. This improves your listing in Google by displaying the breadcrumb instead of the URL. Your search results will be clearer and should get more searchers clicking on your links.

Breadcrumbs are especially good for users on e-commerce sites. This article by BigCommerce has a great explanation of the importance of using breadcrumbs. According to the article, breadcrumbs not only improve click-through rates but also make it easier for search engines to crawl the site.

Drupal Developer: Yoast SEO makes sense. But keep in mind it depends on the Metatag module which takes a long time to configure.

Ben: Yes, Yoast SEO requires the Metatag module. Configuring it is indeed very time-consuming. It takes me about a day per site and I’m a pro.

Drupal Developer: The Metatag module can be used to add these page header tags, but I can do better. The Metatag module lets you dynamically add tags based on entity content but those tags can be added through our theme layer as well. I can program the website to use meta tags well outside the capability of the metatag module.

Ben: Metatags are mission critical. It's much more than just a tag. It's used by search engines, social sites, crawlers, browsers, etc. in a lot of ways. For example, the description tag is what shows up as the description in a Google search. The OpenGraph image tag determines the image that Facebook will show when a product is shared on their site. Twitter tags have a similar function.

In your past, presumably you tried it and it didn't work so you programmed a different solution. It’s possible your products are complicated and can't use straightforward Drupal SEO methods, but I can't really say so I'll withhold comment for now.

Generally speaking, unless it’s absolutely necessary, don't go out of your way to recreate functionality that a module already has. Other modules work well with Metatag—like the Realtime SEO for Drupal and the Schema Metatag module.

(Psst...Would you like to learn more about these and other Drupal 8 SEO modules? Check out Drupal 8 SEO.)

Drupal Developer: The Drupal AMP module would require a new mobile theme, so this is not one you should install.

Ben: AMP is more for news sites, so if you don’t have a lot of news, skip it. However, if you want your news to be top-of-page for Google, make sure this fits with your theme.

Common Drupal 8 SEO Pushbacks: “I can do this, but...”

Drupal Developer: Yes, we can do this but W3C Validator is more or less a one-time thing, not something that needs to be run regularly since we won’t be doing regular markups.

Ben: I agree and good call. Do this on the W3C site instead of using the module. As of right now, the module doesn't work like it should. I've posted a support ticket to Drupal about this but it hasn’t been resolved.

Drupal Developer: Search 404 sounds like it might be useful.

Ben: Search404 helps users and bots find content that has moved or find a relevant page if it has been deleted. As products go away and are replaced with new ones, you don't want to strand your visitors.

Drupal Developer: Diff gives you a view into what has changed between revisions, so this is just a content management aid. If you want you can install it, but revisions are not supported for products, promo boxes, brands, collections or mini-sites so I say don’t bother.

Ben: I use Diff to identify revisions that may have caused an increase or decrease in website traffic, but I didn’t know that it doesn’t work on products.

And the Winner Is...

Okay, shake hands–the match is over. Who won? You did! When the developer and I are on the same page, we can agree on most things. We just need to get our wires uncrossed and work out a solution that makes everyone happy. Sometimes that means I need to know more about your specific installation, and other times, the developer needs a little more education on Drupal SEO.

If you haven’t read the book, I highly recommend getting Drupal 8 SEO to learn more about my recommendations. While the book is written for marketers, if you are a developer, you may find it useful too. If you have any questions about how your Drupal SEO should be set up, give me a call.

Aug 17 2017
Aug 17

Decoupled—or “headless”—content management systems have been trending in the last few years. This web development strategy, in its most basic form, is a “write once, publish anywhere” technology that separates the content from the presentation layer. Well, um...what the heck does that mean? It means that you can publish a piece of content and then use different systems to display that blog post on a computer, a mobile device, a voice-based system like Amazon’s Alexa, or even a smart watch. Basically, it allows developers to write to many different platforms without having to tediously recreate the wheel each time. (I think…)

It is a hot topic in the Drupal community. In fact, Acquia is holding Decoupled Developer Days this weekend (August 19-20 in NYC). Much of the conversation is still occurring in the developer community, but it is also important for marketers to understand the implications of this strategy as well. The strategy has its place, but is not always the best option for several reasons.

But first, here are some terms marketers should know. Then I’ll share what factors you should consider when deciding whether to follow a decoupled CMS strategy.

What is Decoupled (Headless) Drupal? Some Terms to Know

A decoupled CMS is one where the CMS serves as the backend to store, maintain and edit content but no longer necessarily provides the delivery of that content. It’s considered “headless” because it means chopping off the part of the CMS that provides the web display.

A headless CMS usually delivers content through an API, which means that it can deliver content anywhere, on any device. You will often hear this strategy as API-first.

API-first is an approach that starts with the RESTful API as the communication between the backend, headless CMS and user devices such as websites, mobile applications, wearable, IoT devices and more.

Content as a Service (CaaS) is like a Software as a Service (SaaS), headless CMS. Think of Drupal as the host, managing the content and offering that content as a service. This separated content management and display means that the content is easily used by other sites and apps.

The decoupled CMS approach is industry wide and affects more than just those using Drupal. But if you have a Drupal website, you will want to know more about headless Drupal. In normal installations, Drupal provides a way to store data, an administrative area to manage content, and a way to display data. In a headless installation, the data display functionality is replaced with an API to the data. Then, a different framework uses that API to access, format, deliver, and display the data.

Drupal 8 includes a RESTful Web Services module in its core which plays well into adopting a headless CMS. This module along with other powerful modules such as Views and Paragraphs makes Drupal a good choice for a decoupled application.

Benefits of Decoupled Drupal to Marketers

With a headless CMS, it is possible to build flexible, responsive, interactive experiences for your users. New devices are popping up all the time and one of the big questions that marketers need to ask is how they will provide content on them. When the user interface is decoupled from the CMS, the logic for displaying content on each device is on the front-end and can provide full control of the user experience in its native tools. In other words, you, as a content provider, no longer need to worry about how the content is going to be displayed as that is handled on the device itself.

Decoupled CMS may also be faster. When the logic is on the front-end interface, the back-end CMS can be streamlined. The back-and-forth interaction happens in real-time in the browser.

At this point, you might be wondering why everyone isn’t heading toward decoupled CMS. After all, as a marketer, being able to get content out to any device quickly is paramount. However, there is a price to be paid for this ability. In many cases, that price is quite high.

Reasons Why Marketers May Not Want to Decouple Drupal

Drupal is a complete CMS with years and millions of hours of development behind it to provide a full-featured system. Going headless bypasses the value that Drupal brings to content delivery. You lose a lot of functionality that must be re-created on the front end. That will cost you more in development time and expense. Often, headless sites need multiple layers of complexity to gain back the advanced features that you have lost by rejecting the full Drupal system.

For example, if you need multi-lingual content, you will pay more for that functionality with custom development for a decoupled Drupal backend.  Meanwhile, the full Drupal CMS offers multilingual support out of the box.

When you choose to use a decoupled Drupal strategy it is also important to consider the impact on SEO. You will lose standard SEO functionality and SEO will take considerably more time and money.

Here are three examples of real-life problems we have faced when working with customers who have decoupled Drupal 7 or 8 websites:

  • Meta tags are not automatically output. While the Metatag module was installed and properly configured, the data wasn’t being pushed to the page. Search engines weren't seeing them. Extra code had to be written to retrieve the meta tags from Drupal. This took weeks of lost time and dozens of hours between the developer and the SEO team.

  • Decoupled sites that have non-standard URLs. If you are changing the way that URLs work, other things break, like Sitemap. This is another case where functionality had to be re-created. In fact, we opted to not use the available modules and use a third party service to crawl and create a sitemap manually because the development overhead would have been too costly. This functionality is trivial in a non-headless environment, not to mention free.

  • The current crop of SEO SAAS tools do not work on headless sites. If you use any third party tools like Moz, you’re out of luck when it comes to crawling and understanding your decoupled site. While those services may add support for headless CMS in the future, as of today, many hours of manual evaluations and looking at pages that used to take seconds with an automated tool are required.

And a lot more. Almost none of the recommendations I make on my SEO Checklist work with decoupled Drupal sites without some kind of additional development time and effort.

Keep in mind that all of this custom development means that you are responsible for maintenance and upkeep of this code. If there are issues or bugs with your website, your IT team will need to resolve them. Security problems? You’re largely on your own.

Can You Justify Headless Drupal?

If all you need is a CMS to manage content for a responsive website, headless Drupal is overkill and will actually slow time to market. The times to consider decoupling Drupal is when you have several different uses for the same content such as multiple websites displaying the same articles, various front-end device, and custom user experiences. Or, perhaps when you need truly real-time updates to a site where performance would be killed by using Drupal’s entire system (and even then, there are ways to do this without headless).

Powdr Ski Resorts could justify using headless Drupal because they have multiple websites for their network of ski resorts as well as around 50 unique events each year. They need flexibility to have different designs on the front-end but uniform data on the backend to manage content. The website project was completed by Elevated Third, Hoorooh Digital, and Acquia. You can learn about the challenges of this project in this blog: Decoupled Drupal: A 10,000 Ft View.

When the right situation exists, you still need to evaluate the financial impact of decoupling Drupal.

Additional costs for decoupling Drupal include:

  • Custom development to recreate existing Drupal capabilities

  • Custom development to create the data hand-off

  • Custom development for each device

  • Additional development to implement SEO

  • Added SEO maintenance and reporting costs

  • Maintenance of custom development

You may evaluate these costs and still find that headless Drupal is the way to go for your business. But in the majority of cases, the costs are too high.

And just to be perfectly clear: I’m not anti-headless Drupal. In fact, I’m very much in support of it when there are very good and specific applications that call for that particular set of functionality. It’s not bad, it’s just not the right tool for most sites.

That said, I’m very anti-headless when it’s just “for fun” or “that's the way the cool kids are doing it”. That’s crazy and expensive. Unfortunately, that’s what I’m seeing more and more. Implementing headless Drupal for static brochure websites is irresponsible and will drive people away from using Drupal in the long run.

Drupal SEO Services

Before you head down the decoupled Drupal path, be sure to factor in extra time and expense for Drupal SEO development. Volacci can work with your development team to ensure that the right functionality is available in the finished product. Contact us for an evaluation of your SEO needs.

Aug 17 2017
Aug 17
  • Advisory ID: DRUPAL-PSA-2017-002
  • Project: Drupal contributed modules
  • Version: 7.x, 8.x
  • Date: 2017-Aug-16


The Drupal Security Team is now aware that the Views ajax access bypass vulnerability (DRUPAL-SA-CONTRIB-2017-068 and SA-CORE-2017-004) released 16 Aug 2017 is more severe than originally announced, because many widely used contrib modules don't have access restrictions set on the default views they provide. Any view that does not have access controls on the default (master) display may be vulnerable. The vulnerability does not require any authentication to be exploited. A successful exploit results in some non-public data being made public.

Sites running versions of Views prior to 7.x-3.17 or Drupal 8 core prior to version 8.3.7 (including Drupal 8.1.x and 8.2.x) should update immediately. Drupal 7 core is only affected if the Views module is enabled.

If you are unable to update Views, you can mitigate this by editing views that contain sensitive data in the Views UI and making sure they utilise one of the permission controls - such as 'require a role' or 'require a permission'. See Views permissions manual page for more information.

Contact and More Information

The Drupal Security Team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security Team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Aug 15 2017
Aug 15

So you just finished building an awesome new website on Drupal, but now you’ve run into a new dilemma. How do optimize the site for search engines? Search engine optimization, or SEO, can be overwhelming, but don’t let that cause you to ignore certain things you can do to help drive traffic to your website. There’s nothing worse than spending countless hours to develop a web application, only to find out that users aren’t able to find your site. This can be extremely frustrating, as well as devastating if your company or business heavily relies on organic traffic.

Now there are countless philosophies of SEO, many of which are well-educated assumptions of what Google is looking for. The reality is that no one knows exactly how Google’s algorithm is calculated, and it doesn’t help when their algorithm is constantly being updated. Luckily, there are a few best practices that are accepted across the board, most of which have been confirmed by Google as being a contributing factor to search engine ranking. This blog is going to focus on a few of those best practices and which modules we have found to be helpful in both our Drupal 7 and Drupal 8 projects.

So, without further ado, here is our list of Drupal modules you should consider using on your site to help improve your SEO:

XML Sitemap Module

As the name suggests, XML Sitemap allows you to effortlessly generate a sitemap for your website. A sitemap allows for Google and other search engines like Bing and Yahoo, to be able to easily find and crawl pages on your site. Is a sitemap necessary? No. But if it helps the pages of your site to become easily discoverable, then why not reduce the risk of not having pages of your site indexed? This is especially important if you have a large site with thousands or even hundreds of pages. Having a sitemap also provides search engines with some valuable information, such as how often the page is updated and the level of significance compared to other pages on your site.

XML Sitemap allows you to generate a sitemap with a click of a button, and best of all you can configure it to periodically generate a new sitemap which will add any new pages you’ve published on your Drupal site. Once your website has a sitemap, it is recommended to submit that sitemap on Google Search Console, and if you haven’t claimed your website on Google Search Console yet, I would highly advise doing so as it will provide you with helpful insight such as indexing information, critical issues, and more.

Metatag Module

The next Drupal module is one that can really help boost your search engine ranking and visibility. Metatag is a powerful module that gives you the ability to update a large number of various meta tags on your site. A meta tag is an HTML tag which contains valuable information that search engines use to determine the relevance of a page when determining search ranking. The more information available to search engines such as Google, the better your chances will be that your pages will rank well. The Metatag module allows you to easily update some of the more popular tags, such as meta description, meta content type, title tag, viewport, and more.

Adding and/or updating your meta tags is the first step of best SEO practice. I’ve come across many sites who pay little to no attention to their meta tags. Luckily, the Metatag module for Drupal can help you easily boost your SEO, and even if you don’t have time to go through and update your meta tags manually (which is recommend), the module also has a feature to have your tags automatically generated.

Real-Time SEO for Drupal Module

The Real-Time SEO for Drupal module is a powerful tool on its own, but it is even better when paired with the Metatag module which we just finished discussing. This module takes into account many SEO best practices and gives you a real-time analysis, ensuring that your content is best optimized for search engines. It will inform you if your content is too short, how readable your posts are, and also provides you a snapshot of how your page will appear in Google. The other helpful information it provides is regarding missing or potentially weak tags, which is why I mentioned that this module and the Metatag module work extremely well together. Real-Time SEO for Drupal can let you know how to better improve your meta tags and by using the Metatags module, you can quickly update your tags and watch in real-time how the changes affect your SEO.

The Real-Time SEO for Drupal module is a simple, yet incredibly useful tool in helping you see the SEO health of your pages. If you are just getting into SEO, this is a great place to start, and even if you’re a seasoned pro this is a nice tool to have to remind you of any meta tags or keyword optimization opportunities you may be missing.

Google Analytics Module

The final module is the Google Analytics module. Google Analytics is by far the most widely used analytics platform. The invaluable information it provides, the numerous tools available, and the integrations it allows, make it a requirement for anyone looking to improve the SEO of their Drupal website. This Drupal module is extremely convenient, as it does not require a developer to have to mess with any of the site's code. After installing the module all you have to do is enter the web property ID that is provided to you after you setup your account on Google Analytics.
From the Google Analytics module UI, you have a number of helpful options, such as what domains to track, which pages to exclude, adjusting page roles, tracking clicks and downloads, and more. The Google Analytics module for Drupal is another great tool to add to your tool belt when trying to best improve your SEO.

Final Thoughts

This list of helpful SEO modules for your Drupal 7 or 8 site could easily have been much longer, but these are a few key modules to help you get started. SEO is something that should not be ignored, as I mentioned in the beginning of the blog, it’s a shame to build a site only to find that no one is actually visiting it, but using these modules properly can definitely help prevent this issue. if you would like to learn of other great modules to help your SEO, please leave a comment below and I'll write a follow-up blog.

Aug 10 2017
Aug 10

 “By failing to prepare, you are preparing to fail.” Benjamin Franklin

This age-old advice from Benjamin Franklin is applicable in many situations but is a clear truth when you are upgrading or migrating your website to Drupal 8. The fact is: if you do not plan for SEO in your website transition, you will see a drop in Google rankings and traffic.

Whitepaper Cover_Key Steps to a Successful Drupal 9 SEO Website Migration or UpgradeVolacci has over ten years of Drupal experience and has created meticulous, process-driven methods for SEO during website migrations or upgrades. We've detailed all of our steps to a successful transition in our new whitepaper: Key Steps to a Successful Drupal 8 SEO Website Migration or Upgrade. Download for free here.

We’ve seen it happen over and over again: prospective clients come to us, after completing a website migration without an SEO plan, desperate to get their rankings and search engine traffic back. They are getting those dreaded 404 errors because URLs have changed and they are missing valuable content from their old site. By failing to plan for SEO during the transition, they have prepared to fail in Google search results!

The best Drupal migration or upgrade starts with a plan. Starting with an SEO transition plan helps you avoid these problems. In fact, if done right, your traffic and rankings will improve.

What Does a Drupal 8 Migration Plan for SEO Look Like?

“If we could first know where we are, and whither we are tending, we could better judge what to do, and how to do it.” Abraham Lincoln

Just as Abraham Lincoln suggests, the first thing to do is evaluate where you are, where you want to be and then determine how to get there. A Drupal SEO transition plan should include the steps below. Following these steps will take you from where you are with your old website to where you want to be with your new one.

  1. Establish a ranking and traffic baseline on the old site.
  2. Agree upon goals for the newly migrated website.
  3. Evaluate your customer and how you target them.
  4. Analyze the competition. Steal their best ideas.
  5. Review content: keep, improve, or redirect.
  6. Implement technical SEO for the new website.
  7. Evaluate your landing and transaction pages for conversions.
  8. Communicate with Google and other sites about the change.
  9. Measure and monitor your new website before, during and after the migration.

Learn more about each of these steps in Volacci’s new whitepaper: Key Steps to a Successful Drupal 8 SEO Website Migration or Upgrade. You’ll see key metrics to evaluate, questions to answer, and other things to consider in a complete Drupal SEO transition plan.

Transition to a New Drupal 8 Website with Confidence

"Once you have commitment, you need the discipline and hard work to get you there." Haile Gebrselassie

The greatest SEO transition plan is useless if you don’t follow through. Once the plan is in place, the hard work begins. Upgrading or migrating your website to Drupal 8 can be time-consuming and costly, but the results may be essential to improving your digital presence and business growth.

You don’t have to do it alone. Volacci offers specialized Drupal SEO services so that you can make the transition with confidence.  Contact us to sign up for a free migration evaluation or give us a call at (512) 989-2945 x201.

Aug 03 2017
Aug 03

Sometimes you want to react differently, when the current script is running in a command-line environment. Drupal does this internally e.g. for session handling.

In Drupal 7, there was a dedicated drupal_is_cli() function.

In Drupal 8, this function was removed because you can instead directly check the PHP_SAPI constant:

if (PHP_SAPI === 'cli') {
  // Do stuff
Aug 02 2017
Aug 02

When migrating from Drupal 7 to Drupal 8, it is important to remember to migrate over the redirects as well. Without the migrations users will not find your content if for example: the redirect was shared on social media. Using the Migrate Plus module, it is quite simple to write a migration for the redirects. The Migrate Plus module contains some good examples on how to get started writing your custom migrations.

Write your node migrations

I am going to assume that you have written migration for some content types and have the group already written. Once those migrations have been written, in your database should now be a migrate_map_{name}_{type} table. This is where we will be able to find the imported node's new id which will be necessary for importing the redirects.

Write the yml file for redirect migrations

For example, let's say we have a module called blog_migrations. In that module we have a group for blog and a migration for a news and opinion content type. Inside the config/install directory add a new yml file called migrate_plus.migration.blog_redirect.yml where blog is the name of the group being migrated. This file will give an id, label, and the process to use for the migration.

id: blog_redirect
label: Path Redirect
migration_group: blog
  - Drupal 7
  plugin: blog_redirect
  key: blog
  rid: rid
  uid: uid
  redirect_source/path: source
    plugin: d7_redirect_source_query
    source: source_options
    plugin: d7_path_redirect
      - redirect
      - redirect_options
    plugin: default_value
    source: language
    default_value: und
  status_code: status_code
  plugin: entity:redirect

Write the migrate source

Create the file BlogRedirect.php in the module's src/Plugin/migrate/source folder.

namespace Drupal\apa_migrate\Plugin\migrate\source;

use Drupal\Core\Database\Database;
use Drupal\migrate\Row;
use Drupal\redirect\Plugin\migrate\source\d7\PathRedirect;

class BlogRedirect extends PathRedirect {

  public function query() {
    $query = $this->select('redirect', 'p')->fields('p')
      ->condition('redirect', '%user%', 'NOT LIKE');

    return $query;

  public function prepareRow(Row $row) {
    $current_status_code = $row->getSourceProperty('status_code');
    $status_code = $current_status_code != 0 ? $current_status_code : 301;
    $row->setSourceProperty('status_code', $status_code);

    $current_redirect = $row->getSourceProperty('redirect');
    $explode_current_redirect = explode("/", $current_redirect);

    $map_blog_array = array(
    if ($explode_current_redirect[0] == 'node') {
      $resource_type = $this->getDatabase()
        ->select('node', 'n')
        ->fields('n', ['type'])
        ->condition('nid', $explode_current_redirect[1])

      if (in_array($resource_type, $map_apa_array)) {
        $new_node_id = Database::getConnection('default', 'default')
          ->select('migrate_map_apa_' . $resource_type, 'm')
          ->fields('m', ['destid1'])
          ->condition('sourceid1', $explode_current_redirect[1])

        $new_redirect = 'node/' . $new_node_id;
        $row->setSourceProperty('redirect', $new_redirect);

Run the migrations

Using the config_devel module, now import the configuration into active store to be able to run the migration using:

drush cdi1 /modules/custom/blog_migration/config/install/migrate_plus.migration.blog_redirect.yml

Then run the actual migration:

drush mi blog_redirect

After running that you should now have migrated the two content type's redirects with the new node id they were given! Any questions, let us know in the comments below.

Jul 31 2017
Jul 31

On Friday, all the accepted sessions for DrupalCon Vienna were announced, and we are delighted to report that, once again, 5 of our 8 session proposals were accepted! With Acquia and Pantheon being the only companies receiving more acceptances, we are extremely proud of our achievement. It also means that given our size, Annertech has more speakers, per staff member, than any other agency in the world.

This is the second year in a row, where we have had 5 sessions accepted for DrupalCon, and, along with FreistilBox, are the only Irish web agency to be represented. Our sessions this year span a number of different tracks, namely Project Management, Site Building, Performance and Scaling, Front End and Core Conversations, and cover topics such as building multilingual sites in Drupal 8, project forecasting, debugging performance issues, component-based design/development, and accessibility. Congratulations to all our speakers!

Here's a quick run down of each session.

Live Performance Workshop: A top-to-bottom performance overhaul

Speaker: Anthony Lindsay
Track: Performance and Scaling

In this interactive workshop style presentation, we'll take a terrible, awful, broken sample site, look at all the nasty ways that its performance is terrible, and fix them, one by one. We'll get the audience involved with suggestions at every step of the way.

All examples will be taken from real life experiences, but no real sites will be harmed in the making of this demo/session.

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

Speaker: Stella Power
Track: Site Building

Having recently launched a Drupal 8 website with 13 distinct languages across 4 different regions, this session will take you from the basics of configuring your content to be multilingual through to making it localised in different regions and the various pitfalls encountered and lessons learned along the way.

Estimates are dead, long live forecasting!

Speaker: Mike King
Track: Project Management

In his session, Mike will outline the good, the bad and the downright wasteful aspects of estimates and how they’re used, before contrasting it all with the positive benefits of using forecasting to communicate a range of outcomes and how this can be communicated with the wider team. There will also be a follow-up BoF to share open source tools so that everyone can take home this new set of skills.

Back to the Future: No More Static Mockups!

Speaker: Mark Conroy
Track: Front End

This presentation will be an easy-going rant about how to make things better for frontend developers and will start by taking a look at Photoshop, SketchApp and InVision and how these tools fail to deliver (by building up expectations for clients and problems for implementers). We will then move on to talking about designing in the browser and how tools such as PatternLab and Fractal (basically HTML, CSS, and JS - the foundation of the web) can help solve these problems. Finally, we'll look at how we can (easily) integrate PatternLab with Drupal, thereby going 'Back to the Future'.

Core Accessibility: How are we doing, and what can we do better?

Speaker: Andrew Macpherson (and Théodore Biadala and Kristen Pol)
Track: Core Conversations

As we build Drupal websites, our exposure to the world of accessibility is often driven by the client or website owner. If they have accessibility requirements, we learn about these and try to meet their needs. Sometimes, it's driven by our own desire or need to make our websites consumable for more people.

In Drupal core, we've been making great strides incorporating accessibility best practices into the UX and markup. It’s not only important to help increase Drupal product adoption in some markets (e.g. the public sector) that have strict accessibility requirements, but accessibility is important to make Drupal sites reach the most people with varying backgrounds and abilities. This can be good for business. It is certainly good for our humanity.

Congratulations to Anthony, Stella, Andrew, Mike and Mark on their great achievement. We look forward to seeing these and all the other great sessions at DrupalCon Vienna in September. Hope to see you there!

Jul 29 2017
Jul 29

You know you want a t-shirt at DrupalCon Vienna, right? I do. read on...

At this year's DrupalCon in Vienna, the Drupal Association will only be providing 'free' t-shirts to people who purchase an early bird ticket (not exactly 'free' when the ticket costs almost €500) - a position I don't agree with (if you can't afford to give a t-shirt in a welcome pack when charging €500 a ticket, there seems to be something drastically wrong with your business model).

After a tweet last night of me sporting a Druid.fi t-shirt that I received at DrupalCon Dublin, I got thinking: how can we do something to make sure everyone gets a free t-shirt? Then I thought, 'why not provide our own'? Heaven knows we all have loads of them.

Today I'm sporting some haute couture from @druidfi pic.twitter.com/hZm4YYDZ4g

— Mark Conroy (@markconroy) July 28, 2017

So, here's the plan. Everyone brings a Drupal-related t-shirt to DrupalCon. It could be one from your company, one from a previous DrupalCon (I've never been to an non-European one so would like one from somewhere else in the world), one from your local DrupalCamp, a DevDays t-shirt, etc. Then, after the Driesnote, while we are all getting into position for the group photo you give that t-shirt to someone of a similar size to you, and they give you they one they brought (if they brought one). Feel free to bring more than one t-shirt to cover those who don't bring any (it might be some people's first Drupal event).

Oh, and by the way, my size is 'medium'!

Jul 28 2017
Jul 28

I’ve learned something incredible as the PHP Track Chair for Drupalcon Vienna. The Drupal Association has no way to invite PHP speakers to Drupalcon.

This blew me away when I first learned about it. After all the work to bring mainstream PHP to Drupal core, after all the outreach to PHP-FIG, after all the talks Drupalists have given at major PHP conferences, how is this possible?

You see, basically every other PHP conference covers their speakers' travel and accommodation costs. Drupalcon doesn’t, and never has. Historically it has to do with Drupalcon’s identity as a community conference, rather than a professional one. But it means the best PHP speakers never get to Drupalcon.

On one hand that’s great for our project: our speakers are all passionate volunteers! They’re specialists who care deeply about the project. On the other hand, it contributes to isolated, “stay on the island” thinking. If the only speakers we hear are Drupalists, where do we get new insights? If the only people at the BoF or code sprint table are Drupalists, how do we leverage the strengths of the broader PHP community? How do we contribute back? How do we grow?

Every year, the lack of financial support holds back major PHP contributors from speaking at Drupalcon. The maintainers of Composer, PHPUnit, and Guzzle want to come to Drupalcon, but we don’t make it possible. These people built and maintain the cornerstones of Drupal. Why do we hold them at arm’s length?

This year, as Drupalcon PHP Track Chair, I’m in a position to make some changes. So I invited two notable PHP speakers to come and join us at the con: Sebastian Bergmann, author of PHPUnit, and Michelle Sanver, president of @phpwomen. Today I’m announcing a very special GoFundMe campaign to pay the travel and accommodation for these two exceptional contributors.

I believe in the benefits of closer cooperation with the PHP community.

I believe there’s a lot we can learn from these people, and a lot we can teach them too.

And I believe that I’m not the only one.

We’ve estimated costs conservatively; this is not a lot of money. Anything we collect above and beyond their needs will go to the Drupal Association, but let’s be honest with ourselves: this campaign isn’t just about bringing Sebastian and Michelle to Drupalcon. Your donation shows the Drupal Association that you want to welcome contributors from other communities. You prove to them that their constituents want to bring in this kind of speaker. When you donate, you stand up for the kind of community you believe in.

Please donate, share, and tweet the campaign today.

Jul 25 2017
Jul 25

This is an example of anti-virus implementation with an Ubuntu server.

Our back office management solution allows users to upload files in various sections of the application for storage or file sharing. For this reason, checking of files for virus is an important advantage.

We use the ClamAV module integration from Drupal 8.

1) Install ClamAV on Ubuntu

Installation on Ubuntu server is straight forward.  However, it is better to install with clamav-daemon clamav-freshclam options for later settings

You can test with clamscan -r /home for instance

For further options you may refer to ClamAV website.

2) Install and set-up Drupal module

Module installation on Drupal 8 has no specific requirements.

As indicated on the module page, "Daemon mode" is preferred when executing the scan.

In the settings page (/admin/config/media/clamav), select Daemon mode (over Unix socket) in scan mechanism

You need to indicate the path for the socket pointing file; it can be found in the configuration file  : /etc/clamav/clamd.conf.

Input the file path into next setting:

3) Test

When uploading a file on the server via any upload interface, the file is scanned and validated. Scanning process is logged:

The Eicar test virus file is filtered when uploaded:

If you have implemented ClamAV with Drupal and have further comments, please feel free input your own.

Thank you.

Jul 18 2017
Jul 18

Simple Style Guide was created to be a fully flexible style guide for Drupal developers and site builders.

I’ve been using style guides for a while now. I can’t imagine developing any site without one, regardless of size. The idea behind this module was to enable devs and site builders to create a fully functional, living, style guide with only the elements you want and nothing more.

What I wanted was the ability to create one in a fast, effecient manner. No elements are required. No elements are added by default. And all this funcationality is fully accessible to site builders without having to write a single line of code.

Style Guide Settings

Default Patterns
You can choose from a set of very basic default patterns such as headings, text, lists, blockquote, horizontal rules, table, alerts, breadcrumbs, forms, buttons, and pagination. Chosen elements will appear on the style guide page. Choose as many default options as you like, or choose none.

Color Palette
You also have the ability to create a color palette by adding a hex color code, a class name, and usage descriptions (if desired).

Live Example of a Color Palette

Custom Patterns
You can also create custom patterns. Custom patterns can be any chunk of html that you want. There are no restrictions.

Add Any Custom Patterns

With these tools, I hope you will be able to create a very flexible style guide/pattern library. To view a live example of a working style guide, you can check out this page:


Jul 18 2017
Jul 18

Rather than creating friction for a user to show a password every time by clicking a checkbox, the password is revealed by default. In my own experience, I generally prefer password fields to be plain text almost all the time. It’s only when in public or during a presentation that I want to conceal passwords. And I’m not the only one…

There is another module that provides similar functionality. However, Simple Password Reveal takes a different approach than the Password Toggle module. They use javascript to add a checkbox to each password field in any and all forms. They also have a Drupal 7 version.

This module attempts to keep things simple by concentrating solely on the user login and user edit pages. If you need this feature on custom forms, on forms loaded by ajax, or for a Drupal 7 site then this module may not be for you.

Simple Password Reveal also uses form alters to add one checkbox per form, rather than one checkbox per input. So, for example, when you are on the user edit page you have three password fields — current password, new password, and confirm password. Rather than having a checkbox for each password field, this module only has one.

Jul 18 2017
Jul 18

The Simple MailChimp module for Drupal 8 intends to be the easiest way to add MailChimp integration to your site.

There is already a MailChimp module for Drupal, of course. There are several of them.

The main MailChimp module itself does a lot…

The MailChimp module allows users to manage email marketing efforts through MailChimp’s service. The module supports the creation and sending of campaigns, management of email lists and individual subscribers, and offers standalone subscribe and unsubscribe forms.

The problem with these modules is that they either do too much, or they are too specific in their use case. What I often need on my sites, more than anything else, is just a checkbox at the bottom of a form that will allow me to subscribe users to my MailChimp list if they choose to do so. Most likely, I need a checkbox at the bottom of many forms.

I don’t need to manage campaigns, lists, etc. from within my Drupal site. I just need a checkbox. Maybe a few options (MailChimp groups), but that’s it. And, again,I need it on all forms. I need it on my subsciption form of course, but I also need it on warranty registrations, user registrations, webforms, or any other form that may be included with my site.

This is where the Simple MailChimp module comes in.

Example form with “group” options.

Again, this module is not meant in any way to be as robust as the MailChimp module. You can’t manage subscribers. You can’t work with lists. It simply gives you the ability to add a checkbox for subscribing to a single MailChimp list, and also allows a field for one interest group option.

To configure this module, you will need your MailChimp API key, list ID, and a mapping of fields. See screenshot below. Under “Enabled Forms” you would enter one Drupal form id per line, and then map the email field (and other fields) to the appropriate merge fields.

Simple MailChimp supports most MailChimp field types:

  • text
  • zip_code
  • number
  • address
  • date
  • phone
  • birthday
  • website

The idea of this module is to be simple. It does not make any assumptions. It does not provide any public facing forms. It’s simply for adding a checkbox to existing forms.

Download Simple MailChimp and try it out.

Jul 18 2017
Jul 18

One of my pet peeves is searching for a local event and finding details for that event… 3+ years ago.

Many Drupal sites feature some sort of event type node. It’s really anything with a start date, and likely, an end date. The problem is, most developers don’t take into account whether or not that content should live on once the end date has come and gone.

Perhaps, in some instances, keeping that content on your site makes sense. In most cases though, it does not.

For instance, my 3 year old was really into dinosaurs. I knew there was a dinosaur exhibit coming to town, but I didn’t quite remember the name. Searching online provided quite a few local results. And many of those results were for events in the past.

Discover the Dinosaurs (06/21/2014)
(event has since been unpublished!)

(event has since been unpublished!)

Dino Dig! (06/02/2015)

Event from 2 Years Ago

Discover the Dinosaurs Unleashed (02/18/????)

Sometimes sites will even have past events ranking higher in search results than upcoming events.

There’s a whole other blog post I could write about how useful it is to have the year accompanying the day and month on web content — particularly tech blog posts. Was this written in February of this year or 2006? How can I know?!?

For Drupal sites, there’s a relatively easy fix. It requires a small custom module and the contributed Scheduler module.

The Scheduler module is simple and great. Simply enable it for your content type, and enable, at the very least, the unpublish setting. Once that is set up, create a custom module and invoke the hook_entity_presave() function.

This code is pretty self explanatory. All I’m doing is checking to be sure it’s an event node type that’s being saved, and if so, find the start and end date values to be used when setting the “unpublish_on” field.

You’ll of course have to make sure your node type and field names match up.

Once that’s set up, any time an event is saved, your node is scheduled to unpublish one day after the end date.

If you have a Drupal 7 site, this same idea can be applied. The code in the hook_entity_presave() will be a bit different.

I wish I could start a massive movement to help clean up web content that should have been unpublished or removed long ago. Until then, hopefully this article finds a few devs so that they can ensure their site isn’t one of those sending out poor results.

Jul 18 2017
Jul 18

This tutorial is for managing Drupal (>=8.1) with composer.

What is composer?

Git practices:

put /vendor in .gitignore

put /modules/contrib in .gitignore

Install site:

composer install


composer config repositories.drupal composer https://packages.drupal.org/8

ALWAYS install modules using composer. Forget about Drush or even manual download!!

composer require drupal/{module_name}:{module_version}
Where {module_version} example:

8.x-1.1 => 1.1

8.x-2.2.0 => 2.2.0

We can support updates by saying 1.* which means next time you make composer install or update it will update to newer minor version if exists, but won't update to 2.x.


Don't install module manually or through Drush.

Don't change anything in modules source code. Patch it and add patch through composer.json.

Don't use composer manager module, this is no more needed as of Drupal 8.1

Uninstall a module:

Always uninstall a module in this 2 step way:

drush pm-uninstall {module_name}
composer remove drupal/{module_name}


You can always see latest library and module versions installed in composer.lock file.

Deploying modules to other devs or production:

Now you added a module locally through composer and want to push it? Since modules are now ignored in git, only thing that will be pushed is depenency in composer.json. Therefore to deploy the module, each developer will need to rebuild its dependencies using 

"composer install".

Drupal configuration manager will take care if the module is enabled or not. However order must be respected so you should import new configuration only after composer install is run, otherwise you might get a error.

So good practice after git pull is:

composer install

drush cim

drush cr

Drupal 8 composer starterkit:


Q:What if I downloaded a module manually or through Drush?

A: Just re-add it using composer require drupal/{module_name}:{module_version}

Make sure its in modules/contrib folder.

Jul 18 2017
Jul 18

Export configuration:

drush cex

Import configuration:

drush cim


When working on project with other developers ALWAYS do following:

git pull

drush cim

drush cr

{...DO YOUR WORK...}

drush cex

git push (if there where commits in meantime you will have to do git pull)

Not following this order might delete your own or your colleagues work! Try to keep {...DO YOUR WORK...} as short as possible, having it in this state for couple of days might bring you conflict when trying to merge.

Jun 29 2017
Jun 29

Coding style?

Building software is a complex and sometimes tedious process in which you make errors and mistakes. Testing for errors is mostly done by running your website / code through tests either manually or automatically.

Checking for your code style like formatting and documentation flaws you can use a code sniffer. For PHP you can run phpcs using PHP_CodeSniffer.

Drupal core provides core/phpcs.xml.dist to tell phpcs what to test for.

How to run it

Run all tests on current directory.

cd core
../vendor/bin/phpcs -p -s

where -p shows the progress and -s does a sniff.

It result in

............................................................   60 / 7477 (1%)
............................................................  120 / 7477 (2%)
............................................................  420 / 7477 (6%)
...........................S................................  480 / 7477 (6%)
............................................................  540 / 7477 (7%)

............................................................  780 / 7477 (10%)
...............S......S.....................................  840 / 7477 (11%)
............................................................  900 / 7477 (12%)
............................................................  960 / 7477 (13%)

............................................................ 1320 / 7477 (18%)
............................................................ 1380 / 7477 (18%)
.......................................SSSSSSSSSSSSSSSSSS... 1440 / 7477 (19%)

Check for Drupal standards

Using the switch --standard=Drupal you can check your code for Drupal related stuff. This uses coder.

cd core
../vendor/bin/phpcs --standard=Drupal modules/views/views.module

FILE: ...sers/clemens/Sites/drupal/d8/www/core/modules/views/views.module
  92 | ERROR   | [x] Inline comments must end in full-stops,
     |         |     exclamation marks, colons, question marks, or
     |         |     closing parentheses
  94 | ERROR   | [ ] If the line declaring an array spans longer than
     |         |     80 characters, each element should be broken
     |         |     into its own line
 116 | ERROR   | [ ] If the line declaring an array spans longer than
     |         |     80 characters, each element should be broken
     |         |     into its own line
 117 | ERROR   | [ ] If the line declaring an array spans longer than
     |         |     80 characters, each element should be broken
     |         |     into its own line
 120 | ERROR   | [x] Each index in a multi-line array must be on a
     |         |     new line
 121 | ERROR   | [x] Each index in a multi-line array must be on a
     |         |     new line
 121 | ERROR   | [x] Each index in a multi-line array must be on a
     |         |     new line
 121 | ERROR   | [x] Each index in a multi-line array must be on a
     |         |     new line
 121 | WARNING | [x] A comma should follow the last multiline array
     |         |     item. Found: ]


Note the last line telling some stuff can be automatically fixed. Awesome!

Not interested @ all

You can filter on the sniff you are interested in using the --sniff option.

cd core
../vendor/bin/phpcs --standard=Drupal modules/views/views.module --sniffs=Drupal.Commenting.HookComment

FILE: ...sers/clemens/Sites/drupal/d8/www/core/modules/views/views.module
 249 | WARNING | Format should be "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz_bar().", "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz-bar.html.twig.", "* Implements
     |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
     |         | Implements hook_foo_BAR_ID_bar() for block
     |         | templates."
 274 | WARNING | Format should be "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz_bar().", "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz-bar.html.twig.", "* Implements
     |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
     |         | Implements hook_foo_BAR_ID_bar() for block
     |         | templates."
 287 | WARNING | Format should be "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz_bar().", "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz-bar.html.twig.", "* Implements
     |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
     |         | Implements hook_foo_BAR_ID_bar() for block
     |         | templates."
 638 | WARNING | Format should be "* Implements hook_foo()."
 650 | WARNING | Format should be "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz_bar().", "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz-bar.html.twig.", "* Implements
     |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
     |         | Implements hook_foo_BAR_ID_bar() for block
     |         | templates."
 827 | WARNING | Format should be "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz_bar().", "* Implements hook_foo_BAR_ID_bar()
     |         | for xyz-bar.html.twig.", "* Implements
     |         | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.", or "*
     |         | Implements hook_foo_BAR_ID_bar() for block
     |         | templates."

Time: 157ms; Memory: 12.75Mb

More info


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