A couple of days ago I published a new “about” page for introducing myself.

I’ve always struggled to find the best way to brand myself in a way that completely satisfied me. In the past, I only had a landing page linking to the various profiles and networks I wanted to highlight like WordPress.org, GitHub, Twitter, etc.

However, I also wanted a space where I could write. I sometimes feel the need to write about things, or express a point of view about a trending topic. For that, I need a blog where I can write whatever I want, whenever I want. The downsides are:

  1. I am not a regular writer,
  2. I am not a native English speaker, which means my writing is not too pleasant to read

For those reasons I’ve been tempted to just close the blog and go back to a simpler landing page on this domain. However, I know that there’s going to be a day where I want to write something and I’ll be wondering where to do that. Again, not being a native English speaker kind of stops me from writing on Medium or the likes.

Then one day I asked myself why not have both? I could keep the blog for when I need to write, and have a simple one page site that I can direct people to when I just need to say who I am.

This idea got even more interesting when I realized I could make it fun. I know it is possible to host a simple site on GitHub but I’ve never done it. It was the perfect time.

Hosting on GitHub

Hosting a site on GitHub is pretty simple. The only thing you have to limit yourself to is only write HTML. No server side language can be used.

As design and front-end development are far from being my specialty, I decided to use the theme Coffee & Cream by ocholabs. The code is very clean and well commented, which makes it easy to customize it.

The original Coffee & Cream template

The original Coffee & Cream template

After tweaking the code a bit, changing the colors and removing the sections I don’t need, I needed to solve the one problem that the HTML limitation causes: handling the contact form.

Indeed, with no server-side language allowed, it is not possible to handle the contact form directly from the site.

Luckily, there are a couple of services out there that are built to do just that: handling POST data. I’ve opted for FormSpree which is dead simple to use. There is one thing that I don’t particularly like though: your e-mail address can be seen in clear in the source code. Not a huge deal but I’m always afraid of bots.

Using FormSpree with an HTML form is as simple as specifying the FormSpree domain in the form action.

<form action="//formspree.io/your @email.com" method="POST">
    <input type="text" name="name">
    <input type="email" name="_replyto">
    <input type="submit" value="Send">
</form>

Pushing to GitHub

Once everything is ready, the last thing you need to do is push your code on GitHub. There are actually two ways to do it.

If you’re hosting a product / application on GitHub and you are publishing a small site for that application, obviously your codebase is on the master branch of your repo. You will need to push on a new branch called gh-pages.

If you’re publishing a site for yourself (or for your organization), you’ll use a dedicated repository for the site. You will need to name the repo username.github.io where username is your actual username. My repository for instance is called julien731.github.io. In this case, your site will be pushed on the master branch of this repo.

My About Page Repository

My About Page Repository

Pointing your domain

Now you just need to set things up so that your domain points to the repo. Two simple steps are needed.

  1. Go to your registrar control panel (I personally use NameCheap) and set a new CNAME record for the desired domain. This record should point to username.github.io (don’t forget to replace username)
  2. Add a new file to your repository and call it CNAME (no extension). In this file, simply write the custom domain name that you wish to use (do not add the http://)

It is worth noting that you can use a TLD (domain.com) or a subdomain (about.domain.com).

After the new record is propagated and the CNAME file is pushed to the repository, your custom domain will be used instead of the .github.io one.

I am really happy to announce that I pushed version 1.1.0 of WP Google Authenticator today. This version is the biggest update since the first release of the plugin. It adds support for two things that have been asked in the past: apps passwords and role based activation.

Apps Passwords

You might be using the WordPress mobile app on your iPhone or Android phone. So far you could actually use the WordPress app without problem. The plugin was using the user agent to determine if the connection was made from the WordPress app, and if it was, the one time password was skipped. This, obviously, brings the additional security this plugin adds down.

I’m happy to say that this is no longer the case. It is still possible to use desktop editing applications (or web services) to connect to WordPress, but it will require a manual intervention from you. It is not that difficult, and the good part is that the plugin is no longer limited to the official WordPress mobile app.

From now on, if you want to use a service or application that requires your credentials to log into WordPress, you have the ability to create an “app password”. This is a password dedicated to one application that can bypass the one time password.

What’s the difference with your own account password? First of all, the app password generated is strong. Most likely stronger that your current password. The second advantage is that you can revoke an app password at anytime. Don’t need it anymore? Click a button and it’s deleted. Think your app password has been compromised? One click and it’s fixed without cutting the access of other apps.

App Passwords List

Now that you have one (or more) app password(s) set, you can securely log in using your preferred app.

Also, in order to keep an eye on what’s happening, every use of an app password is saved in an access log. If a connection look suspect, the log even highlight it and display a warning message inviting you to check what’s happening and revoke the app password if there is a real risk.

App Passwords Access Log

Role-Based Activation

The second major feature that’s been added in version 1.1.0, and it’s been requested by a few users, is role based forced activation of 2-steps authentication.

Until now, you could either force all users to use 2FA, or let them decide whether they want to use it or not. This has changed. You can now force users of a specific role to use 2FA. This can be especially useful if you have subscribers registered on your site. If the user doesn’t have any privilege on your site then there is no need to enforce the security for them.

Here is what it looks like:

Role Based Forced Activation

 

I think this is going to be a warmly welcome feature 😉

If you have any more feature suggestions, please go ahead and ask. I am more than happy to make this plugin better and better every-time I have a chance to work on it.

One very important thing with the droplet I setup on DigitalOcean is to be able to host multiple sites. Hence, we’re going to use Server Blocks (the equivalent of Virtual Hosts on Apache).

I found and tried several tutorials on how to create Server Blocks and I ended up creating my own “method” based on all the resources I found.

Ghost is the first thing I will host and in most tutorials I’ve been told to setup Node.js, Ghost and then Nginx. However, I found it better to start with Nginx and then do the rest.

Setup your Domain Hosts

First things first, make sure your domain is setup correctly. Wether you use the root domain or a subdomain, make sure the A record points to your server’s IP address.

Create a New Directory

We now need to create the directory where the site will be hosted. In this example, I’ll use domain.com as the domain.

mkdir /var/www/domain.com

Install Nginx

In your SSH terminal, type the following line to install Nginx

apt-get install nginx

Now let’s delete the default configuration file, then we will create our own.

rm /etc/nginx/sites-available/default

Sources

Create a Server Blocks File

For the configuration file, I mostly based my settings on the Nginx documentation.

We can now create our configuration file.

sudo nano /etc/nginx/sites-available/blocks

I called it blocks in this example, but you can of course call it whatever you want.

This line will open the text editor in which we will input the custom configuration.

Sources

Create the Blocks

There are many ways of configuring a block. As of now I have only done it for Ghost, so here is what you need for it. However, if you refer to the Nginx documentation you will find all the basic elements for a block.

Note: When editing a file with nano, you can save the changes by pressing Ctrl+O (Ctrl right). Press Ctrl+X to exit.

Ghost

server {
    listen 0.0.0.0:80;
    server_name domain.com;
    access_log /var/log/nginx/domain.com.log;

    root /var/www/domain.com;
    index index.html index.htm;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header HOST $http_host;
        proxy_set_header X-NginX-Proxy true;

        proxy_pass http://127.0.0.1:2368;
        proxy_redirect off;
    }
}

Next step is to create a “symlink” to the directory sites-enabled. Indeed, sites-available only contains the available sites, it doesn’t mean it’s enabled.

sudo ln -s /etc/nginx/sites-available/blocks /etc/nginx/sites-enabled/blocks

Finally, let’s restart Nginx.

service nginx restart

Sources

That’s it. If everything went well, you should see the Nginx welcome page when browsing to domain.com.

This article is the first one of a series about how to setup a cloud server server running Ubuntu 12.04. This server will be used to run multiple sites. Essentially Ghost blogs and WordPress sites.

Why DigitalOcean

Beforehand, just a few words about why I chose DigitalOcean:

  • Their service seems high level,
  • All plans include SSD,
  • Very aggressive pricing,
  • The interface is dead simple,
  • You really are up and running in less than a minute

Create a Droplet

The first thing to do is to create a Droplet. Their process is really well done and very clear.

As I want to be able to host multiple sites on this droplet, I didn’t go with an Application image, but with a classic Ubuntu 12.04 x64 instead.

Their “55 seconds setup” is really not a lie. You really have your droplet up and running in less than a minute. It’ pretty impressive.

Setup SFTP

I’ve heard so many times that FTP is a very insecure protocol that I didn’t want to take any risk on this instance. I wanted to go with SFTP from the beginning and started to dig for tutorials on how to install ProFTPd with SFTP enabled.

After spending some time trying, I finally came across a very interesting post which basically said: no need for ProFTPd. As long as you can SSH into the server, you can SFTP as well.

I kept searching in that direction and here is what I came up with: create my users in Ubuntu, set their home directory, add them to a group, give the group the right permissions and that’s it!

Create a Web Directory

First of all, let’s create the directory. We will simply usr /var/www here. Try:

cd /var/www

If you get an error message saying the directory doesn’t exist, create it by typing

mkdir /var/www

Our web directory is now ready.

Add Users

It’s now time to add the desired users. For whatever reason I was not able to create a user and assign it a group at the same time. I had to do it in 2 steps.

sudo adduser newuser
usermod -a -G www-data newuser

Now that the user was created, you can possibly give him root privileges if this user is an admin. See “How to Grant a User Root Privileges” in this tutorial.

Last step for user creation is to change their home directory. The user’s home directory is where he will land when reaching the server through SFTP.

sudo usermod -d /var/www/ username

Sources

Set the Permissons

That’s a pretty big part we have done so far. What you are now able to do is to connect to your server via SFTP, and land into the www directory. However, you will not be able to do anything here as you won’t have permissions. We’re going to fix this now.

sudo chgrp -R www-data /var/www/*
sudo chmod -R g+rw /var/www
sudo chown -R username:username /var/www/*
find /var/www -type d -print0 | sudo xargs -0 chmod g+s

Source

Here we are. You now have a cloud server that you can access via SFTP! Just open your FTP client and reach sftp://yourip on port 22 using the username and password you setup earlier.

On the 24th was the second WordPress meetup I organized in Bangkok. We had the two founders of a successful WordPress company talk about the way they “productized” their WordPress development services.

Shinichi, a fellow WordPress developer helping with organizing the meetups, wrote an excellent summary of the meetup: Pronto Marketing at Bangkok WordPress Meetup

This tutorial is gold. You’ll learn the right way to create a translation file for your WordPress themes and plugins.

Poedit: Translation Secrets

Yesterday was the day. First time I organize a meetup. It’s been quite a rush in the end, but it was really worth it. I was very lucky to have Siobhan McKeown speak about getting involved in WordPress.

As it was my first ever meetup (as an organizer), I was really curious to see how full (or not) would the room be. And it was a good surprise! About 15 people came to the event. Out of the 26 who RSVPed, it’s about 61% attendance. Not bad I think.

The attendees were a good mix of Thais and foreigners. This is really important to me as I think it is the foundation of a good community. Both the Thais and foreigners were very interesting people and I’m hoping to see everyone again at future meetups.

If I had to summarize this meetup in one link, it would be http://make.wordpress.org/. I’m going to spend more time there as soon as I have a chance.

Now let’s continue with the pictures.

WP Google Authenticator has just been updated to version 1.0.4. This new version only brings one change few changes, but it’s a pretty big one.

Account Recovery

There was one feature missing to the plugin until now: a way for users to log in their site even if they can’t access the Google Authenticator app. If you just changed your phone for instance: you re-install the app, but you don’t have all your profiles anymore. You’re locked out of your site.

With the new recovery feature, when you activate 2FA for your account, a recovery code is automatically generated.

WP Google Authenticator Recovery Code Feature

WP Google Authenticator Recovery Code Feature

After you generated the recovery code, it will appear in your profile for 5 minutes. After that delay, you can always see your recovery code, but you will need to enter your WordPress account password before you can see it.

Now, if you have to use this code in a situation where you can’t use the Authenticator app, you will be logged in just as usual, but  2FA will be disabled for your account.

2FA Deactivation Notice

2FA Deactivation Notice

Next step is to go to your profile page and re-enable 2-factor authentication. You will setup the new account on your phone, and you’re good to go.

New Filters

Version 1.0.4 introduces 3 filters that might be useful for advanced users of the plugin:

  • wpga_secret_key_length: allows you to change the secret key length. Default is set to 16.
  • wpga_code_length: alows you to change the length of the TOTP. Default is set to 6.
  • wpga_recovery_code_length: allows you to change the recovery code length. Default is set to 24.

I lost a considerable amount of time today.

I’m completely new to Linters. I’ve read about it lately, and I felt dumb I didn’t start using it earlier. It avoids loosing time on stupid mistakes (a forgotten coma, an extra closing parenthesis… you know!) and help keeping a cleaner code.

I use Sublime as my IDE, and I love it, mostly for its package control. It makes installing a new addons easy as a breeze, and that’s how I installed SublimeLinter.

Installing SublimeLinter

Once you opened Sublime, press Ctrl+Shift+P (you must have the Package Control installed), find “Package Control: Install Package”. Search for “SublimeLinter” and install.

So here I am, with SublimeLinter installed, and… well, nothing. I checked a few Youtube videos and what it does seems awesome, but it simply doesn’t do anything for me. Quick Google search, nothing relevant. Actually, I ended up spending a quite a long time browsing, desperately looking for a solution.

SublimeLinter Settings

I finally found out what was wrong, and again, I felt dumb: it took me 1 minute after that to setup the plugin correctly. No more suspense, here is the missing config:

{
	"sublimelinter_executable_map":
        {
            "php": "C:\\wamp\\bin\\php\\php5.4.12\\php.exe"
        },
    "sublimelinter_mark_style": "outline"
}

Note that the double backslash is mandatory on Windows.

When customizing the settings, do NOT edit the default settings, edit the user settings instead. You’ll find it under Preferences > Package Settings > SublimeLinter > Settings – User.

In conclusion, here is my advice: open the default settings file for SublimeLinter and ready it carefully! It is very well documented and it would have saved me a lot of time to start with this.

This article is both a security tip and a tutorial to my WP Google Authenticator plugin.

2-factor authentication is a simple and efficient way to enforce security for your WordPress site. This will ensure you only can login to the WordPress dashboard with your credentials.

What is 2-factor authentication and why use it?

It is also referred to as 2-step verification. The standard way to log in your WordPress dashboard is to use a classic username / password couple. The problem with this is that security is low. A lot of people are debating about this system, arguing that it should not be used anymore.

There are two main possible ways for an attacker to get into your WordPress dashboard without too much difficulty:

  1. Your login / password were stolen,
  2. Your login / password are too weak and the attacker can brute force your login

2-factor authentication enforces security by requesting a one time password in addition to the username / password couple. This one time password is based on the current time, that’s what makes it unique. You will generally receive this password by e-mail, SMS or via a dedicated app.

In our case, we will use a dedicated app: Google Authenticator.

EDIT: You can also use Authy which is a pretty good app. Its main advantage being that you can sync your profiles between different devices (computer, phone, tablet…).

This app, developed by Google, obviously, is available on iPhone, Android and Blackberry. Of course, this mean you will need to have your phone with you every time you need to login to your site.

WP Google Authenticator: Tutorial

Download & Install

First of all, obviously, download and install the plugin. You can find it on the WordPress Extend: WP Google Authenticator, or search for “WP Google Authenticator” directly in your WordPress dashboard.

Setup the Plugin

Once installed and activated, the plugin will add a new sub-menu to the “Settings” item.

Here you have just a few options. Enough to make your site more secure, and few enough to get it working in 2 minutes.

WP Google Authenticator Settings

Let’s see all these options quickly:

  1. Activate the Plugin: pretty clear right? You can have the plugin installed but not active if you don’t check this box,
  2. Force Use: if you run a multi-user site, you might want your users to enable 2FA and not being the only one dealing with security. Enable this and all users will be asked to enable the feature,
  3. Site Name: when you will add a new profile in the Google Authenticator app, the name you typed here will be used to identify your site,
  4. Max Attempts: if you force your users to enable 2FA, they will only be able to log-in a certain number of times WITHOUT using 2FA. After that, if they still didn’t enable the extra security, they won’t be allowed to log-in,
  5. Authorized Delay: this last option will allow you to give more time to your users to type the one time password. The TOTP is valid for 30 secs by default, but you can add some extra “validity time”.

Generate your Secret & Setup the Mobile App

Three steps are required to completely enable the 2FA on your site:

  1. Go to your profile, scroll to the “WP Google Authenticator Settings” section, and click the “Generate Key” button,
  2. The page will reload. Scroll back to the settings section and click “Get QR Code“,
  3. Flash the QR code with the Google Authenticator app on your mobile

Google Authenticator Android app

That’s it! You WordPress site in now protected with 2-factor authentication.