Sep 24 2018
Sep 24

Agiledrop is highlighting active Drupal community members through a series of interviews. Learn who are the people behind Drupal projects. 

This week we talked with Mike Gifford. Read about what his company is striving to achieve, where he thinks has been a lot of movement in the last 2 years regarding Drupal and what contribution to open source is he proud of. 

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

I am best known in the Drupal Community for my work on web accessibility. I am a Drupal 8 Core Accessibility maintainer and I have been spearheading changes in Core for the last decade. I have, also, done work on security and have published a Best Practices Guide to help managers, developers, and system administrators. 

I am the founder and president of OpenConcept Consulting Inc., this web development firm is based in Ottawa, Canada and has been specializing in Drupal for over 13 years. We are a Certified B Corporation and work to be sustainable in every way that we can. We are striving to be a carbon neutral business, and promote ways that we can all minimize our footprint (both online & offline). I have organized numerous of Birds of a Feather (BoF) sessions at Drupal events, trying to build a community of firms that want to “do good and do well”. 

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

I was definitely convinced by the community before the software. Both are amazing, but I continually met people 14 years ago, who were advocating for OpenConcept to move to Drupal. It was a great community and one that I could see working with for a long time. We had been working on our own open source CMS at the time and had built in a lot of multilingual features. It took quite a few years for Drupal Core to surpass the work we had done to support multilingual organizations.  

It was clear that the dedicated team building Core was going to make it easier to maintain sites over the long haul. We were excited by the vast number of modules that were there at the time. Drupal had a critical mass of professional developers and users that made it really attractive to me. I came to appreciate the importance of critical mass when dealing with all software projects.  

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

There are lots of moments that have had an impact on me. Whether it was seeing the community get together to bring Vincenzo Rubano to DrupalCon Portland or being inspired by the work of Leisa Reichelt to make this geeky community more user-friendly. There are so many people finding ways to collaborate and innovate together, whether that is in government or around issues like the GDPR. I have had many fun and inspiring moments engaging with people, both online and in person. 

I think that one big thing was the realization that by improving Drupal, I have been able to help shift 2-3% of the web. I do remember the world before the World Wide Web, but it is hard to imagine how modern life would function without it. Being part of a big community has allowed me to make a dent in how the web is built, this is huge!

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

Most people have heard about WordPress so I generally start with a comparison to this well-known web platform. If they are familiar with WordPress, I tend to talk about how the communities are similar and different. Drupal has a greater commitment to building an open source ecosystem where people are free to use, modify and distribute the code. I explain that  Drupal is a more complicated framework than WordPress, as it has the capacity to have robust permissions and workflows. 

We have done much work in the Drupal community to make it accessible for everyone. WordPress is catching up but has a long way to go and is limited by their ecosystem. I talk about how they are both based on PHP/MySQL and that both projects have their core code under the GPL. Because of this shared code be base and license, there is some overlap. 

For people less interested in the technical details, I discuss how Drupal is a community-driven software that helps people publish content to websites. 

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

It’s hard not to jump right to an API driven framework with a headless JavaScript frontend (likely ReactJS). There has been a lot of movement in this area in the last 2 years, and Drupal 8 has come a long way to help present its’ structured content effectively to a wide range of devices. 

I do think that we will need to do more to recruit more JavaScript focused developers to make good use of this opportunity. This knowledge-set will be needed across the board. 

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

Absolutely, it is based around web accessibility. Seeing what a small team of people can accomplish in an open source community, provides me with a lot of hope for a future that is accessible by default. I was in a pretty unique position to be able to invest time into improving this piece of Drupal. Most of what I learned about accessibility was done through working on Drupal Core. I am really pleased to have helped support other people in getting engaged as Maintainers: Everett Zufelt, Brandon Bowersox-Johnson, Andrew Macpherson & Daniël Smidt. These are just some of the communities that got behind changing Drupal Core as well as helping to make the community, as a whole, more inclusive. 

Drupal 8 has centralized many elements of accessibility that make it easier to make and maintain an accessible site. Drupal is one of few projects that has invested in implementing elements from both parts of ATAG 2.0. The Drupal community accessibility is evolving, and just like security, is something we are going to need to work on and improve as long as Drupal is being used. 

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

I would like to highlight some of the work that is being done by the Drupal Association on making usability improvements to Drupal.org. We are dominated by geeks and we tend to focus on geeky projects rather than design/usability/behavioral changes. Much of this started with Leisa Reichelt’s Prairie Initiative back at DrupalCon Chicago in 2011. A lot of bold ideas were brought up at that time (and since). I do think that as a community we can do a lot more to leverage Drupal.org to put a spotlight on the community. We can do so much more than we are to nudge people to become more involved. There is so much more that we can do with our website to help make our community more vibrant. It is amazing to look at places like Stack Overflow where the Drupal community is engaged through gamification to help provide good questions and better answers. 

I wish the changes were happening a lot faster than they are, but I am happy to see the changes. It is not easy supporting a massive platform with hundreds of thousands of users. Making changes in our online community is not easy, as we are a community of very experienced and opinionated professionals.  

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

No.

Seriously though, there is so much interesting work out there. I have been pretty excited about watching governments around the world, work to re-invent themselves along digital communications. The whole Open Government Partnership and Digital 7 is a really interesting effort to build a foundation of openness into a bureaucracy. In Canada, there is a serious effort to change the culture and behavior of government to adopt open source. Departments that have been stuck between choosing to buy from Microsoft or IBM are suddenly in a position of rethinking procurement processes so that they might be able to buy services from small businesses. Tiny countries, like Estonia, have been leading this initiative, and it is amazing to see that open source and Drupal was critical to its’ success. 

In Drupal 8 Core, Vincenzo Rubano did more to improve Drupal’s accessibility than all of the governments in the world combined. Vincenzo did contribute a lot as a student, but surely even a small country that is using Drupal could find ways to contribute more back. Imagine what would happen if government departments started finding ways to contribute back to the open source projects that they use on an ongoing basis. It could mean so much for difficult problems like security, accessibility and sustainability. 

I am hopeful that government IT will begin to shape open source projects for the better.   

Sep 24 2018
Sep 24

One of the most overlooked barriers to working with Drupal is learning its idiosyncratic naming conventions. Most CMSs use a fairly simple set of terms for things such as Pages, Widgets, and Plugins. Drupal used a more computer-science precise language that is nevertheless confusing as heck when you first start working in the CMS.

Let’s review what some of those are!

Nodes/Content

The basic content for Drupal is the Node. This would be a Page (or post) in every other CMS. In the admin interface, the term Node will not be found however - everything is simply called Content.

Node Screenshot

Developers call them nodes. Editors call them content. Why can’t we communicate?

Blocks

Small pieces of reusable content are called Blocks (and sometimes Beans in Drupal 7). These are Widgets in WordPress and elsewhere. They’re primarily managed through the Block Layout page, which is under the Structure tab.

Blocks Screenshot

Blocks, within the Structure tab.

Entities

This is a really confusing one, since it generally only appears on the programming side of things. Entities as used by Drupal are very similar to Objects. The D7 Intro to Entities page has a very good rundown, though they bury the Entity->Object mapping near the end of the page:

  • An *entity type* is a *base class*
  • A *bundle* is an *extended class*
  • A *field* is a *class member, property, variable or field instance* (depending on your naming preference)
  • An *entity* is an *object* or *instance* of a *base* or *extended class*

Most Drupal content, be it Blocks or Nodes or even Users, are different types of Entities.

Modules

This is a plugin or add-on. It extends and expands the CMS. They come in two types: community-contributed modules (contrib), and custom modules. Custom modules are where you should write low-level programming for your site.

Drupal maintains a well-curated (but slow) system for vetting and approving contributed modules and patches on Drupal.org. The pages for managing Modules are hidden under the Extend tab.

Modules Screenshot

Modules AKA Plugin or add-on.

Hooks

Drupal contains a very large library of custom functions. While some can be used or re-used in a standalone manner, there are special functions called hooks that allow you to access specific points in the Drupal execution thread. As such, some have to be implemented in a custom module, and some can be used in the template layer (template hooks). They’re called ‘hooks’ because you rename the first part of the function depending on where you implement it.

For example, if you implement the template hook called hook_preprocess_page() in a theme called mytheme, you would rename it mytheme_preprocess_page(). If you implement hook_form_alter in a custom module called mysite_common, it would be mysite_common_form_alter().

The full, searchable list of Core hooks is in the Drupal Core API. Additional hooks can be implemented in modules.

Views

This is a UI for a custom database query generator, and it’s fairly unique to Drupal. There’s an optional setting in Drupal 8 /admin/structure/views/settings: ‘Show the SQL query’ that can be helpful if you know SQL.

Views is used to build many Drupal lists, such as the primary list of content/nodes seen above, blocks, files, etc., and for content display, such as a dynamic list of upcoming events, or “related content” blocks. The place to add or edit Views is under the Structure tab:

Views Screenshot

Check out these views.

Taxonomy

Sometimes called ‘Tags’, Taxonomy is the part of the site that holds all of the groups of things such as State names, cities, tags, etc. (called Vocabularies), and those contain Terms. It is also under the Structure tab:

Taxonomy Screenshot

Taxonomy under Structure tab.

Machine Name

A slug! Not a terrestrial mollusk, but the version of something that can be rendered easily in a URL.

D.O

This is shorthand for Drupal.org, the primary drupal site, pronounced Dee-dot-oh.

Drush

This is the command-line tool for Drupal. Very useful for clearing your cache (drush cr).

And there you have it! That’s the most common set of (potentially) confusing terms that you’ll run across when you’re learning to use Drupal. Good luck!

Get In Touch

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

Learn More Get In Touch
Sep 24 2018
Sep 24

Software and the internet have metamorphosed the world and its industries ranging from shopping to entertainment to banking. It is no longer something that just supports a business. Instead, it has become an integral part of every part of a business. Organisations interact with their customers through software that is delivered in the form of digital service or application and on all kinds of devices. They also leverage software to enhance operational efficiencies by transforming every part of the value chain. This is where DevOps plays a key role.

Illustration showing a man protruding out of a computer with an envelope in his hand


DevOps is having an astronomical role to play in the rapid IT service delivery mechanisms. And when it comes to Drupal development, DevOps can be instrumental in streamlining project delivery involving Drupal. Before we traverse deeper into how Drupal can benefit from DevOps, let’s look at this terminology called DevOps.

Evolution of DevOps

Illustration showing venn diagram explaining DevOps model


Sometime between 2007 and 2008, when IT operations and software development communities were vocal about some of the calamitous level of dysfunction in the industry, DevOps started to coalesce.
 
Developers and IT/Operations professionals had separate goals, separate department leadership, separate key performance indicators, and, most often than not, they worked on separate floors. As a result, isolated teams were only concerned about their own fiefdoms, long hours, botched-up releases and dissatisfied customers.

People like Patrick Dubois, Gene Kim and John Willis pioneered the evolution of DevOps model

‘There must be a better way’ was the notion that propelled the two communities coming together and talking about betterments in software deliveries. People like Patrick Dubois, Gene Kim and John Willis pioneered this conversation.
 
Therefore, what began in online forums and local meet-ups is now a significant theme in the software zeitgeist which is probably what brought you here!

What is DevOps and how does it work?

Illustration showing an infinity-shaped spiral explaining DevOps
"DevOps represent a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach"

DevOps constitutes Dev which refers to software application development and Ops which denotes IT operations. DevOps is not a framework or a workflow but a culture that is overtaking the business world.

Gartner states that “DevOps represent a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective”.

Development and operations teams are not siloed under a DevOps model. Sometimes, these two are teams are combined to form a single team where the engineers work across the entire application lifecycle ranging from development and testing to deployment and operations. Thus, engineers wind up developing a range of skills which are not limited to a single function.

Quality assurance and security teams may become more firmly incorporated in some DevOps models with development and operations and throughout the application lifecycle. When security becomes the point of focus for everyone on a DevOps team, this is sometimes called as DevSecOps.

These teams leverage practices for automating processes that have been, historically, manual and sluggish. They make use of tech stack and tooling which assist them while operating and evolving applications rapidly and reliably. These tools also help engineers autonomously accomplish tasks like deploying code or provisioning infrastructure thereby enhancing team’s velocity.

Benefits of DevOps

Infographic showing a man running and bullet points describing benefits of DevOpsSource: Algoworks

Incorporating DevOps into the business workflow brings in a lot of merits.

High velocity

Using DevOps, move at high velocity so that you can build digital innovations faster, adapt to altering markets better and grow more efficacious at driving business results. For instance, microservices and continuous delivery allow teams to take ownership of services and then swiftly release updates.

Scalability

Infrastructure and development processes can be operated and governed at scale. Automation and consistency assists in governing intricate and changing systems effectively and with less risk. For instance, infrastructure as a code assists in handling the development, testing and production environments in a repeatable and more efficacious manner.

Faster delivery

Enhance the frequency and pace of releases so that you can build innovate and improve your projects quicker. The faster you can release new features and fix bugs, the quicker you can respond to needs of customers and develop a competitive advantage. For instance, continuous integration and continuous delivery are the practices that can automate the release process right from the build stage to the deployment phase.

Reliable delivery

Quality of application updates and infrastructure alterations can be ensured so you can reliably deliver at a faster pace, thus, providing a positive experience to the end users. For instance, continuous integration and continuous delivery can be leveraged for testing each of the alterations and ensuring that it is functional and secure. Monitoring and logging practices assist you to be apprised of performance in real-time.

Security

DevOps model can be adopted without compromising on security by using automated compliance policies, fine-grained controls and configuration management mechanisms. For instance, defining and then tracking compliance at scale is possible using infrastructure as code and policy as code.

Collaborative efforts

More effective teams can be built as the DevOps model stresses on values such as ownership and accountability. Developers and operations team collaborate closely, share responsibilities, merge their workflows.

Best practices for the adoption of DevOps model

Infographic showing a downward spiral shape describing best practices and stages of DevOps adoptionSource: Cygnet Infotech

There are significant practices that help businesses to implement DevOps model in the best possible way and get the most out of it.

Performing small updates frequently

These updates are more incremental in nature in comparison to the occasional updates performed under traditional release practices. They assist teams to address bugs quicker as the teams can easily identify the last deployment that resulted in the error. Even though the cadence and size of updates may vary, the DevOps model helps in deploying updates more often than the firms who use traditional software development practices.

Using microservices architecture

Making use of microservices architecture helps firms in making their applications more pliable and allow faster innovation. Decoupling large, intricate systems into simple, autonomous projects is possible with microservices architecture. Applications are divided into many individual components or services where each of the services are scoped to a single purpose or function. They are operated independently of its peer services and the applications as a whole. Such an architecture minimises the coordination overhead of updating applications. When each of the services is paired with small, agile teams, businesses can move more swiftly.

Leveraging continuous integration and continuous delivery

Combination of microservices and enhanced release frequency might lead to numerous deployments which can pose operational hurdles. Hence, DevOps practices like continuous integration and continuous delivery help in resolving these issues and allow businesses to deliver faster.

Making use of infrastructure as code

Infrastructure automation practices like infrastructure as code and configuration management allows you to keep computing resources elastic and responsive to frequent alterations.

Monitoring and logging the workflow

Use of monitoring and logging allows the engineers to track the performance of applications and infrastructure thereby reacting swiftly to the issues.

Implementing DevOps model for Drupal development

A table with rows and columns describing a DevOps Dashboard TemplateDevOps Dashboard Template | Source: Smartsheet

The DevOps movement is leading the way forward for higher quality Drupal projects, quicker delivery, happier team members, and satisfied clients for projects of any scale. A digital agency used a Drupal development process to outline key pieces to a reasonable, DevOps-based workflow irrespective of the hosting platform or the different tools you choose to use.

The DevOps movement is leading the way forward for higher quality Drupal projects, quicker delivery, happier team members, and satisfied clients for projects of any scale

The agency maintains a pre-configured Drupal 8 install profile that lives on Github which is also mirrored on Packagist. This helps in kickstarting all the new projects with a working theme, pre-configured content types, Media bundles, Paragraph bundles and other elements.

A solid local development workflow is integral to any continuous workflow environment. Developers build new features or fix bugs on their local machines and the alterations are pushed to Github for triggering several actions. The agency experimented with DrupalVM and Lando which offered easy, repeatable processes for enabling developers and contractors to easily spin up a local environment matching production environment.

For this agency, the build code for each project like composer.json and any custom modules or theme reside in Github. Every time a pull request is made, their code is automatically deployed to a continuous integration server and to a live web environment.

For incorporating modern DevOps techniques, it needed a programmable hosting platform to let developers and other systems like continuous integration server to automate and interact with the platform. It worked extensively with both Acquia and Pantheon hosting which offered a different set of tools.

It leveraged continuous integration server called Circle CI for automatically spin up and test a new version of the site every time the developer introduces a new functionality or a bug fix to the git repository.

Automated functionality tests are another important part of DevOps strategy which this agency used to a great extent. Each time a commit is pushed, a complete version of the site spins up on CircleCI which runs through a series of automated Behat tests for verifying key functionality. CircleCI automatically notifies the hosting environment if the tests pass thereby spinning up a new branch and a new copy of the site. When the Github pull request is submitted on that branch, the final CricleCI build is triggered. When the tests are successful, the code is automatically combined with the production site.

Future of DevOps

A bar graph showing statistics on DevOps

According to a Capgemini report, 60% of the companies have opted for DevOps model or are planning to do so eventually. That means DevOps is being widely accepted as a key component of a business strategy. As DevOps continues to grow, some of the future possibilities that are expected to transpire along with the increase in DevOps adoption is being outlined here.

Perpetual growth of DevSecOps

Much in the same way, DevOps has the objective of inculcating continuous delivery in the business workflow, DevSecOps expands this to include security. Looking forward, this trend of incorporation of security into the DevOps pipeline will make businesses more inclusive with security tools and practices becoming part of the early development cycle.

DevOps and IoT

Increasingly, hardware manufacturers working on IoT devices would see software as a significant component of their project. This comprises the integration of DevOps into their business workflow making it absolutely compulsory to have people perpetually work on both hardware and software designs.

Monitoring to become the new testing

At the current and future scale, it is a formidable task and impractical to test all conceivable scenarios at the end of the product cycle. Rather than doing this, it is much more worthy to monitor for live issues and rectify them in short cycles. Testing puts a limitation on what you may find as it required you to think of certain problems to look out for.

But, monitoring will bring up issues as they happen. Adoption of monitoring will permit companies to understand the way their software runs in real situations thereby offering quick information about their systems.

Kubernetes to become standard for cluster computing

More companies will join the project and offer services on top of their operating systems. Moreover, extensions will be made for running applications in the cloud. Many of the major cloud providers are starting to provide Kubernetes as a service. Even a serverless Kubernetes will be on offer where nodes are managed by the cloud provider thereby creating another level of abstraction and simplicity for the developers. This general advancement within Kubernetes will lead to an enhanced adoption of advanced monitoring, logging and metric studying within companies.

Removal of (server) operating systems as we know them

This trend links back to Kubernetes becoming a main operating system for the cloud and clusters/containers that means operating systems would be replaced by the ones that can run containers in a Kubernetes cluster. Furthermore, operating systems for hosts will face implications from containers as in these new environments they will no longer have a host.

Conclusion

Continued growth of DevOps into new industries is opening doors for incorporating new departments such as security, enhancement in product monitoring and the standardisation of Kubernetes for cluster computing. DevOps and its accompanying benefits will become the norm as the integration of more departments into the beginning of the product pipeline would transpire and a rise in monitoring would improve solutions and designs.

DevOps strategy would have a positive impact on Drupal development as well and improve the project timeline and delivery. Opensense Labs strongly believe in the digital innovation and can help you provide amazing digital experiences through Drupal development.

Tell us how you want us to be part of your digital transformation journey at [email protected].

Sep 23 2018
Sep 23

This is the second post about the latest developments regarding the editorial experience in Drupal 8 based on a couple of presentations at Drupal Europe 2018.

Gutenberg editor

One project that could make a huge difference in the way the editors perceive Drupal could be Gutenberg.

Gutenberg was being presented at Drupal Europe by the Norwegian agency Frontkom. This contrib module integrates Gutenberg, the React javascript editor that originated from Wordpress, into Drupal.

Gutenberg can be enabled on a per content type level and replaces the node edit form with a blank canvas where the editor can create content using Gutenberg blocks as shown in the demo.

By default, various types of blocks are available to the editor, such as headings, text paragraphs, images and Drupal blocks (like the ones for example provided by the Views module). Other Gutenberg blocks can be custom made and the authors are about to launch the Gutenberg Cloud, a library from where blocks via a UI in Drupal can be installed on your website.

What remained unclear form the presentation was how Gutenberg blocks are being stored in the database and whether the individual blocks can be retrieved in a structured way for example to expose it as a REST resource.

The plan is to launch Gutenberg at the end of this year.

The full presentation is available on Youtube:

Improve Paragraphs with lesser known features

More and more site builders implement Paragraphs to let the users build structured content in a very flexible way. Therefore it was great to see Milos Bovan of MD Systems demonstrate at Drupal Europe-about a couple of lesser known features.

Using the following features you can make Paragraphs even better than it already is.

  • Use the style plugin to give each paragraph a specific style that can be used for CSS styling. The style can be chosen from the node edit form.
  • Add paragraphs to a library so you can reuse them elsewhere in the site. A listing is available to show all the paragraphs that are available in the library. You can promote a paragraph to the library and change it once to have it automatically updated everywhere in the site. If you dont want that then unlink it from the library so that the changes do not affect the paragraphs elsewhere.
  • Use the drag and drop mode to make it easier to order the paragraphs on de entity edit form. In combination with the collapse mode you can drastically improve the paragraphs UI which, often can be quite messy.
  • Organize a long messy list of paragraph types creating type groups. In the UI these groups will become available as separate tabs and by using icons for the types you can make the UI a bit more intuitive.
  • Convert paragraph types. This will allow you for example to convert an existing unstructured text field into a structured card paragraph type.

Multistep forms

Multi Step forms are an important feature of a website or application as it gives users a much better experience when submitting their data. It increases the users motivation to finish filling in the form leading in the end to a much higher conversion rate.

The contrib module form steps seems to to a good job in managing the complexity of the multistep form.

Several contributed modules among them Webform, allow building a multistep form but they are often limited in scope, hard to customize or are simply only available for Drupal 7. Alternatively a multistep form can be achieved by writing your own custom code which could at some point lead to an unmaintainable situation.

The form step module on the other allows creating multistep forms by leveraging the new Drupal 8 core feature of form modes. Much like view mode, form modes are different ways of presenting a drupal form (for example a user profile form or a node edit form).

The Form steps modules, as demonstrated at Drupal Europe by the Drupal agency Actency , lets you create workflows where that are collections of different form modes so that you can present the user with a multistep form. Each step in the workflow is linked to a particular form mode of a specific content type. As a result the user creates several nodes (possibly from different content types) when he follows the steps of the multiforms.

The workflow also manages the progress bar of the multistep form, giving the user the option to navigate through the different steps of the form.

The form step seems to provide a robust solution to a feature that many of us would like implement or should starting to implement in our Drupal websites.

Sep 23 2018
Sep 23

HubSpot provides a powerful combination of customer relationship management (CRM) features and insights that can help organize and maintain business processes tied to customers. Drupal is a key digital platform for businesses, especially for inbound customer engagement, marketing initiatives, and 3rd party integrations. The two systems are highly complementary and deserve consideration for logically separating the responsibilities of digital engagement and customer relationship management. Additionally, both HubSpot and Drupal are very flexible and customizable. As an example, both systems support extensible data structures through custom fields in HubSpot and through the entity system in Drupal that allow for implementation-specific data to be stored and maintained.

Federated Drupal + HubSpot Approach

So you like the idea of using a CRM, but is it really worth all the trouble to integrate it tightly with your Drupal site? Are you afraid of commitment? There’s an interim step you can take before getting married to using HubSpot as your CRM.

If your data isn’t updated multiple times a day, you can work with HubSpot without tightly coupling your data integration. This approach involves using HubSpot’s batch update API. For example, with a regularly scheduled job to grab your active records and upload the relevant fields, you can keep HubSpot aware of your more recent data such as contact information. You get all of the HubSpot goodness without having to change your Drupal code since you get the data directly from your database.

We applied this approach for a Drupal system that isn't really a standard "website" but, instead, a very complex web application with a regularly-updated, separate data warehouse. Users are selected for data inclusion after a series of prior steps involving the end user, customer relations, and third parties. There are hundreds of these records a day which is only a very tiny subset of the site's daily data.

This approach leveraged the data warehouse in AWS, but you could do it against your production database as long as you keep an eye on query efficiency and server load. A CRON job to retrieve updated data was implemented in AWS Lambda, their serverless code platform, but it could also be implemented with a CRON hook in Drupal. While Lambda offers lots of coding choices, PHP isn’t one of them. Fortunately Python is. This approach also allowed us to rapidly prototype and implement our solution without impacting the production system.

Lambda jobs automatically log their output with AWS CloudWatch. After becoming familiar with HubSpot API errors, we built CloudWatch alarms which report to Simple Notification Service (SNS) for notification.

Unified Drupal + HubSpot Approach

While it's more advanced and complex, Drupal’s APIs allow for a much more refined, tighter integration if it is desirable. HubSpot maintains web service APIs for all of its various data objects. Developers can leverage these APIs and the various hooks/events within Drupal to synchronize data bidirectionally.

One common use case is a form in Drupal that end users engage with. The HubSpot module offers Webform integration specifically to HubSpot’s Leads feature. This is a concise, but relevant, single-direction use case in which Drupal can send Webform submissions to HubSpot. This allows for capturing inbound leads within a Drupal system and synchronizing that data to HubSpot.

Drupal’s development framework also supports more nuanced and implementation-specific approaches beyond just the Drupal Webform and HubSpot Leads integration. The HubSpot API module leverages a Composer dependency and Drupal service to integrate a PHP SDK within the Drupal application. This service can be programmatically invoked in any Drupal hook or event. Most CRUD-related runtime hooks programmed into a module allow for any data or transaction to be sent to a corresponding HubSpot entity. For instance, having a user-related hook to synchronize specific Drupal users with HubSpot customers can allow for interactive Drupal applications (commerce, collaboration platforms, etc.) to automatically send customer-related information from Drupal user profiles.

Drupal offers other advanced integration options with HubSpot. Drupal’s CRON system can be used to routinely pull data from HubSpot. This is helpful for creating advanced dashboards and data visualization within Drupal that is potentially tied to a single user-based experience. For instance, a user in Drupal could have a unified experience in which their HubSpot campaign data can be shown in a single dashboard in Drupal without potentially having to log into multiple systems.

The user-based example can be extended with some other key features of Drupal’s provided framework:

  1. Drupal’s Entity API can be used to create a custom entity to track unprocessed users and the state of HubSpot-related operations within Drupal.
  2. Reports can be generated in Views to easily list the tracked entities, like when they were created, when they were processed, their state, and more.
  3. Drupal’s log subsystem can maintain the set of activities tied to the user tracking entities and store HubSpot-generated responses from the API. This helps with failures, which is common for large scale sites with HubSpot’s API rate limiting.
  4. Drupal’s queue subsystem can offer opportunities to leverage CRON in staggering user requests instead of at runtime. This is advantageous should the HubSpot API go down or have slow performance, as there is a built-in failure state. Additionally, operations can be batched which helps avoid hitting API rate limits.

Conclusion

Drupal and HubSpot have a lot to offer each other as complementary solutions. Whether you want a more lightweight, federated approach or a tightly-coupled integrated approach, both Drupal and HubSpot offer enough extensibility through their frameworks and APIs to make even the most complex of use cases happen.
 

Sep 22 2018
Sep 22

Drupal 8's text format system provides a way for developers to manage user generated content, regardless of if the user is trusted staff member or an anonymous commenter. With intelligent configuration of various text formats for the various roles on the site, the security and usefulness of a site can be maximized.

Much like Drupal 7's Better Formats module, Drupal 8's Allowed Formats module allows a developer to limit the text formats that are available on the field level. Normally, all formats that the user has access to are available on all fields, this module allows developers to force a particular format to be applied on a particular field.

The configuration is available on all formatted fields' "edit" page. For example, take this configuration for a "short summary" field.

Allowed Formats example

In this example, only the "Minimal HTML" format will be available for this field, regardless of if the current user has permission to use any of the other formats. For this application, the "short summary" field can only have links, strong text, and emphasized text. By limiting authors to only the "Minimal HTML" text format for this field, these parameters can be easily enforced.

Sep 22 2018
Sep 22

Debugging a Drupal 8 module can take many forms. Often, one of the first tools most developers use is the ability to output variables using the "Devel Kint" module (part of the Devel project). Much like the dsm() function from pre-Drupal 8 versions of Drupal core, the ksm() function provided by Devel Kint provides a slick way to output any variable type to the screen in a readable way. 

Unfortunately, many folks find Kint output to be a bit more cumbersome, and they're right, but Kint is doing a whole lot more than dsm() ever did. In addition to outputting just the variable's values, if said variable is an object, then Kint also outputs that object's methods and other valuable debugging information. Unfortunately, all that information comes with a cost - it tends to really bog down web browsers.

I was finding that some large variables in Drupal core ($form and $node, I'm looking at you) could even crash my browser (out of memory) due to the sheer depth of information returned by a simple ksm(). Out of desperation, I searched for a way to tame Kint a bit so that I could go about my debugging business.

Luckily, I stumbled upon this gist by Julian Pustkuchen which demonstrated how to limit the number of levels returned by a ksm() call. This solved my problem - no more browser out-of-memory issues. The downside is that sometimes a ksm($form) call doesn't get me deep enough into the array, so I have to be a bit more specific when ksm-ing. 

I took Julian's gist and dropped it in my settings.local.php file as follows:

include_once(DRUPAL_ROOT . '/modules/contrib/devel/kint/kint/Kint.class.php');
if(class_exists('Kint')){
  // Set the maxlevels to prevent out-of-memory. Currently there doesn't seem to be a cleaner way to set this:
  Kint::$maxLevels = 4;
}
Sep 22 2018
Sep 22

I've been a big fan of Drupal 8's configuration system since the beta-days of Drupal 8, and even more so now as the contributed module ecosystem around it has matured. I've been using the Config Readonly module from the very beginning to "lock down" configuration on production environments in order to help enforce developer workflows. 

Using the Config Readonly module is a bit of a double-edged sword. On one hand, it really helps in helping get developers accustomed to making configuration changes on local, then exporting them using Drupal 8's configuration system, committing them to the repository, and then moving them up through the project's defined deployment workflow.

On the other hand, sometimes it just really gets in the way. Two areas where I find that clients really find Config Readonly annoying in the live environment is when configuring menu items and block placement, both which can be affected by locked-down configuration. When the Config Readonly module is active, it is not possible to drag-and-drop menu links to reorder them. Nor is it possible to place a block or move a block to a new location.  

Luckily, the Config Readonly module maintainers added the ability to "whitelist" some configurations in version 8.x-1.0-beta3. This allows developers to keep certain configurations "unlocked" on the live environment via the settings.php file. For example:

if (IS_LIVE_ENVIRONMENT) {
  $settings['config_readonly'] = TRUE;
  $settings['config_readonly_whitelist_patterns'] = [
    'page_manager.page_variant.*',
    'system.menu.main',
  ];
}

In this code snippet, all Panel page variant configuration as well as the main menu are whitelisted, allowing site authors to modify these aspects of the site directly on the live environment.

Sep 22 2018
Sep 22

I ran across a situation the other day that had me a bit frustrated for a few minutes until Ted Bowman nudged me in the right direction. I was working on a small custom module for a client - one that involved altering a node form using hook_form_alter() - where I needed to know the value of the node ID being edited.

I had spent more than a few minutes digging into both the $form array and $form_state object desperately looking for the node ID, to no avail. I had pinged Ted on Slack about something else and I asked him if he knew how to find what I was looking for - he told me "maybe the form object is better".

That's all I needed to get unstuck, a few minutes and a Google search or two later, I stumbled upon the following:

$form_state->getformObject()->getEntity()->id()

Not only would this return the node id, it will actually return the id for any type of entity.

Just to be safe, I went ahead and wrapped it in a if-statement to make sure that the form object returned is actually an entity form:

if ($form_state->getFormObject() instanceOf EntityFormInterface) {
  $nid = $form_state->getformObject()->getEntity()->id();
}
Sep 22 2018
Sep 22

What would make for a first-class, enterprise-ready, front-end development team?

Regular Structured Communications

There can be a tendency to presume everyone knows what they are doing and should be allowed to work on their own initiative. This is a tendency I agree with, but it’s also of utmost importance to make sure others on the team also know what each person is working on.

Without regular, structured communications (at least weekly, if not daily, meetings), it’s quite possible for one person to work on a component (say a “tile” component) while another person works on another component (say a “card” component) and both of these components to be the exact same item. Except now we have two versions of the same component, just different names for them.

Without regular, structured communications, each team member is working in a silo, not aware of the whole of the project, and being responsible for only their section. This makes it harder to integrate each section of the site into each other. It will also mean it takes more time for the diligent developer to understand each part of the project if they wish to. Regular meetings save time.

One of the great things about regular, structured communications is that they lend themselves very well to team building. Let your team know you are very proud of how much has been achieved this sprint. Congratulate someone for solving a particular tricky issue. Allow a space for people to vent any issues they might be having.

Fewer Developers, More Focussed

It’s a truism and a paradox, but the more developers we have on a project, the longer the project is going to take to complete. Every new developer takes time to get up to speed with the codebase and slows down the momentum of the other team members. This causes projects to go over-time and over-budget.

This is not to say we should have only one developer per project, but I would suggest keeping teams as small as possible. A small number of really focussed developers will work much faster (having such an intimate knowledge of the codebase, feature set, sprint goals, etc.) than a large team of developers working on many small features. A large team lends itself too easily to people changing someone else’s code not expecting there to be any ramifications, to people “fixing” up another’s code because it doesn’t meet coding standards or has a security issue – work that shouldn’t have to be redone.

Use a Design System/Pattern Library

Pattern library tools have become very popular in the past few years. They allow everyone to see an inventory of the different components the team has available to work with when building web pages.

The tool I have chosen to standardise on is PatternLab. There are many others. Check out the responses to this Tweet to see what other people are using:

They also allow us to show our clients what the designs will look like on real devices, rather than images of what they might look like in InVision or some other tool like that. For years, yes literally years, I’ve been talking at conferences extolling the virtues of using a ‘Design in the Browser’ approach to front-end development and against the practice of using static design tools (Photoshop/Sketch) to deliver designs to clients. By all means, use these tools to deliver the designs to your team, but let the team code up the designs to deliver to your client.

Clients should be sent URLs, not PDFs.

One Component Per Design Feature

Once we are all agreed that we are going to use a pattern library tool, we can then start coding up the features of the front-end. Often components have variations of themselves. An example could be a “Card” component which has an image at the top, followed by a headline; with a variation which has the headline on top followed by the image. In this case we might create a card component and also a card—reversed component.

Card and Card Reversed Wireframe

Sometimes teams can fall into the trap of thinking that “everything” is a variation of a core component. So, for example, we might have a component which has an image on the left, a headline and some teaser text on the right and/or vice-versa. Surely we can just create a component variation such as card—columns and card—columns-reversed? Yes, we can. But then when we see another component that has the same layout, except the image is a different size, there is no teaser text, we have tags under the headline, etc., we are then going to need to make another variation of card— and yet another variation of card— and yet another variation of card— and so on. Technically this is possible, but in practice you are setting yourself up for a maintenance nightmare.

Column and Column Reversed Wireframe

The reason each of these components might look like variations on a core component is because they designers are following brand guidelines and using the same font, same sizing and rhythm rules, same colour scheme, etc. When you think about it like that, everything should look similar – it’s all supposed to fit together, but that doesn’t mean everything is a variation of a core component.

If we want to create all the variations of display types based off one core component, we are going to have a large core file, with a lot of logic and clauses and “if this then that” statements, and an equally large CSS file to take consideration of all the variations. This makes it harder to read the code, harder for new developers to get on-boarded to the project, and harder to maintain.

My suggestion is to create one component per display type. Based on the examples above, we would have a card component and a columns component. My files in PatternLab might look like this:

/card
– card.twig
– card.js
– card.scss
– card.yml
– card~reversed.yml
– card~
no-teaser-text.yml
– card~
no-teaser--text-reversed.yml
– card.md

/columns
– columns.twig
– columns.js
– columns.scss
– columns.yml
– columns~reversed.yml
– columns~
no-teaser-text.yml
– columns~
no-teaser-text-reversed.yml
– columns.md

This means that all the functionality and styling for the card component is within the card directory. It’s a small core file, with only variations for the image to be top/bottom or for there to be teaser text/no teaser text – very obvious variations of the card. The core file should be easy to read (one CSS class will create the variations), and it’s specific enough to know exactly what this component does.

We can set up a regression test for each component very easily to catch any curveballs that might arise later. None should arise if we use correct BEM naming conventions so that all styling for .card is prefixed with .card and all styling for .columns is prefixed with .columns, like so:

.card { css for card container }
.card__image { css for the image in the card }
.card__headline { css for the headline in the card}

.columns { css for columns container }
.columns__image { css for the image in the columns }
.columns__headline { css for the headline in the columns}

Focus on Features, Not Breakpoints

The Unix philosophy says “do one thing, do it well”. Taking this as a guiding principle, we should focus on developing one feature and completing it (the “card” component, for example) before moving to the next one. Sometimes I talk with teams and they tell me they focus on the desktop first or on the mobile screen views first and try to get the whole website looking correct at one breakpoint before moving on to the next one. While much of the code might be fine for each breakpoint, going over the code to catch all the issues for other breakpoints is going to take longer than completing each feature and having them signed off.

Remember, signed-off features can have regression tests written against each breakpoint. It also means that if the site is going to go over time, it’s possible to launch with a smaller set of (completed) features, rather than a feature-complete website, the front-end of which does not meet all the brand guidelines.

Automate Code Quality

Following coding standards can take time. You write your code, you check back over it, you fix up the indentation and comments style. And – you still miss something. The simple fix? Using code sniffers and/or linters and/or combing tools to automate this for you.

I have CSSComb set up in all my projects, so every time I save a CSS or SCSS file, it’s automatically formatted to follow the (Drupal) coding standards. I use prettier for my JS files, so again, each time I save my file, it’s automatically formatted to meet our coding standards. I have php_codesniffer installed and set to (Drupal) coding standards, so it notifies me each time I have an indentation wrong or something like that.

Why is this important? This is important when working as part of a team to make sure everyone’s code looks the same. It makes it much easier to read code from other developers when it is formatted the same as your code. It’s even more important when you edit a file that someone else has worked on and then try to commit those changes to git. How many of the changes were changes you made (that actually affect the code) and how many were just the csscomb or prettier auto-formatting your code? You want your git commits to be meaningful, so you only want the commit to announce the changes you have made.

What I do now on any file I need to work on is save it the moment I open it, so if another developer doesn’t have automated code checkers built-in, the file will format itself. Then I commit this save with the git commit message “running csscomb” or “running prettier”. After this, I make my changes and my commits are then meaningful – I can see the actual code I changed. This takes more time that it would if everyone just installed code formatting tools from the outset, and is something I think we should insist on for every project.

Front-end in Tandem with Site Building

The chances are that the designs are going to be sent to the client as Sketch files or PDFs or similar and not as PatternLab URLs (despite my best efforts to encourage this for years). Or maybe another agency won the contract to design the website and our agency won the contract to build/maintain it. If this is the case, by the time they get to the front-end developers, they are signed-off – a fait accompli.

Let’s turn this into a positive. As we are creating our front-end components (one component per design pattern, please!), we should also be building out the CMS functionality that this component will use. So, if we have a listing page showing teasers of events in a card display, then we should build out the fields (in Drupal or whatever CMS we use) that support this, and then create the configuration and templates needed to map 1-to-1 from Drupal to PatternLab.

This allows us to “dog food” our own work very early on. We can create our front-end and backend in tandem and make sure that both work seamlessly. We can ask our clients to sign-off on the front-end and CMS features at the same time; and we can then set up regression testing for the front-end and functional testing (with Behat or something else) for the backend. As the project progresses, we will have a featured-complete, fully-tested website and can move from feature to feature (or new feature to new feature during future phases of work) with less fear of things breaking when we make changes.

Regression Test

Here’s a joke: a css selector walks into a bar; a table in another bar across town falls over.

Writing front-end code can often be like playing Whack-A-Mole. It doesn’t have to be.

Regression testing is basically taking a screenshot of your website that you can use as a “reference” (this is what it is supposed to look like). Then, when you make a change, you can take automated screenshots of the site again to make sure that the only things changed were things you expected to change. The regression testing tool I use is BackstopJS.

An example: you have a header, a main content area, and a footer. You set up your reference shots when these are all signed off by the client. In a future sprint you are asked to change the main content area from 1220px wide to 1440px wide on desktops. You make the change, tell your regression testing tool to run the tests and then you get back a report showing you that the main content area is now wider than the header and the footer – as it should be. You see the header and footer were not affected so you can deploy this new item. Now, think about doing this for every component across your website! The regression testing suite will run all the tests in a matter of minutes (while you can be happily working on another feature – multitasking for the win!), whereas it could take you an hour to check everything and you might miss something.

Like automating code quality, automate regression testing: automate the boring things.

BackstopJS Regression Testing Report for Mark.ie

Set Time Limit for Being Blocked

If a developer is blocked on something and can’t figure out how to complete the task, that is time wasted. Developers need to know they can ask for advice and they need to know whom they should ask – probably the gatekeeper (see next section).

My general rule of thumb for this is: if I feel I am blocked and just looking at the screen for 15 minutes, I need to ask for help. If I haven’t an idea what to do to unblock myself and I’ve thought hard about it for 15 minutes, that’s enough of the company’s money spent on it.

Ask for help sooner rather than later so you can be as productive as possible.

Nominate Code Gatekeeper

If you need to have a large team of developers, you need to have a code gatekeeper: someone whose job it is to know what components are developed, what ones are in progress, and what is in the backlog.

The gatekeeper also needs to know who developed what component and in what manner, so any components that are re-usable are re-used and one-off components are kept to a minimum. It is the gatekeeper’s job to ensure that no component is developed more than once, just using different names (“card” and “tile” as we saw above).

When someone is blocked or unsure of something, they ask the gatekeeper for advice and guidance so they can continue working as soon as possible. As well as that, the gatekeeper can also step in and try to figure out a solution (or even a proof-of-concept for a solution) while the developer works on something else. When the gatekeeper has an approach figured out they can tell the developer about it and then the developer can get back to that feature as soon as possible. The gatekeeper is a pair of fresh eyes.

The gatekeeper might be the lead developer on the project or it could be a separate role. The gatekeeper should write as little code as possible for the actual production version of the site, and, rather, should focus on the high-level overview of the project and working on solutions to unblock developers.

Conclusion

That’s it. That’s my thoughts on putting together and running a front-end (or teams) that can effectively work on large, enterprise websites. If you have a small team or are a freelancer, I think what I have said above also holds true.

Any thoughts or comments, leave them below. Thanks.

Sep 22 2018
Sep 22

If you want to have multiple Solr indexes using Search API, you need to have a core for each index instance. For my local development stack, I use DDEV. The documentation has a basic example for setting up a Solr service, but I had quite the fun time figuring out how to ensure multiple cores.

After reading the Solr image for Docker, I discovered you can override the container's command and pass additional commands as well. I found the issue "Create multiple collections at startup" from Sep 2017 which summed up my desired outcome. You just need to add this as the command for your container to generate additional cores:

bash -e -c "precreate-core collection1; precreate-core collection2; solr-foreground"

This ensures collection1 and collection2 and could create however many are needed. 

To add Solr to your DDEV with multiple cores, here is the docker-composer.solr.yaml you can add to your project

version: '3.6'

services:
  solr:
    container_name: ddev-${DDEV_SITENAME}-solr
    image: solr:6.6
    command: 'bash -e -c "precreate-core collection1; precreate-core collection2; solr-foreground"'
    restart: "no"
    ports:
      - 8983
    labels:
      com.ddev.site-name: ${DDEV_SITENAME}
      com.ddev.approot: $DDEV_APPROOT
      com.ddev.app-url: $DDEV_URL
    environment:
      - VIRTUAL_HOST=$DDEV_HOSTNAME
      - HTTP_EXPOSE=8983
    volumes:
      - "./solr:/solr-conf"
  web:
    links:
      - solr:$DDEV_HOSTNAME
      # Platform.sh hostname alias
      - solr:solr.internal

Sep 21 2018
Sep 21

When I was at Drupal Europe 2018, I had the opportunity to see the new Drupal core profile Umami being demonstrated. Umami is available in Drupal core since version 8.6 and it aims at demonstrating Drupal’s features.

Umami is an installation profile that shows anyone who is considering using Drupal (so called “evaluators”) what it can do out of the box.

It provides the content (recipes), configuration and the theme (including all resources like javascript, css, images and fonts) for a fictional Food magazine called “Umami”.

Umami Drupal profile screenshot

Umami has been developed by several members of the Drupal community over the last one and a half years and the result is quite impressive. It makes a huge difference from the out of the box experiences that we have become accustomed to in the past. We were used to be presented an empty screen in the layout of default themes Bartik, Garland or even Bluemarine.

It is important to note that Umami only uses Drupal core. So that means that no contributed modules (not even Paragraphs!!), no custom code and no experimental core modules (like the Layout builder) are included.

Besides that restriction, there were many other challenges such as the licensing of web fonts and whether to use British or American standards and wording in the recipes. This makes the end result even more impressive.

Umami is really meant as a demonstration and cannot be used as a starter kit for new sites. Future updates will not guarantee any backwards compatibility.

As soon as they are stable features of Drupal core will be expanded with, among others:

  • media library for easy organizing and adding images, videos and such;
  • layout builder for easy adding block content to a page;
  • content migration for importing the demo content. This feature depends on a CSV migration plugin to become available in core;

The developers did a great job in providing Drupal core for the first time in its history with tasty demo content out of the box!

Sep 21 2018
Sep 21

The Drupal Association is 4 years into our initiative to diversify revenue streams to make the Association more sustainable and less reliant on DrupalCon to fund all of our programs.  Monetization on Drupal.org itself is an important revenue stream that helps fund various Drupal.org initiatives and improvements

We’ve focused much of our effort creating new content that both serves new audiences and provides revenue opportunities, however, we’re still only monetizing roughly 20% of our total site traffic.  When we began, we outlined a few important guidelines for our efforts, including:

  • When possible, only monetize users who are logged out and not contributing to the Project.
  • Address the industry-wide shift to Programmatic Advertising, which is the automated buying and selling of digital advertising.

We’re piloting a new ad program to help us better achieve our monetization goals, while still respecting those users who actively contribute to the project.  We want to experiment with more traditional, high visibility banner ads that you typically see on other websites, such as 970 x 90 Leaderboard ads.  We also want to better leverage 3rd party ad networks and exchanges.  These new advertising placements will automatically check for two things before they display:  1) is the user an active contributor(based on contribution credits) and/or 2) is the user a Drupal Association Member.  If either of those are true, the ad won’t display.

New Ad Network Partner:  Carbon Ads
In addition to the pilot program above, we are also piloting a relationship with a new ad network sponsor, that is tailored to the audiences we serve. When we first launched advertising on Drupal.org, the community asked that ads remain relevant to the Drupal ecosystem. We agree that this is important, however, this makes it extremely difficult to leverage 3rd party ad exchanges like Google. While they offer category filters, it’s impossible to guarantee that every ad served will be relevant to Drupal.

Vertical-focused ad networks exist, although they’re becoming less common. We’re excited to announce that we’ve recently started working with Carbon Ads, a closed ad exchange that limits its advertisers to tech and developer focused advertising. They have a sales team of about 12 people working directly with companies like Microsoft, Slack, and Digital Ocean, and an advertising operations team that manages and uploads all ad creative themselves. This removes a lot of the risk that other self-serving ad platforms pose.

Why we love Carbon Ads:

  • They are a closed ad network (there’s far less risk of malicious, offensive, or unrelated ad content appearing on Drupal.org).
  • They are GDPR compliant.
  • They don’t track site visitors with cookies, nor collect their personal data for ad targeting. You can learn more about their data policy here.   The most sensitive data they collect is the IP address which they use to decide whether to show ads in a specific regions.  Furthermore, none of the data collected are stored permanently.
  • They come highly recommended from partner sites like Vue.js, Laravel, and Bootstrap.

It’s important that we fund Drupal.org improvements, and that we do so in a responsible way that respects the community. Thanks for taking the time to read about our initiatives, and please tell us your thoughts! 

We will be listening, identifying common themes and responding to feedback in about a week.
 

Sep 21 2018
Sep 21

The BADCamp Circus is coming to town for 4 whole days! From cities near and far, Drupalists are converging in Berkeley very soon for this year’s circus-themed BADCamp!

Join Hook 42 under the bigtop for 3 unique sessions. We’ll be sharing our thoughts on redesigning the Stanford Cantor Arts Center website, accessibility tooling, and creating custom Drupal 8 modules. Of course, the whole team will be there too, collaborating with new and old friends alike.

Join us as we flex our Drupal muscles, perform daring acts of development, and add to the general merriment of the Drupal community. BADCamp 2018 is sure to not disappoint!

Sessions:

Drupal 8 Case Study – Stanford Cantor Arts Center Redesign

Ryan Bateman and Kristen Pol | Friday, October 26, 2:30 - 3:15 PM | Sibley

In the Spring of 2017, Stanford’s Cantor Arts Center came to Hook 42 with a project to redesign their aging website with a shiny new Drupal 8 website that would allow the museum’s exemplary visual arts exhibits and photographic assets take center stage. What followed was a development cycle full of rigorous content strategy, front-end design, and back-end development that culminated in the newly-launched Cantor Arts Center website.

This session will expand upon our methodology and thought process in arriving at each aspect of the site’s development, including:

Intended Audience:

Anyone interested in content strategy, migrations, and flexible components will benefit from this session.

Which Accessibility Tools Are Right For You?

Aimee Degnan | Saturday, October 26, 11:15 AM-12:00 PM | Tilden

As an organization who needs to step up their accessibility (a11y) compliance, accessibility testing and remediation is a big deal.

Accessibility testing has a lot of moving parts! There are so many tools. So many! Plugins, suites, crawlers, dashboards, CI tests, and more.

  • Which one is right for you?
  • Will only one fit all of your needs? ;)
  • Build vs. buy some vs. buy vs. free? Is "free" free?

This is not a session about "what tools did our team use". This is a broader overview of the a11y testing tool types, challenges and benefits of the different types, rough costs (when applicable), and the best use cases for them.

When searching for tools, you can find lists of tools, but not comprehensive comparisons of tools to make the decision of which one(s) to use and buy for your need.

We compared a vast amount of tools to analyze and choose the best for our need as a digital agency specializing in accessible design and development and for our clients' needs as public entities requiring multiple levels of compliance.

A developer's tool needs (and budget) may be much different than a larger organizations need for multi-site dashboards and reporting experiences.

All levels of experience can get value out of this session.

Target audiences:

  • Tool procurement teams 
  • Developers (get a list of tools for a11y testing)
  • Website "Owners" / Stakeholders responsible for compliance
  • Project Managers
  • Dev Team Managers

Drupal 8 Custom Module Architecture: What’s Going On?

Lindsay Gaudinier | Friday, October 26, 4:45 PM-5:30 PM | Sibley

It is all fun and games modifying existing code, but what about when you have to venture out to unknown waters and create your own custom module? Don’t worry! We can get through this together!

This talk is a deep dive into creating custom modules from scratch, and the role of each component in the final product.

Let’s consider when it is appropriate to leverage custom development, explore the anatomy of a custom module, the types of expected files in a custom module, and the wonderful world of what you can do with a custom module (spoiler - it is a lot!).

This talk will include: Composer uses, forms, theming within a module, custom pages, Drupal namespacing, object oriented conventions, plugins, controllers, routes and more!

Web Accessibility 101 Training - This training course is a crash-course in web accessibility concepts targeted towards both content managers and developers working in Drupal tasked to create an "accessible website".

Navigating the Issue Queue - A beginner's guide to contribution (half day training) - Most Drupalers dream of being a contributor to the Drupal project. But where do you begin? And more importantly, what are some of the tools to help navigate the adventure successfully?

We look forward to seeing you all there!

Stop by our booth in the expo hall to say hi and pick up some newly-designed stickers!

Sep 21 2018
Sep 21

I spent last week hanging out with over 1000 Drupalers at Drupal Europe, the biggest Drupal event of the year in Europe. It was held in Darmstadt, Germany and brought Drupal users of all sorts from all over the world. Most attendees were from Europe, but many travelled from Asia, North America, and as far away as Australia to attend.

What Was Special About Drupal Europe?

Drupal Europe was basically a community-organized DrupalCon. It was a large event that had most of the features that you would associate with a DrupalCon from the professional venue to the DriesNote to the hundreds of valuable sessions to Trivia Night and the large contribution sprint on Friday.

Watching the 12 core organizers and countless other volunteers step up and organize this event was an inspiration. The volunteers are community members and they brought so many great ideas to the event that made the event excellent. Here are some of the things that I loved about the conference:

BoFs (small break-out sessions that are conversations between attendees rather than speaker-led) were incorporated into the main calendar of events making them highly visible. This made it easy to see which ones were going on. This meant that BoFs were popular and all that I attended seemed highly productive.

There were also lots of opportunities to contribute throughout the conference, and reduced-price contributor tickets were available for people who just wanted to work on the project and not attend sessions.

Diversity tickets were available. I haven’t seen the data, but it seemed like a more geographically and gender diverse conference than other Drupal events I’ve attended in Europe. 

The Splash Awards that kicked off the Tuesday of the event and highlighted great Drupal work being done. I think this is a great way to integrate more success stories and customers into the community.

The overall conference venue from the way the space and sponsor booths were laid out to the food were all very conducive to networking opportunities. There were lots of different spaces to chat, hang out, talk to sponsors, drink coffee, and contribute. The signage kept everything on track and allowed real-time updates to the schedule as needed (thanks Gabor Hojtsy!)

Updates from the Dries Note

If you didn’t attend the event, I recommend watching the DriesNote to get an update on what’s happening with the Drupal project and the community as a whole. Dries talked about the roadmap for Drupal. He touched on recent work on improving the evaluator experience, the work being done on the admin UI, and updates to drupal.org.
 

Image from the DriesNote slidedeck

Drupal User Experience Study

I spent some of the week co-ordinating efforts around the Drupal UX Study that I’ve been working on. I got to meet with Cristina Chumulls and new contributors. We worked on the wireframes for the new Admin UI. The work we’re doing was promoted at the DriesNote, so watch from here to find out more.

If you want to get involved in helping us do user testing to improve the Drupal Admin UI, find us on the Admin UI channel on the Drupal Slack.

Image of the Contribute sign from the Friday

Working Together to Market Drupal!

I also spent a lot of my week talking to folks from different parts of the community about how we can work together to better promote Drupal. This resulted in three separate community efforts: creating a starter kit to help local associations promote Drupal, hiring a marketing manager to create materials for local communities, and a marketing pitch deck for the Drupal project as a whole.
Get in touch with me on the #marketing channel on the Drupal Slack if you want to get involved in these efforts and I’ll connect you to the right person! (my username is pixelite).

Image of the marketing Drupal BOF

Where’s All the Drupal Talent?

Many Drupal agencies face challenges recruiting new talent. When we talk about marketing Drupal, the need to bring new people into the community always comes up. At Drupal Europe, I participated in a panel about how to recruit Drupal talent organized by Josef Dabernig. I talked about our efforts to Axcelerant. I also learned a lot about how other Drupal teams are organized and innovative programs for on-boarding junior developers.

Drupal Association

This was the first big Drupal event that I attended as a member of the board of the Drupal Association. I attended a board retreat the two days before Drupal Europe and got up-to-speed on what the Board is working on. I took advantage of the conference to connect with people in the community who are interested in the Promote Drupal initiative and other efforts of the association. I also sat on a panel about the past, present, and future of the Drupal Association and collected the feedback from audience members who were asking questions about the role of the association going forward.

I’m excited to get started on the board and I’ll post more updates as my involvement advances.

Image of meeting

Watch more here!

#DrupalThanks
Again, huge thanks to the volunteer organizers of the event! 

Drupal Thanks

Sep 21 2018
Sep 21

This year I’ve been working on a fun new Drupal-based event management application for libraries. During the course of development, I’ve become convinced that–beyond caching and naming things–the third level of Computer Science Hell is reserved for time zone handling. Displaying and parsing time zones proved to be a fruitful source of unforeseen issues and difficult to diagnose bugs.

The application we’ve been working on uses a progressively decoupled architecture, meaning interfaces that demand greater interactivity are self-contained client-side applications mounted within the context of a larger server-rendered Drupal site. This allows us to focus our efforts, time and budget on specific key interfaces, while taking advantage of Drupal’s extensive ecosystem to quickly build out a broader featureset.

Some examples of where time zone bugs reared their nasty heads:

  1. In certain cases, events rendered server-side displayed different date times than the same event rendered client-side.
  2. In a filterable list of events, time based-filters, such as “Show events between September 6th and 9th.”
  3. A user’s list of upcoming events would sometimes not include events starting within the next hour or two.
  4. Two logged in users could see a different time for the same event.

Let’s talk about that last one, as it’s a fairly common Drupal issue and key to understanding how to prevent the former examples.

User’s Preferred Time Zone

Drupal handles time zone display at the user level. When creating or editing their account, a user can specify their preferred time zone.

All users have a preferred time zone–even the logged-out anonymous user. A Drupal site is configured with a default time zone upon creation. This default time zone serves as the preferred time zone of all anonymous users. It also serves as the default preferred time zone for any new user account as it’s created.

When date values are rendered, the user’s preferred time zone is taken into account. Let’s say you have Drupal site with a default time zone set to America/New_York. If you have an event set to start at 4pm EST, all anonymous users–since they’re preferred time zone matches the site default–will see the event starts at 4pm.

However, a user with a preferred time zone of America/Phoenix will see that same event’s time as either 2pm or 1pm – literally depending on how the planets have aligned – thanks to the user’s time zone preference and Arizona’s respectable disregard for daylight savings time.

So the first thing you need to understand to prevent time zone bugs is users can set their preferred time zone.

Dates are Stored in UTC

One thing Drupal does really well is store dates in Coordinated Universal Time or UTC – I’m not sure that’s how acronyms work – but whatever. UTC is a standard, not a time zone. Time zones are relative to UTC. Dates are stored in the database as either Unix timestamps or ISO-8601 formatted strings. In either case they are set and stored in UTC.

Likewise, Javascript date objects are stored internally as UTC date strings. This allows dates to be compared and queried consistently.

The Disconnect

We now know Drupal and JS both store dates internally in a consistent UTC format. However JS dates, by default, are displayed in the user’s local time zone – the time zone set in their computer’s OS. Drupal on the other hand, displays dates in your user account’s preferred time zone. These two won’t always match up.

If the browser and Drupal think you are in two different time zones, dates rendered on the server and client could be off by any number of hours.

For example, you may be in Denver and have America/Denver set as your preferred time zone, but if you’re logged out and Drupal has a default time zone set to America/New York, server rendered times will display 2 hours ahead of client rendered times.

In another scenario, you may live in the same time zone configured as Drupal’s default and don’t have have a preferred time zone set. Everything looks fine until you travel a couple time zones away, and now all the client rendered dates are off.

This is the root cause of the bugs in the first three examples above.

The browser couldn’t care less what preferred time zone you have set in Drupal. It only knows local time and UTC time. Unlike PHP, JS currently does not have native functions for explicitly setting the time zone on a Date object.

Keeping Client- and Server-Rendered Dates in Sync

Now we know Drupal and the browser store dates in UTC. This is good. To make our lives easier, we’ll want to keep our client side dates in UTC as much as possible so that when we query the server with date-based filters, we get proper comparisons of dates greater than or equal to.

But we need to ensure our client-rendered dates match our server-rendered dates when they are displayed on the page. We also need to ensure dates entered via form fields are parsed properly so they match the user’s preferred time zone. There’s two things we need to do.

  1. Let the client know the user’s preferred time zone.
  2. Parse and display client-side dates using this time zone.

Passing the User’s Preferred time zone To do this, we’ll attach the preferred time zone via drupalSettings. This can be done via HOOK_page_attachments() in a .module file. If you don’t know how to create a custom module, there are plenty of resources online.

/**
 * Implements hook_page_attachments.
 */
function my_module_page_attachments(array &$attachments) {
  // Add user time zone to drupalSettings.
  $user_time zone = new \Datetime zone(drupal_get_user_time zone());
  $attachments['#attached']['drupalSettings']['my_module']['user'] = [
    'time zone' => drupal_get_user_time zone(),
  ];
  // Cache this per user.
  $attachments['#cache']['contexts'][] = 'user';
  // Clear the cache when the users is updated.
  $attachments['#cache']['tags'][] = 'user:' . $current_user->id();
}

With this, we can now access the user’s preferred time zone in the browser from the drupalSettings global, like so:

const userTimeZone = drupalSettings.my_module.user.time zone;
// Ex: ‘America/Denver’

Displaying, Parsing and Manipulating Dates in the User’s Time Zone

Now that we know the users preferred time zone client side, we can ensure any dates that are displayed and parsed, for example – from an input, are taking into account the correct time zone.

Currently there isn’t good native support for this in browsers. We have to either write our own functionality or use a third party date library. I typically use Moment.js for this. Moment has been around for a while and, as far as I know, has the best time zone handling.

To use Moment’s time zone handling, you’ll need to load the library with time zone support and the most recent time zone dataset. The dataset is required to map time zone names to the appropriate UTC offset – taking into account Daylight Saving Time at the appropriate time of year.

For all the following examples, we’ll assume you’ve loaded the time zone version of Moment with data bundled together as a browser global. There’s a number of other ways to import Moment via npm if you prefer to use it as a module.

<script src="https://momentjs.com/downloads/moment-time zone-with-data-2012-2022.min.js"></script>

Setting a Time Zone on Dates

To begin with, we need to tell Moment what time zone we are dealing with. We’ll also assume userTimeZone has been set to the string value from drupalSettings above.

// Create a date for now in the user’s time zone
const date = moment().tz(userTimeZone);

Just like Drupal and native JS Date objects, Moment stores the underlying date in UTC. The time zone plugin merely allows us to include a reference to a specific time zone which will be taken into account when manipulating the date with certain methods and formatting the date as a string.

const date = moment('2018-09-13 12:25:00');
date.unix();
// 1536863100
date.format('HH:mm')
// ‘12:25’
date.tz('America/New_York')
// "14:25"
date.unix()
// 1536863100

In this case, we are simply using Moment to display a date in a specific time zone. The underlying UTC date never changes.

Manipulating a Date

Whereas the format() method in Moment simply outputs a string representing a date, other methods manipulate the underlying date object. It’s important to take time zone into consideration when manipulating a date with certain operations to ensure the resulting UTC date is correct.

For example, Moment has a handy startOf() method that lets you set the date to, for example, the start of the day.

We instinctively think of the start of day as being 12:00 AM. But 12:00 AM in Denver is a different UTC time than 12:00 AM in New York. Therefore, it’s important to ensure our Moment object is set to the desired time zone before manipulating it. Otherwise we will get different results depending on the time of day and local time zone in which the method was executed.

Parsing a Date

In some cases, we need to parse a date. For instance, to correctly convert a Date Time field from Drupal into a JS Date object, we need to ensure it’s parsed into the right time zone. This is pretty straightforward as the date output from Drupal is in UTC. However, the client doesn’t know that. We can simply append the Z designator to indicate this date in UTC.

moment(`${someDateValue}Z`);

I typically wrap this in a function for easy reuse:

export const dateFromDrupal = date => moment(`${date}Z`).toDate();

And going the reverse direction:

export const dateToDrupal = date => date.toISOString().replace('.000Z', '');

Another use case for parsing dates is when handling user input. For example, if you have a filtering interface in which you need to show events on a given day. The user needs to enter a date. The HTML date input uses a simple string representation of a day, such as 2018-09-15 – in the user’s local time zone.

Now, if we want to take this input and query Drupal for events with a start time between the start and end of this day, we’ll need to convert this string value into a UTC date. We’ll need to do so by parsing this date in the user’s time zone, otherwise we might not get accurate results. In fact, they could be as much as a day off from what we’re expecting.

function changeEventHandler(event) {
  if (event.target.value) {
    const inputDate = moment.tz(event.target.value, userTimeZone);
    const startValue = inputDate.startOf(‘day’);
    const endValue = inputDate.endOf(‘day’);
    // Do something with the start and end date.
  }
}

Date and time zone handling is one thing you should not take for granted when considering decoupling a Drupal application. Having a good understanding of how dates are stored and manipulated will help you identify, diagnose and avoid date related bugs.

Keep these things in mind throughout the development process and you should be fine:

  1. Store your dates and pass them around in UTC. This will help keep things consistent and reduce any time zone related bugs.
  2. Take time zone into account when dealing with user input and output. Time zones are relative to the user, so keeping those operations as close to the user interface as possible should keep the internals of the application simple.
  3. When considering any open source modules that deal with dates, such as React components or date handling libraries, make sure they allow for proper time zone handling. This will save you some headaches down the road.
  4. Test your application using different user time zones in Drupal and by manually overriding your time zone on your local machine. Sometimes bugs are not apparent until you are on a drastically different time zone than the server.

Good luck!

Sep 21 2018
Sep 21

This year I’ve been working on a fun new Drupal-based event management application for libraries. During the course of development, I’ve become convinced that–beyond caching and naming things–the third level of Computer Science Hell is reserved for time zone handling. Displaying and parsing time zones proved to be a fruitful source of unforeseen issues and difficult to diagnose bugs.

The application we’ve been working on uses a progressively decoupled architecture, meaning interfaces that demand greater interactivity are self-contained client-side applications mounted within the context of a larger server-rendered Drupal site. This allows us to focus our efforts, time and budget on specific key interfaces, while taking advantage of Drupal’s extensive ecosystem to quickly build out a broader featureset.

Some examples of where time zone bugs reared their nasty heads:

  1. In certain cases, events rendered server-side displayed different date times than the same event rendered client-side.
  2. In a filterable list of events, time based-filters, such as “Show events between September 6th and 9th.”
  3. A user’s list of upcoming events would sometimes not include events starting within the next hour or two.
  4. Two logged in users could see a different time for the same event.

Let’s talk about that last one, as it’s a fairly common Drupal issue and key to understanding how to prevent the former examples.

User’s Preferred Time Zone

Drupal handles time zone display at the user level. When creating or editing their account, a user can specify their preferred time zone.

All users have a preferred time zone–even the logged-out anonymous user. A Drupal site is configured with a default time zone upon creation. This default time zone serves as the preferred time zone of all anonymous users. It also serves as the default preferred time zone for any new user account as it’s created.

When date values are rendered, the user’s preferred time zone is taken into account. Let’s say you have Drupal site with a default time zone set to America/New_York. If you have an event set to start at 4pm EST, all anonymous users–since they’re preferred time zone matches the site default–will see the event starts at 4pm.

However, a user with a preferred time zone of America/Phoenix will see that same event’s time as either 2pm or 1pm – literally depending on how the planets have aligned – thanks to the user’s time zone preference and Arizona’s respectable disregard for daylight savings time.

So the first thing you need to understand to prevent time zone bugs is users can set their preferred time zone.

Dates are Stored in UTC

One thing Drupal does really well is store dates in Coordinated Universal Time or UTC – I’m not sure that’s how acronyms work – but whatever. UTC is a standard, not a time zone. Time zones are relative to UTC. Dates are stored in the database as either Unix timestamps or ISO-8601 formatted strings. In either case they are set and stored in UTC.

Likewise, Javascript date objects are stored internally as UTC date strings. This allows dates to be compared and queried consistently.

The Disconnect

We now know Drupal and JS both store dates internally in a consistent UTC format. However JS dates, by default, are displayed in the user’s local time zone – the time zone set in their computer’s OS. Drupal on the other hand, displays dates in your user account’s preferred time zone. These two won’t always match up.

If the browser and Drupal think you are in two different time zones, dates rendered on the server and client could be off by any number of hours.

For example, you may be in Denver and have America/Denver set as your preferred time zone, but if you’re logged out and Drupal has a default time zone set to America/New York, server rendered times will display 2 hours ahead of client rendered times.

In another scenario, you may live in the same time zone configured as Drupal’s default and don’t have have a preferred time zone set. Everything looks fine until you travel a couple time zones away, and now all the client rendered dates are off.

This is the root cause of the bugs in the first three examples above.

The browser couldn’t care less what preferred time zone you have set in Drupal. It only knows local time and UTC time. Unlike PHP, JS currently does not have native functions for explicitly setting the time zone on a Date object.

Keeping Client- and Server-Rendered Dates in Sync

Now we know Drupal and the browser store dates in UTC. This is good. To make our lives easier, we’ll want to keep our client side dates in UTC as much as possible so that when we query the server with date-based filters, we get proper comparisons of dates greater than or equal to.

But we need to ensure our client-rendered dates match our server-rendered dates when they are displayed on the page. We also need to ensure dates entered via form fields are parsed properly so they match the user’s preferred time zone. There’s two things we need to do.

  1. Let the client know the user’s preferred time zone.
  2. Parse and display client-side dates using this time zone.

Passing the User’s Preferred time zone To do this, we’ll attach the preferred time zone via drupalSettings. This can be done via HOOK_page_attachments() in a .module file. If you don’t know how to create a custom module, there are plenty of resources online.

/**
 * Implements hook_page_attachments.
 */
function my_module_page_attachments(array &$attachments) {
  // Add user time zone to drupalSettings.
  $user_time zone = new \Datetime zone(drupal_get_user_time zone());
  $attachments['#attached']['drupalSettings']['my_module']['user'] = [
    'time zone' => drupal_get_user_time zone(),
  ];
  // Cache this per user.
  $attachments['#cache']['contexts'][] = 'user';
  // Clear the cache when the users is updated.
  $attachments['#cache']['tags'][] = 'user:' . $current_user->id();
}

With this, we can now access the user’s preferred time zone in the browser from the drupalSettings global, like so:

const userTimeZone = drupalSettings.my_module.user.time zone;
// Ex: ‘America/Denver’

Displaying, Parsing and Manipulating Dates in the User’s Time Zone

Now that we know the users preferred time zone client side, we can ensure any dates that are displayed and parsed, for example – from an input, are taking into account the correct time zone.

Currently there isn’t good native support for this in browsers. We have to either write our own functionality or use a third party date library. I typically use Moment.js for this. Moment has been around for a while and, as far as I know, has the best time zone handling.

To use Moment’s time zone handling, you’ll need to load the library with time zone support and the most recent time zone dataset. The dataset is required to map time zone names to the appropriate UTC offset – taking into account Daylight Saving Time at the appropriate time of year.

For all the following examples, we’ll assume you’ve loaded the time zone version of Moment with data bundled together as a browser global. There’s a number of other ways to import Moment via npm if you prefer to use it as a module.

<script src="https://momentjs.com/downloads/moment-time zone-with-data-2012-2022.min.js"></script>

Setting a Time Zone on Dates

To begin with, we need to tell Moment what time zone we are dealing with. We’ll also assume userTimeZone has been set to the string value from drupalSettings above.

// Create a date for now in the user’s time zone
const date = moment().tz(userTimeZone);

Just like Drupal and native JS Date objects, Moment stores the underlying date in UTC. The time zone plugin merely allows us to include a reference to a specific time zone which will be taken into account when manipulating the date with certain methods and formatting the date as a string.

const date = moment('2018-09-13 12:25:00');
date.unix();
// 1536863100
date.format('HH:mm')
// ‘12:25’
date.tz('America/New_York')
// "14:25"
date.unix()
// 1536863100

In this case, we are simply using Moment to display a date in a specific time zone. The underlying UTC date never changes.

Manipulating a Date

Whereas the format() method in Moment simply outputs a string representing a date, other methods manipulate the underlying date object. It’s important to take time zone into consideration when manipulating a date with certain operations to ensure the resulting UTC date is correct.

For example, Moment has a handy startOf() method that lets you set the date to, for example, the start of the day.

We instinctively think of the start of day as being 12:00 AM. But 12:00 AM in Denver is a different UTC time than 12:00 AM in New York. Therefore, it’s important to ensure our Moment object is set to the desired time zone before manipulating it. Otherwise we will get different results depending on the time of day and local time zone in which the method was executed.

Parsing a Date

In some cases, we need to parse a date. For instance, to correctly convert a Date Time field from Drupal into a JS Date object, we need to ensure it’s parsed into the right time zone. This is pretty straightforward as the date output from Drupal is in UTC. However, the client doesn’t know that. We can simply append the Z designator to indicate this date in UTC.

moment(`${someDateValue}Z`);

I typically wrap this in a function for easy reuse:

export const dateFromDrupal = date => moment(`${date}Z`).toDate();

And going the reverse direction:

export const dateToDrupal = date => date.toISOString().replace('.000Z', '');

Another use case for parsing dates is when handling user input. For example, if you have a filtering interface in which you need to show events on a given day. The user needs to enter a date. The HTML date input uses a simple string representation of a day, such as 2018-09-15 – in the user’s local time zone.

Now, if we want to take this input and query Drupal for events with a start time between the start and end of this day, we’ll need to convert this string value into a UTC date. We’ll need to do so by parsing this date in the user’s time zone, otherwise we might not get accurate results. In fact, they could be as much as a day off from what we’re expecting.

function changeEventHandler(event) {
  if (event.target.value) {
    const inputDate = moment.tz(event.target.value, userTimeZone);
    const startValue = inputDate.startOf(‘day’);
    const endValue = inputDate.endOf(‘day’);
    // Do something with the start and end date.
  }
}

Date and time zone handling is one thing you should not take for granted when considering decoupling a Drupal application. Having a good understanding of how dates are stored and manipulated will help you identify, diagnose and avoid date related bugs.

Keep these things in mind throughout the development process and you should be fine:

  1. Store your dates and pass them around in UTC. This will help keep things consistent and reduce any time zone related bugs.
  2. Take time zone into account when dealing with user input and output. Time zones are relative to the user, so keeping those operations as close to the user interface as possible should keep the internals of the application simple.
  3. When considering any open source modules that deal with dates, such as React components or date handling libraries, make sure they allow for proper time zone handling. This will save you some headaches down the road.
  4. Test your application using different user time zones in Drupal and by manually overriding your time zone on your local machine. Sometimes bugs are not apparent until you are on a drastically different time zone than the server.

Good luck!

Sep 21 2018
Sep 21

A game of soccer is not shorn of any fanfare among the soccer lovers when the so-called English Premier League brings together the greatest players in the same team. And when two legendary players of different nations play together for the same franchise, fans often find it an arduous task to pick the champion of the champions. Choosing the best CMS for your business between Drupal and Sitecore puts you in a similar junction.

Illustration showing a task sheet and icons representing pencil and loudspeaker


Drupal and Sitecore are the leading CMSs in the market and that reflects in the Gartner Magic Quadrant for Web Content Management 2018. Apparently, both are amazing as the content store for websites and that puts digital businesses in a dilemma to choose best of the best breed. Here, we have put several parameters in place and did a side-by-side comparison. Let’s see who comes on top.

A Brief Exploration of Drupal and Sitecore

Before we dive into the comparison part, let’s quickly define the two content management systems.

Drupal

Logo of Drupal with a drop-shaped icon

An open-source CMS, Drupal is absolutely free to use which is maintained by a community of volunteers and sponsored contributors across the globe.

It comes with various modules and integrations out-of-the-box. It is powering some of the world’s biggest and most intricate websites and is a praiseworthy choice for firms that need a solution offering impeccable and complex integrations.

No wonder, it is on the upward direction in the usage statistics as can be witnessed in the graphical representation below.

Graphical representation of Drupal usage statistics with different coloured linesDrupal Usage Statistics from BuiltWith

Sitecore

Logo of sitecore with an circle-shaped red-coloured icon

Sitecore, a closed-source or a proprietary CMS, provides some amazing marketing automation tools out-of-the-box.

It is a good contender for enterprises that are considerate about content personalisation, journey orchestration, and marketing.

Like Drupal, it is perpetually rowing upstream despite heavy competition in the CMS market and has made a mark for itself as can be seen in the graph below.

Graphical representation showing usage statistics of Sitecore with different coloured linesSitecore usage statistics from BuiltWith

While both the CMSs are continuously proving to be quintessential when it comes to their respective growth and business adoption over the years, market share shows a different picture. Market share, with a bulk of the share in the pockets of Wordpress, has a strong contender in Drupal. W3Techs statistics delineates that Drupal leads the market share as compared to Sitecore.

Infographics showing percentage of market share with the help of horizontal bars

Comparing Drupal vs Sitecore in Different Perspectives

Doing a side-by-side comparison of Drupal and Sitecore on different metrics would portray a better picture of who wins the battle when to comes to being the best of the best.

Features and Functionalities

Metrics

Drupal

Sitecore

Content Management

Excellent content management

Excellent content management

Security

Highly secure

Highly secure

Decoupled and headless approach

Decoupled presentation layer available

Decoupled presentation layer available

Performance and Scalability

With a smaller footprint, it is more scalable and offers high performance

With larger footprint, it is relatively low on scalability and performance metrics

Multilingual site

Great support for multilingual sites

Great support for multilingual sites

Accessibility

Better features for web accessibility

Relatively less features for web accessibility

Multisite

Multisite functionality available

Multisite functionality available

Responsive web design

Fully responsive

Fully responsive

1. Content Management

Drupal has a much more customisable backend as compared to Sitecore. The default Drupal content administration view is stupendous. It can be further customised for optimising the content editors’ user experience.

Drupal allows the implementation of custom workflows for the content teams thereby ensuring that governance standards are met. It makes sure that all the content is posted and approved as per the norms of the organisations’ existing content practices.

For instance, with the release of Drupal 8.6, Workspaces module, an experimental module, has been included. So, when a large package of content, let’s say hundreds or thousands of items, have to be assessed and deployed at once, Workspaces module offers intuitive UI to do so.

Drupal 8.6 workspaces module in action with cursor moving in different directionsWorkspaces module in action

On the contrary, while Sitecore's current backend is tremendously functional, the user experience leaves quite a bit to be desired. Sitecore Director of User Experience, Niels Handberg, showcased the Future of Sitecore Content Management User Experience at the Sitecore Symposium 2017.

A man standing on a stage with a vacant chair placed in the cornerSource: Delete Agency

Upcoming editions of Sitecore such as Sitecore 9.1 will have hugely improved content authoring experiences and content management tools. It will have options for advanced workflows in specific areas or content types on the site. It will allow users to configure systems for approvals, notifications, and translations on multiple content items.

Inference: Drupal and Sitecore have been truly consistent with their approach of providing an excellent content management to the users and have been continuing to inculcate more improvements.

2. Security

An extensively researched whitepaper by the University of Washington titled “Is Open Source Software More Secure?” signifies the high-level security that open source software offer. It states that open source does not pose any significant roadblocks to security but rather reinforces best security practices by involving many people who can expose bugs swiftly.

Drupal offers fine-grained access over what content can be created, modified, updated and deleted and by whom. Although, as an open source CMS, it is a highly integrated system, it is also immensely security-focussed CMS. Drupal allows you to build securely integrated platform and has a suite of security modules to choose from.

Dedicated Security Team of Drupal is committed to address security vulnerabilities and build patches to ensure top-of-the-line safety.

Moreover, adhering to Drupal’s coding standards also helps keep security risks at bay.

In the 2017 Cloud Security Report by Alert Logic, Drupal was reported for the least number of web application attacks.

Tabular column showing security attacks in different CMSsSource: Alert Logic

Sucuri’s Hacked Website Report also showed that Drupal was the better performing CMS in terms of security as compared to leading CMSs like Wordpress, Joomla, and Magento.

graphical representation showing statistics on infected websitesSource: Sucuri

Sitecore enables you to create users and user roles with fine-grained access to any part of the site an administrator chooses.

It is built on .Net which means that whenever a .Net patch is released, all Sitecore sites will be updated automatically without any user intervention. And since Sitecore sites are designed to minimally integrate with other systems, the risk of outside security flaw creeping into the site gets reduced.

It offers extensive documentation on safeguarding one’s environment. Clients would have to coordinate with vendors in order to make sure that security patches are installed instantly.

Inference: Both Drupal and Sitecore are highly secure platforms.

3. Decoupled and Headless Approach

Decoupled Drupal offers multi-platform capabilities, awesome frontend experience, and marketing agility. So, a large enterprise with a presence of an awful lot of digital properties to govern benefits a lot with Decoupled Drupal’s Create Once Publish Everywhere approach.

Flowchart showing the different between Coupled and Decoupled DrupalSource: Acquia

Sitecore, with its decoupled approach, can automatically serve content in the format that is best-sized and suited for a user’s device. Sitecore originated as a headless CMS. But it has never marketed itself as headless as it has always separated content from the presentation and thought of headless as a commodity.

Inference: Both the CMSs can be a superb choice as the decoupled or headless CMS.

4. Performance and Scalability

The Drupal effect on high-performance websites is huge and can be very meritorious.

  • Drupal modules like BigPipe and Redis helps in the advanced cache optimisation.
  • Memcache API and Integration module help in the database optimisation.
  • Advanced CSS/JS Aggregation module keeps a tab on your front-end performance.
  • Blazy module provides the functionalities of lazy loading
  • Fast 404 module handles 404 errors on websites.
  • CDN module helps in the integration of Content Delivery Network for Drupal websites.

Also, Drupal scales with your needs to help sites cope with a colossal amount of traffic. High-traffic websites like The Grammy Awards, NBC Olympics, Time Inc., NASA and many more are efficiently handling spikes in web traffic. Drupal can manage a voluminous amount of visitors, content and Drupal users.

Sitecore encounters a challenge in order to attain high performance and scalability but its recent large-scale deployments have shown that it can be addressed. With a large footprint, it requires a large hosting infrastructure to manage it.

Illustration showing server configuration setup in sitecore with relevant icons

For attaining high scalability, Sitecore’s documentation recommends that separate servers can be assigned for individual tasks like content delivery, reporting, processing/aggregation and more.

The Forrester Wave: Web Content Management Systems, Q1 2017 report states that while Sitecore Experience Accelerator (SXA) may ease off operational pains but large feature set add intricacy to operations.

Inference: Drupal has a clear edge over Sitecore in terms of website performance and scalability.

5. Multilingual Site

Drupal’s out-of-the-box language handling abilities deliver value to the firms who need localised digital experiences thus saving time and money in the process. Building multilingual sites is faster and easier with Drupal with the support for natively installing 90+ languages.

Four core modules in Drupal for language handling, interface translation, content translation, and configuration translation allow full translation of every part of a site. You can swiftly develop a customised site in any language. Or, you can build an intricate multilingual web application with dynamic, language-based displays using various admin languages and translation workflows.

Drupal installation showing different language options


Sitecore XM natively governs the multilingual content and the translation workflow. It also integrates with translation services thereby enabling content creators to write in their native language and translate it globally.

Sitecore allows each language to have its own version history. Every field on a template can be marked as unique to a specific language. Or, they can be shared across all the languages. Items can be pushed through the workflow for incorporating the translation process. When done properly, a site won’t require software alterations for supporting new languages.

Sitecore setup showing different language options


Inference:Building multilingual sites are well-supported by both the CMS.

6. Accessibility

Both Drupal and Sitecore are accessible platforms but Drupal has better features out-of-the-box like the default support for Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA).

Drupal 8 comes with several accessibility tools out-of-the-box with modules like Block ARIA Landmark Roles, Siteimprove, CKEditor Abbreviation and much more available to offer better experiences.

Sitecore needs designers and frontend developers to develop an HTML prototype which is split into components, tested, and rebuilt in the Sitecore system.

Both Sitecore and Drupal can be built and tested as per the World Wide Web Consortium (W3C) standards but with Sitecore, it might be time-intensive.

Inference: Drupal has a slight edge over Sitecore when it comes to ensuring accessibility standards.

7. Multisite

The multisite feature of Drupal helps in governing multiple sites across your organisation, brands, campaigns and geographies on a single platform. It allows users to quickly and easily create and deploy multiple websites.

Drupal’s multisite functionality enables you to share a single Drupal installation consisting of core code, contributed modules and themes among several sites. So, managing the code is easier as each upgrade only needs to be done once.

Illustration showing Drupal logos to describe multisite setup

Sitecore allows you to share content across multiple sites for a consistent experience on all of them. A default Sitecore installation defines a single published website but this single Sitecore installation is capable of publishing multiple websites with each site having its own properties.

For instance, you can define a new Sitecore site to be your published public-facing website or to be used by content editors for accessing the content management system.

Sitecore interface showing multisite setup


Inference: Multisite functionality is at the heart of both the CMSs.

8. Responsive Web Design

The out-of-the-box mobile-friendly features of Drupal 8 creates quite the buzz with the words like ‘mobile-friendly’, ‘responsive’ and ‘squishy’ associated with it. Above all, it is designed with a mobile-first approach.

Drupal 8 offers responsive administration and toolbar for the content editors and mobile-friendly core themes for the themers. It also comes with core modules like the Breakpoint module and the Responsive Image module for the site builders. With the Web services in the core, it is also great for application developers for developing native mobile applications.

Sitecore is mobile responsive and display-agnostic. Its device detection module allows users to automatically detect and optimise content for different devices thereby giving the option of previewing the content on different mobile devices.

Also, the geoIP detection package helps in personalising the content based on the physical location of the user.

Inference: Mobile-friendly features are prevalent in both Drupal and Sitecore.

Content Editor’s Eye View

Metrics

Drupal

Sitecore

Editing Interface

Good editing interface

Good editing interface

Drag and drop functionality

Drag and drop feature available

Drag and drop feature available

Granular editing

Granularity while editing possible

Granularity while editing possible

Grouping of the content

Better grouping of content

Relatively less flexible while grouping of content

Layout configuration

Excellent layout configuration options available

Excellent layout configuration options available

1. Editing Interface

Drupal offers excellent editing options. One of the options is to use the full edit mode where any content item can be easily edited using CKEditor - WYSIWYG HTML editor.

Drupal full view edit mode showing the editing of an article


Another option is to do in-place editing with the Quick edit module where specific items are chosen to be edited as shown here.

Title of the article being edited using Quick edit module of Drupal


In Sitecore, content editing is managed by Sitecore Experience Platform and Sitecore Experience Accelerator. Sitecore Experience provides editing tools namely the Content Editor and the Experience Editor.

The Content Editor offers fine-grained control over the content elements organised as objects in a content tree. Editors can choose an item for editing its fields. The Editing UI is by design resembles that of Microsoft Windows and provides easy usability transition for Windows shops.

Sitecore interface showing options for content editing


Sitecore’s Experience Editor enables in-place editing where, like Drupal, content editors won’t have to leave the page to edit a content item.

Sitecore interface showing options for in-place editing


Inference: Editing Interface offered by both the CMSs is similar and efficient.

2. Drag and Drop Functionality

Adopting an intuitive feature like drag and drop interface is quite popular with Squarespace and Wix offering a lot of those features.

Drupal comes with Panels module which can enable drag and drop functionality. Another Drupal module, Stacks, can help content editors build beautiful pages without any code.

Sitecore Experience Accelerator offers a UI which can be leveraged to drag and drop various reusable elements onto the page like text, video, image, JS widgets and many more.

Inference: Both the CMS excel at drag and drop feature offering.

3. Granular Editing

In Drupal, monolithic content is broken up with the help of Paragraphs module that allows end users to select on-the-fly between predefined paragraph types independent from one another. The paragraph type is any unit of content such as a text block, slideshow, image etc. Entity Construction Kit, another Drupal module, offers an alternative solution to edit with more granularity and reuse.

Drupal module paragraphs in action with options for granular editingParagraphs module in action

Sitecore allows the content to be broken up into smaller pieces instead of one monolithic body. This, again, offers more granular control and reuse of content.

Inference: Granularity while content editing is possible with both Drupal and Sitecore.

4. Grouping of content

Drupal offers flexibility in the way display of grouping of its content is done. It is because of its highly structured content and the Views module as part of its core.

Drupal’s Views module in action with options for grouping of contentViews module in action

In addition to basic filtering, Views can also filter on context like determining the logged-in user, knowing what parameters were passed into the URL and many more.

Views also display a grouping with elements of multiple disparate data sources with a common element like the grouping of blogs written by authors from a particular set of magazines. It is possible to filter the search results further by a number of elements constituting author, tag, field etc.

Sitecore displays a grouping of content items using its Search utility. Search results can be displayed in multiple view types constituting image view, list view, and grid view. It can be filtered down further by numerous elements like the author, tag, field etc.

search utility option of Sitecore described with labels


Inference: Drupal offers more power in the grouping of content than Sitecore.

5. Layout Configuration

Drupal provides the Layout module that helps in the provision of author-controlled layouts across several devices. It does so by decoupling layouts from themes created by the developer.

Layout Drupal module interface with horizontal layers from top to bottom


Also, the experimental Layout Builder module in the recent release of Drupal 8.6 supports per-display customisations for defining layouts with dynamic sections. It also helps in creating one-off blocks for a specific layout that won’t show up in the global block list. This is essential for things like a promotion that is only visible in the single landing page.

Another Drupal module, Display Suite, lets content editors place the fields like paragraphs, images etc. in the required region of the page. It can, then, choose from several predefined layouts for any content type.

Display suite drupal module interface with different options


Also, Drupal’s Panels module lets the user select layouts without ever leaving the page.

Panels drupal module interface with different options


Sitecore does not let users do in-page layout editing but it does offer a wide array of multi-column grid layouts where each of the columns can be customised.

Sitecore also provides a tool called Splitter for creating row regions and customise columns where any layout can be customised with CSS.

Sitecore splitter tool interface with vertical columns


Inference: Layout configurations options are excellent in both the CMSs.

Developer’s Eye View

Metric

Drupal

Sitecore

Skillset

Knowledge of PHP, Symfony, Twig, and YAML essential

Knowledge of C# and ASP.NET essential

Development in Drupal needs proficiency in HTML, CSS and JavaScript for the frontend and backend requires object-oriented PHP and MYSQL as the database. Drupal, typically but not necessarily, runs on LAMP stack with Linux as the OS and Apache as the web server. 

Knowledge of Symfony and the dependency injection design pattern is required for the Drupal backend. For theming, understanding of Twig is required and YAML should be known for the configuration of themes, distribution and modules.

Since Sitecore is friendly to Microsoft shops, it requires developers to have proficiency in .Net library, in particular, C# and ASP.NET in addition to HTML, CSS, and JavaScript. Microsoft SQL Server or MySQL covers the database part and the application server is IIS.

Inference: Both are completely different tech stack and very efficacious as well.

Hosting and Deployment

Metrics

Drupal

Sitecore

Hosting

Hosting-service agnostic

Typically hosted by Microsoft Azure

Deployment

Easy deployment

Relatively complex deployment

Drupal is hosting-service agnostic which can be deployed to any hosting service that supports PHP-based web applications. It stores the site configuration data in a consistent manner. It is easy to move configuration between environments like development, test and production environments.

Sitecore solutions are typically hosted by Microsoft Azure. To aid in deployment to Azure, Sitecore comes with an Azure toolkit consisting of ready-to-run command scripts, performance optimisation configurations, security essentials and many more. 

Inference: Being hosting-service agnostic, Drupal does the better job in this category.

Marketer’s Eye View

Metrics

Drupal

Sitecore

Marketing capability

Allows integration with best-of-breed third-party marketing tools

Comes with integrated marketing capabilities but third-party integrations not possible

Web personalisation

Drupal modules available for incorporating web personalisation features

Comes with integrated web personalisation features

E-commerce

Drupal commerce module helps in setting up e-commerce sites

Sitecore commerce helps in setting up e-commerce sites

Although Drupal core does not come with integrated marketing and analytics functionality, It does integrate well with major marketing automation platforms like Marketo and Pardot. Thus, Drupal gives power to marketing teams to choose tools that work best for their organisation.

Moreover, the Rules module helps in creating deep, personalised user experiences without the intervention of developers. Also, Acquia lift connector module provides integration to Acquia lift service incorporation best web personalisation strategies into the website.

Google Analytics module incorporates high-level analytics and reporting capabilities into Drupal.

Google analytics drupal module interface with different options

For businesses, who are in need of setting up an e-commerce site, open source module Drupal Commerce suite of modules offer a great platform.

Sitecore comes with integrated marketing and analytics capabilities in its core. It allows users to easily set up marketing campaigns and campaign analytics. For instance, you can track the number of visitors on your site and the level of engagement of the traffic.

Sitecore marketing analytics interface with different options


Also, Sitecore uses a rules-based interface to let digital marketers target content to specific users under certain conditions. With a feature called Engagement Plans, it can employ actions and triggers upon specific actions that are being met. Moreover, it manages Experience Profiles to track user behaviour.

Sitecore also offers dashboards and reports for monitoring page views, conversion rates, user engagement etc. which can be used for analysis.

However, the Forrester Wave: Web Content Management Systems, Q1 2017 report states that Sitecore’s practitioner’s tools like testing, optimisations, customer data profiles etc. for marketing needs do not compete against best-of-breed tools.

Sitecore also offers commerce capabilities by integrating with a suite of applications which is called Sitecore Commerce which is available for additional licensing costs.

Inference: Sitecore has in-built marketing analytics and personalisation capabilities which is not there in Drupal. But Sitecore’s inability to integrate with other wonderful marketing tools available in the market makes a strong case for Drupal’s third-party integration capabilities.

Business Constraints

Metric

Drupal

Sitecore

Industry-wide adoption

Relatively more market share and industry-wide adoption

Relatively less market share and industry-wide adoption

Business costs

Being open source, it is free to use

Incurs licensing costs and is priced very high

Vendor lock-in Vendor-agnostic Not vendor-agnostic
Bar graphs showing market share of drupal and sitecore in different coloursSource: Similartech

Whether it is Top 1 million sites, Top 100k sites or the top 10k sites, Drupal has a lead over Sitecore. This is because Sitecore’s pricing is high as stated by Gartner Magic Quadrant for Web Content Management 2018. In comparison, Drupal and its contributed modules are absolutely free to use. However, Drupal involves costs for implementation and hosting like Sitecore.
Drupal has a plenitude of hosting options at virtually every price point.

Being an open source platform, Drupal is vendor-agnostic. In contrast, Sitecore, being a proprietary CMS, lands you in vendor lock-in incurring high costs.

Inference: When it comes to right decisions regarding business costs and efficient CMS for the digital business, Drupal beats Sitecore by a country mile.

Community Presence

Metric

Drupal

Sitecore

Community size

Larger community

Smaller community

Drupal community is gargantuan with more than millions of people across the globe of all the skills and backgrounds contributing towards the betterment of Drupal core.

With such a large community, the Drupal project is perpetually under a vast peer review with innumerable independent developers working on the project across the world. Peer-reviewed, community-created patches are rapidly built for Drupal and its modules. The community’s ethos of teamwork and volunteerism drive digital innovation and it keeps on working towards the integration of Drupal with new, trending futuristic technologies.

On the flip side, Sitecore has user forums for developers to support each other. But the comparatively smaller size of community makes it difficult to gain access to qualified developers.

Gartner Magic Quadrant for Web Content Management 2018 stated that Sitecore has a reputation for intricacy and relatively long implementation and deployment times. Some customers have complained about insufficient support resources from Sitecore during design and deployment stages. Also, inconsistency has been witnessed in implementation quality from its partners.

Inference: With a robust community presence, Drupal far exceeds in this category against Sitecore.

Conclusion

Drupal and Sitecore have been compared against various perspectives and both the CMSs have apparently grown over the years with loads of features to offer.

Technical comparisons have shown that Drupal and Sitecore are both content store backed object-oriented framework. However, Drupal’s ability in integrating with amazing third-party marketing tools and web personalisation tools should be considered which can be way better than what Sitecore offers as part of its integrated system.

Unlike Sitecore, Drupal is hosting-service agnostic and is relatively easier to deploy. No wonder, Drupal has witnessed more industry-wide adoption as compared to Sitecore.

More importantly, Business costs are a huge factor where Drupal, being open source, beats Sitecore by a big margin since Sitecore is priced very high.

Finally, Drupal, with a presence of an active community, provides seamless module extensions, quick mutual support, and rapid response to security threats. Unlike Sitecore, Drupal is vendor-agnostic and its smaller footprint ensures more scalability than Sitecore.

Choosing a CMS for a digital business involves business demands and strategies that state what’s best for their future endeavors. It is important to look at this analysis in terms of your organisational needs and make a decision accordingly.

At Opensense Labs, we have been pioneering in the Drupal Development and can help you transform your digital presence. Ping us at [email protected] to make the right decision vis-à-vis CMS selection.

Sep 21 2018
DA
Sep 21

In this post we will share our experience in installing a Drupal 8 application on an Amazon EC2 server with latest Ubuntu 18.04 LTS.

Installing Drupal with composer greatly simplify system maintenance and further update.

AWS image

First you will need to create EC2 instance with proper AMI from Amazon Web Service. You can find the AMI from the locator.

We will not cover in detail this part, as we assume this is already covered by many other blogs and tutorials.

We pick latest 18.04 LTS version of Ubuntu to comply with requirements of Drupal 8 with PHP 7.2.

Composer

Once your server is running, the next step is to install composer.

Once again, we will not go too much into details as composer installation is also widely covered.

In our case we followed similar procedure as the one described here.

Drupal

For actual installatin of Drupal with composer, there is a guide at drupal.org with 3 options. We picked the option A.

The repository is a composer template for Drupal projects with pretty good usage guide. The latest version will install Drupal 8.6.1.

We run the command:

git clone https://github.com/drupal-composer/drupal-project.git <MyAppName>

(note: the code will be copied within the folder "MyAppName" within your current folder location. For instance if you are in /var/www, the application will be in /var/www/MyAppName)

At this point we edited the composer.json file to match our desired folder configuration. You need to edit manually the installer path here before installing the application or if you prefer, keep the default paths.

"installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/{$name}": ["type:drupal-drush"]
        },

To edit, run command:

Sudo nano MyAppName/composer.json

and edit "installer-paths". In our case we changed to:

Once your have the desired folder configuration, you can run actual installation command:

composer -vvv install

(note: -vvv option is optional)

This will install Drupal site.

Custom application

One of the purpose of using composer installation is to merge other composer files and install custom plugins and applications.

To be able to merge composer files, you need to install the composer-merge-plugin first with command:

composer require wikimedia/composer-merge-plugin

then run:

composer update --lock

You can now add additional plugins with their specific composer installer. In our case, we install our own application EK Management tools suite with the following command:

composer require arreasystem/ek:"dev-8.x-dev"

This will install custom application.

You can merge composer.json paths as "extra" option in main composer.json:

Sudo nano MyAppName/composer.json

For instance add the custom plugins paths:    

"extra": {
          "merge-plugin": {
                      "include": [
                          "modules/contrib/ek/ek_admin/composer.json"
                      ],
                      "recurse": true,
                      "replace": false,
                      "merge-extra": false
                  },

And run:

composer update --lock

This will for instance install following libraries:

You may encounter error with composer when updating with an out of memory error. This will happen with low specification EC2 instances. To solve this problem, add swap memory on Ubuntu server.

Create swap file: sudo dd if=/dev/zero of=/swapfile bs=2M count=2048 (this will create a 4M memory swap);

Enable file: sudo chmod 600 /swapfile;

Allocate: sudo mkswap /swapfile;

Start: sudo swapon /swapfile.

With this installation, you will just have to run composer update to update your installation version. This comes also with Drush and Drupal Console installed. Don't forget to run update.php after core update if necessary.

We hope this short post has been useful. Feel free to add comment or questions.

Sep 21 2018
Sep 21

Like every organization, you want yours to build around consistent and successful marketing operations. The choice of your CMS has a lot to do with the execution of the successful marketing campaigns. 

Dynamic organizational goals need dynamic sites. Which raises the bar high when selecting the CMS of your choice. 

Comes along the cost involved in all aspects. 

In the comparison series, today, we have Drupal (open source software) vs Umbraco (proprietary software).

Here’s to choose between Drupal and Umbraco. Which one serves your needs better? Read on to know more. 

But first, let’s have a look at the market share of each CMS. 

Market Share of Umbraco vs Drupal 

market share of drupal and umbraco in graphSource: W3Techsgraph with dots depicting the position of the CMSSource: W3TechsHORIZONTAL GRAPH SHOWING THE COMPARISON BETWEEN DRUPAL AND UMBRCOSource: Similartech


Drupal has better usage coverage in more websites categories. Including Business & Industry, Arts & Entertainment, People & Society, Career & Education, and 242 other categories. In other words Umbraco hasn't got a lead over Drupal in any websites category.

Let’s get to the actual comparison. 

Round One: The Cost

Umbraco is actually an open source but it heavily relies on proprietary software. Umbraco add-ons range from free to a licensing fee either per domain, per server, or a lifetime license. The licensing is covered under MIT license which means you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source. 

Drupal, on the other hand, is an open source software. Free to use, re-use, and distribute. Drupal modules (add ons) are free too. 

The Drupal.org (official Drupal website) writes it as “...It's built on principles like collaboration, globalism, and innovation. It's distributed under the terms of the GNU General Public License (GPL). There are no licensing fees, ever. Drupal will always be free.”

Drupal Wins!


Round Two: Editing Experience

At the heart of marketing lies content. 

A marketing CMS streamlines the work involved in creating new content in unprecedented ways. That is why your CMS needs to offer the right and intuitive kind of editing experience. 

Creating content is easy in Drupal. Authoring with WYSIWYG features is designed to keep content creation neat and ordered. It provides the preview and drag-and-drop image uploads option. And when you need to make quick changes with in-context editing it is easier. 

Not just this, it is available in 100 languages. You don’t have to limit your audience to one specific demography or language. 

With the help of a CKEditor feature built specifically for Drupal, you can more easily control details like image alignment and captions right from the palm of your hand.

By default, the editor enforces clean markup and has formatting tools disabled. In case you are looking to change the settings or editing buttons you just need to use a drag-and-drop configuration UI for adding and removing editor buttons.

Editing is indeed intuitive in Umbraco. 

It is easier to just add the content and rearrange it accordingly. Working on Drupal’s text editor for more than a year, it has been a breath of fresh air (no offense, Drupal community). Adding multimedia content is easy.

Not just this, you can also see the preview of your content on different sites with Umbraco’ unique Responsive Preview. Even before it is live. 

This ensures that the visitors experience the content the way you want them to. Adjustments are easy to make too. 

Another thing that adds is that as an editor you can always rollback to an older version. It’s like an infinite undo button. (@Drupal we need this.)

The built-in Umbraco Image Cropper ensures that your images are presented as you want. With the focal point you simply point and click on the most important thing in the image and the image is automatically resized and cropped so as to fit perfectly on any device while ensuring that the most important thing stays in focus. 

Drupal’s Focal Point module promises similar functionality but it needs to be added later. 

Both offer the option to schedule the content. 

Umbraco Wins! 


Round Three: Practicing Accessibility

It is very important that as an organization you don’t happen to miss any of your audience, not even by ignorance. 

Drupal 8 provides web accessibility out-of-the-box and it is mandatory. Not just this you could even mark content regions with attributes with HTML5 semantic markup. 

Navigation is simpler by identifying menus, banners, and ancillary content areas, and letting keyboard users move through them more easily. Drupal 8 puts these methods to work in a new admin toolbar that adapts to different screen widths, and is easier for people with screen readers to use.

Umbraco, although, provides accessibility features like alt text sadly they are optional. Accessibility is something that should be part of the general web development practices, and clearly Drupal ensures the discrimination doesn’t happen, as a choice. 

Drupal Wins!


Round Four: Community support

The Drupal Community is one of the largest open source communities in the world. The community support involves documentation creation, sharing networking opportunities, and more. The sheer commitment to the open source spirit pushes the Drupal project forward.

Around 1,300 agencies provide Drupal services across the globe (according to Drupal.org) and more than 3,200 contributors are working right now to improve the platform. 

Community support of Umbraco is no different. The official website tells us that they currently have an active community of over 200,000 “Umbracians” worldwide ready to share their experience and knowledge with others.

They take pride that the online community transcends to and becomes real gatherings all over the world in the form of local Umbraco meetups and even Festivals. 

It’s a Tie!
 

Round Five: Installation Profile

Getting started with the Umbraco? It provides you with two options - Clean website and the one with a demo. However good the intentions were a clean slate can be a bit overwhelming for some, especially if they’re new to Umbraco (did I copy that?)

Drupal - the latest 8.6 version provides with a starter kit - a basic site with a sleek minimalistic design of a food magazine. Learn and play with it. Set the features as you want. 

This makes it easy to customize and see how Drupal features set in. See if it fits your needs. 

Drupal Wins!


Round Six: Headless/ API first

An API first or Headless CMS simply lets you hit publish and your changes will automatically update on mobile apps, on store displays, flat screens, websites, even on smart watches. 

A feature that you can’t afford to miss especially when there are numerous screen types today. 

Umbraco promises that its headless “helps you edit the content easily in one place, and it is updated across your webshop, website, campaign sites and on displays on every screen.” 
 
Umbraco Headless helps you enable power for other types of websites with Umbraco such as Single Page Application or websites running on a different platform than .NET. 

Problem? 

The community is very close to having everything in place for the official launch of Umbraco Headless. It is not yet launched. All Hype, Nothing Fruitful

Drupal 8 core has out-of-the-box REST API that allows operators to interact with content entities like taxonomy terms, nodes, users, and comments.

Drupal 8 has Contenta (a Drupal distribution) and Reservoir are two of the API first initiative. Various contributed modules allow you to add web services to a Drupal installation without the need for writing code. 

For instance, Developers can use Services module and the RESTful Web Services module to configure a server for enabling the Drupal installation to push or allow data that is to be pulled as needed with the help of REST API. No matter whether the action is a push or pull, Drupal is the services layer. 

Drupal Wins! 


Round Seven: Training and Understanding 

Umbraco.TV will help you go from zero to Umbraco hero at a pace that suits you. Our easy to follow online training videos + written docs will give you the fundamental knowledge to start building awesome Umbraco websites, without burning a hole in your pocket!

Drupal has a steep learning curve. True that! 

But the content is easily available on the web. You can access learning material on Acquia, OSTraining, and Drupalize.me. Leaving Drupalize.me aside both the sources are free and available for all. 

It’s a Tie!


Round Eight: Hosting and Deployment

Drupal is hosting-service agnostic which can be deployed to any hosting service that supports PHP-based web applications. It stores the site configuration data in a consistent manner. It is easy to move configuration between environments like development, test and production environments.

Umbraco solutions are typically hosted by Microsoft Azure. To aid in deployment to Azure, Umbraco comes with an Azure toolkit consisting of ready-to-run command scripts, performance optimisation configurations, security essentials and many more. 

Being hosting-service agnostic, Drupal does the better job in this category.

Drupal Wins!


Conclusion

Every CMS has its own set of advantages. The choice of CMS is generally influenced by what your web project’s requirements are. The questions that follow are: What functionality or features are needed? 

In my opinion, Drupal has a bonus point for maintaining a modules directory that lets you search and manage the content. 

It's easier to customize components—views, lists, blocks, admin tools, and more—than ever before. Control how data is displayed without using a single line of code.

Drop a mail at [email protected] to discuss your business goals.

Sep 21 2018
Sep 21

The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website!

Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:
 

  • adding media from a remote source
  • adding various types of media
  • embedding Youtube and Vimeo videos in the content (via URL)
  • easily accessing and reusing the existing media
  • uploading new media types right out of the box
     

And this is almost... overwhelming:

From almost no built-in media support in Drupal, for so many years, to a whole set of modern, powerful media management options now in Drupal 8.6.0.

But let's not ramble about this topic anymore and dive right in! Into the pile of new features meant to enhance the whole media management experience in Drupal:
 

But First: An Update on The Progress of the Media in Drupal 8 Initiative

The main goal of this media initiative was to:

Add a rich media support to Drupal 8.

One that would empower the content editors to easily reuse existing media assets, add new media entities and to overall gain more control (and meta information) over their media.

And there are 3 core milestones that we can trace while tracking the progress of this initiative for Drupal 8:
 

  1. adding the experimental Media module to Drupal 8.4 in late 2017
  2. leveling up this module from experimental to stable phase in Drupal 8.5.0
  3. turning it into the standard way of storing media in Drupal 
     

Moreover, starting with Drupal 8.6.0 a new key module for handling media has been added to core — Media Library — along with a few more exciting options:
 

  • quick access to the existing media assets
  • oEmbed support
  • a new media type: remote video content
     

Quite a “leap” forward, to a great media management experience in Drupal, I would say...
 

2. Welcome a New Media Type in Drupal 8: Remote Video

Let us list the 4 media types that you could add to your site's content up to Drupal 8.6.0's release:
 

  1. file
  2. image
  3. video
  4. audio
     

OK, now it's time you welcomed a new media type to the group: remote video!

Basically, as a content editor you're now able to add videos from remote sources, as well — Vimeo and Youtube — via their URLs.

Handling Media in Drupal 8.6.0- New Media Type: Remote Video

In short: you're no longer constrained to settle for the default media types in Drupal 8. No sir, now you get to create new custom ones mentioning their media sources.

Summing up: embedding new media to your website content is nothing but a two-step process: Content-Add Media.

Handling Media in Drupal 8.6.0- Add New Media Type


3. Reusing Media Is Now Possible: Media Library

One of the much-awaited features for media handling in Drupal 8.6.0 had been reusable media.

Well, here it is now: Media Library! It's where you can save and store all your media assets to be further reused whenever needed.

Note: do keep in mind that this an experimental module and that you'll also need to enable the Media module first things first.

“And how does it work more precisely?”
 

  1. while in your content edit screen
  2. just browse through all the media assets stored in your Media Library
  3. select the one you need
  4. and simply “inject” it into your page
     

Note: it's the “Media library” widget, added to the Media field, that enables you to scan through all your media entities straight from the content edit screen.

Handling Media in Drupal 8.6.0- Media Library Widget


4. The New “Media” Field: A Quick Way to Embed Media in Your Content

Handling media in Drupal 8.6.0 is as simple as... adding a new field — “Media” —  to the content type in question (be it news, blog post, article and so on).

Handling Media in Drupal 8.6.0- Add a New Media Field

Once the new field is added on, just go through the 5 media types available in Drupal 8.6.0 and select the one you need to embed.

Next, you can simply integrate it into your content, while in your edit screen, positioning it to your liking.
 

5. New Media Handling in Drupal 8.6.0: Youtube & Vimeo Embeds

A new media management tool that significantly improves the whole content editing experience in Drupal.

You're able to embed remote videos from Youtube and Vimeo via URL, thanks to the now added oEmbed media support.

“How precisely?” Basically, you simply:
 

  1. add that new “Media” field to your content type, as previously stated
  2. select the “Remote Video” option from the “Media Type” drop-down menu
  3. enter your video's URL in the “Video URL” field, while in your “Add Remote Video” screen
  4. and click “Save”
     

And voila: you'll have your remote video integrated into your content!

The END!

As Steve Burge from OSTraining would say:

“Finally we're getting somewhere with media in Drupal!”  

What do you think about the new features for media handling in Drupal 8.6.0? What other options and tools are there on your wishlist?

To be able to embed remote videos right from the node create page, maybe? Or to have other video platforms, as well, supported in Drupal?

Sep 21 2018
Sep 21

What to do with an old, outdated website that you would like to keep online? The perfect solution is to archive it to pure HTML code. We will demonstrate it on the example of a drupalcamp.pl website created in Droopler, based on Drupal 8.

Why archive pages at all?

Sometimes websites have their expiration date. It may result from the life cycle of the technology used to build it or simply because the website was created for an event or some special occasion. When you organise a music festival, for example, the website is no longer up to date and necessary after it ends. When you have long forgotten websites on your server, their code may be so outdated that it will turn into a threat in the future. If, for some reason, you want to keep your websites on the Internet, you have to take into account the cost of their constant maintenance and updating.

What are the costs of an unused website?

The cost of maintenance depends to a large extent on the technology used. Let's focus on Drupal 8 since it is one of the safest CMS available on the market. Updates to D8 are published monthly, and every six months a version containing new functionalities is published. This means you need to install a fresh release of Drupal 12 times a year and test our website to see if it's still working, so you can stay on top of updates. We know from experience that this can be very time-consuming.

On the other hand, if you decide against upgrading, your website is now at risk of being attacked and poses a threat to other websites on your server. Shortcomings in the security department may lead to much higher costs than updating your code on an ongoing basis.

The question arises – how to avoid maintenance costs and keep the website online? A great compromise between sentiment and cost-effectiveness is the conversion to pure HTML code.

What are the advantages and disadvantages of pure HTML?

Deploying websites written in pure HTML is in a sense a return to the roots. In the age of advanced CMSs, hardly anyone remembers that a website can be created without the use of server-side interpreted languages, such as PHP.

Why writing pages using HTML only was forgotten?

  • Due to difficulties in updating their content.
  • Because it is not possible to reuse the code for global elements (such as header, main menu, footer).
  • Due to the static nature of HTML, which makes it difficult to create administrative pages.

So why convert an unused Drupal 8 website to pure HTML?

  • This will result in a rapid increase in the speed of operation of all subpages, including those which have been the slowest so far.
  • It will be very difficult to attack the website if you configure the server properly.
  • Updating the code will become completely unnecessary, the cost of maintenance will be practically zero.

What will be the limitations of a website converted to HTML?

  • Changes to the content will become more time-consuming. The developer will include them in a local copy and then generate the HTML version for publication on the server.
  • Dynamic elements such as forms will stop working.

How to adapt a website for archiving?

Not every website is suitable for archiving right away. First of all, you should make sure that none of the subpages contains any elements requiring PHP scripts to work:

  • Contact forms (they can be replaced with embedded Google Forms).
  • Search engines (they can be replaced with Google search on the website).
  • Views Exposed Filters.
  • AJAX in views.

It is also necessary to disable error messages sent by the server – especially when copying a website from localhost. During archiving you should use settings as similar to production as possible, including CSS/JS aggregation and lack of additional diagnostic information generated by Twig.

At the beginning of the article, we promised to describe the conversion to HTML, based on a real example. Therefore, we are going to present the method of archiving the drupalcamp.pl website, dedicated to the DrupalCamp 2018 conference organised by us. This is a cyclical event, but each subsequent year we prepare a completely new website. Once DrupalCamp has taken place, we leave this page up as a souvenir, archived to HTML at a separate address.

The website of DrupalCamp conference in Wrocław.

What preparations did drupalcamp.pl require? First of all, we removed the subpages with the forms, which were no longer needed, since the conference has already ended. We made sure that all views worked without AJAX on the programme subpages. We also carried out a quick JS audit to eliminate potential code issues when PHP is disabled.

The archiving process

We use the httrack software, which is available under the GNU GPL3 license, in order to automatically archive pages. It is available for Windows, Linux, OSX and Android. We use httrack via a Linux console. There are plenty of switches and options available in the documentation, here is our command to make a 1:1 copy of a website, while maintaining the link structure:

httrack http://example.com -O output_dir --disable-security-limits --max-rate=99999999999 -K3 -X -%P -wqQ%v --robots=0 -N "%h%p/%n.%t"
  • --disable-security-limits - disables the built-in transfer limits, this is useful when our local server is the source.
  • --max-rate - sets the maximum transmission speed.
  • -%P - tries to recognise all possible links to files on the website.
  • -K3 - does not change the links on the pages.
  • -N "%h%p/%n.%t" - does not change file names.
  • -X - on the next command, deletes files from the archived version that were deleted in the original.
  • -wqQ%v - standard mode, silent, with a list of processed files on the screen.

The resulting page image is not yet completely finished. The subpages are in files such as about-us.html, instead of about-us/index.html. A simple script will fix this problem:

#!/bin/bash
for f in $(find output_dir/example.com -name "*.html" -type f); do 
        if [[ $f = *"/index.html" ]]; then
                echo "Omitting $f"              
        else
                echo "Processing $f"
                mkdir "${f%.html}"
                mv $f "${f%.html}/index.html"
        fi
done

The copy created in this way will be indistinguishable from the original to the observer. This is important for the preservation of existing positions in Internet search engines.

Httrack’s compatibility with Drupal

Drupal 8 is not fully compatible with httrack. The main problem is the responsive images presented via the <picture> tag. Proper conversion to HTML requires providing httrack with hints for additional downloads.

The drupalcamp.pl website that we archived is based on Droopler, an in-house, free of charge distribution of Drupal 8. In version 1.3 of Droopler, we have implemented full support for httrack, which helps with identifying and downloading all graphics files used on the website.

How did we “improve” the compatibility with httrack? We used a very simple solution in the form of hooks preparing a list of files to download. Hints for the bot are placed in the <head> section of the page, as subsequent <link> elements:

<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_2000/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=YkFsAytN" rel="droopler:c0527d:img0" />
<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_1200/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=OEsKzsbg" rel="droopler:c0527d:img1" />

These elements are recognised by httrack and downloaded to the copy. Thanks to this, we can maintain full responsiveness of the images. The excess code is usually deleted from the console by means of a regular expression.

Conversion results

The result of conversion to HTML is very satisfactory in our case. We’ve got a folder with files of a total size of about 20 MB. As one would expect, the access time to an HTML file is a few milliseconds, meaning that it is negligible. It remains very low even under heavy loads. So far, this value on the production server has oscillated around 200ms (of course for users who weren’t logged in, with active cache). Under the load, it increased to about 700ms.

We checked the correctness of export using Screaming Frog SEO Spider software. It did not detect 404 errors, which means that the archiving was 100% successful. Also, the browser consoles do not show any JS errors.

It can be expected that in the next few days the DrupalCamp 2018 website will be finally retired and replaced by pure HTML version. In this way, we will avoid the need to update it and, therefore, we won’t incur additional costs. If there is a need to make changes to the content, we will make them on a local version, based on Drupal, and then automatically generate a new HTML page. We encourage you to take advantage of our experience!

Sep 21 2018
Sep 21

You have already seen what Drupal blogs were trending in previous months, and now it is time to look at all the blog posts we’ve written. Here are the blog topics we covered in August.

The first blog post was How to Embed Videos in Drupal 8. Videos have become a major part of the internet alongside images and texts. Videos not only increase the engagement of your website but also making it more appealing/attractive. Historically, Drupal hasn’t been too media friendly and has been criticized for that compared to other CMSs. But with Drupal 8, as well as its media initiative, those days are behind us. In this post, let’s take a look at how easy it is to embed a video on your Drupal 8 site.

The second was a blog post How to Speed Up Drupal Websites with Google AMP. Google’s AMP is an open source project that stands for Accelerated Mobile Pages. As the name implies, this project aims to serve mobile pages instantly without long load times. You can get a feel for AMP by searching for anything on your mobile on Google and clicking on links with a lightning sign beside them. Speed is an important factor for any website as it has numerous benefits, including making a massive impact on a site’s SEO. In this post, let’s take a look at AMP for Drupal 8 and a brief overview of its implementation on the CMS.

We continued with a Drupal is Easy with Michael Anello. In this interview, you can learn about his volunteering, how successful Drupal Career Online (DCO) program (DCO) is and on what contributors he is most proud of.

The fourth blog post was Migrate WordPress to Drupal. WordPress is the most popular and most widely used CMS in the market right now. It’s very versatile and easy to use however it isn’t perfect for all scenarios. There might be instances where Drupal would be the preferred choice for a particular solution and also be a case where a user would need to migrate their WordPress site to Drupal. While this process isn’t quite streamlined, due to the differences in the way both CMSs work, there is a pretty simple way to get started on this and migrate the bulk of your content to Drupal. In this post, let’s take a look at how this can be achieved.

And the last one was Josef Dabernig: Drupal not just a software, but an ecosystem. In this interview read about his move to Switzerland, why he believes Drupal is a role model for other Open Sources, what his master thesis is about and his extreme Tour De DrupAlps.  

Those were our blog posts from August 2018. Looking forward to continuing having you as a reader!  

Sep 20 2018
Sep 20

This is the fifth installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts. To catch up, see Part 1, Configuration Providers, Part 2, Configuration Snapshots, Part 3, Respecting Customizations, and Part 4, Configuration Alters.

In this installment we'll start to pull it all together.

Paraphrasing a bit from Part 1, we described a key problem this way:

How can I update my site so that I have all the latest configuration changes from a distribution--while still retaining any customizations I made?

In Part 1 we mentioned Fabian Bircher's widely used Configuration Split module and its enabling API module, Config Filter, returning in Part 3 to give a more detailed introduction. In Part 2, we summarized the API and accompanying user interface that core provides for staging configuration. Here we'll take a deep dive into how we can merge in configuration updates from installed extensions through an approach that's built on Config Filter and closely parallels core's configuration staging.

Config Filter and core's configuration staging

From Part 2 in this series:

Using Drupal core, you can stage configuration between different environments or versions of a given site--say, from a development environment to a testing one. For details of how this works, see the Configuration Management section of the Drupal 8 handbook. The Synchronizing Configuration Versions section of the Drupal 8 User Guide also reviews this functionality.

When you stage configuration, core reads the configuration to import from a configuration storage (see the overview on storages in Part 1). Core uses a storage provided by the config.storage.sync service, which by default serves up files from a specified directory.

At its most basic, configuration staging is a two-step process:

  • Export configuration from one environment - say, a development ("dev") environment - and copy them to the sync directory on another instance of the site--say, a live environment.
  • Run core's configuration synchronization. All going well, your live site now has configuration that's identical to what was exported from dev.

But what if you don't want live to be exactly the same as dev?

That's where Config Filter comes in. Any module can provide one or more filters. Configuration Split allows site admins to create configuration "splits" that are applied as filters on top of core's sync directory. For details, see the module's drupal.org documentation and the blog post Configuration Split: Managing Drupal 8 Configuration for Different Environments.

Config Filter makes Drupal core's configuration staging workflow a lot more flexible. But its API is not limited to the staging workflow. A config filter can apply to any storage; core's config.storage.sync is only the default.

So, using Config Filter, the way is open for a contributed module to mirror core's configuration staging workflow, but providing a framework for merging in updates from extensions rather than staging configuration between environments.

Config Distro and Configuration Synchronizer

And that's exactly what the Configuration Distro module does.

Configuration Distro provides a filtered storage, config_distro.storage.distro that wraps core's active configuration storage. Config Filter plugins using that storage will apply their changes to the site's active configuration--just what you need to bring in updates from extensions. It then provides a UI directly parallel to core's configuration staging UI.

And it stops there, for reasons explained in the blog post announcing Configuration Distro:

If you only install Config Distro, the import screen eternally shows that there is nothing to import. This is because the module only provides the framework for this to work, ie the UI and the drush command. The module is not opinionated on how or what should be updated. All the complexity can be addressed by a distribution maintainer with the help of a ConfigFilter plugin (the same way Config Split and Config Ignore work). One such module is Config Sync [Configuration Synchronizer]. All the complexity of finding out what configuration a module has originally shipped with, what it does now and whether a user has changed the originally installed configuration is left to Config Sync and its dependencies.

Much of the heavy lifting for "all the complexity" is accomplished through the various modules profiled in this series so far, including Configuration Provider, Config Merge, and Configuration Snapshot. But there's plenty left for Configuration Synchronizer to do ;)

A config snapshot for each extension

The Configuration Snapshot module makes it possible to take snapshots, but leaves the logic of when and why to other modules. In Configuration Synchronizer, we take config snapshots and apply alters to existing snapshots when extensions are installed. We also subscribe to an event, ConfigDistroEvents::IMPORT, that the Config Distro module dispatches on completing a configuration import. This allows us to refresh the snapshot for every extension that had updates imported.

Updates = Providers - Snapshots

Determining what updates are available for each extension involves three steps:

  • First, consult Configuration Provider to find out what configuration is currently provided.
  • Next, load our configuration snapshot for the extension via Configuration Snapshot.
  • Finally, compare the two (using core's StorageComparer) to determine what's been changed or added.

A config filter for each extension

Just as we have a snapshot for each extension that provides configuration, we provide a corresponding configuration filter.

We need a filter for every extension that has available updates--a list that may change any time we update to a new version of an extension or run the Config Distro updates. So we follow a pattern from Drupal core that allows us to dynamically declare our filter plugins: plugin derivatives. An example of a plugin deriver is, BlockContent, used in core to make a block available for each piece of block content. For a detailed backgrounder, see this Tutorial on Using Drupal 8 Plugin Derivatives Effectively.

In our plugin deriver, SyncFilterDeriver, we iterate through the list of available updates by extension and add a plugin for each.

Update modes

In Configuration Synchronizer we provide two different modes for bringing in configuration updates.

The default update mode is merge. When the merge mode is selected, the configuration filter for a given extension merges in changes via a call to the relevant method in Config Merge. This way, any customization done to the site's active configuration is retained.

But in certain cases you might not want to retain customization. So a second update mode is available: reset. When the reset mode is selected, the active configuration is reset to what's currently provided by the extension. This mode is equivalent to what was called "reverting" in the 7.x version of the Features module.

Customizing the update form

Config Distro provides a form for configuration updates that's pretty much identical to the "Configuration synchronization" form provided by Drupal core. But in Configuration Synchronizer we support a separate update per extension. So we extend the Config Distro form to provide a lot more information as well as options.

For each extension, we list details of what updates are available, showing:

  • The type of update (new items vs. changed ones).
  • The type of configuration.
  • The configuration item names.

Clicking on or selecting an individual item's name will load a diff for that item.

And we provide a checkbox to select that extension's updates.

In an "Advanced" section, we offer a select to choose the update mode, "Merge" or "Reset".

Config Distro Ignore

The merge and reset update modes are useful, but there may be cases where you want to combine the two. For example, you might want to reset almost all configuration on your site to the state that currently ships with a distribution, but still retain a select few customizations. To cover that case, Config Distro ships with a sub-module.

Using Config Distro Ignore, you can specify particular configuration items that should be ignored (left untouched) when you bring in changes. Once you have done so, if you then set the update mode to "Reset" and run an import, those specific items should be retained while all others are reset.

Potential enhancements

If there's one thing that's probably obvious by this point, it's that managing configuration updates from contributed modules is complex!

A major lack in Configuration Synchronizer and its Druptopia-sponsored dependencies is test coverage.

Support for Drush has not yet caught up with what's in the module's UI; see the feature request Add Drush command for the "reset" update mode.

Another area for improvement is handling of configuration that's been deleted from the module that originally provided it; see Optionally delete config entities when they're deleted from code.

Next up

Stay tuned for the next post in this series: Packaging Configuration.

Sep 20 2018
Sep 20

As we enter the month of September and start planning for 2019, it’s a good time to take stock of where Drupal is as a project and see where it’s headed next year and beyond.

Dries Buytaert, founder of Drupal, recently wrote his thoughts around the timeline for Drupal 9 and “end of life” for Drupal 7 and 8. We will look at current Drupal 8 adoption and assess where we sit in 2019 as well.

An important part of this discussion that deserves attention is the rise of Javascript as a programming language, in particular, the rise of React.js. This technology has put CMSs like Drupal in an interesting position. We will look at how React/Javascript are evolving the web and assess what that means for the future of Drupal.

Finally, we will wrap up with thoughts on what these changes mean for both developers and organizations that use Drupal today or evaluating Drupal.

Drupal 8 Adoption

As mentioned previously, Dries has offered his thoughts on the proposed timeline for Drupal 9 in a recent blog entry on his website (see below).

timeline: Drupal 9 will be released in 2020. Drupal 8 end of life is planned for 2021

In early September Drupal 8 released version 8.6.0 which included major improvements to the layout system, new media features, and better migration support. This is in addition to many other improvements that have been released since Drupal 8.0 was first unveiled in late 2015.

In terms of adoption, Drupal has picked up steam with 51% growth from April 2017 to April 2018.

Dries Keynote Drupalcon 2018

graph showing that as of April 2018, 241,000 sites run on Drupal

As encouraging is that news is, it’s still should be noted that Drupal 7’s popularity still far exceeds Drupal 8 both in current usage (800k compared to 210k+ sites) and in terms of growth year over year. 

Drupal’s weekly project usage from August, 2018

graph shows Drupal 7 adoption exceeds that of Drupal 8

Drupal 7 will reach its end of life likely around November 2021 with paid support extending the lifetime with commercial support (as was the case with Drupal 6). Will Drupal 8 reach the level of usage and popularity D7 has? Perhaps not but that is largely due to focus on more robust, “enterprise” level features.

Drupal as a CMS sits largely in between Wordpress and enterprise proprietary CMSs like Adobe CMS and Sitecore in the marketplace. With the release of Drupal 8, the project moved more into the direction of enterprise features (which could explain some of the fall-off in adoption).

Pantheon had two excellent presentations (also at Drupalcon Nashville) that dive deeper into Drupal’s position in relation to other projects, most notably Wordpress. I would recommend watching WordPress vs Drupal: How the website industry is evolving and What's possible with WordPress 5.0 for more information on this topic.

According to builtwith.com, Drupal still has a sizable chunk of Alexa’s Top Million Sites. It should also be noted that Drupal does better the higher you go up the list of those sites which underscores the project’s focus on the enterprise.

CMS market share (builtwith.com)

5% of Alexa's Top Million sites run on Drupal

Drupal usage statistics (builtwith.com)

8.5% of the top 10k websites run on Drupal

With the release of Drupal 8, Drupal’s target audience started consolidating more towards the enterprise user. In the future Drupal’s success as a project will be tied more closely to performance against platforms like Adobe CMS and Sitecore in the marketplace.

React (and Javascript) take over the world

The thing about Javascript is that it’s been around forever (in tech terms) but recently has taken off. I won’t detail all the reasons here. Seth Brown from Lullabot has one of the best write-ups I have seen from a Drupal community perspective. In short, the ability now to run Javascript both in the browser and on the server (Node.js) has led the surge in Javascript development. Github shows us that more projects are built with Javascript than any other technology and Stack Overflow’s survey tells us that Javascript is the current language of choice.

Stack Overflow 2018 survey results

Javascript is the most popular language

Github projects 2018

2.3 million Javascript Github projects

Dries recognizes the importance of Javascript and has spoken about this recently at MIT. In a bit, we will look at some of Dries’ ideas for the future in relation to the Drupal project.

A few years ago we saw several Javascript frameworks pop up. These became very popular for single page applications (SPA) but also had broader appeal because they could make any website feel more interactive. React.js & Ember.js were both released in 2015 and Angular.js is older but has started getting more attention around the same time.

A big issue that needed to be solved with these frameworks was how to address SEO. Initially, these frameworks only rendered the page in the browser which meant site content was largely hidden from search engines. For SPA’s this was not necessarily a deal breaker but this limited the broader adoption of this technology.

Only fairly recently have we seen solutions that are able to use the same framework to serve pages both in the browser and on the server. Why do I bring this up? Because this has been one of the more difficult challenges and React.js addresses it better than any other framework. There are many reasons why React.js adoption is exploding but this is why I believe React is king.

The State of Javascript report from 2017 is often referenced to illustrate React’s popularity (see below):

survey respondents indicated that they have used and would use Javascript again - more than other technologies

John Hannah also has some great graphs on javascriptreport.com that demonstrate React’s dominance in this space (see below).

Npm downloads by technology (1 month)

React downloads (1 month) exceed angular and vue

Npm downloads by technology (1 year)

React downloads (1 year) exceed angular and vue

Finally it should be noted that Facebook’s technology, GraphQL paired with React.js is also on the rise and intertwined with the growth of this technology. GraphQL will come into play when we look at how CMSs are adapting to the surge in Javascript and Frontend frameworks.

React and the CMS

Is React compatible with CMSs of ‘ole (e.g. Wordpress, Drupal, etc.)? Well, yes and no. You can integrate React.js with a Drupal or Wordpress theme like you can many other technologies. In fact, it’s very likely that Drupal’s admin interface will run on React at some point in the future. There is already an effort underway by core maintainers to do so. Whether or not the admin will be fully decoupled is an open question. 

Another example of React admin integration is none other than Wordpress’ implementation of React.js to create the much anticipated Gutenberg WYSIWYG editor.

Gutenberg editor

screenshot of empty Gutenberg editor

In terms of websites in the wild using React with Drupal, there have been solutions out there (TWC, NBA, and others) for many years that use Drupal in a “progressively decoupled” way. The “progressive” approach will still exist as an option in years to come. Dries wrote about this recently in his blog post entitled “How to decouple Drupal in 2018.”

The problem I have with this type of solution is that sometimes you get the best (and worst) of both worlds trying to bolt on a Javascript framework onto a classic templating system. The truth is that Drupal’s templating theme layer is going to have trouble adapting to the new world we now live in (addressed in detail at Drupalcon’s “Farewell to Twig”). 

The real power of React is when you can combine it with GraphQL, React router and other pieces to create a highly performant, interactive experience that users will demand in years to come. To accomplish this type of app-like experience, developers are increasingly looking to API’s to address this dilemma, which we will examine next.

CMS as an API

The last couple of years there have been many Cloud CMS-as-an-API services pop up that have been generating some attention (Contentful might be the most popular). At this time it doesn’t appear that these API’s have disrupted market share for Wordpress & Drupal but they do signify a movement towards the idea of using a CMS as a content service. 

The “Decoupled” movement in the Drupal community (previously known as “Headless”) has been a big topic of conversation for a couple of years now. Mediacurrent’s own Matt Davis has helped organize two “Decoupled Days” events to help the Drupal community consolidate ideas and approaches. Projects like Contenta CMS have helped advance solutions around a decoupled architecture. Dries has also addressed Drupal’s progress towards an “API-first” approach recently on his blog.

While cloud services like Contentful are intriguing there is still no better content modeling tool that Drupal. Additionally, Drupal 8 is already well underway to support JSON API and GraphQL, with the potential to move those modules into core in the near future.

As I look at the landscape of the modern technology stack, I believe Drupal will flourish in the enterprise space as a strong content API paired with the leading Javascript Frontend. React & GraphQL have emerged as the leading candidates to be that Frontend of record.

Next, we will look at a relatively new entrant to the family, JAM stacks, and see where they fit in with Drupal (if at all?) in the future.

JAMStacks - The Silver Bullet?

The popularity of Netlify hosting and static generators has created some buzz in the Drupal community, particularly Gatsby.js, which we will examine in a moment.

Netlify provides some great tooling for static hosted sites and even offers its own cloud CMS. Mediacurrent actually hosts our own website (Mediacurrent.com) on Netlify. Mediacurrent.com runs on Jekyll which integrates with a Drupal 8 backend so we are well aware of some of the benefits and drawbacks of running a static site.

Where Drupal fits into the JAM stack is as the ‘A’ (for API), with ‘J’ being the Javascript Frontend (i.e. React) and ‘M’ being the statically generated markup. Back in 2016 we liked this idea and settled on Jekyll as the tool of choice for our rebuild as it was the most popular and well supported project at the time.

Since then Gatsby.js has risen dramatically in popularity and has a robust source plugin system that enables it to be used as a Frontend for many platforms including Drupal and Wordpress.

The creator of Gatsby, former Drupal developer Kyle Matthews recently spoke on the subject at Decoupled Days 2018. While it’s hard to know if JAM stacks like Gatsby having staying power in the years ahead they do have a lot of appeal in that they simplify many of the decoupled “hard problems” developers commonly run into. The question of scalability is an important one yet to be answered completely but the upside is tremendous. In a nutshell, Gatsby provides an amazingly performant, React/GraphQL solution that can pull in content from practically any source (including Drupal).

Do JAM stacks like Gatsby have staying power? Will these close the complexity gap that blocks more sites (large or not) from decoupling? We will have to stay tuned but the possibilities are intriguing.

Looking Ahead

We have examined the state of Drupal as a project, future release plans and how it is adapting towards a future that is “API First” that also fits well with the React world in which we now live. 

The main takeaway I would offer here is that Drupal, while still an amazing tool for managing content, is better suited as a technology paired with a leading Frontend like React. With the web evolving from monolithic systems to more of a services-type approach, it makes sense to use a best-in-class content modeling tool like Drupal with a best-in-class FE framework like React.js. 

What does that mean for the average Drupal developer? My advice to Drupal developers is to “Learn Javascript, deeply.” There is no time like the present to get more familiar with the latest and greatest technology including GraphQL.

For organizations evaluating Drupal, I do think the “Decoupled” approach should be strongly considered when planning your next redesign or build. That being said, it’s important to have an understanding of how the pieces fit together as well as the challenges and risk to any approach. This article attempts to present a high-level overview of the technology landscape and where it’s headed but every organization’s needs are unique. At Mediacurrent we work with clients to educate them on the best solution for their organization. 

Have questions or feedback? Hit me up at https://twitter.com/drupalninja/

Sep 20 2018
Sep 20

In his blog post outlining the roadmap to Drupal 9 published last week, Dries Buytaert states that “if you are on Drupal 8, you just have to keep your Drupal 8 site up-to-date and you'll be ready for Drupal 9.” The maturity of Drupal 8 and its solid upgrade path make this the time to migrate your site to Drupal 8.

We’re excited to announce that the Palantir team released a new Workbench module this month for Drupal 8 called Workbench Tabs. We have used this module to improve editorial usability on nearly all of our Drupal 8 projects, and it has been public on Github for a while now, but now it's available on Drupal.org!

What is Workbench?

Workbench is a suite of modules released by Palantir to help solve common editorial problems in Drupal. The core Workbench module is largely a collection of custom Views that create dashboards for content editors. Its widespread use by organizations in government, higher education, nonprofits, and media is a testament to the module suite, and its capabilities have been helping editorial teams manage workflows and permissions since Drupal 7.

What does Workbench Tabs do?

Workbench Tabs integrates local task tabs and Drupal messages into the Toolbar. What exactly does that mean?

  • Editorial usability is improved by placing the "Edit," "View," "Revisions," and "Delete" tabs in a consistent location
  • Custom themes don't need to place and style the local task tabs
  • Drupal messages will be separated from the content layout

++ to the Palantir team members that made this happen: Patrick, Ashley, Ken, Avi, and Bec.

Want to learn more about Workbench in Drupal 8? Drop us a line through our contact form, or reach out to us on Twitter @Palantir.

Sep 20 2018
Sep 20

Responsive images in PatternLab get a bit of a bad rap sometimes, because they are tricky to have in PL and Drupal. Here's my "easy way" of achieving it.

This came up today in the DrupalTwig Slack (join it). A user wanted to know how to use responsive images with the Emulsify Drupal theme. I don't use the Emulsify theme (yet - I will soon), though Four Kitchens, the geniuses who created it, have responsive images built in. Recently I created my own - simple and rudimentary, but it works a treat.

I first create a "Responsive Image" pattern. In this I have two files - responsive-image.twig and responsive-image.yml. Here's the contents:

responsive-image.twig:

<img srcset="{{ image_src_sets }}" sizes="{{ image_sizes }}" src="https://mark.ie/blog/web-development/responsive-images-patternlab-and-dr...{{ image_src }}">

responsive-image.yml:

image_src_sets:
  join():
    - 'https://placeimg.com/500/500/nature 500w, '
    - 'https://placeimg.com/1000/750/nature 1000w, '
    - 'https://placeimg.com/1440/475/nature 1440w'

image_sizes: '(max-width: 600px) 100vw, (max-width: 960px) 100vw'

image_src: ''https://placeimg.com/1440/475/nature'

To use it in another component, I just call a variable and set that variable in the YML file.

For example, to call the hero image as a responsive image in my event component, I'll print this: {{ hero_image }}. Then in my corresponding event.yml file, I'll define the hero_image item like so:

hero_image:
  join():
    - include():
        pattern: 'basic-elements-responsive-image'
        with:
          image_src_sets:
            join():
              - 'https://placeimg.com/600/600/tech 500w, '
              - 'https://placeimg.com/1200/360/nature 1000w'
         image_src: 'https://placeimg.com/1200/360/nature'

The {{ image_src }} variable is needed to provide a default fallback for browsers that don't support srcset or sizes, such as IE9/10/11.

Then in my Drupal template I just swap my image field variable for the responsive image one, like this:

{% if node.field_hero_image.value %}
  {% set hero_image: content.field_hero_image %}
{% endif %}
{% include ... usual path to component stuff ... %}

Drupal then renders the image field using whatever settings I have given it in Drupal - presumably responsive image ones.

This post might not help you if you are using Emulsify, but it might help others who stumble upon it.

Sep 20 2018
Sep 20
‌‌

"You want to enable your developers to easily deliver content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This is aligned with Drupal 8's roadmap, where we are focused on web services capabilities."

tweet this

Dries Buytaert

If you know Drupal, you HAVE to know Dries. He’s the founder of Drupal, CTO of Acquia, an excellent blogger and a Young global leader at the World Economic Forum.

Quoting him from one of his blogs where he was talking about why headless Drupal is gaining more and more popularity within organizations and how Drupal 8 is focusing on making it more efficient and easy to adopt -

“You want to enable your developers to easily deliver content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This is aligned with Drupal 8's roadmap, where we are focused on web services capabilities. Through Drupal's web service APIs, developers can build freely in different front-end technologies, such as Angular, React, Ember, and Swift, as well as Java and .NET. For developers, accomplishing this without the maintenance burden of a full Drupal site or the complexity of configuring standard Drupal to be decoupled is key.”

He also gives us some statistics on the adoption of Drupal 8 – “Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year.”

"You want to enable your developers to easily deliver content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This is aligned with Drupal 8's roadmap, where we are focused on web services capabilities."

tweet this
Sep 20 2018
Sep 20

One of our customers asked us how to integrate a calendar with events on their site.

The Calendar module is the most popular module in Drupal 7 with over 1 million downloads. Unfortunately, the module is still under development for Drupal 8.

Another option is the Full Calendar View module. This module is by far not as popular as Calendar, but it does its work well.

This tutorial will explain the usage of this module. Let’s start!

Step #1. Install and Enable the Module

  • Use your favorite method to install the module, The recommended way is using Composer.
  • Enable the module:

composer install drupal/fullcalendar_view

How to Integrate a Calendar in Drupal 8

Step #2. - Create the Content Types

For the purpose of this tutorial, you’ll be creating two content types for each of the two different types of events for a travel agency offering :

  • City tours by day.
  • City tours by night.
  • Click Structure > Content types > Add Content Type.
  • Create a Content type called "City tours by day".
  • Click Save and manage fields.

  • Click Add field.
  • Add the following fields:
    • Field ‘Start Date’Type: Date.
    • Label: Start date.
    • Date type: Date only (instead of Date and time).
    • Field ‘End Date’.
    • Type: Date.
    • Label: End date.
    • Date type: Date only (instead of Date and time).
    • Field ‘Description’.
    • Type: Text (plain).
    • Label: Description.
    • Maximum length: 255.
  • Repeat this process and create another Content type called "City tours by night".

Step #3. Create the Content

  • Click Content > Add content > City tours - day.
  • Give this node the name of "Tourist group green".
  • These group is going to take a 7-day tour.
  • The description text is "All included".

  • Create one more node of type City tours - day with the following values:
    • Title: Tourist group green - 1.
    • Length of this tour: 3 days.
    • Description: Beverages included.
  • Create one node of type City tours - night with the following values:
    • Title: tourist group black.
    • Length of this tour: 3 days.
    • Description: Non-alcoholic beverages.

Your content overview page should look like this:

Step #4. Create the Calendar View

  • Click Structure > Views > Add view.
  • Add a proper name for the view.
  • Show Content of type City tours - day.
  • Create a page.
  • The Display format will be Full Calendar Display.
  • Click Save and edit.

  • Go to the Filter Criteria section.
  • Click the drop-down caret besides the Add button, click Rearrange Remove the Content type: City tours - day criterion.
  • Click the Add button.
  • Search for the Content type filter criterion and select it.
  • Click Add and configure filter criteria.

  • Select Is one of and choose the relevant content types, including City tours - day.
  • Click Apply.

  • Click the Add button in the fields section.
  • Select the fields Start date, End date.
  • Leave the defaults.
  • Click the Settings link for the Calendar.

  • Map the fields for start and end date from your content types to the fields the calendar view is supposed to display.

  • Scroll down and open the legend colors section.
  • Choose the appropriate color for each Content type.

Notice also that you have the option to assign taxonomy fields to the content types. That way, you can select multiple colors for one content type.

  • Click Apply.

  • Save the view and go to its URL.

Congratulations! You have successfully created an event calendar for your Drupal site. It’s possible to move these elements by dragging and dropping. Just hold click and move them around. You can edit every element on the calendar by clicking it.

It’s possible to resize them too if they’re full-day events.

Summary

The "Full Calendar View" module lets you easily integrate a fully functional event calendar into your Drupal site.

Thanks for reading!


About the author

Jorge lived in Ecuador and Germany. Now he is back to his homeland Colombia. He spends his time translating from English and German to Spanish. He enjoys playing with Drupal and other Open Source Content Management Systems and technologies.
Sep 20 2018
Sep 20

by Elliot Christenson on September 20, 2018 - 1:07am

Drupal 8 was released on November 19, 2015 - nearly three years ago. The drastic architectural changes created a difficult upgrade path for those running Drupal 7. With the huge amount of investment in Drupal 7 over the previous 5 years, this set off shockwaves of fear across the Drupal ecosystem. Recently, Dries Buytaert, the project lead for Drupal, announced the planned launch of Drupal 9 in 2020. That signals the "End of Life" of Drupal 7 in November 2021. When do I need to upgrade?

By the way, that is more than ten years after the release of the first version of Drupal 7!

It's also the date of the "End of Life" of Drupal 8 (more on that later).

I'm On Drupal 7, So I Have to Upgrade to Drupal 8 by November 2021?

If you aren't getting support from a company doing long-term support for Drupal 7, then you'll actually need to upgrade to Drupal 9!

PHP versions, Symfony versions, and other software roadmaps necessary to keep your website running safely and securely can be confusing and complicated to follow! If you don't, Dries's announcement might be causing you some renewed anxiety. After all, you had three years to upgrade your Drupal 7 site to the shiny new Drupal 8 codebase. If you couldn't do it in the previous three years, why would you be able to over the next three years? That answer is complicated - and depends on your site!

So If I Upgrade to Drupal 8 Today, I Have to Upgrade to Drupal 9 by November 2021?

Maybe, but that's not nearly as bad as it sounds. :)

The secret of D9 is that it's really just the next iteration of D8 - it's not going to be a complete rewrite like D8 or D7 or earlier major versions were.

The plan is that it's going to drop deprecated APIs, and update 3rd party dependencies (like Symfony) - and not much else. In fact, the goal is to allow contrib modules that don't use any deprecated API to be compatible with both D8 and D9, without needing to have two separate versions of the contrib module (like we have always done in the past).

Upgrading from Drupal 8 to Drupal 9 will be more like upgrading from Drupal 8.5 to 8.6.

So I Never Have to Upgrade to Drupal 8 or Drupal 9?

Well...

We've been providing Drupal 6 Long-Term support for over 2 years (as one of the two vendors officially blessed by the Drupal Security Team), and I think we've proven that commercial Long-Term Support works! We've made dozens of security releases, and kept hundreds of sites support and maintained, and plan to continue to do so for a while.

We're even working on getting Drupal 6 core and popular contrib modules updated to run on PHP 7.2. :-)

So, if you don't update to Drupal 8 or Drupal 9, we're going to provide Drupal 7 Long-Term Support (just like we've been doing for Drupal 6).

But if you don't plan to purchase Long-Term Support from us or another vendor, then you really should plan your upgrade by November 2021.

Is Drupal 7 Dead Already? Be Honest!

The Drupal Community has committed to getting Drupal 7 to work on the newer versions of PHP through November 2021. Drupal 7 needs adjustments to completely work with PHP 7.2. Since the earlier versions of PHP are all being "End of Life" as well, this is a necessary step to keep your Drupal 7 site safe and secure. PHP is the programming language Drupal is built on, so changes in PHP have massive effects on what happens with Drupal! If all of that sounds a little familiar, it's because myDropWizard announced recently that we would update Drupal 6 to make it compatible with PHP 7!

Drupal 7 is far from dead.

How Hard Is it Move to Drupal 9 (from Drupal 6 or 7)?

Since Drupal 9 is going to be so similar to Drupal 8, moving to Drupal 9 (from Drupal 6 or 7) should be pretty much the exactly same as upgrading to Drupal 8.

The changes announced shouldn't make life any harder for anyone who's already on track to update to Drupal 8 before November 2021!

OK, So How Hard Is It to Move to Drupal 8 or 9?

It is significantly easier and more practical to move to Drupal 8 in 2018 than it was in 2015. Many of the best modules have gotten incorporated into Drupal Core, still others have been obsoleted by new and better ways of doing things, and the rest have largely gotten updates to Drupal 8 compatibility! The Drupal 8 ecosystem is now really great, and myDropWizard is committed to Drupal 8 as well as Drupal 7. We built our Roundearth platform on the modern Drupal 8 Core!

So, your needed features are probably now available in Drupal 8 - even if they weren't at launch in 2015. However, what's also amazingly improved is the upgrade path. For simple sites, it's phenomenally simple to move your content from Drupal 7 to Drupal 8. Your mileage may vary with more complex sites, but the good news is that there's no reason to suspect that the upgrade path from Drupal 7 to Drupal 9 will get worse. It will likely get better.

That said, upgrading to Drupal 8 (or 9) is still a big investment, so we fully understand that some organizations won't be able to manage it in time, and that's why we plan to provide Drupal 7 Long-Term Support.

So, Why Are We Moving Beyond Drupal 8 Already?

Unlike the move from Drupal 6 to Drupal 7 and then again to Drupal 8 - which required massive re-engineering of legacy websites, the plan for Drupal 9 is to be 100% compatible with the latest released version of Drupal 8. Drupal 9 will simply drop support for modules that weren't following up-to-date standards of that latest Drupal 8 version. So, in many cases, the same module code will work in Drupal 8 and Drupal 9 for a good amount of time. The focus on backward and forward compatibility was a lesson learned by the entire Drupal community.

The planned major version jump from Drupal 8 to Drupal 9 is because the Symfony 3 PHP framework that lies at the core of Drupal 8 is itself moving on to newer versions. Like Drupal 7, Drupal 8's "End of Life" is also scheduled for November 2021. It's this last part that made many people nervous! The pending "End of Life" for Drupal 8 so soon after they spent so much effort upgrading is sure to fill anyone with anxiety. The plans to update seem sound, and the timing seems appropriate, so that should help calm some of the fears.

What's the Short Answer? When Should I Upgrade?

  • Drupal 6? You should already upgrade if you don't have D6LTS. We've been has been providing Drupal 6 Long-Term Support (and will continue to do so for the forseeable future :-)
  • Drupal 7? You should make plans to upgrade by November 2021 - or make sure you have D7LTS engaged before then.
  • Drupal 8? You should make plans to upgrade by November 2021 - but that should be easy! Upgrading from Drupal 8 to Drupal 9 will be more like upgrading from Drupal 8.5 to Drupal 8.6. By this time Drupal 9 should have been out for about a year.

There are all sorts of reasons why organizations don't update to the latest software - most of it boils down to budget. Small organizations with simple sites can't afford thousands of dollars to upgrade to the latest version of Drupal. Large organizations with comparatively complex sites can't always afford the expense of every upgrade either.

Sep 19 2018
Sep 19

The aim of this is to give European citizens more control over their personal data and to update the laws to reflect the world we live in now. This includes laws around personal data and privacy and consent across Europe.

With GDPR organizations will have to ensure personal data is gathered legally and under strict conditions. Organizations will also be tasked with protecting it from misuse and exploitation, as well as to respect the rights of data owners. This will ultimately place legal obligations on a company to maintain records of personal data and how it is used, placing higher level of legal liability should they be breached.

What is considered personal data?

Whether you’re based in Europe or a global organization that is potentially collecting data from European users you should be aware of the data you’re collecting that fall under the scope of GDPR. Under existing legislation names, addresses, and photos are considered personal data but with GDPR this extends to IP addresses, genetic data, and biometric data which could be processed to uniquely identify an individual.

How can I update my site to comply?

There are plenty of checklists to follow in order to make sure your site is in compliance but we’re going to cover a change you’ve probably already noticed from many of the sites you visit daily. You’ve probably already guessed it, those wonderful cookie acceptance pop-ups!

There are a few modules that strive to make short work of the cookie acceptance process but after testing several, the module I’ve found to be the best in terms of ease of use and support from other modules that create cookies is EU Cookie Compliance  (available for Drupal 7 and 8). This module will provide you with a fully customizable banner that can be displayed at the top or bottom of the window and has full support for responsive and multilingual sites. Consent can be given actively by opt-in or out-out, or inferred automatically by clicking any link on the site. I recommend going with the opt-in option. Optionally you will be able to use this in conjunction with the GeoIP module to display the banner for EU users only.

Before we get the module downloaded and installed you’ll want to identify any other modules that currently set cookies for users on your site and make sure they are updated to the latest release. The most common of these is going to be Google Analytics. There was a bug recently where if a user had previously accepted but had returned and revoked consent the cookie would incorrectly remain, so you’ll want to make sure that one is updated.

Setup

First you’ll want to create a privacy policy for you site which you can later link in your banner.

Download and enable the module from either https://www.drupal.org/project/eu_cookie_compliance or with drush or composer.

- Drush

drush dl eu_cookie_compliance

- Composer

composer require drupal/eu_cookie_complaince

Head over to /admin/settings/eu-cookie-compliance on drupal 7 or /admin/config/system/eu-cookie-compliance on Drupal 8 to setup permissions for displaying the pop-up to certain roles and select the type of consent, for your site to be complaint you will want to use the “opt-in”.

Cookie Compliance

Customize your banner, You can setup the text you want displayed for the initial banner, thank you banner, and withdraw consent banner. You will also be able enter hex values to colour your banner or if you’re on Drupal 7 you can use the colorpicker module to style your banner.

Cookie Complaince

If you’d like to limit the banner to EU users you can download and install GeoIP, once you have GeoIP setup you can simply enable the option on the admin page.

If you  are using Google Analytic you will find a setting on their page that once enabled will only place cookies when the user has accepted.

Once you’ve filled out everything simply save and head to the front page, you will be greeted by you brand new consent banner.

Cookie Consent

For developers who have created modules that set cookies there is a javascript function that will return TRUE if the user has given his consent

Drupal.eu_cookie_compliance.hasAgreed()
Sep 19 2018
Sep 19

Gartner recently released an interesting tech note discussing how automated business processes and online integration and transformation of business workflow should be a focus for businesses. By 2022, 50% of digital business technology platform projects will connect events to business outcomes using event-driven intelligent business process management suite (iBPMS)-oriented frameworks - here is a link to the Gartner article.

More than 80% of organizations believe digital transformation is important or very important and 75% say process automation is a must do in business.i Forrester agrees, saying process improvement is required for digital transformation and improving customer experience. Digital technology innovations in the workflow resource ecosystem have already been applied to automate many core business processes. According to AIIM, the top processes being automated include: 

  • Accounts Payable/Accounts Receivable 
  • HR, Recruiting, On-Boarding 
  • Contract Management 
  • Records Management 
  • Legal 
  • Technical Documentation 

A number of these top processes are managed or have involvement of the Human Resources or HR department. The HR departments have a lot of document centric business processes that involve communications or actions by other employees. Human resource management is an essential part of every company. Whether it’s hiring new employees, training, or ensuring that local labor laws are complied with, HR processes are a vital part of every company.

But HR has usually been thought of as a highly manual department process. They are used to rolling up their sleeves and getting the job done themselves. But all that’s changing and they can take advantage of available solutions to optimize these processes and improve the over all process and communications. At the same time, these solutions automate the management of online records and reporting of metrics such as:

  • How long does a process take or specific tasks
  • Were are the typical bottlenecks - one may assume they know but online metrics are very useful for management
  • How many requests do we get a week, month


Onboarding

Employee onboarding is known to be one of the most manual HR processes. It includes collecting documents for verification, giving them network access, setting up or ordering hardware and application access, etc. But all of this can be done automatically, using an online workflow solution.

The automated process ensures that there’s an easy checklist that can be verified by both the human resource management staff, the new employee, and anyone else that is part of the employee onboarding process. Using this, documents can be collected electronically, devices can be delivered without needing to wait around until IT staff arrive, and tool access takes hours, not weeks.

Solution:

  • Online self-service form allows management or HR personnel to submit onboarding requests.
  • Intuitive form design and workflow design interfaces allow customization of documents and processes to enterprise need.
  • Workflows can be tailored to job type, and can specify stakeholders necessary at each stage of onboarding process.
  • Onboarding requests are automatically routed for proper review and approval.
  • Orientation and training sessions can be orchestrated via the workflow, including notification/reminders to attendees.
  • New hires can be automatically sent a packet of orientation materials.
  • Online orientation forms can be included allowing new employees to submit necessary onboarding documents such as agreements, disclosures, benefit applications, etc.

Benefits:

  • Reduction in manual paperwork reduces errors and delays, driving sizable time and costs savings for the enterprise.
  • HR accelerates response times and new hire processing, building goodwill with all stakeholders.
  • Centralized tracking and reporting allows HR to have real-time overview of all onboarding workflows.
  • Workflows are automatically archived and accessible for auditing.
  • E-signature integration standardizes secure approvals.

An example of a onboarding workflow that's been created using the Nextide Maestro workflow solution for Drupal is shown below. The process is launched by the hiring manager and passes through two levels of approval. There are interactive review tasks that will automatically route the process back to the hiring manager. Comments can be collected and task assignment determined automatically via lookups of the company organization information in a database or LDAP directory.

The solution can definitely improve tracking and reduce email and simultaneously, improve visibility and management of a critical process that can make all the difference to a new employee's first day.

HR Onboarding workflow

Once the request is approved, parallel tasks can be launched which make requests to different departments to complete the new employee onboarding request. The workflow can handle processes with dependencies and unique business rules. Example, it's easy to determine if hardware is required from the submitted form and if needed submit a request to purchasing. If needed, there could be a separate sub-workflow for purchasing approval, if the request included special hardware or costs exceed a threshold amount.

The process can include sending of a new hire package to the employee, sending an introduction email to the department or sending out a welcome email on the employees first day. Any other custom communications or reminders to the new employee or stake holders can be automated at various stages of the workflow automatically.

The process stakeholders can easily see where in the process the request is by exploring the request details which include a status bar which highlights the request's current stage in the workflow. Additionally, Maestro keeps track of the time the task was assigned, when it was first clicked on by the task owner and when it was completed. These metrics are available for custom reporting and tracking.

Read more about our recent release and features including information about our demo site that's built to show case an online insurance quote process - Maestro 2.1 Release and Demo Site.

Nextide’s expertise is aimed at helping clients automate these manual systems. Our initial approach with clients is always to see if we can fix what is in place today. It can be that simple and inexpensive. A 5 minute conversation with a Nextide consultant can quickly determine if we can be of assistance.

Contact Us

i Forrester 2018 White paper

Sep 19 2018
Sep 19

Your browser does not support the audio element. TEN7-Podcast-Ep-039-Drew_Gorton.mp3

Today, it is our privilege to be talking with Drew Gorton, Director of Developer Relations at Pantheon and long time web veteran.

Here's what we're discussing in this podcast:

  • Drew's history
  • Cherishing our kids
  • What is Prairie High School
  • Going to St. Olaf College
  • How to choose a college major or not
  • Teaching English in Japan
  • Learning to swim and function in an unknown culture
  • Starting a tech career in Japan of all places
  • Building world cultural exchange with websites
  • Building Gorton Studios
  • Access a database? We don't need no stinkin' ticket!
  • Contributing Backup and Migrate Drupal modules
  • NodeSquirrel
  • Becoming a part of the Pantheon family
  • The joy of leading wonderful teams
  • The joy of cooking
  • The nerd and his love of science fiction

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 am your host Ivan Stegic. In this episode of the Podcast, Drew Gorton, Director of Developer Relations at Pantheon. Drew’s been involved with the web in some capacity, going back to 1996, while teaching English in Japan. He started Gorton Studios here in Minneapolis in 2001, and then in 2015 their product NodeSquirrel was acquired by Pantheon, where he now leads their Developer Relations team. I’m so glad to be able to call him a colleague, a fellow Drupaler and a friend. Drew, it’s my pleasure to welcome you to the Podcast.

DREW GORTON: Wow! It’s my honor as well. You dug into the history vault for that one. I don’t think I have a Wikipedia with me today. How did you come up with all of that? (laughing) All true?

IVAN: (laughing). It’s all true. Well, I kind of looked at your LinkedIn profile, to be honest.

DREW: Oh right! I suppose I probably have some information on there. Alright. (laughing)

IVAN: (laughing) Well, let’s start at the beginning. The beginning of Drew Gorton. So, where did you grow up?

DREW: I grew up in Southeast Wisconsin. So, between Milwaukee and Chicago. It’s a town called Racine and it’s about 80-90-100,000, somewhere in there. My parents still live in the house I grew up in. I was there through high school and that’s kind of poignant for me, because we’ve talked about this before, but, I now have two high school aged children. One of whom is a senior this year, and I’m very aware of the fact that after I left for college, I never went back home again to live. This is one of the things, as a parent who enjoys his adult sons, realizing like “whoa, wait, I might have limited amount of time with them.” But, yea, I came up here, into the Minneapolis area for school, and then after graduating, lived abroad for a while, and did some other things, but then came back and settled down. I’ve basically been in Minneapolis for twentyish years and doing web and Drupalee things for much of it.

IVAN: I know how you feel with the adult kids and leaving home. Interesting to think that once you leave, it’s still in your brain somehow, but you never really think about going back, and now the opposite is happening. It really teaches you to cherish those moments with those adults and kids.

DREW: Indeed.

IVAN: Now on your LinkedIn profile, it said you went to the Prairie School. What is the Prairie School? (laughing)

DREW: Wow! You did dig. Yea, that was the high school I graduated from, Racine. So, Racine is big enough to have a few high schools, so they have three of them. Prairie is a college prep school. It was actually a really good change for me. I went to where I grew up, actually was kind of on a boundary that kept changing. So, I never went to a school for more than two years before transferring over to Prairie. As a kid I was actually not terribly well adjusted to social niceties. I didn’t get other kids. So, basically that means that and the frequent switching of schools, meant I was a pretty isolated kid, and I was doing really badly in school. Despite having all sorts of potential and doing well on standardized tests and things like that, I was kind of feeling output and a bit of a discipline problem. So my parents decided a change was needed, and they packed me off to the college prep school, and it was a pretty fantastic change. I really was glad they did that. I don’t know what bridge I’d be living under if I hadn’t had that big change there. (laughing) Probably not a bridge, but, yea, it was a good change. So, Prairie’s a small college prep school in Racine. So, I graduate glass of thirtyish kids.

IVAN: You’re a liberal arts graduate. You started a web company. You sold a product company. Now you lead a group of engineers. So, tell me about your time at St. Olaf. What did you come out thinking you would actually be doing?

DREW: So, I went to college thinking I was going to become an architect. I was intent on studying math and physics as an undergrad, and then going and doing architecture essentially post-grad. By the end of my freshman year I was convinced that physics sucked. Looking back, I’m aware now that that was just really a couple of bad profs, basically. The teaching was not great, and at the time, what I knew was, this is not interesting, I don’t know why I used to like this, it’s just really boring. And, these other classes that I’m taking are pretty exciting and interesting, and I’m really getting into them. That was enough to push me out of physics, and then that started a slow evolution that, actually in my senior year ended with me totally flipping my majors around to Spanish and religion with effectively a minor in math. I needed like two more classes to have a triple major, but I decided not to kill myself. That was part of what I was actually up to. I kept a math major all the way through because I thought, basically, well, math is employable somehow, probably. Right? I don’t think I can pull that off with a philosophy degree. In my senior year I just decided, “No, it’s fine.” I was in a seminar about fractal and chaos theory, which I really enjoyed, but it didn’t have a lot to do with bookkeeping, and I just decided if I’m really holding onto this with majors in an attempt to be employable, I’ll move up four semesters past the point where any business is going to care about this, and so, I’ll just go do the things I’m having fun with. So, I ended up with the philosophy and religion degree, and Spanish. The love of Spanish happened actually also from my time at Prairie, is when it started. My senior year at Prairie I had a friend who was an exchange student, and I actually got to be good friend with him. And at the end of my senior year, I actually went to visit him in Spain for about a month, and it was really an impactful visit, and it really turned Spanish from being a class that I would joke around in and not really do very well in, in high school, to something that I really, really enjoyed, because I was happy to get to interact with people in this hitherto, you just be like kind of purposeless thing in my mind, but all of a sudden it opened up the ability to communicate with the family and the friends and all of the people. When I started college, I knew I actually wanted to continue doing Spanish and maybe study abroad. And, I did all those things. And, I did it enough that my major was right there, as I was contemplating “what do I want to do? I need to graduate soon. What are the majors I want to do?” And, Spanish was one of the choices.

IVAN: So, are you bilingual or trilingual? Because I know you taught English in Japan, and we’ve talked about Japan in the past, you and I. But, I don’t recall.

DREW: Yea. So, those are tricky things to claim. My English is better than both of them. My Spanish is pretty good. At one point in time I would’ve been able to have a conversation like this at the natural speed in Spanish, and I possibly could still do that. Although, I’m sure there’d be words I’d search for, and every so often I get into a new situation where I do speak Spanish, and that happens, but I can usually just explain around it and be like, “What’s the word for forehead? You know, the thing that’s above your eyes and below your hair? What’s that thing called?” You know, I can say those kinds of things. (laughing) My Japanese used to be quite good as well. I went from no Japanese on arrival in Japan, to being able to do things like lease a car and sign an agreement, and certainly, obviously, live there. We were there for three years and just lived in a professional society and do all of the things that you need to do to survive and thrive in a different environment. But, my written and reading of Japanese, is not nearly as good. Japanese is a hard language to truly master. There’s a ranking system, like an official Japanese government, like your level of proficiency in Japanese, and it’s got four levels and wow, I think I’m a three. One is like, University Professor, can really be incredibly articulate and read and write, and a lot of the focus is on reading and writing. And, basically, my level of Japanese is conversational, like, this person can live in Japan and read a newspaper article and converse, but they’re not going to write a paper. A research paper in Japanese would’ve been out of my grip at the time and like nowadays I look back. I got notes I would take in Japanese, every so often actually we moved houses two or three years ago, and I had occasion to look back and discover a notebook that I had written, and seeing your own handwriting and being like “what in God’s name?” (laughing) I was like “oh, man”. I mean I obviously knew this at one point in time, but I really have to struggle to figure out what I wrote down. Like recipes for example, like talking with friends, got recipes, like, wow, ok, is that chicken or is that pork? (laughing) Yea

IVAN: It must’ve been fascinating to immerse yourself in a completely unknown culture and society, and then have to learn how to swim and function?

DREW: Yea. It was an awesome opportunity, and it definitely shaped a lot of who I am today. I know that for a fact. It’s hard to know exactly how that happened. You know, like to isolate the specific things, but I know that at the point in which I left for Japan, I had, at that point in time, lived in Spain. I spent basically a year in Spain, and so had some level of familiarity with “Ok, it’s different, but, it’s also kind of the same. We’re all just people, we like to eat food, some people are nice, some people aren’t. Going to Japan was an additional level of that. Between Spain and Europe in general, and the United States, there’s a lot of shared, cultural, kinds of influences. So, historically, Europe is dominated by Christianity for example. A lot of that is here present in the United States, and so there are just cultural touchpoints and understandings and such that are Judeo Christian in background. Whereas, you go to Japan, and it’s very different. You don’t have that. That’s just a completely different world view. At the same time, we all like to eat, some people are nice, some people are less nice, some people are welcome with strangers, some people aren’t, so. There are a lot of commonalities again, but, there was enough differences that it also just gave me a cleaner understanding of what it is to be human, in a way that you can see through a few more layers and realize just how much each of us is a product of the stories we tell and the civilizations we celebrate and the histories that we remember and share.

IVAN: And you taught English there, and you weren’t there alone, were you?

DREW: That’s right. Yes. I was there for three years. I taught English in a high school. I was fortunate enough to be in a high school that was considered one of the better high schools in the area. So, I had kids who were motivated to learn and engage in the classroom, and that’s a great situation to be in as a teacher. But, then I was there with my wife as well. We had both lived individually, separately, in different countries. I got married soon after college. I lived in Spain, she lived, at the time, in Czechoslovakia, but currently Czech Republic. We had these amazing experiences, and we felt, ”I learned a lot while I was there, you learned a lot when you were there. You have all these stories. I have all these stories. What if we did something together?” About a year after being married, both of us were in jobs, that we're, paying the rent, but not terribly interesting and we decided, well, now is the time to do it. We actually looked to Latin America, primarily, as the place to go. She has four brothers and sisters, five total, who had all been born in either Venezuela or Mexico, because her parents had lived there for, I think, 17 years or 20 years -- a long time, in combination of those two countries, as American ex-pats. So, she grew up with all the stories of Mexico and Venezuela and some light Spanish being spoken in the house and used for household terms. So, there was again, with both of us, there was a touchstone to Spanish. However, Latin America was not a place either of us had lived before, and we decided “well, let’s go try and figure out what we can do. Latin America will be new for both of us, but also, it feels like it’s also something nearby to both of us.” And, we ended up looking around to these things and applied to something called the JET Program (Japanese Exchange Teaching Program), on a fluke basically. Someone said “Oh, well hey, while you’re looking at things international, there’s this one thing, you could fill out the paperwork.” We were like “Japan, that’s weird. Ok. Alright, it’ll be good for the experience, right?” So, we filled out the paperwork, wrote the essays – whatever the things were – and then kind of forgot about it. And like two or three months later they followed up with us. We got a letter. It was like “Hey, I really loved your applications. You should come to Chicago to interview at the Consulate.” We’re like “Japan? Chicago? I don’t want to go to Chicago.” (laughing) “Wait”. And I’m like “Your sister is in Chicago. She’s kind of fun, we can go hang out with her and like we’ll spend the weekend, we’ll do that, and then maybe we’ll do this thing, and then we’ll just come back and whatever.” We’re like “it’ll be a good experience.” So, then we went, we went to the Consulate, we had this fun weekend, and then again, like two or three months later, we kind of forgot about it, and then they wrote, and they said, “we would like to send you to Japan.” We’re like “Um, really!” (laughing) Then we just, again, kind of went with it. Like “Well, okay. It can’t be that bad, right? It should be fun. We can do anything for a year, right?” So, we went for a one-year contract and then it was renewable after three years and we did that. Went through for three years. Three years turned out to be a natural breakpoint, just because of the way the Visa system works. We could have stayed longer, but it was just getting to a natural endpoint, and we looked around and saw other ex-patriots there, and we saw that it was basically three years, another cut off at seven years and you know, then you’re there for life. We were kind of thinking maybe we’d start a family and things like that. So, it was a hard decision at the time, but it was also a good decision. So, we came back, in Minneapolis, basically ever since.

IVAN: While you were in Japan, were you thinking about, or were you involved in the tech scene in any way? Or, did that come after you got back to the United States?

DREW: It started in Japan, actually. I graduated from college in 1994, and, one of the guys I lived with at the time in 1994, got really excited about the web, and he told me, he took me aside and said, “Hey Drew, I think you’d really like this.” His name was Ted, a successful electrical engineer. He helps design chips these days. He took me aside and he was like, “Drew I think you’d really like this.” I remember he showed me the screen and he said, “hey, look at this, you could find things all around the world.” I remember being totally not impressed. I was like “Ted, that’s super nerdy. Let’s go have a beer.” (laughing) And like, thinking like, “whatever, we’re playing cards. Come on. Join us.” I think I talked him into it. He was like “no, you’ll really like this.” I was like “Ted, I’m sure I would. Have a beer.” Then I went and lived in Japan and that was an isolating experience. That was 1995 to 1998. At the same time, the web was starting to grow, and actually, probably in 1996, I realized I’m using email to keep in touch with my family. These things are emergent and real and new patterns. I started wanting to give those same opportunities to my kids, the kids I was teaching, and so I started studying email exchanges with students who were also learning English in different countries. So, Scandinavia, and then also we ended up with kids in Northern Ireland we were communicating with, who, obviously spoke English quite well. Then the next extension of that was, “Hey, what if we could create little pages about ourselves, and post a picture, and put something together, and use that and just get a little bit more of a sense of who these other people are.” So, we started doing that back and forth, again, with the students in these different countries. It was just transformational. It was like, I could see the same exchange happen for my students that happened for me when I lived in Spain. I thought “this is real. I’m talking to someone who’s actually very real.” I see their face. I see that person. They’re really huge. I want to communicate with that person and put a little extra effort into it. Now, English was not a subject you needed to take to pass a test in order to get into a good university. It was those things, yes, but also actually this really cool thing -- you could learn in order to communicate with somebody impossibly far away. The world has really shrunk a lot in the last twenty years. Talking about this now it sounds incredibly old timery, in like, my kids don’t have a sense of this at all. But at the time it was just really eye opening to me, and I knew that I wanted to be involved with this technology, basically, right away. I was like “well, I’m teaching here, this is good.” When I came back, I knew I wanted to be involved with web stuff. What that meant. How you do that – I didn’t know. But, I saw it as a technology that was fundamentally transformable, and it was powerful, and there are philosophically a number of things that were really attractive to me. The freedom to interact with people around the world regardless of what you look like; what language you might speak, although you need at least a common one; what your belief structure is; your gender. All of those things can be stripped away, and you could interact with folks everywhere. That’s transformative. And, still, we’re not done yet. We’re still in the early days of the web, but it is a fundamental building block in building a world culture, basically. Like this is still transforming the way that we think and identify ourselves, and, while there are all sorts of instances of people doing not so great things with these tools, fundamentally, I think it continues to be a transformative power for the good.

IVAN: I agree with that, and I hope it continues to do that. It’s always been an ideal. I remember when the web started. I was in high school and in South Africa and we were completely isolated, and we just started becoming reintegrated into the world, and at the same time the internet was starting to connect us. I remember being overjoyed with the idea that I could connect on this level playing field, with everybody else. I still believe, and I think you do too, that this is something that will transform our world and our culture. It’s had a little bit of bad press lately, the last few years (laughing), but I think we both still believe in the ideal that maybe this is just a bump in the road.

DREW: Well, I do believe that. I think it was perhaps a naïve, sort of, my own like “Wow, I’m connecting with people.” But, there are many people who grow up and are in environments that push them towards extremism and have situations that are way less privileged than mine. So, it is changing the world. We are becoming a worldwide civilization. It turns out there are a lot of people with strikingly different ideas for what good is, and what should we be doing. And so, there are some pretty horrendous activities that happen in the name of what presumably people think are the right things to do. But, still fundamentally, we are so much more connected today, and we’re starting to learn more about each other, and that’s not without friction for sure. I guess, overall, fundamentally, I believe that that friction is probably a necessary part of learning about each other.

IVAN: And, I think as it matures, and as we learn about those frictions, we can learn to adapt to them. And my hope is that ultimately, we evolve past all of the trouble and past all of the issues that we have. So, you landed in Minneapolis. You chose Minneapolis, and you immediately founded Gorton Studios. Or, was there an interim period?

DREW: There was an interim period there, yes. What we immediately did was, we both earned a pretty nice salary while we were in Japan, we were able to use that to pay off student debts, which was great, came back and had some money saved, And then had actually paid into the equivalent of social security in Japan. When you leave Japan, and say like, thank you I’ve paid in social security, can I have that money back? They say “Yes”. That’s very kind of them. I don’t know that other countries do that. So, you file some paperwork, and then you get a nice big, lump sum. Anyway, we went back. My wife’s parents live in Minneapolis. We lived in their basement. Low rent. Would do things like make meals together and play cards every night. After six months, all of a sudden, we realized money is running short, and we didn’t have jobs. We knew we would take awhile to let our heads clear, after being abroad for so long. And, then, came back and again, like six months later, realized “Oh, we can’t stay retired forever. We should do something.” (laughing) Which was really a bummer. Retirement was great! I liked it. So, both of us actually went back to jobs we had been doing before. At the time for me, that meant going back to the insurance company I had been working for, where I did tech support. I told them “look, I’ll do tech support. This is fine. I don’t want to do this long-term. What I really want to do is this web stuff. However, all of the docs are web documents. So, I ended up taking over internal websites and then did that for about a year, to the point where I could legitimately call myself, “Alright, I’m actually pretty good with this stuff.” I was troubleshooting it for other people and, again, maintaining a pretty large site, without the advantages of things like PHP and maintaining a site by hand that had 5,000 pages of it. It was just like our internal help documentation.

IVAN: Service (inaudible) are your friends at that point.

DREW: It couldn’t have been there, but I don’t think we used them at all. It was like the header, and you got 100 docs that have 5 links to the top and somewhere along the way you copy/pasted the wrong header, and now you’ve got like 600 docs that have a (laughing) slightly different version, footer, and everything else. Oh yea, it was a beautiful way to learn that you don’t manage this by hand. So, then I went from there to a web development job at a dotcom startup, and that lasted about a year. I really enjoyed some of the people I worked with and the work we were doing. We were doing, what we were calling it at the time, webcasting, which was taking television feeds and putting them online using RealPlayer.

IVAN: RealPlayer. Wow!

DREW: We were using RealPlayer, and I think the Windows Media was maybe out in some format at that point. But we used RealPlayer and at least one other one. We also had some custom stuff that allowed us to basically advance slides for recorded versions. So, at the time it was like a ways ahead of things. But, we never had a repeat customer. It was very clear, to me, that it was not worth what we were selling it for. I went independent. I’d been moonlighting at the time, and then that just really took off. I went independent in 2001, I remember incorporating January 2001, and essentially it worked out, despite the fact that the dotcom crash and other things happened in short succession there, but I had enough clients lined up and enough savings, and other things. There were some dark years in there, where I worked many, many, many, many, long hours and, but made it. The lean years were probably done within three or four, and then I was able to start growing a team; had an awesome team, with folks such as Lynn Winter on it. Lynn was probably with us for eight, maybe even longer, years. Before that she was a client. I was really blessed to have an awesome team of people who incredibly stuck around for a long time, and just really great quality people.

IVAN: Yea, Gorton Studios existed for about 14 years, and I think you guys made some significant contributions to Drupal and to the Drupal community. Most notably, I think, Backup in Migrate. Right? Like, that’s one of the top 10 modules of all time that Drupal uses, and that was something you and Ronin created. I’m going to go out on the limb here and say you wrote some of the initial code with Ronin? Or, Ronin wrote some of the initial code with you? Basically, this was your baby?

DREW: Yea. It was much more Ronin’s baby than mine. I contributed small bits, and like any open source thing, it started out as a scratch, you have an itch. We were dealing with a host at the time, there was no access to the database, unless you filed a support ticket, and if they weren’t prompt about getting back to you, you were like, “Hey, I guess I can’t work with the production data, which I kind of need in order to duplicate this thing, so I can build the next thing, whatever it is.” And, like one day while noodling this over and being really frustrated, I think Ronin and I were kind of maybe batting this around out loud, and essentially realized, “You know actually does have read and write access to this database? Drupal. Drupal itself. We don’t need no stinkin' file system, filing some stinkin' ticket. We’ll just write a thing that allows us to actually just grab all the stuff.” So, the first version of Backup and Migrate was an internal tool only, and we called it DB Dump. It was really straightforward, and then we used to grab all the things and then we added like, “Oh, actually what we don’t want is like cache, and stuff like that, so we had to exclude these things, and then over time we realized, actually we even got some clients, we got like all the zip codes in the United States. So rather than just defaulting to exclude cache, how about we interface to be able to exclude other tables like that. If you don’t need 50 megs of zip codes, or whatever it was, on every single DB dump that you want, go ahead and exclude those. So, that was absolutely it. Then, we realized over time, actually I wonder, this could be a tool, a better thought was this could be a tool to move back and forth between environments. Then we decided, “You know, we should contribute this back. I don’t’ know if anybody else wanted this thing, but maybe somebody else has a crappy situation and then contributed it back. It was early enough, and enough other people had this particular pain point for ease of moving things back and forth, that it really took off. Then, once it’s popular…

IVAN: …then you have to maintain it.

DREW: Yea, you have to maintain it, absolutely have to maintain it. But, we also saw it as a way to give back. We, at the time, were working a lot with Drupal and felt like it was providing just a tremendous amount of value to us, and it was like just trying to be an open source citizen basically. There’s so much that we’re getting from this platform from this community, we’re just going to toss them this one little tiny thing. We tried to toss it more than one little tiny thing. There were other things that we contributed in time, and money & other things. It was definitely a concrete example of “Let’s try and give something back,” which is probably 5% of the value if you were to somehow quantify everything that we got out of Drupal. It would be fractional, but we were devoted to giving back, not nothing, but again, it just felt like a good citizenships kind of thing initially. Then, people say appreciative things and that becomes its own, sort of, reason to continue. People say, “this is an awesome module.” You’re like “really? You’ve heard of my module? That’s crazy.” Then you hear that a bunch of times and you’re like “oh, well, that’s pretty cool. I like it when people like me. Maybe I’ll keep working on it.”

 IVAN: I remember using Backup and Migrate for the first time and being so thankful that it existed and then I was curious like, “who made this? Where did this come from?” I went to the page and was like, Ronin and Drew? Hold on a second (laughing), I love these guys. It was awesome. So NodeSquirrel was like an actual extension of Backup and Migrate right? It was another itch that you wanted to scratch, right?

DREW: Yea. Totally. Again, that had been a light discussion for many years, like “oh, we should think about a product.” Because when you’re a services company…I don’t know…we certainly did it, and I hear others do it a lot, like “I wonder if we could build a product. It’s great that we can go ahead and bill clients, but we always have to find a new client.” You know, if it gets tiresome you feel like you’re like a hamster on a wheel, sort of thing, like “we should build product.” I think that’s a common, sort of, thought process and I have strong opinions about that as well, and absolutely something we can talk about. I gave a session at DrupalCon about this a few years ago. I think DrupalCon Barcelona, something about bridging the gap, doing products as a service to this company. And, at one point in time, Ronin just actually said, “You know what? I can just do this. I’m just going to do this in my spare time. I’m just going to do it to like, goof around, and see if I can build it. I’m going to challenge myself with something to build, to see if I can build a hosted version, basically a host destination for databases, that would be secure, and off site, and something you can just rely on.” And, he knocked it together using Drupal, so obviously a Drupal module feeds it – Backup and Migrate. The site where you would go to find out more about it, well, actually there was no marketing site to start off with. But, then he built the receiver on the other end, which was a Drupal site, with a bunch of Drupal modules in it, including quite a bit of stuff for the storing of the databases and stuff, which was custom of a lot of the functionality, it was just standard stuff. It was views for admins being able to see things listed, etc. And, then, he basically brought it in and said, “You know what? I’ve been having a lot of fun with this, and it’s cool, but I don’t know what to do next, and it’s just basically been a pet project, but I think it might have legs. I think it might go somewhere. Would Gorton Studios like in on this?” That started off a lot of conversations like, “Well, that’s cool. I don’t want to take your baby.” Like there was a lot of dance back and forth, like “you built this thing. Are you sure?” His feedback was basically “Yea, I am sure, because I’ve done all the programing, that’s fun, now it needs like marketing and branding, and stuff. Like nobody’s ever going to do this, I don’t think.” And, I don’t know, like, those next gaps were totally opaque to him, and actually, frankly, to all of us, but we knew maybe how to take a crack at it. So, he brought in Gorton Studios, we had a little charter we formed at the time, and we ran it as an independent company. Underneath Gorton Studios it said obviously, by Gorton Studios and managed to learn our way and sort of, block our way, into a modest amount of success. It was going well, like graphs off to the right, making the money, etc., which was cool as a product, essentially to the point where it became a problem. So, for me as the CEO, again, it was in 2015, so probably in 2014 I realized that it was growing enough to merit real attention and time. And that was a problem. Like, “Ok, now we’ve been just doing this kind of round the edges in our spare time, but hadn’t really made it a huge push.” We would show up to Drupalcon, have a booth, do other things, but then we’d go home from Drupalcon, go back to our billable work and then maybe remember to tweet once a month, or something like that. Again, it continued growing through all of that, but we realized that…or I realized…I did a lot of thinking…either I need to hire someone to be devoted to this full-time or, we need to sell this to someone who will do that same thing, or well I suppose the other one would have been shut down. But basically, I was looking between those first two more. Like, do we need a full-time, staff this, dedicate actual money, what does it look like, we’re going to break off and again, give it the attention it deserves for the potential that I see in it, or, I can go for the quick win and sell it to somebody and just make gazillions of dollars. (laughing).

IVAN: So, you went for that option.

DREW: Yea. Actually, I did both simultaneously. I spent a lot of time planning those things, and then at the same time, actively talking to folks. Amongst the people I had an early conversation with was Zack Rosen, he’s the CEO of Pantheon, and just wanted to pick his brains. Because Pantheon came out of an agency that had built a product, a platform, and then went on to great success. I kind of wanted to, just the balance and how to do things, we just really started getting into it and had an awesome conversation. It was at a Pantheon partner dinner in the 2014 range, I happened to crash that dinner to hang out with some friends from Think Shout, who are a great agency based in Portland, than I just sat at their booth, and Zack was kind of doing the rounds, like “Hey, I’m Zack Rosen, I’m the President.” Going around and being sociable, and doing all those…like working the room, in a really great way actually…I mean, it was just a very authentic way, but sat down and I was like “hey Zack, I just want to talk to you for a little bit,” and we ended up talking for like three hours. I kind of killed his circuit over the room. And, then we saw each other again and it was like “Wow, we’re just talking, this is really cool.” We talked a few more times at different events over the next two or three months, where we just ended up being together, and we would actually, we just said, alright we’re going to take a couple hours, I’d really like to pick your brains and get a feel for this,” and, at the same time I was really developing a sense of “Aha, I also think Pantheon might be a potential customer for this.” So, I started in the back of my head thinking, “Alright, I’m going to be able to sell this to these guys. That’d be pretty cool. Problem solved. Get some money and good, I’ll go back to continuing this cool agency I’m running.” I think what Zack was doing is like, “Mm hmm, this is an interesting guy. This product could be cool, but I’d like to have him on my team.” So, I think I was selling his notes, and he was selling me Pantheon. It worked out. I’m happy with where we landed. But, yea, that process went through, and actually, when it first was broached actually, I have to give credit to my wife as well. Because, Zack was like, “You know what? We’re kind of interested in buying NodeSquirrel, but I really want you to come with it. You and Ronin as well.” I actually just laughed. I was like, “I can’t speak for Ronin. You talk to Ronin. If Ronin wants to, that’s cool, but I already have a…it’s got my name on it. It’s called Gorton Studios. It’s actually my name. I do a thing already.” And I just kind of laughed. I thought is this like a negotiating technique. That conversation happened to happen in San Francisco. So, when I came home and told my wife, “Hey, honey, the funniest thing happened. I was talking to Zack, and he thought they’d like to hire me too.” I was like, “Can you believe it? That’s just ridiculous.” She had one of those moments of clarity that I remember, she just looked me deep in the eyes and was just like, “Drew, you have been looking for a change.” This is like slap, slap, slap, across the face. “This would be a pretty cool change, wouldn’t it?” Then I just remember thinking “Oh! yea! That would be pretty cool, huh!” (laughing) “How obvious does that have to be before I see it, my goodness. Thank you. Thank you love. I’m so glad I know someone who knows me better than myself.” At least in some ways. So, yea, so I went into it, the next time we had that conversation, with an open mind. And, that’s how it checked out. It’s been great.

IVAN: What’s it like going from being in charge of all the things as a CEO, to being a part of something that’s not yours. It’s not your baby. What’s that like?

DREW: It’s awesome. (laughing) I can say that, because I have a lot. I have just very high confidence in the people I work with, and that was really important to me going in. I wanted to make sure there was a clear roll for me, that I could see myself making a difference, and also, I could see myself having a lot of comfort knowing that other good people were making good decisions that I would agree with. Maybe not every decision, but I would agree with the decision-making process. And, having been a CEO, I’m very aware of the fact that a lot of the decisions that you need to make, are based on imperfect information and that don’t have a clear, “Well, duh, the obvious answer is this.” I mean, if you only got those questions as a CEO, there would be something terribly wrong. That would mean the people who are doing the work didn’t have the power to make decisions. Basically, the only decisions I would derive that I needed to make were always the messy ones, like, all the easy ones were taken care of. And, even many of the hard ones were taken care of. It’s really only the particularly snarly ones. And, so, one of the things I really enjoy now, is a hand over situation, like “hey, I’m going to weigh in. Here’s what I think is going on. Here’s the things I’m able to see. Here are my recommendations. Enjoy.” (laughing) And, I think it’s fantastic. I’ll leave it there.

IVAN: Ok. (laughing) I was actually going to ask you what the best part of your job is right now, but I think you just answered that.

DREW: Well, I enjoy that freedom. I enjoy the ability for me to be able to have less emotion and angst, perhaps  tied up in my work. There are pressures with being responsible for the paychecks of others. I’m a manager at Pantheon as well, and I still feel some of those pressures, but it’s far less visceral. At the same time, I’m very aware of the fact, I think one of the things that I learned as a CEO is, all companies are two to three months from going out of business. Every single one. We see that in the companies with massive corporate layoffs. It doesn’t matter what size you are. It’s just possible. As a services business, what you end up doing, is you find a new client. And, of course, you find a new client, because you’ve always been able to find new clients, but you don’t know which client it’s going to be, and there’s always some…that is a real recurring pressure.

IVAN: Angst.

DREW: Yea, absolutely. And, so, Pantheon needs to find new clients. It’s a product. But we need to continue doing our work, but not seeing that thing every day is, like I know it’s true, I’m also not, sort of hit with it every moment, and so, I appreciate that. However, coming back to the thing I like the most, I love the fact that I lead yet another great team. So I have this just really cool team with developer relations folks and they’re all experienced, talented, technical people, who have done real work, really interesting stuff elsewhere in the world, Drupal and WordPress and some other systems as well, and they’ve done it well enough to get to a certain level of experience and expertise, and accolade from people around them, but then they’ve also got personalities that are just really warm and open and welcoming. They give talks at different camps and they make friends with lots of people, and they’re just a really warm, wonderful group of people. So, listeners of the Podcast might know, for example, David Needham, who is a Minneapolis ex-resident, who lives in Illinois these days, but he’s a member of the team. Steve Persch also on the Drupal’s team, used to be from Palantir, lived in Chicago, then Milwaukee, now he’s actually in Minneapolis, actually, in the last few months.

IVAN: Hi Steve! We should get Steve on the Podcast.

DREW: You absolutely should get Steve on the Podcast. He’s a great person.

IVAN: I think that would be great.

DREW: Yea. And then Dwayne. Anybody who has ever gone to the Drupal camp has probably met Dwayne. Dwayne is our road warrior. All of us get out on the road. Then we got Tessa here, locally in the community as well. She’s a little bit more active with WordPress, but again, just these fantastic people. And, Andrew Taylor in Portland, these days. Again, more visible in the WordPress space, but again, all of these folks have given sessions at Drupalcon. And again, I love the fact that I work with these great people. What we try to do is cross pollinate best ideas, best practices and help others do their jobs better, and yes, we like it if you use Pantheon as part of that. We hope that we're spreading best practices, like continuous integration and other things like that. People will pick them up and use them however they want, but take the code rebuild, fork it, make it your own thing and use it to make your agency more effective. And it’s really easy, Pantheon, because it’s a pretty great platform. I really wish Gorton Studios had discovered it, it would’ve saved us a lot of freaking hassles. Servers are not fun. I used to end up dealing with servers more often than the rest of the team, and so I felt it perhaps a little bit more acutely, but servers suck. (laughing)

IVAN: I’d rather someone else did them as well.

DREW: Oh man. Yea.

IVAN: I have to say I’m very impressed with and have always appreciated, the amount of contribution and care that Pantheon takes about open sourcing as many of the things that you guys are working on as possible. You mentioned Zack early on, and I remember TEN7 and myself being very interested in Pantheon, very early on. One of the things that struck me was the authenticity that I felt, that Pantheon had, and it felt like you guys were the small fish going up against the bigger fish, and I think you’ve been able to swim upstream, and I see only good things coming forth from Pantheon. I’m glad to see that.

DREW: Thank you. Yea. That’s a great word to describe it. So, Zack is incredibly authenticate, and so is the rest of the leadership too. Just all good people who might disagree on the way to do something, but not the why. We want to make life better for our customers. Like “Ok, good, we all agree, great. Now what are we doing tomorrow?” And, to have a team around, which you could have a great dialogue about things like that. Again, you might not agree with exactly the outcome, but you also agree “Look, there’s a lot of stuff going on here, we need you to make an expedient decision. The decision is made. Let’s do it.” That feels great too. “Right, we’re going to do it, cool.” Now we’ll readdress in six months if we need to, or whatever. It’s great.

IVAN: So, I want to ask you two more questions. Actually, both of them, they could be work related or not, it’s up to you. What’s your favorite thing right now? In the last 24 hours, 48 hours, what’s your favorite thing?

DREW: I like cooking. (laughing) So, one of the things that I’ve really discovered over the last 3-5 years is the simple joy of providing a good meal for others. Last night, my youngest son, who is a freshman in high school, he did his first marching band at the football game. We came home at ten, eleven o’clock and got home, and he hadn’t eaten dinner. I made him, and my other son quesadillas and I had one myself too, because why not? We just had a little time together. Teenage boys that are eating make appreciative noises. (laughing). It’s just a simple joy.

IVAN: It is. Cherish them while they're there. And, my last question before we wrap up. What book should I read next?

DREW: I read a lot of fiction, and I enjoy science fiction and fantasy, because I’m a nerd. The series I have most recently just earned through is called The Expanse, which I also have come to learn is a television show. It is an extraordinarily, well-written series. The author's name is James Comey.

IVAN: James Comey? As in the former FBI director?

DREW: Could be. I think it’s Comey. I’m going to google this up.

IVAN: I mean, is he moonlighting?

DREW: It is not the same guy, I do know that.

IVAN: Well, for a moment I thought he might be moonlighting.

DREW: Corey. You’re right. James Corey. Which happens to be a collaboration of two different authors, but, it’s set in a not terribly far future, in which Mars has been colonized, but is being terra formed, and the asteroid belt is being worked, and it has basically created three distinct civilizations, all humans and historically all over us. But after a few generations living in the outer belt, after a few generations living on Mars, you start to have your own stories and such. So, geopolitical’s not the right word, it’s like solar political, or solo political background upon which they’re just great storytelling. And into that mix is injected some alien technology, and it’s great storytelling, and it's also extraordinarily plausible. It’s not so far ahead that you have imaginary lights, embers, or ray guns or other things like that, that you’re like “well, I don’t want to know exactly how that works, but, whatever, it’s kind of interesting.” It feels very authentic. The thing I enjoy about science fiction and fantasy is it allows you to take, well done science fiction and fantasy, allows you to take real people and put them into a different environment, and then basically look how that environment might shape their behaviors, in a way that is eye opening. And, that’s awesome. It’s an awesome experience.

IVAN: Thank you for the recommendation. We’ll definitely link to it in the transcript.

DREW: Awesome.

IVAN: Drew, thank you so much for spending your precious time with me.

DREW: Thank you! I really enjoyed this. I hope I wasn’t too long-winded. I think I might have been. (laughing)

IVAN: I think you’re good. So, you’re @dgorton on Twitter, and on Drupal.org, and you’re Drew Gorton on slideshare.net/drewgorton. 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.

Sep 19 2018
Sep 19

Spotlights shining on the Drupal 8 logo

Webform in Drupal 7 was always one of the top 10 must-haves on any Drupal site. Then Drupal 8 came along, and Webform wasn’t in the picture at first. Luckily, Drupal 8 came with the contact module in core that took care of most form needs, and we lived without the Webform module.

In the meantime, Drupal contributor Jacob Rockowitz had been working on the YAML Form module, which was a module used to define webforms in YAML files. At some point towards the end of 2017 YAML Form switched to the Webform namespace and Webform in D8 was born.

The Drupal 8 version of Webform will feel familiar to those with experience in the Drupal 7 version, but this is a completely new module and code base. It’s a really great tool for content creators to use, by giving them the ability to create complex forms without having to worry about code. However, as a developer, I found it tedious to create long forms through the Webform UI. Those days are in the past now, since Webform is a descendant of the YAML Form module, you still have the ability to define a form using YAML in the source tab of the build screen.

Screenshot showing direct editing in YAML

Direct editing in YAML really speeds things up for developers, and content creators can still use the UI to create and edit. It’s the best of both worlds.

The Webform module in Drupal 8 is such a powerful and fully featured form builder, that it could be reason enough alone for some site owners to switch to Drupal 8. If you run a site that is in need of new or dynamic forms on at least a monthly basis, then Drupal 8 + Webform would be a lifesaver and a budget saver. Personally, I find that Drupal 8 with Webform rivals any of the standalone form building tools available. There are dozens of features and settings that you get out of the box, and it’s easily extendible if you need to integrate with an outside service.

Like most things in Drupal 8, webforms created with Webform can be exported and synced as config. Webform also plays nice with Features if that’s your thing.

We still custom build many forms in Drupal 8 using the Form API, but Webform is a great tool to keep in mind when things need to be editable by administrators or when you just need a simple solution. It already deals with storage, email, and so many other things out of the box. If you have any webform needs, don’t hesitate giving Webform a shot.

Sep 19 2018
Sep 19

At Droptica we have always wanted to solve the problem of time-consuming creation of Drupal 8-based small pages from scratch. Finally, we have been able to achieve satisfactory results with Droopler. Version 1.3 is even better.

Why did we make Droopler?

We regularly make small pages for our needs (for example for marketing campaigns or events like DrupalCamp Poland) as well as for our clients.

Making a small website from scratch is time-consuming with Drupal 8, especially if you compare it to Drupal 7 or WordPress. It takes a lot of time to create a nice template that will work well on mobile devices, be easy to expand and comfortable to change.

We considered other technologies for small websites, but then we would have to learn all the processes connected with the new technology. And these would all be processes that we already have in place for Drupal 8 – automated testing, automated deployment to the production server, automated security updates and so on. For these reasons, we have decided to adapt Drupal to our needs.

Maximum flexibility

Our goal was to build a system that would allow you to easily add new subpages. Subpages are supposed to look good on your computer, phone and tablet without the need for using CSS. At the same time, the editor needs to be able to create a wide variety of subpages, and not only those containing the title and text.

We have used Paragraphs and prepared ready-made section types (paragraphs), which can be used to create subpages. Each subpage comprises one or more sections. Sections can be arranged in any order and multiple sections can be inserted on one subpage. Immediately after entering the content and graphics, the sections look very pretty. The editor doesn't need to do anything more – nor do they need any developer support when adding new subpages.

Droopler – it really hits the mark!

The editors are amazed! We have already deployed several dozen pages based on Droopler. Every time, the people who enter the content mention the following advantages of Droopler:

  • each subpage looks very nice,
  • high flexibility, there is no limit to subpages or sections within a subpage,
  • no programming work required to make the website look very good,
  • no worries about the correctness of the HTML code – no need to worry whether, for example, an inserted element will display correctly on the subpage,
  • SEO optimisation, often websites that were switched to Droopler from other systems had better positions in Google search results.

Droopler is a flexible system for creating pretty-looking content and at the same time a platform for virtually unlimited development because it is based on Drupal 8.

Drupal 8 also ensures high security. The Drupal Security Team continuously monitors the system code and releases new versions immediately if any bugs are found.

What's new in Droopler 1.3?

Currently, the latest version of Droopler is 1.3. In this version, we have 13 paragraphs for the types of content used to add subpages – 13 different sections available, which you can use to build any number of subpages.

One of the new paragraphs is side embed. This paragraph allows you to embed external content such as a Google map or a YouTube video in a pretty-looking section. It is perfectly suited for use on the contact page. Video embedding can be used on the page listing clips from recent events in the company, among many other examples. This is just one paragraph – but it gives a lot of possibilities.

Droopler sidebar with embedded content in form of google map

Another new addition to the system is a paragraph for creating a photo gallery. You can now easily build multiple galleries within a single page.

Droopler paragraph with gallery

Version 1.3 offers 6 new paragraphs. You can see them all at https://demo.droopler.com

Droopler is also a blog because these days, everyone needs a blog on the company's website

Most traffic to the websites on the Internet is driven by Google search results. And what matters to Google is basically good content and a lot of it. That's why we've added a blog to Droopler.

Droopler blog is also made up of paragraphs. There is fewer of them, but they are enough to create beautifully looking content. Paragraphs make it easy to embed even full-screen photos into your content. Of course, everything looks nice and pretty on mobile devices as well.

A blog with flexible subpages is a set of very convenient tools for every marketing expert. Building different types of websites for different industries and sectors is simple and enjoyable. Examples of industry websites can be found in the demo: https://demo.droopler.com

Plans for future versions

We are going to continue to develop the system. We often use Droopler for our websites, and our customers use Droopler more and more often. It has already been downloaded more than 600 times from https://www.drupal.org/project/droopler!

We have a long list of changes that we want to implement in the system. One of the larger modules will be a module for product presentation. You will be able to add products with photos, descriptions, categories and tags to the system. There will also be a special page listing products with the option of filtering with the use of Faceted API and Search API. This module will be perfect for production companies and distributors. Together with the existing components, it will enable a very nice presentation of the company's offer on the Internet.

How to get started?

Droopler is free and based on Drupal 8. You can download Droopler from www.droopler.com. A full description of the installation can be found on our blog.
We encourage you to download it and see for yourselves. It's really worth it!

Sep 19 2018
Sep 19

Expo just got nominated for the Swedish design award. Before Expo was nominated for two publishing awards, best magazine and best magazine website. The winners will be announced 7th of November 2018 in Stocholm where Ramsalt will be present. While we we wait, we have decided to share with you the secrets behind building Expo.se on Drupal. 

Expo screenshotShort about the client 

Expo is a Swedish anti-racist magazine started in 1995 by Stieg Larsson, also known as the author of the Millennium series books, where the inspiration comes from Expo. Expo magazine is issued by the non-profit Expo Foundation. The magazine contains investigative journalism focused on nationalist, racist, anti-democratic, anti-semitic, and far-right movements and organisations. The people responsible for Expo make no connections with specific organisations or political parties, but work together with individuals and organisations that share Expo's platform. The magazine is headquartered in Stockholm.

Why Drupal was chosen?

Drupal was chosen for many reasons and out-ranked other solutions because it fulfilled many of the requirements from Expo. The strong capabilities for large amount of data, content-authoring options and the high level of community support were a few key elements where Drupal perfectly met the needs. Additionally, Drupal provided reliable content management and moderation features, as well as an editor and user-focused interface. Especially when it came to the wiki functions.

Other reasons include

  • Feature flexibility
  • Scalability
  • No licensing fees
  • Maintainability

Goals, requirements and outcome

Previous site pain points
Multiple Subsites
The previous version of the site was spread over a number of subsites/subdomains which the client was eager to unify into one categorised Drupal site.
Complex, custom database structure & content editing
The database of the previous site was overly complex and custom built which made the site very hard to maintain. On top of that the content editing forms were very long and confusing.

Non-responsive theme
Expo has a huge readership but without a mobile friendly version of the site the full potential of their reach was not being met.

Understanding the pain points of the previous site was essential in making sure we met the needs of the client.

Ramsalt Media
At Ramsalt we’ve developed our own distribution of Drupal called Ramsalt Media which is specialised for online publishers including newspapers & magazines. Ramsalt Media includes all the tools are publisher needs including article scheduling, WYSIWYG, media management and frontpage management. We were able to use Ramsalt Media as a platform to build on top for the rest of the site needs which went outside that of our standard clients. At the time of project start in 2017, Ramsalt Media was only stable for Drupal 7 so initial development has been done in Drupal 7, but Ramsalt Media has since 2018 been available in Drupal 8 buildt with Thunder.

Key development steps
Content Migration
Expo produces both a physical magazine and regular online articles so all the old articles from the custom database had to be migrated into Drupal along with their related media assets. As mentioned above, the database had a very complex structure & naming convention, once information from the previous developer was provided we were able to start mapping the migration for the some 7000+ articles & 2500+ media assets. The migrate module was the main contrib module we used for the migration.

We also made use of rules autotag module which allowed us to read article titles & body content and auto tag articles on migration based on the topics they covered. The topics were all predefined as taxonomy terms, if an exact match was found in the title or body then the article was tagged with the given taxonomy term. This gave the editorials a helpful kick start in categorising all the articles within Drupal as taxonomy term landing pages (see: https://expo.se/tag/hatets-politik-2017 ) where deemed an important new piece of functionality on the site.



Just double click on any text and you jump into edit mode, with our module QuickerEdit

Improved Publishing Tools
As previously mentioned the site was built on top of our own distribution called Ramsalt Media. Ramsalt Media pulls together some of the best contrib modules out there to make article & content publishing easier and more streamlined.

Responsive Theming
We worked closely with Expo’s own design team led by Daniela Juvall throughout development. The goal was a simple, clean design with bold typography which was inline with Expo’s physical magazine style. The magazine has been nominated for a number of design awards in Sweden.
As mentioned the previous site was not responsive so it was essential the new site was optimised for all devices.
The theme was custom built for Drupal 7 using sass.

The New Wiki
Another major part of the development involved creating a new Wiki section to expo.se to house information on all the topics covered by Expo. This included information about right-wing political leaders and groups as well as their symbols and related articles. This section was built as a number of different content types which were then bridged together using taxonomy and entity reference fields. This approached allowed wiki nodes to be associated to a single taxonomy term which could in turn be associated with other content on the site. Binding the wiki together is a central search page which was built using the search API, facets & panels.

[embedded content] Long Reads
Long read or long form articles have become more and more popular with our publishing clients in recent years. They allow for a richer and longer form of article to be published.
Expo wanted long read functionality to be able to post longer articles from the physical magazine in a richer and more eye catching manner. We used the paragraphs module for this and created a number of custom paragraph types to store the different types of content needed to make up a long read. This included text paragraphs, call to actions, images and videos.
We also created a “layout” paragraph type which allowed all paragraph types to be laid out in a set responsive left/right column layout. On top of paragraphs we custom built a floating “table of content” (optional) and read indicator bar.
We found paragraphs to be the best option for this job although the node edit form is an area where we are hoping to improve in the future as it can become confusing on very long articles.

Site Building
The rest of the site was built out using custom content types & fields, views, entity collection, panels/page manager and views content panes. This allowed for a rapid & streamlined approach to site building. Using views content panes meant similar displays could reuse a single view using pane settings to vary the display as needed.

Key modules 

Scheduler: allows editors automatically set articles & content to publish (and unpublish) at a set date & time.

Entity Collection: allows editors to control the frontpage articles list in a custom order and apply custom styles to each article in the context of the frontpage. This along with views & panels allowed us to build a custom frontpage and inject custom blocks with the frontpage article flow.
Entity collection was used throughout the site to give a unified approach to all content lists/blocks you see throughout the site.

Media: allows editors to upload media to a central library allowing easy reuse of media throughout the site.

Fields: of course the fields module & it’s contrib modules are used to provide custom field types allowing editors to add galleries, videos, article sources, bylines and more.

Sep 19 2018
Sep 19

Here are some insights which were shared during the Dries’ session:

  • Drupal 9 will be released in 2020.
  • The next DrupalCon Europe will be held in Amsterdam 28 Oct - 1 Nov 2019.
  • Drupal became the fastest technology to install! Before it took 20+ clicks and 15 minutes but now you do only 3 clicks and spend 1.27 minutes! You may find a table of full comparison with other technologies on a slide in the gallery.
  • Dries also spoke about the Javascript Modernization initiative. Now the Drupal Community is trying to build a bridge to the JavaScript Community and modernize Drupal through API-first and JavaScript.

In the gallery below, you may see a full list of initiatives which will be implemented into practice soon.

Also, It was incredible to be among the top 30 companies which did the most of all contributions to the development of the Drupal CMS.

One more event which our team members had an honor to visit was Round Table with Dries and other partners and supports. There were a big number of business owners and representatives of different Drupal companies.

A variety of questions were discussed there. The main ones were: how to compete with other CMSs and how to promote Drupal. It was an almost two-hour discourse where everybody could tell about problems that Drupal has and suggest solutions.

The ADCI Solutions team wasn’t only a listener but had prepared our own activities: BoF on Drupal marketing and a session “How to boost your team members performance”.

There was a dynamic discussion at BoF. All places were taken and we were happy to see so many people who feel passionately about Drupal promotion as we do. A lot of Drupalers joined us and it was great to hear a big number of ideas, life hacks, and thoughts from people working with this CMS in different countries.

The main points which were touched during BoF were Drupal positioning, competition with other CMSs and between different Drupal companies, how to explain what Drupal is to non-tech people, and how to hire a Drupal prof.

The BoF’s participants determined the primary advantages of the Drupal CMS:

  • It allows you to see a result right away.
  • It is powerful and fast, as well as completely suitable for content-heavy projects.
  • It is an open source technology.
  • It is the best variant if you need a long-term solution because Drupal is highly scalable. You can change it in the future when your business is bigger.
Sep 19 2018
Sep 19

You can’t build a website without a plan. A plan derived from requirements collected and a design created. You also need a development and testing plan that reflects the appropriate strategies for meeting said requirements and design. After you launch your website, you need a maintenance plan to ensure that your code remains secure, your content remains accessible, and your future features are integrated correctly.

Of all the development methodologies, past and present, there is not one that supports the development of software without requirements and design. When choosing a methodology, be it one based on the 12 principles listed in the Agile Manifesto, or not, you will not be able to avoid the effort of creating plans.

Agile Misunderstandings

Among the many misunderstandings regarding Agile methodologies is the aspect of planning. The belief that upfront planning isn’t needed and therefore time can be saved on a project is a misunderstanding of the iterative and incremental approach to software development. Think about it that for a moment. Can you create or build anything without some kind of plan? Be it simple or extensive?

It’s also a misunderstanding that said plans, if any, don’t need to be documented. If you choose an Agile methodology, you will quickly learn about Epics and the Backlog. Epics are large user stories while the backlog is a list of requirements derived from said user stories.

So, Agile isn’t about skipping the planning aspects of the project. It’s about changing the way the planning and development are conducted. And, the first step in the process of planning your site is gathering the appropriate players together.

The Right People

If you are going to put out a request for proposal, you need to include some of the requirements. Perhaps not all the details, but enough that a vendor who wishes to bid on your project can anticipate potential costs. Later, these initial requirements will fleshed out with the vendor whose bid you choose.

So, who needs to be in the room when you start brainstorming what you need? Who will ensure all requirements are identified? 

  • The money person would be good. They will know the budget and can remind you of the fact as the ideas start to mount.
  • The content manager is important. You will need to understand the tasks involved in creating and posting your content. For instance, how will you manage the publication of your content once it is uploaded to your site?
  • Let’s not forget the person who is in charge of your current site. This is the stakeholder who knows where the bodies are buried. They know why the current site is what it is and if certain aspects of the site can't change.
  • Other process owners. Depending on the tasks that your site will support, such as e-commerce or document download, who knows the most about how these tasks should be performed?
  • The naysayer. The squeaky wheel. Who is your Eeyore. “It will never work.” Get them in the room because you want the devil’s advocate. You want to hear what might not work and why.

Bottomline, anyone responsible for an aspect of the site, be it backend support or frontend interactions, get them in the room. You want to cover all your bases.

Agile Upfront Planning

“In 1998, Alistair Cockburn visited the Chrysler C3 project in Detroit and coined the phrase ‘A user story is a promise for a conversation.’”1 Then, in 2001, Ron Jeffries, one of the original signatories of the Agile Manifesto, proposed a ‘Three Cs’ formula for user story creation: card, conversation, confirmation, making user's stories part of the world of Agile methodologies. Coupled with use cases, Agile planning seeks to identify requirements and design before development begins.

However, as you will see, the level of requirements detail depends on several factors such that not every minute decision is made at the start. Let’s look at this idea more closely.

User Stories

User stories are typically brief statements written from the user’s perspective. For example, “As the content author, I need to be able to edit a page so that I can add a header image.” The documentation of such statements can be facilitated with index cards, Post-it notes, wireframe sketches on printer paper, or anything that meets your team’s needs.

A collection of such user stories helps to confirm the scope of the project and can reveal foundational requirements such as which framework or platform to use. Such stories also reveal relationships and thus where shared code will be used, for instance. 

At this point in the planning process, the team might decide to start developing. Such a decision is made possible by today's systems and platforms with plugin and play capabilities. They provide a way to support the user story tasks so that said tasks needn't be reinvented via a use case.

If user stories are unique and more detail is needed, creating use cases is the next step.

Use Cases

If system default tasks are not what is envisioned or additional tasks need to be supported, the team may choose to clarify the user stories via use cases - details of actions and events that define how a user interacts with the system. 

Deeper investigation into the requirements can help define a development path that supports both the overall system architecture required but also the specific tasks required of the system.

Once the stakeholders and development team have gained a common understanding of what is required, the user stories and use cases are converted into epics and the necessary backlog of development tasking.

So, Agile methodologies support the requirement and design phases listed in the Waterfall methodology, it just does it by engaging methods that have proven easier for end users to envision as they communicate what it is they want from the product being created. 

Of course, this isn’t the only time during the iterative and incremental development approach where planning takes place.

Agile Planning in Development

With epics and a backlog populated, the development team plans a series of iterative and/or incremental development efforts, commonly referred to a Sprints. The way the Sprints are defined depends on the overall development strategy required to build out the product, in this case, a website.

Before each Sprint, the existing requirements (based on user stories and use cases) are reviewed and specific strategies are chosen for meeting said requirements. This might include a conversation where details are clarified or added to use cases.

After each Sprint is complete, the product owner is asked to confirm that expectations have been met. If not, requirements and design aspects can be changed to correct misunderstandings or to acknowledge a new idea or need. In other words, additional planning is interjected into the development cycle and the project is adjusted.

In addition, lessons learned are collected and decisions are made regarding how-to strategies for the next Sprint. You might be thinking that enabling changes to the original plan might introduce scope creep. And, you would be right. It can.

Planning and Scope Creep

Scope creep is similar to what happens when you think you are buying the base model of a new car and you leave the lot having spent 20% more than planned because you decided on several add-on features. 

Several factors can influence the possibility of scope creep on a website. Let’s consider two related to planning.

  • Insufficient upfront planning. We aren’t talking about getting into the details of how features on your site are developed in this instance. Instead, it’s about ensuring that all user stories have been identified along with supporting decisions. For instance, if the user needs to be able to categorize an article, has the supporting requirements such as the information architecture been defined? 
  • Incorrect stakeholders at the planning table. The budget folks will have a different take on requirements than say an end user. Content manager will be able to enlighten decision makers on processes that are required to ensure a specific level of content quality. Without the appropriate people involved in the planning process, you might find that a Sprint doesn’t meet expectations.

Conclusion

An Agile approach to website development relies on planning to be successful, however, not all planning is required before development starts. Of course, there are risks associated with moving quickly into development, one being scope creep. 

The power of Agile methodologies isn’t about being able to skip steps that a waterfall methodology is criticized for enforcing. It’s about being flexible. It’s about being able to adjust as forgotten requirements are remembered. And, it’s about continuous feedback, ensuring what was originally thought to be a good idea, still works. 

Promet and Planning

Promet offers a unique planning engagement that we call our Architecture Workshop. This workshop is a customized engagement that engages all of your stakeholders in the Discovery Process.We do a 3-5 days of intensive onsite exercises with stakeholders (for your busy C-level folks we customize the agenda to bring them in where they are needed during this onsite). Then the team goes away and produces a set of deliverables that  includes a full-field level Architecture Blueprint of the website(s). Whether you choose to use a waterfall or agile development methodologies - you have everything you need to build the website everyone has agreed upon. 

Not building your site and stressed out about getting an accurate quote? Investing in this kind of Workshop will make sure that you get the right Partner, and the best price.

Footnotes

1 
https://en.wikipedia.org/wiki/User_story
Sep 19 2018
Sep 19

So here we are, post-Drupal Europe 2018. Talks have been given, BOFs attended, way too much coffee and cake have been consumed, and now I’m tasked with summarizing the whole thing.

The problem faced by anyone attempting to wrap up the whole of an event as momentous as Drupal Europe is that you have two options. On the one hand, you can give a fairly anemic bullet-point summary of what happened and when. The advantage of approaching a summary like this is that everyone who was at Drupal Europe 2018 can look at the list and agree that, “yes, this is indeed what happened”.
Fair enough. Maybe that would be a better blog?

But that’s not quite what I’m going to be doing since (as you’ll find in the links below) my colleagues have done a stellar job of actually covering each day of Drupal Europe in their own blogs. What I’m going to do, rather, is tell you about my Drupal Europe. And my Drupal Europe was far less about talks and BOFs (and coffee and cake) than it was about the people in the Amazee Group and the Drupal community in general.

Reasons to get off the Island

For background, I live in a smallish town (we have a mall and everything) down here on the South of the North Island in New Zealand. Getting myself to Darmstadt involved nearly 30 hours in those metal torture tubes we commonly call “airplanes”. Under most circumstances I’d avoid this kind of travel, but Drupal Europe was an exception because it presented me with the one opportunity I had this year to spend time with and around my teammates in Amazee Labs Global Maintenance specifically, and the rest of the Amazees at the conference in general.

I came to Drupal Europe in order to have the kind of high-bandwidth conversations that (very) remote work almost never allows. It allowed me to meet some of my colleagues in person for the first time, in some cases people who I’ve been speaking and interacting with online for more than a year. Outside of the hours of strategic meetings we all had, it was a joy spending time sharing screens IRL and looking at code, eating kebab (so much kebab), and (wherever we could) doing a bit of real work in-between.

And while my reason to get off my island was really my colleagues at Amazee -- being present, alongside, and with them -- the importance of the wider Drupal community is not lost on me and attending Drupal Europe highlighted to me, once again, just how special that community is.

Beer hall at dusk

We’re hiring, by the way.

In her deeply moving talk about her journey from being a freelancer to being the Head of Operations for ALGM, Inky mentioned the principle of Ubuntu. This ethical and metaphysical principle is often rendered in English as “I am because we are”. In one interpretation, at least, it suggests that our existence as individuals is inextricably intertwined with the existence of others. I think that something like Ubuntu is true of both Amazee and the wider Drupal community.

What makes Amazee special is the remarkable individuals that comprise it, indeed, I doubt I would’ve been as enthusiastic as I was to travel so far if they weren’t remarkable individuals. But I have to wonder whether those individuals would shine quite as brightly in any other company? Amazee gives us the space to be the best we can be and whatever shine we have as individuals makes Amazee glow that much brighter.
Zooming out a little, Amazee, as an organization, would not exist as it does without the wider Drupal community. And the Drupal community would be poorer, at least in my opinion, without the work that Amazee does.

It’s circles within circles within circles, each strengthening the other.

Showing your work.

This was a theme in the Amazee talks at Drupal Europe. Stew and Fran, in their discussion of Handy modules for building and maintaining sites ended things off with a note encouraging everyone who manages to solve a Drupal problem to consider how they might contribute it to the wider community. Indeed, Basti made this the theme of his entire talk, discussing the benefits of open sourcing your work and the material advantages the IO team has experienced by open sourcing their platform, Lagoon. And in terms of open sourcing code, Stew’s talk on Paragraphs has already lead to the creation of a brand new Drupal.org module from an internal Amazee project. Is this an example of upcycling, hmm, Joseph?

Stew and Inky, showing their work.Stew and Inky, showing their work.

We’re off the Island now, time to go farther.

Speaking of circles, in some respects the move in the Drupal community in the past few years has been to expand our circles even further into the wider programming communities. Drupal 8 adopted much “external” code from the supporting PHP communities. But to some extent, we’re moving even further away from the Drupal island than simply playing-nicely with the PHP community. Decoupling Drupal, a major research topic right now, is at least in part about getting Drupal to be less monolithic, for it to serve content to systems and in contexts that aren’t necessarily Drupal specific. It’s no exaggeration to say that Amazee is ahead on the curve on this, as was evidenced by Michael and Philipps' talks. Michael discussed the “implications, risks, and changes” that come from adopting a decoupled approach, while Philipp simply dazzled a packed room with his demonstration of staged decoupling with GraphQL integration into Twig.

Drupal Europe art installation

This was Drupal Europe.

This was Drupal Europe. Not just talks, or coffee, or BOFs, or the (delicious) lunches. Rather, it was the opportunity to really dive in, experience, and behold the interlocking circles of individuals, friends, companies, and community that holds this sprawling structure we call the Drupal ecosystem in place. To get a sense where we are and where we’re going.

Previous Drupal Europe Blogs

Sep 18 2018
Sep 18

At Drupal Europe 2018 I had the chance to learn the latest developments regarding the editorial experience in Drupal 8.

Content planner

One improvement that can make a big impact on the daily work of the editors is the Content planner which was being demonstrated by Lukas Fischer of Netnode.

Currently Drupal’s out of the box content overview screen (admin/content) provides a somewhat Spartan experience. Thus the need arose of a more feature rich content dashboard. With that need in mind, the team of Netnode found inspiration in content planning tools like Buffer, Gathercontent, Trello and Scompler.

This resulted in the Content planner project. This contributed module will provide a content planning dashboard that allows editors to easily find the content they need to work on.

Content planner features

Some of the features of Content planner are:

  • a content status giving quick overview of the state the websites content is in
  • a calendar that allows scheduling the publication of the nodes
  • a recent content list giveing the editor quick access
  • a kanban board voor content with columns for the content statuses draft published archived and so forth

De module is quite young and still needs improvement, but it seems useful enough to start using in your projects. By adding Content planner to your website you will probably increase your popularity among your editorial colleagues tenfold!

Autosave form

Another development that could make many editors working with Drupal happy is autosaving forms and resolving conflicts.

The autosave form contrib module was being demonstrated at Drupal Europe by Hristo Chonov of Biologis.

It automatically saves the field values every minute when you are filling out a form (for example a node or a contact form). To be able to do this correctly it bypasses all form validation, disables any implemented forms hooks and keeps the form ID intact so that the normal Drupal form editing workflow is not being disturbed.

At the moment the module is not able to autosave when creating a new node because essential information like the node ID is not available at that moment.

Autosave states are saved per user and it’s disabled when two users are working on the same content.

Conflicts

If multiple users are working on the same content then conflicts may arise. The conflict module aims at resolving those conflicts by comparing the following versions of the content:

  • the initial content;
  • the content that’s being edited;
  • the content that’s stored (which could be the content that’s been edited in the meantime by another user);

Most fields will be merged automatically but fields that have conflicting values are presented to the user so he can choose how to resolve them. The UI for resolving conflicts is currently being re-evaluated and contributions in this area are more than welcome.

If you are looking for ways to improve the editor experience of your projects then put Autosave form and Conflict on your checklist.

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