Drupal and WordPress - Comparison, Analogies, Similarities, Differences

The purpose of this publication is to compare the capabilities of two popular CMS - Drupal 7 and WordPress (latest version 4.6 at the moment). The goal was to consider the CMS from the point of view of the programmer and compare the main APIs of both systems, draw analogies, draw conclusions about which system is best suited for which tasks. The publication does not claim to be a complete exposition of all the capabilities of the CMS, and the author will be grateful for the corrections and additions.

Architecture


Both frameworks are built on a similar architecture: core + theme + add-ons. The core (engine) provides basic functionality. Add-ons are called modules in Drupal, and plug-ins in WP. Both modules and plugins require minimal effort to create (pairs of files with a certain structure) and do not differ in essence, this is some named piece of php code with possible related styles and JS scripts that can be independently distributed and installed on the system. Themes are designed to provide a Look & Feel site, consist of page templates and supporting code, and are also distributed and installed separately. We will consider the details later.

Customization and redefinition of the core functionality of the kernel and standard components occurs using the hook system, which also has a similar purpose in these systems. Thus, the overall architecture seems very similar.

Operational Features


WordPress has long grown out of its original purpose of being a blog engine. At the moment, it is declared that its use is practically unlimited. Drupal, sometimes defined as CMF (content management framework), was originally thought to be universal and suitable for all types of sites. Installation of both systems takes a short time (5-10 min), does not require any special computer power and is free. After installation, in both cases, a site with a default theme ready for configuration and use is obtained.

WP uses only MySQL as a database; Drupal provides a set of variants of popular databases (MS-SQL, Oracle, SQLite, PostgreSQL). After the basic installation, WP creates 11 database tables, Drupal - more than a hundred (at first glance it scares, at the second too).

Both systems have an administrative menu. Drupal clearly defines its own theme for it; in WP, the admin theme is formally always the same theme, but it is configured using plugins. In general, the WP admin panel seems more ready to be used by the end user and easier to understand than the Drupal admin panel, which seems to be designed for a professional administrator or programmer (but this is only a topic for the admin panel).

WP plugins are conveniently searched and installed right in the admin panel, usually have a clear description and all sorts of hints for the user (such as “hello, I'm installed, click here”). Drupal does not have a built-in search engine for modules, the module is searched manually on drupal.org and installed by its URL, either by direct copying to the modules directory (which is also possible for WP), or using the console applicationdrush (WP also has a WP-CLI console application , but I think it is much less popular).

The updates of both systems are quite similar, the check for updates is automated, the updates themselves are downloaded and installed with the click of a button. The major difference is the major version system, where WP adheres to a single line policy with full backward compatibility (and your site updates to the latest version), while, for example, Drupal 7 and Drupal 8 are completely different and incompatible product lines . Migrating a site from Drupal 7 to Drupal 8 may require significant programmer efforts.

Due to the fact that updates for both systems come systematically, it is not recommended either to “crack the kernel”, i.e. modify kernel files. Most likely it will not be necessary to do this, and if it seems that this is the only way, then most likely either the CMS was chosen inadequately to the task (which is less common), or (and most likely) not all system configuration options have been studied yet.

More about modules and plugins


A Drupal module is created by defining the module_name.module and module_name.info files, where the former can be completely empty, and the latter should contain only minimal information of a certain structure. After these files appear in the module folder (usually in a separate folder, but not required), Drupal recognizes the module and displays it in the admin menu panel. To start work, the module must be activated. Custom (i.e., created by the programmer for this project) modules are no different from contributing (standard, located in the Drupal database), the latter in practice sometimes undergo refinement for the needs of a particular project.

It is believed that the module should contain some logically isolated piece of functionality, i.e. the breakdown of the more complex parts of the functionality into separate modules is welcome ("see something separate / separable - write a module"). A professional Drupal site, especially using large subsystems such as Drupal Commerce (consisting of many interconnected modules), can contain several hundred contributor and custom modules.

To determine the WP plugin, minimal effort is also required, namely just one PHP file with a comment in the header (only one line with the name of the plugin is required). Like the module, the plugin needs to be activated in the admin panel to get started. Since, in fact, there is nowhere to write code (the functions.php theme file is clearly not intended to contain all the functionality, and it is not customary to fill in templates with business logic code), the application is also organized using breakdown into plugins.

WordPress is often criticized for the fact that there are a lot of plugins, but no one guarantees that with the connection of a specific plugin your site will not form a security hole. In Drupal, monitoring the status of the modules by the public seems more attentive, although it is not very clear whether this can really prevent security problems or only respond quickly to a disaster that has already happened. In general, the WP plugin market gives the impression of being more “free” and versatile (and unsafe), and the set of Drupal modules gives the impression of being more professionally tested. Although it may be just an impression.

Hooks


The cornerstone of the work of themes, modules and plugins is the ability (and necessity) to use hooks. A hook (hook) is a place in the kernel or another module / plugin when it is possible to change the default operation of the code. There are a lot of hooks in both systems (the basic ones in Drupal are about 350, in WP - about 250).

Drupal uses an interesting and distinctive naming system to hook hooks that does not require a separate explicit connection. For example, the my_module_menu function in the my_module module will automatically serve as a hook for defining routes (the template name is “hook_menu”). In WP, to determine a hook (more precisely, a hook / action or filter action, which is essentially the same thing), you need to explicitly call the add_action or add_filter function. Considerations for this may be different. On the one hand, defining a function and then calling add_action () may seem like a slightly redundant syntax. On the other hand, there are the following nuances:

  • add_action () somewhat reduces the amount of “magic” in the code, which does not contribute to the readability of the code;
  • add_action () allows a single plugin to add as many handlers as needed, while the function my_module_menu () can be only one in a given module;
  • there is a remove_action () function with which you can cancel the hook of another module, but there is no such mechanism in Drupal.

Create theme


The Drupal theme appears after creating themename.info file in the sites / all / themes folder. An Info file is a simple text file that defines general information about a topic: title, author, regions on a page, JS and CSS include files, etc. After creating or installing (installing a theme is similar to installing a module), the theme must be activated in the admin panel and the main one selected.

A WP theme is defined by two files: the main one is style.css, which sets the name of the theme (and of course, usually styles) and the additional one, the basic index.php template. The WP theme definition structure dates back to the days when WP was a simple blogging engine, the only template was index.php, and style.css itself contained styles. Since then, there have been more templates, but the definition of the topic has remained the same. Making style.css mandatory and the main theme file may not seem elegant, but there is backward compatibility.

Both systems support the creation of subsidiaries, which simplifies life when you work with very complex ready-made themes, customizing them for yourself. In the case of a child theme, only * .info and style.css files remain mandatory.

The theme in Drupal is accompanied by the template.php file, where the theme settings are made, and the functionality specific to the whole theme is determined. WP has a similar functions.php file. When creating your own WP theme, functions.php usually places code for connecting and disconnecting typical features of the theme (add_theme_support and remove_theme_support functions), JS scripts, styles, and sidebars are registered. In Drupal, such things are usually done with the mouse in the admin panel, and functions like template_process / template_preprocess that override the behavior of templates are placed in template.php.

Ready themes and their settings


In terms of ready-made themes and their settings, WP is significantly ahead of Drupal. Free (and non-free) access has a very wide range of topics for every taste and with a classic and modern design, ordinary, responsive and generally whatever. In addition, WP provides a separate API (customizer) for defining theme settings, and theme creators try to make them as customizable as possible. WP theme is sometimes a separate product with regular updates and premium functionality. A separate feature when setting up a WP theme is the preview function.

Drupal doesn’t focus on customizing themes that way. For a regular theme in the admin panel, you can only change the color scheme and the main parameters of the site - name, icon, etc. In a typical way, a programmer creating his website will take some standard minimalist theme (for example,Stark ), and on its base to build your layout. Another approach would be to use more advanced products, such as the Zen theme using responsive design, Sass, and Gulp.

HTTP Request Processing


In web applications, it all starts with a query string. Using the query string, both systems determine how to proceed. Drupal creates a path router that includes both standard paths (such as “node / 1234”, “user / 123” or “taxonomy / term / 123”) and custom paths (defined using hook_menu). After analyzing the query string, the desired path is found in the router and delivery_callback, the page rendering function, is obtained from the additional information attached to the path. There are two standard delivery callbacks - the default drupal_deliver_html_page and the ajax ajax_deliver, plus you can set your own when defining the path.

In WP, the query string is parsed based on the query string and a global $ wp_query object of the WP_Query class is created. Next, set the conditional tags ( conditional tags- is_page, is_single, is_category, is_archive, etc), which describe what the request is and what is actually being requested (specific type of posts, posts from the archive or from a category, etc.). The global $ wp_query object and conditional tags are further used in templates and user code. Based on the conditional tags, there is also a further selection of a template file for rendering.

In general, the approach in Drupal is more systematic and solid (the router is a single repository of paths and handlers), the approach in WP is simpler, and apparently evolved (for example, by adding new conditional tags), but nevertheless it is quite flexible and customizable. The WP_Query class seems to be a very convenient mechanism for simple work with additional queries, and the pre_get_posts hook allows you to modify the main query.

Patterns


The Drupal template hierarchy has the following structure. The lowest level template is html.tpl.php, which contains the main markup of the page with the doctype tag. It is configured in relatively rare cases, because there are higher-level mechanisms for adding CSS / JS (even Google Analytics code is implemented by a separate module ). Next comes page.tpl.php, inserted into html.tpl.php in the form of the variable $ page and determining the overall structure of the page. The page.tpl.php defines the regions specified in the topic info-file. There are no explicit concepts of header and footer in Drupal, logically they are “spread out” between html and page templates.

The system of regions in the subject is very convenient and flexible, you can define your own templates for regions (region.tpl.php template), there can be as many regions as you like, and by default a good basic set is provided. There is a variable $ content in the page template, through which the actual content gets into the template. There is a node.tpl.php template for outputting content that is represented in Drupal by entities of type node (node).

For all of these basic templates, there are default versions, i.e. the theme is able to live completely without templates in its own folder, in this case templates of the same name from the kernel and kernel modules (for example, from the system module) will be picked up. To override, just find and copy the template to your theme folder. In addition to standard templates, modules can define their own, as, for example, is done in the Views module. Each template is supplied with a number of predefined variables (described in detail in the comments in the template), which can be changed and supplemented in functions like process_page / preprocess_page.

In general, the hierarchy of Drupal theme templates has the character of “nesting”, field is embedded in node, node is embedded in page, page in html. Also, replacing one template with another occurs during specialization (when, for example, node-15.tpl.php is used instead of node.tpl.php).

The WP template hierarchy is different. All basic templates here are “full-sized”, i.e. contain doctype. Which template is applied depends on the current request and conditional tags. The tags determine which template to use. If, for example, a page is requested (is_page () == true), then the system uses page.php, if the request contains a category (is_category), then category.php, if there is a separate blog entry, then single.php is used, etc. . The centerpiece is the index.php template, which is used to process requests for which no more specific template was found. Once upon a time, this template was unique in WP, and this central place remained so behind it.

There are no default templates in WP, but index.php (as an “omnivorous” template) most often has a typical look with a WP loop ( loop) WordPress usually defines header.php and footer.php templates explicitly. These are the “raw” parts of html (opening tags in header.php, and closing tags in footer.php). The functions get_header () and get_footer () are provided for their insertion (therefore, files should be called that way). It seems like primitive, but simple and understandable. Sidebars correspond to Drupal regions in WP, they have their own sidebar-name.php templates and dynamic_sidebar () functions for using them (about sidebars and widgets a bit later).

In addition to typical templates in WP, you can create named custom templates, which can then be applied to individual pages (when creating pages, the option to use templates appears if at least one exists).

To display the main page, there is not quite (as it seemed to me) obvious logic based on several display options: a static page, a standard blog view, or a custom template. Details can be found in the WP code in the topic development section.

As you can see, the patterns in Drupal are more systematic and easy to learn, while in WP they are probably more flexible and practical. Both the template hierarchy has to be studied in order to be applied efficiently. Both there and there is a choice and the necessary flexibility to achieve the desired result.

Regions and sidebars


So, the regions are defined in the Drupal info-file of the topic, the placement of regions on the page is determined in the page.tpl.php file, and the markup of specific regions is determined in the region - name.tpl.php templates. This gives a clear structure and great flexibility in building the theme. After defining the regions, they are available in the admin panel to place blocks (block). Blocks are visually isolated pieces of output on pages that can easily be moved between regions (for example, with the mouse in the admin panel). In essence, regions are created to accommodate blocks and main content. A block can be standard (for example, “made by Drupal”), it can be defined in any module using hooks (hook_block_info), or it can be created right in the admin panel as an arbitrary html-code. For blocks, there is a block template - name.tpl.php.

Widgets in WP are exactly the same as blocks in Drupal. WordPress widgets can also be standard (for example, “the site runs on WP”), can be created by plugins and themes (using the inheritance of the WP_Widget class and the register_widget function), and can be defined directly in the admin panel using html code (more precisely, there is a standard widget, allowing you to place arbitrary HTML code). The role of regions in WP is played by sidebars. Sidebars need to be registered in the theme in the functions.php file using the register_sidebar function. After registration, sidebars become available in the admin area in the Widgets section and allow you to place widgets of different types. There is a sidebar.php template for the sidebar by default, sidebar-name.php templates can be defined for additional “named” sidebars.

In general, regions and blocks in Drupal are somewhat simpler to use, but not significantly, the functionality of sidebars and widgets is completely similar.

CSS / JS Connection


To connect JS to WP, use the wp_enqueue_script function, and the wp_enqueue_scripts hook. Actually the only way. If you want to control the connection, then the logic is used, since hooks in WP require an explicit call to add_action (). There are several ways to connect JS in Drupal:

  • connection in topic info file
  • connection by drupal_add_js function (similar to wp_enqueue_script)
  • connection via libraries API
  • connection via the attach parameter in forms
  • Connection directly to the html.tpl.php template (not recommended);

The first way is the most convenient and logical, the second allows you to add logic when connecting. Libraries API is a pretty convenient thing that allows you to connect entire libraries (JS / CSS / PHP), with several versions and tracking which version is when to load. Libraries can be used for several topics.

For connecting CSS, the connection mechanisms are similar (with replacing the script with style and js with css).

Content


For historical reasons, content in WP is called posts, post in Drupal is called nodes. In general, they have no special differences, with the exception of nuances. For example, the two standard types of content in WP are the actual posts and pages. Pages are not a subtype of posts, but are a kind of isolated type of content with its own properties. For example, you cannot define a taxonomy for pages. Pages are often used for static content, but can be defined according to a custom template, i.e. essentially contain anything.

Nodes in Drupal are all kinds of content, including pages. All content is initially accessible through links of the type “node / node_id”, for example, “/ node / 12345”, so all content is unified.

Content Types and Fields


Content types are subtypes of nodes and posts, respectively. For WP, the type of posts is determined simply by a certain marker name and does not define anything else. You can create posts with this “type”, you can pull them out of the database by type. For Drupal, the type of node (bundle) is not only a name, but also, for example, custom fields that are attached to this bundle by default. In WP, instead of fields, the basic functionality has meta information - any kind of key-value pair that can be attached to a post (a specific post, and not the entire type).

A popular solution is to use the Advanced Custom Fields module.(ACF), with which you can define field sets and attach them to content types, similar to the Drupal approach. In Drupal, this is done more flexibly because the concepts of field and field instance are separated - an abstractly defined field and a field attached to some kind of bundle. But overall, the practical possibilities are ultimately similar.

WP meta information can be attached not only to posts, but also to users, taxonomy terms and comments (add_post_meta, add_user_meta, add_term_meta, add_comment_meta functions). Drupal has a generic concept of an entity (Entity and Entity API), and fields are attached to entities that have a fieldable property.

Taxonomy


A taxonomy is a categorization of content using a hierarchy of terms. Both systems have full-featured capabilities for determining an arbitrarily complex taxonomy, since the idea itself is not too complicated. Both systems provide an advanced API for operations with dictionaries and taxonomy terms. The appearance of custom post types and hierarchical taxonomy in WP is announced as a radical change, thanks to which WP is no longer just a blog engine and has become a full-fledged CMS. Perhaps one can agree with this, although there are a lot of rudiments of the former “blog-oriented” WP (for example, the bloginfo function, WP_Post, sidebars, Loop itself, etc.).

Custom content output


Views , one of the most significant contributors to Drupal, allows you to create pages to display available types of content in almost any form. This is all convenient to configure from the admin panel, but you can also from the code if you wish. In fact, when creating specific site pages on Drupal, the task of displaying content in the form of static pages, the entire node (via the node.tpl.php template) or a view (i.e. a block or page formed by the Views module) is solved. The view itself determines how the output content is formed, and the corresponding Views module templates determine the specific output markup. To override such templates, you should also copy them from the module into your theme.

The analogue of Views in WP can probably be considered the main mechanism for displaying content - a loop. The loop uses the global variable $ wp_query to get the query results. Most standard templates use a loop and template tags ( Template Tags ) to display specific parts of the content (title, date, actual post content, link to the post, etc.). In essence, a Drupal view object is a wrapper of this kind of loop, which is configured using a structured array (which Drupal loves so much).

It is difficult to say which mechanism is more convenient and flexible. You can create views without programming at all, immediately getting a preview of how everything will be displayed on real content. On the other hand, finer tuning of the views (from the code through the view object and functions of the type views_embed_view) is clearly more complicated than setting the output of the WP loop. But then the already configured view object can be reused anywhere in the code, no need to repeat the loop code.

Speaking about the output of content using a set of templates, it is important to note one significant difference - until the very last moment (calling the render () or drupal_render () functions), the format for outputting content in Drupal remains in the form of the so-called renderable arrays- structured arrays, which are easier to change than the finished HTML string. Structured arrays are an interesting and convenient mechanism, although these arrays grow over time to incredible sizes (sometimes hundreds of thousands of elements), become recursive, include and re-include the same content, and in general sometimes terrify.

APIs


Both Drupal and WP are constantly evolving and adding new features for programmers. In both systems, these features are structured as separate APIs. Let's consider some of them.

AJAX API


Drupal provides a very interesting interface for working with Ajax . The main idea is to organize Ajax functionality whenever possible without writing any JavaScript code. This is achieved by introducing CSS classes of type “use-ajax” (just assign such a class to a button or link), as well as a mechanism for standard processing of ajax requests (for all ajax requests, one typical system / ajax path). On the server side, using the functions of the ajax_command_ * series (for example, ajax_command_invoke), you can completely determine what will happen in the browser, up to the call of specific jQuery functions. The mechanism takes some time to master, but later allows you to efficiently redraw the necessary pieces of the DOM directly from PHP.

The Drupal behaviors mechanism deserves special consideration.. By design, this mechanism is intended to treat JS code as some behavior that is included at the right time, not only during the initial loading of the page, but, for example, after redrawing part of the DOM with an ajax request. Behavior gets the context (in fact the root element of the DOM in which the changes occurred) and can respond accordingly. The behaviors mechanism is useful and interesting if mastered and correctly applied.

The Ajax mechanism in WP is much simpler and slightly different from the basic ajax in principle in PHP. Essentially, WP defines the standard path where requests from JS are sent (global ajaxurl variable in JS) and the mechanism for determining handlers via hooks. An Ajax response is generated using the WP_Ajax_Response class, which simply creates the necessary XML code. You can also just use the wp_send_json function.

Forms API


Drupal provides a fairly powerful API for working with forms using structured arrays. In fact, any form in Drupal should be determined by the description of all its components, as elements in a structured array, and displayed already in the template using drupal_render. When defining the elements of an array, you can specify many interesting things, for example, use the Ajax API mentioned above, include those required specifically for the JS / CSS form, and you can create multi-page forms. The Forms API (FAPI) supports input validation, multiple submit handlers, and the ability to override forms using hooks.

In WP, there is no such mechanism for working with forms; there are many plugins that help you to draw feedback forms for sites in the admin panel and embed them on pages. Knownattempts to create something similar to Drupal FAPI. In general, it’s somewhat a shame that for such a basic functionality there are not even simple helpers like Form :: open ().

More about the way


As already noted, routes in Drupal are defined using the hook_menu hook. Thus, you can set any possible paths (normal, in the admin panel, Ajax, API, etc.) - the method is convenient and uniform. There is no such a uniform way in WP, but there are two interesting APIs: Rewrite , with which you can independently determine the rules for converting the path into a beautiful link, and the WP REST API . The latter provides a real ready-made REST interface that allows you to receive data from the database, and also allows you to define any of your custom paths. Drupal has no analogues to this API.

Entity API


Not so long ago, the Entity API appeared in Drupal - a new level of abstraction over nodes that allows you to define entities that are not directly related to content. Nodes, users, comments, and taxonomy terms have become special cases of entities. When connecting the Entity API plug-in (which for some reason is not included in the default set), entities can be effectively worked on.

The main question is when and why to do it. They recommend everything that looks like content and has the appearance to be styled as types of nodes, and something more abstract and “invisible” on the screen - as entities. We can say that this is a tool for organizing a more complex application on Drupal. For example, entities are actively used in Drupal Commerce to process individual characteristics of an order.

There is no such abstraction in WP, so if you need to write something more elaborate, you will either have to use custom post types or just have fun and write in PHP.

Data Models and DB


The data model in the CMS is built around content types. If the business logic of the application can be conveniently described using content types, then CMS is a good tool to use. A content type is an independent entity with a fixed set of attributes (among which there is something like title and description). It is desirable that different types of content are not interconnected.
It is most convenient to work with WP post types through the WP_Query object, as well as the get_posts () and query_posts () functions. If WP_Query features are not enough, then there is the dbDelta () function, which is designed to run any SQL queries, as well as the wpdb class, the capabilities of which are used through the global $ wpdb object. The wpdb class simplifies working with the database a little, but you still often have to write raw SQL, it does not provide any query builder features.

In Drupal, there are several APIs for working with the database:

1. For working with the database structure (schema), there are hook_schema and functions like db_create_table / db_add_field.
2. The drupal_write_record function, as an easy way to write to the database.
3. The main API is a set of functions db_select / db_insert / db_update / db_delete / db_query, with the dynamic construction of queries (examples ).
4. For more convenient work with entities and fields, there is an EntityFieldQuery class , which also allows you to make dynamic queries.

There are also attempts to add more serious tools like Doctrine to CMS. Both WordPress and Drupal have corresponding modules / plugins, but, apparently, are not in active development. Apparently there is no acute need for such tools, in view of, again, a slightly different data model.

Conclusion and Conclusions


Consideration of specific possibilities for a programmer leads us to the conclusion that Drupal is a much more complex and equipped development system, which at the same time requires a lot of time to learn (which not always and not everyone has). Experience has shown that Drupal power in practice is offset by its complexity. A Drupal site that fell into the wrong hands is quickly becoming a huge pile of unaccompanied code.

On the other hand, WordPress is a much lighter platform that allows you to quickly get a noticeable result. Of course, WordPress has not enough tools for a long team development, but the system is actively developing, it grows with interesting features. Both CMSs, therefore, deserve serious consideration for their tasks.

Also popular now: