May 27 2019
May 27

Why Would One Use a Dev-Master Branch?

We've all done it, especially in the Drupal world. We've searched and searched for that perfect contrib module that does almost everything we need. When we find it, we rejoice, only to find out that there's no alpha, beta, release-candidate, or stablerelease available. We comb the commits and repo, looking for clues as to why it's as tagless as a quality cotton undershirt (no, I'm not being paid by big clothing. However, if they were interested in sponsoring me for any reason, I'm open to that conversation.) Nothing sticks out, like a quality cotton undershirt with no tag.

Sorry, I just bought some new shirts and this is the only analogy I can think of because they're soooo soft, but I won't mention the brand until I get sponsor money.

Maybe it's something else. Perhaps we've run into a problem with an external API changing and the contrib module hasn't been keeping up. We go to the issue queue to start an issue, but like good, little developers, we first search for something like what we've run into. A-ha, there it is! Someone else has found it, fixed it, and the maintainer committed it, but we don't have a tagged release yet. What are we to do? We want to manage our dependencies with composer, but we haven't learned how to use composer.json to manage patches yet. We decide to throw caution to the wind and composer require drupal/some_module:dev-master

Feel good about it?

WELL YOU SHOULDN'T!

The Risks of Non-Tagged Dependencies

Recently, I ran into an issue where another developer on a project was doing some updates and ran the ever-troublesome composer update. Why is this a risk? Well, to put it simply, if your package is locked at dev-master then it's not locked at a tag so it's only locked to a branch. Since the dev-master branch is where the updates happen, it's a good chance that the package maintainer is eventually going to merge in a few commits to this branch and make some updates. It's even possible that the functionality will be changed by A LOT down the line.

Imagine, if you will, that we found that Xyz API had changed significantly and went through the process outlined above. We found the right module with the updates committed from the issue queue and we required the dev-master package.

Six months later the project maintainer decides to commit and merge a completely revamped version of the module to dev-master. A security PSA is released on d.o and it becomes time to make some updates.

[ [email protected] ~/docroot ]$ composer update
Using version dev-1.x for drupal/xyz_module
./composer.json has been updated
Gathering patches for root package.
Loading composer repositories with package information
....    
15/15:        https://ftp.drupal.org/files/projects/xyz_api-8.x-dev-master.zip    
Finished: success: 15, skipped: 0, failure: 0, total: 15 
Package operations: 13 installs, 2 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
....
Writing lock file
Generating autoload files

What just happened? Well, if we look at the diff of our composer.lock file, we'll notice that there's been a change right around here:

"name": "drupal/xyz_module",
"version": "dev-1.x",
"source": {                  
  "type": "git",
  "url": "https://git.drupal.org/project/xyz_module",
-    "reference": "722692cd27591385dc694a04561fd1a9ace1c78f"
+   "reference": "91385dc7cd27569ace1c94a0456226a78f921fd1"
  },

Uh-oh...

Now we don't have the same commit, and if we're not paying attention then stuff is going to break.

What Should Have Happened

We have a couple of options here. Option one would be to include the changes from the issue queue as a patch within the composer.json file. That way, the next time we run composer update we'll see the patch fail and know it may be time to check the issue associated with the patch for resolution.

Alternatively, we can lock dev-master at a certain commit. This is done very similarly to the way that we lock a package to a version. Instead of a ~ or^, we're going to explicitly declare the commit hash.

composer require drupal/xyz_module:722692cd27591385dc694a04561fd1a9ace1c78f

Where everything after the : is the hash number of the commit. This can usually be found in the URL of a repo or, if you've tested the d.o gitlab waters, you may notice the icon to the left of a commit message that shares similarities with a copy icon.

Image of a copy to clipboard icon

Now, use that freshly copied hash and lock in your dev-master to prevent tears in the future.  Trust me on this.

May 27 2019
May 27

Have you thought of hiring a remote developer?

Here at Sooperthemes, we stumbled upon the challenge of looking for remote talent to hire, specifically a remote developer. With this in mind, we scoured the internet for the best websites where you can find a remote developer to hire. Hiring remote staff is a completely different process, compared to hiring an on-site employee. However, this also comes with a lot more freedom from where to choose talent for your business, since remote staff hiring usually gives access to a bigger pool of candidates from different countries or even different continents! This list has a focus on finding remote developers, however, it can also be used to search for other classes of remote professionals. Having said that, here are the top 10 places from where you can hire a remote developer:

Upwork

Upwork is the first on the list of places from where to hire remote employees. It has a lot of job bidding which can drive the cost of hiring down. However, a lot of job bidding can also lead to price fixation and a drop in the quality of work, it’s a double edged sword. Currently, they have an escrow account that is put in place in order to protect both parties involved in the deal, the client and seller. Lately however, there have been a number of negative reviews, from both sides, the clients and sellers. On top of that, there are fees to be paid when using their system in order to make the payment. A workaround for this is to use the platform to make contact with the remote developer and to take the rest of the business outside of the platform.

Freelancer.com

Freelancer.com is similar in concept with Upwork. They do provide a huge pool of talent, however, with a great pool of people to choose from, there are chances to stumble upon untalented workforce. It is also great for project based work. On the other hand, it can get quite pricey, with service fees of 3%. Freelancer.com is the 2nd go-to place were Sooperthemes is looking for remote developers.

Jobrack

Are you searching for labour from Eastern Europe? Then Jobrack is for you. Jobrack prides itself by providing Eastern European talent that work for less money than their Western counterparts. This way businesses can save money while also being able to acquire skilled workforce from the remote corners of Eastern Europe. Jobrack is the Eastern European website dedicated to remote  hiring.

TopTal

TopTal claims to provide the top 3% talent in the industry. They have a rigorous screening session that basically ensures that the people that are selected are indeed top notch professionals. Because of this, TopTal doesn’t have a rating system in place, since it's already implied that they have the best that the market has to offer. On the other hand, hiring off of TopTal will generally result in generally bigger fees to be paid, since talent is usually more expensive compared with lower skilled workforce. If you have a budget and want to cut to the chase, while also saving time on the screening process, then TopTal is the best place for you to find highly skilled workforce.

Guru

Guru is another platform that is similar to Upwork and Freelancer. However, compared to the abovementioned, Guru has better search parameters that enable you to pinpoint the right talent for the job. On top of that, they do have a pay-back feature in case the client is not satisfied with the quality of the work that was delivered to him. One downside is that Guru has a 2.5% handling fee every time a client is making a payment towards the employee. On the other hand, there is a cash back of 3.5% if the payment is done through check, e-check or wire transfer.

Fiverr

Fiverr is the most straightforward platform on this list. You can find here a lot of sellers that are selling their services at a starting price of 5$. However, if you decide you need more complex work done, then you can choose a more expensive package, that will be able to fulfill your higher expectations. Not only that, but if you’re unsatisfied with the work received, then you are able to get a revision from your seller if the package does include them in the price. Some sellers will charge more money for an increased amount of revisions for the project. On top of that, Fiverr is really protective over the buyers at the detriment of the seller, which is good for buyers but sometimes results in unfair results for sellers. This might scare away sellers who can find business elsewhere on better terms.

Indeed

Indeed is a platform that is continuously scouring the internet for job openings. On Indeed, you have the option to be find remote talent, although at a much slower rate than on other platforms. Indeed is not a dedidacated remote staffing website, however there might still be some hidden gems hidden.

GetACoder

If you’re looking to hire more technical staff, like a remote developer, then GetACoder is the right platform on our list. The platform is focused on being able to provide sellers (employees) from 234 different country locations. Because of this, the prices are driven down. On top of that, as a buyer (employer/client) you can post jobs for free. One of the drawbacks are that there are no tests for the employees to pass, meaning that there might be unskilled workforce, thus requiring a good screening process from the side of client.

Drupal Jobs

Drupal Jobs is the place where you can search for Drupal remote developers and on-site. Drupal Jobs is a niche hiring and job seeking platform that focuses on Drupal development jobs. Drupal Jobs may not have the sheer number that other sites have, but given the fact that this website is entirely dedicated for good Drupal developers, it is worth it.

Codementor

Codementor is a website that is specifically dedicated for clients to be able to find software developers. Codementor has a fast and efficient registration process. After that, it doesn’t take much time for a client to be able to find the right freelancer that is willing to do the job for him. If you’re a client that is searching for a remote developer or on-site, then Codementor is definitely the right place from where you can start.

Costs for using these services:

Company

Pricing

Upwork

Freelancer.com

  • 3% or $3, whichever is greater for fixed price project

  • 3% for hourly paid jobs on every payment made to the freelancer

Jobrack

TopTal

Guru

  • Job posting is free. Promoting the job posting starts at $29.95

  • 2.5% handling fee when paying an invoice

  • 3.5% Cash back when paying with check, e-check or wire transfer

Fiverr

Indeed

GetACoder

Drupal Jobs

Codementor

Conclusion

Hiring remote employees always seems like a daunting task, especially if you don't know the right places where to search. However, with this list, now you know where you can find the best remote employees that the market has to offer. On top of that, when keeping in mind the challanges that come when hiring a remote employee, which were discussd in a previous article, you can better mitigate the shortcomings and better leverage the positive aspects of remote hiring.

May 27 2019
May 27

Local development environments are in the midst a bit of a renaissance recently - mainly driven by the maturation and adoption of Docker-based solutions.

I've been using (and recommending) DDEV for awhile now, and one of the things that I really like about it is the consistent pace of development. Since early February, there have been three minor releases of DDEV (1.6, 1.7, and 1.8). With each minor release of DDEV comes new, often very useful features. Here's just a few of my recent favorites:

NFS Mounting

One of the few disadvantages of using a Docker-based solution over a native local development solution is often the performance (depending on your operating system and hardware). In the DDEV 1.6 release, NFS mounting was introduced - this is a method to mount the DDEV Docker containers using NFS instead of the default Docker mount - resulting in significant performance gains. While using NFS mounting does involve a one-time system -setup, the results are well worth it.

Windows Chocolatey support

For Windows users, Chocolatey is similar to Homebrew for Mac OS X. With DDEV 1.6, you can now install DDEV using Chocolatey from the command line.

Local DDEV config files

If you're working in a team environment, then having a local DDEV config file is a huge advantage. Prior to DDEV 1.7, if you wanted to utilize a DDEV post-start hook, it had to be configured in .ddev/config.yaml. In a team environment, this file is shared among all developers, so everyone would share the same post-start hook (even if they didn't want it). Starting in DDEV 1.7, you can have your own .ddev/config.local.yaml with only your additions or modifications to .ddev/config.yaml. For example, if you want to add a post-start hook and not share it with the rest of your team, just create a .ddev/config.local.yaml file and add it there.

Easy local https by default!

It is pretty much standard practice these days to have your production environment only available via https. It only makes sense that your local development environments should behave in the same manner. In DDEV 1.8, support for the most-excellent mkcert project was added, so with a one-time, super-easy mkcert installation on your host operating system, DDEV will automatically default to providing you with an https connection to your local development environment. 

There's a lot of great reasons to use DDEV (check out more of them in my DDEV book!), and it is exciting to know that every six weeks or so, we'll be getting new ones with each DDEV release.

May 27 2019
May 27

Cathy Theys could often be found roaming contribution days at DrupalCons organizing people, but she's recently switched gears back to development. I caught up with her in Seattle to find out why.

Somebody showed me that if you help other people in the issue queues, they'll help you back, and that snowballed.

May 26 2019
May 26

Possibly the greatest ever digital signage advertising was created for British Airways which had it all. The advert, connecting to live flight information, displayed a child pointing up to the sky as an aeroplane flew above him. This was so cleverly done that the advert showed the flight number and its destination as well.

What a great blend of entertainment and education using the latest technologies!
A big screen shows a child pointing his fingers upwards while a plane flies in the skySource: British Airways

The digital signage system is scalable and its usefulness can be extracted to a great extent like digital menu boards for restaurants or the interactive digital movie posters for movie theatres. Drupal has the power to be a remarkably scalable digital signage solution for different sorts of organisations thereby reducing costs, speeding up time to market, and building engaging experiences for the people.

Digging Deeper Into The Terminology: Digital Signage

Digital signage refers to a centralised content dissemination platform for serving digital content on screens. It can be leveraged to display information through television programming, menus, advertising and other messages.

It can be seen in the form of digital signboards, billboards, and other such display devices for displaying visual information. It is connected by a content management system like Drupal that sends the digital content to be displayed. The information displayed can be anything ranging from static data and charts and graphs to images and video streaming.

Digital signage is a centralised content dissemination platform for serving digital content through television programming, menus or advertising on screens.

It can be commonly seen in outdoor marketing campaigns to display promotional content. Moreover, industries that rely on real-time information delivery to its employers or customer such as stock exchanges, airports, and sports stadiums can use digital signs to a great extent.

Digital Signage Can Be Used In Awesome Ways

Its uses can be seen through the eyes of organisations to understand the different ways it can be implemented. Some of the biggest brands have harnessed its immense potential.

Netflix, one of the largest over-the-top media service providers, carried a promotional campaign that relied on the humbled animated GIF. Instead of using a long video clip, they opted for reaction-based clips which were just a few seconds long. These videos were tied into the events that were actually happening around the globe.

[embedded content]


Swedish pharmacy Apotek Hjärtat developed a controversial billboard using a built-in smoke detector. Every time a smoker passed by, the billboard would cough loudly at them before displaying a series of products to help people stop smoking. Although it turned heads, questions were raised whether such an overt messaging is effective or not.

[embedded content]


Coca Cola’s Small World Machines Initiative had a grand ambition and offered a live link between India and Pakistan. Coke machines were placed in both the nations where people could interact with one another through the screen like touching hands, drawing peace, love, and happiness symbols together.

[embedded content]

A Trio Of Major Merits Through Digital Signs

Enormous possibilities of digital signs are pretty evident with so many big brands using them to a great effect. Using digital signs can prove beneficial in many ways.

  • Enhances customer engagement: People love colourful and moving images rather than static images which help in enhancing user engagement.
  • Makes a good impression: Content can be updated remotely within seconds. For instance, such quick updates can help retailers to form a good impression and adjust to customer demands without having to deploy employees or new signs printed.
  • Revs up revenue: Digital signs can help increase your sales and revenue. In 2014. Taco John deployed digital menu boards and witnessed a 12% increase in sales.

How Can Drupal Be The Perfect CMS For Digital Signage Solutions?

Well, it all boils down to the CMS that would be relaying digital content on to the screen to attract people. Drupal is one of the big players in the content management systems that can be the perfect fit for creating digital signs.

Content Creation

Your CMS should allow the content creation to be done intuitively and support all the common file types. Drupal comes with intuitive tools for content creation, workflow and publishing for streamlining content authoring.

Remote Access

With Drupal, on-the-go team members can assess, edit and approve content from mobile devices to keep content and promotional campaigns flowing on to the screens regardless of where they are and what device they are working on.

Content Revision

Drupal helps in enabling a swift and simple way to track all the alterations and revisions which is a must-have if you have multiple editors and need to handle a history of content changes.

Content Workflow

Drupal allows you to administer custom, editorial workflows for all the processes involved in the content production. It lets you view the stage your content is in - from creation to assessment to publication.

User Controls

Authentication and user permissions in Drupal helps in handling editorial workflows efficaciously and previews show how the content will look on screen before the content editors would finally approve and relay them on to the screens.

Content Scheduling

Drupal has the provisions for scheduling the content at your own convenience. It is possible to schedule a campaign to be published at a certain time. In case, a campaign is no longer required or outmoded, it can be unpublished as well.

Security

Drupal is one of the most secure CMS platforms among the leading players like Wordpress, Joomla and Magento. In a report published by Sucuri called Hacked Website Report, Drupal turned out to be the least vulnerable to security attacks in comparison to Wordpress.

Scalability

Your CMS should be able to grow with you and accommodate more screens. Drupal is a highly scalable solution with high traffic sites like Grammy, NBC Olympics, University of Oxford and many other renowned names performing astoundingly well even during the busiest of times.

Support And Maintenance

Drupal is an open source solution and you can rest assured that the Drupal community comprises of numerous vendors who are adept at providing round the clock support and maintenance.

At Opensense Labs, we have designed the Bucket and on-the-go models of support and maintenance services. We offer support in the day-to-day operations. Our support hours run parallelly with business hours but are extendable as per your needs.

Use Cases

The University of Iowa, which is powered by Drupal, kicked off a Drupal Digital Signage Service to offer new digital capabilities inside the campus.

Drupal’s flexibility in content management and delivery in combination with Intel Compute Sticks, mini-computers that serve each screen or sign, proved rewarding. This helped in offering wireless connectivity to the Drupal-based content as it is relayed on to the screens in real-time.

Three girls looking at a screen showing building architectureSource: University of Iowa

The digital signs provided key information for students like the time at which a bus would arrive or leave, emergency alerts, advertisements for student groups, computer lab availability, university news, and events etc.

The University reported rapid adoption of the service as many colleges and divisions within the University used the free and user-friendly solution on several screens. Stakeholders used templates and drag and drop tools and widgets for customising and governing the screen content.

The University’s move to expand the use of Drupal to digital signs proved beneficial in many ways. An IOWA NOW news story stated that “the backend is incredibly user-friendly. It’s the same system our websites run on, and so very intuitive. The web-based platform allows us to update information and slides from anywhere and anytime”.

Being an open source software, Drupal incurred no licensing fees. Hardware costs were lower too. Thanks to the project team’s discovery that the digital signs could be run on small, energy-efficient compute sticks. Moreover, wireless connectivity eliminated the expense of data ports and cabling.

People standing at the sides of the screen showing the pillars and the word IOWASource: University of Iowa

The Drupal Digital Signage system, rather than using a webpage, used a specialised software application. This made the displaying of content as simple as plugging the URL of a sign into a browser. Users were granted access permissions for specific signs and by utilising templates and a drag-and-drop interface, they could display the content or widgets in numerous regions of the screens. That content, displayed on the screen, could also be shared with other units.

Furthermore, the digital signs, being accessible to all screen-reading technologies, saved staff time. Being easy to learn, training time got reduced.

Content editors only needed to enter news or events into a familiar interface. The content would go to both their websites and digital signs simultaneously without having to perform double entry.

Another example can be seen through Metropolitan Transportation Authority (MTA) which plays a huge role as the largest public transit system in the United States of America. It had benefitted tremendously by using Drupal and Amazon’s Internet of Things (IoT) service from Amazon Web Services (AWS). With Drupal, the MTA was able to leverage the same CMS that powers its website to serve content and data to thousands of digital signs in hundreds of stations in New York City. By utilising the power of digital signage into station countdown clocks, MTA has been able to disseminate a great customer experience.

A digital signage screen in New York railway station reading station name and time of arrivalSource: Acquia

The content can be built inside Drupal and data is pulled from external feeds in order to supply the countdown clocks with data. Data can be pulled from transit information, weather and message provider as Drupal is equipped with provider APIs. Once data is given context via Drupal content model, it is pushed to the digital signs with the help of a data pipeline that was implemented to leverage IoT service from AWS. Using progressively decoupled Drupal approach, a front end experience was developed using ReactJS for displaying the data. As data flows, React governs all the important on-screen presentation and utilises the data that is received to inform the display on the countdown clock.

Future Of Digital Signage

According to the statistics given by the Statista, the statistics portal, the digital signage market worldwide was valued at 19.61 billion U.S. dollars in 2016 and the display market was estimated at 6.07 billion U.S. dollar in 2015.

Future of digital signage is bright as is for Drupal and together they can work wonders.
Graphical representation showing bar graphs for market value of digital signageSource: Statista

This number is going to see a significant rise by 2023 as the market value is poised to reach 32.84 billion in 2023. Digital signage technology is not just here to stay but grow multifold.

Conclusion

Digital content distribution can surely be taken to next level by making it engaging through digital signage solutions. Drupal can be the perfect choice of CMS for relaying content on screens.

We provide Drupal services with top-of-the-line expertise. Contact us at [email protected] to explore Drupal as a superb platform for building digital signage solutions thereby providing a whole new level of customer experience.

May 26 2019
May 26

World Economic Forum, an International Organisation for Public/Private Cooperation, has its digital presence not only in English language but other prominently spoken languages like Spanish, Chinese, French and Japanese as well. Rio Olympics 2016, which is also known for the infamous haul of 9 golds by Usain Bolt, had its online presence in both English and French. Oxfam, an international confederation of 19 organisations that has the objective of mobilising the power of people against poverty, has its website in Spanish and French languages other than English. What is common between all of them? Their websites are powered by Drupal which is one of the leaders in the open source content management system (CMS) market.

Illutration showing people in the background and different coloured leaves containing the word Hello in different languages


Built and maintained by an international community of developers, Drupal has been a marvellous solution for organisations around the globe that are in need of swiftly launching their websites that is tailored to a variety of language needs. As a matter of fact, Drupal 8, the latest version, was created keeping multilingual use in mind. But why should an organisation consider building a multilingual site in the first place? Let’s understand its significance before taking a plunge in exploring Drupal’s capabilities in building a localised site.

Significance of multilingual sites

A bar graph showing percentage of online users of different languages


English is certainly the most widely spoken language in the world and dominates the internet space. But it would be wrong to consider it is as the most preferred language. Chinese, Spanish, Arabic and many others, as you can see in the graph above, are spoken by millions of online users. So, optimising your site and going multilingual gives you a huge advantage.

Some of the major benefits of having a multilingual website are:

Illustration showing horizontal bars to explain benefits of multilingual websiteSource: DayTranslations

One of the most important benefits of going multilingual is that you can enhance communication as even though English has its preeminence over the online space. That doesn’t mean that everyone wants to buy from English language websites. Research from CSA Research says that people prefer to make purchases while browsing in their own native language as more than half of the people who were surveyed bought from sites that were available in their own language. Another important benefit is that you can expand your reach and cover a wider audience. Localised websites also result in increased client satisfaction. Multilingual SEO is of paramount importance too and localising your website into different languages helps improve your SERP (Search Engine Results Page) ranking locally across the globe.

Moreover, website localisation is efficacious and gives you a competitive advantage. In a survey by Content Marketing World, 60% of participating marketers agreed that there is a dearth of multilingual content marketing strategies. Therefore, not capitalising on the immense amount of opportunities that website localisation presents can prove detrimental to your business pursuits. You may lose out to a local business that is well known and also fare badly against another foreign company that is localising better. Also, not only you get to touch a wider demographic of the audience, you get the opportunity to increase your audience as you will be noticed by a massive pool of potential buyers for your product and services. And you do not get penalised for duplicated content on translated sites. Localising your website also bring about higher conversions and skyrocketed return on investment. Even if you cannot please everyone, you can please the majority of them when you make your site multilingual.

Considerations for turning your site multilingual

In order to develop a great multilingual site, there are some considerations that should be kept in mind.

Building a site in any language needs a clearly thought-out plan for content and needs a detailed picture of your business objectives and vision. For instance, you should know who the ideal customer for your products and services is and where does he or she live. And you should know which language will have a wider reach amongst your potential customers.

You would, then, require a wisely laid-out strategy. You can register top-level domains like .mx for Mexico or .fr for France. You must know that photographs, artwork, fonts, and colour choices carry different meanings across different cultures. Visitors should find it easy to navigate and find their native language microsite. Different languages should be used appropriately and nothing should come across as offensive or insensitive to the different cultures.

Most importantly, you need to determine the best technological solution for creating your localised site. A robust CMS like Drupal can be a remarkable option that can dovetail with your multilingual strategy.

Drupal in the mix

If you are in the need of quickly creating customised sites in any language of your choice or an intricate multilingual web application with dynamic, language-based displays, Drupal is a wonderful option. Without the need for any additional components, Drupal 8 can be installed in over 90+ languages. Drupal’s out-of-the-box support for language handling assists you in delivering localised digital experiences and saves time and money. Drupal 8 core comes with four core modules for localising content on the website.

Administering Language

Language handling module


The Language handling module lets you pick your choice from 94 languages.
 
Language configuration has been streamlined. Assign a language to everything from taxonomy terms to administration language. You can even delete the English language. Each user can also select his or her own language for the admin interface.
 
The detection of browser language can be easily configured with external language codes. There is also a built-in transliteration for the machine names.

Translating Interface

Interface translation module

Interface translation module provides a central directory to manage interface. It has built-in translation UI for simplifying content editing. By allowing automatic downloads and updates, it lets users use any translation interface available in the Drupal community in any language supported by Drupal 8.
 
English language interface can be customized. You do not have to use English as your default language.

Translating Content

Content translation module

Content translation module is applicable to all of your content. It lets you translate everything from the pages to the taxonomy terms. It allows you to configure custom fields of a web content.
 
Like interface translation, the default language of your content can be flexibly configured. You can even hide or display the position of language selector.

Managing Configuration

Configuration translation module

Everything that comes with the configuration of your website can be translated using this module. Things like views, blocks, panels, field panels or text formats can be easily translated with its built-in responsive translation interface.
 
Moreover, there is a provision of an overview screen to help you in the process.

Case studies

Homepage of Sevilla FC website with three people holding the team jersey on left and the football team posing for the camera on right


Sevilla FC, founded in 1890, is one of the oldest football teams in Spain. A digital agency helped it to implement a series of quality and qantitative enhancement in its digital services via web, mobile and social media channels. Drupal turned out to be a fantastic option in their pursuit of improving the digital experience. Drupal’s in-built multilingual capabilities, top-of-the-line open source security, tremendous scalability, great content workflow tools and the support for agile project delivery were the major factors that made it the right choice for this project. With a continuous increase in the number of international fanbases of Sevilla FC, it was important to create a multilingual site. The multilingual capability of Drupal 8 streamlined the process of localising their website into multiple languages.

What if your native language is not available to choose from 90+ languages that the Drupal offers? OpenSense Labs leveraged Drupal 8 to provide a clean architecture and design for the betterment of digital presence of the Ministry of Finance in Somalia.

Homepage of Ministry of Finance of Somalia with an image of a multi floor building


The remodelling of the website needed new content types with user-friendly navigation and the addition of a custom type of publication to publish annual reports. Agile development methodology helped the project to be completed within six weeks. And, as Somali isn’t available in the list of languages provided by Drupal 8’s out of the box solution, the flexible multilingual infrastructure of Drupal aided in adding it easily.

Conclusion

While English language internet users have been the primary source of the target of every business. There has been an unprecedented growth in the non-English language online users as well. Reaching them out is beneficial for widening your customer base and establishing their business in newer markets. Your content determines the website traffic, customer retention, and conversion rates. CMS is the warehouse of your web content. It is significant to choose the right CMS before even making your first move towards making your site multilingual.

Drupal 8 has made tremendous improvements to include the built-in multilingual feature. It delivers multilingual websites right out of the box. Its 4 key modules for language, interface, content, and configuration of your website helps in efficaciously building a multilingual site.

Drupal development is our forte and we are committed towards the provision for great digital experiences. To tap into newer markets with multilingual Drupal websites, reach us out at [email protected].

May 24 2019
May 24

4 minute read Published: 24 May, 2019 Author: Colan Schwartz
Drupal Planet , Aegir , DevOps

Aegir is often seen as a stand-alone application lifecycle management (ALM) system for hosting and managing Drupal sites. In the enterprise context, however, it’s necessary to provide mutiple deployment environments for quality assurance (QA), development or other purposes. Aegir trivializes this process by allowing sites to easily be copied from one environment to another in a point-and-click fashion from the Web front-end, eliminating the need for command-line DevOps tasks, which it was designed to do.

Setting up the environments

An Aegir instance needs to be installed in each environment. We would typically have three (3) of them:

  • Development (Dev): While generally reserved for integration testing, it is sometimes also used for development (e.g. when local environments cannot be used by developers or there are a small number of them).
  • Staging: Used for QA purposes. Designed to be a virtual clone of Production to ensure that tagged releases operate the same way as they would there, before being made live.
  • Production (Prod): The live environment visible to the public or the target audience, and the authoritative source for data.

To install Aegir in each of these, follow the installation instructions. For larger deployments, common architectures for Staging and Prod would include features such as:

  • Separate Web and database servers
  • Multiple Web and database servers
  • Load balancers
  • Caching/HTTPS proxies
  • Separate partitions for (external) storage of:
    • The Aegir file system (/var/aegir)
    • Site backups (/var/aegir/backups)
    • Database storage (/var/lib/mysql)
  • etc.

As these are all out of scope for the purposes of this article, I’ll save these discussions for the future, and assume we’re working with default installations.

Allowing the environments to communicate

To enable inter-environment communication, we must perform the following series of tasks on each Aegir VM as part of the initial set-up, which only needs to be done once.

Back-end set-up

The back-ends of each instance must be able to communicate. For that we use the secure SSH protocol. As stated on Wikipedia:

SSH is important in cloud computing to solve connectivity problems, avoiding the security issues of exposing a cloud-based virtual machine directly on the Internet. An SSH tunnel can provide a secure path over the Internet, through a firewall to a virtual machine.


Steps to enable SSH communication:

  1. SSH into the VM.
    • ssh ENVIRONMENT.aegir.example.com
  2. Become the Aegir user.
    • sudo -sHu aegir
  3. Generate an SSH key. (If you’ve done this already to access a private Git repository, you can skip this step.)
    • ssh-keygen -t rsa -b 4096 -C "ORGANIZATION Aegir ENVIRONMENT"
  4. For every other environment from where you’d like to fetch sites:
    1. Add the generated public key (~/.ssh/id_rsa.pub) to the whitelist for the Aegir user on the other VM so that the original instance can connect to this target.
      • ssh OTHER_ENVIRONMENT.aegir.example.com
      • sudo -sHu aegir
      • vi ~/.ssh/authorized_keys
      • exit
    2. Back on the original VM, allow connections to the target VM.
      • sudo -sHu aegir
      • ssh OTHER_ENVIRONMENT.aegir.example.com
      • Answer affirmatively when asked to confirm the host (after verifying the fingerprint, etc.).

Front-end set-up

These steps will tell Aegir about the other Aegir servers whose sites can be imported.

  1. On Aegir’s front-end Web UI, the “hostmaster” site, enable remote site imports by navigating to Administration » Hosting » Advanced, and check the Remote import box. Save the form. (This enables the Aegir Hosting Remote Import module.)
  2. For every other server you’d like to add, do the following:
    1. Navigate to the Servers tab, and click on the Add server link.
    2. For the Server hostname, enter the hostname of the other Aegir server (e.g. staging.aegir.example.com)
    3. Click the Remote import vertical tab, check Remote hostmaster, and then enter aegir for the Remote user.
    4. For the Human-readable name, you can enter something like Foo's Staging Aegir (assuming the Staging instance).
    5. You can generally ignore the IP addresses section.
    6. Hit the Save button.
    7. Wait for the server verification to complete successfully.

All of the one-time command-line tasks are now done. You or your users can now use the Web UI to shuffle site data between environments.

Select remote site to import

Deploying sites from one environment to another

Whenever necessary, this point-and-click process can be used to deploy sites from one Aegir environment to another. It’s actually a pull method as the destination Aegir instance imports a site from the source.

Reasons to do this include:

  • The initial deployment of a development site from Dev to Prod.
  • Refreshing Dev and Staging sites from Prod.

Steps:

  1. If you’d like to install the site onto a new platform that’s not yet available, create the platform first.
  2. Navigate to the Servers tab.
  3. Click on the server hosting the site you’d like to import.
  4. Click on the Import remote sites link.
  5. Follow the prompts.
  6. Wait for the batch job, Import and Verify tasks to complete.
  7. Enable the imported site by hitting the Run button on the Enable task.
  8. The imported site is now ready for use!

The article Aegir DevOps: Deployment Workflows for Drupal Sites first appeared on the Consensus Enterprises blog.

We've disabled blog comments to prevent spam, but if you have questions or comments about this post, get in touch!

May 24 2019
May 24

Dwayne McDaniel did some thorough reporting of deprecated code use in all Drupal 8 contributed modules in March. Ultimately this kind of reporting would be best to have on drupal.org but while that is figured out, Dwayne's data set provides a very nice way to mine data about Drupal 9 readiness of contributed modules and to inform our tooling to improve the process. His original numbers showed that almost 44% of contributed modules had no deprecated code use at the time. What I was interested in was how to help the rest of the 56%.

Dwayne created an updated process and a new repository this week with fresh data. I was still curious so I delved right into the data and started mining it. A key question I was interested in is how much of the most widespread deprecations are actionable right now. An actionable deprecation is something core deprecated in a previous version that is not supported anymore, so you can update your code to remove the use of that API. Currently Drupal 8.6 and 8.7 are supported, so deprecations there should only be acted on for your custom code. However deprecations in and before 8.5 are entirely fine to act on.

First I counted the top list of deprecated APIs used from Dwayne's data across all of contributed projects. Then I wrote a script to collate api.drupal.org documentation to the deprecation notices. Ideally phpstan itself would report these messages directly and Matt Glaman is working on that. However since that is still blocked on the phpstan side, one needs a different data source to find the deprecation documentation for each occurrence, so I took to api.drupal.org to get that for now. Once that is found, we can categorize the deprecations into actionable, not actionable and actionable for custom code only. For the later case you know which core version you are using, and that should be an up to date minor version. So you don't need to deal with what core branches the community supports otherwise.

The results look really promising so far in terms of how much contributed modules can make progress on even today. If all already actionable deprecations get resolved, there will be very little left at least of the deprecations we already know.

A month ago Dezső Biczó created a set of proof of concept Rector fixes to automate some of these deprecation fixes, so I opened an issue with this new data set to try and cover the top ones that are not just actionable but approachable to automate.

Screenshot of deprecation status PDF

As with all interesting data sets, this summary is just the tip of the iceberg. There is huge potential to mine this data set for other uses, such as finding modules that potential contributors at an event could contribute fixes to. I don't know yet how much I can continue to work with this data myself, and of course others doing analysis of their own would be more than welcome.

Are you a drupal.org project maintainer? Now would be a good time to fill in your Drupal 9 porting information in your project, so you can let contributors know how to best engage with your in the process towards Drupal 9.

https://t.co/hf2ENvlZSo projects can now specify Drupal 9 porting information, so *you* can direct *your* contributors to provide the most valuable help on the way to Drupal 9, fund the process or just step back (for now). Edit your project to help your contributors help you! pic.twitter.com/l1OWwOllBK

— The Drop is Always Moving (@DropIsMoving) May 21, 2019

Disclaimer: The data is based on the state of contributed projects on May 20, 2019 based on Drupal core's 8.8.x development branch on May 20, 2019. The lookup on api.drupal.org was not perfect and I found some bugs there that are being resolved as well so the data gets more accurate. Also, as contributed modules will get updated, there will be less uses of deprecated APIs. As core will introduce more deprecations, the data could get worse. There may also be phpstan Drupal integration bugs or missing features, such as not finding uses of deprecated global constants yet. This is a snapshot as the tools and state of code on all sides evolve, the resulting data will be different.

May 24 2019
May 24
Time is always of the essence. From a consumer perspective, you want to know when events take place, when something’s open or closed, how long a meeting or activity will last. And, from a development perspective, you want to be able to create a date…
May 24 2019
May 24

There has been a lot of hype recently about emerging innovations in the digital field, with buzzwords such as AI, IoT, blockchain, AR & VR, 5G … and many more. 

But, looking from the other end of this fast-paced digital evolution, there’s another buzzword that’s quickly gaining ground: community.

In an era of ever-greater connectivity, interacting with like-minded individuals from anywhere in the world has never been easier. Some of the major tech giants of today have long since capitalized on our desire for human interaction and forming communities - we don’t even need to call any names (*cough*Facebook*cough*).

The community that’s best known to us is, of course, the Drupal community. Anyone who’s been in contact with Drupal knows at least a thing or two about its community, and has probably heard the now famous saying “Come for the code, stay for the community” (we know, we know, it’s getting kind of worn out - but it's very relevant here!).

Simultaneously leveraging Drupal’s open source code and contributing back to it, it is a very powerful, while also a very welcoming community, one that’s based on inclusivity and acceptance.

But what if Drupal’s versatile CMS could be extended to not benefit only its own community, but any community, anywhere in the world?

Enter Open Social - a Drupal distribution that enables anyone to quickly & easily set up a platform for their own community, no matter its size or needs. It comes out-of-the-box with a plethora of useful features; and, it’s open source, which means that if you’re at least somewhat familiar with development and CMS, it’s practically free to set up. 

1. What will I get if I decide on Open Social?

Open Social offers a wide range of useful features; they are too numerous to list all of them in this post, so we decided to just pick and showcase a select few. You can get more information about all its features on their website. Here are the ones that stood out to us the most:

  • Users can log in via social login, with accounts they have set up on other social networks such as Facebook.
  • Users can enhance their profiles with tags indicating their company and their role within the company.
  • Users can further connect and collaborate through creating events and groups.
  • Site managers can make use of analytics to track users’ behavior; on top of that, integration with Google Analytics is very easy.
  • Community managers can send bulk emails to community members.
  • Users’ email addresses are encrypted on the server, adding an extra layer of protection.
  • Thanks to its advanced risk analysis techniques, an Open Social community is safe from spam accounts.
  • The performance of an Open Social platform and all its pages is super fast (and we all know that the #1 reason for users not using a website is its poor performance!).

Of course, all the essentials, such as management of personal data and social features, are all also present in Open Social. If you go through the detailed list of features that we linked above, you’ll quickly be able to confirm that the team really took every little detail into consideration. 

What’s more, due to the platform’s open source status, you have way more control over yours and your users’ data than when setting up your community on one of the existing social platforms - we’ve all heard of the Facebook - Cambridge Analytica scandal

A bit later on, we’ll see how Open Social is a community effort in the truest sense of the word - and, logically so, since it was born out of a community as inclusive and welcoming as the Drupal community. 

2. How can I get even more out of Open Social?

But its countless features are not at all everything you can do with Open Social - if you opt for the enterprise package, you can customize your platform even more through its extensions. 

Again, rather than just copying and pasting all available extensions (which you can find listed here), we’ll focus more on the ones that appealed to us the most. So, to give you a taste:

  • WYSIWYG for Comments: community members don’t need to rely on markups to stylize their comments, but can instead leverage the what-you-see-is-what-you-get editor, familiar to all who have been working with CMS.
  • Google Translate: thanks to the integration with Google Translate, Open Social is the perfect fit for a multilingual and/or international community.
  • Crowd Innovation: likely the most interesting and innovative of all of these extensions, this feature allows communities to ideate and solve challenges together, through a true collective effort.

As you can probably surmise from these first two points alone, Open Social is much more than just a basic social platform. Its unique features account for every aspect of a great user experience, while at the same time making it as close as possible to a real-life community.

3. So far so good, but ... Is Open Social even the right fit for my community?

Well, based solely on the two previous points, it’d be more difficult to find a community for which Open Social isn’t a great fit. 

Basically, its high customizability makes it ideal for any type of community by enabling its members to exchange ideas, collaborate and ideate together. Open Social efficiently solves a paradox of social networks and online communities: users want the features that they’re used to using, but, at the same time, they want innovation. Open Social delivers in both of these aspects. 

Its wide range of available features and extensions allows you to tailor the platform to the specific needs of your community, while also retaining basic ones such as social sharing. Whether you need a platform for your thriving volunteer community, an extranet connecting stakeholders outside your organization, or a simple social network, Open Social will more than satisfy your needs.

If you’re at least somewhat familiar with development and CMS (Drupal in particular), there’s practically no reason not to give Open Social a shot. The only case where you should consider a different solution is if you lack development experience and/or have a small, self-contained community that isn’t focused on growth and needs just the basic social features.

4. Ok, then it just has to be costly and difficult to set up, right?

Aha - now we’ve come to the salient part that you’ve probably been eagerly anticipating! In this section, we’ll answer questions such as: How difficult is it to set up and integrate Open Social? Is it a long and expensive process? Do I need to be a developer to effectively use Open Social?

Let’s first address the primary concern: no, you don’t need experience with Drupal development if you want to use Open Social. However, the code is open source and is available for free on drupal.org, which means that setting up Open Social incurs no additional costs for those who are versed in Drupal. 

So, if you or your team possess adequate Drupal expertise, you won’t have to worry about monthly fees; you will however need to invest a little bit more into maintenance, since you’ll need to handle all updates manually. 

But not everyone who wants to have an awesome community platform can be expected to know Drupal. Fortunately, Open Social is also available as SaaS, with three very affordable packages:

  • The Basic package offers all basic features and costs €195 a month. You even get the option of a 30-day free trial before committing - no credit card required at this stage!
  • The Premium package, listed as the most popular, is a bit more costly, with €495 a month. Same as before, you get a 30-day free trial, but it also comes with huge benefits of a much larger number of users, as well as the ability to import these users from existing platforms.
  • The Enterprise package is the most expensive, at €1,250 a month. As the name suggests, this is ideal for enterprises who want to build a large global community. With this package, you can have as many users as you want, and even benefit from API integrations as well as all the features and extensions exclusive to this package.

In contrast with the open source solution, by opting for one of the paid SaaS options of Open Social, you’ll only need to worry about the monthly fee - security and feature updates will all be automatic. Owing to this flexibility, Open Social really is a great fit for different needs and backgrounds.

5. Ok, I've set up Open Social, but I'm having some trouble with it - how & where can I get help?

Considering how the Open Social team take every minute detail into account, it’d only make sense if they also provided top-notch guidance and support to anyone who wishes to use the software for their community, right?

Well, you can actually educate yourself on the ins and outs of Open Social before you even have to decide on a package or start your free trial! There’s a standalone website available to help you jumpstart your community, as well as a free guide on their website. Moreover, their blog section contains a lot of content that’s geared towards community management

But, not to worry - you’ll also be able to get help and support once you’ve set it up and started using it. Even the basic package comes with support via email, while the enterprise one also offers support by phone with guaranteed response times. 

If you’ve chosen the path of open source, you can find help on Open Social’s page on drupal.org. You get a lot of information just by visiting the page, but you can also check out the project’s issue queue, where you’ll either find the answers you seek, or be able to contact someone who has worked on a particular issue and get more specific help from them.

6. Alright, I'm almost convinced, it's just ... How can you reassure me that Open Social will be as useful in the future as it is today?

We’ll see your concern and raise you this: not only will Open Social continue to be useful - it’ll only keep getting better and more suited to the wants and needs of its users! 

How so, you ask? Well, you actually get a say in the project’s roadmap! This means that your input and ideas can help shape the future of Open Social. You’re able to make suggestions on which all participants can then vote. Your feedback is thus taken into account when developing new features.

This is all done through Open Social’s Roadmap tool. As you can see, you get a neat overview of what’s planned for a certain period of time and even to some extent track the progress of the suggestions. 

So, even if you disregard the rapid pace of digital innovation (which presupposes continuously better technologies), you can safely assume that this receptiveness to feedback will lead to a software progressively catered to its users’ needs.

7. *sigh* You're really giving me no choice, are you? Alright, final question: who's actually using Open Social?

You can check out a list of showcases on Open Social’s website. Apart from that, there are some additional businesses using Open Social listed on the project’s page on drupal.org. Among the most notable ones are:

Moreover, what served as the initial inception of Open Social was Greenpeace’s Greenwire project. Launched in 2011, Greenwire was born out of the desire to make the world a better place by bringing people together and enabling them to better collaborate. 

Drupal’s open source was thus the perfect fit for an active volunteer community. Based on the platform’s success, the GoalGorilla team realized their solution can help even more communities worldwide, and so Open Social came to be. If you want to learn more about the Greenwire project, you can also check out GoalGorilla’s case study or the one on drupal.com.

Conclusion

We hope we’ve successfully answered your questions. You can always get more specific information by visiting Open Social’s website or by contacting their team - they’re very open and very social (pun definitely intended), so there’s really no need to be shy.

Of course, there’s still much more that Open Social has to offer. The best way to discover more of the platform’s powerful capabilities is to do some exploration of your own, either by opting for the free trial or tinkering with the software downloaded via drupal.org. 

Hopefully, we’ve given you enough of a jump-start to know what to focus on and make the process of exploring a fun one. We wish you lots of success in building and growing your own community!  

May 24 2019
May 24

What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?

And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?

You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
 

But how precisely do these new concepts, part of Drupal 8's cache system, refine and streamline the way you cache data on your website?
 

Let's try to demystify the terminology of Drupal 8's Cache API and to translate its new “fancy” terminology into... crystal-clear benefits for you:
 

1. What Is Caching More Precisely? Why Do We Cache Data?

To your “What” question I'd answer:
 

Caching is a... strategy (or layer) for storing data from your website. Or: it's a software or hardware component where you store your data. 
 

Both definitions are equally accurate.

Why would you want to store your data?
 

Because this will streamline the way your website serves all future requests for that cached data.
 

And it goes without saying that reading data straight from the cache takes less time than... retrieving it from a slower data container or fully recreating the result.

In short: caching data translates into faster page load time.


2. Cache API in Drupal 8: The Automatic Cache System

A brief, yet accurate definition of cache in Drupal 8 would be:
 

Storing data that takes too long to load.
 

And if I am to detail it a bit I'd have to add that:
 

Caching can be either permanent or time-limited you'ree to cache any type of data on your website.
 

Now, talking about Drupal 8's cache API, what everyone points out is that: it is much improved. That it's so different from the cache systems of the previous Drupal versions that... you even risk turning your website uncachable if you're not familiar with its new concepts.

“But how different/sophisticated can it be?” you might ask yourself.

Before we delve deep into details let me add just one thing:
 

We're talking about an... automated cache system. Basically, your Drupal 8 website retrieves cache data for both anonymous and logged in users with no configuration whatsoever. All by default...
 

And now, let's shed some light on all these new fancy concepts that the Cache API in Drupal 8 is based on:
 

2.1.The Cache Tags

We all do agree that “invalidating cache” is one of the most challenging tasks of any cache system.

Luckily, not anymore. At least not in Drupal 8, where you now have the concept of “cache tags” that you can use for tagging:
 

  • specific pages
  • specific page elements
  • various types of content
     

… and thus invalidate them all. Improved efficiency and high accuracy through... basic tagging.

Basically, using these cache tags you can easily identify outdated data stored in multiple cache bins and... invalidate it.

This way, you no longer run the risk of invalidating “still green” cache items, in bulk, not knowing which data to invalidate.
 

2.2. The Context Cache

Here's an all too common scenario:
 

You're faced with multiple variants of the same data; only one of them should be cached, based on a specific criterion like language, user, country, content access permission...
 

Well, how do you automate targetting the right variant to be cached? And how do you automate caching the other left variants, as well, depending on the... context.

You use “cache contexts”, that's how...

They're one of those new remarkable features that the Cache API in Drupal 8 ships with, that allow you to specify the criteria to be used for the cached content on a page to vary. By user, by language, by country, by path...
 

2.3. The Max-Age (The Cache Duration)

Maybe you don't want certain data to be forever cached. Maybe you need it stored for a certain period of time only.

In this respect, the “max-age” property in Drupal 8's cache system allows you to define that time limit. To invalidate data that will have run... out of time.
 

2.4. The Bubbleable Cache Metadata

What does this even mean “cache metadata... bubbling”?

Let's take this example: 
 

You have a parent item with its own “family” of... children items. In this context, “bubbled tags” makes it possible for the parent item in this render array to receive cacheability metadata from its children.
 

Bubble cache metadata streamlines the whole process of invalidating... outdated cached data. As simple as that...
 

The END!

Is it any clearer for you now what makes the Cache API in Drupal 8 so... powerful? How its new features come to remove most of the limitations that you've already faced in Drupal 7?

And how you can use them to refine and automate caching on your own Drupal 8 website?

Image by Pexels from Pixabay  

May 23 2019
May 23

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn’t ask the right questions. If you’re solving the wrong problem, it doesn’t matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don’t wants and needs match? It might be because the client hasn’t spent enough time thinking about the question, or because they haven’t approached it from the right angle. If that’s the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you’ve properly understood the problem, you can start to look for a solution. In this article, I’ll talk about some examples of problems like this that we’ve recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there’s already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you’re lucky, they’ve shared their solution.

In general, I’d prefer to avoid writing custom code, for the same reasons that we aren’t rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn’t already a solution, or the solution isn’t quite right for your needs. Whenever that’s the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it’s surprising that there isn’t already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you’d expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn’t always obvious why some things are easy and others are hard.

tasks comicXKCD -tasks

Even experienced developers sometimes fail to grasp this - here’s a recent example where I did exactly that.

We’re building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there’s a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour’s work. Except that in Drupal 8, webforms are no longer nodes - they’re configuration entities, so there is no creation date to order by. What I’d assumed would be trivial would in fact require major custom development, the cost of which wouldn’t be justified by the business value of the feature. But there’s almost always another way to do things, which won’t be as time-consuming, and while it might not be what the client asked for, it’s often close enough for what they need.

What’s the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn’t be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I’d spent hours going down a blind alley.

This is a really good example of why it’s so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client’s business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn’t necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we’re working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it’s possible, but the more relevant question is whether it’s feasible.

Just as the web has a grain, most technologies have a certain way of working, and it’s better to work with your framework rather than against it. Developers, designers and clients should work together to understand what’s simple and what’s complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn’t that I don’t want to do the work, or that I want to charge clients more money. It’s that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don’t bring business value, like banging their heads against the wall trying to bend a framework to match a “requirement” that nobody actually needs. It’s better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn’t necessarily easy for another, or for a computer, so it’s useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I’d got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client’s content team was knowing what their images would look like when they’re rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it’s important to be able to see what an image will look like in different contexts. This is especially important if you’re using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn’t much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn’t already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

May 23 2019
May 23

This article was originally posted on the Capgemini Engineering blog

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn't ask the right questions. If you're solving the wrong problem, it doesn't matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don't wants and needs match? It might be because the client hasn't spent enough time thinking about the question, or because they haven't approached it from the right angle. If that's the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you've properly understood the problem, you can start to look for a solution. In this article, I'll talk about some examples of problems like this that we've recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there's already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you're lucky, they've shared their solution.

In general, I'd prefer to avoid writing custom code, for the same reasons that we aren't rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn't already a solution, or the solution isn't quite right for your needs. Whenever that's the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it's surprising that there isn't already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you'd expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn't always obvious why some things are easy and others are hard.

tasks comicXKCD -tasks

Even experienced developers sometimes fail to grasp this - here's a recent example where I did exactly that.

We're building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there's a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour's work. Except that in Drupal 8, webforms are no longer nodes - they're configuration entities, so there is no creation date to order by. What I'd assumed would be trivial would in fact require major custom development, the cost of which wouldn't be justified by the business value of the feature. But there's almost always another way to do things, which won't be as time-consuming, and while it might not be what the client asked for, it's often close enough for what they need.

What's the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn't be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I'd spent hours going down a blind alley.

This is a really good example of why it's so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client's business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn't necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we're working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it's possible, but the more relevant question is whether it's feasible.

Just as the web has a grain, most technologies have a certain way of working, and it's better to work with your framework rather than against it. Developers, designers and clients should work together to understand what's simple and what's complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn't that I don't want to do the work, or that I want to charge clients more money. It's that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don't bring business value, like banging their heads against the wall trying to bend a framework to match a "requirement" that nobody actually needs. It's better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn't necessarily easy for another, or for a computer, so it's useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I'd got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client's content team was knowing what their images would look like when they're rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it's important to be able to see what an image will look like in different contexts. This is especially important if you're using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn't much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn't already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

May 23 2019
May 23

Mike and Matt invite Layout Initiative lead Tim Plunkett on the podcast to talk everything about Drupal's new Layout Builder, its use-cases, issues, and what's new in Drupal 8.7, and what's coming next!

People want visibility controls like they have in the block system... there are people working on that issue.

May 23 2019
May 23

Last month, Special Counsel Robert Mueller's long-awaited report on Russian interference in the U.S. election was released on the Justice.gov website.

With the help of Acquia and Drupal, the report was successfully delivered without interruption, despite a 7,000% increase in traffic on its release date, according to the Ottawa Business Journal.

According to Federal Computer Week, by 5pm on the day of the report's release, there had already been 587 million site visits, with 247 million happening within the first hour.

During these types of high-pressure events when the world is watching, no news is good news. Keeping sites like this up and available to the public is an important part of democracy and the freedom of information. I'm proud of Acquia's and Drupal's ability to deliver when it matters most!

May 23, 2019

31 sec read time

db db
May 23 2019
May 23

How Grazitti’s Drupal Marketo Connector module is helpful for form prefill?

by on May 23, 2019 in Connectors, Drupal, Marketo Integrations

How does a brand leave a lasting impression on its customers?

While your products and prices definitely help you get an edge over your competitors, the experience that your users have while dealing with you is as critical for sustained growth. In fact, 73% of users surveyed by PWC cited the experience they had with a company to be one of the three prime factors that make them come back to an online business. That is a true testimony of the power that customer experience holds.

Experts are always talking about the myriad of options available with marketers through which they can better the experience that users have on their websites.

One of them is using pre-populated form data.

Drupal Marketo Connector

How can a Prefill feature help you with improving CX?

It’s easy to imagine how being asked to fill out a form repeatedly can irk someone. In this age when consumers are being given more power over brands, this is a major step back.

Instead, consider this: the form that consumers have to fill already contains their contact info, based on data they had provided previously.

This can save a lot of time for returning visitors that have filled out forms on your website before and will help them stay more focused on their searches and purchases. You can also use this opportunity to ask for additional information to establish a better rapport with them.

If your form has too many fields, even the most motivated prospect may not make it all the way to the end. So prepopulating the forms on your website with the data that you have acquired from your previous interaction with them, is the best way to go.

Grazitti’s Drupal Marketo Connector can help you achieve just this.

What are the features of this connector?

Let’s take a look at the various features that this connector offers.

Embedded Marketo Form

When an anonymous user visits your website, they will be asked to fill out their details in a form. As soon as the details are filled, Marketo’s Munchkin API passes the user identity i.e, full name, email address, company, and country and syncs it to Marketo. The marketing automation platform saves this user data in the form of cookies.

Drupal Marketo Connector

Prefilled Marketo Form

When a known user visits your website the second time, Marketo form fields are prefilled with their information. This functionality will work for all forms on the website. Also, we have created the prefill configuration functionality in the back-end. So, the enable and disable functionality will be active in the administrator section whenever you install the module form prefill. Form prefill will remain enabled by default, however, if you want it disabled, you can simply do it by choosing the Disable Form option from the admin back-end.

Drupal Marketo Connector

Restrict Prefilled Marketo Form

Another feature that we have implemented is the Restrict Prefilled functionality on the field level. Through this functionality, we can hide the prefill for some custom field value or some form field value. The customer will have to fill the information for these fields every time he visits the website. We have provided the functionality in the back-end.

Drupal Marketo Connector

DoS Attack Configuration:

Through this functionality, the form can be protected from DoS attacks. If a malicious user hits the form repeatedly, the prefilling functionality will be turned off and the user will be barred from using it till the penalty time is over.

***

You should leave no stone unturned to make the customer experience smooth and efficient. The form prefill feature can definitely prove useful in this regard. Make optimum use of the data that you already have and direct it towards making your users’ journey better.

Want to Know More About Our Drupal Services? Contact Us.

Grazitti has been offering full-fledged Drupal web development services to companies across the globe for the last 10 years. We also help in automating processes using our custom plugin that integrates your website with Marketo to boost conversions and sales. Learn more about our web development services here or write to us at [email protected].

Tags:

Drupal Marketo Connector

Related Articles

May 23 2019
May 23

Through the late 90s and through the early to mid-2000s there was a great rivalry, Open Source versus closed, proprietary software. At times it got ugly - any of us working at that time will remember the “Linux versus Windows” flamewars and the Microsoft-as-the-Borg memes (before “memes” were a thing). But all the ire directed at MS could arguably be justified - recall the so-called “Halloween Documents” or Steve Balmer declaring that “Linux is cancer”.

How different did things look to a programmer at the end of the second decade of the 21st century? To some extent, the “war” is over. Open Source Software is ubiquitous across the entire stack, from server infrastructure to front end frameworks.

My guess is that you’d be hard pressed to find a modern software project that doesn’t involve Open Source in some way.

If I were to attempt to answer the question “how can you use open source to your advantage” twenty years ago, the overall thrust of my suggestions would look a lot different than they do today (and possibly a lot angrier). I don’t have to convince you or the utility of Open Source. History has already done that for me.

If you’d like a rundown of the reasons that people ordinarily use to justify why you should investigate/use Open Source, you’d be hard pressed to find a better summary than Michael Tiemann’s whitepaper “How open source can save the ICT industry $1 Trillion per year”.

I’d like to suggest a few, more personal, reasons how you might use Open Source to your advantage. Think of them as expanding circles of concern, first for yourself, then your immediate community, and then for the world as a whole.

What others give to us

I’m not suggesting that you can use Open Source software to beef up your resume, which I’ve seen argued again and again. Rather, I’m speaking to those programmers who genuinely care about becoming better at what they do.

There’s a deep satisfaction in progressing at your craft - whether that be writing poetry, painting, or coding - and there are at least two parts to this. The first is actually producing, writing new poetry or code. That’s vitally important. But there’s a second, arguably more important, and often forgotten part.

That is, developing your taste.
Your eye.
Your sensibilities.

Ira Glass, in his much-shared piece, speaks about “the gap” that exists in any artist between their taste and what they can produce at any time.

The suggestion is that becoming a better artist is about producing a lot of work so that what you’re making begins to line up with what you consider great. Your taste guides your practice.

With visual arts or prose, developing your taste seems to be simpler. Those writers can read a lot of poetry. Those artists can visit galleries and view hundreds of the best works that history has to offer. Further, there’s a long tradition of critical literature that reaches at least as far back as Aristotle that can help inform us, help further develop our taste.

While the field of critical code studies is relatively new and we don’t yet have quite the mass of critical literature as poetry or visual arts (it does exist, though -- this is a wonderful example), the fact that there are just so many examples of truly great code that we’re able to read and learn from means that the problem of developing taste, and thus knowing what great code is in your bones, is made far simpler.

Fabian Sanglard, for instance, suggests that anyone wanting to become a great C programmer should read the source of the games Doom and Quake. Closer to my own concerns, being a web developer, I might suggest to a junior on our team to read something like Elloquent’s Collection class for an example of an elegantly structured set of abstractions, or the code for the Slim Framework to get a clear idea of how precisely middleware works.

What we can give to others

This might be the most personal (for me) of the three ways you can leverage Open Source software, and I doubt it will resonate with everyone - but it might, so it’s worth mentioning.

The first time you ask a question can be terrifying.
The first time you submit a bit of code to a project can be terrifying.
Making a mistake in either of these can be mortifying.

And yet, learning to be brave enough to ask questions, to make suggestions, to submit PRs - is a vital step to becoming a better developer.

For some, these steps are taken in their first jobs, within the context of a team, sometimes with a mentor. For most, I’d bet, this is not the case.

Open Source projects are the perfect place to get this kind of feedback, to experience what it’s like working with other programmers, asking questions etc.

This is not simply about developing your taste, or reading code, but learning about the collaborative nature of programming.

Open Source projects are a fantastic space in which to get this kind of experience for new programmers. But we need to be mindful.

There is a certain style of communication in “tech” that’s needlessly aggressive. When there is a community that, or individual who has adopted this kind of communication style, it can be chilling for those who are just getting started. I’m not sure what causes some people to use their knowledge and experience as a weapon, but the mere presence of someone adopting that kind of style can be crippling.

I’m not suggesting there shouldn’t be standards or that anything should go in terms of code. It’s good and right to worry about quality and correctness. But this style of communication can drive people away who might otherwise make great contributions, who may eventually be great programmers. It can drive them away faster and more successfully than any kind of intrinsic difficulty there is in programming.

And so, my second suggestion about leveraging Open Source has two parts.

First, Open Source may be an important place for beginners to take their first steps collaborating and learning “in the open”, sure. But here I’m not really interested in the in beginners.

The second and more important aspect is for more experienced programmers. Working in Open Source gives us the opportunity to be kind to those taking their first steps, those just learning to be brave. We can listen, we can answer with patience, we can learn how to guide people without hardening ourselves towards them and their feelings. We can learn to put aside our frustrations, and when we can’t, learn how to express them humanely, in ways that don’t belittle and crush.

Furthermore, when we successfully demonstrate this kind of behaviour towards others, we’re acting as a positive example for the next generation of programmers.

What we can change

I mentioned at the beginning that Open Source has won, at least in terms of global adoption and acceptance by businesses. But this is only a partial victory.

Open Source, and free software more generally, has never simply been about business value. It has to a large degree been underwritten by the notion that we can change the world.

What I’m suggesting is that we should remain alert to this revolutionary undercurrent in Open Source, to not forget it.

It seems to me that in Open Source software we have a strange win-win situation - we have the opportunity to deliver business value while at the same time making the world a better place. This is what has always drawn me to work with and in Open Source Software. Installing Linux used to feel like a small act of resistance.

And even now, the code you contribute to a project like Drupal or Laravel doesn’t simply make, say, a form easier to place on a page, but it can help, in some small way, say, a startup in Zimbabwe with no access to capital to build a viable business.

It can help charities and governments save many millions of dollars on software licenses, money that is far better spent elsewhere.

In a very real way, Open Source Software has already changed the world. We should never forget that.

My third suggestion for leveraging Open Source is to use it both as an example of how to change the world and as a vehicle to do just that again and again.


Resources:

May 23 2019
May 23

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

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

Host: Ivan Stegic
Guest: Tess Flynn, TEN7 DevOps

In this podcast we'll discuss: 

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

Links:

TRANSCRIPT

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

TESS FLYNN: Hello.

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

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

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

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

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

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

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

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

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

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

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

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

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

IVAN: Nice.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IVAN: No.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IVAN: Oh, my goodness.

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

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

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

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

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

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

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

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

TESS: (laughing) All right.

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

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

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

May 22 2019
May 22

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

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


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

The Drupal Connect

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

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

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

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

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

RESTful Web Services and others

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

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

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

JSON:API and others

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

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

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

GraphQL and others

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

OpenAPI and related modules

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

Contentajs and related modules

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

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

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

Of relating to JavaScript frameworks

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

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

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

Conclusion

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

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

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

May 22 2019
May 22

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

What is Drupal multisite?

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

Drupal multisite architecture

In the multisite setup, different Drupal sites share:

  • Drupal core
  • codebase
  • available modules
  • available themes

At the same time, they do not share:

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

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

Drupal multisite example

Drupal multisite benefits

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

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

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

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

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

Drupal multisite risks

In some cases, Drupal multisite can present risks — the "flip side" of its benefits. They have caused some heated discussions in the Drupal community.

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

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

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

When Drupal multisite is the best choice

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

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

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

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

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

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

Let’s discuss multisite for your case

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

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

May 22 2019
May 22

One of the significant advantages of using free and open-source software is the ability to fix bugs without being dependent on external teams or organizations. As PHP and JavaScript developers, our team deals with in-development bugs and new features daily. So how do we get these changes onto sites before they’re released upstream?

In Drupal 7, there was a fairly standard approach to this. Since we would commit Drupal modules to a site’s git repository, we could directly apply patches to the code and commit them. A variety of approaches came up for keeping track of the applied patches, such as a /patches directory containing copies of each patch or using drush make.

With Drupal 8’s adoption of Composer for site builds, not only did the number of third-party dependencies increase but a new best practice came along: /vendor (and by extension, /core and /modules/contrib) should not be committed to git. Instead, these are left out of the site repository and installed with composer install instead. This left applying patches in a tricky place.

I’m sure I wasn’t the only one who searched for “composer patches” and immediately found the composer-patches plugin. My first Drupal 8 work was building a suite of modules and not whole sites, so it was a while until I actually used it day-by-day. However, when that time came, our team ran into several edge cases. Here are some of them.

Some issues we ran into with patching

❗ Note that we originally did this investigation in June of 2018, so some of these issues may be different or may be fixed today.

Patching of composer.json is tricky

Sometimes, a change to a library or module also requires changes to that project’s composer.json file. Typically this is when a new API is added that the project now requires. For example, we needed to update the kevinrob/guzzle-cache-middleware library in the guzzle_cache module so we could use PHPUnit 6. Since composer-patches can only react to code after it’s installed it can’t see the updated require line in the module’s composer.json. Even if composer were modified to detect the change and rebuild the project’s dependency tree, that is a slow process and would impact composer update even more.

“Just apply the patch” assumes consistent patch formatting

It’s a fact of life that different projects have different patch standards. While the widespread adoption of git has improved things, proper prefix detection is tricky. For example, we ran into a situation where a Drupal core Migrate patch that only added new files was being added to the wrong directory. There was a configuration option we could set to override this, but it was many hours of debugging to figure it out.

Patch tools themselves (git apply and patch) don’t have great APIs for programs to use. For example, git apply has had many subtle changes over the years that break expectations when users are running old versions. Trying to script these programs for use across the broad spectrum of systems is nearly impossible. There’s an open issue to rewrite patching in PHP for composer-patches, which is a big undertaking.

Patching on top of patches

Some sites may require multiple patches to the same module or library. For example, on a recent Drupal 8 site we launched, we floated between 5 to 10 patches to Drupal core itself (with the actual set of patches changing over time). If patches conflict with each other, resolving the conflicts is a lot of work. You have to apply one patch, and then apply each successive patch resolving conflicts at each step. Then, a new patch has to be generated and included in composer.json. When an upstream release occurs, or a patch is merged, the whole process starts over. This can be especially tricky in situations where a security advisory has been published, and you’re under time pressure to get a release out the door.

Faith in rm -rf vendor web/core web/modules/contrib

When patches fail to apply correctly, it can sometimes leave local vendor code in a broken state. For a long time we had an rm in our CI build scripts even though we were trying to improve build performance by caching vendor code. Several times a week developers on our team would report having to do the same on their locals. On the one hand, at least this was an option to get things up and running. However, it was concerning that this was our solution so much of the time when we couldn’t quickly find a root cause.

You still have to fork some projects

By default, applying patches is a root-only configuration in composer.json. That means that if a Drupal module requires a specific patch in another library, it won’t be applied. It’s possible to enable patching of dependencies, but it still requires the developer to be aware that the patches are required. If you’re maintaining a module or library used by different teams, it’s much less of a support burden to fork the patched project.

If you have an existing code base, and you haven’t hit any of these issues, then it’s fine to stick with what you have. We have some teams who haven’t had any trouble with patches. But, if the above issues are familiar, read on!

What does upstream use?

After encountering the above issues, we took a step back and looked beyond the Drupal island. Certainly, we weren’t alone. What are other composer-managed PHP projects doing to solve this problem?

After some research into what PHP projects outside of Drupal, and npm projects do, most use a forking model instead of a patching model.

I was curious about patch-focused solutions for other code dependency managers. I found patch-package for npm, which is the most popular package for applying patches during npm builds. Looking at their issue queue, it seemed like that entirely independent project experienced similar classes of bugs (#11, #49, #96) as composer-patches. For example, there are bugs related to patches applying differently based on the host environment, handling multiple patches to a single package, or applying patches in libraries and not root projects.

I’m in no way trying to say that these issues can’t be fixed, but it does provide some evidence that my prior troubles with composer-patches were more due to the complex nature of the problem than the specific implementation. As someone who routinely works on projects where a code base is handed off to a client team for maintenance, solving bugs with less code (in this case, by removing a plugin) is almost always the best solution.

The Steps for Patching and Forking

Let’s suppose that we need to patch and fork the Pathauto module.

  1. Fork Pathauto to your user or organization. In most cases, forking to a public repository is fine. If it's a Drupal module, you can import the repository to GitHub using their import tool. Any other Git code host will work too.
  2. Clone from the fork you created and check out the tag you are patching against.
  3. Create a branch called patched.
  4. Apply the patch there, and file and merge a pull request to your patched branch with the changes.
    1. Optionally, you can create tags like 1.2-patch1, incrementing patch1 each time you change the patch set against a given tag.
  5. In your site, add the newly forked repository to composer.json:
    "repositories": [
     {
         "type": "vcs",
         "url": "https://github.com/lullabot/drupal-pathauto"
     },
     {
         "type": "composer",
         "url": "https://packages.drupal.org/8"
     }
    ]
    
    
  6. Use the new branch or tag in the require line for the project you are patching, such as dev-patched or ^1.2-patch1.
  7. Run composer update drupal/pathauto and you will get the new version.

We like to create a PATCHES.md in each fork file to keep track of the current patches, but it’s not required.

Rerolling your patch

If you haven’t already, you’ll need to add a second remote to your local git checkout. For example, if you imported Pathauto to GitHub, you’ll need to add the Drupal.org git repository with git remote add drupal https://git.drupalcode.org/project/pathauto.git. Then, to fetch new updates, run git fetch --tags drupal.

In most cases, you can simply run git merge <new pathauto tag> into your patched branch. The patch(es) previously applied will be left as-is. If there are conflicts, you can use your normal merge resolution tools to resolve them, and then update the issue with the new patch.

Removing your patch

If your patch has been merged, and it was the only change you’d made to the project, you could simply abandon the fork and remove it from your site’s composer.json.

Otherwise, in most cases you can simply merge the new tag into your patched branch and git will detect that the changed files now have identical contents. You can double check by running git diff <tag> to see exactly what changes your fork has compared to a given version.

Handling Drupal Core

There are two small cases with Drupal to be aware of.

First, the Drupal Composer project has a composer script that runs to download index.php, ROBOTS.txt, and other “scaffolding” files when you change Drupal core releases. For example, if you create a 8.7.0-patch1 tag in your fork, the scaffolding script will look for that tag on Drupal.org, which won’t exist.

The best way to handle this is with Composer inline aliases, specifying in require:

"drupal/core": "8.7.0-patch1 as 8.7.0"

Unfortunately, drupal-scaffold doesn’t check for inline aliases, but there’s an open pull request adding that support. Or, you can ignore the errors and manually download the files when updating Drupal.

A slightly trickier issue comes from how Drupal core handles release branches. Most other projects using Git, such as Symfony, will forward-merge changes from older versions to newer versions. For example, with Symfony you could checkout the 3.4 branch, and merge in 4.1 without any conflicts.

Drupal treats its branches as independent due to the patch-based workflow. A given bug may be fixed in both 8.6 and 8.7, but the actual changes might conflict with each other. For example, merging 8.7.0 into 8.6.15 leads to dozens of conflicts.

Luckily, git has tools for this situation.

$ git checkout 8.7.0 # Checkout the new version of Drupal.
$ git checkout -b update-core # Create a branch
git merge -s ours 8.6.15 # Merge branches, ignoring all changes from 8.6.15. The code on disk is identical to 8.7.0.
git merge patched # Merges just the changes left over from our patched branch into 8.7.0 - only patch related conflicts remain.

Once the transition to GitLab on Drupal.org is complete, and we start using git merges in Drupal workflows, these extra steps should go away.

Transitioning an existing project

When we moved to this workflow, we didn’t want to update every single patched dependency at once. At first, we just updated Drupal core as it was the project we had the most trouble with, and we wanted to be sure we’d see a real improvement. In fact, the site I first used this workflow on still has a few patches applied with composer-patches. For existing projects, it’s completely reasonable to transition dependencies one at a time as they need to be updated for other reasons.

Results

Over a period of several months, we incrementally replaced patches with forks as we updated dependencies. Over that time, we saw:

  • Fewer git checkouts in vendor. With patches, you need to set "preferred-install": "source" which causes Composer to use git to fetch dependencies. With forks, Composer uses the GitHub API to download a zip of the code, which is significantly faster.

  • A much faster composer install.
  • Easier peer review, because the patch is applied in the forked repository as a pull request.
  • Simplified updating of patched dependencies, as we could use all of git’s built-in tools to help with conflict resolution.
  • Forks completely solved problems our front-end developers had with composer install failing to apply patches correctly.
  • An identical workflow for Drupal modules, PHP Libraries, and node packages.
  • Reduced maintenance by sharing patch sets with multiple projects.
    • For example, we are working on a Drupal 8 project for a client that is their second Drupal 8 site. Rather than track and apply patches individually, we point Composer to the existing Drupal 8 fork from the first site. This significantly reduces update and testing time for new core releases.
  • Simplified checks for dependency updates by running composer outdated.

There were a few downsides:

  • Sometimes slower composer update especially if dependencies have lots of tags. In practice, a straight composer update on a site takes between one and two minutes.
  • Many more repositories to manage.
  • Simple patch updates with no conflicts are a little more work as you have to push to your forked repository.
  • If your team doesn’t have any private repositories with custom modules as a Composer dependency, team members running composer update may need to generate an API token. Luckily, Composer provides a one-click link to generate one.

Many thanks to James Sansbury, Juampy NR, and Eduardo Telaya for their technical reviews.

May 22 2019
May 22

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

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

Enter Layout Builder.

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

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

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

How It All Started

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

 drupal6-cck-display-fields-srijan-1

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

drupal7-image-display

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

drupal8-image-display-srijan-technologies

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

powerful-customization-in-tempaltes-srijan-technologies

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

block-description-srijan-technologies-1

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

panels-srijan-technologies

What Went Wrong?

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

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

Layout Builder - What and Why

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

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

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

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

layout builder infographic

Why Else Choose Layout Builder?

Simple Page Management

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

Accessibility

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

Workflows

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

Templates

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

How to Work with Layout Builder?

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

devel-srijan-technologies

 Source: OSTraining

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

content-type-srijan-technologies

Source: OSTraining

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

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

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

 

Upgrade to Drupal 8.7 without a doubt!

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

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

May 22 2019
May 22

Drupal 8.7 was released with huge API-First improvements!

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

Thanks to everyone who contributed!

  1. JSON:API #2843147

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

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

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

  2. datetime & daterange fields now respect standards #2926508

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

    For a field configured to store date + time:

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

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

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

    For a field configured to store date only:

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

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

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

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

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

  3. rest.module has proven to be maintainable!

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

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

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

Was this helpful? Let me know in the comments!

For reference, historical data:

May 21 2019
May 21

As a digital agency, we believe it’s important to remember the world that exists beyond our JIRA boards. We feel a genuine responsibility to always try to do something that can be of service to the greater good; especially when the opportunity to give a damn is so constant and pervasive.

Our Director of Tech and Director of Sales & Marketing beckon participants to our Drupalcon booth Rob Loach and Larkin McGowan beckon attendees to our DrupalCon booth

Consequently, for DrupalCon Seattle, Kalamuna partnered with OneTree Planted and sponsored the planting of 450 trees in areas devastated by the recent California forest fires. These fires – comprised of 8,527 fires burning a total 1,893,913 acres – were practically in our backyards, and it broke our hearts to hear of the tragic loss and desolation around us.

The number of trees we sponsored was determined by engagements we solicited at our DrupalCon booth. Attendees were invited to plant a sticker on our wall. Every sticker became an actual tree we sponsored. Participants who signed up for our newsletter funded the planting of another tree, and those who gave us a shout-out on social media sponsored yet another tree. 

twitter image of April Sides from Lullabot engaging our DrupalCon booth Thanks for sponsoring trees April!

Many of the employees of Kalamuna come from backgrounds outside of tech where we have used the resources and skills at hand to contribute to the Occupy Movement, political art collectives, voter drives, a prisoner’s library project, among other things. It was in this spirit that we recognized that swag is inherently wasteful. Why not put that money towards something that is useful, and let that be the thing people remember about Kalamuna? If nothing else, we’ll have at least redirected our swag budget to a worthy cause, and funded some trees.

Rachel Agyemang tweets that she's pleased to see more meaningful swag Your shout out means a lot to us Rachel!

We find a lot of meaning in the conversations sparked by our conference booths. We love talking about our Drupal powers, but we also love learning non-Drupal things from the people we meet. For example, because our booth nodded towards activism, and leaned towards environmental issues, we learned that websites emit quantifiable carbon emissions, and that Microsoft has an admirable program to support employee giving.

We love our Drupal family, and it’s for this reason that we try to reignite the hashtag #Drupal4Good. We want to further the conversation around how Drupal can be a force for good. We’re heartened to know other agencies in the Drupalverse, like our friends at Last Call Media, also recalibrated their DrupalCon booth for charity, and we applaud Mediacurrent for their ongoing generosity. It's an ethos we hope continues to be contagious.

As Drupal agencies continue to grow, this trend towards giving is a natural philosophical extension for businesses making their livelihood with an open-source ecosystem in constant need of communal contributions. It’s embedded in our DNA and we’d love to see it expand. Kalamuna has donated thousands of dollars at each BADCamp and DruaplCon booth since 2017, and it feels like we're just getting started (stay tuned)!

A digital certificate from OneTree Planted verifying our 450 trees It's official!

May 21 2019
May 21

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

drupal-wordpress

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

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

Ease vs Order

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

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

Model vs. Building Blocks

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

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

Solo vs Team

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

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

Pages vs. Architecture

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

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

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

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

Explore Duo

May 21 2019
May 21

drupal sneakers

We made a pair of Drupal-inspired kicks to give away at DrupalCon Seattle. We knew that single pair would be highly coveted but we got challenged to "open source" the design after word got out.

I think we need @thirdandgrove to open source the Nike ID config for these :)

— Tom Wentworth (@twentworth12) May 10, 2019

We've always been open source so it only makes sense: Create your own pair using the original #drupalsneakers design. Tag @thirdandgrove with your take on the Drupal sneakers to complement your daily getup.

drupal sneakers

May 21 2019
May 21

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

A quick introduction

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

Open Source

Wikipedia sums up open source software well.

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

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

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

Drupal

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

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

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

Drupal for experience-led commerce

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

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

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

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

TELUS Mobility

Website: www.telus.com

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

You can read the full TELUS Mobility case study here.

Bug Out Bag Builder

Website: www.bugoutbagbuilder.com

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

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

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

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

BikeHike Adventures

Website: www.bikehike.com

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

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

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

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

Who is Drupal best suited for?

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

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

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

UPDATE: Read part 2 of this series - BigCommerce & Drupal for Growing Ecommerce Businesses

Additional resources

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

Click to discover your ideal architecture with our analysis.

May 21 2019
May 21

by David Snopek on May 21, 2019 - 9:17am

As you probably know, Drupal 6 reached its End-of-Life (EOL) on February 24th, 2016. However, the mantle of supporting Drupal 6 was taken up by the Drupal 6 Long-Term Support vendors - including the team here at myDropWizard!

Long-Term Support isn't glamorous or exciting.

It's making security releases. It's minor bug fixes. Sometimes it's updating a contrib module that hasn't had an official release since 2009 to work with PHP 7. :-)

In fact, a big part of Drupal 6 Long-Term Support (D6LTS) is updating Drupal 6 core and contrib to work with new technologies, especially as the older versions that it was originally designed to work with become deprecated or reach their own EOL, like when PHP 5 reached its EOL at the end of last year. (Did you know that Drupal 6 now works with PHP 7?)

Today, I'd like to announce that Drupal 6 supports MySQL 8, starting with Drupal 6.51!

This was implemented in collaboration with the community, largely the contributions of f1mishutka, but also a number of others who contributed testing and bug reports.

I know there's a lot of anxiety over how Drupal 7 Extended Support (D7ES) is going to work, however, I think that this is more evidence that the vendor-supported model used by D6LTS (and soon, D7ES) is working.

You can download the latest Drupal 6 LTS core release from GitHub.

May 21 2019
May 21

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

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

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

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

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

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

Benefits of migrating to Drupal 8

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

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

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

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

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

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

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

How easy is it to upgrade my site?

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

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

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

What can ComputerMinds do for you?

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

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

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

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

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

May 21 2019
May 21

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

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

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

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

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

Pune Drupal Group monthly meetup 2019

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

Pune Drupal Group monthly meetup 2019https://dri.es/drupal-7-8-and-9

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

Pune Drupal Group monthly meetup 2019

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

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

Pune Drupal Group monthly meetup 2019https://dri.es/drupal-7-8-and-9

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

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

Pune Drupal Group monthly meetup 2019

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

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

May 21 2019
May 21

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

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

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

Steps for sponsoring a feature

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

  • Communication

  • Documentation

  • Agreement

  • Payment

Communication

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

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

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

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

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

Documentation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Giving back to the community​

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

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

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

Addressing some hesitations and concerns​

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

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

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

How do we get started?

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

If you want to take a much larger, bolder, and significant first step that earns trust and shows good will, please join the Drupal Association and back the Webform module's Open Collective.

Almost done…

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

OKSubscriptions powered by Strikingly

May 21 2019
May 21

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

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

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

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

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

You Need to Have a Content Strategy. But Why?

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

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

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

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

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

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

Some of the benefits of a digital content strategy are:

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

Building Content Strategy With Drupal

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

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

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

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

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

Unifying the Content Strategy Across Channels with Drupal

Content Governance

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

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

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

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

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

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

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

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

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

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

Enterprise-wide password control systems

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

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

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

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

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

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

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

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

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

Content Modelling with Drupal

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

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

Content modelling is a critical starting point for website content.

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

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

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

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

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

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

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

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

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

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

Omnichannel Content Strategy with Drupal

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

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

API First Publishing with Drupal

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

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

[embedded content]

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

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

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

Mobile-first and Out of the Box Responsive

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

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

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

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

Personalization with Drupal

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

This orchestrates customer experience and drive engagement.

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

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

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

Drupal in Other Marketing Technology

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

Virtual Reality

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

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

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

[embedded content]

 
Augmented Reality

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

[embedded content]


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

Wrapping Up

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

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

May 21 2019
May 21

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

Optimized Image

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

Adjusting Image Dimensions

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

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

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

Configure image styles

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

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

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

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

Create image styles

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

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

No image style

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

Image style 970

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

Image style 970 comparison

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

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

Image style 1940 comparison

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

Defining Image Quality

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

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

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

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

Image style 1940 toolkit

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

Image style 970 toolkit

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

Image style 970 toolkit comparison

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

Image style 1940 toolkit comparison

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

Responsive Images

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

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

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

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

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

Retina settings

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

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

Conclusion

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

May 21 2019
May 21

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

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

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

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

everyone benefits and work is a lot more fun.

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

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

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

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

Human Centered Design vs. Agile Development

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

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

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

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

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

Going Wider, Digging Deeper 

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

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

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

Stakeholder Mapping

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

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

Persona Development

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

Drupal-Specific Rose-Thorn-Bud

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

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

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

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

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

Drupal-Focused Statement Starter

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

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

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

Their responses are recorded here.

Importance / Difficulty Matrix

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

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

Illustration of an Importance/Difficulty Matrix


Why Human-Centered Design?

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

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

May 20 2019
May 20

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

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

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

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

Suzanne Dergacheva

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

Ryan Szrama

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

Jono Bacon

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

What is the role of the Review Panel?

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

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

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

How do the Drupal Association and the CWG work together?

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

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

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

May 20 2019
May 20

For years, SimplyTest.me has provided a once-and-done tool for testing Drupal, and Adam Bergstein has recently taken over maintainership. In this episode we find out why, how you can help, and coffee!

May 20 2019
May 20

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

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


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

Faster Drupal - Part 2: Aggregation and CDN

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

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

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

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

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

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

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

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

Image optimization

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

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

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

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

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

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

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

 

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

 

Written by Sohail LajevardiSohail Lajevardi
Developer at Ramsalt Lab

 

May 19 2019
May 19

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

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

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

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

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

The Drupal 9 Release and Timeline

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

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

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

a horizontol table with Drupal versions

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

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

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

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

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

The Upgrade and The Tips

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

Text on left with a blue table in centre and left

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

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

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

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

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

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

What is Deprecated Code?

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

Here is an example of the deprecated function:

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

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

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

Ways to Find and Fix Deprecated Code in your Drupal Project

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

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

      deprecated-code-1-srijan

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

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

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

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

Wrapping Up

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

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

May 19 2019
May 19

Do try this at home!

Check out my repository on GitLab:

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

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

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

,

Umami home page

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

,

How Drupal works with Gatsby

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

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

JSON:API

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

,

Gatsby home page

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

,

Gatsby blog list

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

,

Gatsby blog page

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

,

GraphQL queries

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

,

Drupal and Gatsby configuration

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

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

,

Lando configuration

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

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

What's new?

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

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

All of these projects have more recent releases.

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

May 18 2019
May 18

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

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

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

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

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

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

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

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

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

Refs

Pages

About Drupal Sun

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

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

See the blog post at Evolving Web

Evolving Web