Have you ever thought to yourself, “I like WordPress, but … can I build a website in WordPress the same way as I would in Drupal?”. If so, you’re not alone. This guide is for Drupal agencies and developers who are considering how to build powerful, complex, and flexible websites with WordPress.
- Introduction – Why Consider Moving from Drupal 7 or Drupal 8 to WordPress?
- Chapter 1 – Mapping Basic Drupal Features to WordPress
- Chapter 2 – Migrating Content and Data from Drupal into WordPress
- Chapter 3 – Mapping Advanced Drupal Architecture and Display/Layout Features to WordPress
- Part 1: Drupal Paragraphs / Field Collection » WordPress Gutenberg + Toolset Types
- Part 2: Panels / Layout Builder / Lightning » Toolset Layouts + Gutenberg
- Part 3: Display Suite » Toolset Content Templates
- Part 4: Context » Widget Context
- Part 5: Custom field types » Toolset Custom field types
- Part 6: Relationships (Node/EntityReference) » Post Relationships
- Part 7: Media, Image styles, etc » Media, Content Templates, Views
- Part 8: Custom Blocks » Toolset Block
- Part 9: Drupal Multilingual » WPML
- Chapter 4 – Advanced “Drupal-style” Sitebuilding Solutions in WordPress
- Solution 1: How to build an “exposed filters”-style custom search in WordPress with Toolset Views
- Solution 2: How to build a custom interactive map using Toolset Views and Toolset Maps
- Solution 3: How to display related posts with toolset
- Solution 4: How to create Nodequeue-style (or Entityqueue) custom list
- Chapter 5 – Authoring and Managing Custom Code in Drupal vs WordPress: More Similarities than Differences
- Chapter 6 – Rebuilding Your Drupal Views in WordPress
- Chapter 7 – Replicate Your Drupal Forms for Front-End Content Creation and User Registration: Toolset Forms
- Chapter 8 – Rebuilding Your Drupal Access Controls in WordPressa
- Chapter 9 – Content publishing, Admin UX, SEO, Media Management, and Gutenberg
- Chapter 10 – DevOps, Performance, and Security in Drupal vs WordPress
- Chapter 11 – Pricing Table: the Freemium ecosystem, consulting fees WordPress vs Drupal
The short answer: because it’s possible to have the best of both worlds. In this guide, we’ll teach you how to build WordPress sites using The Drupal Way – flexibility, extensibility, and interoperability of component parts. In WordPress, people also talk about The WordPress Way.
That “way” used to be limited. WordPress was a less flexible product than Drupal. That’s not as true anymore, thanks to Toolset, a package of plugins which can play a major role in how you re-create a complex Drupal site on WordPress.
Meanwhile, WordPress core is still relatively lean. Consider this: while a “vanilla” (no additional modules or custom code) Drupal 7 or Drupal 8 database is comprised of over sixty database tables, a vanilla WordPress site comes with just twelve. Those extra 50 tables are part of what makes The Drupal Way possible; they make Drupal not just a CMS, but an application framework.
But what if you don’t need an application framework? What if that complex Drupal infrastructure introduces more pain than it solves? Here’s the common outcome to that what-if: days, maybe weeks, of frustrating, confusing problem-solving that should take hours at most. Multiple thick, heavy Drupal reference books purchased – and read all the way through.
To build complex WordPress websites with Toolset, however, doesn’t require you to read heavy books. And Toolset doesn’t populate your database with dozens of extra tables; it fits into the native WordPress database architecture. Toolset provides the foundation for flexible, extensible content architectures that Drupal developers are accustomed to. And it integrates all that with key WordPress features: visual, drag-and-drop content editing, media management, and SEO-friendly publishing.
We created this guide to help you evaluate moving from Drupal to WordPress – to the best of both worlds.
To get started, it’s important to understand how one Drupal components “map” to their counterparts in WordPress. In this section we focus on the universal elements that all Drupal developers and sitebuilders use to create websites. We’ll use this section as a map to refer back to when digging into more complex implementation techniques later in this guide. We’ll also introduce the Toolset plugins. As you’ll see, Toolset plugins like Types and Views emulate some of the most attractive features of Drupal.
|Drupal element||WordPress equivalent||Notes on Implementation|
|Users||Users||While the user element has become an “entity” in Drupal 7 and 8, the nature of that entity is almost identical to “Users” element in WordPress.
As in Drupal, in WordPress users can be either administrative users or “end users”, according to their roles and permissions. Also as in Drupal, in WordPress users have their own database table.
A common Drupal-developer objection to WordPress used to be that user records were not customizable. That is, there was no systematic way to add custom fields to them; instead, you had to use a custom-built plugin. Toolset has helped changed that; it provides a visual UI for adding custom fields to users.
|Roles and Permissions||Roles and Permission||As in Drupal, a “default” installation of WordPress comes pre-configured with an array of user roles, each with pre-configured permissions.
The WordPress User Role Editor plugin emulates some of the permissioning functionality that comes with Drupal; you might require the premium (paid) version if building a complex community site with varying end user roles required.
The Toolset Access plugin also provides fine-grained user roles and permissions with respect to the content creation and access..
|Content Types||Custom post types via the Types plugin||Just like in Drupal, a default WordPress install comes with two content types, or “post types”: article (“post”) and page. But with Toolset Types, it’s possible to create custom post types via a visual UI, just as you can create custom content types in Drupal.
As was the case with Drupal 6 and the contrib CCK (Content Construction Kit) module, creating custom posts in WordPress is achieved using a contrib plugin (or by writing custom code). Of the 2 or 3 plugins suited to this purpose, the Toolset Types plugin provides by far the most “Drupal-like” method for creating custom post types in WordPress.
|Fields||Custom fields and fieldsets via the Types plugin||As with Content Types, Drupal sitebuilders will be accustomed to adding custom fields to Drupal Content Types and other entities. As with custom post types, a handful of contrib plugins provide the “custom fields editing” ability, including Advanced Custom Fields, Pods, and the aforementioned Types plugin.
If you’re coming from a Drupal background, the Types plugin will provide the most familiar solution for you.
Like the CCK module that is now a part of Drupal core, the Types plugin provides you the ability to create custom fields, field sets, taxonomies, and post types – all in a unified UI.
|Blocks / Regions||Widgets / Widget Areas||There is no one-to-one equivalency between blocks and widgets, but the closest thing to the classic Drupal block, is the “Text Widget”. Think of it as a classic Drupal block (title and body field) with a preloaded WYSIWYG editor.
Note that widgets by default do not provide the equivalent of “Visibility settings” that come with default Drupal. The Widget Visibility plugin, however, approximates that functionality.
In addition to the “Text Widget”, WordPress comes with a variety of other widget types by default. Also, contrib WordPress plugins also provide custom widgets, as is the case with contrib modules for Drupal providing custom blocks.
For example, the WordPress Views plugin makes it possible to embed a custom view into a widget, which mirrors the popular Drupal Views functionality which allows sitebuilders to create a custom view as a block “display”.
|Menus & Menu items||Menu and menu||Here the functionality between Drupal and WordPress is almost identical.
It’s important to note that in WordPress, first you create content, then you add a content items link to a menu as a menu item.
On other words, in WordPress you don’t create content and menu items at the same time – or have to worry about configuring that functionality as part of the content management workflow.
|Vocabulary||Categories or Tags||While Drupal allows the creation of any kind of “vocabulary” – and obligates sitebuilders to customize them – WordPress provides just two types of vocabularies: categories and tags, and provides one of each by default.
Using Types, you can customize the configuration of WordPress taxonomies in ways that will remind you of Drupal, including setting fine-grained content relationships and hierarchies, as well as controlling editing and display. With the Types plugin, a vocabulary is called a “Taxonomy”.
|A Term||“Term Field” (in Types)||As a Drupal developer, you’ll be familiar with terms (which most of your customers might call “tags”, anyway!). By default, WordPress calls these tags or categories, depending on which type they belong.
Toolset Types, however, uses a naming convention and functionality that closely resembles that of Drupal.
|Views||Toolset Views||Of all the ways that Toolset makes WordPress equivalent in flexibility and power to Drupal, this is the most clearcut example.
Toolset Views is conceptually identical to the functionality provided by Drupal Views but it does so with intuitive UI that provides greater templating and display options.
Let’s be honest, there are some parts of Drupal Views that are so complex, you may as well be writing custom software. And with that complexity becomes even more custom solutions. But Toolset Views allows you to build 98% of them and all of them that matter.
Later in this guide for example, we discuss the creation of a custom search form, or custom, interactive map, using Toolset Views.
|Tokens or Slugs||Shortcodes or slugs||What you might think of as a token in Drupal could be either a slug or a shortcode in WordPress, depending on the context.
Like tokens in Drupal, WordPress shortcodes are used to “tokenize” slugs but also many other types of data, from field values, to widgets, or even blocks of entirely custom code.
If you have ever created custom layouts in Drupal Display Suite using “block fields”, this concept should be intuitive for you.
As you’ll observe from using Toolset, when editing display templates, whether in the context of a view or just a stand-alone content template, “shortcodes” is the convention used to publish the contents of a custom field.
In other contexts, such as storing a URL path value, a WordPress slug correlates with its namesake in Drupal.
|Entities||posts/posts-meta||If you know how Drupal architecture works, you’ll know that as of Drupal 7, pretty much everything in Drupal is technically an entity, including all of the elements in this table. Even users and comments are entities.
Technically, there’s no equivalent to an entity in WordPress.
However, identical outcomes can be achieved by using posts and its closely related posts-meta table.
Those of you who built or developed sites in Drupal 5 or 6 will recall similar approaches based in manipulating nodes and turning them into all sorts of strange things.
So far we’ve just covered the basics – the fundamental building blocks of Drupal sitebuilding.
As you know, however, most Drupal sites use a combination of complex display and visibility tools. We’ll get into Views later in this guide, but for now, we also want to provide a guide for mapping the more advanced features of Drupal to WordPress.
This should get you started in the right direction when it comes to finding WordPress-based solutions for complex website challenges. It should also get you started if you need to perform a migration.
As you know, migrating from one CMS to another is always extremely easy. Ha! We’re just checking to see if you’re an engaged reader.
Migrating data from one software product into another is hardly ever easy, but of all the CMS-to-CMS migrations you might undertake, moving from Drupal to WordPress + Toolset is one of the easiest. That’s because both systems provide extensible, structured data architectures.
We’re providing three simple steps in this guide to get you started in the right direction; you’ll probably need to do more independent research and experimentation – or hire a contractor – to complete your migration to WordPress.
Step 1 in this process is to create your mapping refer to the table above (we recommend creating your migration mapping in a spreadsheet). If for example, your Drupal site contains a custom content type called, “Portfolio items”, use Toolset Types to create Custom post type of the same name. In this way, your mapping document will indicate element-to-element and field-to-field mappings.
One of the trickiest parts to any migration is not mapping element-to-element, but the relationship between those elements. You’ll want to supplement your element/field mapping spreadsheet with some kind of mind map that indicates relationships between content, then find a way to ensure those relationships are captured in your spreadsheet so that they can ultimately be accounted for by whatever migration logic you employ.
Keep in mind that while Drupal allows field-level relationships, and relationships between any kinds of entities, WordPress only provides a system for creating custom relationship between content (not counting the built in relationships between user, taxonomy, and media). So part of your architectural task is to streamline and simplify relationships between elements in your new WordPress website.
Step 2 is to perform sitebuilding using Toolset Types and WordPress configuration to prepare your WordPress site to accept data from Drupal.
In Drupal 8 for example, a page containing images is probably not comprised of only a node whose body field HTML points to static image files; more likely, it’s comprised of both node data (Content Type) and media data (Media Type); there are one or more relationships between these two types of data, and those relationships must be imported into WordPress, along with the relevant nodes and media files. In this case, WordPress works in just the same way as Drupal 8 and even Drupal 7 (sometimes) is configured to work – separating out post data from media data.
Another common challenge that has massive implications for your SEO is mapping URL paths correctly. To be on the safe side, be sure to install the Redirection plugin, which provide almost identical functionality to Drupal’s Redirect module; no WordPress site is complete without Redirection!
Step 3 is to execute your migration. If you haven’t done something like this, keep these points in mind:
- The first step is the export of data from Drupal; the Backup and Migrate module it’s helpful for exporting data (and it’s add-on module can neatly export code and files). With some fine-tuning, it will provide you a export file you can use to import data into WordPress.
- We advise you to use a purpose-built migration plugin to ensure consistency and organization; a strong option, for example, has been the WP All Import plugin and the WP All Import – Toolset Types Add-On because of their explicit support for custom post types and fields, in general, and for Toolset Types, in particular.
- The natural way to perform CMS-to-CMS migrations is super iterative; that’s why it’s important to use tools like the Migrate module and Ultimate CSV Importer; they let you create import/export templates can be run and refined over and over until your migration is just right.
- If your site is complex (multiple content types, views, content templates, etc), plan on writing some custom code. In this case, consider hiring a professional with experience migrating between Drupal and WordPress.
As you wrap up the migration with custom-coding, you’ll move into the rebuilding process; using custom post types, post relationships, custom fields, content templates, and views provided by Toolset will will bring order, flexibility, and speed to this process.
In the next chapter of this guide, we explore some of the ways that advanced Drupal sitebuilding techniques can be replicated in WordPress using Toolset.
If you’ve ever built a Drupal website that was more complex than a brochure site, you’ve probably run into things like Panels, Display Suite, and Paragraphs. If you’re brave enough to try to make Drupal 8 work, you might have even replaced these products with Layout Builder, or attempted to use the “enterprise authoring “Lightning” distribution.
Life as a web developer doesn’t have to be that painful, thanks to the new generation of WordPress display and layout products from Toolset and Automattic.
We’re also aware that in both Drupal and WordPress, there are dozens of ways to use these advanced features in interlocking ways. So these aren’t meant to be solutions for your particular challenges, but hopefully they’ll serve a compass for how you can starting thinking about solving problems in WordPress according to Drupal conventions.
Like Paragraphs for Drupal, Gutenberg is a relatively new addition to WordPress. The latter has been in development long enough to have become a mature product and will soon become part of WordPress Core.
These two powerful products are not quite equivalent, though. Both provide a system for creating and managing content based combining a series of custom blocks. And thanks to the Toolset+Gutenberg integration, these two systems compliment one another.
Gutenberg, however, provides a front-end “edit-in-place” UI; as with Medium, Gutenberg lets you “preview-in-place”.
In WordPress, this type of functionality is known as a page builder; there are dozens of page builders in WordPress (Elementor, Divi, Beaver Builder, WPBakery Page, to name a handful), but Gutenberg is the only one which will become part of WordPress core.
The truth is there’s no exact equivalent to Drupal Panels or Layout Builder in WordPress – but there are dozens of variations on the same concepts: fine-grained and visually intuitive UIs for controlling the layout of any part of your website down to the field level.
In WordPress, these “Layout Builder” equivalents are known as page builders. They provide an actual drag & drop interface for managing and editing layout on the front end. By virtue of its built-in integration with other Toolset functionality (and with Gutenberg) one of the most powerful page builder options is Toolset Layouts.
While technically both Toolset Layouts and Gutenberg could be referred to as page builders, Layouts provides layout templating controlling the entire page, similar to Panels and Layout Builder, whereas Gutenberg is mostly focused on making it easy to create “post content” (in the main content area).
Toolset and Gutenberg fit well together and are an enormous improvement on Panels and Layout Builder.
Part 3: Display Suite » Toolset Content Templates
As with Panels, Display Suite doesn’t have a direct 1-to-1 equivalent in WordPress. The Toolset Types plugin comes with “Content Template” (similar to the content templates of Drupal 6, before Display Suite came on the scene). Content templates in WordPress are easy to use, but unlike Display suite, they don’t provide a 100% UI-driven method for managing the display of fields on a per-post-type basis.
However, Toolset Types “Content Templates” can solve the exact same UX problems that you might be used to solving with Display Suite, whether you’re coming from Drupal 8, Drupal 7, or even Drupal 6.
Note that content templates can be rendered as “custom blocks” and used to render Views output, as well as controlling page-level content. Note that there is no UI equivalent in WordPress to the powerful “field template” convention that comes with Display Suite.
Context may not be as popular in Drupal 8 as in Drupal 7, but a total of 175,000 sites still report using it. One of the reasons it’s becoming “unofficially” deprecated is that it’s painful to maintain over time because it tries to do so much.
If you’ve worked with Drupal long, you’ll know that its most powerful feature (along with Views) has been the ability to create custom fields and content types. Because this feature came into use so long ago (mid-2000s), it’s hard for a Drupal developer to imagine building a website without it.
Meanwhile, WordPress core’s schema supports custom content types and fields, but does not provide a UI with which to define them; nor does it provide or enforce enormous variety of field types, field widgets, and field settings that come with Drupal.
A couple of UI and structural differences between Drupal custom fields and custom fields in WordPress as implemented by Types:
- Whereas in Drupal, fields are standalone entities, in Types, custom fields always belong to a fieldset (even if it’s a fieldset of just one field).
- Just as a field in Drupal can be applied to one or more custom Content Types (or other entities), a Types fieldset can be associated with one or more custom Post Types. However, in WordPress you cannot create separate instances of a given custom field for each of its entity associations. So if your field label says, “Bio” when applied to, say, a Staff Profile custom post type, it must also say “Bio” when applied to, say, an Author custom post type.
- Unlike in Drupal, there is no differentiation between a custom field’s data type (e.g. Boolean) and its “widget”, which is how that field type is expressed (checklist, select, radio) in the UI. In Toolset, some custom fields can only be expressed in the UI in one way.
- As mentioned previously, fields themselves are not themeable through the UI; they are of course themeable with custom code.
Is one approach better than the other? You will have to decide.
We think that it depends on your perspective; obviously, Drupal is much more flexible when it comes to custom fields, in particular. But that flexibility requires much more time to setup, configure, and manage; there is also a performance cost (one of the reasons Drupal 7 is slower than Drupal 6 was that CCK was moved into core).
We know this though: like a modern-day CCK module for WordPress, Types allows you to design custom content types, custom fields, and custom taxonomy – in a systematic, UI-driven fashion. As in Drupal, content architecture become something controlled through the WordPress admin, not through managing and editing dozens of custom PHP files.
Toolset does all this using standard WordPress tables, making it easier for other themes and other plugins to integrate with it – just look at all the page builders and themes that support Types.
Long-time Drupal developers know that to create a powerful, customized content architecture, you also must be able to create a variety of field types. Toolset makes that possible in WordPress; here’s a sampling of the field types available:
- Embedded Media
It’s also possible, as in Drupal, to create calculated fields and make them a part of the architecture of any custom post type or content template.
Part 6: Relationships (Node/EntityReference) » Post Relationships
If you’re a Drupal developer, you’ll be well accustomed to the ability to create a variety of highly customizable relationships, probably using EntityReference, in Drupal 7 or its successor code in Drupal 8 core.
We love that you can use Entity Reference to relate any entity type (content type, blocks, comment, user, term, media, date, etc) with any other, in unilateral, bilateral, one-to-many, or many-to-many ways.
One the WordPress side, we’ve seen a number of hard-baked related content display plugins crop up, but until Toolset Types, there were few truly data-driven solutions to relating content across post types in either one to many, one to one, or many to many configurations.
The exception would be Pods, which is similar to Toolset Types but less full-featured (especially if you’re coming from Drupal); Pods creates many-to-many post relationships by creating a new relationship table in the WordPress database. Unfortunately, Pods offers no Views solution, and one of the most powerful applications of Post Relationships is its ability to create views comprised of multiple content types based on relationships; a great way to forge custom “Related content” blocks.
As with other building blocks of scalability and flexibility (custom fields, taxonomies) Types doesn’t replicate all of the complexities of Drupal. Instead it identifies the fundamental need (many-to-many) and provides that part of its product.
Part 7: Media, Image styles, etc » Media, Content Templates, Views
There is a WordPress plugin called Enhanced Media Library which approximates the functionality offered by Image Styles (in core since Drupal 7), if the primary concern is dynamically resizing images on upload to the various dimensions your design calls for.
Many contrib Drupal modules extending image styles (e.g. Responsive Image Styles) are baked right into WordPress core, including Media. With the possible exception of its WYSIWYG editor, there’s no part of WordPress that is as superior to Drupal as Media. Unlike the Media module in Drupal 7 (it’s “sort of” in Drupal 8 core, but not really finished yet), Media is not a plugin; it has been tightly woven into WordPress core for many years – and it shows.
To replicate Media in WordPress in Drupal 7 or 8 would require dozens of modules and probably years worth of custom code. So there really isn’t a direct parallel, but it’s important to know a couple of things, with respect to migration particulars:
- Assuming media files exist as entities in your Drupal instance, it’s possible to migrate them to WordPress so that they come under the control of its Media management system and retain content relationships
- You will be spending far less (zero) hours trying to get media to work on your website once it’s in WordPress
- You can use Toolset Views and Content Templates to customize the display size of images, in much the same way as you combine Image styles and Views in Drupal. This allows, for example, a listing of blog posts that use a “Featured image” (primary image associated with the blog content type) to render a thumbnail in each row of the view. It also allows for the creation of sliders, galleries, and slideshows, just like you may be accustomed to building using Drupal Views and the relevant plugins (in fact, Toolset Views has built-in support for a slider/slideshow display).
Toolset Views and Types provide an inline element which it labels a “custom block”, but it’s not as flexible as Drupal’s custom block, which is more of a concept than a discrete piece of functionality. The concept of a custom block in Drupal is that a “Block Type” (just like a Content Type) be “fieldable”. In other words, you can assign custom fields to it – and other entity level configuration. This concept has yielded Panes, Mini Panel, Beans, Field Collections, and any number of custom blocks provided by custom code).
The Toolset Block can achieve the same outcome of custom blocks; using the “Content Template” and rendering it as a widget, ie, a block, any combination of custom fields can be published to any part of a page in an inline block. However, this isn’t yet a custom “Block Type” in the Drupal sense in that you can create the structural element once and then use it to build any number of block-level content item.
You may have attempted to create a multilingual Drupal 7 site using the Internationalization project’s modules, or in Drupal 8 now that Internationalization is part of core.
If so, you’ll find the functionality provided by the WPML suite of WordPress plugins very familiar, just as if not more powerful, and much easier to use.
Like Internationalization, WPML provides language handling, extremely fine-grained interface translation, content translation, and configuration. And just as Internationalization integrates (in theory) with Drupal content architecture and Views, WPML also integrates with the content architecture provided by WordPress Types and Views.
Disclaimer: Toolset’s parent company, OnTheGoSystems, also owns WPML. In fact, many of the same engineers and designers built these two products from scratch. You will also find ample documentation on the Toolset website demonstrating how to use WPML to fully translate and maintain a complex WordPress website with multiple custom post types, custom fields, views, and custom content templates and block.
In Drupal, using Views to build highly customized content searches using “exposed filters” is such a powerful feature that it’s hard to imagine using any CMS not offering that type of solution. In Drupal, the feature went from being a “happy accident”, designed to allow end users to customize sorting, to being the most popular sitebuilding solution for advanced searches.
In Toolset Views, the “exposed filter” approach, which we call “parametric searches”, was purposefully designed into our product. Custom content searches are created using the “Custom Search Settings” feature that comes with every view.
This video tells you exactly how to do it:
If you’re more of a hands-on learner, see the actual demo site referenced in this video right now; you can view either the front-end or the backend, and see for yourself how it was built.
If you’re a Drupal developer, you may have fought many long and painful battles mapping the output of view to a map display, probably a Google map, probably using the GMap module (which is still not production-ready for Drupal 8, as of October 2018). Some mapping projects in Drupal take weeks to complete (or longer), especially when it comes to customizing markers, clusters, info popups, and map styling – or when it comes to customizing map controls.
For that reason, one of the most delightful discoveries when migrating from Drupal to WordPress + Toolset is how easy it can be to create interactive maps populated with Views data. Maps like these can be built and deployed in an hour or two, not weeks.
Another benefit that will make your customers love you is how much easier it is for them to easily set the location for a content item. With Toolset Map, your admin user simply starts typing into the address field and selects her desired location. Just like using Google Maps itself, all she needs to do is starting typing.
There are dozens of real-world Toolset showcases showing how WordPress can be mapped to Google Maps following this method. As we mentioned earlier in this guide, Toolset also provides sample demo sites that illustrate how to tackle sitebuilding challenges like these that you’ll know from Drupal.
The real estate demo site mentioned in the previous guide demonstrates exactly how to build an interactive map using Google Maps and Toolset.
All Toolset demo sites’ codebases are available for download, so you can learn from them or use them as a starting point for your own project.
Special bonus if you’re a Microsoft/Azure developer: Toolset Maps also supports Azure Maps integration.
One thing that Drupal has always done superbly well is provide the ability to display content relationships in a way that’s helpful to users. Thanks to Toolset, every type of related content display you can imagine being possible with Drupal is also possible with Toolset.
With the relatively recent release of many-to-many relationships in Toolset Types, it’s now possible to create a WordPress content architecture that is just as flexible as one in Drupal.
This video provides an excellent overview:
One of the first things a Drupal developer will ask of WordPress is, “how do I let my client manually rearrange the results of a view on her site?” (Or anywhere else). In Drupal, the presentation logic of a view is entirely separate and extensible from the query logic thereof. Which makes it easy to create a custom query and – using entityqueue (or its predecessor, nodequeue), let the client manually sort how that query is ordered.
So how do you do this in WordPress? By combining Post Types Order and Toolset Views. While there isn’t a purpose-built integration as between EntityQueue and Drupal Views, the effect is the same. Use Post Types Order to manually sort custom posts of a given type, then use create a Toolset View querying that same post type.
The key is to tell the view to sort by “Menu Order”, allowing your view to import whatever manual order has been set using Post Types Order
Et voila – the client now has drag-n-drop, manual control over how content is prioritized and displayed to ender users.
This chapter gives you a glimpse into what’s possible and hopefully demonstrates the primary point: most advanced Drupal sitebuilding techniques are possible in WordPress too. For more ideas, documentation, real world examples, and demo sites, visit the Toolset website.
Chapter 5 – Authoring and Managing Custom Code in Drupal vs WordPress: More Similarities than Differences
If you have practiced and are accustomed to the “Drupal Mindset”, or the “Drupal Way”, of writing and organizing code, you can transfer those exact same best practices to WordPress development.
Minimize custom coding (your own or contrib), load CSS and JS resources programmatically, use parent-child themes, build in extensibility, make on-page output completely themeable, separate logic and presentation layers, etc. Sound familiar?
It should. After all, WordPress has many similarities with Drupal – both sit on top of a LAMP stack and both are designed to be extensible and “themeable” by adding custom code where it is needed, rather than by rewriting the core software itself.
Drupal modules are WordPress plugins
The code management itself is also very similar. As with Drupal modules, WordPress plugins are created as a folder, sometimes with multiple subfolders, and added to the code base in a parent folder called “plugins”.
As in the Drupal development community, tools like Git, Github, and product-specific shell clients (Drush == WP-Cli) are common tools of the trade. As is dev-staging-production deployment environment and DevOps methodologies that go with it.
The custom code you may know as a module in Drupal is exactly equivalent to a plugin in WordPress.
Like Drupal CCK and Views, Types, Views, and the rest of the Ttoolset suite of plugins dramatically reduce the need for custom code. As we know, however, there will always be a need for it.
Commenting and documentation conventions are similar as well – as is the case with Drupal.org being the primary repository of module and theme projects, WordPress plugin projects are – usually – hosted on WordPress.org. Partly because WordPress is a simpler platform, it offers centralized and extremely useful document.
Both platforms use a function-oriented programming approach, written in custom PHP against the CMS API. Hooks in Drupal are fairly equivalent to WordPress hooks. Should you find it necessary to migrate functionality from Drupal to WordPress in the form of newly written custom code, you will find the process very familiar and the learning curve considerably lighter.
You may be surprised to learn, however, that there is in fact a greater volume of contrib code in WordPress than in Drupal, so that you can find sitebuilding solutions.
Themes are themes
Ironically, WordPress as in Drupal, it’s possible to break with best practices by writing “logic layer” code into theme theme layer, with the most common approach being to insert code in the theme file called functions.php, which is exactly equivalent in usage (and mis-usage!) to template.php in a Drupal theme.
Theming is similar in most other ways, as well. Maybe you’re coming from Drupal 8 and prefer Twig, or another theming engine, so that you don’t have to learn to theme in raw PHP. Like Drupal, WordPress will let you use whatever template engine you prefer working with. And if you are used to experimenting with a new CSS framework every two weeks, you’ll feel right at home moving from Drupal to WordPress.
With that said, one of the stark differences you’ll find migrating to WordPress is the sheer volume of contrib themes, some of which (DIVI, Beaver Builder, etc ) contain their own “page builder” built right in, or bundled with plugins. Toolset provides its own page builder but also supports the use of several others.
However, many of these themes may not be worth wasting your research time on if you are used to the rigorous standards that Drupal themes (e.g. Zen, Omega) abide by. For a good frame of reference, consider evaluating the themes recommended by Toolset.
WordPress themes, libraries, resources, and frameworks that support responsive web design and development are roughly equivalent to Drupal, although there are more options to choose from; all major themes (and image handling functionality) are mobile-friendly.
At a high level, the process of building a view in WordPress Toolset is identical to building a view in Drupal. It you are accustomed to using Drupal Views, you will feel right at home with the WordPress Views plugin.
The process looks like this:
- Content architecture is created (using Types)
- Content is published against that architecture
- A view is created which both queries that content and displays it dynamically
That being said, the WordPress Views is written from scratch and has no relationship to the code itself that comprises Drupal. In keeping with the spirit of WordPress, it trades in some of the extreme complexities of Drupal views in the name of usability and performance.
By default, Drupal Views outputs a “div-itis” (and “class-itis”) quantity of HTML markup, as in the example below, where you see a view embedded into a Panels pane:
That’s just wrapper code – it doesn’t include any content or code stored in the database. Of course, you can “easily” theme Drupal views to generate little or no wrapper code. I put “easily” in quotes because although the coding itself may be trivial, the strict DevOps procedures in most Drupal development environments makes small theming code changes tedious and time-consuming.
Toolset Views, on the other hand, allows you to theme outputs directly in Views editor, as in the screenshot below:
Does this store markup in the database? Yes. And this is where you start to evolve from the Drupal Way to the WordPress way – which consists of a compromise between elegant code and elegant solutions.
For example, as you can see above, WordPress Views allows inline CSS and JS code to be stored alongside the view in the database, offering dramatic improvements in performance or level-of-effort over the alternative approach, which is to either:
- dump those customizations into enormous external files (slower performance)
- carefully maintain an elaborate library of hundreds of external CSS and JS files (massive level of effort).
As you can also see from the screenshot, WordPress Views allows you to customize the output of a view using tokens (called “shortcodes”, in WordPress). If you are familiar with the “Rewrite the output of this field” functionality of Drupal Views, WordPress Views works in much the same way, allowing the rendered code to be customized in infinite ways according to the particular needs of the site.
Chapter 7 – Replicate Your Drupal Forms for Front-End Content Creation and User Registration: Toolset Forms
If you have ever provided anonymous-user access to a Drupal node form, to allow the public the ability to create content, then you will instantly understand the purpose of Toolset Forms plugin.
Now imagine being able to create these forms without having to mess with hook_form_alter or write any other custom code. This is what Forms was built for. As such, it handles many of the famously painful tasks that you may have tried to custom code in Drupal, such as:
- Whether the form creates new content or updates an existing content item
- Field level customization (hiding some fields, like a custom “Reviewed by admin” checkbox, from the public user
- Layout and display of the form and the fields it includes
- Notification emails generated when the form is submitted
- How many times the same user can submit a form
Of course, forms work by building on Types, so as in Drupal, you can control which types of content are generated by them. Another Drupal-like feature of Toolset forms is that they can be used not just to create Content Type (Post Type) content, but also to register users.
You may have noticed in your research that the user registration of user management in default WordPress doesn’t allow you to “field” (assign fields to) user creation forms, a popular problem that some websites need to solve.
Here again, Toolset forms are very useful, because they can create either content or users with (thanks again to Types) custom fields associated with them, as you’ll see from this detailed guide on designing custom user forms.
The Toolset Forms plugin works closely with the Access plugin, which we discuss next.
Drupal developers are accustomed to demandingly complex requirements around content access, permissions, and even custom workflows – demands like those have traditionally been impossible to build in WordPress without significant custom coding, or without assembling a broad hodgepodge of permissions and content access plugins.
Toolset gives WordPress developers the ability to meet complex content access and workflow demands with Access, which integrates seamlessly with Types and other Toolset plugins. But it does so without requiring you to manage and maintain thousands of permissions.
If you are familiar with Content Access or content access modules in Drupal, you will recognize many of the features in Access, including the ability to override per-content-type defaults on an individual content item.
But where WordPress Access excels is in replicating the role management permissions and fine-tuning that comes built into Drupal core, where read, edit, and delete permissions can be customized against every type of content. (It doesn’t provide view own, edit own, or delete own, however – that functionality can be achieved in other ways).
Caption: A refreshingly simplified permissions matrix provided by Toolset Access
If you’re familiar with the field-level permission customizations that Drupal’s Display Suite module helped popularize, you’ll greatly appreciate the way that Access has neatly replicated all of this functionality by making it possible to set access control in-page on a field by field level.
Consider this fact: While TinyMCE has been a part of WordPress core for many years now, Drupal, in the name of extensibility, has still not made a WYSIWYG text editor part of core. The Lightning distribution for Drupal 8 tries to change that, but that initiative and Drupal as a whole is 5 to 10 years behind WordPress when it comes to content publishing, admin UX, SEO, and media management.
Caption: The WordPress WYSIWYG editor comes built-in and works flawlessly – as does lots of other functionality that Drupal developers spend days or weeks installing, configuring, fine-tuning, and troubleshooting
This is one of the many reasons that content publishing in WordPress in a far more pleasant, user-friendly, and frankly, efficient activity than in Drupal. The workload and “quality-of-workload” undergoes dramatic improvements just from switching from Drupal to WordPress. Here are some of the reasons why:
- The Save/Publish buttons are always visible in the upper right of content creation/edit pages
- Because the text editor is part of core, it always works – and works well (and it can still be customized)
- The width of the content editor itself always remains at a user-friendly 600 pixels, rather than expanding to occupy the entire page as often happens in Drupal
- The distraction-free mode hides the rest of the admin while you write content
- The publishing settings easily allow publishers to schedule the go-live publication date of content (which Drupal tries to replicate with the clunky, options-bloated Scheduler module)
- What you may know as the LinkIt module in Drupal is built right into every WordPress text editor; it just works, right out of the box, and in a much more intuitive and user friendly way.
- The Media management makes it remarkably easy to integrate images, documents, and videos into content (Drupal developers still find themselves writing CSS code to solve the problem of making text wrap images, a problem WordPress solved with a few buttons a decade ago)
Speaking of Media management, this is, along with the text editor, one of the most mature and highly perfected parts of the WordPress CMS. Have you ever tried to implement the Image crop module in Drupal – and get it working with Image styles, display suite, the Media module, and so on and so forth?
Like many aspects of media management, cropping functionality comes stock with WordPress and works perfectly. That’s one of the many ways in which a tightly integrated and non-biggy Media management system can transform the efficacy of work spent towards content publishing.
Meanwhile, rather than resting on its laurels, WordPress is pushing ahead with Gutenberg, which provides users with a Medium-like drag & drop, edit-in-place interface for creating richer, more customized post content. The Gutenberg editor is somewhere in between Drupal paragraphs, Medium, and a WordPress page-builder.
Recognizing how well-built and well-supported the Gutenberg editor is, Toolset is committed to creating value for its users by integrating as tightly as possible with Gutenberg.
SEO and Content Marketing in WordPress
One of the side benefits of a great publishing experience, perfect media management, and Gutenberg, will be better, more engaging content, which will translate to even better SEO. WordPress core is by itself a highly SEO-optimized CMS. Just by installing basic, vanilla WordPress, in fact, you’ll benefit from better technical SEO than is available from Drupal (or other CMS products), no matter what additional modules you might install.
That said, we’d like to highlight two 3rd-party WordPress plugins that elevate what’s possible with SEO, All-in-One SEO and YoastSEO. The latter especially is useful for integrating web-based content marketing with social media, because of its ability to repurpose post content for consumption on Facebook and Twitter.
It’s also worth noting that by creating more dynamic and customized content, Toolset-built WordPress sites are more likely to field evergreen content and long-form content, both of which are understood to be increasingly important factors in search engine content ranking algorithms. WordPress isn’t just the best SEO CMS, it might be the best content marketing CMS.
Just a quick note on admin UX. On the one hand, WordPress out of the box offers a great admin experience. On the other hand, Drupal’s admin is much more flexible and scalable – one of the things that makes Drupal an application framework in addition to a CMS.
To help bridge that gap, we recommend a terrific plugin WordPress called Admin Columns (which integrates with Toolset custom post types and custom fields).
Here they are some of the most common questions Drupal developers have about WordPress:
- What about Feature (Drupal 7) or Configuration Management (Drupal 8)?
- What about Git?
- What about Drush?
- What about managing and deploying code in multiple environments?
And here’s the general answer: whatever development and deployment you can design for a Drupal site, you can design just as robust an environment for a WordPress.
On a more specific level, you can use many of the same tools (except instead of Drush, you’d use WP-Cli). WordPress even has a code management product called WordPress Configuration Management (WP-CFM).
Just ask specialized web hosts like Pantheon; they only host Drupal and WordPress – and they provide a web-based DevOps platform that is identical for either CMS.
A word about caching, performance, and security.
For many years, caching plugins like WP Super Cache or Total Cache have been considered attractive options for WordPress sites. They do seem to make the site go faster, Coming from the Drupal perspective, however, you’ll probably view solutions like these as extremely dated and inefficient. For one thing, letting any file be written to any part of a production Drupal website is just “Not Done” – for security reasons, and also to maintain “keep it in code” configuration management best practices.
For these and for pure performance reasons, we understand that Drupal developers may want object and page caching to be handled by database and web servers (and by CDN) – not by custom code stored in a CMS. We support hosting and hosted DevOps-as-a-service providers who are committed to providing “Drupal-quality hosting environments” to WordPress developers and agencies.
In the final analysis, WordPress site of equal scope and complexity tend to be about 40% as expensive to build as their counterparts in Drupal – and 10% as expensive to maintain over time. We’d like to get right down to specifics however, and break down pricing costs associated with migrating a fairly complex Drupal site into WordPress. Without these plugins, replicating your Drupal website in WordPress will be extremely difficult.
The prices listed below are for developers and agencies who build many sites for their clients; single-site licenses are considerably less expensive.
|Recommended Paid Product||Approximate Drupal equivalent||Cost/year one||Cost/ year*||Consulting fees – SMB site in WordPress||Consulting fees – SMB site in Drupal|
|Toolset||CCK, Views + add-ons, Gmaps, Content Access, Field Permissions, Display Suite, Form Builder, Chaos Tools||$149||$111|
|Ultimate CSV Importer||Migrate||$100||$100|
|Premium theme (e.g. Avada, Astra, OceanWP, GenratePress)||Zen, Omega, etc||$60 (average)||$60|
|Premium page builder (e.g. Elementor Pro)||n/a||$100 (average)||$100|
|Admin Columns||Core admin + Views||$200||$120|
|Grand Total||WordPress: $20,850||Drupal:
* Most premium plugins are discounted after year one; in no case are you unable to use premium themes or plugins are their support and upgrade license expires; WordPress is open source, so there is no such thing as a usage license.
** Doesn’t include WPML
*** YoastSEO for Drupal 7 is nothing like the WordPress product
We understand that In Drupal, asking for money for themes and modules is still considered taboo. Drupal Mollum is a freemium product, like Akismet, but that’s a service, not just code. We also understand that $850 dollars is a rounding error when you consider the fees charged by Drupal agencies (and unfortunately, it’s hard for such agencies to realize a profit on those fees because of the extreme level of effort required to make Drupal work).
While we have enormous respect and admiration for the Drupal product and its community, we do believe strongly that WordPress offers a vastly better return on investment for developers, agencies, and their clients. We think that is in part down to the fact that the freemium model is accepted business practice in the WordPress community.
If there were no freemiums, WordPress wouldn’t be the valuable CMS platform that it is today. The plugins and themes listed above would be nothing like what they have become. There is a reason Drupal still doesn’t have a single drag & drop page builder that works, while WordPress has over a dozen. Perhaps the dynamic, freemium WordPress ecosystem, that has created products like Toolset, is part of why you are considering a move to WordPress.
When you purchase commercial themes and plugins, you spend money, but you also save money. Any purchase entitles you to support, which can save you precious time and valuable money.
This is true of the Toolset suite of plugins too. At the premium $300/$225 price point (we have lower prices for individual sites) WordPress developers and agencies get:
- Unlimited sites – you can use Toolset plugins on all your sites as well as on sites you build for your clients.
- Automatic updates from the WordPress admin – saves you time downloading updates and installing them manually.
- Expert support – our support team is comprised entirely of developers. We provide support five days per week, 19 hours per day. When you are working, we are too.
- WordPress ecosystem integration – like Drupal Views or Display Suite, Toolset is broadly supported by other major WordPress projects – including all of the themes, page builders, and plugins listed in the table above.
The Toolset team includes developers, supporters, testers and designers from all over the world who are working round the clock on building and supporting Toolset plugins. We want you and your clients to have all the power and flexibility of Drupal with the usability and marketing power of WordPress.
Thinking about moving to WordPress and need some help? Ask us about Toolset.