How to rename your WordPress database tables prefix after the installation

It’s really easy. You just need a plugin: Change DB Prefix

  • Make a backup of your database (and maybe your wp-config.php)
  • Make sure the webserver owns the whole WordPress directory (i.e. if you’re using Apache Web Server and your WordPress files resides inside /var/www/webdomain.com/public_html/, just make sure to sudo chown -R www-data:www-data /var/www/webdomain.com/public_html/
  • Also issue a sudo chmod -R 755 /var/www/webdomain.com/public_html/ to give the webserver the ability to write to files but only read/execute to others.
  • Go to the plugin screen inside your WordPress admin panel, set the new prefix and run it.
  • Done.

 

Convert your WordPress Database Charset and Collation to utf8

In the wp-config.php file there are two lines that define your MySQL database charset and collation.

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

These lines should match those of your database but it’s not always like that; maybe you want to migrate the database content into another one (which is CHARACTER SET utf8 COLLATE utf8_general_ci) or maybe you just want to set reasonable defaults for your blog (avoiding the defaults, which more often than not are unknown).

Enter Utf8ize. It’s a simple WordPress Plugin but it’s a life-saver.

The goal in these conversions is always to decide on what charset/collation combination you want to use (UTF8 being the best choice in almost all scenarios) then to convert all tables/columns in your database to use that charset. At that point you can set DB_COLLATE and DB_CHARSET to the desired charset and collation to match.

It reads your database and generates SQL statements for every table and column. Then you simply copy/paste the statements into phpMyAdmin or Adminer and execute.

Just remember to change your wp-config.php accordingly and pay attention to the generated SQL statements for the specific collation (may be utf8_general_ci or utf8_unicode_ci). Set the correct values in the wp-config.php right after you run the SQL statements and you’re done.

Block direct ip access to your server in Apache 2.4

Let’s say you have:

  • A server with an ip address (like xxx.xxx.xxx.xxx)
  • A domain name (like example.com)

And you want to be able to reach your web server (Apache 2.4 in this case) via your domain name (example.com) but you want to block access via ip address (so that when you type xxx.xxx.xxx.xxx in the address bar, it doesn’t work).

  • Connect via SSH to your server.
  • Create a new config file in the sites-available directory:
    sudo nano /etc/apache2/sites-available/direct.conf

Now type the following lines

<VirtualHost *:80>
    ServerName xxx.xxx.xxx.xxx
    Redirect 403
    DocumentRoot /dev/null
</VirtualHost>
  • Save the file
  • Type sudo a2ensite direct
  • Now restart your server: sudo apache2 restart

Done. You won’t be able to access your website using the IP address of your server.

If you want to disable this particular site configuration, just type sudo a2dissite direct and restart the server (sudo apache2 restart)

EDIT:

You might have to use

Redirect 403 /

As pointed out by Chris (thanks for letting me know).

Steps towards a readable, usable and fast blog

I’m not new to blogging but I wanted to make something unusual (based on my standards). What I wanted was simple:

  • Google Compute Engine
  • WordPress
  • Just enough themes, plugins and optimizations to get things done. Fast.

This blog is the result.

In the coming days I’m going to write the steps I’ve taken (and the ones I still have to take) to end up with a decent, fast, beautiful blog.

This is a little summary:

  • Set up the Google Compute Instance.
  • Configure a Domain Name with the Google Cloud DNS.
  • Installing and enabling a bunch on WordPress plugins at once, keeping in mind speed, robustness and readability factors.
  • Enable SendGrid to easily send email within WordPress (without messing up the Google Cloud Instance).
  • Configure Amazon S3 to host static files (like the themes files, css, js, fonts and so on).
  • Create a Cloud Backup solution.

There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.

– The Zen of Python

Now, since I’m not Dutch, I had to make and break things again and again just to find out a possibly viable way. I wanted to be able to crash and burn the whole infrastructure and then be up and running again in less than 30 minutes.

As I said, I’ll document my journey in the coming days, but I also expect comments and hints on how to make things better… ’cause I’m not Dutch.

Google Cloud vs Amazon AWS – WordPress Performance

Whenever I say this WordPress blog is hosted in the cloud, people automagically assume I’m using Amazon AWS. Wrong!

I’m using Google Compute Engine and let me show you why.

 Google Compute EngineAmazon AWS
Regioneurope-west1-deu-west-1b
Machine Typen1-standard-1m3.medium
CPU11
RAM (GB)3.753.75
Hourly Cost$0.055*$0.073*

Setup:

These were the plugins I installed, activated and configured in both instances.

  • Akismet: 3.1.5
  • Bulk Images to Posts: 3.3
  • BulkPress: 0.3.4
  • Google XML Sitemaps: 4.0.8
  • PHP/MySQL CPU performance statistics: 1.1.9
  • Pods – Custom Content Types and Fields: 2.5.5
  • Regenerate Thumbnails: 2.2.4
  • SendGrid: 1.6.7
  • Simple Tags: 2.4
  • SysInfo: 1.1.0
  • Wp Favs: 1.0.6
  • WP Super Cache: 1.4.6

Both deployments (just for the test purposes) are Bitnami WordPress. Well, let’s see the interesting part, shall we?

Bitnami WordPress on Amazon AWS
Bitnami WordPress on Amazon AWS
Bitnami WordPress on Google Cloud
Bitnami WordPress on Google Cloud

Results:

Google vs Amazon - Results

TestGoogle Cloud EngineAmazon AWS
Inbound Speed444.77 Mbps256.16 Mbps
Outbound Speed11.24 Mbps8.83 Mbps
Total MySQL Time7.71 s16.63 s
Total PHP Time1.87 s4.93 s
Total Test Time9.58 s21.56 s

I didn’t expect to see such a difference. Google Compute Engine is twice as fast the same type of machine from Amazon AWS. And it costs way less (in fact I haven’t applied the sustained use discount for a whole month usage so you might spend way less than $0.055 with Google Compute Engine).