Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Feb 11 2021
Feb 11

Last week one of our clients was asking me about how they should think about the myriad of options for website hosting, and it inspired me to share a few thoughts. 

The different kinds of hosting

I think about hosting for WordPress and Drupal websites as falling into one of three groups. We’re going to compare the options using an example of a fairly common size of website — one with traffic (as reported by Google Analytics) in the range of 50,000–100,000 visitors per month. Adjust accordingly for your situation. 

  • “Low cost/low frills” hosting — Inexpensive website hosting would cost in the range of $50–$1,000/yr for a site with our example amount of traffic. Examples of lower cost hosts include GoDaddy, Bluehost, etc.  Though inexpensive, these kinds of hosts have none of the infrastructure that’s needed to do ongoing web development in a safe/controlled way such as the ability to spin up a copy of the website at the click of a button, make a change, get approval from stakeholders, then deploy to the live site. Also, if you get a traffic spike, you will likely see much slower page loads. 
  • “Unmanaged”, “Bare metal”, or “DIY” hosting — Our example website will likely cost in the range of $500–$2,500/yr. Examples of this type of hosting include: AWS, Rackspace, etc. or just a computer in your closet. Here you get a server, but that’s it. You have to set up all the software, put security measures in place, and set up the workflow so that you can get stuff done. Then it’s your responsibility to keep that all maintained year over year, perhaps even to install and maintain firewalls for security purposes. 
  • “Serverless” hosting¹ It’s not that there aren’t servers, they’re just transparent to you. Our example website would likely cost in the range of $2500–5000/yr. Examples of this kind of hosting: Pantheon, WP Engine, Acquia, Platform.sh. These hosts are very specialized for WordPress and/or Drupal websites. You just plug in your code and database, and you’re off. Because they’re highly specialized, they have all the security/performance/workflow/operations in place that 90% of Drupal/WordPress websites need.

How to decide?

I recommend two guiding principles when it comes to these kinds of decisions:

  1. The cost of services (like hosting) are much cheaper than the cost of people. Whether that’s the time that your staff is spending maintaining a server, or if you’re working with an agency like Advomatic, then your monthly subscription with us. Maybe even 10x.  So saving $1,000/yr on hosting is only worth it if it costs less than a handful of hours per year of someone’s time. 
  2. Prioritize putting as much of your budget towards advancing your organization’s mission as possible. If two options have a similar cost, we should go with the option that will burn fewer brain cells doing “maintenance” and other manual tasks, and instead choose the option where we can spend more of our time thinking strategically and advancing the mission.

This means that you should probably disregard the “unmanaged/bare/DIY” group. Whoever manages the site will spend too much time running security updates, and doing other maintenance and monitoring tasks. 

We also encourage you to disregard the “low cost” group. Your team will waste too much time tripping over the limitations, and cleaning up mistakes that could be prevented on a more robust platform.

So that leaves the “serverless” group. With these, you’ll get the tools that will help streamline every change made to your website. Many of the rote tasks are also taken care of as part of the package. 

Doing vs. Thinking

It’s easy to get caught up in doing stuff. And it’s easy to make little decisions over time that mean you spend all your days just trying to keep up with the doing. The decision that you make about hosting is one way that you can get things back on track to be more focused on the strategy of how to make your website better. 

¹ The more technical members of the audience will know that “serverless” is technically a bit different.  You’d instead call this “platform-as-a-service” or “infrastructure-as-a-service”. But we said we’d avoid buzzwords.

Jan 11 2021
Jan 11

Whether you are running your business into B2B space or B2C space, the need for agility and speed in workflow management is indispensable. Because eventually, clients also expect faster delivery of the project/application to catch up with their customers’ requirements.

However, if developers do not use any standard tools, it can add unnecessary overhead and eat away their development time. Also, given that they are coming from different backgrounds and skillsets, it would become difficult for stakeholders to set up projects, onboard developers, troubleshooting, and even train them as large-scale projects come with complex requirements.

That is why it’s critical to have a standardized development environment across the teams. This blog guides you on using Lando software (an open-source tool that provides a single local development environment for all the developers’ projects) with Drupal 9 composer, PHP & SCSS Linters, and a multisite architecture scenario.

How Lando Provides a Standard Development Environment?

Setting up the project from ground level to managing configurations and distributing it to each developer, including frontend & backend,  becomes tedious due to various aspects, including different machines, a different configuration of the machine, and different OS.

And that’s where Lando software comes into the picture.

What is Lando Software?

It is an open-source, cross-platform, local development environment, and DevOps tool built on Docker container technology. Its flexibility to work with most of the major languages, frameworks, and services helps developers of all skill sets and levels to specify simple or complex requirements for their projects and then quickly get to work on them.

Some of the benefits of Lando include-

  1. Maintaining standardization across project/application.
  2. Offering speedy development(prebuilt configuration of the composer, drush).
  3. Add tooling to extend it from services. 
  4. Recommends out-of-the-box settings that are customizable.
  5. Automates the complex steps involved in unit testing, linting, compiling, or other recurring workflows.

How to Use Lando With Drupal 9’s Composer.json for Faster Development?

Consider a scenario when a developer has been replaced in the team with the new developer for the existing Drupal project. The new developer might not be familiar with the OS that others are using. Here, it would become difficult for him/her to install the composer quickly. And hence, this would delay his/her onboarding process.

However, if the team is already using Lando for development, it would take care of the operating system’s bottleneck itself. In fact, the composer is already built in the recipe (Recipes in Lando are the highest level abstraction and contain common combinations of routing, services, and tooling) of Drupal 9 and is also compatible with different OS. The only thing is developers should know how to use it.

code written in maroon background

Steps to Use Lando with Drupal 9’s composer.json

The prerequisite for this setup is that your local development machine should be compatible with Docker and Lando and installed successfully without any glitches. Make sure when you are running docker setup, other ports are not conflicting with Lando setup.

Here are the steps to be followed-

  1. You need to clone this  Drupal 9 open source git repository.(Ex:

    git clone  [email protected]:AbhayPai/drupal9.git)

  2. Change the directory to the cloned repository. (Ex: cd drupal9)

  3. Start your app using the lando start command. Before you begin, you can change some parameters in .lando.yml as per the need of your application.

This repository would give you some common tools that include linting of PHP, linting of SCSS, linting of js files, and compiling of SCSS files and services like node.js and npm to directly connect with the Lando app. You do not need to go inside any container after starting your application. By default, this repository is only able to lint custom themes and is flexible enough to extend it to custom modules and profiles.

How to Use PHP Linters With Drupal in Lando

As Drupal is one of the largest open-source communities, millions of developers contribute and offer coding solutions in different ways. To standardize the coding practices and make the modules easy-to-maintain and readable, varying from indentation, whitespaces to operators, casting, line length, and many more, Drupal has a core package that takes care of these standard practices automatically when configured in the project. In general, these are called PHP Linters.

Following are the steps to configure the PHP linter in the project-

  1. Download dependencies package of Drupal coder using `lando composer requires drupal/coder`.
  2. Define a file for linter standard or copy file from Drupal core in your project folder where all standards are predefined in the XML file. It resides in core/phpcs.xml.dist.
  3. Configure a tool of `lint:PHP` within the .lando.yml file like the below example-

code written in black background

4.  Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling. code written in white background

5.  Use this newly configured tool in your project using ‘lando ’. In this case, it is ‘lando lint:php:themes’

code written in maroon background

This automating tool which is configured with Lando software will help developers save time for finding and fixing these issues and will also ensure best practices are followed in the project repository.

How to Use SCSS Linters With Drupal in Lando

SCSS is a preprocessor used for writing CSS or CSS3 in any modern-day project. This SCSS is used because it helps developers to write less code and remove redundancy in the repetition of classname and other properties which are frequently used in the project.

The purpose of using SCSS linter in the project is to ensure that the quality of the code is high and easily maintainable for future enhancement. Further, it would save time in development and faster delivery of the projects.

Following are the steps that need to be followed for configuring the SCSS linter in our project-

  1. Configure node service and install gulp inside that service within .lando.yml file.
    code written in black background
  2. Configure tool for using npm with Lando within .lando.yml file.
    code written in black background
  3. Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling.
    code written in white background
  4. Create a package JSON file and install and configure the stylinter package in the project.
  5. Create a new script in the package.json file for triggering stylinter.
    code written in black background
  6. Configure the tool to trigger this using lando.
    code written in black background
  7. Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling.
    code written in white background
  8. Run this tooling command and Lando will lint it automatically.
    code written in maroon bavkground

This automation tool integrated with Lando for SCSS linter will ensure that best practices and code hygiene is followed in the project repository.


How Can Lando Help in Reducing Developers’ Efforts While Building Drupal Multisite Architecture?

Let’s take a scenario where your project ( client’s website) is live now and running smoothly. Now the client wants to create multiple new sites in alignment with the existing site. For instance, the new sites should have custom modules, themes, profiles, etc. to ensure brand consistency. 

Here, Drupal would come in handy as it would simplify the multisite architecture and speed up the local development setup with Lando through some minor tweaks in configuration files.

For setting up multisite architecture in an existing project, you need to follow below steps- 

  1. Configure .lando.yml file to setup app server URL for the new website
    code written in black background
  2. Configure database server for setting up this site with the new website
    code written in black background
  3. Configure drupal settings like sites,php, and folder structure for site2; to leverage this Lando configuration
    code written in black background
    code written in black background
  4. Rebuild configuration for setting up this new website.
    code written in maroon background

The minor tweaks in the existing project would help you extend existing Lando projects/websites to build multi-site architecture via local development and accelerate the delivery process for the client.

Conclusion

If you have come this far, Dhanyavaad (thank you). I hope that this article would help you in speeding up the development process & hence, faster project delivery, knowledge transferring of your application/project with Drupal, and leveraging Lando at its best by using inbuilt composer for automation in local development environments.

Now that you are armed with the knowledge and Lando’s benefits, what are you waiting for? Get started now!

Dec 15 2020
Dec 15

Every aesthetically pleasing website has a common ground - a good theme. An attractive theme can bring the website’s visuals to life and facilitate you to create a powerful brand identity. But that’s just one part of the story!

The website theme, beyond being beautiful, should cater to great user experiences also. 

And that’s how you prepare a robust yet enticing website - maintaining design & the best usability practices hand-in-hand are the key to increase conversion rates.

The launch of Drupal 9 in June encouraged the community to make it high up on their agenda to revamp its user experience and ensure friendliness for every stakeholder - designers, editors, marketers, and developers, of course. 

With an emphasis on Olivero, a modern front-end theme designed to exhibit the CMS in its best light; front-end developers can expect plenty of benefits from it. 

It will empower them to bring that magical touch to the websites by utilizing their creativity along with modern tools and frameworks to define layout, styles, typography, buttons, color schemes, and many more, to drive the visuals and engagements of the website/ application.

This blog walks you through Drupal's soon-to-be default theme - Olivero and how front-end developers can leverage it for designing a great website.

Olivero and It’s Benefits

Olivero is going to be a new default front-end theme that is expected to be rolled out in Drupal 9.2. It is designed to give Drupal a flamboyant look and feel. Olivero is also going to be compatible with the Drupal 8 website as a contributed theme.

Currently, Bartik, a ten-year-old theme, initially created for D7, is being used. It is certainly mobile-responsive and had some outstanding features to meet D8’s mobile-first requirements. However, the development has outdated the design. 

Thus, the need for a new front-end theme emerged to showcase Drupal’s strength appropriately.

Drupal Trivia

Olivero is named after a female programmer, Rachel Olivero, an outstanding supporter/ programmer of website accessibility. Sadly, she passed away in 2019. To honor her, the Drupal community kept her name alive with this beautiful theme. The idea is to showcase patience, generosity, and inclusiveness - the qualities of Rachel that the theme should also epitomize.

Benefits of Olivero Theme in Drupal 9

The Olivero theme is intended to give Drupal websites an eye-pleasing view apart from ensuring,

  • Simplicity- declutters by eliminating the colors, effects, and visual elements that make the theme look and feel too heavy.
  • Professional look - encompass all the design elements, for instance, negative space and high contrast, to grab users’ attention.
  • Accessibility- designed with WCAG AA conformity in mind, from functionality to layout, to colors, all components will be accessible for everyone. 

Drupal Trivia

The blind federation conducted an accessibility test to evaluate the Olivero theme for visually impaired users. They were happy and satisfied with its design and high responsiveness.

  • Flexibility- facilitates Drupal front-end developers with multiple options to choose from - be it button styles, headers, or logo styles to text titles, and many more.
  • Compatibility - supports modern browsers’ features & various engagement modes. The creators have ensured that the theme supports recent Drupal updates and features for websites such as Layout builder, media embeds, second-level navigation, and many more.

Get the Hang Of Olivero’s Exciting Features

Here are the features of Olivero that you can leverage for designing your next Drupal website-

A. Bright color palette

Websites leveraging Olivero’s color scheme will look beautiful with a base color of bright blue. Besides being attractive, it would boost Drupal’s brand recognition. Several permutations and combinations of darker and lighter colors and shades would provide website improved accessibility.

Screen Shot 2020-12-15 at 11.23.46 AM

A bright color palette in Olivero theme

Source- Drupal.org

B. Simple and elegant forms & buttons

The forms and buttons added in the new theme are user-friendly, distinguishable, and accessible. Forms comprise a left color bar, and their labels are placed above the fields to abide by the website accessibility requirements and guidelines. 

The buttons inform users about clickable action. The theme also has a filled primary button style and a secondary button style which is an outlined version of the button.

The buttons’ different modes are present default in Olivero, unlike other themes where you need to define these modes. 

The four modes are- Default, Hover, Focus, and Active

8 rectangles in white background

                                                                 

                                                                 Button modes in new theme                                                                                                                                         
                                                                   Source- Drupal.org

C. Typography

Typography provides scale to maintain uniform sizing, line height, and spacing throughout the design. The base font used for body copy is 18px. The size can be tweaked for smaller screen sizes.

Consistency, throughout line-height and spacing, has been a key objective when setting the scale for typography.

D. Flexible header and navigation options

Navigation options can cater to any website’s needs. The header can fold into a hamburger button menu when scrolling, allowing the user to access the menu easily on long pages. 

The secondary dropdown menus are also supported by Olivero, thus saving coding efforts of developers unlike Bartik where they need to reinvent the wheel time & again.


E. Vertical Rhythm

Vertical rhythm ensures the correct spacing arrangement of the text. It calculates line-height, font size, and margin or padding to maintain equal space throughout the website. 

F. UI Patterns

The header is designed flexibly so that it can accommodate the text titles and or logos of varied width and height. 

On scroll down, the header will fall into a hamburger-button menu, to let the user access the menu or longer pages.

G. Site branding variations

You can tweak the theme settings to change the background color and width of the site-branding to incorporate different types of logos and long text.

white background with text and boxes

Flexible site-branding options in Olivero

Source- Drupal.org

H. Forms

These simple yet modern forms consist of elements that enhance the design, while still being recognizable, usable, and accessible. 

The left color bar highlights the form element and labels are added above the form field to avoid confusion. Form fields have a consistent look to indicate to users that they are a form element. States such as focus, disabled, and errors have also been accounted for.

3 field boxes

Highlighting error state in the form

Source- Drupal.org

I. Tables

Table divider lines are designed such that it improves readability. Olivero's theme will also support the responsive table features of Drupal. 

J. Sidebar

Only one sidebar is implemented to stop competition for space on the screen. It improves readability and allows content to look more rich and prominent on the screen. Editors can showcase related posts and other types of utility blocks too. 

The sidebar also offers good support and space.

Text written in white background

One sidebar aimed at improving readability

Source- Drupal.org

K. RTL Support

Olivero theme supports right-to-left languages as required by Drupal core. It also supports better display and multilingual functionality. For example, Arabic, Hebrew, Persian, and Urdu support RTL writing and so does Drupal.

text written from right to left in white background

RTL support in Olivero

Source- Drupal.org

L. Messages

Messages intent to inform users for they need to consume important information or provide feedback on an action already taken. 

Messages are visible as they are designed with bright colors to highlight the message and yet don’t mess up with the readability of the message itself. 

Text written in white background

Displaying messages per their type (error, alert, and success message)

Source- Drupal.org

M. Breadcrumbs

Breadcrumbs in Olivero are placed near the top of the page above the page title to help users keep track of documents or websites. 

A visual cue informs users about more breadcrumbs which they can access later by swiping left to right or right to left. This feature is not part of MVP. 

Text written in white background

Breadcrumbs to keep track of pages

Source- Drupal.org

N. Color module

This feature is not part of the initial release. However, this or similar functionality might be included later. 

Challenges That Olivero is Going To solve for front-end developers

Olivero is a modern theme with a magnificent look and feel. It can help front-end developers in simplifying their work. See how-

1. Lighter theme with up-to-date design elements

Unlike Bartik which used outdated graphical elements such as drop shadow and gradient, it uses a layout builder, grid system, hamburger menu, to name a few, to ensure that the site remains lightweight and responsive.

2. Low code

There is little or no coding required in CSS to determine the presentation of a web document and for adding content blocks anywhere. 

There are few other scenarios that simplifies the work of front-end developers -

  • Bartik doesn’t offer a secondary menu while Olivero does. This saves the coding efforts of front-end developers 
  • If any other theme is used, the hamburger menu is not available. Olivero theme is mobile-friendly. It encapsulates the menu automatically via the hamburger menu feature. No coding is required for it.

3. Scalability

Even on enlarging page size, it won’t break. Instead, it would give you a clear view as always. This makes Olivero more responsive.

4. Compatibility with other browsers

Bartik is not compatible with other browsers like Internet Explorer 11 while Olivero is. Front-end developers need not write code separately to ensure the support to all the functionality and features of the browsers. 

5. Code compilation/ testing

Olivero has CSS Grid Layout that can handle both columns and rows. It is a powerful layout system that helps developers write code hassle-free. They can write code in a nested structure to make it compact, easy to understand and increase readability. 

6. Extensibility with PostCSS Standalone technology

PostCSS is an accessible tool that empowers front-end developers to easily contribute to in the form of custom plugins. 

It simplifies the writing of CSS stylesheets by keeping code simple and facilitating understanding of dependent selectors and media queries within the stylesheet. 

During the development of the Olivero theme, there were several PostCSS plugins that were leveraged to make the CSS more readable and reduce the probability of breaking the page.

Conclusion

Olivero is a modern theme that is going to be the new default theme for Drupal from version 9.2. Front-end developers can use this flexible and scalable framework to improve work efficiency and create exquisite websites. 

Figure out how your enterprise can leverage Olivero’s constructive features to empower your front-end developers. Meanwhile, let’s wait for this beautiful theme!

Nov 09 2020
Nov 09

[embedded content]

Sarah Durham (00:02):

Hey everybody. Welcome to today’s webinar. I am Sarah Durham, and I am going to briefly introduce my colleagues. They will talk a little bit more in a minute and also we’d love you to introduce yourself as people start to arrive. If you are comfortable doing so, you’ll see a chat panel. And if you could chat in to us your name, the name of your organization, your pronouns, and where you are, where you are geographically, so who you are and where you are, would be great. Theresa, you want to say hi. 

Theresa Gutierrez Jacobs (00:50):

Hi, I’m Theresa Gutierrez Jacobs. I am a project manager at Advomatic. And for today, I’m going to just quickly chat my email. If you have any, I don’t know, tech issues or questions or anything like that, that is more tech related to this webinar. Feel free to reach out to me via my email. Otherwise, you can always chat or ask questions, particularly for this webinar here. And Dave, you want to say a quick hi, before we get rolling.

Dave Hansen-Lange (01:18):

Hello. I’m Dave Hansen-Lange and where I am, I’m about an hour from Toronto. I’m the director of technical strategy at Advomatic. I’ve been with Advomatic for about 13 years. And I’ve been doing work with nonprofits in the web for maybe about 15 or 17 years.

Sarah Durham (01:42):

Okay. So we’ve got a bunch of people who are already with us, a few more people who might join us in the next couple of minutes, but just to keep the ball rolling and use your time thoughtfully, we’re going to dig into our content for today. And as I said a little bit earlier, I will reintroduce myself. I’m Sarah Durham, I’m the CEO of Advomatic and also Advomatic sister agency, Big Duck. Some of you may have noticed that the Zoom we’re using today is a Big Duck/Advomatic shared Zoom. So if you’re wondering what the connection is, there’s some common leadership across both companies. For those of you who might know Big Duck, but don’t know Advomatic, Advomatic builds sturdy sites that support change. We build, and we support websites in Drupal and in WordPress. And Advomatic has been around now for, I think almost 15 years, although it’s partnership and collaboration with Big Duck and my coming into the company is relatively new.

Sarah Durham (02:43):

It’s about, I’ve been in it about two years. And so Dave is going to really take us through our topic today. And Dave, you could advance to your next slide, if you would like, which is this, what should you do with your Drupal 7 website? So Dave’s gonna talk us through why this is an issue and a few other things in a minute. What I am going to do throughout this conversation is I am going to be monitoring both the chat that you can see in the bottom of your screen, a little button that says chat. And if you click on that, you have the ability to either chat privately to the panelists. So if you want to ask a question confidentially, or you don’t want everybody who’s here to see it, just chat to the panelists and only Dave and Theresa and I will see it.

Sarah Durham (03:26):

If you want to chat to everybody and share who you are, like shout out to Rick, who’s already done that. He’s from the National Council of Nonprofits and he’s in the DC area. If you want to share your information with the panelists or to everybody, you can chat to all attendees. Also, you have the ability to specifically ask questions. There’s a Q&A feature in Zoom Webinar. And that will give me the ability to keep an eye on your questions. And some of them I can type back to you and others will be addressed verbally. So throughout the presentation, I’ll be monitoring all of that and we will address your questions perhaps as we go on, certainly at the end if it doesn’t make sense to do so in the webinar. So don’t hesitate to chat, don’t hesitate to ask questions. We are recording today’s session and Theresa will be sending out an email with a link to that recording and the transcript and the resources we’re mentioning later this week or early next week. So you will have all of this and you can share it with any colleagues if that is useful. So with that, we are going to get rolling over to you, Dave, and thanks, Theresa.

Dave Hansen-Lange (04:44):

Okay. Thank you, Sarah. All right. So to kick things off before we get into the details of all the different things that you can do with your website and what might be best for you I thought we should start with some backstory about like, why we’re at this spot and like, what does end of life even mean? Like, it’s software, how can software… and it really all comes down to security. And just to explain a little bit about how security in Drupal works, there is the Drupal security team, and that’s a team of about a dozen people all across the world. And then there’s a group of people even wider than that who contribute things to the team and say, Oh, this could be a problem. We should look into this. And people on the security team, you know, a lot of their time is paid for by their employers or their clients, but a lot of their time they’re just volunteering for free.

Dave Hansen-Lange (05:50):

And you know, there’s a lot of commitment there. Like, they have weeks on call and stuff like that, because security is very important to the Drupal community. And so we don’t want to have those people working forever for free. So the Drupal community at large has decided, okay, thank you for your time of service, people on the Drupal security team, we will let you go after this date. Some of those people work on AAA too. But people are generally committed for like Drupal 7. And so the original date for the end of Drupal 7 was going to be November, 2021. But then COVID happened and the Drupal community decided, okay, there’s this extenuating circumstance. We’ll give everybody one more year to figure out what they’re going to do. So now that the end of life date for Drupal 7 is November 2022, two years from now. 

Dave Hansen-Lange (06:56):

Drupal 8, just as an aside, it’s not really what we’re talking about today. Drupal 8, the end of life is November 2021, a year from now. That’s not what we’re talking about today. And thankfully, if you do have any AAA sites, the situation is a lot simpler. And if you want to get into that a little bit more possibly we could at the end of the presentation. Okay. So today we are going to first cover: these are the options that you have in dealing with your Drupal 7 websites. Then we’re going to look at some example scenarios. And by that, I mean like, okay, here’s an organization, they have a website like this, and because of that, they might consider scenario x. And then I’m going to pass things over to Sarah. And Sarah is going to dive into more of the organizational things, like, how do you plan for this and how do you work with this within your organization? All right. 

Sarah Durham (08:15):

Hang on one second, Dave, before we dig into this, I also just want to remind everybody feel free to chat in questions and comments as you go, and we’re going to take pauses in between each of these sections. So if you have, as Dave goes through the options, if you have a specific question about one of the options, and it seems like it’s universal to some of the other people who are participating today, I’ll probably pop in and ask that otherwise we’ll save Q&A for the end. Alright, sorry for the interruption.

Dave Hansen-Lange (08:41):

No, no, all good. I’m also going to be muting every now and then to take a sip of tea. I’ve got a sore throat. It’s not, COVID, it’s just a cold. And yeah, so I’ll be pausing too, as I go. Okay. So what are your options? So I’ve grouped these into four main options, and these are listed in terms of most expensive, to least expensive, most expensive option being start from scratch and build a new website for most people with a Drupal 7 website your main options are move to Drupal 9 or create something in WordPress. There’s some other options that you might consider, but those are the two that are applicable to most people. Option B is upgrade to Drupal 9 and immediately you’re probably thinking what is upgrading to Drupal 9? How is that different from building a website and Drupal 8? And I’ll explain that when we get there, another option is to switch to something called Backdrop. Many of you have probably never heard of Backdrop. And so I’ll start us out by what exactly that means. Or you could just stay on Drupal 7. And even though it has end of life, that there still are ways to keep going on, on your Drupal 7 website.

Dave Hansen-Lange (10:15):

So moving to a new website like I mentioned the main options for most people are Drupal 9 or WordPress. And so just by saying those two names in the same sentence, we immediately get into the topic of like what’s better Drupal or WordPress and what is right for me? I will touch on this a little bit now, and sort of back up a little bit and say that for starters, it’s really hard to make an unbiased and fair assessment of the two. But in a general sense, Drupal 9 is really great for people that, or on websites and organizations that want to do something a little bit more complicated, a little bit more ambitious, a little bit more technological, with more moving parts. And WordPress is generally more applicable to the organizations whose website, in many ways might be similar to other websites. And yeah, that is a little bit vague. I don’t want to dive too deeply into this topic right now. 

Dave Hansen-Lange (11:54):

If you want, we can come back to this in the Q&A at the end. And we also have another webinar that we did a couple months ago on this topic more generally. And if you’re just, if you can, we can send along a link to that as well. One last thing on this, though, I will say that when most people compare Drupal and WordPress, they’re not really comparing Drupal and WordPress, they’re comparing the website that someone built for them in Drupal or the website that someone built for them in WordPress. And because of that, they’re often comparing the skills of those people who built the website and not necessarily the underlying technology. And that’s part of the reason why this is such a sticky, thorny issue with a lot of people being on one side or the other there about moving to a new website. You don’t have to do the whole entire thing. You can find ways to do this in bits and pieces. I’ll show some examples of that later, but we’re at this point of rethinking what should we generally do with our Drupal website. It’s a great time to think, okay, this section, do we need it anymore? Should it be here? Is there a better way to do this then when we created this website however many years ago?

Dave Hansen-Lange (13:30):

Since many of you may not have seen modern Drupal I’m going to show you, or we’re pressed, I’m going to show you some slides here. So on the left, what we see is I am editing a page on a website and I want to add a new component which is a common term that we use these days, a new component to the page. I can browse through this library of available components and then add one.

Dave Hansen-Lange (14:00):

Or how it’s going to appear on the page. There’s many ways to do this in Drupal. Drupal is kind of known for having many ways to solve a problem. What we see in this screenshot is a tool called paragraphs. That’s a tool that we’ve been using for this problem pretty successfully on several websites. There’s other tools within Drupal 9. You may have heard the term layout builder and there was a couple of smaller ones as well on the right side. We see the administrative listing of all the content on your website for each site, it’s going to be a little bit different, what you decide to list here. But this is just one example of how it looks and comparing this to WordPress on the left. This is also how WordPress looks when you want to add a new component to the page. And so the right column there, we see, the available components that you have, again, on the right, a screenshot that’s WordPress of a list of all the content on the website.

Dave Hansen-Lange (15:20):

Looking at these two sets of screenshots, there’s a couple things that might sort of immediately come to mind. WordPress, the administrative interface generally looks a little bit more polished.

Dave Hansen-Lange (15:39):

In some ways WordPress can be a little bit all over the place in that each plugin or each new thing that you add to your website tends to design things its own way and do its thing its own way and it’s WordPress. Compared to Drupal, each new thing works in a very consistent manner. So it’s easy to move around from section to section on the website. All that to say is really either is probably a big step forward from where you are with your Drupal 7 website.

Dave Hansen-Lange (16:18):

All right, so which Drupal 7 website is this going to be most applicable to, or maybe you shouldn’t at all consider this option? If you are really frustrated with any part of your website, be that like how the content of this is organized, or just the general backend experience the design of the website, if there’s anything about it that you’d just want to just toss and start again fresh, this is a good option to consider. But like I mentioned, when I listed these four main options, creating a new website is going to be the most expensive of the options. And in the age of COVID, many of you are probably dealing with some tight budgets. So one of the other options may be the better choice. Also, this might not be a good choice for you if your existing site is very complex. And one way to think about this is like you built your website so many years ago, let’s say it was five years ago. And you put all this work into doing that initial build, but then over those five years, you’ve also put in some work, to make the website more and more better. And in this new version of the website that you’re gonna create, you want to encompass all of that. 

Dave Hansen-Lange (17:52):

It’s going to be a pretty big project. And so it’s just one way to consider looking at your options.

Okay. Option B, I don’t have a handsome, single flat you can upgrade to Drupal net. So how is this different from just creating a new websiteIn AAA? Drupal 9 has these built-in tools that can take your Drupal 7 website and take all those, all that content, all the content structure all the menus, everything that’s stored in the backend of the website and upgrade it and make it work in a new Drupal 9 website. But what you don’t get is any of the, how that content is presented to visitors, all of that stuff. If you go through this upgrade process, you still need to come up with or you still need to rebuild the way that it’s presented to visitors. Maybe, maybe you’re happy with the design of your Drupal 7 website. And so you can just redo that same design in Drupal 9 or another option since we’re here and we’re creating a new website and Drupal 9, you might want to take advantage of that and do a new design.

Dave Hansen-Lange (19:31):

And so, because of all those things, it’s going to be still a big chunk of work, not as big as just doing a clean slate and starting from scratch. But still a lot of work involved. One thing you do need to look into before you get too far down this road is like, are there any ways in which we solve the problem in Drupal 7, that just there’s no equivalent in Drupal 9. And that has sometimes happened because the Drupal 7 way of solving a problem, one example would be locations. Let’s say you got a content type in Drupal 7 called offices of your organization and they’re storing their address and location. That’s almost certainly done in a very different way in Drupal 9. And there isn’t a way to directly go from one to the other, at least not directly in the same sense of this upgrade process that I talked about before. There may be these situations like that, and you’ll have to do something custom or something else. That’s a little bit more complicated. It’s just important that, you know, these things happen upfront before you get into moving down this road.

Dave Hansen-Lange (21:00):

So who is this good for? I mentioned, you’re going to get the same stuff in the backend as you have now. So it’s, if you’re happy with that, great, consider this option. I mentioned that the visual presentation, you’ve got to redo that. So if you want a fresh design, this might be an option for you. Again, avoid if budget is tight, like I mentioned, it’s still a fairly complicated procedure. All right. A third option is to switch to Backdrop.

Dave Hansen-Lange (21:39):

So Backdrop, I said earlier that your main options are WordPress or Drupal. What’s this, what’s this new Backdrop thing? Backdrop is kind of like a different flavor of Drupal. And in the technical parlance, Backdrop is a fork of Drupal 7. And what does cutlery have to do with software? Absolutely nothing. So by fork, we mean fork in the road. You may know that Drupal and WordPress are open-source software. And that means that anybody, anybody really who has the time available to do it, can jump into the project. You got a problem with the way something works, you want to make it better, you can just do that and you can contribute something and get it rolled into the software. But what that also means is that if you don’t like how something works, you can just take it, copy it, and roll with it.

Dave Hansen-Lange (22:42):

And that’s what’s happened with, with Backdrop so well. Drupal 8 was being developed. There were many people in the community who thought, “Oh, no, like Drupal 8 is looking great and all, but it’s going to be really hard for websites that are on Drupal 7 to get to Drupal 8 and whatever it comes in the future. And they were right. That’s, that’s why we’re here. That’s why we’re having this webinar. And so what they did was they took Drupal 7, copied it, called it Backdrop and started to evolve it and evolve it in some of the same ways that AAA has evolved only keeping with the Drupal 7 way of doing things and the Drupal 7 styles. And so you have an option to take your website and sort of just take that fork in the road and start moving down the Backdrop trail.

Dave Hansen-Lange (23:42):

What this is going to look like for your website is that you’re still gonna have the existing content structure things in the backend of the website, just like that, upgrading to Drupal 9 option. It’s all going to look very similar, if not identical, but different from that upgrade to Drupal 9 option. You can still keep the visitor-facing portion of the website. If it’s going to need a little bit of tweaking to get onto that Backdrop fork in the road. But that is going to be relatively much smaller, a much lighter lift. Not to say that you must keep your existing design, you can make some changes and revisions. You might even consider doing a full redesign. But yeah, you don’t have to, as you’ve heard me describe this, you may be thinking fundamentally that the steps involved, it’s pretty similar to the upgrade to Drupal 9.

Dave Hansen-Lange (25:00):

It is, but still, it is almost certainly cheaper than upgrading to Drupal 9. And mainly the reason is because like I mentioned, it is just Drupal 7 evolved. So the changes that you have to make to your existing website are just immensely smaller, some increased risk. So what I mean by this well, like anybody who works with websites for a nonprofit is probably going to know WordPress, and probably getting to know the word Drupal, probably not going to know the word Backdrop, because it is such a much smaller community. Where there might be that there’s about half a million Drupal websites out there. There may be like a few thousand Backdrop websites out there. And because of that, there’s enough momentum in the community that we know that Backdrop will be here for two years, maybe four years, but it’s harder to sort of see deeper into the future. Whereas Drupal, you know, half a million websites. We know it’s, there’s a lot of people working on this, a lot of organizations, big and small, it’s going to be here for probably at least another 10 years, if not longer. Backdrop, much smaller community. There’s just not as much certainty about the future. 

Dave Hansen-Lange (26:44):

But with that said, Backdrop has committed to like the same sort of upgrade structure that Drupal 8 and Drupal 9 have committed to being. We’re not going to do a huge change again in the future. We’re going to make all these incremental changes that will make it much easier for you to stay up to date and evolve your website over time.

Dave Hansen-Lange (27:12):

Great. I thought it important to show some visuals about what Backdrop looks like and looking at these, you might be thinking, “Oh, this looks pretty similar to my Drupal 7 website, but the colors and fonts are more contemporary”. And you are a hundred percent correct in thinking that like I mentioned, it really is Drupal 7 evolved. But there is more to it. There are some easier things on the technical side of how to work with Backdrop compared to Drupal 7. There’s some different ways of managing page layouts. There’s other new features in Backdrop that Drupal 7 doesn’t have. But the thing is, if you take this sort of upgrade from Drupal 7 to backdrop trajectory, you’re not going to get those things all of a sudden. If you want to take advantage of Backdrop’s fancier ways of laying out content on a page then you’re going to have to have a small project to enable that feature. At first, you’re still going to be working in the same paradigms as you are with Drupal 7. So who is Backdrop great for? Anyone who has a lot of custom code. I was talking earlier about like, why you might want to avoid building a new website and Drupal 9 is if you’ve got a lot of custom stuff. Here in this option, and this would be a good option for you because all that custom stuff probably doesn’t need to change very much, probably needs to change a little. But if it’s not going to be all that significant, this is a good option for you.

Dave Hansen-Lange (29:16):

If you are happy with your existing design that’s going to need a little bit of touch-ups to move to Backdrop. I was trying to be consistent here and come up with a reason why you should avoid Backdrop. I couldn’t really come up with one. I think everyone should at least consider this option. It’s kind of like the middle of the road option. You might not choose this option if you’re wanting to do a full redesign, but if all the rest of the things line up for you, then you could do a full redesign in Backdrop. It would be fine. I guess the only reason that I can think of now is that if you are super concerned about keeping the website that you have the same fundamentally as it is now, four, five years into the future, 7 years into the future—because the future is a little less defined for Backdrop—you may want to avoid it in that case.

Dave Hansen-Lange (30:35):

All right. And the last option stay on Drupal 7. I mentioned even though Drupal 7 has reached end of life, there are ways to continue on with it. If you had any websites that were on Drupal 6 and you were in this sort of situation for Drupal 6’s website, when it reached its end of life, there was a program started called the extended support for Drupal 6. This Drupal 7 version of that program is fundamentally identical. And what this is is that I mentioned that many of the security team are volunteering their time. And so this program gets around by trying to force people to volunteer their time by saying it’s a paid program. The Drupal community has vetted several Drupal agencies to offer this extended support service. And what that means is that as security issues come up, maybe there’s a security issue that comes up in Drupal 8 that might also apply to Drupal 7 this, this team of extended support people work on fixing that problem in Drupal 7.

Dave Hansen-Lange (32:11):

And so there’s kind of two ways to take advantage of this: Number one, you sign up with one of the extended support vendors. You’ll be able to find that list through some links that we’re going to send at the end. One of the mandates of this is that they release all of their fixes publicly. It’s happened for Drupal 6 as well. And so if you are technically savvy or you’ve got someone at your disposal who’s technically savvy and can sort out the details and apply these fixes as they come up, this could be a good option for you, too.

Dave Hansen-Lange (33:08):

I think it’s important though, to like, take a step back at this point and talk about why you might think about security in different ways. And one way to think about security is kind of like two groups of websites on the internet—those who security is really important for, for whatever reason. Maybe they’re doing something that some people find controversial and they have people who are trying to hack into their website. Maybe you are processing credit cards on your website and you, you know, someone might want to try and break in and steal those credit cards. Maybe you are a news outlet and you get hundreds or hundreds of thousands of people viewing your content every day. And if someone could break in and get some sort of message out to those people, that might be an incentive as well. So that’s like one group of websites, people who have some sort of special security concern. And then there’s kind of everybody else—everybody who knows that security is fundamentally important, but it’s not more important than it is for everyone else in this group.

Dave Hansen-Lange (34:33):

It’s just the nature of how I described that most organizations are going to be in this group where security is important, but not more important than anyone else. Some are going to be in this heightened group of security. And for those people, they need to think about things more than just like, am I getting the bare necessity basics? Or am I really doing all that I’m responsible for ensuring the security is as good as it can be. And for those people, this may not be the best option in that you’re not on the most recent and currently secure thing you were on, this thing that’s on extended support. And whether that rationale is purely technical, or if it’s purely optics in that if something were to ever happen to your website and it was discovered, “Oh, they’re running this version of Drupal that was created 10 years ago”. 

Dave Hansen-Lange (35:38):

How can that be responsible? And then there’s all sorts of politics involved. I mean, it’s a situation you want to completely avoid, but for those of us who are in the group of security as important, but not more important than anyone else, this can be a very reasonable option to consider. So stay on Drupal 7, if you have a really tight budget. And I admit that budget is in the eye of the beholder. For some of you a roomy budget would be a tight budget and vice versa. Like I was talking about, if you don’t have any special security requirements avoid, if your site needs a facelift or if you’re frustrated with the backend. So like I mentioned, this is keeping the same website and keeping it the same. And so if you want to rip something out and try again, this is probably not the option for you.

Sarah Durham (36:56):

Okay. So, Dave, I’m just going to jump in here for a second before we continue with your sample scenarios. We’ve got about 20 minutes left in our time together, so we’re going to need to move pretty quickly through our sample scenarios and through the make a plan section. But we did get a really good question that I’d love you to try to answer for us before we continue on. It’s from our friend, Rita, and Rita asks, if you choose to migrate or upgrade to Backdrop, what would that mean for your future options to upgrade to Drupal 9?

Dave Hansen-Lange (37:29):

I don’t think it really changes the landscape for that at all. Whether you’re upgrading from Drupal 7 or from Backdrop, it’s fundamentally the same thing. It is technically almost identical and that’s because well, Backdrop has gone on this new trail at a foundational level. The way the content is stored, it’s fundamentally the same. And so if you want to pull that content out of either version of those websites into a new Drupal 9 website, it’s going to be the same process. That could change though, as it’s a fork in the road. So Backdrop could go further one way, while well, Drupal 7 is not moving anywhere at this point, but it could continue to move on in a way that’s more different from Drupal 7. But in my opinion, it’s unlikely to change all that much for the foreseeable year or two.

Sarah Durham (38:37):

Okay, great. So, so back over to you.

Dave Hansen-Lange (38:40):

Okay. So like I mentioned, those options, they were great in theory, but now let’s try and put some of this to practice. I’m going to show, I think, four, maybe five example websites and what is unique or different about those websites and why they might choose one option over the other. As you’re looking through this, you might think, “Oh, that’s nothing like my website”. But I’m going to try and pull some things out here that hopefully are going to apply or at least show some things that you should consider. And you also might recognize some of these websites. Don’t focus on that. We’re going to focus on what is it about these websites? I’m also not going to tell you anything about these websites that isn’t something… Sorry, everything that I’m going to tell you about these websites is something that you could just go to the website, look at and figure out for yourself.

Dave Hansen-Lange (39:45):

So there’s not going to be any sort of like private information here that I’m gonna show either. So in this first example, we’re going to look at the ACLU. On the left here, we see what their website homepage used to look like. On the right side, we’re going to see what the homepage looks like now. And the prior version of the website, that was Drupal 7. The homepage, and I say that specifically, the homepage, is now WordPress. You may remember back when I talked about the option of creating a new website that you don’t have to do the whole thing. Here’s just the homepage. And they’ve actually done the same thing with the blog section. It used to be Drupal on the left. Now it’s WordPress on the right. You don’t have to do with everything.

Dave Hansen-Lange (40:44):

So this is an example of a case on the ACLU website. And like, this is just one really long page here that is cut up into three pieces. See at the top, this is all just fairly straightforward content. But then in this section, things start to get more complicated. Like there’s all these other bits of content elsewhere on the website that are related to this case. That’s something that you can do in WordPress, but the more complicated those relationships get, the more awkward it gets to do in WordPress. Then down here at the bottom of the page, things get super complicated. Visually it doesn’t look too bad, but that’s because I think the design was done well. There’s hundreds of legal documents that relate to this case, all in these groupings and hierarchy and get super complicated. WordPress is not the best tool for this kind of job. And so this part of the website is still on Drupal. It’s still going to be on Drupal for now. It might evolve in the future, but that’s where it is for now.

Dave Hansen-Lange (42:03):

Another section of the website, there is this sort of intermediary thing where you could show an action within like an article or a blog post or something to say, “Okay, come take this action”. And during the redesign or in moving bits to WordPress, you know, if you’ve stepped back and thought, is this useful? Is this complicated? Is there a way to do this simpler? And this sort of intermediary thing was just checked and now there’s just links to actions and there’s other ways to show actions without this complicated section of the website. Please consider for your website: What should I get rid of? There’s almost always something. 

Dave Hansen-Lange (43:11):

Looking at a different organization, here is one that’s a Drupal 7 website. But you might be thinking, “Oh, this design, it looks fairly current”. And you’d be correct because this organization went through a redesign, I want to say, like, two years ago. And so because of that, looking at those four main options, they can probably throw the create-a-new-website option out because the design still looks great. As long as they’re happy with how the content works on the backend, they could really choose any of the other three options. And, yeah, so consider that.

Dave Hansen-Lange (43:47):

Next, we have a municipality. When I was talking about the option of staying on Drupal 7, that’s maybe not the best option for a municipality in the news all the time. We hear stories of like such-and-such municipality, their website has been hacked, or their computer systems have been taken over by ransomware. And so just the optics of staying on Drupal 7 might not be the best choice for them. The design looks, doesn’t look as fresh as those first two options that we showed. But let me guess a municipality kind of has different requirements in that the number one goal is not a flashy design, it’s getting information out to its residents.

Dave Hansen-Lange (44:32):

And so there may be a way for them to choose one of the non-design related options. And at the same time, maybe consider how it can do any sort of restructuring to better present the information that people need to find. Here’s another organization. In looking at the screenshot, you might be thinking the same things that this organization thinks about this website and that the design is very text-heavy, and it is not quite as engaging as they would really like it to be. And so for this organization, one of the first two options is probably the best choice: creating a new website completely or upgrading this to Drupal 9 with a new design.

Dave Hansen-Lange (45:43):

Lastly, we’re going to look here at, this is not so much a website, but a web platform. AFT has 1,300 websites on this one platform for States and Locals within a state. And the center one up top here, this is for a campaign website. And this is an example of a few things: One, it’s not their primary website, it’s not aft.org. And so if you’ve got more than one website, you don’t have to choose the same option for all of them. You can choose different options. Number two, there’s a lot of custom stuff involved here, as you might imagine. Some stuff around creating a new website, around connecting the information altogether. So because of that, you might lean more to one of the options that works better for custom stuff and doesn’t require recreating all of their custom stuff in a brand new website.

Sarah Durham (47:07):

Thank you, Dave. So a quick question, before we talk about where you go from here. Just want to confirm the ACLU, the sections of the ACLU site that are still in Drupal, or are those WordPress? 

Dave Hansen-Lange (47:22):

That is in Drupal. Yes. 

Sarah Durham (47:26):

Okay, so Dave is going to be advancing some slides for me. So I will ask you, Dave, to go onto the next slide. And basically, before we flip over to your questions and discussion, and in the remaining time we have together, what I want to get you thinking about is how to make a plan. And it’s interesting we’re doing this today because actually I had a call with somebody at a higher ed institution this morning, who’s got an old site and they are debating what their options are. They were describing a lot of feelings of being overwhelmed. I think that, you know, these days with the reality of what’s going on in the world with COVID, with elections, all that kind of stuff, tackling these kinds of big projects is feeling pretty daunting. So I wrote an article about planning and we’ll share links to that article and a bunch of other things.

Sarah Durham (48:20):

Dave has also written a really helpful post about Drupal 7’s end-of-life. At the end of this webinar and also in the follow-up email, we’ll send you one of the things I wrote. The first step is to make a plan and you don’t have to have all the answers. You’ve just got to begin by getting your team on the same page about the implications. I think that’s one of the big barriers that a lot of people are facing is that they’ve got these Drupal sites and there is a real challenge coming up, a real cliff coming up for many of you that you’ve got to begin to get your team aligned around so that you can budget and plan appropriately. Next slide please, Dave. So I recommend that you come up with a plan, which you could do in five slides or in two pages.

Sarah Durham (49:05):

And the intention of this plan is actually to give you an internal document you can use to get your team on the same page and build some buy-in. So you can see first you’d start by outlining the situation. I think we’ve given you some of the ammunition for that conversation and in today’s session or in the articles we’ll share with you, and what the risk is to your organization. You might want to outline some options if it’s clear to you and the people on your team where you should go from Drupal 7. You might go forward with outlining some options or making a recommendation, but honestly, if you’re not sure which way to go, a good partner should help you get there, too. So if you don’t have the answers already in mind, if it’s not clear to you which way to go, it might be that you map out a few options.

Sarah Durham (49:52):

But your recommendation might be more to find a partner to help you navigate that. Of course Advomatic can do that. We would love to help you make a decision about this, and we do regularly do that as part of our work. There are many people you could work with who could do that. I think one of the things that’s also really important in your plan is mapping out a timeline, not so much for the build or the upgrade that you might do, but all the things leading up to it. If you are looking ahead and thinking what you really need to do is rebuild your website or do a significant upgrade, that’s going to take time and a lot of work, and you’re going to want to get your team on the same page about when the budget needs to be approved, and when you’re going to get rolling so that you’re doing it hopefully well in advance of some of the deadlines that are going to be important within your organization and within the Drupal 7 end-of-life timeline.

Sarah Durham (50:49):

You know, in the non-profit sector, one of the key pieces that is in my experience kind of do-or-die for many big projects is building buy-in. So with that plan in mind, I would encourage you to have some conversations, share it, get it into the budgeting process and kind of keep it alive because very often you know, you mentioned these things once or twice, but there’s so many things going on that are taking up so much attention and energy for the leaders of organizations today that I think you’re going to have a little bit of work to do to keep it alive, which is the next step. My next slide. Also, keeping it alive is about not just writing this plan and sending it to people, but keep nudging and keep bringing it up. If you know what your milestones are when people are talking about budgets or budgets are getting approved, you know, those are great opportunities to research, collate your plan and go from there.

Sarah Durham (51:47):

Now, many organizations that we work with and talk to are already doing this, and they’re already talking to us and other people about what they’re doing. And a partner can also help you figure out your timeline. So there are a lot of ways to do this. You don’t have to do the heavy lifting on your own. But what you don’t want to do is you don’t want to wait until you’re, you know, a couple of months away from these deadlines if they pose significant risks or implications for your organization. So we have a few minutes left to go before the top of our hour. And I want to hear a little bit from you. So if you’ve got questions or comments, you can either use the Q&A feature, which you will see at the bottom of your screen, or you can chat them in to Dave and I, as we go. And we’re going to stop sharing our screen. Now we’ll take a few questions and while you chat those in, I also want to just remind everybody that we are going to be sending out a follow-up link to the recording here. And Theresa is also going to chat out a couple of the articles we mentioned. Dave has written a really helpful article about D7 end-of-life. He’s also written an article about D8 and there’s an article I’ve written that’s about how you, how you plan for this change. So Theresa will chat those all out.

Sarah Durham (53:17):

Okay, Dave, first question for you. Somebody is chatting in about administrators and they’re thinking, well, actually, this is sort of a double-barreled question. Let’s take it in two parts. First in option A, you talked about building a new site as option A. You specifically talked about WordPress and Drupal. Both of those are open source technologies. Why are you talking just about WordPress and Drupal and not any other systems?

Dave Hansen-Lange (53:46):

One of the things that I also talked about was like, kind of the momentum of these projects, like Drupal is large. WordPress is ginormous. And there’s lots of movement in those projects. There’s lots of momentum as soon as someone has a new idea or a new technology pops up on the internet, like things move quickly. And there’s a way to do it on your website in short order. And I also talked about the security group, that’s not the official title, but like there’s ways like that in which you’re getting the benefits of someone else volunteering their time for your website, which you just don’t get in in some of the other options that you have.

Sarah Durham (54:37):

Okay, thank you. And the second part of this question was about comparing WordPress and Drupal about administrators and the options there. This person is talking about how there’s lots of different people in their organization, who right now have different layers of access in Drupal 7. And they’re wondering if there are any recommendations you have for new platforms based on that kind of complexity.

Dave Hansen-Lange (55:01):

Yeah, so like the area of editorial permissions and controls, like that’s one of the big differentiators between Drupal and WordPress. WordPress has some basic systems around this role can do this, or this role can do that. In Drupal, we can make things a whole lot more complicated, like people who manage this section of the website, they can upload images. Other people can use those images, but only the original group of people can edit them or ways of more complicated things that you can do in Drupal.

Sarah Durham (55:38):

Okay, so there’s a question here about the difference between a Drupal new build and a Drupal upgrade in terms of cost. And actually, would you mind just bringing it up again, cause somebody chatted to me that they arrived a bit late and they didn’t see your slide. I think it’s your slide number six, which outlines all the options. Let’s just quickly go back to that slide for a second and share that. And I think that the question that just got chatted into me relates to this. So on slide six, you mapped out a bunch of different options ranging from building a new site to staying on Drupal 7. And those were ranked, as you talked about them from most expensive to least expensive. So you said building a new site is the most expensive, staying on Drupal 7 is the least expensive, and then the upgrade or the switching to Backdrop were in between. So the question is about the cost differential between building a new site in Drupal 9 and upgrading in Drupal 9. I assume that there are additional costs for design, for UX, things like that, and building a new website, but how significant is that differential? What other variables inform the cost difference there?

Dave Hansen-Lange (57:06):

Yeah, so I talked about sort of in any of these higher options… well, no, let me rephrase that. In the two middle options, you have the option of how much redesign you want to do, of course. And that’s probably the biggest thing that affects how big or small upgrading to Drupal 9, that project is going to be. But let’s say you wanted to redesign and compare upgrading to Drupal 9 versus creating a new website in Drupal 9. It’s difficult to be put on the spot, but I don’t know, 80%, 90% since you’re doing a full redesign. Upgrading to Drupal 9 and moving to a new website, they start to become more similar. The more you’re redesigning, the similar in cost.

Sarah Durham (58:01):

Okay, thank you. That sounds like what we were expecting. So I am just skimming through your questions and it looks like a couple of other questions that we have here are pretty unique to specific organizations, so I’m going to follow up directly with those organizations since we are just about out of time. I want to thank Theresa and Dave for joining us today. Dave, thank you for imparting your wisdom on this topic. And I want to thank everybody who took the time to log in and watch this. I hope this has been helpful for you. If you have specific questions or concerns or things you want to pick our brain about, you can always email us at [email protected] or [email protected]. We’d be happy to get on the phone with you, talk a little bit about your situation if that is of use to you. And again, Theresa will be sending out a link to these articles and the recording to you in just a few days. So thank you, all. And thank you all for the excellent work you do to make the world a better place. Be well, thanks.

Oct 13 2014
Oct 13

A whirlwind tour of dozens of useful contributed modules for building Drupal 7 sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from administration to workflow, from paths to views, and beyond.

One factor to consider when choosing contributed modules is the recommendations of other experienced Drupallers. So in the list below I've noted some Drupal-as-a-Service (DaaS) platforms that have included a module in their service, which is essentially groups of experienced Drupallers indicating they find a module useful (and reliable enough) for a very large number of sites. I've also noted when at least some of a module's features are part of core in Drupal 8, which is an indication that very senior indeed Drupallers consider it useful for most sites.

  • (This functionality is part of core in Drupal 8.) indicates some/all of module's functionality is part of core in Drupal 8.
  • (This module is included in Stanford Sites.) indicates module is included in Stanford Sites.
  • (This module is included in Drupal Gardens.) indicates module was included in the late, lamented Drupal Gardens.

A key principle of module usage is to use as many as you need, but no more. Some of the modules (or their submodules) listed below are really useful when you are building or configuring the site, but don't need to be enabled for just visiting it or editing its content and so should normally be disabled on live/production sites.

  • (This module should only be enabled on live/production site if truly required by content editors.) indicates module should only be enabled on live/production site if truly required by content editors.

Essentials

These are modules that I install on essentially every site I build.

Administration menu (drupal.org/project/admin_menu(This module is included in Stanford Sites.) Provides a dropdown menu to most administrative tasks and other common destinations (to users with the proper permissions). (Don't forget to disable the core Toolbar module when using this.) Administration views (drupal.org/project/admin_views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Requires Views, Views Bulk Operations, Chaos Tool Suite, Entity API.
"Replaces administrative overview/listing pages with actual views for superior usability" —in other words, you can customize them! Advanced help (drupal.org/project/advanced_help(This module is included in Stanford Sites.) Displays advanced help and documentation. Many contributed modules' help and documentation are primarily available through this module. (This module should only be enabled on live/production site if truly required by content editors.) Chaos tool suite (drupal.org/project/ctools) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) A helper module required by Administration views, Views and a number of other modules. Date (drupal.org/project/date) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides "a flexible date/time field type (Date field) and a Date API that other modules can use." Entity API (drupal.org/project/entity(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Required by Administration views and Views bulk operations.
Extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Libraries API (drupal.org/project/libraries(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a common repository for external (non-Drupal) libraries in sites/all/libraries and sites//libraries for use by contributed modules. Module filter (drupal.org/project/module_filter(This module is included in Stanford Sites.) Tames the modules list page, so you can quickly find the module you are looking for without tons of scrolling or having to rely on the browser's search feature. (This module should only be enabled on live/production site if truly required by content editors.) Pathauto (drupal.org/project/pathauto(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Token.
Provides a mechanism for modules to automatically generate URL aliases for the content they manage. Human-friendly URLs (e.g.,"about" rather than "node/72") are important for accessibility, usability, and SEO. Pathologic (drupal.org/project/pathologic(This module is included in Stanford Sites.) A filter that helps avoid broken links and incorrect paths in general text fields (e.g., Body, etc.). These tend to arise when full URLs ("http://sample.edu/about") or relative path URLs ("about") are used in general text fields instead of absolute path URLs ("/about") for internal content. Redirect (drupal.org/project/redirect(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Redirects users from one URL to another. When used with Pathauto, "automatically generates path redirects to ensure that URL alias changes do not break existing links." This is considered the best practice for SEO and usability. Token (drupal.org/project/token(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) The basic token API is now a part of Drupal 7 core, but this module provides a browsable token UI, as well as field & profile tokens that did not make it into core for Drupal 7. Transliteration (drupal.org/project/transliteration(This module is included in Stanford Sites.) Provides a central transliteration service (converting Unicode text to US-ASCII) to other Drupal modules (e.g., Pathauto), and sanitizes file names while uploading. Views (drupal.org/project/views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Chaos tool suite.
Required by Administration views and Views bulk operations.
Creates customized lists and displays from already entered content. Along with fields, this is the heart of adding content once but being free to display it multiple places and multiple ways. (For those familiar with relational databases, fields & Views let you use the power of relational databases to wrangle your content, while still keeping content adding and editing as simple as word processing and online shopping.) Submodules include views_ui (This module should only be enabled on live/production site if truly required by content editors.) Views Bulk Operations (drupal.org/project/views_bulk_operations(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Views and Entity API.
Required by Administration views.
Exposes new Views style 'Bulk Operations' for selecting multiple nodes and performing actions on them all at once. Wysiwyg (drupal.org/project/wysiwyg) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires installation of (non-Drupal) editor libraries.
Allows users to edit contents with rich text editors such as CKeditor (This functionality is part of core in Drupal 8.) and TinyMCE. Permits inclusion of more than one rich text editor in the same site. Wysiwyg filter (drupal.org/project/wysiwyg_filter(This module is included in Stanford Sites.) "Provides an input filter that allows site administrators to configure which HTML elements, attributes and style properties are allowed" (based on whitelists). This lets administrators permit content editors to include images in general text fields without giving them access to Full HTML. (Allowing Full HTML is a security risk and just generally a Bad Idea.)

Frequently used

These are modules I install on many sites, but not all of them need the functionality provided.

Fields

Address Field (drupal.org/project/addressfield)"Defines a new field type to store international postal addresses, implementing a subset of the top-level address elements defined in the xNAL standard"Automatic entity label (drupal.org/project/auto_entitylabel) Allows automatic generation of entity label fields, such as node titles. (Replaces Automatic node titles module.) Email field (drupal.org/project/email) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Provides a field type for email addresses. Entity Reference (drupal.org/project/entityreference) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Entity API and Chaos tool suite.
Provides a field type that can reference arbitrary entities (nodes, etc.). Can display the field either as a link to the entity or as a rendered entity (for example, it can show either a link to a node or the node itself).Field collection (drupal.org/project/field_collection) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Field Group (drupal.org/project/field_group(This module is included in Stanford Sites.) Link (drupal.org/project/link) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a link field type. This allows association of a link title with a link URL, while permitting either to be optional.Smart trim (drupal.org/project/smart_trim(This module is included in Stanford Sites.)

Views

Better exposed filters (drupal.org/project/better_exposed_filters(This module is included in Stanford Sites.) "[R]eplaces the Views' default single- or multi-select boxes with radio buttons or checkboxes, respectively. Description fields and Select All/None links can be added to exposed filters to make for a better user experience." Calendar (drupal.org/project/calendar(This module is included in Stanford Sites.) Enables displaying views containing date fields in calendar formats. Can display information by day, week, month, or year in either pages or blocks. Date iCal (drupal.org/project/date_ical(This module is included in Stanford Sites.)"provides a plugin for Views to enable exporting your site's calendar as an iCal feed, and a plugin for Feeds to enable importing external iCal feeds into your site's calendar."EVA: Entity Views Attachment (drupal.org/project/eva)"Provides a Views display plugin that allows the output of a View to be attached to the content of any Drupal entity", such as a node, user profile, comment, etc.Views data export (drupal.org/project/views_data_export(This module is included in Stanford Sites.) Provides a way to export data from views to CSV, Microsoft XLS, Microsoft DOC, plain TXT, or XML. Views Datasource () (This module is included in Stanford Sites.)Views field view (http://drupal.org/project/views_field_view(This module is included in Stanford Sites.) Allows users to embed a view as a field in a view. A new field handler is made available, so this can also be used in area (header/footer/empty) handlers as well as rows.Views slideshow (http://drupal.org/project/views_slideshow(This module is included in Stanford Sites.)"Views Slideshow can be used to create a slideshow of any content (not just images) that can appear in a View." 

Blocks

Bean (drupal.org/project/bean(This module is included in Stanford Sites.) Allows the definition of block types (like content types, only for blocks instead of nodes). This has various benefits, including making it easy to add distinct fields to blocks, use WYSIWYG editors for block content, and the like. Block class (drupal.org/project/block_class(This module is included in Stanford Sites.) Lets site builders add CSS classes to any block through the block's configuration interface. This lets you really take advantage of the block-centric responsive design of themes like Open Framework and Stanford Framework. Block title link (drupal.org/project/block_titlelink(This module is included in Stanford Sites.) Allows site builders to turn a block's title into a link.Menu block () (This module is included in Stanford Sites.)

Context

Context (drupal.org/project/context(This module is included in Stanford Sites.)Allows site builders more fine-grained control over what is shown, where it is shown, and how it is shown ("reactions") on any given page based on a much wider and more flexible range of criteria/"conditions" than Drupal core. There is a lot of power in this module: with it you can have the same block show up in the header of one page but in the footer of others or have different themes depending on the path and much, much more. Context accordion (drupal.org/project/context_accordion(This module is included in Stanford Sites.) Requires Context
Improves the user interface (UI) of the Context module by adding a nice javascript accordion effect.Context HTTP headers (drupal.org/project/context_http_headers) (This module is included in Stanford Sites.)Requires Context
"Provides a set of Context reactions that allow you to set HTTP Response Headers for each context on your site. It is a generalized framework for response header handling that allows the sending of any arbitrary header value(s)." You can thank Whitehouse.gov for this one! Context list (drupal.org/project/context_list(This module is included in Stanford Sites.)Requires Context
Improves the administration experience of the Context module by providing "a list of contexts, their conditions and reactions in a simple view … The intention of this module is to provide a means of inspecting all contexts in one easy screen." Context list active (drupal.org/project/context_list_active(This module is included in Stanford Sites.)Requires Context
Like the Context list module, but lists the contexts, conditions, and reactions only for the current page. Context respect (drupal.org/project/context_respect(This module is included in Stanford Sites.)Requires Context
"Extends the Context module by making it respect default block settings. This makes it so you can retain your block visibility when assigning them into various Contexts." Context user agent (drupal.org/project/context_useragent(This module is included in Stanford Sites.)Requires Context
"Adds a new condition to the Context module that allows performing regular expression tests on the useragent string ($_SERVER['HTTP_USER_AGENT']). This allows adding different reactions based on the user's browser, operating system, or other needed contexts that may be found in the useragent string."  Delta (drupal.org/project/delta(This module is included in Stanford Sites.) Requires Context
Allows site builders "to make duplicates of your theme settings for any context on your site. This gives you the ability for alternative layouts as a reaction in Context" Contextual Block Class(es) (drupal.org/project/cbc(This module is included in Stanford Sites.)Requires Context
Allows site builders "to contextualize block classes" 

Appearance/Theme

Colorbox (drupal.org/project/colorbox) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)CSS injector (drupal.org/project/css_injector(This module is included in Stanford Sites.)Allows site builders to add new CSS (and override the theme's CSS) without editing (or even access to) the theme's files on the server. Display suite (drupal.org/project/ds(This module is included in Stanford Sites.) "[A]llows you to take full control over how your content is displayed using a drag and drop interface. Arrange your nodes, views, comments, user data etc. the way you want" by defining custom view modes. Site builders can define how one piece of content should be displayed in different places such as teaser lists, search results, the full node, views, etc."JS injector (drupal.org/project/js_injector) (This module is included in Stanford Sites.)Like CSS injector, only for JavaScript (SJ).

Development

Bundle copy (drupal.org/project/bundle_copy(This module is included in Stanford Sites.) Allows administrators to export and import content types and other entity definitions (taxonomy, user, field definitions, field groups). This is great for sharing structures between sites, instead of rebuilding them by hand each time. (Note, it does not import/export the content/data, just the structure/definitions.)Features (drupal.org/project/features) (This module is included in Stanford Sites.)"Enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case."Strongarm () (This module is included in Stanford Sites.)

Data Import

Feeds (drupal.org/project/feeds(This module is included in Stanford Sites.) "Import or aggregate data as nodes, users, taxonomy terms or simple database records." Feeds JSONPath Parser (drupal.org/project/feeds_jsonpath_parser(This module is included in Stanford Sites.)Feeds Tamper (drupal.org/project/feeds_tamper) (This module is included in Stanford Sites.)Feeds XPath Parser (drupal.org/project/feeds_xpathparser) (This module is included in Stanford Sites.)Path redirect import () (This module is included in Stanford Sites.)

Files and Images

File entity (fieldable files) (drupal.org/project/file_entity(This module is included in Stanford Sites.)"File entity provides interfaces for managing files. It also extends the core file entity, allowing files to be fieldable, grouped into types, viewed (using display modes) and formatted using field formatters."File (Field) Paths (drupal.org/project/filefield_paths(This module is included in Stanford Sites.)Requires Token. 
Adds the ability to use node tokens in destination paths and filenames. FileField Sources (drupal.org/project/filefield_sources) Extends file and image fields to allow referencing existing files, remote files, and server files.Insert (drupal.org/project/insert(This module is included in Stanford Sites.)Adds a button to file and image fields so images and links to files may be inserted inline into general text fields (e.g., the Body field).

Other

Backup and migrate ( drupal.org/project/backup_migrate (This module is included in Stanford Sites.) "Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. Backup and Migrate supports gzip, bzip and zip compression as well as automatic scheduled backups." [I use this when I can't use shell scripts in the command line on the server.] Better formats (drupal.org/project/better_formats(This module is included in Stanford Sites.) Adds more flexibility and control to Drupal's core text format system. It allows site builders to: set allowed text formats and/or default order of text formats per field; hide format tips and/or hide more format tips link per role; and hide format selection per role per entity. Bibliography module (drupal.org/project/biblio(This module is included in Stanford Sites.) For managing and displaying lists of scholarly publications, including importing from PubMed, BibTex, RIS, MARC, EndNotee and XML and exporting to BibTex, EndNote, and XML. Output styles include AMA, APA, Chicago, CSE, MLA and others. Content Access (drupal.org/project/content_access(This module is included in Stanford Sites.) Allows granular control of access to content by content types and, optionally, specific nodes by role and author, by specificing independent view, edit and delete permissions. Custom breadcrumbs (drupal.org/project/custom_breadcrumbs(This module is included in Stanford Sites.)"Allows you to create and modify your own breadcrumbs based on node type." (Breadcrumbs are that trail of links indicating the way to your current page, usually displayed just above or below the page title.) Diff (drupal.org/project/diff(This module is included in Stanford Sites.) "[A]llows pretty viewing of all added/changed/deleted words between revisions." Drupal Commerce (drupal.org/project/commerce)Flag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Google analytics (drupal.org/project/google_analytics(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) "Adds the Google Analytics web statistics tracking system to your website."Inline entity form ()"Provides a widget for inline management (creation, modification, removal) of referenced entities. … Existing entities can also be referenced." This solves the chicken or egg problem for referencing content that hasn't been created yet!Job Scheduler (drupal.org/project/job_scheduler) (This module is included in Stanford Sites.)An API (helper module) "for scheduling tasks once at a predetermined time or periodically at a fixed interval."JW Player() (This module is included in Stanford Sites.) Link checker (drupal.org/project/linkchecker) Periodically checks for broken links in node types, blocks and cck fields and reports the results.Menu position () (This module is included in Stanford Sites.)Metatag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Mollom () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Node clone () (This module is included in Stanford Sites.)Node convert (drupal.org/project/node_convert(This module is included in Stanford Sites.) (This module should only be enabled on live/production site if truly required by content editors.)Node form columns () (This module is included in Stanford Sites.)Panels ()Relation () (This module is included in Stanford Sites.) Rules (drupal.org/project/rules) (This module is included in Stanford Sites.) Lets you define conditionally executed actions based on occurring events. In other words, add logic/processing without having to code a custom module. Also required/used by many other modules. Services () (This module is included in Stanford Sites.)Site verification () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Taxonomy manager () (This module is included in Stanford Sites.)Universally Unique IDentifier () (This module is included in Stanford Sites.)Webform () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Workbench (drupal.org/project/workbench) (This module is included in Stanford Sites.) Workbench access (drupal.org/project/workbench_access) (This module is included in Stanford Sites.) Workbench moderation (drupal.org/project/workbench_moderation) (This module is included in Stanford Sites.) XML sitemap (drupal.org/project/xmlsitemap) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)
Apr 21 2014
Apr 21

In this screencast, you will discover how you can use the OSF for Drupal user interface to browse, filter and search for Resource entities that have been indexed in Open Semantic Framework (OSF) datasets. You will see how you can use it to manage what you want to expose on your Drupal portal.

Then you will see how you can create, update, delete and export Resource entities using Drupal.

Finally you will discover the revisioning system, and the revisioning user interface that is available to the Drupal administrators.


tut_9_blog_400
Apr 18 2014
Apr 18

This screencast introduces you to another one of the most important OSF for Drupal connector: the OSF FieldStorage module. What this module does is to create a new FieldStorage type for Drupal7. It enables Drupal7 to save the values of its Content Types fields into another storage system than the default one (i.e MySQL in most of the cases).

Because of the way that the Field system has been designed in Drupal7, it is possible to save the values of different fields that compose the same Content Type bundle into different field storage system. For example, if your Content Type bundle is composed of 10 fields, then 4 of them could be saved into MySQL and 6 of them into OSF.

The main purpose of the OSF FieldStorage module is to be able to save Drupal local Content Type information into OSF. What that means is that all your Drupal7 local content then become accessible, manageable and manipulatable using the 27 Open Semantic Framework (OSF) web services endpoints. Your local Drupal content can then be shared with other Drupal instances that could use OSF for Drupal to connect to that same OSF instance and seamlessly republish/re-purpose that local content from the other Drupal portal.

Here is the documentation of the architecture of this connector module.

This is the power of the OSF FieldStorage connector module. It supports the following Drupal features:

  1. Full FieldStorage API
  2. Entities caching
  3. Revisioning
  4. SearchAPI
  5. 29 field widgets
  6. Export feature in 6 formats

In this screencast, you will be introduced to Drupal7’s Field system. Then you will see how the OSF FieldStorage module creates a new FieldStorage type for Drupal7 and how it can be used. Then you will see how to configure the OSF FieldStorage module: to creating new Content Type fields that uses this osf_fieldstorage type, how to map these fields to RDF, how to use one of the 29 supported field widgets, etc.

Finally, you will see how you can synchronize existing Content Type pages (that was created before OSF for Drupal was installed on your Drupal instance) into a OSF instance.


tut_8_blog_400
Apr 17 2014
Apr 17

This screencast introduces you to one of the most important OSF for Drupal connector: the OSF Entities module. This module creates a new Entity Type called Resource. The description of these entities is managed directly into the Open Semantic Framework (OSF). All the calls to the core entity API function like: entity_load(), entity_save(), entity_create() and entity_delete() are operated with different calls to different OSF web service endpoints.

What this means for a Drupal developer is that they can use Drupal’s Entity API to manage instance records that are hosted remotely in a OSF instance. They don’t have to know how OSF works in order to take advantage of it. They just have to use the API they are used to use. This new Entity Type supports the following Drupal features:

  1. Full Entity API
  2. Entities caching
  3. Revisioning
  4. SearchAPI
  5. Templates selection with inference on their type
  6. 29 field widgets
  7. Export feature in 6 formats

The screencast introduces you to the following aspects of the OSF Entities module:

  1. Introduction to the architecture of the OSF Entities module
  2. Exposing the available entities in OSF into Drupal Bundles and Fields
  3. Browsing and searching for Resource entities
  4. Managing Resource Type bundles
  5. Introduction to the OSF Entity Reference field widget
  6. Creating and updating Resource entities

tut_7_blog_400
Apr 16 2014
Apr 16

In this new screencast, I first introduce the concept of a dataset: what it is, what it is used for and how it works. I will also outline the characteristics of datasets in the Open Semantic Framework (OSF) such as having a set of permissions for group of users, a unique identifier, etc.

Then I explain how datasets are being used by OSF for Drupal, and how they can be managed using a Drupal portal: how to import, create, register, change permissions to datasets. Then I explain how datasets can become searchable using the SearchAPI or be disabled in the web portal.

Finally I cover the OSF Entities administrators search and browse utility which can be used by Drupal administrators to browse and search for all entities that are accessible to the Drupal portal: even the ones that are indexed in datasets that are not yet registered to the portal.

tut_6_blog_400
Apr 15 2014
Apr 15

In this screencast, I explain how we can link (register) one or multiple OSF Web Services networks to a single OSF for Drupal instance. I discuss how this OSF Web Services mechanism can be used to bring datasets from multiple different OSF instances into the same Drupal portal. I also cover how we can use the same OSF Web Services network as the backend for multiple Drupal portals (which uses OSF for Drupal).

We briefly discuss the distributed aspect of the Open Semantic Framework (OSF), but this topic will be discussed more in deep in a subsequent screencast.

tut_5_blog_400
 
May 05 2012
May 05

Or: The What, When, Where, Why, and especially How

Versions of this talk has been presented at:

What are modules?

Drupal is designed to be modular. Instead of always having every possible tool or feature in every site's code, you can just have those you're actually going to use.

Drupal core —what you get when you install Drupal— is like a very basic box of Lego™: a platform and some basic bricks (modules) to get you started. You can do a lot with just those basics, but usually you'll want more.

That's where contributed modules come in. Contributed modules are packages of code that extend or enhance Drupal core to add additional (or alternate) functionality and features. These modules have been "contributed" back to the Drupal community by their authors.

When should you use contributed modules?

"The Drupal Way" can be summed up as both "Don't re-invent the wheel" and "Share and share alike". Although you may be perfectly capable of writing your own custom module to add some feature/functionality to your Drupal site, you should always first check to see if there is an existing module that does (or nearly does) what you want.

Using contributed modules not only saves initial coding time, it also makes it significantly easier for you and, especially, others to maintain the site in the future. Contributed modules also benefit from multiple eyes and multiple users to find problems and improve code.

Where can you find contributed modules?

Contributed modules live on Drupal.org, specifically, at http://drupal.org/project/modules. You can search the module list and filter it by category, Drupal version, and status. You can also sort based on most installed, title, author, last release date, etc.

Why should you choose one module over another?

Choosing which contributed modules to use is an art. There isn't an easy list of objective criteria to be checked off. There are, however, various factors that should be weighed when evaluating modules:

  • Suitability for your purpose
  • Release status
  • Recommendations by experienced Drupallers
  • Usage statistics (http://drupal.org/project/usage/[module_name])
  • Issue queue (not just outstanding issues, but response time, etc.)
  • Development activity
  • Author & maintainers

For more about how to choose modules, see Karen Stevenson's excellent session at DrupalCon Munich 2012 There Might (Not) Be a Module for That.

How do you install modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just four major steps to adding a contributed module to a Drupal site:

  1. Upload the module code
  2. Enable the module
  3. Set permissions for the module
  4. Configure the module

The four steps in detail

  1. Upload the module code
    • Upload (install) the module's file directory into the sites/all/modules/ directory
    • Preferably, upload as a compressed archive (.zip, .tar.gz) and expand the archive on the server (rather than expanding on your desktop and uploading as a folder with individual files). This is both quicker and avoids potential problems with file permissions or invisible files not making the transition.
  2. Enable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Enable (check) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  3. Set permissions for the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules).
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click Configure permissions
      • Drupal 7: Click Permissions
    4. Set permissions as appropriate.
    5. Scroll down to the bottom of the page and click the Save permissions button.
  4. Configure the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules)
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click [Module name] settings and, in turn, any other link(s) (besides Configure permissions or Get help)
      • Drupal 7: Click Configure
    4. Configure as appropriate.
    5. Don't forget to Save any configuration changes!

How do you uninstall modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just three major steps to removing a contributed module from a Drupal site:

  1. Disable the module
  2. Uninstall the module
  3. Delete the module code

The three steps in detail

  1. Disable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Disable (uncheck) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  2. Uninstall the module
    1. Return to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Click the Uninstall tab.
    3. Select (check) the relevant module.
    4. Click the Uninstall button. 
    5. When asked "Would you like to continue with uninstalling the above?", confirm by clicking the Uninstall button.
  3. Delete the module code
    • Remove the module's file directory from the sites/all/modules/ directory
Mar 21 2012
Mar 21

(This is the second installment of a multipart series. The first installment was Hiring Drupal professionals, part 1: Know what you need.)

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them?

This can be quite a challenge if you aren't very familiar with Drupal yourself. But the general principles are the same as for hiring any other kind of professional outside your own sphere of expertise. You want to look at their reputation, talk to references, check out their prior work, and watch for warning signs. Of course, there are some Drupal specific details for doing these things, too.

But before you can look at their reputation, prior work, and the like, first you need to know who they are. 

Who are they?

If they are an individual freelancer, do they use their own name in advertisements and on their website? If they use a company name, can you easily find out their real name on their website?

For a company, do they advertise under their company name? Can you easily find out the real names of those working for the company on their website? When checking reputations, you need to consider not only the reputation of the company as a whole, but also the reputation of the individuals associated with the company, especially those running the company and the individuals assigned to your project.

In short, you need to know who you're dealing with, and so should avoid any freelancer or company who is reluctant to let you know.

Who are they online?

If you haven't already found their professional or company website, ask for the URL. Ask if they have LinkedIn profiles, and if so, ask to see it. (If you can't see it without being in their network, ask to be connected, if only temporarily.) Ask if they have a professional Twitter account, and if so, what their Twitter handle/username is.

There are lots of good Drupallers who don't have LinkedIn profiles and/or professional Twitter accounts, but for those who do, checking them can help you confirm a positive impression (or improve a negative impression). 

Note that a pitiful website isn't necessarily a warning sign —the cobbler's children have no shoes and all that— but no website at all is strange for people who build websites for a living.

Who are they to Drupal?

Ask for their Drupal.org user number or a link to their Drupal.org user profile. (For example, my user number is 237528 and my profile can be found at http://drupal.org/user/237528). It is okay if they give you their Drupal.org username instead, though it requires more work on your part. (You can find a user's profile by searching for their username on Drupal.org and then, on the results page, clicking the "Users" link under "Or search for…".)

Not having a lot of activity on their Drupal.org account isn't necessarily a warning sign, but not having a Drupal.org account at all is strange for a professional Drupaller.

Warning signs

  • Advertising semi-anonymously, with only a phone number or first name and phone number. (For example, on Craig's List, stay away from ads that don't include either a company name or an individual freelancer's full name in the ad.)
  • No website. 
  • Website doesn't list any real names.
  • (Drupal specific) Won't tell you Drupal.org user number/profile link
  • (Drupal specific) Doesn't have a Drupal.org account

Now what?

So, you've advertised/searched for the kind of Drupaller you need and you know who the people who've responded are, now what? How can you know if any of these people are who you want? Stay tuned for the next installment in this series! (And I promise there won't be as big a gap between Part 2 and Part 3 as there was between Part 1 and Part 2!)

Jun 19 2011
Jun 19

I've been asked what I meant by "The Drupal Way" in my Drupallets blog post Hiring Drupal professionals, part 1: Know what you need.

In the Drupal community, "Drupal Way" is used in two related, erm, ways. The primary meaning is a general ethos or guiding philosophy, but it also gets used to refer to specific applications of that ethos. In my blog post, I was referencing the general principle, The Drupal Way, as a whole. But google "the drupal way" and you will find lots of hits talking about specific applications of the Drupal way, that is, the Drupal way to do X or the Drupal way to do Y.

The Drupal Way, the ethos, permeates every aspect of Drupal, from coding to content. It is the very essence of the Drupal community. It can be explained many different ways, but I like to boil it down to this:

Don't re-invent the wheel.

Or, put another way:

Share and share alike.

Drupal is not just open source; it is also modular by design. Thus it is not just licensed to share, it is designed to share —easily and flexibly— because by sharing (by not re-inventing the wheel) we all benefit. We can build better, more robust websites more quickly if we take advantage of one another's work than if we do everything ourselves from scratch.

This design and ethos goes beyond the mere existence of contributed modules to add features and functionality. If modules are like Lego bricks, the API(s) are the pegs that let you snap them together firmly to build your creation. Yes, you could lash some bricks together using duct tape, but the result just isn't going to be as good; further, it'll make it harder down the line to make improvements and updates.

Even more fundamental is Drupal's separation of visual appearance (themes) from structure/functionality (core & modules) from site content. Keeping these distinct makes sharing and reusing that much easier. For example, no need to build a whole new site structure and migrate all your content every time you want to totally change the site's visual appearance —just upload a new theme and click a few buttons.

And then there is content. I don't think it is a coincidence that CCK (Content Construction Kit, now in Drupal 7 core as fields) and Views were developed in Drupal. These contributed modules are simply —brilliantly— extensions of The Drupal Way to content. They, and various other Drupal modules as well, make it easy to enter content once but use it many times in many places in many different ways in your site. (For you relational database fans out there: think of a Drupal site as one gorgeous web-enabled relational database for your content. Or, as I heard someone put it: a Drupal site is essentially "things and lists of things". But more on that in another post…)

Finally, it should be noted that The Drupal Way is a guiding ethos, not rigid step-by-step instructions. Not re-inventing the wheel doesn't mean using the exact same wheel for every project. As often as you will hear "There's a module for that…" you will hear "There's different ways you can do that…"

So there you have it: Don't re-invent the wheel. This is the whole Drupal Way. The rest is commentary — and now go learn. (with apologies to Hillel…)

Update: Others' commentary on The Drupal Way

I'll be keeping an ongoing list of other good discussions of The Drupal Way (and/or not re-inventing the wheel). Please post or contact me if you know of any others!

Jun 06 2011
Jun 06

(This is the first installment of a multipart series.)

As a Drupal trainer and consultant, I've been getting a lot of phone calls lately either asking if I have trainees to recommend or else hoping that the "consultant" in my job title is a synonym for developer. (It's not: I'm the kind of consultant who helps you figure out what to do rather than the kind that does it for you.) People are having a really hard time finding experienced Drupallers to hire.

At the same time, I've become aware of more and more Drupal projects that went horribly awry because the freelancer or shop hired, though perfectly good PHP coders, didn't really know or understand Drupal. (In just in the last few months, I've personally had not one but two clients who were site-rescue refugees from the same freelancer!)

Unfortunately, the increasing popularity of Drupal can add up to a double whammy for those trying to hire Drupal help. Not only is there a shortage of experienced Drupallers, but there is an increasing number of inexperienced Drupallers offering their services. And these difficulties are compounded by the fact that many of those seeking to hire, quite naturally, don't know very much about Drupal.

So how do you find good Drupallers so your project actually gets the power, flexibility, and ease of use for content creators/managers that led you chose Drupal in the first place?

The first step is to ask for the right thing. There are different kinds of Drupal professionals and most clients and companies seeking to hire Drupallers don't understand or ask for the kind they need.

Besides end users, there are three broad categories of Drupallers: themers, site builders, and module developers. Of these, only module developers actually need to be PHP ninjas

Themers are responsible for the site's graphic design, which in Drupal is independent from the site structure and content. A Drupal site's entire visual design can be completely changed with literally just a couple mouse clicks. (For a demonstration of the independence of content and theme, visit Drupal Gardens —note how the content remains constant as you change from theme to theme.)

Themers come in two flavors: those who customize existing themes (subthemers) & those who create entirely new themes. Only the latter need significant PHP skills, but even then, graphic design and CSS mastery are much more important. For subthemers, PHP doesn't hurt, but isn't vital; often only custom CSS is needed.

Site builders put together the site's structure —the data types, displays, menus, navigation, entry forms, access control, administration, and other functionality for the site's content.

Site builders have even less need for mad PHP skills. Much more important is information architecture, usability, accessibility, and the like. Very complex, feature-rich Drupal sites can be built using only existing core and contributed modules. Indeed, while having familiarity with PHP can help, you actively do not want someone whose first instinct is to code to solve problems. For Drupal, custom PHP should be the last resort, not the first. Re-coding the wheel defeats the purpose and advantage of using Drupal!

If custom PHP is needed for a site —that is, if there is some functionality needed that can't be achieved using existing contributed modules— then it should go in a custom module, which is where module developers come in.

For module developers, of course, PHP is a must. But to be a good module developer, you also need to have good site building skills; you need to understand and appreciate The Drupal Way and also have mastery not just of PHP, but of the Drupal API (and certain contributed module APIs).

I should clarify that there aren't impenetrable divides between these three broad groups. Many themers are also site builders, many site builders are also at least subthemers, etc. and naturally there are various specializations that overlap or even fall somewhat outside these broad three, such as performance optimizers who get into server configuration, etc.

Unfortunately, clients and companies new to Drupal rarely know much about Drupal beyond that it is a CMS based on PHP and databases. So they understandably, but detrimentally, focus on the PHP bit, advertise for "Drupal developers", and emphasize PHP skills in their criteria.

But in a labor market where any kind of experienced Drupaller is in short supply and where there are more good site builders than good module developers, advertising for module developers (which is effectively what advertising for a "Drupal developer" with PHP skills is) when what you need is a good site builder is not the best recipe for success. Good site builders know when to bring in a themer or module developer, but trying to hire a module developer before you even know if you actually need one just frustrates everyone.

Worse, remember those decent PHP coders who don't really know Drupal? They tend to be attracted to "Drupal developer" positions that emphasize PHP skills, too. And that's how sites end up with custom PHP code that is not only totally unnecessary but located in the wrong place (e.g., hacked core/contributed modules or everything in a single theme page.tpl.php file instead of in a custom module where it belongs) and an unsustainable site that doesn't work properly.

You're much more likely to be successful finding and hiring a good Drupal professional if you know what kind you need and ask for it by name. If you're new to Drupal, start by looking for a "Drupal site builder" and emphasize Drupal knowledge and web best practices, not PHP skills. If you already have a site builder but need a graphics professional for your visual design, look for a "Drupal themer" and emphasize graphic design and CSS skills as well as Drupal theming knowledge. If you already have a site builder but determined that existing modules can't do what you need, then it's time to look for a "Drupal module developer" (not just a "Drupal developer") and emphasize Drupal module development knowledge, especially Drupal core and contributed module APIs and best practices.

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them? See the next installment in this series: Hiring Drupal professionals, part 2: Know who they are

[Added 5 Jun 2012] Especially for larger projects, a more expansive discussion of the different roles involved in creating (Drupal) websites can be found in Randall Knutson's great blog post Why Web Development is Like Building a House over at LevelTen. (Just make sure to translate their use of "Developer" to "Site builder"!)

May 28 2011
May 28

Updated! This is the version that I presented at Drupal Camp Sacramento Area at 10 am on 28 May 2011, updated & expanded from the version I presented at DrupalCamp @ Stanford at 10 am on 2 April 2011.

Session description

More than three score and ten useful contributed modules for building Drupal sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from accessibility to workflow, from images to input formats, and beyond.

This session will be of interest to beginner and intermediate Drupallers, as well as those who manage or hire Drupallers or who are just trying to decide whether to use Drupal.

(This functionality is part of core in Drupal 7.) indicates some or all of the module's functionality is part of core in Drupal 7.

Apr 27 2011
Apr 27

In the LinkedIn group Drupal Community Network, there has been a discussion started by the question: "Drupal for a novice or newcomer? Good Bad , Ugly and why?"

This was my response to that question:

Drupal = good, whether novice or expert. The thing to remember is that novices don't stay novices. Why start with something "easy" just to have to start all over again with something else when you outgrow it? But you can't outgrow Drupal. Drupal will more than keep up with you as your site grows and as your knowledge grows.

A good part of why Drupal is (in)famous for having "a steep learning curve" is because when people hear of all the things Drupal sites can do, they tend to want their Drupal site to do those things, too. And they want to be able to do everything right away — but there is no system in the world that lets you do everything and anything —easily— right away.

Right out of the box, Drupal —even Drupal 6.x— can easily be used for a personal blog or basic news site. Add one of many free themes (just a matter of uploading & expanding a file and then clicking a few buttons), and it becomes an even better looking site. Start with Drupal 7.x (released in January) and it is even easier and nicer right out ofthe box.

But it is unreasonable to expect to be able to create complex sites like Whitehouse.gov or Grammy.com easily as a novice. Of course, if you are building such complex sites, it is easier to build them using Drupal than in anything else I'm aware of (which is more than a good part of why those sites were built with Drupal).

So, yes, Drupal is good —great, even— for a novice or newcomer, whether you're just new to Drupal or new to website building entirely. It is incredibly powerful, but you can start simply and learn as you go along.

As the discussion progressed, and as people shared their own experiences with Drupal and other CMSes, coding was mentioned. I've noticed a lot of discussions of the merits of various CMSes, especially Drupal, tend to get bogged down in discussions of coding, as if being able to code was essential to building websites using Drupal. This is not the case at all! As I noted in the discussion:

I build flexible, complex sites using Drupal 6.x and 7.x without touching any code at all. The few times I have done any coding, it was only in the subtheme. (Most of the time all that is needed for the subtheme is to change the CSS.)

Coding is a last resort in Drupal. "The Drupal Way" mainly comes down to: Don't re-invent the wheel.

So, with regard to coding, that means use existing contributed modules to add functionality. If you do have to create a custom module, do your best to contribute it back to the community -- if you needed that functionality, chances are others want that ability, too. Share and help others, as others are sharing and helping you, so everybody can avoid re-coding the wheel.

(The Drupal Way extends to structuring your site for content, too: sites can be and should be set up so users enter content once, and then it shows up in as many different places as desired, automagically.)

After some more talk of coding (which I contributed to —my bad!), Steve Ringwood made an excellent point:

There is a fair amount of talk of coding here. I like to encourage new folks to look at the "legos". Between content types, views, panels and others (I like the display suite) you can achieve a lot without any coding. I think it valuable to understand what you can do first, before writing code.

The Legos analogy really suits Drupal. In Drupal, just as with Legos, you can build very simple things (CayucosLioness.org) or you can build very complex things (MTV.co.uk). You can use just the original rectangular Lego bricks (Drupal core) or you can add specially shaped Lego parts for added functionality (contributed modules). You can even, if you want, mold your own pieces (custom modules —though I'd say the analogy breaks down a bit here, because it is much easier to write your own modules than mold your own Lego pieces!)

Yet despite the Lego professionals who build incredibly detailed custom models or even the Lego fans who build the large and complex Lego kits of the Taj Mahal, Tower Bridge, and the like, nobody talks about Legos having a "steep learning curve". To the contrary, we tend to think of Legos as a child's toy, suitable for 5 year olds!

Just like Legos, Drupal grows with you. And, like Legos, your imagination is the only limit to what you can build with Drupal —including building simple websites easily.

So let's stop perpetuating this false notion that Drupal has a "steep learning curve". Drupal is Lego. Come play!

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