Category Archives: WordPress

Setup Mailtrap with WordPress

Mailtrap is a service that captures all mail sent by your site and prevents it from arriving at the intended┬árecipient. It’s really useful for testing and debugging mail without having to write manual checks to ensure your users don’t get spammed with tests.

Setting up Mailtrap with WordPress is pretty straightforward, because all we need to do is overwrite the default SMTP server in the PHPMailer, which is what WordPress uses to send mail. It’s important to note that it will also trap mail sent from plugins like Contact Form 7.

Add the following hook in your theme’s functions.php file or throw this in a plugin:

1
2
3
4
5
6
7
8
9
10
function mailtrap($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = 'mailtrap.io';
    $phpmailer->SMTPAuth = true;
    $phpmailer->Port = 25;
    $phpmailer->Username = 'username';
    $phpmailer->Password = 'password';
}
 
add_action('phpmailer_init', 'mailtrap');
function mailtrap($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = 'mailtrap.io';
    $phpmailer->SMTPAuth = true;
    $phpmailer->Port = 25;
    $phpmailer->Username = 'username';
    $phpmailer->Password = 'password';
}

add_action('phpmailer_init', 'mailtrap');

Be sure to replace the username and password with your personal ones, which can be found by clicking on your inbox in Mailtrap. Look for the SMTP credentials.

Once the hook is in place, you’re done. Give it a go!

WordPress could not establish a secure connection to WordPress.org

I’m using Vagrant to work on a WordPress site and noticed the following error throughout several admin pages that attempt to connect to WordPress.org:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.)

Continue reading

How to update and deploy WordPress as a Git submodule

WordPress 3.8.2, a security release, came out yesterday. Now, if you’re already on WordPress 3.8, your WordPress installation will most likely automatically update, but if you are using Git to manage WordPress as a submodule, and have auto-update disabled, you have to do that manually.

That said, it’s still super easy to do. It definitely outweighs not having a version control system.

Let’s look at the Git commands required to update WordPress from 3.8.1 to 3.8.2. Note that this will work for updating any version.

Continue reading

WordPress Upgrade: Peer certificate cannot be authenticated with known CA certificates

I was trying to upgrade WordPress on one of my servers, but kept receiving an SSL-related error:

Peer certificate cannot be authenticated with known CA certificates.

I verified the SSL certificate on the server and there are no issues with it as far as I can tell, but I’d be curious to know if someone else figures out the actual cause.

That said, and as a quick work-around, you can prevent cURL from verifying the certificate just during WordPress upgrades:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
add_action(
    'load-upgrade.php',
    'my_load_upgrade_php'
);
 
function my_load_upgrade_php() {
    add_filter(
        'http_request_args',
        'my_http_request_args',
        10,
        2
    );
}
 
function my_http_request_args($args, $url) {
    $args['sslverify'] = false;
    return $args;
}
add_action(
	'load-upgrade.php',
	'my_load_upgrade_php'
);

function my_load_upgrade_php() {
	add_filter(
		'http_request_args',
		'my_http_request_args',
		10,
		2
	);
}

function my_http_request_args($args, $url) {
	$args['sslverify'] = false;
	return $args;
}

What this will do is set CURLOPT_SSL_VERIFYPEER to false:

1
curl_setopt( $handle, CURLOPT_SSL_VERIFYPEER, false );
curl_setopt( $handle, CURLOPT_SSL_VERIFYPEER, false );

Git post-receive hook to deploy WordPress and plugins as submodules

In a previous blog post I discussed how best to manage file and folder permissions when deploying with Git, but today I’ll show a specific example of what that post-receive hook might look like for a WordPress project that uses submodules.

I have three servers that I can deploy to, but the post-receive hook only deploys a project when it encounters the specified branch as defined per server:

  1. QA waits for a release branch
  2. Staging waits for the master branch
  3. Production waits for the master branch

Other than this small difference, the post-receive hook is identical on all three servers to reduce maintenance.

Lastly, each server has two repositories per project:

  1. Bare repository – storage unit that uses a post-receive hook to deploy the project.
  2. Working repository – web root that will serve the project to the end-user.

This method has several benefits:

  1. View a combined list of all version-controlled projects via the /opt/repositories directory.
  2. Recover a corrupted web root by cloning a fresh copy from the origin.
  3. Prevent some issues that may occur during the deployment, since it will fail before post-receive hook is fired.

Continue reading