Securing Your WordPress Website with SSL

We wrote about the importance of using SSL before. And we have been pushing for all our clients to get on board and get an SSL certificate. Not only is it good for SEO, but it also makes sure that browsers this year will not consider forms on your site that take user payment details or password details as insecure if they are not using https / SSL. So let’s talk about securing your website with SSL

Why do you need SSL?

So why do you need it? Well, one, it gives you more authority on the web and better SEO. But also, it is becoming more a more urgent to get an SSL certificate as more and more browsers will flag your sites / pages on your site as insecure when you ask for payment or Credit Card data in forms – think ecommerce – or password and do not use SSL. And that will look really bad on your site. Again, see earlier article on Chrome and SSL push.

What is SSL

SSL or TLS are basically two technologies to encrypt the connection from the visitor of your website to your website. So every time he enters data on your site in forms that data will be sent securely. Once a site is https secure you will see either a green lock in your browser or the lock and the word Secure.

How to get SSL

SSL can be gotten by either paying for an SSL certificate with a company that deals with it, by asking your host to arrange it or by taking care of itself. Normally your webhoster should have options available. Not all hosters have the free Let’s Encrypt option though so you may need to pay around €15-30 a year for it.

User Case

One of our long term clients Het Wapen van Enkhuizen, a hotel in the picturesque Enkhuizen, Holland has just had a lovely upgrade to a Comodo SSL certificate as well and is now completely secure. Giving it more authority on the web, better SEO and better preparation for an SSL only web in the future. Let’s Encrypt was not possible with their Dutch hoster Hostnet. So we went for a Comodo Positive SSL Certificate instead.

Now some technical details

Settings > General URL Change

Here you need to replace http by https. This will not cover all your bases but it is a good and quick start. You can do this in the database as well of course and you could even do this and all replacement in one turn, but that is a bit tougher for most.


After adding modified WordPress rewrite

<IfModule mod_rewrite.c>
# BEGIN Force http to https
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
# END Force http to https

and adding

define('FORCE_SSL_ADMIN', true);

to wp-config.php all traffic got redirected to https.

Hard coded Urls

Then we only needed to replace some hard coded urls inside header.php, style.css and replace image paths. You can do this with Search and Replace Database by Interconnectit or yourself in the database. Just be careful with serialized data.

Image Paths replacement

For replacement of image paths in the database we used the search and replace script of the awesome company Interconnectit. And then we had a great secure Wapen van Enkhuizen!


If you are interested in help with Securing Your Website with SSL we can take care of this for a very affordable fee.

Change Custom Post type Name and Taxonomy of existing Custom Post Type

Had a client ask me the other day if the existing name of the Custom Post Type in question could be changed as the url or taxonomy. So how do you Change Custom Post type Name and Taxonomy of existing Custom Post Type? Well there are a few steps you need to take to do this without blowing up your website.

Custom Post Type Setup

As with most if not all custom post type setups you have the option to create posts under that custom post type. The name of that post and slug can be adjusted, but the name for the group it is under cannot be changed. So in our case the name module or plural modules cannot be changed in the backend. To do that you have to change things in the database and in the code to load things properly.


Backup your site’s database and theme files before you get started. You will be making theme file changes as well as do a database update. So make sure you can revert when shit hits the fence. Always better to the safe than sorry, right?

Change Custom Post Type Name in Database

To update the Custom Post Type name we would have to run the following in the database:

UPDATE `wp_posts`
 # Update the post_type column
 `post_type` = REPLACE(`post_type`,'name_of_old_post_type','name_of_new_post_type'),
 # Update the urls
 `guid` = REPLACE(`guid`,'name_of_old_post_type','name_of_new_post_type')
WHERE `post_type` = 'name_of_old_post_type'

NB See SO thread on something similar here.

You might though just do a simple:

UPDATE `wp_posts` SET `post_type` = '' WHERE `post_type` = '';

without replacing the GUID might suffice as well. Then you just need to update the permalinks after that has been changed as well as the taxonomy here below. With this query you basically update the name of the custom post type without changed the GUID. It is simple and quick.

Change Taxonomy Name in Database

To update the url or taxonomy used by the Custom Post Type you will have to to do the following

UPDATE `wp_term_taxonomy` SET `taxonomy` = '' WHERE `taxonomy` = '';

See also WordPress Stack Exchange thread

Post Meta

If you have stored any references to this post type within wp_postmeta within serialized arrays you cannot simply do a search and replace as they replaced strings need to be of the same length or things won’t work anymore. There are scripts and plugins out there that can help with this though. Here is a Better Search and Replace plugin and there is of course wp-cli search and replace that does all this taking care of serialized data as well.

Permalink Update

Do not forget to update the permalinks after these changes under settings > permalinks. Otherwise your existing custom post type posts won’t load anymore and neither will the taxonomy they are under. But hey, this is not hard to take care of now is it?

Theme Changes

You’ll need to update any references to this post type in your code. So references to the old custom post type and taxonomy in template files, functions.php and so on. And this could take some time. Especially if it wasn’t you who created the theme in the first place. And that was the case in our case. In the end we postponed this big change as a new theme change was coming up. Once that is done we will get back to this possible upgrade.


PHP Fatal error: Allowed memory size of x bytes exhausted – How to fix this error

We have a client with Antagonist in Holland and it has had multiple brief downtimes over the last couple of weeks. We are already no longer using Slimstat as it seemed to be rather demanding memory wise. But the downtimes still continued. “PHP Fatal error: Allowed memory size of x bytes exhausted” was the key error we found out. Here is how we dealt with it.

Allowed Memory Size Exhausted

As stated we soon saw in the logs that there was an issue with the PHP memory limit set. We got too many well known general errors like:

PHP Fatal error:  Allowed memory size of x bytes exhausted

We found this specific error using WP Debug in the debug.log file:

[02-Dec-2016 03:38:22 UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/account/domains/ on line 1832

and another one an hour later:

[02-Dec-2016 04:08:50 UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/account/domains/ on line 1832


The file wp-db.php the error refers to is the file used to interact with the database. It is based on the ezSQL class by Justin Vincent. It contains the useful global $wpdb There is a Codex article on it as well. There on the line 1832 of wp-db.php you will find:

while ( $row = mysqli_fetch_object( $this->result ) ) {
 $this->last_result[$num_rows] = $row;

That does mean that during a database fetch query more memory than allowed was asked for. This is still rather vague though and does not help much. More on a better analysis option a little later.

When we checked the general error log we only found:

Fri Dec 02 00:11:18.364110 2016] [ssl:warn] [pid 689240] AH01909: server certificate does NOT include an ID which matches the server name
[Fri Dec 02 04:49:58.434566 2016] [include:error] [pid 683238] [client] unable to include "/403.shtml" in parsed file /opt/error_pages/403_antagonist.shtml, subrequest setup returned 403, referer:

This error is not related to the issue though. And as the Antagonist cycles the logs rather quickly we will have to wait for more useful logs to show up.

Raising PHP Memory

So clearly we needed to raise the memory. This at least to avoid downtime. First we had to find out the amount of RAM used in DirectAdmin*. When you convert the bytes to megabytes you will see it passes 256MB:

bytes to megabytes

Location to check the PHP RAM limit varies from hoster to hoster. So is the place where you can raise memory usage for PHP. Some hosters will allow you to raise PHP memory in .htaccess or a custom php.ini file, others give you full root access to change the core php.ini.

When we checked the PHP settings in DirectAdmin – where Antagonist allow you to change it – we found out the limit was set at a puny 128MB so we raised it to 512MB:

Antagonist DirectAdmin PHP settings

We do prefer max 256MB for most non e-commerce sites though so we will start monitoring things more to figure out why this is happening.

WordPress Memory Limit

If this did not help you probably have to add one or two lines of code to wp-config.php to tell WordPress to really use the extra RAM given  (Codex Article). In our case we may add the following if need be:

define( 'WP_MEMORY_LIMIT', '512M' );

With most of our WooCommerce setups this is needed. In the case of memory allocation issues like ours we probably can just stick to change in PHP config itself.

Analysing Higher RAM Demand

To figure out what plugin or queries are the most demanding I normally use two plugins:

P3 Profiler has unfortunately not been updated in over 2 years so is no 100% very reliable. But still a great plugin that shows what your plugins and theme is using as a percentage of the whole.

The Query Monitor is more detailed as it will really show what particular queries are very demanding. Is a better option if you are the theme or plugin developer and want to improve the overall performance of your baby. For end users it is however more difficult to put to good use.

NB We are focussing here on backend stuff as the issue is related to database queries.  For frontend stuff  and site performance you can use tools like GMetrix, Chrome Inspector.  Also See this article for more .

Causes of Higher RAM Demand

Normally a plugin like Wordfence doing security scans, a statistics plugin like Slimstat or a backup plugin like BackupBuddy are the culprit as they all demand more than the average plugin. Site scans and backups as well as dealing with site traffic statistics tend to demand a lot. Lot’s of queries being fired, lots of I/O. That does not mean that these aren’t great plugins though. Some hosters just limit you quite a bit on memory or I/O (Especially GoDaddy!). Especially shared hosters.

In our case it was Wordfence demanding a bit more of the site every now and then. That and some heavy brute force password attacks that come and go. We are limiting the failed login attempts more now and we are considering stopping the use of Wordfence though we really love it.


If you want to keep on working with these or other demanding plugins you often need to upgrade your hosting package. Dropping the use of certain plugins tends to go only so far as some you simply cannot live without. So upgrade when need be. Unless there is space for the hoster to give you more RAM and they are willing too. You should at least be able to get 256MB. Even 512MB for running WooCommerce.

If you are on shared hosting, well, that often means you will need to upgrade to a better package. That has been my and my clients’ experience. In the end a better package, especially on a VPS or managed WordPress hosting service, will be best for most of you.




Child Theme Trouble: This theme is broken

Sometimes you bump into errors while working with child themes. I bumped into a “This theme is broken” error the other day. I wanted to modify an existing child theme. When checking the child theme from the Dashboard I saw this warning in the header:

This theme is broken. Template is missing. Standalone themes need to have a index.php template file. Child themes need to have a Template header in the style.css stylesheet.

This was the first time in all these years I saw this error myself. Normally I create child themes well and then you won’t see warnings like these.

Missing Stylesheet Header

This “This theme is broken” error showed up because the stylesheet of the child theme was missing the necessary header. All child themes need one for proper display. Once I added:

 Theme Name: Divi Child Theme
 Theme URI:
 Description: Divi Child Theme for LawOkk
 Author: Jasper Frumau
 Author URI:
 Template: Divi
 Version: 1.0.1
 License: GNU General Public License v2 or later
 License URI:
 Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain: divi-child

all was wel again. No errors were mentioned. More details on the header and how to work with it can be found in the WordPress Codex. But basically you can you use my example or the example in the codex. It is just basically a way of indicating:

  • we are dealing with a child theme,
  • what the parent theme is and
  • some details on the design and author behind it
  • text domain being used

Index Missing

I did however not add the index.php yet. That was also mentioned in the error message. This is also needed when using standalone themes. And this is a child theme so one is not needed really. Files you do need are:

  • style.css
  • functions.php

Those contain information to show we are dealing with a child theme and the proper way of loading or enqueuing the child theme CSS.

Bonus I: Enqueuing Styles Properly

Functions.php should normally contains something like this to enqueue styles properly:

function my_theme_enqueue_styles() {

    $parent_style = 'parent-style'; // This is 'twentyfifteen-style' for the Twenty Fifteen theme.

    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style ),
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );

This way you will load the parent theme CSS as well as the child theme’s CSS well.  For a more detailed discussion on why it should be set up this way see this SO thread here. But this quote should tell you why you should use it instead of @import:

The statement @import url('../twentythirteen/style.css'); is completely independent of the underlying parent theme’s version. In fact, the parent theme can be updated without updating the child theme but browsers will still use cached versions of the old ../twentythirteen/style.css.

Bonus II: Extra Functionality

On top of that you can add extra functionality when need be of course. The functions.php in the child theme ads functionality to the parent. It does not override like the style.css in the child theme.


Adding a Favicon in WordPress

To add a favicon in WordPress these days is way easier than it used to be. You used to have to upload the file to the webroot of your website’s server and then added the necessary code to load the favicon in your header. For that your theme needed to have a specific line of code to load the icon like:

<rel="shortcut icon" type="image/png" href="/favicon.png"/>

Adding Favicon in WordPress  Customizer

This tedious way of adding favicons is a thing of the past. It is no longer necessary. Since WordPress 4.3 you can upload the favicon under appearance > customize > site identity. The only thing you have to keep in mind is to use an image of a minimum size of 512px x 512px:

Site Identity

Browser Display

After you added it you may have to empty your browser cache to see it properly. So do this if you do not see it yet in your browser. Once you have done that you should see the icon. Here is how the favicon for our Ianua theme in progress looks like once we added a new favicon icon:

Favicon Display in Browser

Slider Revolution Slide could not be loaded – Possible Fix

Recently I updated my main slideshow on the homepage. I use Slider Revolution. It is awesome and goes well with the theme I use. For most themes I use really. It is a very versatile slider plugin. But this time around I bumped into an issue I did not see until my CDN loaded the new image. A Slider Revolution Slide could not be loaded.

Slider Revolution Slide could not be loaded

Somehow Slider Revolution did not appreciate the new first slide being 974KB. This caused the slider plugin not to load that slide properly. Here the error in the Chrome inspector console I found:

jquery.themepunch.revolution.min.js?ver=5.2.6:8 Could not be loaded !

This error caused a huge white hole on my homepage! I talked to MaxCDN to figure out why the image would not be loaded from their side. They figured it was a JavaScript issue. So not a CDN issue. This as the asset or image could be loaded from their end and from my VPS. And in the end it was. It was not the new live chat which I was testing though. I thought it was because it got added recently.

Slider Revolution Issues

Slider Revolution somehow blocked the loading. I realized this checking the Performance and SEO Optimization tab for that slider.

Performance and SEO Optimization tab

It said there was an issue with my first slide. I decided to optimize it some more with Imagify. The slider plugin somehow still loaded the old slide worth 974KB by itself. That is no longer the case in the screenshot above where the total of the 3 slides is only 379.53 KB. Afterwards it was lighter and loaded well. The warning went away too.

SEO Sidenote

I do know SEO wise many out there are not big fans of sliders. But I do still think when you do offer something on the slides like the initial one does and the titles of services on the others slides can contribute to the whole UX. Also make sure you do not slide right away or not too quickly at least. It annoys repeat visitors. And of course do cache things well so visitors do not have to wait too long.

Furthermore, do remember, the eye wants something too and that it provides. I do see a trend popping up every now and then where sites are told to be stripped to the bare minimum and drop slideshows and large images. People are not bots people!

Slider Revolution still a keeper

Finally, the enormous options Slider Revolution offers are incredible. They way you can display slides, effects you can choose and control over desktop, tablet and mobile you have are simply terrific. Too bad the issue was not clear for me from the start. And, perhaps, Slider Revolution should tell me clearer when an added image causes issues.. Still, happy user of SR and not going away anytime soon.

Anyways, that is that. I hope this helps others!

Need help setting things up?

[product id=”7324″]

Create WordPress Database using MySQL Client

Every now and then I need to create a MySQL or MariaDB database from the command line using the MySQL Client. And I tend to forget exactly what commands to run. Lots of things to remember as a web developer. That is why I created loads of gists at Github. Unfortunately their search is not that great and it is often hard to find stuff as you cannot write solid descriptions like you would do on a blog.

So here let me tell you what to do when you need to quickly create the database for a WordPress site from the command line. In my case I have Laravel Valet up and running on OSX with PHP7 and MariaDB running based on Homebrew. So all I need is to log into the MySQL Client and add the database. So how to proceed.

  • open the terminal
  • run the command mysql -u root -p
  • enter your password

That should show you the MySQL client prompt demonstrating you logged on. Then you need to run the following commands – with adjustments for the names and passwords:

CREATE DATABASE databasename;

And then you add privileges for a user:

GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname" IDENTIFIED BY "password";

Make sure you change the

  • database name to the one you picked,
  • choose a database user and
  • choose a password.

And then you flush all privileges:


So you would see something like this:

mysql> CREATE DATABASE databasename;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname" IDENTIFIED BY "password";
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.01 sec)

mysql> EXIT

As you can see not really hard to do, but nice to have handy to quickly modify, copy and paste is it not?

NB Do not forget to note down your used credentials for adding to wp-config.php

If you would like to check if the database is there run:



Show Databases

Your database with your name should be there.

Question? Leave a comment here below!

Converting Japanese Character Sets

A client of mine – Kyoko Inatome – who writes both in English and Japanese, had an issue with the Japanese characters (letters). She had saved the database language differently earlier. Now things no longer worked as it should and all the Japanese had become gibberish. The Japanese Character Sets needed to be converted to be displayed properly.

This is a WordPress site that has been around for a long time. At the time all data was stored as Latin and only partly converted to UTF8. And what was converted or added was not done successfully as the database character set and collation had not been adjusted and nor had the necessary table columns been adjusted.

One Step Conversion

What I tried first was a one step conversion of the post content and post titles. This I did using the following commands. I ran these from PHPMyAdmin:


The two queries above were to convert the database to UTF8 and to set the character set of the table with the main issues. Then I ran:

alter table wp_posts change post_content post_content LONGTEXT CHARACTER SET utf8;

This did not work at all.

Three Step Conversion

Then I read the article on the possible need of a three way conversion and the reasons behind this. I quote:

This is necessary when the charset of the table/column does not match the charset of the data that was being saved to it. Specifically it is necessary when the WordPress site was sending data in latin1 format (because DB_CHARSET was not set to UTF8) but the database was in fact formatted as UTF8. This seems crazy but it can happen because of mysterious compatibility layers in MySQL/MariaDB.

So I ran the three way conversion on the following table columsn

 alter table wp_posts change post_content post_content LONGTEXT CHARACTER SET latin1;
 alter table wp_posts change post_content post_content LONGBLOB;
 alter table wp_posts change post_content post_content LONGTEXT CHARACTER SET utf8;

alter table wp_posts change post_title post_title LONGTEXT CHARACTER SET latin1;
 alter table wp_posts change post_title post_title LONGBLOB;
 alter table wp_posts change post_title post_title LONGTEXT CHARACTER SET utf8;

alter table wp_terms change name name LONGTEXT CHARACTER SET latin1;
 alter table wp_terms change name name LONGBLOB;
 alter table wp_terms change name name LONGTEXT CHARACTER SET utf8;

Database Character Set

As they stated the three way conversion was probably needed as the database character set was not set properly. It wasn’t as I saw that the data in the database was still gibberish while it now looked fine on the site. So I added”

define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );

to wp-config.php .

Issues with Latin Characters

But running it got some Latin Chars mangled. These I fixed using the WordPress WYSIWYG Editor. This I could do as there was not too much text to go round and most of it was fine.

Japanese Letters Gone and Back Again!

Then when I checked all the Japanese categories and posts as well as post titles I saw they were all being displayed as gibberish again. Oh my goodness what now? then I realized reading it all I just had to repeat the three way conversion now that the database char set was all good.

So I ran the above variation three again going from latin to blob to utf8.

After that the Japanese in the database was fine:

phpmyadmin - Japanese All OK

as well as it was on the website:

Japanese on the site


WP CLI Call to undefined function apply_filters()

Doing a BackupBuddy backup from the commandline using WP CLI on a GoDaddy server the other day I ran into a fatal error. A WP CLI Call to undefined function apply_filters() error to be precise. It did not allow me to backup from the command line at all. The site was running fine.

Anyways, the error I got running the command:

wp backupbuddy backup 2

was the following one:

Fatal error: Call to undefined function apply_filters() in /home/user/public_html/wordpress/wp-includes/load.php on line 317


Googling the issue I found out that many websites were displaying similar issues. And no solutions really but to remove the core files and replace them with a fresh set or turning off all plugins and checking if that helps. The basics. But then I stumbled upon this SO thread. There the suggestion was to see if wp cli could be updated. And then I remembered wp cli having some issues with Trellis and WordPress 4.6. And I thought, yeah, that could be it!

Updating WP CLI to 0.24.1

So I ran the updater using the following command:

wp cli update

and it worked updating it all:

 wp cli update

You have version 0.22.0. Would you like to update to 0.24.1? [y/n] y

Downloading from

New version works. Proceeding to replace.

Success: Updated WP-CLI to 0.24.1

WP CLI BackupBuddy Re-Run

After that I ran the command to backup the site again:

wp backupbuddy backup 2

It did not spit out the same error again, but it did take its sweet time showing some feedback. After like 2 minutes it mentioned zip functionality it could not find as usual and then proceeded to do the backup.

Happy ending!

NB Reasons for using wp cli for BB backups on GoDaddy and installation instructions are mentioned here if you need them.

WordPress – Simply Good for Business

In this blog post I am going to show you why WordPress is such a great platform for content creation online. WordPress is simply good for business for many reasons and though some may always be partially subjective or just subjective please just bear with me.

Twenty Five Percent of the Web Can’t Be Wrong

25.5% of the web

WordPress powers 25.5% of the web and 30.3% of top 1000 sites. So that means a lot of people like using it. Also that a lot of companies and professionals do too. Companies like Sony, Time, Samsung, Linked and celebrities like Jay Z, Snoop Dog and Malala Yousafzai use WordPress. Here is a list of Fortune 500 companies using WordPress. And the reason they are using it? WordPress is simply good for business they found out.

Now the reasons you should go for WordPress one by one:

User Experience

user experience


As iThemes mentioned in their blog article, “it’s probably the easiest and most powerful blogging and website content management system (or CMS) in existence today”. Usage is often a personal experience and mine is of course too. But I have worked with other content management systems in the past. CMSs like Joomla!, Drupal, Typo3, Ghost and others. And WordPress’ Dashboard is just very intuitive and easy to learn. The Customizer to adjust the looks of your site and widgets are just amazing. Content creation using posts and pages is just not difficult at all. Also, there is plenty of help out there, either paid or for free.

Here a list of WordPress features that make it very user friendly:

  • widgets – easy way of drag and dropping content blocks into place
  • customizer – easy way to manage all elements of your theme from one location with live preview
  • posts – built for blogging with easy to set up hierarchy
  • wysiwyg – beautiful content editor with full screen zen mode
  • mobile friendly – WordPress Dashboard is fully responsive


huge ecosystem

The ecosystem of plugins to extend the functionality and themes to give your site the needed look is just wonderful. This is really important. So many free and commercial themes and plugins out there. It is unbelievable. There is no other rival CMS that offers this many themes and plugins to choose from. None. Just look at what a company like Themeforest offers in the WordPress section alone. It is truly phenomenal.

When I talk about the ecosystem I am including the community mind you. The WordPress online presence is truly magnificent. So many online resources and fora to read up on WordPress and to get help. The organization behind Joomla! has had quite a few issues the last couple of years. One of the reasons I left that CMS. The organization and people behind WordPress with Automattic and benevolent dictator Matt has thrived like no other. So in brief:

  • enormous and friendly online community
  • large online grid of documentation and tutorials
  • themes – huge amount of free and commercial themes
  • plugins – over plugins to extend your setup


open source - free

WordPress is 100% Open Source, baby! Nobody owns WordPress nor its themes nor its plugins. Everyone can use them for free and fork them to make them better. All is free for use as long as you follow the basic GPL licensing rules. Open Source makes sure nothings gets stuck behind licensing walls and that all keeps on growing. Beautiful!

Reasons for going for WordPress in Brief

So to summarize it all, it all comes down to is:

  • usability- very user friendly and easy to use
  • licensing – is it closed source or open source / what do extensions and or themes cost
  • eco system – large enough to sustain users and to grow and with solid enough leadership

And so far the answer has been yes to all three. Usability is great, licensing is open source and there is an amazing ecosystem out there waiting to be embraced. Plenty of reasons explaining why WordPress is simply good for business