WordPress Video Tutorial "it sucks"


I propose today to learn a little more about the WordPress CMS and try to understand more in depth the criticisms that are made against it.

WordPress is full of flaws!

The first criticism that comes up quite often when talking about WordPress is its lack of security. This defect is amplified by the popularity of CMS which makes it a target of choice for people looking for security breaches. The impact of a flaw is also much greater since it will automatically affect thousands of sites.

However, popularity is not enough to explain the problems. WordPress, by its design, brings certain risks in terms of security (especially in its default configuration).

PHP

The first problem is the use of PHP. The operating method of PHP makes it possible to execute a file knowing the URL allowing access to it. This is not a problem in itself but amplifies the impact of other problems. Indeed, if a user manages to obtain write rights on a folder, he will be able to create a malicious PHP file which he can then execute via a simple HTTP call.

This is not a problem specific to WordPress but you have to be very attentive to permissions when hosting a PHP application so as not to end up with corrupted PHP files (see next point).

Permissions

The second problem lies in the use of too lax permissions. It is not uncommon to see WordPress sites operating with a user having write rights on all of the site's files. These permissions allow the administrator to update the site and install extensions or themes from the web interface.
Such permissions allow someone exploiting a security vulnerability to write new files, or modify WordPress files to inject malicious code. This code can be used to spy on your site or to use the resources of your server without your knowledge.

There is no miracle solution against this problem except to completely lock the permissions of the folders and to leave write access only the folder supposed to accommodate the files sent by the administrator (the folder wp-content / uploads). We will also add a special rule to prevent the execution of PHP file within the folder uploads (this folder is only supposed to host images). This will limit the impact of a flaw on your application.

However, these more restrictive permissions will prevent the administrator from updating the site or extensions from the web interface. These operations will then have to be done from the server with tools like wp-cli.

Everything at the root

The other concern we will encounter with WordPress is the folder structure. Indeed, to make the site work, the root of the web server must point to the root of WordPress. This configuration has the effect of making all of the application's files accessible from the web.
It is now a very discouraged practice, which is not found in any modern PHP application. We recommend placing the source files one level above the web root (for example the PHP dependencies are located in a folder vendor not accessible from the web). It is also the presence of dependencies in a public folder that allowed the exploitation of a flaw in PHPUnit for example.

Unfortunately, there are no methods to mitigate this problem for WordPress files. It is possible, when you code a theme or an extension, to move the files elsewhere on your server but it is not possible to do so for WordPress files without affecting the proper functioning of the CMS.

wp_has_password ()

Password hashing is often questioned. For better compatibility, and to support older versions of PHP, WordPress uses the external PHPass library to hash passwords. In itself, this library may be suitable, but WordPress uses a cost that is too low by current standards. This cost means that, if a person can get a database, they will be able (in a more or less reasonable time) to obtain passwords by the brute force method. The increased cost slows down this strategy and prevents attackers from obtaining your users' passwords in a reasonable time.

It is however important to note that WordPress has a mechanism to replace the hashing method of the CMS. It is therefore advisable to replace this strategy with a more secure strategy (via the password_hash plugin or the wp-password-bcrypt library)

WordPress is slow!

Another argument given against WordPress is its slowness. We often experience sites that take a long time to appear or that consume a lot of server-side resources.

Poor MySQL :(

One of the roots of the problem is the multiplication of SQL queries when generating a WordPress page. Indeed, many modules and many functions generate SQL queries which are not necessarily necessary. Also, it is not uncommon to see several hundred requests made to display an article page.

This is a problem inherent in the very functioning of a CMS which seeks to have the most generic database structure possible (in order to adapt to a maximum of cases). It will be possible to mitigate this problem thanks to the use of cache which will allow to store the data. This caching allows to drastically lower the display time of a page and to reduce the server resources required.

If you are developing a theme or plugin you can also use the query-monitor extension to observe the number of requests made by the CMS and to assess the impact of your own functions.

WP_POST_REVISIONS

The other concern that is encountered systematically is a database saturated with the use of revisions. This system makes it possible to keep in memory a trace of the various modifications made to the contents (without time limit by default!). These revisions end up saturating the database and negatively impact the functioning of the site. You can correct this problem by disabling revisions or by limiting the number of revisions that are kept by the system.

Too much CSS and JS

WordPress has a system allowing developers of extensions and themes to add JavaScript and CSS assets via a hook. A site that uses a lot of extensions will inevitably end up with dozens of Javascript and CSS. This has a negative effect on the user experience.

<? Php
function loadMoreAssets ($ hook) {
    wp_enqueue_script ('custom_js', plugins_url ('js / custom.js', __FILE__), array (), '1.0.0');
    wp_register_style ('my_css', plugins_url ('style.css', __FILE__), false, '1.0.0');
    wp_enqueue_style ('my_css');

}
add_action ('wp_enqueue_scripts', 'loadMoreAssets');

This problem is often amplified by the use of page builder which allow the administrator to build a page with a lot of freedom and modules. These extensions also tend to generate additional CSS and JavaScript for each module that is used on the page (carousel, accordion, video player ...).

There is no miracle method to combat this concern, except to avoid the problem at its source. If you develop a custom theme, try to minimize the use of plugins and limit the use of large third-party CSS / JS files as much as possible (pay attention to the weight of the modules you use so as not to make the page load too slow for your users).

There are many plugins that allow you to merge and minimize JS and CSS but these plugins can not do miracles if you load a dozen libraries larger than 200kb (we find this situation very frequently on WordPress themes which includes every imaginable JavaScript module).

Too many images

The proliferation of image formats often leads to space problems on modest servers. It is possible from a theme or an extension to define an image format.

<? Php
add_image_size ('my-super-format', 220, 180, true);

Sometimes with formats declared for very specific uses. Note that each format will then be generated for each image sent by the administrator. Also, if the theme creator has declared ten formats, this means that 10 images will be created for each image sent by the administrator. This abundance of format can cause problems if you have limited disk space or if the site has a lot of content.

However, even if this early generation of images is a problem on the server side, it has an advantage from a visitor point of view. Indeed, when an administrator inserts an image into an article, WordPress uses a responsive image tag which allows an image loading adapted to the screen resolution of the visitor (a mobile visitor will not end up loading an image in 3000x2000 ).

If you want to limit the number of image formats you can use an on-demand generation method via a PHP library or through the use of third-party services.

WordPress is badly coded

If you seek the advice of a developer regarding WordPress, it will not take long to criticize the code of the CMS and its extensions. This is an argument that comes up quite often against WordPress: "its code is bad". To maintain compatibility with older systems, but also with its own ecosystem, WordPress keeps dated code, which leads to code that is less easily maintainable and more prone to bugs.

Hooks and Filters

The first concern that you will encounter when you go to work with WordPress (especially if you take the code from another developer) is the overuse of filters and hooks. These functions allow grafting behavior at different levels of the CMS by associating a function with a particular event.

function addLolToTitle ($ title, $ id = null) {
    if (in_category ('lol', $ id)) {
        return $ title. 'lol!';
    }
    return $ title;
}
add_filter ('the_title', 'addLolToTitle', 10, 2);

The main problem with this approach is that it is not possible to easily identify the functions that will be called. This leads to a lot of confusion when looking for why the return of a function is not as expected.

echo get_the_title (); // 'I am a title'
the_title (); // 'I'm a title lol!'

global

The second practice that is very often found in WordPress is the use of global variables (they allow the content to pass through the system). This poses several problems:

  • The code is not easy to test because it will be necessary to define global variables before launching the different functions to be tested.
  • The same function can give different feedback depending on the context in which it is called (which leads to many surprises).
  • As with filters / hooks, it is often difficult to understand who is at the origin of a modification of a global variable.

To give you a more specific example, WordPress uses a global variable to represent the query used to generate the content: $ wp_query. This object is passed throughout the system and allows WordPress to know which page to display, which template to load and is also used in functions like have_posts (). Changing this variable causes a change in behavior for the entire application.

WordPress is for noobs!

A last problem, more subjective this one, is the fact that WordPress is widely used by people with little technical skills (this is also a criticism that we also find against PHP). The accessibility of the tool is both an advantage and a disadvantage.

  • Lack of technical skills leads to WordPress installations that are not secure or slow. And there is nothing worse than having to repair a WordPress site with a theme that has hundreds of files that does not follow any defined structure.
  • The ecosystem is a mixture of very good tools but also poorly designed tools and it is not easy to sort out the good from the bad.

WordPress allows people who are not developers to design websites which some developers do not necessarily like (there is a certain elitism).

Why use it?

With all that I have just said, one can then wonder why use WordPress as a solution to create a site. In the end, WordPress is primarily a tool that meets a specific need, a need that is not necessarily covered by other tools. As often, the problem comes from the fact that one tends to see a tool as a quick fix for all problems.

WordPress is very effective if we want to set up a showcase site where the administrator will be autonomous in managing content. On the other hand, this is not a lasting solution for a dynamic site which will have to evolve over time (we can, but that does not mean that we have to do so).

RELATED ARTICLESMORE FROM AUTHOR