Arguments a customer can understand not to use WordPress

I saw an article that Wordpress has a new version. So I checked the code on Github. While I could do a lot of moaning about the code, I want to present some arguments that can help you to make a customer not choose for WordPress. Support for PHP 7 My biggest gripe with WordPress is that they still support dead PHP versions. I don't mind conservative support, PHP 8.2 as minimum version is fine. I understand updating a website because of a language update is not a something a non technical person needs to understands. On the other hand people are aware about regular software updates on their computers and phones. To get the latest features they are encouraged to buy the latest phone/computer/tv. I don't update if it has no added value, but even moving from 7.4 to 8.0 adds massive benefits: performance (more people can see the site for less money) better comparisons (less development time) easier to use functions (less development time) The other 8.x versions offer developers things that reduces the time they need to come up with a solution. Like making it easier to work with arrays, a json validate function, a SensitiveParameter attribute. That last one is a security feature, so lets stay on that topic. By supporting not maintained PHP versions it not only makes it more likely people can steal or destroy the information that is needed to make the site work, but they even can take over the whole website if they want to. Exposing all the files If you look at the Github repository the index.php file is in the root, which means you have to expose all the php files, including wp-config.php which holds the information that needs to stay secret. There are options like Wordplate that solve that problem. The thing that annoys me the most is that it still places the wp-config.php in the public directory. That is the most important reason to have a subdirectory that is linked with the url. Lack of standardisation I looked at the Plugin check code and on the page they mention only the Plugin repo category is required for a plugin to be allowed on the marketplace. In the security category there is a check for unescaped database queries. In my opinion that should be required. This is a security risk. Input sanitation is required, so it is less of a risk but it is still a risk. There is also no requirement to follow the PHP-FIG standards. The best thing that is build because of those standards is Composer. The most plugins I downloaded while writing use composer. The problem is that the plugins ship with their own vendor directory. While the standard is to have one vendor directory for the whole project. This results in different packages with the same or different version of it in the plugins. Other CMS's like Craft CMS and Drupal have the same problem where third parties provide plugins, but they are able to use Composer as it should be used. When I searched for scaling I couldn't find official WordPress documentation. You have to rely on third parties to get the information. While I understand there are a lot of ways to scale, basic documentation could send people on their way. Even the documentation search has no relevant results. Conclusion Because of their dedication to leaving code as much as it is, while adding new features causes problems like security risks, longer development times when things go bad and scaling problems. These are things you as a developer need to put on the table because it involves your customers reputation.

Apr 19, 2025 - 11:07

Arguments a customer can understand not to use WordPress

I saw an article that Wordpress has a new version. So I checked the code on Github.
While I could do a lot of moaning about the code, I want to present some arguments that can help you to make a customer not choose for WordPress.

Support for PHP 7

My biggest gripe with WordPress is that they still support dead PHP versions.
I don't mind conservative support, PHP 8.2 as minimum version is fine.

I understand updating a website because of a language update is not a something a non technical person needs to understands. On the other hand people are aware about regular software updates on their computers and phones. To get the latest features they are encouraged to buy the latest phone/computer/tv.

I don't update if it has no added value, but even moving from 7.4 to 8.0 adds massive benefits:

performance (more people can see the site for less money)
better comparisons (less development time)
easier to use functions (less development time)

The other 8.x versions offer developers things that reduces the time they need to come up with a solution. Like making it easier to work with arrays, a json validate function, a SensitiveParameter attribute.

That last one is a security feature, so lets stay on that topic. By supporting not maintained PHP versions it not only makes it more likely people can steal or destroy the information that is needed to make the site work, but they even can take over the whole website if they want to.

Exposing all the files

If you look at the Github repository the index.php file is in the root, which means you have to expose all the php files, including wp-config.php which holds the information that needs to stay secret.

There are options like Wordplate that solve that problem. The thing that annoys me the most is that it still places the wp-config.php in the public directory. That is the most important reason to have a subdirectory that is linked with the url.

Lack of standardisation

I looked at the Plugin check code and on the page they mention only the Plugin repo category is required for a plugin to be allowed on the marketplace.
In the security category there is a check for unescaped database queries. In my opinion that should be required. This is a security risk.
Input sanitation is required, so it is less of a risk but it is still a risk.

There is also no requirement to follow the PHP-FIG standards. The best thing that is build because of those standards is Composer.
The most plugins I downloaded while writing use composer. The problem is that the plugins ship with their own vendor directory. While the standard is to have one vendor directory for the whole project.
This results in different packages with the same or different version of it in the plugins.
Other CMS's like Craft CMS and Drupal have the same problem where third parties provide plugins, but they are able to use Composer as it should be used.

When I searched for scaling I couldn't find official WordPress documentation. You have to rely on third parties to get the information.
While I understand there are a lot of ways to scale, basic documentation could send people on their way. Even the documentation search has no relevant results.

Conclusion

Because of their dedication to leaving code as much as it is, while adding new features causes problems like security risks, longer development times when things go bad and scaling problems.

These are things you as a developer need to put on the table because it involves your customers reputation.