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.
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
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
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.
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 Engine
These were the plugins I installed, activated and configured in both instances.
Bulk Images to Posts: 3.3
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
Simple Tags: 2.4
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?
Google vs Amazon - Results
Google Cloud Engine
Total MySQL Time
Total PHP Time
Total Test Time
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).