Jan 25 2020
Jan 25

A sluggish-performing Drupal website not only impacts user experience but also worsens the ranking of the site on search engines like Google who are fanatical about faster page load times (user experience mostly).

Contrary to it, when a Drupal-powered website is perfectly optimized for performance, it can tackle many million visits on the site each day. 

There are multiple ways to configure web performance for optimal results. This blog post will walk you through the checklist of feasible performance optimization techniques for your Drupal website at a beginner level.

Beginners’ Level Tricks to Load Drupal Site Faster

There are several methods at the beginner level that can be implemented to speed up page loading. Specific Drupal tools and modules are listed for the same-

  1. Core Caching: Go to Extend -> Module

These two Drupal modules, “Internal Dynamic Page Cache” and “Internal Page Cache”, should be installed and enabled by default. 

  • Internal Page Cache:

Internal Page Cache is beneficial for sites that have several millions of unregistered users

This module is beneficial for sites that have several millions of unregistered users. It stores the entire page in the cache so that whenever a new user or even the same user revisits that page, it can load faster than ever without the need of putting information together from scratch.

  • Internal Dynamic Page Cache: 

This module is designed to cache small sections of each page for all users, no matter if the users are logged in or not. The objective is to accelerate the building of the website page on the go.

2. Twig Caching: 

Twig caching is deployed as a template engine for theming purposes in Drupal 8. It relies on its own cache of compiled Twig templates, which is separate from other caches.

Go to sites/default/ & copy your default.services.yml file to services.yml and check below config settings:

  • twig.config : debug: false
  • auto_reload: null
  • cache: true

These commands will help one on/off caching for the twig template.

3. Page Caching:

The information available online is valid for a certain period of time. In such a scenario, it is better to define a corresponding maximum age. However, in Drupal 8, there doesn’t exist any feature that validates data for a limited time. Rather, it caches data permanently and relies entirely on cache tags for invalidation.

Therefore, this module depicts the maximum time duration for a cached page. Whatever age we set here in Cache max-age, implies the maximum age that our site tells browsers to keep cached information/ data. 

  • To enable caching, navigate through Configuration- Development-Performance. 
  • Activate “Cache pages for anonymous users” by selecting the minimum time for the cache lifespan as well as the termination of the cached pages.

Drupal logo and Speed word written                             Source: CloudReviews

4. Bandwidth Optimization: Go to configuration -> development -> performance

Bandwidth optimization is performed to reduce both the size and the number of requests made to your website

Drupal 8 has already eliminated “compress cached pages”. Instead, it has introduced a default setting where one can optimize external resources efficaciously. This bandwidth optimization is performed to reduce both the size and the number of requests made to your website. 

With Drupal 8, you can simply aggregate CSS & JavaScript files to load them together faster with just a handful of aggregates.

5. Views Caching :

The Views caching module helps in displaying content in various ways. Views instances should be cached as the best practice so that when accessed, a cached copy is returned instead of having to rebuild each view every time it’s loaded.

There are 4 options in views caching :

  1. Tag-based

Cache tags make Drupal aware of the entities used during a page view. This implies that Drupal saves the cache tags along with the data it caches. Thus, if it needs to clear the caches because one entity is updated (let’s assume node with ID 55), instead of erasing all caches, it can easily find out which caches actually used node 55 and clear only those.

2. Time-based

The cached data remains valid for a certain period of time. To set time-dependent caches, one can use cache max-age and set the time duration for a cached page, further exceeding which, it will be erased or expired.

3. None (no caching)

It implies that there is no caching associated with the view.

4. Views custom cache tag

Views automatically add cache tags to every view in order to nullify content whenever it is updated (and can be cached maximum possible until they do).

However, Drupal 8 encompasses a single list cache tag for every entity type. Every view that enumerates nodes is tagged with node_list and will be invalidated when a node is added, changed, or deleted.

Views contain filters. They list nodes of a specific type or those which are tagged with certain terms and a combination of three other filters. With the usage of more specific cache tags, it is possible to update views that actually might list the changed node. 

This module allows developers to set different cache tags based on the configuration of the view. It is also possible to set cache tags based on arguments/contextual filters.

6. Clear Cache Tag

The caching process in Drupal is carried out through tags. The Clear Cache Tag module also uses the tags in the form of strings to pass it in sets and clear the required cache items only, unlike the conventional practice, which involves the cache clearance of the whole site.

This module helps website developers save a considerable amount of time and effort, which otherwise would have been dedicated to maintaining information. Besides, frequent caching can aggravate the website loading time, thereby impacting user-experience extensively.

7. Image Optimization


Image optimization module configuration                       Source: Drupal.org

 The ultimate goal is to reduce the file size as much as possible without sacrificing quality

The image size that you choose for your website has a profound impact on your website’s speed and performance. The right approach to ensure image optimization is to adopt correct sizing and formatting (JPEG, GIF, or PNG). The ultimate goal is to reduce the file size as much as possible without sacrificing quality. Fortunately, Drupal 8 core offers tools to control and optimize image sizes. Use the Image style features to have different image sizes for different devices like tablets and mobiles.

You can change the compression ratio of an image. By default in Drupal 8, it is set to 75%.

1. To change the ratio, go to Configuration -> media -> Image toolkit

2. change the % and Save configuration

8. Use Syslog For The Error Log

Syslog delivers valuable information for use in the system management and security auditing

The Syslog module records events by sending messages to the logging facility of your web server’s operating system. Syslog is an operating system administrative logging tool that delivers valuable information for use in the system management and security auditing. Suited for medium and large sites, Syslog offers filtering tools to route messages as per their type and severity. 

It can significantly improve the performance of the site.

Watch out how to set up the Syslog module-

[embedded content]

9. Disable Unused Modules

List out all the modules that you don’t need and disable them as these only add to the total overhead for additional PHP code to execute on each page load and demand extra CSS and JavaScript files, even if you are not using the module for anything.

In case you have modules that you use seldom, it’s suggested to disable them and try to find an alternate method to achieve the same result. 

10. Regularly Update Core, Contributed Module, and Themes Of Your Drupal Site

It is best to be cognizant of what each update offers and test things out before pushing them live

Per the proven methodologies and practices, you should keep an eye on updates to the Drupal core and contributed modules. The updates are released frequently and encompass performance improvements, so keeping them maintained is essential. 

Simultaneously, it is best to be cognizant of what each update offers and test things out before pushing them live.

Final Words

There are several factors to take into account which can hamper the performance of your Drupal site. Therefore, you must make sure that your site is cached appropriately, images are of the desired size, and unused modules are discarded. These factors consolidated with adequate bandwidth usage will give your Drupal site an edge against the competitors.

Jan 24 2020
Jan 24

A decade ago, the media and enterprise industry looked completely different. Those were the times when print media ruled, blockbuster (video store)  had around 100 stores around the UK, and barely anyone had heard of Netflix or Spotify. During those times, consumers preferred physical media and the mere thought of even accessing video content through the internet was considered as engaging in flights of fancy.

However, the time has changed dramatically- publishers of every kind are finding it difficult to deal with the digital incursion. Blockbusters exist no more, while Netflix on the other hand, is a gleaming example of how to engage customers in this digital age. 

In fact, last year saw the downfall of traditional satellite and cable services worldwide and subscriptions to online streaming services at a breakneck pace. 

Given the huge pace of change recently, this blog will run through the challenges that the media and publishing industry is facing right now, and how can it be resolved.

Challenges that Media & Publishing Companies Are Facing Currently

Cloud surrounded by various digital elementsSource: Tildeworks


Content plays a paramount role in building a brand’s online presence, engaging customers, and reaching new audiences altogether, provided it is in sync with the business guidelines. However, there have been some challenges that media and publishing companies especially are facing currently in achieving the same. Look what those are-

  1. delivering personalized results to keep readers engaged
  2. standing out in the crowd with a unique content approach
  3. improving the mobile experience
  4. adopting new technologies
  5. print versus digital
  6. revenue recognition
  • Delivering Personalized Results To Keep Readers Engaged

Media and publishing enterprises have not yet been able to leverage the power of personalization to its full extent. With personalization, enterprises can push a different set of content based on the users’ preferences, that too at the right time, and on the right devices.

Big data analytics and predictive technologies can serve as the basis for personalization but since multiple customer data points are stored in different repositories, enterprises are having a hard time getting valuable insights about the customers, thereby making effective personalization a mere reverie.

  • Standing Out In The Crowd With a Unique Content Approach

The proliferation in websites and a shedload of content on them have crowded the online world for years. Further, the rapid expansion in the number of ways information is disseminated has made it challenging for media & publishing enterprises to cut through the noise and reach, attract, & retain their target audiences.

  • Improving the Mobile Experience

As per this report, the consumption of online content on mobile devices has been steadily growing for years already now, but many prominent digital publishers are yet far short in this game. Enterprises are behind the curve in adopting “mobile-first culture”, which, as a result, is leading to an unpleasant end-user experience on screens of all sizes. 


Various vertical bars representing mobile usage statsSource: Smartinsights

  • Adopting New Technologies

Merely catching up with all the latest technologies available to digital content creators is challenging enough, never mind their evaluation and deployment!

Media and publishing enterprises need to gain expertise in information technology as a business can only be disrupted once companies move over conventional approaches. 

  • Print Versus Digital

It is normal to presume that print media is obsolete as digital publishing continues to blossom. However, it is partially incorrect. For example, 58 percent of online subscribers are primarily found interested in reading print. Additionally, publishing revenues are generated from 60 to 80 percent of print sales.

Simply stated, enterprises need to utilize the available information on their readers to better understand their preferences and the way they want to interact with their sites and products on a daily basis. 

  • Revenue Recognition

Addressing multiple sources of revenue in different ways proves challenging for a business. For instance, subscription revenues are only recognized when the product or service is delivered whereas advertising revenues are taken into account when the ad is published or broadcasted, while events & exhibitions are paid for on delivery of the event.

Whether small or big, companies can find it difficult to manage these variations as it is a very time-consuming and inefficient way as well. Relying wholly on Excel spreadsheets is an error-prone approach, making the enterprise vulnerable to reporting inconsistencies in their accounts as well as suffering from discrepancies across key information.

The repercussions of such inaccuracy and mismanagement of accounts can be serious enough that it can even threaten the existence of a business.

What Features the Best CMS Should Include

When building websites that are focused on content, one should opt for a content management system which is easily maintainable, free (e.g. open-source CMS), and user-friendly at the same time. Below are the features that an “ideal” CMS should possess-

1. Flexible Content Repositories

Segregating content and presentation layers in CMS is a requisite to do away with the concerns of content creators on how every single front-end would display content. Rather, they can work with structured content.  That’s how repositories come into play and ensure that your content is structured and accessible. Structured content enables you to separate your content into independent parts so that every single entity can be edited or repurposed. Following this;

  1. Your visitors will easily find what they are looking for on your site or app
  2. You can recommend visitors the associated content apart from their searches, to let them explore the other offerings and content on your site
  3. You can create meaningful relationships between content pieces to fortify the user experience significantly
  4. You can focus on delivering personalized user experience through dynamic content for a particular set of audience

2. Open APIs

API, Application Programming Interface,  ensures easy interaction of application programs with each other in order to share data.

A combination of flexible repository and open APIs implies that one can deliver content beyond the web. The CMS’ APIs can be leveraged by the app developers to build a targeted app using available content beyond the web. This way, it becomes a five-finger exercise to repurpose the existing content in an eBook, on websites, mobile, native apps, Facebook Messenger, and other platforms.

In addition, with APIs, you can integrate your CMS with other internal and external systems such as ERP, CRM systems that you already have established.

For instance, Federal Election Commission (FEC) uses API to allow users explore the way candidates and committees fund their campaigns. You can search candidates and committees and use their IDs to find reports on line item details with the other endpoints.

3. Personalization

Marketers delivering personalized web experiences to their users are getting double-digit returns & loyal customers in marketing performance and response. 

More and more CMS vendors are adopting stronger, and more tightly integrated personalized capabilities to fulfill the demand for personalized experiences. 

A significant role in enhancing the user experience comes down to verifying the content on your website. For instance, Ez content uses predictive analysis and intelligence to understand users’ preferences and accordingly showcase results. 

Acquia’s product, Lift is a personalization tool, designed for Drupal, to help marketers quickly optimize user experiences. 

Similarly, the merger of Acquia and AgilOne will help enterprises deliver powerful customer experience via AI, to  ensure higher engagement levels.

4. Multi-lingual

Enterprises already targeting an international audience, or have plans to cross borders in the future should consider a CMS that can meet your multilingual requirements. Many CMS vendors provide multilingual capabilities through plugins or extensions. However, the problem with this type of offering is that it can go unmaintained and hence introduce vulnerabilities. 

A CMS having multilingual capabilities should be able to fully customize URLs, support more translations than currently required, and has a language switch option, to enhance the user experience even after changing the language.

For instance, Drupal 8 offers multilingual capabilities (modules) to facilitate enterprises deliver seamless customer experience.

5. Multi-platform Capabilities

If your WCMS only facilitates you to manage one platform (i.e. a website), then that multi-platform management is either beyond reasonable capability or unwieldy to maintain with separate administrative platforms.

For instance, when you decide to run a seasonal campaign with a microsite, you would like to track your content, analytics, and general web management from your existing system. But if your CMS can only handle one site, or if the cost of additional sites is off limits, then it won't be possible.

Contrary to it, Multi-platform functionality gives your organization flexibility and space to grow.

One of Srijan’s clients, Crain, wanted it to build multi-platform capabilities (11 sites) for them, with each site being managed centrally to reduce inefficiencies and enhance ROI at the same time.

6. Tiered Permissions That Suit Your Organization


WCMS should have some form of tiered access so as to permit users access the platform as tailored for each one of them. For example, some organizations have many content writers but only one or two content publishers. 

Other organizations might need their content writers to be able to upload only certain types of content, while others might be able to publish-but only on certain parts of the site.

So, enterprises should ensure that the CMS should have tiered publishing options- what each level can do, if users can be designated with multiple roles, and how many users are there for each permission level.

7. Business Alignment

Ensure that the CMS you have chosen for your enterprise should meet your unique business requirements. The secret however is, there is no perfect CMS, it can be only made perfect for you. 

Therefore, it’s crucial to understand and pen down your requirements from CMS and use it as your guiding star. Because at the end of the day, you will be the user and not any sales guy offering you upgrades free of cost to an e-commerce storefront, and not the huge community of support and plugin creators, and not even the end user who would love the design.

8. Security

Security is a vulnerable issue for multinational organizations. On ensuring maximum security on their websites, they will not just protect their data but also their customers’ and business from a very public- and potentially devastating exploitation.

So, while considering various WCMS, keep the following points in mind-

  1. What does that CMS platform offers
  2. How much efforts your team will have to put to achieve your security standards
  3. Whether this approach will protect your customers’ data or not
  4. Customers can carry transactional activities without any security concerns.

9. Detailed Analytics

Content marketing team’s work does not limit to pushing content only. Rather they also track engagement on your platform to either continue or tweak their content strategy. WCMS should integrate seamlessly with the most popular analytics tools- like Google Analytics, so that you can track your KPIs right from your dashboard.

A good WCMS should enable your team to gather and analyze the business insights they need. 

For instance, Ez Content is built on top of one the most SEO friendly CMS, which takes your SEO and VSO efforts to the next level. 

10. Powerful Publishing Tools

Much like the content you publish is the foundation of your interaction  with the key audiences, publishing tools, in a similar manner, make the core of any WCMS.

A good WCMS can be identified as the one which can adapt to any type of content you want to publish- from short news items to long form articles with custom layouts to landing pages with embedded documents, while simultaneously integrating this into an overall publication workflow.

In addition, it should be capable of handling SEO, content tagging, inserting images, video, and more from within the publishing interface.

A CMS should be intuitive and easy to understand even for novice users. When working with content, it is also essential to be able to move articles around when needed.

11. Versioning for Quick Rollback

Versioning ensures that you always have an alternate of rolling back to the previous one when something gets published by accident.

A valuable feature in WCMS especially when you plan to update a page or section of your site for an upcoming event or promotion, and want to roll back to the previous version when it’s over.

Summing Up

With continuous evolvement of content management systems, enterprises can expect the addition of the new features to the existing set, primarily focusing on meeting customers’ demands.

From being capable of creating multiple robust websites, easy-to-use publishing tools to delivering personalized content, your next CMS should possess all these cutting-edge features -  to ease the burden of content marketers and help customers as well in finding what they have been looking for!

Jan 23 2020
Jan 23

Agaric leads a migration training at BADcamp 2019

Drupal 7 End of Life is November 2021, and while you can still get mileage from your site, and there will be community long term support for Drupal 7, there are many features in Drupal 8 (and soon Drupal 9) your organization's site will benefit from. Also, getting everything lined up for an upgrade takes time. This is the year many should be putting plans into motion.

At Agaric, we've made upgrades and migrations our main focus in our work to help people leverage the open web to meet their goals. Last year we led 4 migration trainings and presentations, including a sold-out training at DrupalCon. Mauricio even blogged every day in August to share his expertise on Drupal migrations. This year we're hitting the road to help as many people upgrade to Drupal 8 as possible.

Upcoming Trainings

We also plan to propose sessions and trainings at DrupalCamp Spain, DrupalCamp Iceland, Drupal GovCon, DrupalCamp Colorado, DrupalCon Barcelona, BADCamp, and some other DrupalCamps.

Last year, many of our events sold out, so register ahead of time to take advantage of early bird rates and ensure you have a spot.

We're also available for paid consulting work and migration work. If interested, we would love to hear from you

Resources

 Not everyone can attend a training. We've tried as much as possible to also share our knowledge through blog posts and tutorials. Others in the Drupal community have also contributed documentation to make the upgrade/migration process easier.

An upgrade or migration can seem daunting, but we're committed, along with many other Drupal community members, to support one another in making everyone's upgrades as smooth as possible. 

Jan 23 2020
Jan 23

The Drupal Community Working Group is pleased to announce that nominations for the 2020 Aaron Winborn Award are now open. 

This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It includes a scholarship and stipend for the winner to attend DrupalCon and recognition in a plenary session at the event.

Nominations are open to not only well-known Drupal contributors, but also people who have made a big impact in their local or regional community. If you know of someone who has made a big difference to any number of people in our community, we want to hear about it. 

This award was created in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis, or  ALS (also referred to as Lou Gehrig's Disease)  came to an end on March 24, 2015. Based on a suggestion by Hans Riemenschneider, the Community Working Group, with the support of the Drupal Association, launched the Aaron Winborn Award.

Nominations are open until Monday, March 30, 2020. A committee consisting of the Community Working Group members as well as past award winners will select a winner from the nominations. Current members of the CWG and previous winners are exempt from winning the award.

Previous winners of the award are:

  • 2015: Cathy Theys
  • 2016: Gábor Hojtsy
  • 2017: Nikki Stevens
  • 2018: Kevin Thull
  • 2019: Leslie Glynn

Now is your chance to show, support and recognize an amazing community member!

If you know someone amazing who should benefit from this award you can make your nomination using this form.
 

Jan 23 2020
Jan 23

Over the course of Drupal’s lengthy history, one of the most common feature requests has been automatic updates. A common complaint of Drupal site administrators, especially those who have smaller sites updated less frequently, is the frequently complex and drawn-out process required to update a Drupal site from one minor version to another. Updates can involve a difficult set of highly specific steps that challenge even the most patient among us. Indeed, many in the Drupal community simply choose to ignore the automatic e-mails generated by Drupal.org indicating the availability of a new version, and waiting can lead to compounding security vulnerabilities.

Fortunately, the era of frustration when it comes to automatic updates in Drupal is now over. As one of the roughly dozen Drupal Core Strategic Initiatives, Drupal automatic updates are a key feature that will offer Drupal users better peace of mind when minor releases occur. Over the last several years, Tag1 Consulting, well-known as leading performance and scalability experts in the Drupal community, has worked closely with the Drupal Association, MTech, and the Free and Open Source Software Auditing (FOSSA) program at the European Commission to make automatic updates in Drupal a reality.

Recently, I (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) sat down with Lucas Hedding (Senior Architect and Data and Application Migration Expert at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Tim Lehnen (CTO at the Drupal Association), and Michael Meyers (Managing Director at Tag1) to host a Tag1 Team Talks episode about the story of Tag1’s involvement in the automatic updates strategic initiative. In this blog post, we dive into some of the fascinating background and compelling features in Drupal’s new automatic updates, as well as how this revolutionary feature will evolve in the future.

What are automatic updates in Drupal?

Listed as one of the Drupal Core Strategic Initiatives for Drupal 9, Drupal’s automatic updates are intended to resolve some of the most intractable usability issues in maintaining Drupal sites. Updating Drupal sites can be a challenging, tedious, and costly process. Building an automatic updater for Drupal is a similarly difficult problem, with a variety of potential security risks, but it’s a problem that other ecosystems have solved successfully. Following Dries’ announcement of automatic updates as a strategic priority, several early architectural discussions took place, especially at Midwest Drupal Summit 2018 in Ann Arbor.

Automatic updates in Drupal provide certain key benefits for users of all shapes and sizes who leverage Drupal today, including individual end users, small- to medium-sized agencies, and large enterprises. Advantages that apply to all users across the spectrum include a reduction in the total cost of ownership (TCO) for Drupal sites and especially a decrease in maintenance costs.

As for small- and medium-sized agencies and individual site owners, it can be difficult—and deeply disruptive and anxiety-inducing—to mobilize sufficient resources in a brisk timeframe to prepare for Drupal security releases that typically occur on Wednesdays. For many end users and small consultancies who lack experience with keeping their Drupal sites up to date, high-alert periods on Wednesday can be deeply stressful. And for enterprise users, how to incorporate security updates becomes a more complex discussion: Should we integrate manual updates into our security reviews or keep adhering to continuous integration and continuous deployment (CI/CD) processes already in place?

Where are Drupal’s automatic updates today?

The full roadmap for Drupal’s automatic updates is available on Drupal.org for anyone to weigh in, but in this blog post we focus on its current state and long-term future. Automatic updates in Drupal include updates on production sites as well as on development and staging environments, although some integration with existing CI/CD processes may be required. In addition, automatic updates support both Drupal 7 and Drupal 8 sites.

Because of the ambitious nature of the automatic updates initiative, as well as the desire by the module’s maintainers to undertake a progressive approach from an initial module in the contributed ecosystem to a full experimental module in Drupal core, the development process has been phased from initial architecture to present. Currently, a stable release is available that includes features like public safety alerts and readiness checks.

As for other developments within the scope of available funding from the European Commission, in-place automatic updates have also arrived. If a critical security release is launched, and your site has the automatic updates module installed, you’ll receive an e-mail notification stating that an update is forthcoming in the next several days. Once the update is available, the module will then automatically execute the in-place automatic update if all readiness checks show as green on the Drupal user interface, meaning that no additional action is required on the user’s part.

Key features of Drupal automatic updates

Together with MTech, the Drupal Association, and the European Commission, Tag1 has been heavily involved in architecting the best and most graceful approach, particularly in such a way that it can be generalized for and leveraged by other open-source software projects in the PHP landscape. This includes approaches seen in other ecosystems such as readiness checking, file downloading, and signature verification that generates “quasi-patches” as well as inspiration from the WordPress community. One of the team’s major concerns in particular is ensuring the continuous integrity of update packages such that users can be confident that such packages are installed from a trusted source.

There are three key features available as part of automatic updates in Drupal that will be part of the initial release of the module, and we discuss each of these in turn here.

Public safety messaging

After the noted security vulnerability in 2014 commonly known as “Drupalgeddon,” a notice was posted indicating that a critical release was forthcoming. When it comes to automatic updates, a similar process would occur: Several days before a critical security release for Drupal core or for a contributed project in Drupal, a notice would be posted several days prior and available on every Drupal site.

This sort of public safety messaging allows for an additional communication mechanism before a key update so that site owners can ensure they are ready for an update to land. In Drupal sites, the feed of alerts originate from the same security advisories (SAs) that the Drupal Security Team and Drupal’s release managers issue.

Readiness or “preflight” checks

Every Drupal site with automatic updates installed will also have readiness checks, also known as “preflight” checks, that run regularly every six hours through Drupal’s cron and will inform site owners if their site is prepared for an automatic update. Readiness checks are essential to ensure that sites are not functionally compromised after an automatic update.

For instance, if Drupal core has been hacked by a developer, if a site is running on a read-only filesystem, or if there are foregoing database updates that need to be run, readiness checks will indicate that these issues need resolutions before a site can automatically update. There are eight or nine readiness checks available currently, and some are simple warnings to aid the user (e.g. in situations where cron is running too infrequently to update the site automatically in a timely fashion), while others are errors (e.g. the filesystem is read-only and cannot be written to). Whereas warnings will not impede the commencement of an automatic update, errors will.

In-place updates

The final crucial component for automatic updates is in-place updates, the centerpiece of this new functionality. The in-place updates feature in Drupal’s automatic updates downloads a signed ZIP archive from Drupal.org. Using the libsodium library, the feature then compares the signature of the ZIP file to verify that the resulting archive matches Drupal.org’s official archive.

Thereafter, in-place updates will back up all files that are slated for update and update the indicated files. If the process concludes successfully, the site issues a notification to the user that the site has been upgraded. If something fails during the procedure, in-place updates will restore the available backup.

Common questions about automatic updates

On the recent Tag1 Team Talks episode about automatic updates in Drupal, contributors from Tag1 and the European Commission answered some of the most important questions on every Drupal user’s mind as the initiative continues to roll out automatic updates features.

What about using Composer versus tarballs?

One of the key differences between Drupal implementations today is the use of the Composer command-line interface to handle Drupal’s installed modules in lieu of managing module installations through tarballs. Due to the widening use of Composer in the Drupal community, if a site has updated to Drupal 8.8.0 or later, the site will be using Composer. And if the two key Composer-related files in Drupal codebases (namely composer.json and composer.lock) are not modified, automatic updates will continue to function properly. However, for sites leveraging Composer and subsequently modifying the /vendor directory in Drupal codebases, this question becomes more complicated.

At present, the automatic updates team will release early versions supporting all scenarios for Drupal sites, short of those sites that have modified composer.json and composer.lock directly. By observing users as they gradually adopt automatic updates, the team plans to learn much about how users juggle Drupal dependencies in order to release improved update methods that accommodate Composer much more gracefully.

Are automatic updates part of Drupal core?

As of now, automatic updates are not part of a vanilla Drupal installation, but all major components of the module will be incorporated into Drupal core in due course. The in-place updates feature presents the most overt difficulties.

Before in-place updates can land in core, the automatic update team plans to implement an A/B front-end controller that is capable of swapping between two full codebases and toggle back to the backed-up, out-of-date codebase if the update exposes certain issues mid-flight.

What is the future of automatic updates?

While the European Commission has funded the first twelve months of work over the course of 2019, there is much more work to do. The initial European Commission funding accounts for the three aforementioned key features, namely readiness checking, the delivery of update “quasi-patches,” and a robust package signing system, all focused on security updates, which are the most pressing. However, the current year of development excludes better support for Composer and contributed projects.

The longer-term roadmap for automatic updates includes the A/B front-end controller mentioned in the previous section, more robust support for Composer-powered sites, and other types of updates. These include updates for contributed modules and themes as well as batched successful updates for sites that have fallen particularly behind.

Conclusion

Automatic updates will reinvent how we maintain and upgrade Drupal sites, particularly in the realm of security. Because they allow novice and experienced Drupal users alike to save time without the need to worry about how they will implement updates, this strategic initiative improves the total cost of ownership for Drupal users of all sizes and backgrounds.

No account of the extraordinary initiative that is Drupal’s automatic updates would be complete without appreciation for the sponsors of the developers involved, especially from the Drupal Association, MTech, Tag1 Consulting, and the European Commission’s FOSSA program. Organizations and individuals alike have sponsored automatic updates in Drupal to widen awareness of their brands, to showcase their skills as developers, and to attract other Drupal contributors and resource Drupal teams.

To sponsor the continued success of Drupal’s automatic updates, please consider sponsoring development by contacting the Drupal Association. And for more insight into automatic updates directly from the module’s creators, check out our recent Tag1 Team Talks episode on the topic for information we were unable to fit in this blog post.

Special thanks to Fabian Franz, Lucas Hedding, Tim Lehnen, and Michael Meyers for their feedback during the writing process.

Click the following link for our Tag1 Team Talk on Drupal Automatic Updates!

Jan 23 2020
Jan 23

Forums are a great way to create a community of people. This is where they can discuss issues, share skills, or talk about your company’s products. Forums are able to keep your visitors on your website. But this is not all — let’s discuss more benefits of forums, see some best forum website examples, and review how to create a forum on your Drupal 8 website.

Benefits of creating a forum for your website

Having a forum, also known as a discussion board or bulletin board, on your site can be useful in many ways:

  • Understanding your customers: A forum is a place to get to know your customers, which is great for market research. Discover their feedback, issues, questions, and needs about your products or services. You can also study their user personas, improve your products, and brush up your marketing strategy.
  • Helping your customers: A forum enables you to resolve your customers’ issues in the form of official customer support or an unofficial advice board.
  • Increasing website traffic: Forums help you engage and retain your website users. They keep coming back to your site, especially if they need an answer to their particular question. The average session duration, just like the visit rate, increase thanks to the activity.
  • Boosting your SEO: If you create a forum on your website, you boost your SEO. Nested discussions built around more general topics and leading to more specific ones work great with search engines. Google also loves exact questions — if a user asks a question that is addressed on your board, the chances are high they will arrive on your website. In addition, you will automatically have fresh content being created.
  • Inspiring purchases: Discussions of products or services are the first stage of the buyer’s journey. When your prospective customer sees other customers’ comments, photos, videos and more, it may bring them a step closer to the buying decision.
  • Monetizing the forum: An additional benefit you can have from creating a discussion board is monetizing it. There are several ways to monetize a discussion board including subscription fees, advertising, donations from users, affiliate programs, sponsorship and more.

Famous forum website examples

There are plenty of famous examples out there to see what a good discussion board looks like. Let’s look at a few.

Reddit

Reddit — famous forum website example

Ubuntu forums

Ubuntu forums — famous forum website example

Stack Overflow

Stack Overflow — famous forum website example

Boards

Boards — famous forum website example

MoneySavingExpert

MoneySavingExpert — famous forum website example

Ars Technica

Ars Technica — famous forum website example

How to create a forum on your Drupal 8 website

If you have a website created with Drupal (or plan to get one), there is great news for you — the forum functionality is already built-in!

The core Forum module

There is a core module responsible for creating forums. It is turned off by default and needs to be enabled for those who want it.

the core Forum module in Drupal 8

Creating categories and subcategories

You decide what hierarchy structure your discussion board will have. In “Structure,” there now is a “Forums” tab that enables you to add forums and containers. Containers can be used to group related forums together.

The module also provides a ready-made forum “General discussion” that we can rename or delete.

Adding a forum in Drupal 8

Your discussions can have categories and subcategories, aka parent and child forums. For example, let’s create a forum called “Drudesk services.” It is going to be the main one and, in its settings, the “Parent” is set as “root.”

Creating forum categories in Drupal 8

Let’s add a couple of subforums (e.g. “Drupal development” and “Drupal support.” The procedure is the same (the “Add forum” button). The only difference is that we need to set the “Parent” as “Drudesk services.” Next, we can add more detailed subcategories to our subcategories by setting the right “Parent” every time.

Forum categories and subcategories in Drupal 8

We can see what it looks like on the default page created by Drupal by checking the address /forum, or simply by clicking the right category link. However, we see that the number of topics and posts is null because we still need to create topics.

Simple forum page in Drupal 8

Adding forum topics

Forum topics will be posted like any other content nodes. The module has created a content type “Forum topics” for this. For the user’s convenience, there is also the “Add the forum topic” button on the Forums page.

When creating a topic, we need to select which category or subcategory we want to post it.

Adding forum topics in Drupal 8

The answers to each topic will be posted like comments to each node. In our example, after we have posted one topic and one comment (or reply), we see that the count of topics has changed to 1 and the post count to 2.

A forum topic in Drupal 8Simple forum with posts in Drupal 8

Forum participant permissions

Now it’s time to determine who can view, add, edit, and delete the topic and comments. A common option is allowing authenticated Drupal users in “People — Permissions.” Alternatively, it’s possible to create a separate Drupal role if you want to make a membership forum for subscribers only.

Check out our video tutorial about how to create a forum on your Drupal 8 website.

[embedded content]

Entrust our Drupal experts with creating your board

Inspired to create a forum on your Drupal website? The above example has been a rough sketch. Your discussion board will look exactly as you wish.

If you want to change the style or position on your website, add a feed with the latest discussions on other pages, or explore the many other options, our Drupal development experts can configure it out. Contact us and enjoy an attractive and user-friendly forum!

Jan 23 2020
Jan 23

Yes. “Prelaunch anxiety” is a thing. 
You have worked tirelessly on your Drupal 8 website for weeks/months together and now the most important day has arrived – the launch day! But wait! Have you done everything right to ensure your Drupal website does not run into any unforeseen issues? It is always best to compile a checklist of things to do a few days before the launch to make sure you have everything in place and that your website is not under any kind of risk. Don’t have a Drupal checklist yet? Put your mind at ease with our compiled prelaunch Drupal checklist for developers.

Are the File Permissions set right?

This is one of the top items in our pre-launch Drupal checklist. To secure your Drupal website, the first step you must take is to set the file permissions right. Make sure your web server is not given permission to edit or write the files that it executes. Automated tools to set and verify permissions like File Permissions and Security Review Module, can also be used. The PHP Filter Module under /admin/modules needs to be disabled, if your site is using Drupal 7. The settings.php file should be secure so that the database connection information is protected. 

Drupal Security Updates?

Drupal has been a choice of Content management system for various organizations but particularly so for organizations that deal with critical data. The reason why Drupal is known to become a secure CMS is because of the Drupal security team’s constant effort to keep it safe. With every major/minor release, security updates are shipped out. Many of them address immediate security risks. You will get warning messages when your Drupal security has lapsed.  Make sure your Drupal 8 release is up to date with all the security releases and patches. Keep your modules and core updated. You could also check for security updates manually by clicking on Reports and then checking for Available Updates.

Secure your admin’s account name

The Admin account is the root account that is used for any Drupal website development. Securing the root account is very important and should not be ignored. The installation is extremely vulnerable to hacker attacks as it isn’t hard to guess the username for the hacker. So the root account name should be changed to a more complex one (before launch at least) and a strong password must be used. You can use the Real AES module to tighten up your security. Also, when granting user permissions, ensure minimal permissions are given to anonymous users and all permissions granted to them should also be given to authenticated users.

Don’t let your users see those Error reports!

Because it can get very annoying. Error reporting should be turned off such that it must write the errors onto a log but does not display it to the users. To disable error reporting, go to Configuration > Development > Logging and Errors, set the option to None, which will disable all the error reporting. It should be ensured that 404 errors are handled well. Using Drupal modules like Search 404 helps in displaying more helpful content like search results based on the URL the user has been searching for.

search 404 module

Search 404 Result:

search 404 modules

Content and Search Engine Optimizing for your Drupal 8 website

You must ensure that all your site’s contents are displayed correctly. Don’t forget to run your site through the Lorem Ipsum scanner before launching. You might have missed to change all the dummy text when you have a lot of pages to go through. There are some great SEO modules that will boost traffic to your site after you launch.  Using the PathAuto Module is extremely important for Drupal web development as it will generate friendly URL’s instead of a URL that will look like this www.specbee[dot]com/node/3843. It is also recommended to use the Redirect Module along with PathAuto as it allows users to redirect from old URLs to new URLs. Because if you have two URL’s (with alias name) that represent the same content, it can be very harmful for your SEO ranking.

Redirect Module Settings

Redirection module

Redirection Module:

add url redirection

Check Your Drupal Modules

Unused Drupal modules end up taking up space and makes your website slow. Ensure only those modules that are being used are enabled. Removing unused modules will help with your website’s start-up time. You could also use a Drupal module for this – Unused Modules. Also, it is recommended to disable the Devel module and similar modules during launch. Make sure your modules are up to date with its latest releases. Using a Drupal 8 module like the Site Audit can be extremely beneficial as it analyses your website for performance and behavior. It gives you a report that tells you if you have followed best practices (else gives recommendations), website’s caching settings, codebase (size and file count), unused content types if any, and much more.

Server Configuration

Check the file upload sizes. This is to allow users to upload large media files from your Drupal website. To do this, you may need to adjust the server configuration. It is also important to check the execution time. You can do so by setting the max_execution_time in the server configuration. Also don’t forget to check that all the forms and modules are being sent to the correct email addresses.

Is your Drupal site optimized for performance?

There are many things a Drupal developer can do to optimize the performance of your Drupal website, like

  • Caching –configuring caching will boost the performance of your website. Caching for some modules are turned off by default – so make sure they are turned on. Drupal 8 core comes packed with modules like the Internal Page Cache module and the Internal Dynamic Page Cache module
  • CSS and Javascript – a typical Drupal website will have a lot of Javascript and CSS files which will increase the number of HTTP calls for each page. However, one can compress all these relevant files by enabling the Advanced CSS/JS Aggregation feature in the performance section.

CRON jobs?

These time-triggered actions can help in checking for updates, re-indexing the search mechanism, retrieving feeds, notifying other sites of updates and perform routine maintenance tasks. It is also recommended to configure CRON for security and performance reasons.

Jan 23 2020
Jan 23

Drupal’s massive and passionate community has long been the envy of the open-source world. The many thousands of active contributors to Drupal are its strength, and one of the key reasons Drupal continues to be a force while others have stumbled.

With the release of Drupal 9 rapidly approaching, the support of the community is more important than ever. Here’s your chance to make the first release of Drupal 9 even better!

The annual Drupal Global Contribution Weekend, where Drupal User Group Meetups all over the world volunteer Drupal development time and make open-source contributions, is this weekend.

Anyone can take part in this initiative either from the comfort of their own home or at a contribution event near them. It is a great way to meet new people, learn about Drupal, and be part of something bigger. 

Check this Drupal map to see if there is a group meeting near you.

If you are planning to attend Southwestern Ontario’s contribution Meetup event in London, Canada on January 25th, (still time to RSVP) read on to get some helpful pre-event recommendations. 

Drupal 8 license plate

Pre-Attendance Checklist

Here are five things you can do ahead of time so that you are prepared for a quick start - especially if you have not contributed to Drupal core before: 

  1. Create a user account on Drupal.org if you do not have one
  2. Install Git on your laptop* (Yes, you will need a laptop)
  3. Make sure your laptop has a local development environment* (more on this later)
  4. Set up Drupal*
  5. Have some knowledge of how to create and apply patches using git*

Do as many of these steps beforehand as you can. If you need help with one or more, someone can help you on the day. 

*Not mandatory if you plan to contribute to documentation or marketing issues on Drupal.org, instead of code.

Resources For Beginners

Some other things we recommend beginners do ahead of time is to get familiar with the following resources:

  • Search the Drupal 8 Issue Queue. A list of issues tagged as ‘novice’ can be found here.  
  • Read guidelines on how to make a good issue.
  • Chat with the Drupal community using Slack and speak to core maintainers directly in the #contribute channel.
  • Join the slack channel for #Global-contribution-weekend
  • Read Echidna’s How to Contribute to Drupal blog series 

Local Development Environment

To have a successful contribution weekend you will need a solid local development environment and to install the latest development branch of Drupal. You can use any local environment you are comfortable with and in my opinion, either Pantheon, XAMPP, or the Acquia Dev desktop, would have what you need.

  • Pantheon sandbox is easy to setup. You can work with it either in SFTP or Git mode if you don't want to set up a server on your computer. 
  • XAMPP is a simple, lightweight Apache distribution that works well to create a local web server for testing and deployment purposes.
  • The Acquia dev desktop local comes with almost all tools you would ever need - Apache, PHP, mySQL and drush - and it installs Drupal in one click so you can get going, faster.

At the Southwestern Ontario event, we will have available a limited number of older machines ready and set up, specifically for guests to use for writing and testing patches, etc. 

Social

Finally, let people know you participated on your social media by using the hashtags #ContributionWeekend #Drupal, and tag the Drupal Users Group that organized the event you attended. 

For Southwestern Ontario's event, use @LondonDUG and hashtag #WRDUG, download and post this badge. 

London Ontario building with loon

Digital Echidna is a proud sponsor of the Southwestern Ontario Global Drupal Contribution Event 2020. 

--

 

Jan 23 2020
Jan 23

On Wednesday, March 18, MidCamp will offer four full-day training sessions to get you a deep dive into Gatsby, Composer, A/B Testing, or Migrate API.

Read more about each, then register! Only 25 seats are available for each training, so they'll go fast. Each training costs $85, which includes lunch and coffee. Trainings are ticketed separately from our main sessions on Thursday and Friday.

Jan 22 2020
Jan 22

WebRTC, a protocol that facilitates peer-to-peer communication between two clients via the browser, is now supported by all modern browsers. Since its introduction it has mainly been used for web conferencing solutions, but WebRTC is ideal for a variety of other use cases as well. Because of its wide platform support, creating peer-to-peer applications for the web is now more straightforward than ever. But how do you manage many people working together at the same time on the same data? After all, conflict resolution for peer-to-peer applications remains a challenging problem. Fortunately, with Yjs, an open-source framework for real-time collaboration, developers can now combine WebRTC and Yjs to open the floodgates to a range of future-ready collaborative use cases.

Thanks to WebRTC and Yjs, anyone can build collaborative editing into their web application, and this includes more than just text Yjs enables collaborative drawing, drafting, and other innovative use cases. The advantage of such a peer-to-peer model (in lieu of a client–server model) in the CMS world is that collaborative editing can be added to any editorial interface without significant overhead or a central server handling conflict resolution. By integrating with y-webrtc, the Yjs connector for WebRTC, CMS communities can easily implement collaborative editing and make it natively available to all users, whether on shared hosting or in the enterprise. The future of Drupal, WordPress, and other CMSs is collaborative, and, together, WebRTC and Yjs enable collaborative editing out of the box.

In this deep dive into how Yjs enables peer-to-peer collaboration, join Kevin Jahns (Real-Time Collaboration Systems Lead at Tag1 and creator of Yjs), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Michael Meyers (Managing Editor at Tag1), and Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a closer look at how you too can build peer-to-peer collaboration into your decentralized application.

[embedded content]
Jan 22 2020
Jan 22

WebRTC, a protocol that facilitates peer-to-peer communication between two clients via the browser, is now supported by all modern browsers. Since its introduction it has mainly been used for web conferencing solutions, but WebRTC is ideal for a variety of other use cases as well. Because of its wide platform support, creating peer-to-peer applications for the web is now more straightforward than ever. But how do you manage many people working together at the same time on the same data? After all, conflict resolution for peer-to-peer applications remains a challenging problem. Fortunately, with Yjs, an open-source framework for real-time collaboration, developers can now combine WebRTC and Yjs to open the floodgates to a range of future-ready collaborative use cases.

Thanks to WebRTC and Yjs, anyone can build collaborative editing into their web application, and this includes more than just text Yjs enables collaborative drawing, drafting, and other innovative use cases. The advantage of such a peer-to-peer model (in lieu of a client–server model) in the CMS world is that collaborative editing can be added to any editorial interface without significant overhead or a central server handling conflict resolution. By integrating with y-webrtc, the Yjs connector for WebRTC, CMS communities can easily implement collaborative editing and make it natively available to all users, whether on shared hosting or in the enterprise. The future of Drupal, WordPress, and other CMSs is collaborative, and, together, WebRTC and Yjs enable collaborative editing out of the box.

In this deep dive into how Yjs enables peer-to-peer collaboration, join Kevin Jahns (Real-Time Collaboration Systems Lead at Tag1 and creator of Yjs), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Michael Meyers (Managing Editor at Tag1), and Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a closer look at how you too can build peer-to-peer collaboration into your decentralized application.

[embedded content]
Jan 22 2020
Jan 22

Automated tests are rapidly becoming a prerequisite for successful web projects, owing to the proliferation of automated testing tools and an explosion of continuous integration (CI) services that ensure the success of web implementations. Nonetheless, for many developers who are new to the space, automated testing can be an intimidating and altogether novel area that causes more than a few groans at weekly meetings. Luckily, with the right development culture and testing infrastructure in place, your team can focus on implementing new features rather than worrying about the quality of their code.

Yuriy Gerasimov (Senior Back-End Engineer at Tag1 Consulting) delivered a presentation at DrupalCon New Orleans about automated testing and its advantages for web projects of all shapes and sizes. In this four-part blog series, we explore some of the essentials that all developers should be aware of as they explore automated testing as well as the key fundamentals you need to know to incorporate automated testing into your daily workflows. In this second installment, we inspect how to implement a robust testing infrastructure and how to cultivate a development culture favorable to automated testing with the help of code checks.

Key elements of automated testing

Over the course of his career, Yuriy has interacted with a variety of consultancies to gather anecdotal evidence of how automated testing has worked across a range of scenarios. What he discovered is that most orgs tend to implement testing infrastructures and automated testing on a project-by-project basis rather than incorporating it as a part of their regular process for every project. This betrays a fundamental disconnect between the value that automated testing can provide and the inevitable inefficiencies that arise when automated testing is added to individual projects on an ad-hoc basis.

Implementing robust testing infrastructures

One of the classic problems that arise from such a situation is the notion of development teams only implementing a continuous integration (CI) server when customers are able to provide for it in the project budget. In other words, either you can build a server that extends a development culture centered around automated testing, or you risk a scenario in which shared characteristics and shared testing components are absent across projects, requiring you to bootstrap a new infrastructure every time.

Even upon improving quality in your projects thanks to a robust testing infrastructure, code reviews are essential and will allow your interactions between your team’s developers to be elevated to a higher caliber. Unfortunately, however, developers tend not to share substantial knowledge after they complete the features they are tasked to complete. If a developer sees a colleague not following best practices, code reviews can foster improvements in the code thanks to the knowledge that all parties gain in the process. Because of this, Yuriy suggests that development teams leverage a source control provider like GitHub, Bitbucket, or GitLab that incorporates built-in peer reviews functionality.

Fostering a development culture conducive to testing

Development culture is also essential to ensure the success of automated testing. This means that all developers should understand how the testing infrastructure functions in order to guard against regressions. When deployments are not tied to individual team members, for instance, this means that all members of the team understand how deployment occurs and are thus able to implement improvements themselves. For this reason, we discourage blocking deployments on a single function or individual contributor.

The optimal situation is one in which even a project manager who does not write code is capable of initializing deployments and kicking off a series of automated tests. When deployment is automated in this way to the point where even team members uninvolved in development can understand how quality is assessed across the project, this can level up the skill sets of the entire team.

For example, Yuriy recommends that every new developer on a team conduct a deployment themselves in isolation from the rest of the team. By doing so, the least experienced individual contributor may encounter inefficiencies theretofore unaccounted for by other team members and catalyze improvements in the quality of the code. When collaborators who are not yet on-boarded are able to foster advancement in the testing infrastructure across the team, the benefits can not only enrich the automated tests themselves but also cultivate a highly improved development culture across the board.

Considering maintenance costs

Nonetheless, maintenance costs are an important facet of automated testing to consider for any implementation, large or small, because they may be sufficiently exorbitant to encourage recalibration in the testing infrastructure. Some of the key questions to ask include: Do you have enough people to maintain the system from end to end? Do you have a dedicated systems administrator or DevOps specialist who can correct issues when discovered?

After all, testing infrastructures tend to be the components of projects that are scrutinized the least once they are complete—this is part of the blessing and curse of the notion of a “one and done” mindset. In the end, every project has different requirements, and other upcoming projects may demand different systems or other approaches to the same problem. When selecting automated testing systems, therefore, it is essential to consider their impact on the maintenance costs that your team will inevitably incur.

Code checks

Among the easiest and simplest to implement, code checks are static analyses of code that are not only educational about the code’s quality itself but also can perform very quickly unless your codebase includes hundreds of megabytes of code. As Yuriy notes, in that case, you have other problems to solve first. For many Drupal development teams, code checks for adherence to Drupal coding standards are the first line of defense against potential regressions.

By the same token, security checks, which evaluate the risk of potential vulnerabilities, are also critical. Security checks are capable of verifying that certain best practices are followed when it comes to possible attack vectors, such as the use of globals or session variables in key functions or the allowance of input into deeper recesses of Drupal without proper sanitization. These checks are also convenient in that in many cases, less experienced developers can run security checks and understand the implications of the results without consulting a more senior developer. Along these same lines, linters, which check for syntax errors and the like, can be hugely beneficial for front-end developers.

Complexity metrics and copy-paste detection

Another fascinating selling point for code quality is complexity metrics, which are comprised of assessments of how complex the code is. Among the most important of these is cyclomatic complexity. Consider a scenario in which you have written a function that contains a foreach cycle with multiple control structures (many if-statements) nested within. If your function has many levels of nesting, this can present problems not only in code readability and the likelihood of introducing bugs but also in maintenance. Code checks that analyze cyclomatic complexity can help you to uncover situations in which others would have a horrible experience reading your code by limiting the number of levels that code can be nested (e.g. no more than five levels). Such complexity metrics will aid you in isolating certain logic into other functions or exiting early from your cycles to help your code become more legible.

Finally, copy-paste detection is another hugely useful element of code checking that allows for you to encounter inefficiencies in code. Some developers, for better or worse, often copy and paste code from examples or Stack Overflow responses without necessarily considering how it can best be incorporated into the existing codebase. Copy-paste detection can thus inspect the code to detect code pasted in multiple places; if you use the same piece of code in multiple locations, it may be best to abstract it out by isolating it into another function instead.

Conclusion

All told, code checks are often so immediate that they can take mere fractions of a second. For this reason, they are a ubiquitous element of automated testing and can allow developers to become more productive in a short period of time. In this way, your team can create not only a robust underlying testing infrastructure well-suited for repeatability but also ensure the longevity of a testing-oriented development culture that values consistent code quality.

In this blog post, we covered some of the most crucial elements of any automated testing approach for projects both large and small, namely a robust testing infrastructure and a focused development culture for automated testing. In turn, we looked at the outsized benefits that code checks and security checks can have on your codebase. In the next installment of this four-part blog series, we will devote our attention to some of the other essentials in the testing toolbox: unit testing and functional testing.

Special thanks to Yuriy Gerasimov, Jeremy Andrews, and Michael Meyers for their feedback during the writing process.

Jan 22 2020
Jan 22

Automated tests are rapidly becoming a prerequisite for successful web projects, owing to the proliferation of automated testing tools and an explosion of continuous integration (CI) services that ensure the success of web implementations. Nonetheless, for many developers who are new to the space, automated testing can be an intimidating and altogether novel area that causes more than a few groans at weekly meetings. Luckily, with the right development culture and testing infrastructure in place, your team can focus on implementing new features rather than worrying about the quality of their code.

A few years back, Yuriy Gerasimov(Senior Back-End Engineer at Tag1 Consulting) delivered a presentation at at DrupalCon New Orleans about automated testing and its advantages for web projects of all shapes and sizes. In this four-part blog series, we explore some of the essentials that all developers should be aware of as they explore automated testing as well as the key fundamentals you need to know to incorporate automated testing into your daily workflows. In this second installment, we inspect how to implement a robust testing infrastructure and how to cultivate a development culture favorable to automated testing with the help of code checks.

Key elements of automated testing

Over the course of his career, Yuriy has interacted with a variety of consultancies to gather anecdotal evidence of how automated testing has worked across a range of scenarios. What he discovered is that most agencies tend to implement testing infrastructures and automated testing on a client-by-client basis rather than incorporating it as a part of their regular process for every project they come across. This betrays a fundamental disconnect between the value that automated testing can provide and the inevitable inefficiencies that arise when automated testing is added to individual projects on an ad-hoc basis.

Implementing robust testing infrastructures

One of the classic problems that arise from such a situation is the notion of development teams only implementing a continuous integration (CI) server when customers are able to provide for it in the project budget. In other words, either you can build a server that extends a development culture centered around automated testing, or you risk a scenario in which shared characteristics and shared testing components are absent across projects, requiring you to bootstrap a new infrastructure every time.

Even upon improving quality in your projects thanks to a robust testing infrastructure, code reviews are essential and will allow your interactions between your team’s developers to be elevated to a higher caliber. Unfortunately, however, developers tend not to share substantial knowledge after they complete the features they are tasked to complete. If a developer sees a colleague not following best practices, code reviews can foster improvements in the code thanks to the knowledge that all parties gain in the process. Because of this, Yuriy suggests that development teams leverage a source control provider like GitHub, Bitbucket, or GitLab that incorporates built-in peer reviews functionality.

Fostering a development culture conducive to testing

Development culture is also essential to ensure the success of automated testing. This means that all developers should understand how the testing infrastructure functions in order to guard against regressions. When deployments are not tied to individual team members, for instance, this means that all members of the team understand how deployment occurs and are thus able to implement improvements themselves. For this reason, we discourage blocking deployments on a single function or individual contributor.

The optimal situation is one in which even a project manager who does not write code is capable of initializing deployments and kicking off a series of automated tests. When deployment is automated in this way to the point where even team members uninvolved in development can understand how quality is assessed across the project, this can level up the skill sets of the entire team.

For example, Yuriy recommends that every new developer on a team conduct a deployment themselves in isolation from the rest of the team. By doing so, the least experienced individual contributor may encounter inefficiencies theretofore unaccounted for by other team members and catalyze improvements in the quality of the code. When collaborators who are not yet on-boarded are able to foster advancement in the testing infrastructure across the team, the benefits can not only enrich the automated tests themselves but also cultivate a highly improved development culture across the board.

Considering maintenance costs

Nonetheless, maintenance costs are an important facet of automated testing to consider for any implementation, large or small, because they may be sufficiently exorbitant to encourage recalibration in the testing infrastructure. Some of the key questions to ask include: Do you have enough people to maintain the system from end to end? Do you have a dedicated systems administrator or DevOps specialist who can correct issues when discovered?

After all, testing infrastructures tend to be the components of projects that are scrutinized the least once they are complete—this is part of the blessing and curse of the notion of a “one and done” mindset. In the end, every project has different requirements, and other upcoming projects may demand different systems or other approaches to the same problem. When selecting automated testing systems, therefore, it is essential to consider their impact on the maintenance costs that your team will inevitably incur.

Code checks

Among the easiest and simplest to implement, code checks are static analyses of code that are not only educational about the code’s quality itself but also can perform very quickly unless your codebase includes hundreds of megabytes of code. As Yuriy notes, in that case, you have other problems to solve first. For many Drupal development teams, code checks for adherence to Drupal coding standards are the first line of defense against potential regressions.

By the same token, security checks, which evaluate the risk of potential vulnerabilities, are also critical. Security checks are capable of verifying that certain best practices are followed when it comes to possible attack vectors, such as the use of globals or session variables in key functions or the allowance of input into deeper recesses of Drupal without proper sanitization. These checks are also convenient in that in many cases, less experienced developers can run security checks and understand the implications of the results without consulting a more senior developer. Along these same lines, linters, which check for syntax errors and the like, can be hugely beneficial for front-end developers.

Complexity metrics and copy-paste detection

Another fascinating selling point for code quality is complexity metrics, which are comprised of assessments of how complex the code is. Among the most important of these is cyclomatic complexity. Consider a scenario in which you have written a function that contains a foreach cycle with multiple control structures (many if-statements) nested within. If your function has many levels of nesting, this can present problems not only in code readability and the likelihood of introducing bugs but also in maintenance. Code checks that analyze cyclomatic complexity can help you to uncover situations in which others would have a horrible experience reading your code by limiting the number of levels that code can be nested (e.g. no more than five levels). Such complexity metrics will aid you in isolating certain logic into other functions or exiting early from your cycles to help your code become more legible.

Finally, copy-paste detection is another hugely useful element of code checking that allows for you to encounter inefficiencies in code. Some developers, for better or worse, often copy and paste code from examples or Stack Overflow responses without necessarily considering how it can best be incorporated into the existing codebase. Copy-paste detection can thus inspect the code to detect code pasted in multiple places; if you use the same piece of code in multiple locations, it may be best to abstract it out by isolating it into another function instead.

Conclusion

All told, code checks are often so immediate that they can take mere fractions of a second. For this reason, they are a ubiquitous element of automated testing and can allow developers to become more productive in a short period of time. In this way, your team can create not only a robust underlying testing infrastructure well-suited for repeatability but also ensure the longevity of a testing-oriented development culture that values consistent code quality.

In this blog post, we covered some of the most crucial elements of any automated testing approach for projects both large and small, namely a robust testing infrastructure and a focused development culture for automated testing. In turn, we looked at the outsized benefits that code checks and security checks can have on your codebase. In the next installment of this four-part blog series, we will devote our attention to some of the other essentials in the testing toolbox: unit testing and functional testing.

Special thanks to Yuriy Gerasimov, Jeremy Andrews, and Michael Meyers for their feedback during the writing process.

Jan 22 2020
Jan 22

Whether RSS has a future or not is debateable, but I often find myself removing the standard RSS icon in Drupal, sometimes for good or sometimes for just placing a nicer version of the classic icon somewhere else in my theme, linked to the RSS feed.

In Drupal, like with so many other things, there are several ways of removing the RSS icon in the theme. I'm going to show you the way that I have found to be the easiest and the way that also sticks when you're trying out, or switching to a new theme.

The frontpage of Drupal where we automatically is served an RSS icon with a link to the feed.The frontpage of Drupal where we automatically is served an RSS icon with a link to the feed.

Sure, you can remove the icon in the theme you're putting together, or you can hide it with CSS (don't do that, that weakens your SEO ranking) so the way I'm going to show you is within the system, within the awesome thing that is Views.

What... Views?

For those who don't know it, Views is a module in Drupal (up until version 7 of Drupal it was a stand-alone module, but from version 8 it's part of Drupal and makes every listing a view, which is awesome!). Views can be described as a "point and click interface to ask simple or complicated questions about the content of the website", or "a graphic way to get content in listings (or just one result) from the database". Whatever you want to use Views for, it's highly competent and when you get to know the way Views in Drupal works, it's only your imagination that set the limits of what you can do with the content after that.

Every listing you see in Drupal, both the listings for the editor and the listings that visitors can see and visit, are powered by Views. And you are able to edit all of these, able to bend them to your pleasing.

With that said, let's dig into Views and make a teeny, tiny change that'll remove our RSS icon.

Structure -> Views

Log in to your website, navigate to Structure and then Views. The image below shows the way (the dropdown menu is not native to Drupal, it's an add-on module (or plugin if you will) called Admin Toolbar.

Image showing where to click in Drupal to get to the Views sectionClick "Structure" and then "Views" to get to Views section of Drupal.

Behold! Views!

When accessing Views for the first time, it's kind of boring. It's only a listing of different Views that you know nothing about.

The landing page for Views in Drupal

Well... See this as a "beginning of a beautiful friendship".

Different displays in Views

Another thing you need to grasp before heading into the interface of Views is "displays".

You can have as many Views as you want, but it's common and recommended that you collect them and sort them depending on what the views are for. 

For example. If you want to have three content listings - perhaps landing pages - showing the articles you have written but you want to sort them differently or want to show different version of the content depending on the situation. In the first listing you want to show everything - preamble, the article itself, images and a description of you as an author. The second listing should only include a small version of the article image and the preamble - to tease your readers. And the third listing should only include the title and the date of when the post was published. Since all these three listings handles the same content in some way, it recommended that you create one View, and have three different displays in that View.

There are many different displays in Views - and you can add and create your own - but this article will only mention them.

Different displays in Views

Let's dig in!

Time to do the thing we're here for. Time to edit a view! And not only a view - one of the displays of a view!

Start by finding the View called Frontpage and then click Edit to start editing the View we want to change.

Click Edit for the view called Startpage

What you see next can be a bit much, but don't worry, we won't go into the depths that are Views, we are just going to do some clicking around, uncheck a checkbox and save the view to accomplish what we are here for.

What we are editing now is the list of content that are shown on the frontpage of Drupal, and the feed icon is there because there is another Display in this View.

Remember, you are recommended to use one View for similar content and here is another great example: content shown to visitors and a RSS feed, shown also to users, but with a RSS Reader of some kind. Same content - shown in two different ways.

This View has two displays: Page (the one that are used as frontpage) and Feed (the RSS feed). The RSS feed is represented by the icon and are attached to the Page display. In other words, whereever the Page is shown, the feed tags along like an annoying little sister or brother.

The two different displays of the View

Ok, let's remove the RSS icon now already!

Yes, time to operate! We are going to edit the second display, the Feed, and detach that one from the first display, the Page.

To do that, click the display for the Feed.

Then, in the middle column, find Feed Settings. 

Next to Attch to:, click Page.

Uncheck the Display called Page.

Click Apply.

End this by clicking Save, to save the View and make your changes take action on your website.

And, voilà, when you visit the frontpage of your website, the icon is gone!

Think of this as well

Even if the icon is gone, the feed is still active and can be accessed via the URL /rss.xml. If you want to remove the feed, you need to deactivate the Feed display in the View called Frontpage.

You can choose to disable the feed altogether

Another way to make the feed more difficult to find is to change the URL to the feed, set your own path to it.

Under Feed settings in the middle column of the View, click the /rss.xml path to change it to whatever you want. Don't forget to Save the view after you've changed something.

You can change the path to the RSS feed as well

"But wait, there's more..."

Yes. There is one other thig to remember. Well, there are many other thigs, but Drupal also generates RSS icons to taxonomy feeds as well. Taxonomy is the name for terms, tags, categories, and these are displayed by default in Drupal.

The taxonomy listing is structured in the same way as the Frontpage, with two displays where the Feed is attached to the Page. So to remove the RSS icon from the feed of taxonomy terms all you need to do is to repeat the process shown above but within the View called Taxonomy term.

Also change the view called Taxonomy Term

That's it!

That's my way of removing that pesky RSS Icon. Hope you have enjoyed the guide. Please feel free to read some of my other guides and walk-throughs in Drupal.

TL;DR;

For those who already know Drupal: Detatch the Feed display from the Frontpage Page display in Views. Repeat with Taxonomy Term if you want to remove the RSS Icon from that listing as well.

Jan 21 2020
Jan 21

Drupal is often spoken about as far more than an open source project, because our global community is vibrant and passionate; a model for other projects to learn from and emulate. There are many ways to be a Drupal ambassador: by mentoring others, by helping people answer why they should use Drupal, and why they should contribute. In addition, I have a few ideas on ways you could be an ambassador for Drupal by sharing about yourself with the global community. By participating, you help put a story behind the people of Drupal, and you show the broader community why the Drupal Association needs support. We'd love to have you involved!

Give a testimonial


".... because of it's wonderful community which has such inspiring contributors spread around the world. Being a member fills me with immense positive energy :)" — Surabhi Gokte (surabhi-gokte)

Get inspiration from the testimonials and share your own.

Be featured on Drupal.org

We're running the banner ad on Drupal.org - visible only to users who don't have an active membership. You may see these banners throughout the year (usually for a week-long run) if you visit without being logged in. To participate, email me or chat on Slack (lizzjoy). 

We rely on Drupal. Our team feels responsible to contribute back to the project and participate in its growth. - Baddy Breidert, Drupal Association Board and Co-Founder of 1xINTERNET.
Drupal.org banner featuring Baddý Breidert (baddysonja).

Thanks to DrupalCon for a boost in motivation. I joined the Drupal Association because being a member in the first place fosters contribution in other areas of the community, too. - Christian Schnabl, Founder & Developer, 42robots.
Drupal.org banner featuring Christian Schnabl (snable).

MemberMondays

Monica S. Flores is organizing DrupalCamp Hawaii 2020 and is learning and sharing more ways to foster inclusion in technology with @drupaldiversity. She's been a pianist since childhood, and is interested in learning how to do music composition. Say hi to her at DrupalCon! #MemberMondays
From this month's #MemberMondays.

This month, we've launched social posts about a different member each week. We're calling it #MemberMondays. You can share about yourself in this questionnaire.

I hope you participate— it would be wonderful to share about you with the global community. If you are interested, but feel you don’t have time or are hesitating, let us know.

Jan 21 2020
Jan 21

Bloomington Public Schools website

From chaotic and disjointed to streamlined and cohesive

Bloomington Public Schools (BPS) has been a client since 2011. We migrated them from SchoolFusion back then and helped them design, architect and develop The Hub, a parent and student portal in 2013. Not only have we been keeping their district and accompanying school websites updated and secure, we’ve been adding features to The Hub. In 2019, they decided it was time to re-architect their district and school sites to be user focused and consolidated under one domain. So we helped them with their strategy, redesigned the site and migrated to Drupal 8.

“We already had a good working relationship with TEN7. They know our organization, they know our systems,” said Andrea George, BPS Communication Specialist. “When that’s the case, you get a different level of collaboration and outcome, versus when you just start to work together. We didn’t know how big of a benefit that would be.”

The redesign was going to be a big job, as the sites had issues on many fronts:

  • Content: Things had gone a bit “wild west.” There were 3,000 content items on the site (!), and a large chunk of them were expired news content or dead pages created for one-off purposes.
  • Usability: User feedback (parents and staff) overwhelmingly said that it was too hard to find information they needed. The navigation wasn’t intuitive, was different on each school site and was located in different places on school pages, and in general the page designs just weren’t user friendly.
  • Search: The search didn’t work well, and was bringing up really old content.
  • Design: The sites were over seven years old—a lifetime in internet years—and the design was starting to show its age. Each of the 15 schools lived on its own subdomain, had its own visual identity and there was no visual design relationship between schools, or between the schools and district pages.

Our assignment: cull content and design a user-focused district-wide site

When you redesign legacy sites, the best place to start is with content strategy and a content audit. “Since we were truly starting from scratch, and we were not going to automatically migrate content over, we were committed to looking at EVERYTHING,” said Andrea.

Lynn Winter, our Content Strategist, went through two content purge rounds. The first identified content that should absolutely be removed, like outdated content, and “dead” pages no one was visiting. The second round identified content that could be combined or removed, but that needed BPS review. When it was all over, Lynn and BPS had pared 3000 content items down to about 1000.

To avoid the same content chaos on the new site, BPS wanted to be more intentional about allowing content on the site. Webmasters from each school would be gatekeepers for content, and there would be an approval process for any potential new site content. To assist with this, Lynn ran a workshop with the BPS marketing department to teach them how to rigorously evaluate content, both to determine what should be recreated on the redesigned site, and to help them determine criteria for adding content to the website in the future.

On the infrastructure side, we rebuilt the sites on Drupal 8, got rid of the subdomains they were using and unified the district site and all the school sites under a single domain. We set up the Drupal Group module to provide relationships between the content on the site and group entities. The module also manages permissions and roles for each school, which would help in the future content approval process. We implemented SOLR for search on the back end, with rules to make search results only show current school year content and prioritize recent content. We also added a keyword field to each page, so it could show in results even if a desired keyword isn’t part of the organic page content.

With the content and infrastructure nailed down, the design challenge was: how do we create one design to accommodate the branding distinction of individual schools? We decided the district brand should be the strongest, and we kept a tight shared design aesthetic between the district and school branding. To keep brand impressions consistent between schools, all the schools have a consistent design, with differences occurring in their unique logo, and a distinctive color palette, chosen from the BPS “super style guide” that we created. If a new school is added down the road, they can again choose from the approved palettes. We also made sure that the design was responsive and looked good at multiple screen widths.

The district branding/navigation is omnipresent with a mega menu at the top of any site page. School site navigation is found in a consistently located left sidebar, and navigation options there are related to each school.

A few months before launch, we trained the school webmasters in using Drupal 8’s component-based pages and were there to answer any questions they had on using the new site. Our designer also attended the training to get feedback on whether the content was working as intended with design—and then tweaked the design where it wasn’t.

Outcome: a streamlined, fresh and cohesive site

BPS launched the redesigned district site in mid-January 2020, and they’ve already received great feedback from staff and other stakeholders. “We were worried about how schools would react, but it’s been really positive,” said Andrea. Kate Martin, District Marketing and Communications Manager, added, “They like the use of color. It’s brighter, fresher, and feels more modern. Everyone is just really excited. From a design and style standpoint, the site has achieved all our goals.”

Jan 21 2020
Jan 21

Just because a website is required to follow WCAG 2.1 accessibility guidelines doesn’t mean it can’t have a great design. Sometimes this misconception can frustrate designers before they even begin to understand the accessibility guidelines and the reasons they exist.

Get our 12 Point Design Checklist for Accessibility

Great design that is accessible can actually ensure a better user experience and result in an expanded customer base, a better brand image, superior SEO rankings, and reduce the risk of an ADA lawsuit.

At Promet Source, our designers are guided by the following quote.

“The enemy of art is the absence of limitations.” -- Orson Wells

Too often the WCAG guidelines are viewed as design limitations, but it is within limitations that creativity can best thrive.

We are not designing within a vacuum or to impress ourselves and other designers. We practice Human-Centered Design for people who have distinct objectives, and often they have limitations that include physical and cognitive disabilities. It is our responsibility as designers to build an inclusive experience for everyone. Creating an accessible website is not just the right thing to do, or an ADA Section 508 legal mandate, it’s good business.

Consider: There are 7 million people in the United states with a visual disability.1 One in four U.S. adults is living with a disability,2 and the total disposable income for U.S. adults with disabilities is estimated at $490 billion, with $21 billion in discretionary income.3 The web is where many connect and conduct business, and if people with disabilities can’t access the websites we are creating, we are all at a disadvantage.

In other words:

When UX doesn’t consider ALL users, shouldn’t it be known as 'SOME User Experience' or… SUX? -- Billy Gregory, Senior Accessibility Engineer

How do we ensure that online experiences are inclusive? ADA Section 508 provides the mandate for accessibility and WCAG 2.1 provides the guidelines. But while WCAG 2.1 AA guidelines are an essential framework, creating a truly accessible and user-friendly site involves more than checking off boxes. 

To create true usability, Human-Centered Design and usability testing incorporate the essential component of empathy to ensure that the humans, for whom the site is designed, can successfully engage and complete the tasks they set out to accomplish. 

To date, usability testing and research has tended to overlook the needs of people with disabilities. A true commitment to accessibility requires upfront user testing, the assurance that developers are deploying accessible code, collaboration among stakeholders, manual and automated audits, and perhaps most importantly, an empathetic understanding of how and why the humans for whom the site is designed will engage with it. 

Promet Source has created this essential 12 Point Design Checklist for Accessibility for designers to help meet WCAG 2.1 guidelines and develop accessible online experiences. Click here to get the checklist.

Contact us today for further information on implementing WCAG 2.1 guidelines for your site and to find out how we can help ensure more user-friendly and accessible online experiences. 

Sources:
1. National Federation for the Blind
2. Centers for Disease Control and Prevention
3. American Institutes for Research
 
Jan 21 2020
Jan 21

Every new year, aside from maintaining and continually improving the Webform module for Drupal 8, I look forward to putting together and practicing a Webform presentation with the hope that it will be accepted at the upcoming DrupalCon.

My first Webform presentation, a general introduction to the Webform module for Drupal 8 at DrupalCon Baltimore, was simply titled Webform 8.x-5.x.. The following year at DrupalCon Nashville, I organized a more feature-focused presentation called Webform: There is this for that. Last year at DrupalCon Seattle, I did an ambitious 90-minute Advanced Webform session.

Each year, I have to decide what is the best approach to organizing and sharing the Webform module at DrupalCamps and DrupalCon. I struggle with including too much or too little information in my presentation. It’s also difficult to pinpoint my target audience - every DrupalCon session is supposed to have a target audience, but I want everyone to use and appreciate the Webform module. And while I certainly appreciate the event’s organizers need to classify things, I really believe in letting anyone who attends DrupalCon know that the Webform module isn’t specific to any one group.

The target audience for the Webform module is everyone.

Webforms for Everyone

The defacto audience for the Webform module is developers, only because I am continually scratching my developer itch when adding new features and improving APIs. At the same time, I am always thinking about site builders, who on a daily basis need to build and manage forms. Finally, it is hard to forget about the business owner and the end-users because, ultimately, we want to create an engaging user experience for end-users that meets a business owner's needs.

So after last year's developer-focused presentation, I started organizing a presentation titled "Webform for Everyone." I recently presented (aka practiced) this presentation at NEDCamp, and honestly, my presentation went so-so. Keeping certain information too basic, started to bore developers. Conversely, showing code samples, lost half the audience. I have done enough presentations not to be discouraged, but realized that I need to rethink my approach.

The best advice I got while practicing my "Advanced Webform" presentation was to focus on the most exciting and essential aspects of the Webform module. In other words, talk about my favorite Webform things.

My favorite Webform things

The "Webforms for Everyone" presentation is still going to broadly walk-thru the three primary audiences for the Webform module, which are site owners, site builders, and developers. I’m aiming to engage everyone and focus on "my favorite webform things" as they relate to each audience group. I admit that I am struggling with my slides. As such, I thought the best way to reapproach this challenge would involve stepping back and writing this blog post, about "my favorite webform things"

10 - YAML Source

Use the YAML source...

The Webform module started as the YAML Form module, which allowed people to build forms by writing YAML markup. At some point, the YAML Form module started to have UI and became the Webform module for Drupal 8. Please read Webform 8.x-5.x: Where Do We Come From? What Are We? Where Are We Going? to learn more about this journey.

Every Webform demo I have ever given includes showing people the YAML source editor because it demonstrates how Drupal's Form API (FAPI) render arrays are used to build forms. Being able to see an entire form's elements on one page makes it easier to tweak a form's labels and descriptions. Developers, including myself, can also hand-code webforms. I enjoy being able to take something as complex as a form and represent it using something as simple as YAML.

YAML Source

YAML Source

9 - Results

The results tab provides a quick and straightforward way to view submissions.

The Webform's use-case is "build a form", "collect submission data", and "distribute submission data". Collecting data requires that it is also easy to review. Drupal core's Views module is an incredible tool for building reports, but it requires a full understanding of Drupal's Field API. Most non-technical users simply need to be able to filter and sort submissions and then hide or show a few columns. With this in mind, the Webform module provides a very straightforward way to customize the results table.

Of course, developers and advanced site builders can replace the Webform's default results table with a custom view. Here is a video showing how to customize and improve the Webform module's Views Integration.

I enjoy keeping things as straightforward as possible while offering the most flexibility, and my attempts to simultaneously provide both of these qualities has been a constant tug-of-war while developing the Webform module.

Results

Results

8 - PDF generation

PDF makes it easy to print or save a submission

Just as important as viewing submissions online, it’s equally important to be able to download submissions. PDFs provide a universal and straightforward way to share information. Being able to generate and download a PDF for single or multiple submissions provides the most visually appealing and standardized approach to share information.

What I like most about the Webform modules's PDF generation is being able to leverage the Entity Print module to provide comprehensive integration. Webform modules PDF support is a great example of Drupal’s extensibility and community working together. 

7 - External Libraries & Add-ons

Like PDF generation, many of the coolest aspects of the Webform module are provided by external libraries and add-ons. I am always in awe of what people contribute back to the Drupal and larger Open Source community.

Early on in the development of the Webform module, I started leveraging external libraries to provide advanced features like select menu enhancements and a signature element.

Now the Drupal community is extending the Webform module and providing additional functionality and integrations. Contributed add-on modules have handled several key aspects of the Webform module including Views integration.

External Libraries & Add-ons

External Libraries & Add-ons

6 - Webform Elements

Every type of element is available.

Being able to build the Webform module on top of Drupal's Form API while also leveraging external libraries made it possible to develop and maintain a wide variety of Webform elements. Webform elements, which can vary from basic HTML input to an advanced composite element, make it possible to collect any type of data.

Every possible element title and description variation is supported. For example, a form element can "hide" descriptions in help tooltips or read more slide-outs depending on the form’s use case and requirements.

The concept that every single aspect of an element is customizable can feel overwhelming and also empowering. I appreciate being able to add that little extra CSS to an element when it is needed. 

5 - Configuration and Settings

Everything and anything is customizable.

As we walk through this list, a common theme for the Webform module is everything is customizable. Every message displayed to an end-user can be changed. Even administrative features like the usage of modal dialogs can be adjusted.

I enjoy knowing that every single possible way to confirm a form submission is supported. I like being able to open a confirmation message in a simple modal dialog.

5 - Configuration and Settings

5 - Configuration and Settings

4 - Reusable code

I know it may seem strange that one of my favorite Webform things is the simple fact that most of the code within the Webform module is reusable and extendable using Drupal's plugin and entity system.

Drupal's entity system made it easy for me to create a very basic UI for managing reusable lists of options and images for select menus, checkboxes, and radios. Drupal's plugin system makes it easy for developers to create custom webform elements and handlers.

I am not sure if Drupal developers realize that any webform element, including elements like select, checkbox, and radios with the other option, entity references, composites, and multiples, can be reused in their custom forms, built with Drupal's Form API. There are even some simple utility classes available to manipulate custom-built forms, elements, options, and arrays.

Reusable code

Reusable code

3 - Twig support

Twig is awesome!

There is a limited amount of flexibility available in a graphical user interface, and sometimes the most flexibility happens when a developer can only write the code they need. The old school and utterly insecure solution was to allow developers to inject PHP into a page. Before Drupal 8, pages were rendered using PHP templates. Luckily with Drupal's adoption of Symfony, the Twig templating engine was added to core. Initially, I thought Twig was just for rendering variables and executing loops with templates. At some point, I realized that Twig supports most math calculations and even some OO concepts. It makes a lot of sense to build custom emails using Twig. It also mind-blowing that Twig can be used to perform calculations for computed elements.

Computed elements can collect and manipulate that little bit of extra data that needs to be captured and stored with a submission. Computed elements can calculate totals and even trigger custom conditional logic.

Twig support

Twig support

2 - Remote post handler

Everyone needs to be able to consume and share information.

The remote post handler allows a webform submission to be posted to a URL. When I added the remote post handler to the Webform module, I thought it was nice to have feature that would be used by a few websites. In the past few years, with the rise of CRMs, being able to push data from server to another is a requirement for most enterprise websites. I frequently recommend that people build a webform in Drupal, but remote post the submission data to a system that is designed to aggregate, analyze, and report on data securely.

Remote post handler

Remote post handler

1 - Videos

Having some adequate documentation is one of my biggest accomplishments with the Webform module. Like many developers, I do not like writing documentation. That said, documentation makes it possible for people to understand how things are supposed to work. I started out recording some general demos of the few modules that I have contributed back to the Drupal community. I realized that I could add links to videos about functionality and features within the Webform module's user experience.

It is fun and rewarding to show people the latest and greatest Webform feature or improvement. I know the Webform module can occasionally feel overwhelming, and it helps to have a video that guides someone through the process of getting the most out of the Webform module.

Videos

Videos

Finally…

As you can see from this blog post, on my favorite Webform things is sharing my code, ideas, and passion with the Drupal community. Hopefully, you can catch my "Webforms for Everyone" presentation at DrupalCamp NJ, MidCamp, or DrupalCon Minneapolis.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

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

OK

Jan 21 2020
Jan 21

Deciding on a CMS these days is not a simple task. There are many things to take into account and lot at stake.

  • Business websites are more important then they ever were and if a business wants to communicate effectively, it needs a great website.
  • Budgets and lead times for new CMS deployments get bigger and projects more and more complex. Often, it is difficult to plan for a complete overhaul and businesses have to plan for a phased approach
  • The business moves faster and the CMS has to keep up the pace with changes in requirements and technology

All the above means that often a CMS re-deployment is a multistep project for many months or even years. One cannot allow for errors. Choosing incorrectly can set the business back years.

In this ever-changing, fast-paced environment Drupal stands out as one of the best choices available. Here is why:

Speed of delivery and flexibility

One of the great risks of licenced products is being left behind the market. If your vendor does not build the features you need, you might get left behind the competition.

By choosing Drupal, CTOs have great flexibility and are not bogged down by one vendor’s feature list. With Drupal and its hundreds of modules, they can build whatever they like. They are also free to extend Drupal, building unique advantages for their companies.

Another thing to consider is the vendor's capacity to deliver. With a licenced product, a company is often locked down with one vendor and if his capacity is reached, development slows down. With Drupal, even if one vendor is at capacity, a CTO can easily extend by adding another one. This is quite often a strategy large enterprise clients chose from the outset - work with multiple agencies in parallel.

Standards and best practices

Being an Open Source project, and a very successful one, Drupal has clearly defined best practices and standards. This helps CTOs in many ways:

  • It is easier to set expectations from vendors
  • It is easier to replace one vendor with another
  • It is possible to cooperate with multiple vendors, setting the requirements on the commonly accepted development standards at the same time

Budget considerations 

Being open-source, Drupal does not have a licence fee. Licences, when it comes to the Corporate Market, can be quite expensive. This is an immediate financial benefit to the CTOs organisation

Long term, typically services of companies operating in the Open Source are a bit lower than those of their counterparts offering licenced products. This is because the cost of licenced tooling, partnership fees etc ado not have to be recharged to the end customer.

Another way in which Open Source can help reduce costs is by access to a wider range of service providers. Of course, you should still choose companies that are reliable and trustworthy, but in the Open Source, there are many smaller agencies and outsourcing partners, who, in the right mix, can help reduce the overall development bill.

Drupal prides itself in having a very vibrant business community. A CTO can choose from a really wide range of Drupal service providers, starting from the really big, like Accenture, through medium Drupal focused agencies like Droptica, down to a few-person-shops or even freelancers.

It is also quite common to handle initial ideation and development close (e.g. same city) and then hand-off the big delivery tasks which require a lot of manpower to an outsourcing partner in a region with lower costs - like Central or Eastern Europe. With Drupal being popular all over the world, you can easily find talent everywhere.

Drupal is tried and tested

CTOs time perspective is usually at least 5 years into the future. Often more. Choosing a technological solution with such a timeframe in mind is not easy. There aren’t too many solutions which withstood the test of time. Most of the other Open Source frameworks and proprietary CMSs are on the market since just a few years. Others have their best times behind them.

Drupal withstood the test of time. It is on the market for over a decade and is still extremely strong. The vibrant community is growing the number of websites built on Drupal 8 is growing steadily. Choosing Drupal, the CTOs know they will have a growing framework to work on which will continue to have wide support and a plethora of vendors years to come.

Drupal 8 is fully Enterprise ready

With the release of Drupal 8, any gap between proprietary CMSes and their Open Source counterparts has disappeared. Drupal offers everything Corporate clients need. 

API First

CTOs know that integrations are more and more important. To answer that, Drupal has built an incredible API framework. Out of the box, most of Drupal is available via JSON API. This includes all the content and a lot of the configuration. 

Drupal API is also not just an afterthought. It is baked straight into Drupal core functionality. Thanks to this, all the Drupal features, like content access permissions, translations, entity states and more are automatically available via an API.

Multilingual

Drupal in the 7 version was already a fantastic multilingual CMS. Drupal 8 improved upon it even further. If you are building a multilingual website, there is absolutely no better alternative.

Workflow management

A typical case for an enterprise-level website is a content workflow. Drupal includes a workflow module out of the box, thanks to which, it works really great with all the other Drupal features and functionalities.

Versioning

Drupal allows for versioning content. Combined with a Workflow module this brings powerful editorial mechanisms to the table. All this is of course already included in Drupal default installation.

...and more

Drupal comes with many other prepackaged features which make it a great choice for any CTO.

Choosing Drupal is a safe bet

By choosing Drupal, CTOs chose a system which is a safe bet. Drupal will not stand in the way of the success of the project. It is a solid foundation to build on. Especially if the right vendors are chosen.
 

Jan 20 2020
Jan 20

Websites and apps should be designed and developed in such a way that people with disabilities (permanent, temporary or situational) find them easy to use (if you’re unsure on what accessibility is, take a look at our blog, What is digital accessibility?).

But how do we measure accessibility? How can we tell whether a site or an app is accessible? The answer is by checking it against international accessibility standards - Web Content Accessibility Guidelines (WCAG) 2.1. This can be done in two ways: by using automated testing tools or carrying out a manual audit. In this article we’ll compare the two methods to better understand when and how they should be used and look at their advantages and disadvantages.

Automated accessibility testing

Automated evaluation can be carried out by anyone with access to an accessibility testing tool. There’s a number of free and paid tools available, including:

Accessibility testing tools run a set of scripts checking web content against certain criteria based on WCAG 2.1. For example, according to WCAG, every <img> element (an image) has to have “alt” attribute which is used to provide a text description of that image for the benefit of users who cannot see it:

<img alt=”black cat sleeping on a sofa” src=”/images/123.jpg” />

The relevant script would consist of the following steps:

  1. Check if there are any <img> elements

    1. If no, the result is N/A

    2. If yes, check if each of those elements has “alt” attribute

      1. If yes, the result is Pass

      2. If no, the result is Fail

Automated testing pros:

  • It’s easy - it can be done by anyone with access to a testing tool

  • It’s fast - it can check hundreds of pages and provide results in a matter of hours

  • It’s cheap - some of the automated tools are free to use

  • It can detect problems early on - some tools can be integrated into the development process and run tests whenever new code is added or perform regular scans to ensure that no new issues have been introduced since the last check. 

Automated testing cons:

  • Automated testing tools are not able to test websites or apps against all success criteria listed in WCAG. Many guidelines are objective and therefore can’t be tested using a script as they require human judgement. For example, while automated tools can check whether an image has an “alt” attribute, they cannot evaluate whether it’s correctly used, i.e. whether its value conveys the same information as the image. A picture of a cat described as “red car” would pass automated testing.

This also applies to links. Accessibility guidelines require link texts to be descriptive, and yet the link below would pass automated accessibility testing:

<a href=”/contact-us”>go somewhere else</a>

Automated tools can check whether link text is provided, but they cannot determine whether that text accurately describes the link’s purpose.

  • Automated testing can generate false or misleading results. Even when checking against guidelines that can be tested using automated tool, the results may be inaccurate or wrong. Someone with no or limited knowledge of web accessibility may not be able to correctly interpret the results. 

  • The advice on how to fix the issues is quite generic and often vague and therefore some developers may find it difficult to understand and implement the required changes. 

Someone who is not aware of the limitations of automated tools may not realise that even though a site has passed automated testing, it may still have many barriers preventing people with disabilities from accessing its content. When the site passes an automated test it only means that there were no errors found in checks that can be performed by an automated tool and not that the site is accessible. Most automated tools can only check a small number of criteria reliably (e.g. 6 out of 50) so automated accessibility testing cannot determine whether a website is WCAG 2.1 compliant.

Laptop

Manual testing

Manual testing is carried out by an accessibility expert who checks a subset of pages or app screens (usually 5 - 20) against WCAG 2.1 criteria. Every page element and their underlying code is manually evaluated for issues related to non-text content (images, audio, video), use of colour, keyboard accessibility, descriptive links, labels and instructions, correct HTML structure and many others.

Manual testing pros:

  • A manual audit is much more thorough and, unlike automated testing, includes checking the content against all WCAG 2.1 criteria at a required level

  • The results of manual accessibility testing are considered much more reliable and trustworthy

  • While results generated by automated testing tools are generic, a report written by an accessibility expert is specific to your site and includes realistic and tailor-made solutions.

Manual testing cons:

  • Manual testing is more time-consuming and therefore expensive compared to automated testing. The cost depends on the coverage - the more pages included in the audit, the more expensive it is. However, even though in most cases it’s not possible to manually check all pages (unless the site is really small), an accessibility expert who is also an experienced Drupal developer is able to select a good representative sample of pages that includes as many content types and components as possible to maximise test coverage

  • The value of the audit depends largely on the knowledge and experience of the accessibility expert who carries it out. While any accessibility expert can identify issues on a Drupal site, an accessibility expert with good working knowledge of Drupal is able to provide much more detailed advice on how to fix the issues found during the audit. For example, rather than just saying, “these images need alternative description”, they can specify where and how in the code or CMS that change needs to be made. This makes implementing suggested fixes much easier and cost effective for the client. 

Recommended approach

Automated and manual testing complement each other and should both be used to assess the level of accessibility of a website or app. Generally speaking, automated testing can identify some of the issues found on pages across the site but manual testing can find all of the issues on a subset of pages.

As mentioned above, automated testing has many limitations, but it will give you a rough idea of the level of accessibility of your site. Automated testing can quickly check a large number of pages and find some obvious issues, such as missing alternative descriptions or form fields without labels.

We’d then suggest embarking upon a manual accessibility audit. An experienced accessibility expert can help you select a good sample of pages which will cover all (or key) content types and components. This is important to make the manual audit cost-effective and ensure you get the best value for money. Following the audit you’ll receive a report which will clearly explain all issues found on your site and provide tailor-made and specific suggestions on how to fix them.

Any issue described in the report should then be resolved, remembering to apply the suggested fixes to not only to pages included the audit, but also to other areas of your site. 

Once all identified issues are fixed, a re-test can be carried out to confirm that they’ve been correctly resolved and no new issues have been accidentally introduced in the process. 

Following an automated and manual audit, you could look at usability testing with people with disabilities so that further improvements can be made to your site. Regular automated testing and training sessions for content authors and developers contributing to the site will help maintain its high level of accessibility and prevent new issues.

Want to know more about how we can help you on your accessibility journey? Get in touch

Jan 20 2020
Jan 20

Conferences and camps are the lifeblood of the Drupal community. They provide in-person opportunities to grow our skills, our learnings and our projects beyond our current limitations and perspectives.

DrupalCon 2019 in Amsterdam was no exception! The open-source community was out in full force, doing what we do best — asking questions and seeking the smartest answers/solitons to our most challenging questions/problems.

From the Driesnote to the Women in Drupal Luncheon, from the First-Time Contributor Workshop to Bird’s of a Feather sessions, DrupalCon Amsterdam tackled such a wide range of exciting topics, we had to find a way to show you some the highlights as we look forward to another great year of open source community and events. 

Check out the entire highlights video below -- see you at DrupalCon Minneapolis! 

[embedded content]

Jan 20 2020
Jan 20

Drupal 9.0.0 is scheduled to be released in 2020. There are 3 possible release dates, depending on when the requirements are going to be met. The earliest possible date is June 3, see https://www.drupal.org/core/release-cycle-overview for details as well as the overview below.

Drupal 9 Scenarios draft

First, the most important fact is that Drupal 9.0.0 will be a very different release compared to Drupal 8, Drupal 7 and so on. Before Drupal 8 has been released, the community has been working for years on a new version, with a lot of new functionality and major changes that required huge efforts to update or migrate sites to a new major version.

However, since Drupal 8.0.0, the Drupal community has released a new minor version roughly every 6 months with new functionality and improvements. That means that maintaining Drupal 8 sites is a continuous process that requires regular updates. Drupal 9.0 will then not provide any new features, it will instead just update all its third-party dependencies (like Symfony) as well as remove the so called backwards-compatibility (BC) layers, which allowed it to keep existing modules working while making a lot of changes to improve and modernize the code base.

There are no content structure changes planned between Drupal 8.9 and 9.0 which means that updating will only be about updating code and - to a lesser degree - configuration.

For sites that are still using Drupal 7 or even earlier, no longer officially supported versions, it makes sense to start the migration to Drupal 8 now instead of waiting for Drupal 9 to be released, as that gives them a longer time period to finish this process.

That means:

  • Predictability: Drupal 9 will be released on one of those 3 dates, unlike earlier major versions which were often delayed by months or years.
  • Lessened burden on maintainers: Contributed modules will be able to support Drupal 8.8+ and Drupal 9+ in a single release, with a limited amount of necessary adjustments. In turn, that will result in modules being Drupal 9 ready earlier than with previous releases.
  • Seamless update: Once all modules that are used by a project support Drupal 9 and its own custom code and themes are updated, the project can be updated to Drupal 9.0 just like updating from Drupal 8.7 to 8.8.
  • Shorter window of support for previous versions: Drupal 7 and 8 support will end in November 2021, due to support for third party components ending.

So how is MD Systems dealing with this major transition as a responsible and active major contributor in the ecosystem?

Primer will be Drupal 9 ready

All our customers who are using our install profile Primer and have an active maintenance contract with us will have their sites updated to Drupal 9.0 once it is ready, as part of our regular Primer updates. Likely without even noticing it, thanks to our extensive automated test coverage and visual regression tests.

MD Systems is also available to consult with updating sites to Drupal 9 as well as working on specific contributed projects.

Read on to learn more about the background, technical processes and tools to prepare for Drupal 9 as well as our contributions.

Drupal Core and Tooling Status

Preparations in Drupal core are ongoing for Drupal 9. There has been a lot of progress already, but there is still a lot to do. Drupal 9.0.0-alpha1 is expected to be released very soon.

The following graph shows the remaining work in the progress on removing the mentioned backwards-compatibility layers around deprecated code: https://dev.acquia.com/drupal9/deprecation_status/graphs

Drupal core 9.x-dev @deprecated mentions graph

Once this is done as well as the other required preparations, then Drupal 9.0.0-beta1 will be released and the release date of Drupal 9.0.0 will be set. MD Systems is actively involved in removing these BC layers.

Beside Drupal core itself, a lot of work is also going into the infrastructure on drupal.org, which will for example allow contributed modules to adopt semantic versions (1.2.0 instead of 8.x-1.2) as well as tooling to support contributed project maintainers as well as custom code in sites in updating their modules to Drupal 9.

For example, https://dev.acquia.com/drupal9/deprecation_status inspects the whole ecosystem of contributed modules in regular intervals to identify the progress in becoming Drupal 9-ready. Drupal-check is a CLI tool that allows to check the status of one or multiple modules and Upgrade Status is a Drupal module that can check all or some of the installed modules that a site uses and display a report of the Drupal 9-readiness of a site.

Some deprecations can not be identified with static code analysis, the best way to identify these is to have automated test coverage with phpunit tests which can report issues based on runtime calls to deprecatd methods.

There is also a weekly meeting in #d9readiness in Slack on Monday 7pm UTC where the progress is discussed.

Collaboration for Contrib readyness

Drupal 8.8, released back in December, is the last minor Drupal 8 release with additional Drupal 9 deprecations. Drupal 8.9, will focus on stability instead.

This allows most contributed modules to be compatible with Drupal 8.8+ and Drupal 9 in the same release and makes it a perfect time to start preparing for Drupal 9.

And while the community has been preparing for Drupal 9 for some time already, there has been a flurry of activity since the release of Drupal 8.8.0 and improved tooling. Maintainers of large distributions and ecosystems like Thunder, Lightning and Commerce have committed to making their projects available to Drupal 9 as early as possible and have committed a lot of time already to work on the modules they use.

MD Systems maintains multiple internal install profiles and supports almost 100 projects on drupal.org. We are committed to prepare all modules that we maintain for Drupal 9 and have already been working actively on that in the last weeks and months. Many of our modules now require at least Drupal 8.7 and only have a few remaining deprecations left to be fully ready for Drupal 9. Resolving these means requiring Drupal 8.8, which we’ll start doing in a few weeks.

In the upcoming Global Contribution Weekend, a key focus will be to prepare modules for Drupal 9 and our team will join the local sprint in Zurich. If you have any questions about our projects or need help in preparing your own, talk to us in person or Slack.

Custom transition

Typically, Drupal sites also have custom code that might need to be updated as well. The same tools that can be used for contributed modules can also be used for these custom modules. 

If a site has kernel or functional phpunit tests then these are a great way to test for deprecations in custom code as well as contributed modules as well.

To be able to test a site on Drupal 9, all used modules need to have a release that supports Drupal 9. Once that is the case, it is also possible to do manual tests as well as running automated test suites like Behat.

Making legacy projects ready

Some projects that were released early in the Drupal 8 cycle might be using legacy contributed modules that have been abandoned or have been merged into Drupal core or other modules might face some challenges.

Examples include the Media Entity project (8.x-1.x, including its large ecosystem), the Workbench Moderation modules as well as File entity. While some of these projects might still receive Drupal 9 compatibility releases, they only receive minimal maintenance.

These sites will either need to find ways to migrate away from these old modules or new maintainers need to step up and make the module available for Drupal 9.

MD Systems is available to consult with updating sites to Drupal 9 as well as working on specific contributed projects.

Jan 20 2020
Jan 20

John Cook and Andrew MacPherson at a previous Contribution Weekend event
John Cook and Andrew MacPherson at a previous Drupal Global Contribution Weekend event.

Since 2013, Drupal Global Contribution Weekend (DGCW) has been held on the last weekend of January.

People more-or-less close to Drupal and its community join for this worldwide event where everyone can participate: site builders, testers, designers, project managers, translators, marketers, writers, and, of course, developers.

You are all welcome to contribute to make Drupal better.

Contribution is at the core of any open source software project and this event is the perfect opportunity for you to be a maker.

January 24-26

This year, DGCW is from Friday to Sunday, January 24-26.

Where to participate

It’s worldwide! You can check this year's DGCW page to see a list of local events participating in the initiative.

At the moment of writing there are events in India, Pakistan, Russia, Belgium, Germany, Switzerland, Ukraine, United Kingdom, USA and Canada.

Keep watching that space as new events may popup, including Virtual Meetups where you can join online events like last year's Contribute to accessibility and Contribute to Gender Field Module.

Interesting, but there isn’t anything close to me.

Oh, this is a great opportunity then! If you would love to participate, you can create your own event.

Find a venue

The first step is finding a place to hold your event. It’s likely that the first time only a few people may join. Reserving a table in a local pub/bar/cafe can do the job. Or if you have a company who can provide or sponsor a better place, even better. Sometimes nonprofit organisations are more than happy to provide spaces to these kinds of initiatives.

Find a comfortable place with these things:

  1. It’s a safe environment for everyone, physically and mentally
  2. It has WiFi and power sockets
  3. It doesn’t have accessibility barriers

Bonus: provide or plan breakfast, refreshments and/or lunch.

Plan the day

It may seem like the scariest bit, but it is not! The Drupal Community has created a series of tools and guides facilitating the hosting of these kinds of events. From the DGCW landing page:

No events close to you? Why don’t you host one! Have a look at the information on how to become a host and when you are ready add your event in the list (see Example code for adding a sprint below).

The minimum you'll need:

  • A page people can visit, and possibly subscribe (groups.drupal.org/ helps)
  • Be ready to great your guests on the day
  • Use Drupal Ladder platform (http://drupalladder.org/ or https://drupalize.me/series/learn-drupal-ladder)
  • Encourage guests create a Drupal.org user account. It’s a must-to-have for contributors, besides they can benefit from subscribing to awesome drupal-related newsletter (weekly bulletin from Drupal Association, Security updates, etc.).
  • Explain the issue queue. See Getting started in the issue queue Drupal Ladder section for a good introduction.
  • Point them to the Novice issues queue, and the Novice code contribution guide if they need more step-to-step info.
  • Set expectations. The first interaction may be no more than a comment in an issue. And that’s OK!

Am I up for this challenge?

Yes! Every single event organiser has worries when planning events. And we're here to help. You can reach most of them on these channels:

You can get in touch directly with me, Lizz, or Rachel and we will be more than happy to help.

Is not just Drupal and its community that needs you to act. It’s your neighbours, and people living in your community which want to participate more in contributing and don’t know how to do it.

We are always alone, until we call.

Jan 20 2020
Jan 20

In this tutorial I will explain how I accomplished taking a listing of nodes that came from a View and created a Parallax effect using the Bootstrap theme from Drupal 8.

The code in this tutorial can be found on GitLab. 

To use the code in the repos, you can:

  1. Clone the repos locally
  2. Run composer install from the root folder
  3. Run drush config:import -y 

I would like to refer to this article which explains how to Add Parallax Blocks to Drupal 8 With ScrollMagic. I got my ideas and most of the code from there.

You will need to have Drupal 8 installed with Views and a Bootstrap subtheme set up.

For this tutorial, I am using a simple Page content type that I created with 3 fields: Title, Body and Background Image.

You should then create a View that lists this Page content type. I am listing the Body field and Background Image field in my example. I am keeping my Page content type and View very simple for explanation purposes. But you can set up more complex Views and content types as you wish. You just need at least an image field (or you can place a background image to an existing content type field via CSS as well).

Step #1 - Configure the Bootstrap theme

Because Parallax effects are usually full width, you should turn on the Fluid container option in the Bootstrap theme menu.

  • Enter your subtheme Boothstrap theme settings.
  • Under General >> Container check the Fluid container boxFluid checkbox

Step #2 - Set up your Content Type and Views.

Here is my Page content type with 3 fields: Title (not show in in screenshot), Body and Background image

Page content type fields

Here is my View. It's a pretty much standard View which just lists the Page content type and creates a page out of it. I am using the image field here as the background image for the Parallax. You can also use another field (text or whatever) and set a CSS background as the image.

View listing page content types

Now create some Page content and go to the View page to see the listing of your content.

Step #3 - Style the View using CSS

Here is my CSS:

.view-homepage {

  .views-row { text-align: center; position: relative; overflow: hidden; height: 500px; }

  .views-field-field-background-image { position: absolute; width: 100%; height: 140%; }

  .views-field-body {

    position: relative; top: 50%;
    -webkit-transform: translateY(-50%);
    -ms-transform: translateY(-50%);
    transform: translateY(-50%);
    color: #fff;
  }
}

Step #4 - Get the ScrollMagic files

Go to Github and download/extract library.

Now go to your theme folder and create a folder called /js/ and move these files into the folder

  • animation.gsap.min.js
  • ScrollMagic.min.js
  • TweenMax.min.js
  • and also manually create a blank parallax.js

You now need to tell the theme to load the js libraries. To do that, open your_theme/your_theme.libraries.yml:

global-styling:
  css:
    theme:
     css/style.css: {}

  js:
    js/ScrollMagic.min.js: {}
    js/animation.gsap.min.js: {}
    js/TweenMax.min.js: {}
    js/parallax.js: {}
  dependencies:
    - core/drupal
    - core/jquery

Step #5 Add the Parallax JS code to parallax.js

(function ($) {
    'use strict';
    Drupal.behaviors.myBehavior = {
        attach: function (context, settings) {

            var controller = new ScrollMagic.Controller();

            $('.views-row').each(function (index) {

                var $bg = $(this).find('.views-field-field-background-image');
                var $content = $(this).find('.views-field-body');

                var tl = new TimelineMax();
                tl
                    .from($bg, 2, {y: '-40%', ease: Power0.easeNone}, 0)
                    .from($content, 1, {autoAlpha: 0, ease: Power0.easeNone}, 0.4)
                ;

                var scene = new ScrollMagic.Scene({
                    triggerElement: this,
                    triggerHook: 1,
                    duration: "100%"
                })
                .setTween(tl)
                .addTo(controller);
            });
        }
    }
}(jQuery));

Make sure the images you are using are big enough for the max width you want to display.

You should now have a nice parallax scrolling effect for each node in the View list.

Parallax example

Jan 20 2020
Jan 20

If you find yourself here, dear reader, that means you went through one hell of an upgrade process to Drupal 8. I’m sorry you had to go through that. What you now know all too well is that upgrading to Drupal 8 is sort of like what Uncle Ben says to Spider-Man — “With great power comes great responsibility” — except in our comic book where Drupal is the superhero, he says “With great power comes great opportunity to completely fuck it up.”

The good news is that there is a path forward, it gets better, and success is decidedly on your horizon.

Start with a retrospective

Mistakes happen but you have to learn from your mistakes in order to get yourself out of the hole. Gather the team, gather your notes, and spend 90 minutes talking as candidly as possible. You should invite everyone that worked on the project to the retrospective, and no one else. Only people with non-trivial, hands-on experience with the specific project can add value to the discussion. You can share the summary of what went wrong in an email to every other interested party.

Ask why a few times. Don’t just write down a list of every issue you hear, discuss them. Ask why repeatedly until you feel like the root cause of the problem is known. It probably takes 2-3 whys to get there.

Don’t make a plan in this meeting, that comes next, but you have to digest what went wrong first to prevent it from happening again.

OK, now make a plan 

You know what went wrong from your retrospective and, at a high level, you should know what you need to do to recover to best support the business.

First, make a detailed list of all of the issues. Canvas the team and end-users to identify all of the issues. Create a list of everything you feel is a valid issue. For each item, apply a t-shirt sizing level of effort. Is this small (two hours or less), medium (a day of effort or less), or large (days of effort)?

Also rate each item in terms of impact on the business on a scale of 1 to 5, with 5 being hugely impactful to the business and 1 being trivial. Refinements like SEO issues, performance, and anything impacting conversion are likely 5s. Keep yourself honest by identifying the concrete value provided to the business for each refinement before picking the rank.

If needed, don’t hesitate to implement several small refinements during planning to buy your team time to plan for proper recovery, or, if you have your plan in place, to buy you time before working on larger efforts.

Don’t be shy in your planning: Make the big sweeping changes that are needed to get the site where it needs to be. Don't pick and choose, try to be as exhaustive as possible so that you only have to recover once. Technical debt always has to be paid, no matter what, at some point. It’s far better to pay it off now than let it grow.

Managing your recovery while keeping an eye on Drupal 9

Drupal 9 is right around the corner. Take relief in knowing that migrating from Drupal 8 to Drupal 9 is going to be easier than every version upgrade in drupal history. Take a deep breath. The worst is hopefully over. You have migrated to Drupal 8 and that is HUGE. No more looming November 2021 deadline where D7 reaches end of life.

However, make sure that part of your recovery planning includes consideration to ensure your fixes don’t complicate a future move to Drupal 9. Be sure to keep your contributed modules up to date and replace any deprecations used by any of your custom code.

Most importantly, be sure to review our Drupal 9 Readiness Guide in detail to ensure you are following all of the best practices guidelines to be ready.

What to do if your SEO tanked

One common issue we encounter when clients come to us after a failed Drupal 8 upgrade is that their organic rankings are in freefall. Nothing is more painful to a digital marketer than seeing years of accumulate search ranking goodwill vaporize in days. It’s going to take time to recover what you lost, but it won’t take years.

First, run the site through several SEO assessment tools (our favorites are Google Webmaster Tools and Moz). Google Search Console (GSC) will provide crawlability errors including 404s and other technical issues to resolve. In GSC, you can also audit the robots.txt file to make sure that search engines aren't being blocked from pages you want crawled. A paid tool like Moz can make sure that there is no low hanging fruit on the site such as missing H1s, URLs that are too long, and missing meta descriptions. (Although meta descriptions do not directly affect SEO, they should be written to encourage a user on Google to click your link.)

After you’ve gathered data from a variety of sources, combine the results from all the assessments into a single list of refinements, and look for (and prioritize) the fixes that compound. That is, in SEO, you can often fix 3, 4, even 10 issues with a single foundational fix to HTML structure or theme templates. Make those changes right away.

Third, use 301 redirects to save the day — make sure you aren’t using 302s as these types of redirects don’t pass along link equity like a 301 redirect does. Using analytics data and your marketing team’s understanding of important site content, use your CMS’s built-in redirect tool to set up redirects for any links in search results that are 404ing.

Lastly, keep pushing refinements from your hit list through development and encouraging Google to reindex your site. At first, this will be a daily task, then a weekly task until all of the issues are refined. Keywords should be monitored for what users are querying and the content that lives on your site so you can track ranking improvements. While you’re tracking progress on ranking improvements, keep in mind if these keywords are still worth pursuing or if you might be better off targeting other keywords as user behaviors change.

Bonus: perform a detailed audit of the Google Analytics integration and configuration with the site. If you are using Google Tag Manager (excellent!), audit that as well. Pay close attention to goal tracking, custom event tracking, and analytics best practices. Fix any data capture issues immediately — you can’t fix something you can’t verify and sometimes it’s only a simple tracking issue that needs to be fixed.

You will have missed a beat and might miss your goals for the quarter or year, but by executing this plan you will get the site back to a stable, performing state you can build from. Without this work, the specter of not addressing these foundation issues will hamper your digital marketing efforts for years.

What to do if you lost ADA compliance

If your public digital experience isn’t compliant with US accessibility regulations — often referred to as WCAG A, AA, or AA, website accessibility, or ADA — and you are a medium or large business it is only a matter of time before you are the target of litigation. The settlement is always the same: a modest amount of damages owed and a contractual obligation to achieve compliance in a set timeframe (typically 6 - 9 months). It’s far less painful to achieve compliance on your own terms than someone else's.

The first step to recover from lost ADA compliance is to decide your target compliance level. There are three: WCAG A, AA, or AAA. Consult your legal counsel in terms of what level you need to achieve. In general, we think of AA as the most ideal compliance level. This represents a fair effort to make the site easy to use for those with disabilities but balances reality with that old adage that the last 20% of the work takes 80% of the overall effort.

Next, you need to perform a comprehensive audit. This should be a combination of off-the-shelf automated tools and manual testing from an ADA expert to ensure you get a complete picture of the ADA issues. Combine all of these findings into a single list of the issues, and categorize each as editorial or engineering.

Now, prioritize the issues by level of effort (t-shirt sizing like we mentioned previously works great) and impact (again, some refinements will address more issues at once than others). Start with the lowest effort highest impact refinements first, and work through the entire list.

Finally, when all of the refinements are live-run the comprehensive audit again to verify that all existing issues have been addressed and that these refinements didn’t create new compliance issues (it happens). Trust but verify.

And as anything involving ADA compliance consultant your legal counsel. We aren’t attorneys at Third and Grove and while we can help fix your digital compliance, we can’t provide legal advice.

How to fix a poor backend experience

It’s easy to tell if your Drupal 8 editorial backend is well built: If your marketing team complains more than usual, well, it isn’t. You can explain away all of their concerns all you want but the fact remains that if the marketing team is frustrated than the CMS implementation has failed. The most common issue we hear from new clients is that their backend is not flexible for marketers to build pages.

The most foundational issue to determine is if the design of the site was component-driven or not. If the design system was built to support the idea that page templates don’t exist but page components (widgets) do, then you have a framework that will support a path to success. Unfortunately, the inescapable reality is that if the design system was not built to support components, there is very little you can do to address the overall flexibility of the editorial backend without a redesign.

Assuming your design system was built properly, the issue will be primarily on the contributed modules and best practices followed by the development team that built the site. It will be a non-trivial effort, but you can prepare a release — that includes new functionality and a complex release script — that refactors all of the existing content into a component system. The amount of site content and how structured (or not) it is will determine how much of this release can be automated and how much will require manual editorial clean up.

Before working on this cleanup release, define 2-3 core editorial use cases such as the ability to build a landing page for an email campaign. With a clear target state defined, it becomes easy to work backward and determine the technical approach needed to achieve the sought after editorial flexibility. 

Regardless if you need to clean up your backend or recover a drop in your organic visibility, the point is to take your time in planning the recovery process and bringing the right stakeholders together as soon as possible. If you take your time at the beginning of the recovery process, you’ll only have to recover once and then fix your gaze to the future.
 

Jan 19 2020
Jan 19

The Drupal Community Working Group is happy to announce that we are once again teaming up with Otter Tech to offer live, monthly, online Code of Conduct enforcement training for Drupal Event organizers and volunteers in 2020.

During the second half of 2019, 17 Drupal community members completed the training (see full list), helping to ensure Drupal events world-wide have qualified Code of Conduct contacts. We are excited to be able to provide support for the training in 2020.

The training is designed to provide "first responder" skills to Drupal community members who take reports of potential Code of Conduct issues at Drupal events, including meetups, camps, conventions, and other gatherings. The workshops will be attended by Code of Conduct enforcement teams from other open source events, which will allow cross-pollination of knowledge with the Drupal community.

Each monthly online workshop is the same; community members only have to attend one monthly workshop of their choice to complete the training.  We strongly encourage all Drupal event organizers to consider sponsoring one or two persons' attendance at this workshop.

The monthly online workshops will be presented by Sage Sharp, Otter Tech's CEO and a diversity and inclusion leader in the open source community. From the official description of the workshop, it will include:

  • Practice taking a report of a potential Code of Conduct violation (an incident report)

  • Practice following up with the reported person

  • Instructor modeling on how to take a report and follow up on a report

  • One practice scenario for a report given at an event

  • One practice scenario for a report given in an online community

  • Discussion on bias, microaggressions, personal conflicts, and false reporting

  • Frameworks for evaluating a response to a report

  • 40 minutes total of Q&A time

In addition, we have received a Drupal Community Cultivation Grant to help defray the cost of the workshop for those that need assistance. The standard cost of the workshop is $350, Otter Tech has worked with us to allow us to provide the workshop for $300. To register for the workshop, first let us know that you're interested by completing this sign-up form - everyone who completes the form will receive a coupon code for $50 off the regular price of the workshop.

For those that require additional assistance, we have a limited number of $100 subsidies available, bringing the workshop price down to $200. Subsidies will be provided based on reported need as well as our goal to make this training opportunity available to all corners of our community. To apply for the subsidy, complete the relevant section on the sign-up form. The deadline for applying for the subsidy is end-of-business on Wednesday, July 1, 2020 - those selected for the subsidy will be notified after this date (in time for the July 8, 2020 workshop).

The workshops will be held on:

Those that successfully complete the training will be (at their discretion) listed on Drupal.org (in the Drupal Community Workgroup section) as a means to prove that they have completed the training. We feel that moving forward, the Drupal community now has the opportunity to have professionally trained Code of Conduct contacts at the vast majority of our events, once again, leading the way in the open source community.

We are fully aware that the fact that the workshops will be presented in English limit who will be able to attend. We are more than interested in finding additional professional Code of Conduct workshops in other languages. Please contact us if you can assist.

Jan 17 2020
Jan 17

Drupal 9 is scheduled for release on June 3, 2020. And as with any highly anticipated release, questions abound: “What will change from Drupal 8 to Drupal 9?” “What do I need to do to prepare before upgrading?” And top-of-mind is the big question: “What will Drupal 9 be like to work with?”

Read on as we share what you’ll need to know … and what might surprise you.

Anybody who’s upgraded from Drupal 7 to Drupal 8 recalls the giant chasm between the two systems. Almost 200 new features were launched including an entirely new page editor, a new theme engine, a new text editor, and new field types, to name but a few.

This gap doesn’t exist between Drupal 8 and Drupal 9. In fact, on the surface, there IS no difference: Drupal 9 has the same code, functions, and feature set as Drupal 8.9.

So why release it then? As it turns out, there are differences — they’re just not front-and-center on the interface.

Time to Clean House

Throughout its development cycle, Drupal 8 has wound up with a lot of code debt: functions that were created programmatically and used for some time but have been rendered redundant by more efficient functions.

These bits of code clutter up Drupal 8 like your old CDs and DVDs clutter up your bookshelf: There’s nothing wrong with them, but you probably don’t need them anymore now that you have something more efficient.

The result of all this extra code is that programmatically, there might be 10 different ways to do one single thing.

What Drupal has done is marked all of those code items in the backend code base as being “deprecated”. When Drupal 9 comes out, the plan is to remove all the deprecated code on this list, leaving only the latest version of whatever that code’s API is. They’ll also be updating third-party dependencies, such as Symfony and Twig. From Drupal’s site:

“Drupal 9 will be a cleaned-up version of Drupal 8. It will be the same as the last Drupal 8 minor version with our own deprecated code removed and third-party dependencies updated. We are building Drupal 9 in Drupal 8.”

Will Drupal 9 Be Better?

Yes, but not without some minor risks.

Jettisoning all this deprecated code will result in a much faster, cleaner, and better-operating version of Drupal. However, if you have legacy programs whose modules use some of that deprecated code, you could find yourself with some broken processes.

How to Prepare for Drupal 9

In general, upgrading to Drupal 9 is not an onerous process – it can literally be done via a single command. What will take more time is monitoring and auditing code bases to ensure that none of your functionality is dependent upon deprecated code.

Fortunately, Drupal is well prepared for this, and has indicated that the Drupal 8 branch of the Upgrade Status module can be used  to identify and report on any deprecated code:

“This module scans the code of the contributed and custom projects you have installed, and reports on any deprecated code that must be replaced before the next major version. Available project updates are also suggested to keep your site up to date as project will resolve deprecation errors over time.”

In addition, we anticipate that when downloading or updating modules, Drupal will likely advise whether there are compatibility issues due to bad functions. However, that notification system isn’t currently in place (if it indeed happens at all), so your best bet is to work with your development partner, who can audit your code to identify any trouble spots.

Marie Kondo-ing Your Infrastructure

Drupal 9 will be a much faster and more streamlined platform, but it doesn’t exist in a vacuum. If the rest of your operational architecture is similarly full of code debt and redundant processes, updating Drupal 9 will be akin to sending a Lamborghini down a pothole-rutted road: That powerful engine is wasted if the route is slowing it down.

So, going to Drupal 9 is an excellent opportunity to look at your legacy systems, audit them as well, and make sure your entire infrastructure is clean, fast, and free of roadblocks.

The Bottom Line

In general, upgrading to Drupal 9 should not be a complex or lengthy process. By cleaning out the clutter and performing some common dependencies, Drupal is practicing good development hygiene and providing its customers with a more streamlined system that will be faster … but still familiar.

Want to know more? Contact us today!

Jan 17 2020
Jan 17

The World Wide Web without barriers could be an amazing place for everyone. What about your website — does it follow web accessibility guidelines?

Our web team respects accessibility and is always ready to help you make your website accessible. We also love to share tips about creating accessible content and making your images accessible in your team’s everyday content editing practices.

This post will sum up everything you wanted to know about accessibility (a11y for short): what it means to make your website accessible, what accessibility tools are available based on your site’s CMS (Drupal modules and WordPress plugins), and much more.

What does it mean for a website to be accessible?

An accessible website is one that is available to all users regardless of their visual, auditory, cognitive or motor disabilities. It is friendly in every aspect — from color contrast to keyboard navigation.

No user is left behind — the site’s content and UI are easy to comprehend and control in various ways including via assistive technologies.

Why is accessibility important for a website?

  • Website accessibility (a11y) enhances your brand’s reputation because it shows your attitude. According to the Centers for Disease Control and Prevention, roughly one in four adults in the US has some form of impairment. Most people have a friend or acquaintance with a disability, and they appreciate your willingness to follow the guidelines.
  • Make your website accessible and stay protected against possible legal proceedings. The Americans with Disabilities Act (ADA) prohibits discrimination against people with disabilities. It states that everyone should be provided with equal access and opportunities. There are an increasing number of lawsuits against businesses with inaccessible websites.
  • An accessible site gets a much wider reach. To estimate the figures, consider the above mentioned quarter of the US population and add users with situational issues. These may include broken arms, tired eyes, or even just the need to use your site’s content in a non-native language. In all these cases, users will love your accessible site.
  • By making your website accessible you boost your SEO. Being ready for assistive tools is in many ways similar to being ready for search engines. ALT tags describing the images, clear meta descriptions, video captions, a clear menu hierarchy, and other a11y practices are good SEO practices as well.

How do I add accessibility to my website?

To make your website accessible, you should follow the WCAG (Web Content Accessibility Guidelines). They are the international web standards embracing every aspect of your site’s interaction with users who have an impairment.

The WCAG has been brought to us by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). They are based on four key principles:

  • Content is perceivable
  • Interface elements are operable
  • Content and controls are understandable
  • Content is robust enough

WAI has also developed ARIA (Accessible Rich Internet Applications Suite). This is a suite of attributes that make interfaces, especially rich and interactive ones, more understandable to assistive devices. WAI-ARIA attributes (roles, states, and properties) can be added to the HTML markup.

Considering all the above, here are some of the key things required from you to make your website accessible:

  • text equivalents for non-text content (ALT tags for images, captions for videos, transcripts for audios, etc.)
  • the proper HTML markup (with the use of WAI-ARIA where necessary)
  • logical layout
  • keyboard controls
  • clear field labels
  • informative error messages
  • clear and simple language
  • informative link texts
  • sufficient color contrasts
  • text resizability
  • adjustable audio volume
  • no auto-playing media
  • more time to complete regular actions

and much more.

Tools to make your Drupal or WordPress website accessible

If your site is built with a CMS, you are in luck . It should already have built-in or add-on plugins to make your website accessible. They are easily installed and configured on your website and take care of various a11y aspects.

Since our agency’s main expertise is Drupal and WordPress, we will list a bunch of helpful extensions for both these CMSs — Drupal modules and WordPress plugins that make your website more inclusive and compliant.

Drupal accessibility modules

Automatic Alternative Text

The Automatic Alternative Text module generates alternate texts to describe images using the Microsoft Azure Cognitive Services API. This is an example of how artificial intelligence helps you make your website accessible.

Automatic Alternate Text - Drupal accessibilty module

CKEditor Accessibility Checker

It’s important that you make your content accessible in everyday editing practices. The CKEditor Accessibility Checker module inspects the content created in Drupal content editor and immediately resolves the issues found. The module may soon become part of the Drupal core.

CKEditor Accessibility Checker Drupal module

Block ARIA Landmark Roles

The use of WAI-ARIA in your site’s markup becomes more advanced with the Block ARIA Landmark Roles Drupal module. Every block in your site’s layout can be assigned an ARIA landmark role and/or ARIA labels directly in the block configuration form.

Block ARIA Landmark Roles - Drupal accessibility modules

High contrast

The High contrast module enables users to switch between the active theme on your Drupal site and a high contrast version of the theme. This will make your website more accessible to users with eyesight problems.

Text Resize

Since adjustable text size is one of the requirements to make your website accessible, the Text Resize module is very helpful. It provides website visitors with a block that has two buttons to make the font size larger or smaller.

Text Resize - Drupal accessibility modules

Text Size (Drupal 7 only)

The Text Size module serves a similar mission. It provides an adjustable text size changer or a zoom feature. Though its zoom capabilities are similar to text zoom in Firefox, the module can also work with variable media objects, pixel images, and vector images.

Text Size - Drupal accessibility modules

htmLawed

The proper HTML markup is essential in making your website accessible. The htmLawed Drupal module gives you highly customizable control of your HTML. It uses the htmLawed PHP library to restrict and purify the code.

htmLawed - Drupal accessibility modules

WordPress accessibility plugins

WP Accessibility

The WP Accessibility is a multi-functional plugin to help you make your website accessible. Its wide range of features includes enabling skip links, enforcing ALT tags on images, adding language and text direction attributes, providing a font size and color contrast toolbar and more.

WP Accessibility Helper (WAH)

Here is another multipurpose plugin with basic a11y tools — WP Accessibility Helper (WAH). It adds a user-friendly accessibility toolbar to your site. Among its key features are a skip links menu, adjustable fonts and color contrasts, accessibility error scans and more.

WP Accessibility Helper (WAH) plugin

Accessibility by UserWay

The UserWay plugin provides a smoother browsing experience on your website, with particular attention to keyboard navigation. It performs smart modifications to your site’s elements in order to make them more compliant with the a11y requirements.

Accessibility by UserWay WordPress plugin

Accessibility Widget

The Accessibility Widget plugin adds a sidebar widget to allow users to easily make the text size larger or smaller in your WordPress website. It offers the “Small,” “Medium” and “Large” text options.

WCAG 2.0 form fields for Gravity Forms

The WCAG 2.0 form fields for Gravity Forms plugin makes the forms created by the famous Gravity Forms builder more accessible on your site. It wraps form fields in a fieldset, adds ARIA attributes, gives on-page error messages with the number of errors and links to them, etc.

WCAG 2.0 form field for Gravity Forms WordPress plugin

Screen Reader WCAG Accessibility Tools

Here is a plugin that makes your website accessible by adding a text-to-speech engine to it. The Screen Reader WCAG Accessibility Tools plugin can read the text in 50+ languages. However, the free version of the plugin is limited to 100 characters.

WP Accessibility Tools & Missing Alt Text Finder

Here is a plugin that helps you make your website accessible in a number of ways. The WP Accessibility Tools & Missing Alt Text Finder offers a missing alt text finder, contrast ratio checker, compliance checklist, automated accessibility audit, and more.

WP Accessibility Tools & Missing Alt Text Finder WordPress plugin

SOGO Accessibility

The SOGO Accessibility plugin for WordPress scans your website’s code and adds the accessibility support automatically. It uses JS and CSS to improve or enable accessibility features.

SOGO Accessibility WordPress plugin

Our experts are ready to make your website accessible

Hopefully, this article has provided a good review of the basic accessibility principles, requirements, and tools based on your CMS.

The above listed Drupal modules and WordPress plugins are just a few of the many. Our web development team can select or create from scratch the ones that will suit your website best. Let us make your website accessible in every way!

Jan 17 2020
Jan 17

With the release of Drupal 8.8, Drush is also due for an upgrade — to Drush 10. For this venerable command-line interface that many Drupal developers know intimately well, what does the present and future look like? What considerations should we keep in mind when selecting Drupal Console or Drush? What new features are available in Drush 10 that characterize the new CI/CD approaches we see expanding in the Drupal community?

In this Tag1 Team Talk, join the creator and maintainer of Drush Moshe Weitzman (Senior Technical Architect at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Preston So (Editor in Chief at Tag1), and Michael Meyers (Managing Director at Tag1) for a journey through Drush’s history and promising future. We take a deep look at what made Drush what it is today, the most compelling features in Drush 10, and how a hypothetical Drush in core could look.

[embedded content]
Jan 17 2020
Jan 17

As Dries Buytaert explained in his Plan for Drupal 9 post at the end of 2018 (emphasis mine):

Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.

Here we are 14 months later and while most people took the June 3 release date and took it for granted, it is still not guaranteed! However you can help in various ways to make it much more likely!

Late last fall, we focused on defining what it means if we cannot make the June 3, 2020 release despite our best efforts and what is an early indicator that tells us we are going to miss it. First of all, that meant defining requirements for the first alpha release and requirements for the first beta (API complete) release. Also we needed to set some expectations as to when do we want to see the API-complete beta release to give enough time for the ecosystem to test it and find important problems in time. Based on how soon the beta requirements are met, there are three release scenarios and the best case ending in the June 3, 2020 release date for Drupal 9 has a beta deadline in 6 weeks! Yes, 42 days!

Alpha requirements simplified

The key requirements for the first alpha release are simple. We wanted to update the key dependencies: Symfony to version 4.4 and Twig to version 2, as well as remove frontend polyfills that were not needed and remove most of jQuery UI (which were already deprecated in Drupal 8). This gets our most important dependencies up to shape to what will be in Drupal 9. We also made it possible for contributed projects to depend on Drupal 8 and 9 at the same time, so they will not need to branch for Drupal 9 support.

There are two outstanding things for the Drupal 9 alpha:

  1. Drupal.org does not yet have an automated packaging pipeline that conforms to all the recent composer related improvements and therefore making core releases is error prone. I don't believe you can help with this at this time, the Drupal Association is hard at work on this.
  2. Drupal core should use a major version agnostic update feed for projects which is already being provided by Drupal.org but the core code to consume it is still in the works. While this is actively being worked on, reviews are always helpful. This will make sure Drupal 9's Update Status gets only contributed projects that are actually Drupal 9 compatible, while contributed modules will not need to establish a Drupal 9 branch.

Beta requirements simplified

The beta requirements are a bit more complicated and longer of course because we are looking at being API complete here. Once again, for the June 3, 2020 release date, we need these done in 6 weeks! The issue lists must haves and should haves, however the should have issues should be considered must-have for the June 3, 2020 release date and would only be reconsidered later if that date cannot be met. Here is a simplified rundown of the beta requirements:

  1. We want to keep dependencies up to date. There is no concrete pressing issue here at the moment that I know, but this really depends on how our dependencies evolve.
  2. We'd like to remove all the deprecated APIs themselves. Last year I built a graph to track this, and it shows nicely that we are down to half of them remaining (yay!), but still quite enough to deal with. There are various outstanding issues you can help with here.
  3. We want to make sure people can update to Drupal 9 from Drupal 8 by resolving critical upgrade path bugs. If you cannot update to a later version of Drupal 8 due to some critical bug, then you will be stuck on your version of Drupal 8. Not good. These include views, layout_discovery, taxonomy, menu_content, etc. related issues. All of them need help. If you are on an older version and can reproduce the problems, that is useful. If you have experience in these areas, your input would be useful.
  4. It will only be possible to update to Drupal 9 from Drupal 8.8 or 8.9, so all older update paths and their tests should be removed. Older versions of Drupal 8 will themselves be unsupported already at the time of Drupal 9's release. This issue is getting close but needs reviews.
  5. No new security or data integrity issues should be in Drupal 9. If there are any, they should be resolved. I don't know of any issues at the moment here.
  6. The API should be complete. There are no critical API additions or changes that I know of at the moment in this general category.
  7. We want to make sure people can migrate from Drupal 6/7 to Drupal 9. This needs the remaining multilingual migration paths to go stable. This is an area where we posted several call to actions, but still need your help. There are proposed migration paths for node translations and entity translations that respect revisions but they need at least code reviews to make sure they are good. Otherwise if you had content translations with revisions, the migration will not be correct. Without that, multilingual migrations will not go stable.
  8. PHP requirements should be finalised. It is likely at this time that Drupal 9 will require PHP 7.3 that is being worked on currently and could use a review.
  9. Database requirements should be finalised in terms of MySQL/MariaDB/Percona and PostgreSQL. Both issues need data as to which distributions and hosts support certain versions.
  10. The right security update information should be provided for users taking the one year support cycle and long term support of the last Drupal 8 release. This could also use reviews.
  11. We should put Drupal's base theme on a track so that it can evolve in Drupal 9 finally. This involves creating a new stable9 theme and decoupling the core themes from Classy. Various issues to help with here.
  12. Drupal.org should support multi-core compatibility eg. on project pages, localize.drupal.org, etc. This work is currently deprioritised by the Drupal Association due to the focus on the packaging pipeline blocker that I listed first. Once this gets attention, it will likely uncover core issues to resolve as well.

The two areas that receive the least attention at the moment are upgrade path blockers and the stability of the multilingual migration path, so those two are the most pressing where we need your help!

While the above is a complete rundown of the current beta requirements, it may change later on, so refer to the beta requirements issue later on for up to date information.

What happens if all the above are not done by end of February (in six weeks)

If all goes well, with your help, we'll be done with all the above in six weeks. If that does not work out, we have a plan B and a plan C. Here is how those options unfold. If beta requirements are only done two months later by end of April, then Drupal 9's first beta will be released on the first week of May and Drupal 9 is to be released on August 5, 2020. If the beta requirements are only done by end of August (four more months later), than the first beta will be released than with a Drupal 9 release date of December 2, 2020. In this case a Drupal 8.10 may also be released if needed. These dates are spelled out well in the Drupal core release cycle overview. I created this visual to help understand the alternate timelines:

Drupal 9 release scenarios visualised

While I think it is reassuring that we have plans for what happens if our initial date targets don't work out, unfortunately the end of life date at the end of next year for Drupal 8 is not movable because it is based off of Symfony 3's end of life. So the sooner we can make Drupal 9 happen (while meeting the upgrade and stability requirements) the better. What are you going to work on to help?

Helping with contributed projects

Based on the PHP deprecations our tools can identify, 43% of contributed projects would only need info.yml file updates to be Drupal 9 compatible. An additional 41% of the remaining projects have only issues that are resolvable now (even while keeping support for Drupal 8.7). Solving those anytime between now and Drupal 9's release (whenever it is) would put us to almost six thousand contributed projects compatible with Drupal 9 on day one! While that is a very idealistic number, helping with contributed projects is nonetheless a great avenue to contribute to Drupal 9 readiness. Help at the Drupal Global Contribution Weekend at end of next week or anytime before and after! I prepared a quickstart guide for this occasion.

Jan 17 2020
Jan 17

Last year I embarked on a personal open source challenge, focused on Drupal. Very easy to say: “12 months 12 patches”. Some months my work lent itself naturally to contributions, but when it didn’t, I got creative. Here’s how I made it happen, and inspired others on my team to follow suit. 

Drupal


I’ve been working with Drupal for quite a few years now. Drupal is open source, and thanks to that, we (and so many other companies) can build powerful websites that match our client’s expectations. Drupal has a very powerful and capable core which offers CMS functionalities that allow you to build powerful sites by clicking around the Drupal UI.

It also has contributed modules, which aren’t used on every site and you can choose to enable for your new site if you need that functionality. There is also a big pool of base themes that you can build upon that will give your site a great starting point and make it look nice.

We often build on top of existing modules and themes. We enhance them or create our own, sometimes tailor-made to the site’s context, sometimes generic enough so the module or theme can be made available to Drupal and therefore to the whole community. 

I’ve always loved this. By sharing it you make the product bigger, more robust, better in general and we don’t need to reinvent the same wheel over and over. 

Modules and Patches


However, building a whole new module or theme is usually not a quick task, or even desired in some cases (if something similar is out there already). So we often find ourselves trying to leverage existing modules. 

Probably the easiest way to contribute to an already big community and an already big set of modules and themes is to help them improve by either fixing little bugs, or by adding new features to them. This is done usually via what we call “patches” (which under other platforms could be called a “pull request”). A patch is just a file that contains changes to the existing source code that will fix or enhance the given project.

For example: if the webform module lacks a type of field for emails, we could create a patch that adds that capability and submit it for the community to review it, and to the maintainer to merge it into the main project. If all goes well, then the webform module will now support emails as a field type, so everybody will benefit from it when updating the module.

The Challenge


At Amazee Labs, we encourage a workflow that lends itself to both contribution and client projects. I knew I wanted to incorporate contribution into my work on an even more regular basis, so my 2019 resolution was to submit (at least) one patch a month to a Drupal module. 

Some months it was easy, especially when opportunities for the contribution came right out of working on a ticket. For others, it wasn’t so easy. When I didn’t see any obvious chances to contribute in my work for the month, I set a practice of searching through the issue queue of any module I was installing and working on one of them. This made me inspect the code, see how it was structured and eventually create a patch for an existing issue.

Working in this manner vastly improved my Drupal knowledge, and cemented my personal resolution to regularly contribute. After each month, I felt like I was helping Drupal (even if it was just a tiny bit) one way or another.

Drupal Patches

I was really happy that I could complete the challenge. Some team members joined during the year and that made the challenge more fun and encouraged me to carry on. Also, as team lead, I had already agreed with some of my team members to set this challenge for them as well for 2020. We have a Slack channel where we share the patches, ask questions, encourage each other, etc.

So if you’re using Drupal and you’d like to contribute more, maybe this could be a challenge that you could also take for 2020.

The Patches


In case you were wondering which patches were submitted, here is the full list:

January

February

March

April

May 

June

July

August

September:

October 

November

December

Happy coding!
 

Jan 17 2020
Jan 17

Drupal is well known for its flexibility in managing and presenting content. Drupal View Modes allow you to render (display) a Drupal entity or entities (like nodes) in a certain way, based on a particular context. 

This tutorial will demonstrate the usage of Drupal View Modes with an example. We will install and also use the modules Field Group and Display Suite.

Let’s get started!

Step #1. Install the Required Modules

  • Open terminal application and place the cursor in the root of the Drupal installation.

  • Type:

composer require “drupal//field_group:^3.0"

composer require drupal/ds

What are View Modes in Drupal 8

What are View Modes in Drupal 8 

  • Click Extend.

  • Enable Display Suite and Field Group.

  • Click Install.

What are View Modes in Drupal 8

The system will prompt you to enable the Layout Discovery module.

  • Click Continue.

No further modules are required.

Step #2. The Content Type

For the purpose of this tutorial, we am going to create a content type called ‘Famous person’ with the fields detailed in the table below. Follow along with the same content type or create another one, like ‘Author’, ‘Patient’ or even another entity type like ‘Member’, for example — remember, view modes can be applied to all kinds of entities, not just nodes

Field name

Field type 

Allowed number of values

Additional info

Image

Image

1

 

Born

Date

1

Date only - Field group Personal data

Died

Date

1shu

Date only - Field group Personal data

Known for

Text (formatted long)

1

Field group Personal data

Early life

Text (formatted long)

1

 

Lifework

Text (formatted long)

1

 

Death

Text (formatted long)

1

 

Trivia

Text (formatted long)

1

Bulleted list

File download

File 

Unlimited

Additional files to download / Allowed file extensions: txt, pdf, doc, xls, xlsx, docx, jpg, png

Related links

Link

Unlimited

Link to other resources

 The fields:

  • Born

  • Died

  • Known for

will be grouped in a field group called Personal data.

What are View Modes in Drupal 8

Step #3.  Create the Field Group

  • Click Manage display > Add field group.
  • Select Fieldset in the dropdown.
  • Add a proper label.
  • Click Create group.

What are View Modes in Drupal 8

  • Drag the fieldset below the Image field. 

  • Hide the Image label.

  • Group the fields inside the fieldset by indenting them.

  • Make the labels within the fieldset inline.

  • Click Save.

What are View Modes in Drupal 8

Notice, that we are already configuring one of the two active view modes in Drupal (Default and Teaser).

The Default view mode shows the whole node, whereas the Teaser view mode shows the teaser display of articles on the front page of Drupal.

Step #4. Create Content

  • Click Content > Add Content > Famous person

  • Create 4 to 5 nodes

What are View Modes in Drupal 8

 Step #5. Create Custom View Modes

  • Click Structure > Content types.

  • Select Manage display for the ‘Famous person’ content type.

What are View Modes in Drupal 8

  • Scroll down and click Custom display settings.

  • Click Manage view modes.

Here we can configure existing view modes across different entity types (bundles). We can also create custom view modes to match our design or information requirements. 

  • Click Add view mode. 

What are View Modes in Drupal 8

  • Click Content.

  • Give the view mode a proper name.

  • Click Save.

200106 view modes 010

  • Create 2 more view modes.

I used these names:  Lifework view mode   -   Trivia view mode

What are View Modes in Drupal 8

  • Click Structure > Content types.

  • Select Famous person > Manage display.

  • Scroll down and click Custom display settings once again.

  • Check the 3 view modes you have just created.

  • Click Save.

What are View Modes in Drupal 8

  • Click the Personal data view mode.

  • Scroll down and select Two column layout (under the Display Suite options) from the dropdown.

  • Click Save.

  • Click Save again (eventually) to move fields to the new column.

  • Drag the Personal data fieldset to the top of the left column.

  • Place the three corresponding fields accordingly.

  • Place the image on the right column.

  • Change the Image style to medium.

  • Click Update.

  • Drag all other fields to the Disabled section.

  • Scroll down and click Save.

What are View Modes in Drupal 8

  • Repeat the process with the other two view modes Using the layout options:

    • Three-column equal width

    • Three-column 25/50/25

What are View Modes in Drupal 8

What are View Modes in Drupal 8

Step #6. Create a View

  • Click Structure > Views > Add view.

  • Give the view a proper name. 

  • Select Content of type Famous person.

  • Check Create a block.

  • Change the number of Items per block to 1.

  • Check Use a pager.

  • Click Save and edit.

What are View Modes in Drupal 8

  • Click the Fields option under the Format section. 

  • Select Content.

  • Click Apply.

What are View Modes in Drupal 8

  • Select the first view mode. 

  • Click Apply.

  • Click Save.

What are View Modes in Drupal 8

  • Click the Advanced section on the right of Views UI.

  • Click on Use AJAX: No.

  • Check Use AJAX.

  • Click Apply.

  • Click Save.

What are View Modes in Drupal 8

  • Create 2 more blocks with the same process. The only setting that will differ will be the view mode in the Format section.

What are View Modes in Drupal 8

What are View Modes in Drupal 8

Step #7. Place the Blocks

  • Create an article with just the title.

  • Click Save.

What are View Modes in Drupal 8

  • Click Structure > Block layout.

  • Scroll down to the Content section.

  • Click Place block.

  • Search for all 3 blocks.

What are View Modes in Drupal 8

  • Click Place block.

  • Uncheck Display title. 

  • Restrict the block to the article we just created.

  • Click Save block.

What are View Modes in Drupal 8

  • Repeat the process with the other 2 blocks.

  • Rearrange the blocks beneath the title.

  • Click Save blocks.

What are View Modes in Drupal 8

Head over to the article and take a look.

What are View Modes in Drupal 8

Drupal coolness! Congratulations!

Please tell us how you plan to use this useful Drupal feature. 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.
Jan 16 2020
Jan 16

My goal in this post is to explore creating a Drupal powered mobile app with React Native. With no prior experience with React Native or React JS myself, this is truly an exploratory quest. I do have some experience with Angular 2-7 and AngularJS before it, so I admit I might have some more familiarity with concepts and code structure. 

What is necessary however, is an understanding of a few core things, namely Javascript 6 (ES6), as React Native supports and uses it, as well as Promises and HTTP Requests.

To explore React Native, I opted to replicate the sample ReactJS + NextJS sample application available on GitHub and visible here powered by this Drupal site as a React Native application. In the process, I’ll explain the core concepts I felt I had to learn and provide code where applicable.

While its not necessary to know ReactJS at all to get started with the React Native tutorial, as it assumes you have no prior knowledge of React or React JS, it would probably be helpful if you were at least a little familiar with ReactJS. I myself spent a little time familiarizing myself with how ReactJS works and even building a simple application before starting to work with React Native.

Building the application

Disclaimer: My aim is not to create a beautifully styled app, but simply get something up and working as quickly as possible. I added minimal styling. The app was built on a Mac for iOS. So let's begin.

You can find the finished code on GitHub.

First, create a new project, I named mine DrupalReactNative:

react-native init DrualReactNative

Project Structure

The first decision I made was how to structure the project. I came to Atomic Design because I stumbled upon an article that pointed out React follows the same principles as Atomic Design. I’d never used Atomic Design outside of the context of CSS, so I did look for examples of how this was implemented in React. 

cd DrupalReactNative/
mkdir src
cd src
mkdir components
cd components
mkdir atoms molecules organisms pages templates

After some research, specifically looking at the site I was building, I settled on the following folder structure and breakdown of files:

preview of folder structure on a bright blue background

This is by no means the “correct” way to organize folders, but this is what I settled on. We will come back to the code later.

Additional Libraries

I chose to use React Navigation (and related required modules) to handle the app navigation, and despite React implementing the straightforward Fetch API for network requests, I was a little lazy and used React Native Rest Client for network requests. This made the networking tasks even easier and React Native Vector Icons for menu icons.

From root directory:

npm install react-navigation react-navigation-stack
npm install react-native-gesture-handler react-native-rest-client
npm install react-native-screens react-native-reanimated
npm install react-native-vector-icons

Then install the pods for IOS:

cd ios
pod install

You will then have to manually install Vector Icons.

Note: I found the only thing that worked was adding font to Xcode. Failure to do this will result in an unknown font error when trying to compile.

Routing/Navigation

At this point, on running react-native run-ios, you should get the default app with the default screen. Now we will replace the contents of the App.js file with the following:

import React from 'react';
import RecipeApp from './src/RecipeApp';

const App = () => {
  return (
      <RecipeApp />
  );
}

export default App;

Then create the referenced file, RecipeApp.js in the src directory:

import React from "react";
import { createAppContainer,} from "react-navigation";
import { createStackNavigator } from "react-navigation-stack";
import HomePage from "./components/pages/Homepage/index";
import Recipes from "./components/pages/Recipes/index";

const MainNavigator = createStackNavigator({
    Homepage: HomePage,
    Recipes: Recipes,
  },
  {
    initialRouteName: 'Homepage',
    headerMode: 'none',
  },
);

const RecipeApp = createAppContainer(MainNavigator);
export default RecipeApp;

The code references 2 custom items which we will also create.

First, the homepage which will be in the pages folder in the components directory:

import React from 'react';
import { Text, View, Button } from 'react-native';

export default class HomePage extends React.Component{
  render() {
    return (
      <View style={{margin: 20, marginTop: 30, flex: 1}}>
        <Text style={{marginTop: 10, fontSize: 28, fontWeight: 600}}>Contenta + React Native</Text>
        <View style={{flex: 1, flexDirection: 'row'}}>
          <Button
            style={{flexDirection: 'row'}}
            onPress={() => {
              this.props.navigation.navigate('Homepage');
            }}
            title="Home"
          />

          <Button
            style={{flexDirection: 'row'}}
            onPress={() => {
              this.props.navigation.navigate('Recipes');
            }}
            title="Recipes"
          />
        </View>
        <View style={{flex: 1}}>
          <Text style={{fontSize: 24, fontWeight: 600}}>Home</Text>
          <Text>Lorem Ipsum</Text>
        </View>
      </View>
    );
  }
}

I added some very basic styling. It’s worth mentioning that styling in ReactNative, like styling in React, is in JavaScript, hence the camel case code.

I practically repeat the same for the Recipes page, which should now give us 2 screens and a working navigation:

import React from 'react';
import { Text, View, Button } from 'react-native';

export default class Recipes extends React.Component{
  render() {
    return (
      <View style={{margin: 20, marginTop: 30, flex: 1}}>
        <Text style={{marginTop: 10, fontSize: 28, fontWeight: 600}}>Contenta + React Native</Text>
        <View style={{flex: 1, flexDirection: 'row'}}>
          <Button
            style={{flexDirection: 'row'}}
            onPress={() => {
              this.props.navigation.navigate('Homepage');
            }}
            title="Home"
          />

          <Button
            style={{flexDirection: 'row'}}
            onPress={() => {
              this.props.navigation.navigate('Recipes');
            }}
            title="Recipes"
          />
        </View>
        <View style={{flex: 1}}>
          <Text style={{fontSize: 24, fontWeight: 600}}>Recipes</Text>
          <Text>Ipsum Lorem</Text>
        </View>
      </View>
    );
  }
}

With that you should have an app with two screens and screen to screen navigation.

Components and Data

With the basic structure in place, we can now jump to creating components and retrieving data. For this I copied most of the structure of the React + NextJS repo and updated the code for React Native. 

I had to create a custom class to transform the JSON:API response into a usable object (JSON:API, part of Drupal core, is one of the key modules used in Contenta as it’s API first). This was necessary because all attempts to normalize the response using various libraries failed. The following code is used to process all incoming responses:

import React from 'react';

export default class Transform extends React.Component {
  transformJson(obj) {
    let nodes = [];
    if (typeof obj.data.type !== 'undefined' && obj.data.type == 'recipes') {
      item = obj.data;
      const node = {
        id: item.id,
        title: item.attributes.title,
        difficulty: item.attributes.difficulty || '',
        ingredients: item.attributes.ingredients || [],
        numberofServices: item.attributes.numberofServices || 0,
        preparationTime: item.attributes.preparationTime || '',
        instructions: item.attributes.instructions || '',
        totalTime: item.attributes.totalTime || '',
        image: transformJsonGetImage(obj, item.relationships.image.data.id),
        category:
          typeof item.relationships.category !== 'undefined'
            ? transformJsonGetCat(
                obj,
                item.relationships.category.data.id,
                'categories',
              )
            : '',
      };
      nodes[0] = node;
    } else {
      obj.data.forEach(function(item, index) {
        const node = {
          id: item.id,
          title: item.attributes.title,
          difficulty: item.attributes.difficulty || '',
          ingredients: item.attributes.ingredients || [],
          numberofServices: item.attributes.numberofServices || 0,
          preparationTime: item.attributes.preparationTime || '',
          instructions: item.attributes.instructions || '',
          totalTime: item.attributes.totalTime || '',
          image: transformJsonGetImage(obj, item.relationships.image.data.id),
          category:
            typeof item.relationships.category !== 'undefined'
              ? transformJsonGetCat(
                  obj,
                  item.relationships.category.data.id,
                  'categories',
                )
              : '',
          tags:
            typeof item.relationships.tags !== 'undefined'
              ? transformJsonGetTags(obj, item.relationships.tags)
              : '',
        };
        nodes.push(node);
      });
    }

    return nodes;
  }
}
// Gets tags.
export function transformJsonGetTags(res, obj) {
  let tags = [];
  obj.data.forEach(function(item, index) {
    tags.push(transformJsonGetCat(res, item.id, 'tags'));
  });
  return tags;
}
// Gets category of item.
export function transformJsonGetCat(obj, id, type = 'tags') {
  name = '';
  obj.included.forEach(function(item, index) {
    if (item.id == id && item.type == type) {
      name = item.attributes.name;
    }
  });

  return name;
}
// Gets image
export function transformJsonGetImage(obj, id) {
  fid = '';
  src = '';
  obj.included.forEach(function(item, index) {
    if (item.id == id && item.type == 'images') {
      fid = item.relationships.thumbnail.data.id;
    }
  });
  obj.included.forEach(function(item, index) {
    if (item.id == fid && item.type == 'files') {
      src = item.attributes.url;
    }
  });
  return src;
}

Now to update the homepage:

The homepage contained 5 components and api calls to supply data.

import React from 'react';
import {View} from 'react-native';
import Header from '../../../components/organisms/Header/index';
import {ScrollView} from 'react-native-gesture-handler';
import RecipeApi from '../../../api/recipe';
import PromotedRecipes from '../../organisms/PromotedRecipes/index';
import Transform from '../../../utils/Transform';
import MonthEdition from '../../organisms/MonthEdition/index';
import HomeWidgets from '../../organisms/HomeWidgets/index';
import RecipeList from '../../organisms/RecipeList/index';
import styles from '../../templates/styles';

export default class HomePage extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      promotedItems: [],
      latestRecipes: [],
    };
  }

  initialize = () => {
    recep = new RecipeApi();
    t = new Transform();
    try {
      recep
        .getPromoted()
        .then(response => response)
        .then(responseJson => {
          const transformed = t.transformJson(responseJson);
          this.setState({promotedItems: transformed});
        })
        .catch(error => {
          console.error(error);
        });
    } catch (e) {}
    try {
      recep
        .getAll()
        .then(response => response)
        .then(responseJson => {
          const transformed = t.transformJson(responseJson);
          this.setState({latestRecipes: transformed});
        })
        .catch(error => {
          console.error(error);
        });
    } catch (e) {}
  };
  componentDidMount() {
    this.initialize();
  }

  render() {
    return (
      <View style={styles.container}>
        <ScrollView stickyHeaderIndices={[0]}>
          <Header navigation={this.props.navigation} style={styles.header} />
          <View>
            <PromotedRecipes
              recipes={this.state.promotedItems}
              navigation={this.props.navigation}
            />
            <MonthEdition navigation={this.props.navigation} />
            <HomeWidgets />
            <RecipeList
              recipes={this.state.latestRecipes}
              navigation={this.props.navigation}
            />
          </View>
        </ScrollView>
      </View>
    );
  }
}

I won't get into the details of each component on the homepage and will just link to the repository here.

The Recipe page contains 2 components, a node view of a node ID is supplied and a component that displays 10 recipes if there is no Node ID. Again, I won't get into the details of those components. 

import React from 'react';
import {View, Text, StyleSheet, ScrollView, Button} from 'react-native';
import NodeView from '../../organisms/NodeView/index';
import RecipeApi from '../../../api/recipe';
import Transform from '../../../utils/Transform';
import styles from '../../templates/styles';
import Header from '../../organisms/Header/index';
import RecipeList from '../../organisms/RecipeList/index';

export default class Recipes extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      nodes: [],
      allNodes: [],
    };
  }

  initialize = () => {
    recep = new RecipeApi();
    t = new Transform();
    nid = this.props.navigation.getParam('nid', null);
    if (nid) {
      try {
        recep
          .get(nid)
          .then(response => response)
          .then(responseJson => {
            const transformed = t.transformJson(responseJson);
            this.setState({nodes: transformed});
          })
          .catch(error => {
            console.error(error);
          });
      } catch (e) {}
    } else {
      try {
        recep
          .getAll(20)
          .then(response => response)
          .then(responseJson => {
            const transformed = t.transformJson(responseJson);
            this.setState({allNodes: transformed});
          })
          .catch(error => {
            console.error(error);
          });
      } catch (e) {}
    }
  };
  componentDidMount() {
    this.initialize();
  }

  goBack() {
    this.setState({
      allNodes: [],
      node: [],
    });
    this.props.navigation.goBack();
  }
  render() {
    return (
      <View style={styles.container}>
        <ScrollView>
          <Header navigation={this.props.navigation} style={styles.header} />
          <Button title="Go back"
            onPress={() => {
              this.goBack();
            }}
          />
          <View>
            {this.state.allNodes.length > 0 ? (
              <RecipeList
                recipes={this.state.allNodes}
                navigation={this.props.navigation}
              />
            ) : (
              <NodeView
                node={this.state.nodes}
                nid={this.props.navigation.getParam('nid', '')}
              />
            )}
          </View>
        </ScrollView>
      </View>
    );
  }
}

The finished product looks something like this:

Four mobile screens displaying umami recipe and home page built with react

Conclusion

There was only a slight learning curve getting up to speed on most things with React Native and as such I certainly think an experienced developer could easily make the transition. 

Prior to using ReactNative, there was a certain mystique, but it turned out to not be less complicated than I anticipated. There were certainly some challenges finding the right documentation for versions of modules I was using, but this is not unlike many Open Source projects. A few modules mentioned in tutorials or documentation I tried to follow were updated or deprecated, but save for a few issues with this, it was relatively straightforward to get the app up and running. 

Judging from my experience so far, I may certainly be a convert to React Native and will explore opportunities to build more Drupal powered native apps.

Jan 16 2020
Jan 16

Drupal 9 is just around the corner. Do you have a plan to upgrade to Drupal 9? Are you still in the “Why should I upgrade to Drupal 9 after all” phase? Wondering what your next steps should be for Drupal 9 readiness? We have answers to all your questions and a quick Drupal 9 checklist on how to prepare for Drupal 9.


The best way to prepare yourself for tomorrow is to give your best today. And very apparently, the Drupal community has done just that. I know, migrating to Drupal 8 from previous versions was hard. It meant a complete rebuild of the code and a lot of learning. But once you are fully onboard Drupal 8, life gets easier. Think of it as a hard climb for a gorgeous view from the mountaintop. Truly worth all the effort, isn’t it?
 

The Much-Talked-About Drupal 9 Release Date

One of the most frequently asked Drupal questions lately has been about the Drupal 9 release date. Drupal 9 is currently scheduled to release on June 3rd, 2020. The Drupal community has been successfully releasing minor versions every six months since the adoption of semantic versioning in Drupal 8. Every minor version came with several valuable new features. 


Drupal 8 extensively depends on third-party libraries like Symfony, Twig, Guzzle, CKEditor and must keep up pace with their updates as well. For example, Symfony 3 (Drupal 8’s biggest dependency) will reach EOL (end of life) by November 2021. The same time as Drupal 8 reaches end of life as well. Drupal 9 will be released with the latest Symfony 4.4 support and will not be backwards compatible with Symfony 3. 

Drupal 9The Drupal 9 Readiness Roadmap (Image Credits – Drupal.org)

What’s New in Drupal 9 (Drupal 8 vs Drupal 9)

Drupal 9 is already being built within Drupal 8. Drupal 8.9 will release along with Drupal 9.0 in June 2020. This is because Drupal 9 is going to be the same as Drupal 8.9, except that it will be a cleaned-up version that is updated with support for its third-party dependencies. And hence one of the outstanding Drupal 9 features is that it is so easy to upgrade!

Every new minor version of Drupal 8 saw many new features but it also contained a lot of old code so it could be backwards compatible. This “old code” is also famously known as “deprecated code”. Because of the dependencies on third parties like Symfony, Twig, etc., Drupal 9 will incorporate updates to these dependencies. Drupal contributors and module developers are collectively making the road to Drupal 9 easier by eliminating “bad smelling code” (as Jacob Rockowitz calls it in his blog about deprecating code for his Webform module) from various Drupal 8 modules.

Drupal 9What’s new in Drupal 9.0 (Image Credits - Drupal.org)

From Drupal 9.1 onwards, the same story continues. New Drupal 9 features will continue to be added every six months (Drupal 9.1..Drupal 9.2..Drupal 9.3…and so on) which will be backwards compatible with Drupal 9.

“If Drupal 9 is the same as Drupal 8.9, why should I even upgrade?”. Because Drupal 8 reaches end of life on November 2021 and will stop receiving any security fixes or updates from then on. So once Drupal 9 is released, there is an 18-month window to upgrade to Drupal 9. Sure, long-term support will be offered by Drupal vendors, but do we really want to miss out on all the new Drupal 9 features and enhancements that it will offer?

Drupal 9 Checklist

Regardless whether you’re upgrading from Drupal 7 to Drupal 9 or Drupal 8 to Drupal 9, you will need to start planning for Drupal 9. The scheduled release is soon approaching and now is a good time to get prepared for Drupal 9. 

  • Drupal 7 to Drupal 9
    If you are still on Drupal 7 and looking forward to getting onboard Drupal 9, it isn’t too late. Ideally, it is recommended you upgrade to Drupal 8 now and stay updated with the latest core releases. Migrate content and code to Drupal 8, Check for availability of modules in Drupal 8 using the Upgrade Status Drupal module, upgrade your Drupal 7 modules to Drupal 8 with the help of modules such as Drupal Module Upgrader, remove any deprecated code, upgrade to Drupal 9. And as already discussed, upgrading from Drupal 8’s latest version to Drupal 9 is easy as pie. Upgrading from Drupal 7 to Drupal 9 will take as much resource time (and resource budget) as a Drupal 7 to Drupal 8 to Drupal 9 upgrade. Drupal 7 will reach end-of-life by November 2021 and will continue to receive community support until then. 
  • Stay Up to date with Drupal 8
    With every new minor version release of Drupal 8, the benefits are not only restricted to access to new features and enhancements. It also takes you one step closer to Drupal 9. Since Drupal 8.8 is the last minor release before the Drupal 8.9 release (which also happens at the same time as Drupal 9!), it is the last Drupal 8 version to contain significant feature additions. Drupal 8.9 releases on June 3rd, 2020 and will include more stable modules (that were previously experimental) and a few UX and API enhancements. So, the best thing to do now is to keep Drupal core updated and update your website to Drupal 8.8. 
  • Weed out the Deprecated code
    Make way for new and improved features by removing old and deprecated code from your Drupal 8 codebase. When you keep Drupal core and contributed modules up to date, you are also embracing cleaner code. Updated versions remove usage of deprecated code and API. There are various methods to check for deprecated code. 
    • Sometimes functions are marked with @deprecated annotations that warn the developer that the following code is deprecated and what they should be using instead. 
    • Use a command-line tool like Drupal Check (by Matt Glaman from Centarro) to help check for deprecated code and other bugs. It can also be integrated in continuous integration environments.
    • Leverage the Drupal 8 Upgrade Status module on top of Drupal-Check for a more UI based solution. It can scan your entire Drupal project and generates a report that illustrates any compatibility issues and Drupal 9 readiness. 
    • Drupal.org also offers support to check for Drupal 9 readiness and deprecation within its testing system. Like enabling static analysis with phpStan or by setting a trigger_error() when a deprecated level is reached.

      Once identified, it is time for some manual work to remove the deprecated code and refine existing codebase. Use automated tools like Drupal 8 rector to resolve some code issues, although it does need some manual intervention.

Jan 16 2020
Jan 16

So, you already have a Drupal-based website. Great! What now? Well, you should definitely start promoting it! Some claim that nothing is ever lost on the internet; however, it won’t hurt to help your potential customers find your website using some SEO tricks. What should you do to get your website to come out of the depths of Google search results right to the first page? The following ten elements are indispensable for any website, which aims to be included high in search results.

1. H1 heading – website title tag

As the name suggests, it’s the real number one – it stores information for users (and search engines) about the topic of the subpage. It is visible to the user in the form of a title in a blog article, or a name of an item or service on a product page, and because of that, it needs to be understandable to your potential customer. It should also contain some keywords.

Out of the box, Drupal requires the author of an item to include a title and makes it easy to edit it at a later time; however, there is still some room for error, for example, if the title was never actually included in the project.
This can happen when the main page or landing pages consist of several sections or blocks. When the first thing your visitor sees on your website is a text banner, make sure that its text exactly matches the H1 heading.

2. Title tag

Unlike H1, the content of the title tag is visible as the browser tab name and in search results, where it is displayed as the title of a given result – this is the large blue text at the top of the search result. In the vast majority of cases, H1 headers and Title tags are similar.

In the case of Drupal, the Metatags module enables you to set up titles in such a way that the Title is copied directly from H1 by default, but it can be edited manually, should the need ever arise. For example, if your H1 is longer than the commonly suggested 50-60 characters, you can shorten it for SEO purposes using a Title tag.

3. Description tag

The third part of the tag triumvirate – the three HTML tags of the greatest importance for your website. It’s never an easy task to describe a website in just a few dozen characters in the title, which is why search engines display a longer description, which is taken directly from the Description tag.

However, letting the search engine fill the field automatically based on other fields of the website is hardly the best way to show what the website is really about. The Metatags module mentioned above enables you to edit this field as well, which solves this issue.

To further optimise your website in terms of SEO, make sure that H1, Description and Title tags contain similar keywords. By doing so, you will make sure that neither search engine robots, nor users will have any doubts concerning the content on your website.

example of search engine results with title url and description visible

4. HTTPS

Your website should use the HTTPS protocol, and all links using HTTP should redirect to HTTPS. Why? Security, of course. Websites, which don’t use the secure protocol are considered inferior to those, which use encrypted connections, in a bid to motivate website administrators to take care of their users’ security. Make sure that your website does not scare the visitors away with security issue warnings, and they will be much more likely to trust you.

In Drupal, HTTPS is fully supported and using it should not be any problem at all – just make sure that your server is properly configured.

5. Robots.txt

The main directory of your website should have a robots.txt file with proper content – a file used to inform website robots as to how they should index your website.

Drupal supports robots.txt file out of the box, and by default, it is configured in such a way that administrative subpages are not indexed. The only thing you will need to add manually is a link to the site map, which is discussed in more detail below.

6. Site map

Search engines use site maps to index all the pages making up a given website, which allows them to include content that was published fairly recently.

In the case of Drupal, the Sitemap module allows you to manage the content of your site map effectively. The system will automatically update the map if you set rules for different content sets and make changes concerning selected subpages.  

7.  ALT attribute

Every image and graphic element used on the website should not only have an ALT attribute, but it should also be described in a few words. This may sometimes seem to be counterintuitive and complicated, especially when it comes to graphic elements illustrating more complex or abstract concepts; however, you can also take this great opportunity to saturate the site with even more keywords. By doing so, you will provide search engines with information about the content of the image and – more importantly – you will also help people with visual impairments to use and understand your website. The software used by such people to read the content of various websites detects and reads aloud the descriptions contained in the ALT attribute.

Examples of ALT description of the header image of this blog post: improper (above) and proper (below)

Drupal enables you to add the ALT attribute when you are adding a picture or a graphic element. The best way to go about it is to make this a mandatory thing – by doing so; you will make sure that your editors won’t forget about it and won’t have to go back and do this in future.

8. URLs

Plan your website’s structure in advance and make sure that all the product links are as user-friendly as possible – this will also make them SEO friendly.

What does it mean for the link to be user-friendly?

  • It means that it’s readable to the user.
  • It may contain a keyword.
  • The words are separated with hyphens.
  • All the included words are in the language of the page.
  • The link should not contain any content from saved user session or other sources.

Just take a look at the URL of this article! At Droptica, we are using the Pathauto module, which automatically creates user-friendly URLs for every path in the system and enables us to edit them manually if needed.

9. Redirections

There are some situations in which you should use redirections on your website. From the standpoint of SEO, the most important of them are:

  • Redirections to the actual content, if the URL linking to it has been changed.
  • Redirections to new locations related to content that has been deleted.
  • Avoiding duplicated content.

Drupal offers a number of features, which are useful in all of these cases, such as creating automatic redirections of URLs containing uppercase letters to their lowercase counterparts. In the previous section, we mentioned a module that enables you to create user-friendly URLs. Redirect is yet another module that is useful for handling redirections – it allows you to create redirections to pages without a forward-slash (“/”) from pages with a slash at the end of their URLs.

10. Mobile-friendly approach

More than half of traffic on the internet is generated by users browsing using mobile devices, no wonder why search engines started prioritising mobile-friendliness as an important indicator of whether a website is relevant to the user.

Thanks to its theme engine, Drupal enables you to create responsive websites.

Summary

In this article, we shared ten important tips, which you can apply to help your Drupal-based website successfully compete for the top positions in search engine results. However, this is the absolute minimum. If you want to achieve even better results, take a look at our e-book about SEO and Drupal. In addition to numerous tips and extensive explanations, you will also find a handy checklist to help you carry out an SEO audit on your own.

You can also take advantage of our services! We will carry out an in-depth professional SEO audit of your Drupal-based website and point out how you can develop it further to make it more visible in search engine results.

Jan 15 2020
Jan 15

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

Project News

Get Ready for Drupal 9

The next minor release of Drupal will be 8.9 - to be released simultaneously with Drupal 9.0. The first target window for the release is this coming June, so now is the best time to get ready for the release.

As it turns out, many contributed or even custom modules only need a one-line change to be ready for Drupal 9. Check yours using: the upgrade status module, or the Drupal Check command line tool.

DrupalCon Minneapolis 2020

DrupalCon MinneapolisSpeaking of Drupal 9, DrupalCon Minneapolis is coming up from May 18-20. We expect their to be a large amount of programming and contribution focused on the upcoming release of Drupal 9. Minneapolis will be a great opportunity to get help with checking your module compatibility, or to find someone who can help you get your Drupal 7 or 8 site ready for the upgrade. Get your tickets now, before prices go up!

DrupalCon Europe 2020

Did you hear the news? DrupalCon Europe 2020 has been announced - and DrupalCon is coming back to Barcelona from Sep 14-17th.

Our partnership with Kuoni Congress continues, and we're excited to join you in beautiful Spain to celebrate Drupal 9 together.

Kuoni Congress

Mark your calendars, and bookmark the site - more info coming soon!

Drupal.org Update

Have you unwrapped automatic updates yet?

In November we finished the primary engineering work to support Phase 1 of the Automatic Updates initiative. In December we completed validation and testing, and launched the first stable release of the Automatic Updates module.

In its current form, Automatic Updates is available as a contributed module for both Drupal 7 and Drupal 8. After installing the module you'll be able to take advantage of three new features: 

  • When the Drupal Security Team identifies a critical release, they'll be able to publish a PSA that will be directly displayed in your admin interface. 
  • The module will run automated readiness checks to make sure your site is ready for the update, or to let you know if there are errors you need to fix.
  • The module will automatically apply Drupal core updates. 

What about automatic updates for contributed modules and composer dependencies?

The next phase of work on the Automatic Updates initiative is to support updates for contributed modules, and for sites managing Composer dependencies.

This is where we need your help! We're looking for organizational sponsors to help move this work forward. If you're interested in helping us move the initiative into the next phase, please contact the Association.

We want to thank: The European Commission, Acquia, Tag1, Mtech, and Pantheon for their support of Phase 1.

Expanding Drupal Solution content with Feature pages

About two years ago we decided to start featuring Drupal Solutions on Drupal.org. These Solutions are examples of Drupal being used in the real world in specific use cases. Our first series of this content was the Drupal Industry pages, highlighting the power for Drupal in specific industry verticals.

In December, we've just launched our next set of content, this time focusing on specific features of Drupal that set it apart from the competition. These Feature pages talk about the specific Drupal Solutions that are built around key features of the software.

Updating our packaging pipeline

Do you know what goes into a packaged release of Drupal? It's not just a git clone - and as of Drupal 8.8.0 the package you download from Drupal.org also includes Composer scaffold files.  As Drupal evolves, the way we deliver the software to users has to evolve along with it.

To support the increasingly sophisticated packaging process for Drupal, we started work on overhauling our packaging pipeline for Drupal releases. This work continues into January.

Preparing for contrib Semver

As part of Drupal 9's release we are working to migrate all of the projects on Drupal.org to properly use semantic versioning. Right now, contributed modules typically use a version format like: 7.x-1.6 or 8.x-1.7. The first part of this is just the platform version (D7 vs. D8), and the second part is the Major version and the Patch version.

We'll be migrating this version schema so that the current Major version remains the Major version, the current Patch version becomes the Minor version, and we'll add the ability to define new patch versions.

This enables several improvements. Firstly, contrib maintainers can now follow backwards compatibility policies similar to core, i.e: Major versions with backwards compatibility breaking changes, minor version with new features, and patch versions for bug fixes and security releases.  Secondly, because contributed modules can now be compatible with both Drupal 8 and Drupal 9, contrib semver will be an important part of keeping version management sane.

We've made some initial progress in that direction, and have a roadmap for completing this support.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Jan 15 2020
Jan 15

CLI tools is a great way to automate certain tasks for your CI needs. For example you re-use same shell scripts project to project. Or maybe you are integrating with some third-party service. Abstracting these tasks into your own CLI tool could be a great way to go.

You can think about some examples from Drupal world -- each hosting provider has some sort of CLI tool. European Commission has one to automate certain DevOps tasks (https://github.com/openeuropa/task-runner).

In my case I was building one for interacting with Diffy -- visual testing platform. Repository of the CLI tool is https://github.com/DiffyWebsite/diffy-cli

First, when I initially thought about idea of building a CLI tool I thought about the tools I used myself. Among them there were Drush and Terminus (Pantheon’s CLI tool). They both use https://robo.li/ so my choice was obviously to use this framework as well.

Getting started

One of the best parts of Robo is that they is a Starter project (https://github.com/g1a/starter) that will create a code for you and also push it to your github.

Once you’ve done that you can start creating your commands right away.

Command syntax

And that is simply creating classes that extend \Robo\Tasks class.

For example here is a command that saves a configuration variable:

You can definitively recognize annotations if you have build custom Drush commands in the past.

Configuration

As for configuration Robo already promotes having a config file in your home folder as a YAML file. So for Diffy we store it in ~/.diffy-cli/diffy-cli.yml file.

There is a component https://github.com/consolidation/config/ that is used in Terminus and Drush. It is really great. Allows merging configs (imagine providing defaults and allowing override them) and also getting nested properties (get(‘foo.bar.baz’) type syntax).

But for my case I just needed to save an API key. So I went with a custom Config that simply saved or loaded parsed YAML file https://github.com/DiffyWebsite/diffy-cli/blob/master/src/Config.php.

Distribution as a PHAR file, self:update

Best part of the starter project is an example how you can pack the tool into single PHAR file.

Main idea is to use Travis to build and publish your PHAR file. Main idea is that you will need to use Travis CLI tool and run “travis setup releases”. Make sure to deploy released for tags only.

I have found more detailed instructions here and here.

Because of the starter project sets the setSelfUpdateRepository() for the runner whenever in the future next release will be available -- you can simply run yourcommand self:update to self update the tool.

Jan 15 2020
Jan 15

When migrating content with the Drupal 8 migrate module, the creation and updating of new entities may fire lots of custom module hooks. This may or may not be desired; if you have found yourself here, it probably interferes with the source data in a problematic way, or unnecessarily slows down the migration process.

The cleanest way I found to stop specific hooks for specific migrations, is to add a dummy/meta field to the migration and check for its value in the hook.

Include a dummy field in the migration

In the process section of the migration, add a field with a name that will not interfere with any field name of the target entity:


  1. # This is the field that will provide a custom hook

  2. # with the information about the migration.

  3. _migration:

  4. - plugin: default_value

  5. default_value: 'blog_categories'

This is an example migration with CSV as source and taxonomy terms as target:


  1. id: blog_categories

  2. label: 'Blog category migration'

  3. migration_group: default

  4. source:

  5. plugin: csv

  6. path: 'public://migrations/blog_categories.csv'

  7. delimiter: ','

  8. enclosure: '"'

  9. header_row_count: 1

  10. ids: [tid]

  11. process:

  12. name: name

  13. # This is the field that will provide a custom hook

  14. # with the information about the migration.

  15. _migration:

  16. - plugin: default_value

  17. default_value: 'blog_categories'

  18. destination:

  19. plugin: entity:taxonomy_term

  20. default_bundle: blog_categories

  21. migration_dependencies:

  22. required: {}

  23. optional: {}

Check for the value in an entity hook


  1. /**

  2.  * Implements hook_entity_update().

  3.  */

  4. function my_module_entity_update(Drupal\Core\Entity\EntityInterface $entity) {

  5. if (isset($entity->_migration) && $entity->_migration === 'blog_categories') {
  6. return;

  7. }

  8. // Some undesired custom hook logic.

  9. }

In this case the hook will never fire for this specific migration, but may fire for other migrations. Skipping the second condition will make sure the hook will never fire for migrations where the _migration dummy field is defined.

Jan 15 2020
Jan 15

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Happy nineteenth birthday

Nineteen years ago today, I released Drupal 1.0.0. Every day, for the past nineteen years, the Drupal community has collaborated on providing the world with an Open Source CMS and making a difference on how the web is built and run.

It's easy to forget that software is written one line of code at the time. And that adoption is driven one website at the time. I look back on nearly two decades of Drupal, and I'm incredibly proud of our community, and how we've contributed to a more open, independent internet.

Today, many of us in the Drupal community are working towards the launch of Drupal 9. Major releases of Drupal only happen every 3-5 years. They are an opportunity to bring our community together, create something meaningful, and celebrate our collective work. But more importantly, major releases are our best opportunity to re-engage past users and attract new users, explaining why Drupal is better than closed CMS platforms.

As we mark Drupal's 19th year, let's all work together on a successful launch of Drupal 9 in 2020, including a wide-spread marketing strategy. It's the best birthday present we can give to Drupal.

Jan 15 2020
Jan 15
What is digital accessibility? Andrew Nevins Wed, 01/15/2020 - 17:05

The word accessibility is used to describe whether something can be used by everyone, regardless of ability. Digital accessibility is referring to websites and apps ensuring that people with disabilities (permanent, temporary or situational) find them easy to use. 

At least 15% of the world’s population - one billion people - have a recognised disability. There are many ways in which a person’s disability may affect the way they perceive information online, and how they navigate within pages. 

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