Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jul 31 2023
Jul 31

We released a new version of MaxLength just in time for me to present about it in my session, Designing User-Friendly Drupal Modules at Design4Drupal. 

MaxLength 2.1.2 is a modest improvement with three bug fixes and one new feature.  Seventeen Drupalistas helped on this release. A big thanks to each of you!

A More Accurate Character Count

The most exciting bug fix is that new lines and spaces are no longer miscounted. This was a long standing issue, first reported back in 2017 and the only major bug in the module. 

New lines were being counted as three characters and spaces we counted as two. 

A big thanks to:

Display “Hard Limit” Instead of “Force Truncate” on Form Summary

A small, but annoying bug was both reported and fixed by Paul Leclerc (paul_leclerc). After configuring a hard limit on a field, the form display summary used the old verbiage, “Force truncate” but now it displays hard limit. So satisfying. 

 

Some Code Clean Up

Binoli Lalani ran PHP Codesniffer on MaxLength and found a few issues, which she fixed. This was her first contribution to MaxLength. Thanks Binoli!

Improved Support for Link Fields

Previously MaxLength’s support link fields was limited specifically to the Drupal Core link field and the LinkIt field widgets. Michael Vanetta (recrit) rewrote the code so that any kind of link field widget is now compatible with MaxLength. Michael has contributed quite a few times to the project, so his continued support of the project is much appreciated. 

Looking Ahead for MaxLength

Us maintainers are due for another meeting to set priorities. Some bugs have recently been reported that are worthy of our attention. We would also like to clean up the JavaScript code further to follow best practices. Who knows, we might even get ambitious and rewrite it in vanilla JavaScript so that we no longer require jQuery. If anyone out there has the time and skills to work on any open issues, we always welcome the help. You can reach out in the issue queue or messaging me, cedewey, on drupal.org

Mar 31 2023
Mar 31

To effectively communicate, we need to know who and how people are responding to our content. A key part of this is collecting data on our website, known as website analytics. 

For a long time, Google Analytics has been the de-facto analytics tool. Like many Google products, it’s free and ubiquitous. The growing concern over surveillance and big tech hegemony, however, is causing many nonprofits to rethink their relationship to Google and their data collection practices.

Google announced in 2021 that it would retire its old Google Analytics tool (Universal Analytics) in favor of a new, rewritten Google Analytics tool (Google Analytics 4). There is no way to bring your UA data into the new GA 4 platform. While GA 4 is more powerful, that power comes with increased complexity and a steep learning curve. 

Organizations are understandably questioning whether GA 4, a tool designed primarily for ecommerce websites, is a good fit for their nonprofit websites. There are several established and well-designed analytics tools that can be used instead of Google Analytics. 

To help you assess which analytics tool is right for you, here are some guiding questions, along with a summary of the differences between the top analytics options.

Questions to Ask When Choosing an Analytics Tool

Are you currently using, or planning on using, Google Ads?

 If you use Google Ads to drive traffic to your website, you should strongly consider using Google Analytics 4. Naturally, Google Analytics is well suited to bring in data from Google Ad campaigns.

Do you run multiple web properties that need their data aggregated?

If you have multiple websites or apps and you would like to monitor users’ activity between those properties in a single dashboard, Google Analytics 4 is well-suited to do so. If you have multiple web properties but are ok tracking the data for each separately, a simpler analytics tool is sufficient.

How often, and for what reasons, do you check your analytics?

If you check your analytics frequently (ie: weekly or monthly) and create sophisticated reports for stakeholders, the steep learning curve of Google Analytics 4 might be worthwhile. If you use analytics on a monthly to quarterly basis for more of a high level monitoring of traffic, a more lightweight solution is probably best.

How important is data privacy for you and your constituents?

Google Analytics 4 is still not compliant with the European Union’s data protection law the General Data Protection Regulation (GDPR). Plus, Google has a notorious track record for violating users’ privacy. If you share information and services that are under attack by authorities and/or bad actors (eg: reproductive health, gender-affirming care, legal aid, mental health services), then a privacy-focused analytics tool could be best for you and your site visitors.

Website Analytics Tools Comparison

Now, for a preview and breakdown of the differences between the top analytics tools out there. 

CMS-specific Analytics Tools

If your analytics reporting needs are simple, most content management systems have their own analytics tool you can use for free.

Drupal Statistics

 

If you have a Drupal website, you actually already have an analytics tool built in! It is called the Statistics module. It will take some light configuration by a developer to get it up and running for you.

Advantages
  • Free
  • Easy-to-use
  • Built into the website
  • GDPR-compliant
  • 100% Data Ownership
Disadvantages
  • Drupal websites only
  • Only tracks pageviews
  • Site traffic statistics are less accurate than third-party analytics tools

WP Statistics

 

If you have a WordPress website, WP Statistics is a plugin with a free tier. Like the Drupal Statistics module, it requires some light configuration by a developer.

Advantages
  • Free
  • Easy-to-use
  • GDPR-compliant
  • 100% data ownership
  • Tracks pageviews, traffic sources, visitor location and search terms
Disadvantages
  • WordPress websites only
  • Lacks goal setting and monitoring and other advanced features

Third-party Analytics Tools

CMS-specific analytics tools tend to be a bit more limited. If you’re looking for an analytics tool that is more feature-rich there are many third-party tools you can integrate into your website.

Fathom 

 

Fathom is a well-designed, privacy-respecting analytics tool. It starts at $14/month and is a great tool for people who want something easy to use that also has  some tracking and reporting features beyond the basics.

Advantages
  • Easy-to-use
  • GDPR-compliant
  • 100% data ownership
  • Can set and monitor goals
  • CSV data exports
Disadvantages

Google Analytics 4

 

Google Analytics 4 is a widely-adopted analytics tool backed by the might and power of Google. You can easily find online courses to help you learn it. Many people will be using it, so you will be able to ask questions of and learn from peers and colleagues in the nonprofit tech space. The learning curve, however, is steep.

Advantages
  • Free 
  • Most popular analytics tool
  • Robust analytics tracking and reporting
Disadvantages
  • Not GDPR-compliant
  • Data owned by Google
  • Steep learning curve

Matomo

 

Matomo is an open-source analytics tool. It is free if you install and host the software yourself. You can also pay Matomo to host it for you (starting at $23/month). 

Of the Google Analytics alternatives, it has the most tracking and reporting features available. This also means you should budget for a developer to configure it to your liking, and for some training for your team on using it.

Advantages
  • Free (if self-hosted)
  • GDPR-compliant
  • 100% data ownership
  • Can set and monitor goals
  • Can export reports
  • Other analytics features
Disadvantages
  • Intermediate ease-of-use
  • Requires self-hosting or paying for hosting

Plausible

 

Like Fathom, Plausible is a lightweight and privacy-respecting analytics tool. It starts at $9/month. 

It doesn’t have quite as many features as Fathom, but it’s comparable. It does have a Google Analytics importer, which is great for nonprofits who previously used Google Analytics and want to make the switch while keeping their historical data.

Advantages
  • Easy-to-use
  • GDPR-compliant
  • 100% data ownership
  • Can set and monitor goals
  • Can import your Google Analytics UA data
  • Can export reports
  • Other analytics features
Disadvantages

React Retro Counter

The React Retro Hit Counter by Joshua Comeau.

 

If you yearn for a simpler time you can always go for a retro page counter. This one is free, lightweight and carries the cachet of the early ‘90s revival so many of us are enjoying. It does require a quick installation by a developer.

Advantages
  • Free
  • Easy-to-use
  • GDPR-compliant
  • 100% data ownership
  • Hip retro vibe
Disadvantages
  • Only counts pages

Conclusion

While Google Analytics used to be the gold standard for website analytics, GA 4 is not nearly as user-friendly. And Google’s track record around privacy isn’t great. If GA 4 may be more than you need, this is a great opportunity to consider alternatives. It’s best to first get clear on what data is helpful to track. Then choose the tool that can collect that information and aligns well with your team’s values and skill sets. You might be surprised by the tool that fits best. 

Oct 26 2022
Oct 26

Folks often ask us, “What are the things that can make website redesign and rebuild projects more expensive?”

The quick answer: things that take up a lot of time.

The longer answer: over many years and hundreds of projects, we can tell you exactly what the biggest cost drivers usually are. Here are our top 5 hits:

  1. Design & Development
  2. Stakeholder Wrangling, Internal Capacity, & Timeline
  3. Content Migration
  4. CMS: Drupal vs WordPress
  5. Transactional vs Consultative Partnerships

There are ways to save time and cost in some of these areas; others can’t be cut. Let’s dive in and explore each a bit more.

1. Design & Development

“Website design” encompasses many areas, including information architecture and content modeling. But here, we’re focusing on the aesthetic elements that make a website pretty and usable: fonts, colors, page layouts at different device widths, photos, illustrations, icons, UX (user experience) patterns, animations, interactivity, etc. Design can take up a lot of time! Why? There are a few reasons. 

Creating a visual design for the interactive medium of the web is its own discipline, and requires a special constellation of skills. Designers need time to synthesize user research, get to know an org and its brand, and understand the nature of a site’s content.  

Once a site design begins coming together, it’s usually presented via “comps” (pretty pictures of a web page that aren’t yet built in code). Comps let designers iterate more rapidly and get design approval (which can also add time, see below re: “cat herding”) before development work begins.

When development begins, the amount of time it will take to build the design can be summarized as “more variations, more time.” Some examples: 

  • More page layout variations will take more time to build. If you have six different landing pages, giving each one a bespoke, artisanal, completely unique layout will take more time than consolidating your landing pages to conform to one or two shared layout patterns. 
  • Animations and interactivity often need a lot of thought and troubleshooting to ensure they’re accessible and working on desktop and mobile, and require time for testing on a variety of mobile and touch devices.
  • A design with many custom elements that can be combined in many different ways, like mix-and-match Lego blocks for creating web content, means developers need to test all of the permutations and combinations of those elements at different screen widths. More variations, more problems (and, of course, time).

On the bright side, keeping website designs more consistent can provide a better user experience overall and reinforce an org’s visual brand. A simpler design can be made more complex in the future, and herein lies an opportunity for savings. 

If you’ve got a tighter budget limit than you’d like, can you save cost on design? And if so, how?

Stay Flexible, Consider an MVP

If you want a more complex and/or interactive design than you can afford, the great news is that a well-built, well-designed site is made to be enhanced in the future. Approaching your project in phases is the best way to build a site on a limited initial budget. 

A good project partner will help you define an “MVP”, or “minimum viable product” (which should be called a “minimum lovable product”), to launch. This may mean starting with a smaller number of page layout patterns, and adding more later, or saving complex animations for post-launch enhancements. When we work with clients this way, we recommend trade-offs based on a particular org’s project priorities. We maintain a wish list of enhancements as we build the MVP, and then we can help orgs address their wish list items in the future, as more funds and time become available. 

2. Stakeholder Wrangling, Internal Capacity, & Timeline

Stakeholders: like cats, you gotta love them. Ok, maybe you don’t like cats. But you’ve probably heard that herding cats is extremely difficult, and wrangling stakeholders around website redesign and rebuild decisions is often compared to “herding cats”. 

There are many decision points in a website redesign and rebuild project: content and site structure changes, aesthetics, and functionality. Who in your organization will need to weigh in on these decisions? How will final decisions be made? The process of getting internal consensus and sign-off on decisions can take time. 

When you engage an expert team to help you design and build a site, they need to stay engaged throughout the project to deliver well. A longer timeline means more hours and more cost. 

A web project is also a lot of work for internal org staff. When you’re working with a good project partner, they bring web design and development expertise to the table, but you are the subject matter experts on your content, your work, your mission. You will need to write new content for your site, rewrite existing content, help migrate content, and/or help clean up script-migrated content. If you have events and other mission-critical work in addition to your website project, and your team is low on capacity to meet your project deadlines (i.e. getting sign-off on a decision, entering new content into a new design, etc.), this can also make project timelines longer.

There’s a caveat here: a project can be more expensive because its timeline is too short. There’s definitely a magic spot where your internal capacity to keep things moving along is in alignment with an affordable, steady development pace. A good project partner will work with you to map out that sweet-spot timeline.

If you’ve got a lot of internal stakeholders to wrangle, or limited internal capacity, how can you help a project stay on schedule?

Empower a Client Lead

A great client lead consolidates feedback from the web project team and other stakeholders to deliver back to your project partner. This person should have the power to finalize big decisions, make smaller decisions on their own, and enlist help from other internal staff members as needed. At DevCollab, we’ve found this role to be so important to keeping costs down that we require a client lead on every project.

3. Content Migration

If you’re redesigning and rebuilding a site that currently exists, and you plan to keep any of the content, that content needs to move into its new content management system (CMS) home during the development process. If an older site has a large volume of content, it can be more efficient to do this via computer scripts: developers write little computer robot friends that automatically grab the content from your old site and funnel it into the structures on your new site.

Sounds great, right? But, if your legacy content is complex, you’re changing a lot about it (i.e. its field structure, the way it’s entered into the CMS), or there are thousands of pages that need to be moved, and/or your site is very old, the content migration robot friends we build for you will need to be more complex. This can drive up costs a great deal.

Well, like, what if we need to do other things with our limited budget besides having you craft us expensive content migration robot friends?

Consider Some Manual Migration

Even when content migration is scripted, there’s manual clean-up that a project partner will need you, as the experts in your content, to do. If you’re doing content strategy, writing new content, or rewriting legacy content, a human will need to do that by hand, too. 

There’s almost always some manual content work to be done on any big website project. When scripted content migrations are too costly, and the volume of content isn’t overwhelming (only a few hundred to a few dozen pages), some organizations choose to do some or all of the migration by hand, copying and pasting it into the new site, rather than have developers spend time and budget on scripts (robot friends). 

Entering content into your new site is also a great way to test and learn the new editing interface. If you have staff capacity to manage interns, or a junior staff member will regularly be doing content entry on the site, organizing a copy/paste party can be a way to spare some of your project budget. (Interns often do at least need pizza, though, so keep that in mind.)

4. CMS: Drupal vs WordPress

“WordPress is cheaper” is something we hear all the time. But we can tell you that it’s not always cheaper in the long run.

This is for another day, but, if you need the flexible, robust functionality Drupal offers out of the box, recreating it in WordPress may save you money during the initial build. But building too much Drupal-like functionality in WordPress can lead to the codebase being more brittle, and therefore more costly to enhance and maintain over the long term. 

On the other hand, if you only have a small handful of content types, and are fine with building content relationships only via categories (taxonomy), maybe you don’t need Drupal at all. In that case, WordPress may be a more cost-effective option for you. 

So wait, WordPress is cheaper than Drupal, right?

Let an Expert Help With CMS Selection

If you’re unsure which of the two best open source CMS platforms is best for you, an excellent, collaborative project partner can help you figure out what the most cost-effective choice may be. 

This brings me to our final, most important cost driver.

5. Transactional vs Consultative Partnerships

Some web development partners have a more transactional approach to projects. They listen to what you need and want, square that with your budget, and then go away for a while and make your website. Then they’ll present it to you, get feedback, and go away again to fix or add the things you’ve asked for until everyone feels it’s ready to launch. 

There’s nothing wrong with this transactional type of relationship, but we’ve found that it tends to produce sites that “scratch the itches” your team presented to developers initially, but isn’t built with the bigger picture in mind. 

How do I find a partner who’s looking out for my long-term bottom line?

Partner with a Nonprofit Web Expert, Don’t Cut Corners Here

The best sites we work with are the ones that were produced via collaborative partnerships between the development teams and the orgs. Whether we originally built them or not, these sites are easy for us to build upon. This is why working with a partner that specializes in nonprofit sites can be extremely helpful, as they have a deep understanding of funding cycles, capacity issues, sustainability concerns, and other kinds of business challenges specific to nonprofits.

A good consultative partner will advise you on building a site that will last as long as you need it, and will plan for your long-term goals, as well as scratching those immediate itches. They will push you to prioritize users over internal org politics, and defend accessibility throughout the project. 

More collaboration means more discussion, communication, and sometimes developers saying no to requests that make a site less sustainable for your org, or less accessible or usable for your audiences. This style of working together takes more time than “throwing things back and forth over a wall” in a more transactional way. 

Taking time to plan your site in a holistic, strategic way will be time well-spent when the outcome is a flexible site that can be built upon for years to come. This is far better than ending up with a bespoke, overly complex site that is costly to maintain and may need to be scrapped and rebuilt prematurely. That’s why this is not the place to cut corners.

And yes, you guessed it, DevCollab is a consultative project partner. And that means we’re not necessarily the cheapest and fastest web development team out there. That’s by design. It also means we sometimes have limited space to take on projects. But we’ve got many business-friends out there who are consultative in their approach to web projects, too, and we’re happy to make referrals if we’re not a good fit for your particular needs or timeline. Just reach out and drop us a line.

Back to top

Aug 23 2021
Aug 23

We want our websites to be able to reach as many people as possible. Luckily, Drupal has many baked-in features that ensure its sites are accessible on a variety of browsers, operating systems, and assistive devices.

If done right, your site’s visual design and theme will ensure that color contrasts work for the vast majority of people, that screen reader users and keyboard navigators can use your menus, and that other accessibility benchmarks are met.

So, when all is said and done, remaining accessibility issues usually come down to the content that editors add to a site.

This is where accessibility checkers prove useful. An accessibility checker scans a web page and informs the author of any accessibility issues that need to be fixed.

People are also working on incorporating an accessibility checker into Drupal Core. Until then,  there are three accessibility checker contributed modules to choose from:

I tested all three, and the clear winner is Editoria11y.

How I Tested the Accessibility Checkers

To determine the winner of the Great Accessibility Checker Competition, I put together a sample page riddled with the most common accessibility mistakes.

Workflow note: The two CKEditor-based modules check for issues while editing the page. Editoria11y detects the issues when viewing the page. This means that Editoria11y also checks accessibility issues outside of the page’s content area, though it can be set up to ignore specific elements if you so choose.

Common Content Entry Accessibility Issues

  • Using headings decoratively instead of to make meaningful, outline-like, ordered structure  
    • Using an H4 element, followed by a H2 element
    • Making an entire paragraph a heading because it looks nice to the author
  • Creating lists using dashes, asterisks, or manually-typed numbers, instead of using the semantic HTML for an ordered or unordered list
  • Missing alternative (“alt”) text on images
  • Overly verbose alt text on images
  • Using ambiguous link text like “click here”

Drupal requires alt text for images, so that helps tremendously with preventing people from forgetting to add alt text. Of course, these accessibility checkers aren’t smart enough to know if the alt text written is helpful or not. That requires editorial review by a real human. (Though Editoria11y in particular is the only checker I tested that does provide some feedback as to the quality of the alt text, more on that in a minute.)

So without further delay,  here are my results!

CKEditor Accessibility Auditor

Test Results

Caught

  • Out-of-order headings
  • Lists without semantic meaning

Not Caught

  • Overly-verbose alt text
  • Ambiguous link text
  • Entire paragraph as a heading

Pros

 Cons

  • Report has many false positives
  • There is no visual marker on the page to show where  the error occurs

Conclusion

While the set up and interface works well, the report itself is cluttered with false positives, while also missing some of the most common accessibility issues. To the module maintainer’s credit, they give a shout-out to the Editoria11y module on this project’s page.

CKEditor Accessibility Checker

Test Results

Caught

  • Lists without semantic meaning
  • Overly-verbose alt text

Not Caught

  • Out-of-order headings
  • Entire paragraph as a heading
  • Ambiguous link text

Pros

  • There is a visual marker on the page, inline with the content, to show  exactly where the error is
  • Easy to install and configure
  • Has a “Quick Fix” option
  • Actively maintained
  • Widely-used

Cons

  • Missed some accessibility issues
  • The Drupal 9 version does not have a stable release
  • No documentation (but the README file is easy to follow)
  • Lacks composer support for the third-party libraries on which it relies (ie: a developer needs to handle the third-party libraries manually)

Conclusion

This module is maintained in part by my dear friend and former co-worker Mauricio, a.k.a. dinarcon, over at Agaric Tech Cooperative. The Agaric folks rule and this module overall is solid. There’s a reason it is the most downloaded of the three accessibility checkers.

It comes in at a respectable second place because it shows the errors inline and is well maintained. It did still miss some of the accessibility errors, however. It would also be nice for it to have a stable release and be covered by the Drupal security team.

Editoria11y

Test Results

Caught

  • Everything!

Not Caught

 Pros

  • Caught all of my intentional errors
  • Shows exactly where each error is with a visual marker, inline with the content
  • Easy to install and configure
  • Several configuration options
  • Shows errors automatically, so authors don’t need to manually run an accessibility check
  • Well-documented
  • Stable and supported release
  • Very well maintained (there are no bugs at the time of writing)

 Cons

  • Lacks the “Quick Fix” feature of CKEditor Accessibility Checker

Conclusion

I am blown away by this module. It caught every accessibility error. I also love that it runs automatically, rather than relying on an author to manually check the accessibility of a page. The only drawback to that approach is the author needs to go back to the edit form to make the changes, rather than as they edit. If the CKEditor Accessibility Checker caught errors as well as Editoria11y I would recommend people choose whichever workflow they prefer. Because Editoria11y is so much better at finding accessibility errors, however, this is, by far, the superior module.

Conclusion - Editoria11y is the Best Accessibility Checker

I have deep gratitude for the maintainers of all three accessibility checkers. All three are easy to install and use. All three are well-maintained and Drupal-9 compatible. They all do a decent job of finding accessibility errors, but Editoria11y is significantly better at detecting issues, and presents  them to authors in a more helpful way .
Thank you Editoria11y, itmaybejj, Sa11y (which Editoria11y forked) and Adam Chaboryk for helping us write accessible content for our readers.

Jul 22 2021
Jul 22

I recently went through the process of setting up an RSS Feed for our blog here at DevCollaborative so that our articles can be syndicated to Planet Drupal. It had a surprising amount of gotchas and the documentation was dated and sparse. So I thought I’d help remedy that by sharing what I learned.

I’ve created a video that walks you through the steps of using Views to set up an RSS feed on your Drupal site, below. I’ve also written out the steps below. 

RSS Isn’t Dead, Dangit

For those who might not be familiar with RSS feeds, RSS (Really Simple Syndication) is an open web standard that lets websites generate a syndicated content feed to which people can subscribe. In recent years, corporate social media platforms have worked to overshadow RSS by pushing their own content feeds, but it is still a widely-used and helpful way to get content to audiences. Adding an RSS feed to your site is a great way to participate directly in preserving and defending the open web.

If you’re still not convinced it’s worthwhile, I suggest you read the thought-provoking blog post, Why I Still Use RSS, and how it helped the author to improve their focus and wellbeing during the pandemic. If you are a marketer, I recommend Is RSS Dead? 23 Million Sites Still Find It Useful. So What’s Going On?. If you yourself are not yet using an RSS Reader (or need to get back on the bandwagon), then check out How to Read RSS in 2020.

Surprise! You Already Have an RSS Feed

Drupal actually comes with two RSS feeds out of the box, and you probably have at least one of them running on your site. Congratulations on already having an RSS feed. :) That’s the good news. The bad news is that these default RSS feeds are a little messy. To get a clean output that ensures your content displays nicely in RSS Readers, I recommend following the steps below in Create a Views RSS Feed Display. 

Frontpage Feed

The first RSS feed Drupal gives us is the Frontpage feed. RSS feeds are powered by the Views module.

Check to see if you are using the Frontpage View by visiting the Views admin page at /admin/structure/views.

If you see it in the list of enabled Views then you’ve got yourself a Frontpage Feed at your-site-url.com/rss.xml.

The Frontpage Feed view configuration page is at /admin/structure/views/view/frontpage/edit/feed_1.

Drupal comes with two RSS feeds out of the box. This is the configuration page for the Frontpage RSS Feed Views display.

The Frontpage feed is configured to show all posts that have been marked Promote to your front page.

Taxonomy Term Feed

The other feed Drupal provides is one for each taxonomy term on your site. That means that depending on your site, you may have dozens or more feeds to which your audience can subscribe. If you have a taxonomy term for Baby Elephants, then you have an RSS feed for all those people eager to see the next cute baby elephant photo you publish to your site.

Drupal provides, by default, an RSS feed for each taxonomy term on the website.

You can then decide whether to customize these existing feeds, disable them for now, or delete the Feed display altogether. If you want to keep any of them, do read on because there are some important adjustments you will need to  make. 

Create a Views RSS Feed Display

More often than not, your feed will be associated with an existing page. For example, you may have a News page showing published articles and want a corresponding feed. In that case, navigate to the Views overview page Structure > Views (admin/structure/views) and edit the View that is powering that page.

Note: If you would like to cut right to the chase, import this News Article configuration file and News View configuration file to see the final work of art.

Add a Feed Display

Once you are editing the correct View, click Add > Feed.


Define the Channel Information

Let’s start by defining the general information about the feed, also known as the channel.


Set the Title of the View to whatever you want the RSS Feed title to be. Remember, if this is your single feed of all relevant content on your site, it should be the website’s name.

Next, define the channel description in Format: Settings.


Define the Feed Link

The link to your feed is defined by the Path under Feed Settings. The default link for the Frontpage feed is /rss.xml. That works, but know that you don’t need the path to end in .xml. You can set this to whatever you want. For example, it could be /feed.

If you plan on having multiple feeds, then I recommend you set up a Feeds webpage that then lists out each feed link, similar to what A List Apart does with their RSS page

If you would like to display an RSS icon that links to this feed on a corresponding page, then set the Attach to option to that display.

Configure Fields to Display

By default, the Format on the Frontpage Feed is set to show Content of RSS

This means that we are showing fields from the RSS view mode. If you click into that select list you see a list of other available view modes, several of which are non-existent.

Unfortunately, this default setting is very broken. 


Speaking of broken features, there is also an RSS Publishing configuration page (/admin/config/services/rss-publishing). This too is very broken and should be ignored entirely. 


There is progress being made for both of these issues, which you can follow along at: 

This is fine. Everything is fine. We didn’t want that RSS Publishing configuration page anyways. We want fine-grained control over our feed. We want a View that shows fields.

Go ahead and change Show: Content to Show: Fields 

When you do this, you won’t be able to click the Apply button, because we do not have any fields to associate with the required RSS Feed properties. This is fine. Everything is fine. Click the upper right X to close the form.


Now we need to add fields for the following RSS settings:

  • Title
  • Link
  • Description
  • Creator
  • Publication date
  • GUID field (unique content ID)

Notice the setting is not for Author, but rather for Creator. This is because the Author requires an email address. That is an open invitation for spam and trolling. Instead, Drupal uses the Dublin Core extension of the RSS specification, which defines instead a Creator setting that asks instead for a name.

Here are the most common values from Drupal to use for these RSS settings: 

  • Title - Title
  • Link - Link to content (enable the “Output the URL” as text option)
  • Description - Body (set to “Summary or Trimmed”)
  • Creator - Authored by
  • Publication date - Authored on
  • GUID field - UUID (disable the “GUID is permalink” setting)


Create an RSS Friendly Date Format

The Publication date should use the following date format: Mon, 15 Oct 2007 14:10:00 GMT.

Create this date format at Configuration > Regional and Language > Date and Time Formats.

This uses standard PHP Date formatting. Here is the PHP string to use: 

D, d M Y h:i:s T


Once your date format is created, update your Authored on field to use this new format.


Configure the Author to Display a Person’s Name

If you are using the Authored on field to display the author, this will output the username. If you would like to display someone’s actual name instead, be sure you have a name field added to the User account. Then, add a Relationship in the View to the Content author.

Once you create and save that relationship in the View, you will be able to add the Name field from the User account.


Ensure All Other Views Settings Are Relevant

Since we inherited Views settings from another View display, there are probably other settings that aren’t relevant. For example, we want to show all items, not a pager.

Now save your View and you are all set!

Validate Your RSS Feed

To make sure your RSS feed conforms to the best practices defined by the W3C overlords, visit your feed page, save the XML file and paste its contents into W3C RSS Feed Validation Service.

If all goes well, you will get this friendly confirmation message, Congratulations! This is a valid RSS feed.


Conclusion

Despite some wonky default settings, Drupal makes it quite easy to set up RSS feeds to meet your exact needs. Your website now offers your audience a free, open, ad-free way to subscribe to and read your content in whatever RSS reader they wish. Plus, that little orange icon is a small symbol in defiance of corporate walled gardens and proprietary algorithms.

Jun 25 2020
Jun 25

On June 7,2023 Drupal 7 End of LIfe was extended a to January 5, 2025. The same advice in this article holds true though.

The pandemic has radically altered everything about our lives, including our work in nonprofits and open source software communities. These changes raise some questions about planning website projects. We’ll attempt to tackle some of those questions here.

This past Wednesday, the Drupal Security Team announced

Previously, Drupal 7’s end-of-life was scheduled for November 2021. Given the impact of COVID-19 on budgets and businesses, we will be extending the end of life until November 28, 2022. The Drupal Security Team will continue to follow the Security Team processes for Drupal 7 core and contributed projects.

We’re on Drupal 7, but we’re not ready for a rebuild. So what does this mean? 

This is good news for nonprofit organizations on Drupal 7 who don’t have funds, capacity, and/or time for a rebuild right now. It means that the Drupal Security Team will keep watch on the Drupal 7 codebase for an additional year, into November 2022, and release security updates as needed. Whoever keeps your Drupal codebase happy and healthy now can continue to safely do so for an extra year beyond the original planned November 2021 “end of life” for Drupal 7. 

Security updates are great because they help keep your site secure and stable, but be aware that this does not change the fact that Drupal 7 is no longer being actively developed in terms of new features. Right now, creative energy and focus in the Drupal development community is on Drupal 8-9, and beyond. 

So, should our organization hold off on a rebuild?

There’s no need to hold off on rebuilding your site if you’re ready to rebuild. Whether you’re rethinking your content, your visual design, your site’s core functionality, or any of the above, if you have funds and capacity to rebuild right now, our advice hasn’t changed: go for it. 

If you’re thinking of moving off Drupal, but still want to use content management system (CMS) software, we advise most nonprofits to stick to heavily-used open source software. For many organizations, if Drupal is not a good fit, WordPress may be a good option, especially if your site content is fairly simple. Another open source CMS to consider is Backdrop, which is an open source “fork” (i.e. spin-off) of Drupal that resembles a modernized version of Drupal 7. 

If you’re not sure which one is the best fit for your organization, feel free to get in touch with us to chat about options.

We want to rebuild on Drupal, but now that Drupal 7 has a longer life than Drupal 8, we’re confused. Should we rebuild on Drupal 9?

Drupal is still the most powerful open source CMS option that we recommend, because it’s heavily and widely used on a global scale. So it’s still a great choice. 

In short, Drupal 7 is an old, different product. Drupal 8, and the recently-released Drupal 9, are the future, and will provide your website with a stable foundation for many years to come.

You can absolutely rebuild on Drupal 8 right now. If your Drupal 8 site is built with care and attention to choosing modules that are “Drupal 9 ready”, it will seamlessly port to version 9 when the time is right to upgrade. 

The whole re-engineering of Drupal under the hood, between versions 7 and 8, was done with the intention of making major Drupal upgrades more uniform and less onerous into the future. Once you’re on Drupal 8, you should not need to rebuild to get to the next Drupal version, unless you feel like it. 

We covered this before, in our earlier post, Drupal 7 & 8 Support Ends Nov. 2021. What’s a Nonprofit to Do?

Sep 13 2018
Sep 13

June 07, 2023: Drupal 7 end of life was extended to January 5, 2025. For more details on this, please see our updates in our post, Extending Drupal 7’s End of Life: What’s a nonprofit to do now? An Update.

This week, Dries announced at DrupalEurope, and on his blog, that November 2021 will be the End of Life date for both Drupal 7 and Drupal 8. “End of Life” (EOL) means that a version is no longer supported by core maintainers with fixes, security releases, or enhancements. 

Drupal 9 is now scheduled to be released in 2020, giving people a year to upgrade from version 8 to version 9, before Drupal 8’s EOL.

Why is Being on a Supported Version Important?

Being on a version of Drupal that’s “no longer supported” means that it will not be updated when new security vulnerabilities are discovered. Your site’s data and infrastructure would be at a much higher risk of hacking than usual.

How Does this Affect Resource-constrained Nonprofits Using Drupal?

At first glance, this seems pretty concerning. At the moment, 4 out of 5 Drupal sites are still on Drupal 7, and about 20% are on Drupal 8. If your org is still on Drupal 7, then why should you bother upgrading to 8? Should you wait for 9? OMG?!

Don’t Panic! There’s a Reasonable Plan

This is a new release model, and it’s really different.

  • The D8-D9 upgrade is planned to be much less dramatic than any major version upgrade in the past, because the code between the versions will be very similar.

  • Major contributed modules will be usable in both Drupal 8 and 9, simultaneously. This is really different from how it’s ever worked, and underscores how similar the two versions are intended to be.

Here’s Our Recommendation in the Meantime (which hasn’t really changed)

  • Get onto Drupal 8 when you can;
  • Keep it up to date! Because up-to-date sites are more secure, and will be the most seamless to upgrade to D9.
  • and stay on the Drupal superhighway. By this, we mean that when you choose contributed modules to extend Drupal’s core functionality, choose well-vetted, heavily-used, “best practices” modules as much as you can.

Why is this Even Happening?

This is all about dependencies. Drupal 8’s API is built on top of several other codebases. If Drupal is a LEGO set, its bricks include PHP, Symfony, Twig, and a few other frameworks. It’s extremely important to the Drupal community that Drupal core remains secure. That means that when these building blocks get deprecated, and are no longer supported by their communities with security releases, changes, and enhancements, then those bricks need to be upgraded in Drupal core so that Drupal core stays secure and functional. 

Over the next year, Drupal Core maintainers will be going through the codebase to see what parts of Drupal’s API depend on bits of PHP, Symfony, Twig, etc. that will be changed or retired in the next releases of those systems. Just like we don’t want to have Drupal sites that the Drupal community no longer supports, Drupal doesn’t want to depend on a building block that is no longer being fixed and maintained.

When Drupal 9 is released, it will be the same as the latest Drupal 8 release, but it will no longer include any of those deprecated building blocks. Ostensibly, this means that if you’ve got a healthy, up-to-date Drupal 8 site, an upgrade to Drupal 9 will be fairly minor. It will be nothing like the radical changes that happened under the hood between Drupal 7 and 8.

For more in-depth information on all of this, please see this overview of the Drupal 7 and 8 EOL announcement, by the always-helpful Damien McKenna of Mediacurrent.

Is any of this set in stone? As Damien said in his disclaimer on that call, some of it is, but a lot of it is still in flux. That’s how web technology rolls. We can plan as best we can with the information we have, but we also have to do some waiting-and-seeing. But for the moment, there’s a lot of hope that this new release model will be manageable.

Once More, with Feeling

Is a Drupal site right for you, but your org is not swimming in gold bullion web development dollars? On Drupal 7 still? Continue working toward moving to D8, as soon as you can. When you choose contributed modules, stick to the Drupal Superhighway as much as you can. Once you’re on D8, keep your site up-to-date! As always, we promise to keep watching this space, and to share back what we learn. Stay tuned to nonprofit Drupal channels for news.

Thanks to Damien McKenna, Paige Eaton, Erin Fogel, and Jess Snyder. 

June 29, 2020: Drupal 7 end of life has been extended to January 2025. For more details on this, please see our updates in our post, Extending Drupal 7’s End of Life: What’s a nonprofit to do now? An Update.

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