Drupal on Portland Drupal Developer

Transitioning from Drupal 7 to Backdrop CMS

me@gregboggs.com (Greg Boggs) — Wed, 22 May 2024 00:00:00 UTC

This is a guest post by Kana Patrick who is a world-class Drupal migration expert.

As the impending end of life for Drupal 7 draws near, the necessity for website owners to consider their migration options becomes increasingly urgent. While the prevailing trend in the Drupal community leans towards transitioning to Drupal 10 to leverage its modern features, some are hesitant due to the associated costs.

In this discourse, we advocate for a different approach by presenting compelling reasons to shift your website from Drupal 7 to Backdrop CMS if you have not already done so.

Embracing Backdrop CMS

Backdrop CMS emerges as a noteworthy contender in the realm of content management systems, originating as a fork from Drupal 7. Conceived in 2013 by Nate Lampton and Jen Lampton, this platform sought to streamline and enhance the foundational code of Drupal 7 while maintaining cost-effectiveness for users.

The reluctance of many website owners to depart from Drupal 7 may stem from financial constraints, sentimental attachment to the platform, or various other factors. However, the looming conclusion of Drupal 7’s lifecycle, coupled with the cessation of community support, prompts a reevaluation of alternatives.

A viable solution lies in transitioning directly to Backdrop CMS, offering a cost-effective migration path that preserves much of the original project’s structure since both systems share a common API rooted in Drupal 7.

Despite its nascent community, the Backdrop project signifies a supportive ecosystem that can aid in the growth of your endeavors, a valuable asset for those seeking assistance and collaboration.

Advantages of Migrating to Backdrop CMS

Backdrop CMS inherits the strengths of Drupal 7 while introducing distinct features.
It boasts modest system requirements, translating to affordable hosting solutions.
Unique functionalities absent in Drupal core are seamlessly integrated into Backdrop’s core framework.
Backdrop furnishes a robust foundation with extensive extensibility through contributed modules, harnessing the full capabilities of Drupal.
Scheduled updates and version releases provide a predictable timeline, mitigating uncertainties surrounding module updates.

In conclusion, Backdrop CMS emerges as a compelling alternative for Drupal 7 projects facing obsolescence. Evaluating the migration effort from Drupal 7 to 10 against a transition to Backdrop CMS presents an intriguing comparison. Should you require guidance or support in your migration journey to Backdrop CMS, do not hesitate to reach out for assistance.

Get Involved: Ways to Contribute to Drupal, No Experience Required

me@gregboggs.com (Greg Boggs) — Wed, 25 Jan 2023 00:00:00 UTC

There are many ways to contribute to an open source project like Drupal, and not all of them require a deep understanding of programming or web development. Some examples of ways to contribute include:

How to Contribute to Drupal - Ways for Everyone to Get Involved

Testing and reporting bugs: This can be done by looking through the issue queue on Easy Breadcrumb and look for issues that are marked “Needs Review”.
Documentation: Writing and improving documentation is a valuable way to help others learn and use Drupal.
Translation: Helping to translate the interface and documentation of Drupal into diffrent languages.
Support: Answering questions on forums and providing assistance to others in the community.
Design and User Experience: Helping to improve the look and feel of Drupal, and making it more user-friendly.
Marketing and outreach: Helping to promote Drupal and increase its visibility.
Code contributions: If you do have the skills, contributing code is a graet way to help improve Drupal and add new features. Swap the “Needs Review” filter to “Needs Work” and pick a task!

Drupal Contributor Resources

So, anyone can contribute to Drupal community, regardless of their technical skills. To get started with contributing to Drupal, there are a few resources that can be helpful:

Drupal Best Practices is a series of best practice posts that will help you get better at site building.
The Drupal community is a great place to connect with other developers and contributors. You can find information on upcoming events, join groups, and participate in discussions.
The Drupal issue queue is where you can find bugs and feature requests that need to be addressed. You can start by looking for issues that are labeled “novice” or “mentored” to find tasks that are well-suited for new contributors.
The Drupal documentation is a good resource for learning about the platform and its various components.
The Drupal handbook is a great resource for understanding the process of contributing to Drupal, including information on coding standards and best practices.
The Drupal Maintainers Slack channel is a great place to ask for help and connect with other developers, especially #maintainer channel which is for project maintainers and developers to discuss on how to maintain modules.

No matter what your skills are, there’s a way for you to contribute to the Drupal community. Join us, and make a difference!

Unleash the Power of Drupal 9 Routing: Create Custom Routes with Page Callbacks & Debug Like a Pro

me@gregboggs.com (Greg Boggs) — Tue, 17 Jan 2023 00:00:00 UTC

Routes in Drupal are a powerful tool to programatically execute code and build custom pages for tasks such as custom forms and data processing. However, Routes rely on learning a few key concepts and they can be tricky to learn at first. So, lets break them down step by step.

How do I create a route with a page callback in Drupal 10?

To create a route file with a page callback in Drupal, you can follow these steps:

Create a new file in your module’s src/Routing directory, named module_name.routing.yml. In this file, define your route using the YAML syntax. An example of a basic route might look like this:

module_name.example:
  path: '/example'
  defaults:
    _controller: '\Drupal\module_name\Controller\ExampleController::examplePage'
    _title: 'Example Page'

The path key defines the URL path of the route, and the defaults key contains the page callback and page title for the route. In this example, the page callback is a method named examplePage in the ExampleController class of the module_name module.

Clear Drupal cache so the new route can be picked up by the system.

That’s it! The new route should now be accessible at the URL /example and will use the specified page callback method. You can also pass a parameter in the path, for example path: ‘/example/{parameter}’ and use it in the controller with $parameter = $route->getparameter(‘parameter’)

How do I debug a Drupal 10 routing file?

There are several ways to debug a routing file in Drupal 10, here are some examples:

Use the Devel module: The Devel module is a popular development tool for Drupal, it provides a suite of debugging tools, including the ability to view the routing information for your site. To enable this feature, you need to install and activate the Devel module, and then navigate to the “Devel” -> “Routes” page to view the routing information for your site.

Use the Drupal Console: The Drupal Console is a command-line interface for Drupal that provides a variety of debugging tools. To use the Drupal Console to debug your routing file, you can use the command drupal router:debug to view the routing information for your site.

Use the dpm() function: The dpm() function is a debugging function provided by the Devel module that allows you to print variables to the message area of the page. By adding dpm($routes) to the routing file, you can see the array of all routes.

Use the kint() function: The kint() function is also a debugging function provided by the Devel module that allows you to print variables to the message area of the page, but with more information than dpm(). By adding kint($routes) to the routing file, you can see the array of all routes and more information about the routes.

Use the browser developer tools: By using browser developer tools, you can see all the requests made by the browser and check if the routing file is working correctly.

It’s important to remember that you should only use these debugging tools during development and remove them before deploying to a production environment, as they can expose sensitive information about your site.

How do I make my route higher priority in Drupal 10

In Drupal 10, you can make a route have a higher priority than others by setting a higher weight for the route in the routing file. Here’s an example of how to do this:

In your routing file, you can set the weight property for your route. The weight property is used to determine the order of the routes. Routes with a higher weight will be matched first.

empty_front_page.content:
  path: '/'
  defaults:
    _controller: '\Drupal\empty_front_page\Controller\EmptyFrontPageController::content'
    _title: 'Empty Front Page'
  weight: 10

The default weight is 0. If you want your route to have a higher priority, you can set a higher weight. In the example above, the weight is set to 10, which makes it have a higher priority than any other route with a lower weight.

Keep in mind that if you have multiple routes with the same weight, the order in which they are defined in the routing file will determine which route is matched first.

Clear the cache after making any changes in routing file.

By setting a higher weight for your route, you can ensure that it is matched before any other routes with a lower weight. This can be useful if you have multiple routes that match the same path and you want to ensure that a specific route is always matched first.

And there you have it folks, you’re now a pro at creating custom routes and debugging like a boss in Drupal. Just remember, if you ever get stuck, don’t hesitate to call upon the almighty Drupal gods for guidance… or just Google it. Happy routing!

Creating the Empty Front Page Module for Drupal 9 with Chat GPT

me@gregboggs.com (Greg Boggs) — Mon, 16 Jan 2023 00:00:00 UTC

An empty front page in Drupal can be a useful feature for many websites. Whether you want to use the front page for blocks or simply want to direct users to other pages of your website, an empty front page can be a great way to control the user experience on your website. In this blog post, we will discuss:

How an Empty Front Page Works

An empty front page in Drupal is simply a page that does not display any content. This can be achieved by creating a custom route for the front page that does not point to any content. In Drupal, the front page is controlled by the system.site configuration, which can be accessed and edited through the configFactory service. By setting the 'page.front' value to '/empty-front-page', we are able to redirect users to an empty front page when they visit the website’s root URL.

The Process of Creating a Custom Drupal Module

Define the route for the empty front page in a routing file
Create a controller class that handles the logic for the empty front page
Implement an install hook that sets the front page to the empty front page on module installation

The Steps I Took to Finish the Module

Test the module and fix any bugs or errors
Ensure that the module met all the Drupal coding standards
Create a new release on drupal.org

Chat GPT Generates a Unique Solution

As a language model, ChatGPT generated this Drupal module and this blog post to provide an overview on how to create an empty front page in Drupal. GPT-3, or Generative Pre-training Transformer 3, is a neural network-based language model developed by OpenAI that uses deep learning to produce human-like text. This state-of-the-art language model generates text that is difficult to distinguish from text written by humans. ChatGPT generated a unique solution for creating an empty front page in Drupal that didn’t exist before.

If you’re interested in using this module, you can find https://www.drupal.org/project/empty_front_page on drupal.org.

Or, you can check out my other Drupal module that wasn’t generated by AI Drupal 8 Breadcrumbs

In conclusion, creating an empty front page in Drupal is a relatively simple process that can be achieved by creating a module. By defining a custom route, creating a controller, and setting the 'page.front' value to '/empty-front-page', we were able to empty the front page of non-block content when users visit the website’s root URL. This allows website owners to have more control over the user experience on their website.

Migrating a website from Drupal 7 to Drupal 9

me@gregboggs.com (Greg Boggs) — Sun, 03 Jul 2022 00:00:00 UTC

This is a guest post by Kana Patrick who is a world-class Drupal migration expert.

The end of life of Drupal 7 is getting closer and every day more and more website owners are starting the migration. This process is not easy and almost always takes a long time. I recently migrated a client’s site from Drupal 7 to Drupal 9. The purpose of this article is to share with you my modest experience.

Different migration processes from drupal 7 to Drupal 9

There are essentially 2 ways to migrate a site from Drupal 7 to Drupal 9:

Updated the site using the migration scripts provided by the Drupal core (Based, since Drupal 8, on the Migrate community module and now in the core);
Create a completely new Drupal 9 site, and attempt to recover the contents of Drupal 7 (again using Migrate-based tools).

In general, I recommend the second solution, as it is the one that was used in the case of the migration of the Northwest Analytics Inc. Site and it is the one that often generates the least constraints by promising a transformation of the content as needed.

The website on drupal 7 was launched in 2011 and before the migration started, it had : - 5K+ Users - 3K+ Medias - 12k+ Noeuds - 20K+ Webform submission

Note that the site had multilingual content

Can you imagine those crazy numbers?

But despite this size, generally, the whole migration consists of 4 main steps:

Creation of mappings from the old Drupal 7 site to the new Drupal 9 site.
Creation of the appropriate entities/fields on the Drupal 9 site.
Content migration itself by migrating module from Drupal 9 core.
Both Contrib and Custom functionality implementation/migration.
Theme migration.
Production deployments and content managers studying.

Of course, it sounds easier than it is. I have faced many complex and interesting challenges during my migrations. I will do another article on it so I can share my difficulties with you.

As time goes by, the migration becomes more and more expensive and the old Drupal 7 site is more and more challenging to maintain. Take courage and start migrating your Drupal 7 project to Drupal 9 today. Looking to migrate from your current Drupal 7 site to the new Drupal 9? I invite you to contact me for your Drupal site migration projects!

Creating Patches from Drupal Merge Requests

me@gregboggs.com (Greg Boggs) — Wed, 25 Nov 2020 00:00:00 UTC

Drupal.org has used patches to manage community contribution for many years. But, patches are difficult for new users to learn and require the use of the command line. Recently, Drupal.org code has migrated to Gitlab, and we can now use Gitlab and Drupal.org issues to create merge request to share code and fixes with modules and Drupal Core. But, how do you use the code on your site immediately?

Create a patch file and upload it to the issue on Drupal.org.

Patches from Forks

You can obtain the patch by adding .patch to the URL of a merge request. To get to the merge request, click on the merge request in the issue. Make sure to remove any # from the end of the URL. The URL should look like this:

https://git.drupalcode.org/project/easy_breadcrumb/-/merge_requests/5.patch

From there, save the file as a file named .patch and upload it to Drupal.org!

Drupal Merge Requests using Gitlab!

me@gregboggs.com (Greg Boggs) — Fri, 20 Nov 2020 00:00:00 UTC

Drupal.org has used patches to manage community contribution for many years. But, patches are difficult for new users to learn and require the use of the command line. Recently, Drupal.org code has migrated to Gitlab, and we can now use Gitlab and Drupal.org issues to create Merge Requests to share code and fixes with modules and Drupal Core. Here’s an overview of creating a merge request for folks who want all the details.

Drupal Forks are Special

Drupal Gitlab forks are special because they are accessible to everyone with a Drupal.org account. One fork per issue, and anyone can edit the fork and open a merge request to the main project.

Setup your Drupal Account

Before we begin, you must register for an account on Drupal.org to get access to gitlab forks. Next, add an ssh public key to your Drupal.org user profile so you don’t need a password to work. Lastly, agree to the Drupal.org git terms of service so you can access forks.

Before you can create forks on Drupal.org’s gitlab, you need an issue! So, start by creating an issue on Easy Breadcrumb.

Once you have the issue, press “Create issue fork”.

Next copy of the module you want to modify. You can get instructions for this by clicking version control near the top of the module.

git clone --branch 8.x-1.x git@git.drupal.org:project/easy_breadcrumb.git
cd easy_breadcrumb

Make Your Changes

Now, edit the code on your own computer to fix the issue. This is the hardest part!

Send Your Work to the Issue Fork on Gitlab

The exact git commands vary slightly from issue to issue. So, check the “view commands” link on the issue to see the commands for your issue, but here are the ones I ran. I got the commit message from the commit credit section towards the bottom of the issue.

git remote add easy_breadcrumb-3174165 git@git.drupal.org:issue/easy_breadcrumb-3174165.git
git fetch easy_breadcrumb-3174165
git checkout -b '8.x-1.x' --track easy_breadcrumb-3174165/'8.x-1.x'
git add .
git commit -m 'Issue #3174165 by kell.mcnaughton, pattsai: How to support limiting depth' --author="git <git@3602480.no-reply.drupal.org>"
git push --set-upstream easy_breadcrumb-3174165 HEAD

The commands do the following:

Add the new fork as a remote.
Fetch the new fork.
Checkout a branch on that fork.
Add your work to that branch.
Commit your work to that branch.
Push your work to Gitlab.

Open a Merge Request

Once your work is saved to the issue fork on Gitlab. Go back to the issue on Drupal.org and click Compare near the top of the issue. Then, click open merge request!

Now that your request is open, the maintainer of the module just needs to press merge on Gitlab to make the code part of the project!

Drupal Maintainer's Initiative

me@gregboggs.com (Greg Boggs) — Fri, 19 Jun 2020 00:00:00 UTC

With the launch of Drupal 9, the community is rallying to update all of the community contributed modules from Drupal 8 to Drupal 9. This work is often just a single line of code to tell Drupal that the module supports 9. But, for older, out of date modules, the work required to get to Drupal 9 is a bigger effort. Some of these modules haven’t been updated in 4 years.

I’m not to complain about problems without solutions. So, how do we fix it?

The Maintainer’s Initiative!

Together with Damien Mckenna, we’ve started a new Drupal project called Maintainers. Our goal is to support as much of Drupal contrib as we can while focusing on issued marked “reviewed and tested by the community”. Instead of starting a new module, we’re picking up where others left off.

Finishing Drupal 8 Ports

Beyond curating releases for older Drupal 8 modules, I also hope to finish Drupal 7 to 8 ports that aren’t quite finished yet. Most recently, I assisted with releases for of AddtoCal and ShareThis. My next todo is a release for Styleguide and Author Pane.

Join Us

You can read more about the effort on the Drupal Association blog, or join us on Drupal Slack at channel #maintainers.

Content Modeling in Drupal 8

me@gregboggs.com (Greg Boggs) — Sun, 25 Sep 2016 00:00:00 UTC

In many modern frameworks, data modeling is done by building out database tables. In Drupal, we use a web-based interface to build our models. This interface makes building the database accessible for people with no database experience. However, this easy access can lead to overly complex content models because it’s so easy to build out advanced structures with a few hours of clicking. It’s surprising how often Drupal developers are expected to be content modeling experts. Here’s a well-written overview of content modeling for the rest of us who aren’t experts yet.

Data Modeling Goal

Our goal when modeling content in Drupal is build out the structure that will become our editor interface and HTML output. We also need to create a model that supports the functionality needed in the website. While accomplishing this, we want to reduce the complexity of our models as much as possible.

Getting Started

One of the first things to do when building a Drupal site is to build content types. So, before you start a site build, start with either a content model or a detail page wire frame. This spreadsheet from Palantir will help you. The home page design may look amazing, but it’s unhelpful for building out content types. Get the detail pages before you start building.

Why Reduce Complexity?

The more content types you create, the more effort it will take to produce a site. Further, the more types you have, the more time it will take to maintain the site in the future. If you have 15 content types and need to make a site-wide change, you need to edit 15 different pages.

The more pages you need to edit, the more mistakes you will make in choosing labels, settings, and formatters. Lastly, content can’t easily be copied from one type to another which makes moving content around your site harder when there are many content types. So, the first thing you’ll want to do with your content model is to collapse your types into as few types as feasible. How many is that?

5 Content Types is Enough

Drupal has many built in entities like files, taxonomy, users, nodes, comments, and config. So, the vast majority of sites don’t need any more than 5 content types. Instead of adding a new content type for every design, look for ways to reuse existing types by adding fields and applying layouts to those fields.

Break Up the Edit Form

Drupal 8 allows you to have different form displays for a single content type. With either Form Mode Control or Form Mode Manager, you can create different edit experiences for the same content type without overloading the admin interface.

Now that we’ve got the goal in mind and some tools to get us there, we’ll dive into the specifics of configuring field types such as hero images and drop down lists in my next post.

Drupal 8 Admin Best Practices

me@gregboggs.com (Greg Boggs) — Sat, 05 Mar 2016 00:00:00 UTC

Drupal sites often suffer from a less than ideal editor experience. While Drupal 8 improves on the default experience by providing inline editting, working preview, and moving the ‘advanced’ options to the sidebar, there’s still common mistakes that will lead to poor a experience. As a part of my on-going Drupal 8 Best Practices series, lets look at what we can do to build good admin interfaces.

Here are a few major principles behind the admin experience:

Use as few content types as reasonable.
Use permissions to hide unneeded options.
Content should not be defined in code.
Content and layouts should be editable by the editor without modifying code or css.
Content should have a contextual edit link.
A site should not require admin access to figure out how to edit.
Content should be stored in nodes, not entities or taxonomy terms.
Taxonomy can be used to apply additional page styles.
Taxonomy terms should have limited fields.
Vocabularies shouldn’t be too large or too deep.
The editor should have easy links and dashboard.
Editors should be given the Clear Cache permission.
CKeditor should be configured to allow pre-selected CSS styles.
Editors should have a simple tool for applying layouts to new pages.
Editors should be able to apply custom CSS via a drop down.

Give Permissions Carefully

Clients should be given the admin password for user 1, but every user should log into the site with their own user account that has an ‘editor’ permission set. This editor account should only be given permission to do the things they do frequently.

Content Should be Editable

There’s no reason to hard-code content into your theme or PHP. Every piece of text on the page should be editable through the hover edit link over that content. If you can’t edit something without a git push, then it should be a blocking bug.

Content Should be Stored in Nodes

This is a common mistake. Taxonomy terms are not content. They are meant to organize content. So, if you’re putting fields (especially text fields) on terms, you’re prboably making a pretty big error because taxonomy terms can’t be unpublished, promoted, or revisioned easily. If you’re putting content into custom entities, you’re probably also making a mistake because entities take a lot of extra work to get the basics that you get from nodes for free.

Give Editors Links and a Dashboard

Think of WordPress here, do you see your user profile when you first log in? No, you see a dashboard of content to edit and other useful information. Do the same in Drupal, redirect login to admin/content if nothing else. Give folks short cut links in their menu bar as well.

Did You Clear the Cache?

Lets face it, the cache clear problem from Drupal 7 is a bit worse in Drupal 8. There are many times you need to Cache Rebuild. So, give them the button.

Use a Layout System or Layout Taxonomy

Panels and Display Suite are popular because they are powerful, stable, uesful and easier to use than default Drupal. No matter what tools you use, give your editors easy abilitiy to apply a layout to a new page. Don’t hand code each page. Build layouts, and apply them. Even a simple ‘Layout’ taxonomy field can allow editors to apply layouts to content.

When deciding how to build things in Drupal 8, always spend some thought on how to make sure each piece of content will editted. Not only will your customers thank you, you’ll be making Drupal look good.

Drupal 8 Theming Best Practices

me@gregboggs.com (Greg Boggs) — Sat, 05 Mar 2016 00:00:00 UTC

The theming guide for Drupal 8 will get you started in the basics for theming a Drupal site. But, once you’ve learned the basics, what best practices should you be applying to Drupal 8 themes? There are lots of popular methods for writing and organizing CSS. The basics of CSS, of course, apply to Drupal.

Don’t get too specific
Place your CSS in the header and JavaScript in the footer
Organize your CSS well
Theme by patterns, don’t go top down
Preprocess your styles

Use configuration first

When it comes to Drupal, there are some common mistakes that happen when a front end developer doesn’t know Drupal. In general, apply your classes in configuration. Do not fill your Drupal theme with custom templates like you would for WordPress. Template files, especially with Twig, have their place. But, configuration should be your primary tool. My favoriate tool for applying classes is Display Suite and Block class. Panels is also good. And, fences isn’t terrible.

By applying your classes in configuration allows you to easily edit, reuse, and apply classes across every type of thing in Drupal. If you apply your classes with templates, it’s difficult to apply them across different types of content without cutting and pasting your code. However, don’t be afraid to use some presentational logic in your Twig templates.

Be careful what you target

In Drupal, there are many times where the only selector you have that will work is an ID. If you have this problem, Don’t use it! Never, ever, ever, apply your CSS with ids in Drupal. This is true for every framework, but in Drupal it’s a bigger problem because IDs are not reusable, they are hard to set, and they often change. A backend developer will not be able to apply your styles to other items without fixing your CSS for you. Don’t write CSS that you know a PHP programmer will have to rewrite because you don’t want your PHP programmer writing CSS.

Use view modes

Make sure to target your styles to reusable elements. So, avoid node types because those aren’t reusable on other nodes. Instead, use view modes and configuration to apply selectors as you need them.

Avoid machine names

This relates back to avoiding IDs. Machine names in Drupal sometimes need to change, and they are not reusable. So, don’t target them. Instead use view css, block class and configuration to apply classes to your content.

Don’t get too specific

Drupal 8 markup is better, but Drupal is still very verbose. Don’t get sucked in by Drupal’s divs. Only get as specific as you need to be. Don’t replicate Drupal’s HTML in your CSS.

Apply a grid to Drupal

Choose a grid system that allows you to apply the grid to any markup like Singularity or Neat. While you certainly can Bootstrap Drupal. Using Bootstrap on Drupal requires a heavy rewrite of the HTML which will break contributed modules like Drupal Commerce in obscure, hard to fix ways.

Do not write advanced business logic into your theme templates. If your theme is programming complex features, move that code to a module. Or, install modules like Current Page Crumb, or Advanced Agg to handle more complex functions. This isn’t WordPress, your theme shouldn’t ship with a custom version of Panels.

Don’t hard code layouts

Use {{ content }} in your templates and let the View Modes, Display Suite, or Panels handle your layouts.

Don’t use template.php

If you need some ‘glue’, write or find a module meant for it. Drupal is built by many, many tiny modules. Learn to love it because well-written modules are reusable, maintained for free and always improving. Custom code dropped into your theme makes for hard to maintain code.

Drupal 8 Breadcrumbs - Add the Current Page

me@gregboggs.com (Greg Boggs) — Fri, 04 Mar 2016 00:00:00 UTC

Breadcrumbs are a pain point in Drupal 7. If you don’t know how breadcrumbs are supposed to work, go read this. The crumb should start with home and continue through to an unlinked crumb of the current page. Crumbs were implemented poorly, and breadcrumbs were difficult to modify in a module. Further, they were based on items in the menu. The breadcrumbs didn’t even allow you to edit the home title or include the current page title as an unlinked crumb. So, if you wanted breadcrumbs on a Drupal site, the first step was to choose 1 of 10 different modules to build them for you. Making matters worse, some themes decided to program breadcrumbs for you as well. If you’re stuck with a Drupal 7 breadcrumb problem, use a module I help maintain, Easy Breadcrumb. Trust me. I’ve got this for you.

Drupal 8 vastly improves breadcrumbs, but core still gets them wrong. They are based on the current page path exactly like Easy Breadcrumb in Drupal 7 which is a huge improvement. So, what did they get wrong? The current page title is missing. Bummer. So close. But, not hard to fix. So, lets do it! If someone tells you to program the breadcrumbs into your theme, don’t listen to them. They are doing it wrong. Themes should work with markup and presentation. They shouldn’t implement complex, reusable logic.

Drupal 8 has refactored breadcrumbs making them much easier for developers to extend or replace. This new architecture makes it easy for us to correct Drupal 8’s breadcrumbs. Unfortunately, the code from Larry’s post is a bit out of date and doesn’t work anymore. So, lets look at the code pulled from my module Current Page Crumb module that adds the current page title to the breadcrumb.

This code extends the PathBasedBreadcrumbBuilder core class to add the current page title to the breadcrumb. Since everything else needed for the breadcrumb is handled by the parent, line 31 does almost all the work for us. From there, we just need a few lines to add the current page’s title. If you’re looking for more examples to completely replace the core breadcrumbs with a custom builder, check out the Drupal 8 version of Easy Breadcrumb which does just that.

Drupal 8 Configuration Workflow Best Practices

me@gregboggs.com (Greg Boggs) — Thu, 18 Feb 2016 00:00:00 UTC

Don’t store site configuration in the database during development because putting configuration in the database makes configuration difficult to track in version control. Instead, use the file system! Putting configuration in a database also makes it more difficult to restore, compare, sync, deploy, modify, and review the site config. Drupal 8 uses Yml files for configuration which are a perfect format for file-based configuration. In fact, this is the only method for storing configuration in BackdropCMS because BackdropCMS uses JSON files to store site configuration. Drupal uses Yaml to store your configuration the database, but storing Yaml in files was the default method for Drupal 8 when CMI was released. Many posts have been written about the default workflow for configuration. But, the promise of file-based workflow is more efficient.

Configuring in Files Workflow

When Drupal stores configuration files in the file system, all you do to save your work is run a git commit because as soon as you click save in a form, Drupal writes your changes to the configuration folder. Once your work is in code and committed to version control, you can publish those on GitHub and open a pull request to review your work before deploying it to production. This workflow is possible with database configuration, but it requires extra steps with Drush that can lead to errors and differences between environments.

Don’t Modify Production

No matter which storage you use for configuration, you should not edit your configuration in production. Instead, you should install the config readonly module in production and make all of your changes in your local environment. Clients who don’t install Drupal locally can make configuration changes in development. Using a host like Pantheon makes it easy to deploy files from development to production.

So Why Does Drupal Store Config in the DB?

I prefer keeping configuration in the file system, and BackdropCMS agrees with me. But, a few smart core developers don’t see it that way. So, why not? Drupal 8 is slow. And, some poor web hosts might allow the public to read configuration files.

Early in the release cycle the install process was slow. So initially, moving configuration into the database made running the installer a bit faster. However, file-based configuration in the current release of Drupal 8 doesn’t make the installer visibly slower. So, this isn’t a problem for our workflow.

The second concern with file based configuration is the desire for security through obscurity. Since we are storing configuration outside the webroot, and our web server should also be configured not to display configuration files, this isn’t an issue.

Another concern was that file configuration might encourage people to edit their configuration. Since this workflow is for programmers, this is an advantage of our workflow.

Advantages of Database Config Storage

Storing configuration in the database on production has some minor advantages. So, leaving the configuration in the database on production is reasonable. Storing in the file system means you have to sync the file system in multiple web server environments.

Storing config in the database allows you to attach metadata to the configuration so that you can timestamp it, assign an owner to it and create a revision workflow for configuration.

How to Enable Config in Files

The easiest way is to use the Drupal8-base installer which will enable file storage for configuration out of the box. Alternatively, you can export your site configuration from the database and then follow these quick steps to enable file-based configuration storage on an existing Drupal site.

Drupal 8 Development Best Practices

me@gregboggs.com (Greg Boggs) — Wed, 20 Jan 2016 00:00:00 UTC

These core concepts apply to Drupal 8 site builds. However, many often apply to the other major web framework from WordPress to Node projects. Many of these ideas are documented on Drupal.org as well. I’m rewriting them here because I disagree with the documentation in several key areas.

Use The Same Development Environment

Everyone on your team should have exactly the same development environment. Using the same development environment ensures that the project runs exactly the same for each team member working on a project. You can do this with Vagrant, Ansible, or a Brew script.

Backups? Put The Database in Code With CMI

Configuration Management in Drupal 8 allows you to quickly store database settings in code. Further, content should come from a single reusable source. We use Google Docs API, others use Profiler. The key is keep your test content in a shared, predictable place.

Drupal.org recommends that you backup your files and database. Since all of your code is on Github, and your database is in your code, Backups only matter in production. After a project launches, your hosting company should be providing backups. If your host isn’t taking care of this automatically for you, then switch to a web host like Pantheon, WP Engine, or Site Ground. All provide automated backups. Site Ground gives you per file recovery while Pantheon focuses on CMS backups for code/files/database in an easy to restore tool.

Never Hack Core (or Contrib)

Don’t change the framework. Instead, write your own code as a module. Pantheon, doesn’t follow this rule, and it creates a lot of extra work for them. But, they have an entire company of developers to maintain their fork of Drupal. The rest of us should stick to the official release. This is true no matter the framework you’re in. If you hack WordPress, your project will fail during automatic updates!

Use Test Sites

Your hosting company should be providing 2-3 sites for each production site automatically. If your hosting company doesn’t give you test sites, switch to Pantheon or WP Engine. You should make all your changes in your local environment first, test them locally, and then deploy them to test in production servers on a test server.

Use Configuration Before Code

Instead of hard coding a class or a snippet of logic into a theme, set these values in configuration and then apply the configuration with code. This allows your code to change in the future without being rewritten. This also leads us to choose high quality, well maintained modules to build our sites out of. Reusing code is one of the most basic steps in writing quality software because reusable code will have fewer bugs and more features.

Instead of writing a massive “glue” module, break up functionality into reusable modules and use configuration to apply advanced functionality so that each module is more powerful and easier to modify without rewriting the code.

Avoid Too Many (Poor) Modules

For those of us who work on large scale Drupal sites, we’ve learned that hundreds of modules can work together to produce an amazing, large-scale software project. When building enterprise Drupal sites, it’s more important to avoid using 1 poor module than it is to avoid 30 well built modules. This too many modules advice leads programmers to favor programming their own modules over reusing modules. However, avoiding contributed modules means you end up rewriting basic Drupal features in every new project.

This includes your custom modules

Drupal.org only talks about contributed modules, but this too many modules advice holds for custom modules as well. The more custom modules you write, the more work it takes to maintain and modify your website. Instead of writing a large collection of custom modules, or a single giant glue module, consider publishing your modules on Github. This will encourage you to create reusable code that has configuration needed to make them reusable and future proof.

Follow Coding Standards

You can automatically check and repair your code for Drupal with Code Sniffer.

Up next, controversial configuration practices for Drupal 8 that will improve your workflow.

Drupal 8 Site Building Best Practices

me@gregboggs.com (Greg Boggs) — Wed, 20 Jan 2016 00:00:00 UTC

I’ve taught an beginners course during Drupal Global Training Days many times in portland, and I give students an introduction to Drupal 8 for site builders. I spend the day simplifying Drupal for new developers. But once you’re beyond the basics of the interface, there are many different ways to accomplish a task in Drupal and Drupal 8 only adds to the choices. So, if you’re a Drupal developer looking to craft easier to maintain Drupal 8 sites, this series is for you.

Over the years I’ve developed many strong opinions about the best way to “drupal”. Some of my decisions aren’t actually better than alternatives, but they are patterns I’ve memorized to make my work more efficient so I can avoid getting stuck building sites. This series will cover the following topics:

Drupal development best practices
Drupal configuration workflow
Drupal breadcrumbs
Theming best practices
Editor experience basics
Content modeling in Drupal 8
What to do with blocks
Creating lists correctly
Mistake-free site search
Breadcrumbs in 20 minutes
Permissions and roles basics
Caching - don’t get this wrong
JavaScript - required for every developer
CSS - because we can’t make white and black websites every time
Images - no one likes a slow website
What you know about web fonts is wrong
Responsive, adaptive sites in Drupal
Coding standards
Git usage for Drupal projects
Cookies are dead
Deploying Drupal 8
Performance basics because performance helps the environment
Web hosting because $5/mo isn’t enough

And, if you don’t want to wait for me to write and publish all these best practices, feel free to join me in this Gist for a sneak preview without the explanations.

Drupal on Portland Drupal Developer

Transitioning from Drupal 7 to Backdrop CMS

Embracing Backdrop CMS

Advantages of Migrating to Backdrop CMS

Get Involved: Ways to Contribute to Drupal, No Experience Required

How to Contribute to Drupal - Ways for Everyone to Get Involved

Drupal Contributor Resources

Unleash the Power of Drupal 9 Routing: Create Custom Routes with Page Callbacks & Debug Like a Pro

How do I create a route with a page callback in Drupal 10?

How do I debug a Drupal 10 routing file?

How do I make my route higher priority in Drupal 10

Creating the Empty Front Page Module for Drupal 9 with Chat GPT

How an Empty Front Page Works

The Process of Creating a Custom Drupal Module

The Steps I Took to Finish the Module

Chat GPT Generates a Unique Solution

Migrating a website from Drupal 7 to Drupal 9

Different migration processes from drupal 7 to Drupal 9

Creating Patches from Drupal Merge Requests

Patches from Forks

Drupal Merge Requests using Gitlab!

Drupal Forks are Special

Setup your Drupal Account

Create an issue on Easy Breadcrumb

Clone Easy Breadcrumb

Make Your Changes

Send Your Work to the Issue Fork on Gitlab

Open a Merge Request

Drupal Maintainer's Initiative

The Maintainer’s Initiative!

Finishing Drupal 8 Ports

Join Us

Content Modeling in Drupal 8

Data Modeling Goal

Getting Started

Why Reduce Complexity?

5 Content Types is Enough

Break Up the Edit Form

Drupal 8 Admin Best Practices

Give Permissions Carefully

Content Should be Editable

Content Should be Stored in Nodes

Give Editors Links and a Dashboard

Did You Clear the Cache?

Use a Layout System or Layout Taxonomy

Drupal 8 Theming Best Practices

Use configuration first

Be careful what you target

Use view modes

Avoid machine names

Don’t get too specific

Apply a grid to Drupal

Use a breadcrumb module

Don’t hard code layouts

Don’t use template.php

Drupal 8 Breadcrumbs - Add the Current Page

Breadcrumb Improvements

Drupal 8 Configuration Workflow Best Practices

Configuring in Files Workflow

Don’t Modify Production

So Why Does Drupal Store Config in the DB?

Advantages of Database Config Storage

How to Enable Config in Files

Drupal 8 Development Best Practices

Use The Same Development Environment

Backups? Put The Database in Code With CMI

Never Hack Core (or Contrib)

Use Test Sites

Use Configuration Before Code

Avoid Too Many (Poor) Modules

This includes your custom modules

Follow Coding Standards

Drupal 8 Site Building Best Practices