Category Archives: Blogging

Download failed. error:0D0890A1:asn1

A Pipe and a Keyboard Posted on by

I maintain a series of WordPress sites.

One of them recently started throwing up an error whenever I tried to update the core or a plugin.  All I got was the not very helpful message:

Download failed. error:0D0890A1:asn1 encoding routines:func(137):reason(161)

As this meant that every update had to be downloaded locally and then FTP'd up to the site I was anxious to find a fix.

I found this simple piece of code (courtesy of Damien Carbery over at the WordPress Forums)

<?php
/*
Plugin Name: Skip SSL Verify
Plugin URI: http://www.damiencarbery.com
Description: Skip SSL verify in curl downloads - fixes: Download failed. error:0D0890A1:asn1 encoding routines:func(137):reason(161).
Author: Damien Carbery
Version: 0.1

$Id:  $
*/

function ssv_skip_ssl_verify($ssl_verify) {
    return false;
}
add_filter('https_ssl_verify', 'ssv_skip_ssl_verify');
add_filter('https_local_ssl_verify', 'ssv_skip_ssl_verify');

I saved this into a text file which I named Skip_SSL_Verify.php, copied it up into the site's plugin directory and activated it.

Problem solved.  The site now updates normally.

Speeding up a WordPress site

A Pipe and a Keyboard Posted on by

One of the top considerations of any web site owner should be speed.

In these days of broadband connections, people are used to near instantaneous results, and a slow loading front page is guaranteed to lose visitors.

There are several factors which control loading time.

One is of course server response times.  There is little that can be done about that!

Then there is the core code of the site.  WordPress is WordPress and there is little or nothing you can do to change it.

There are areas though that are well within the site owner’s control.

The Theme.

The one thing I would say about themes, from the speed perspective is that the more graphic the site, the slower it tends to be.  A graphic rich theme is going to be slow, and it is worthwhile bearing this in mind when making a choice.

Plugins.

Plugins can be a site killer.  I use a plugin on my sites – Plugin Performance Profiler (P3) – which is a good indicator of which plugins are holding the site back.  Using that plugin I have managed to shave seconds off sites’ load times, by either indicating which plugins to remove or which to replace with a slicker version.  In quite a few cases I have managed to find replacement plugins that have exactly the same functionality but are faster to load.

External links.

External links within plugins or extra coding (such as advertising or analysis0 are frequently the cause of sluggish sites, as the server has to wait to connect to those sites before continuing to serve up the rest of the main site.  If your traffic analysis site is having an off day then your site will too.  

As an example, I had a plugin on this site which displayed my blogroll on the sidebar along with their latest posts and date of posting.  Before the page could load, the server had to contact each linked site in turn to retrieve information.  I ditched the plugin and reverted to standard links and shaved 32 requests and several seconds off the load time.

Images.

These are probably the biggest contributors to “gross tonnage” of any site.  Always reduce images in physical size and compression before uploading.  A photograph that is say 3,500 by 2,000 pixels may look stunning but it will weigh many megabytes.  Setting its display size may reduce the visible size but it will still weigh all those megabytes.  If you only want it to appear at say 600 x 400, then reduce it before uploading.  Also compress it as much as possible as many kilobytes can be shaved off an image that way.

Caching.

Caching can have an enormous impact on page load times.  It does so by generating static pages from the normal dynamic ones and therefore cuts way back on database requests, code requests and file loads.  There are several excellent caching plugins which can be found on the WordPress site.  While I haven’t tried all of them, the ones I have tried give facilities to allow code compression and browser caching which help greatly with load times.

A word of warning about caching plugins – I have noticed that Plugin Performance Profiler (see above) tends to give very poor responses for caching plugins.  On closer examination though, the poor response times are almost exclusively within the Admin pages of the site.  One would assume that not many outside visitors are going to reach in there?!

No buttons on WordPress Media Player

A Pipe and a Keyboard Posted on by

One of the big changes that came with WordPress 3.6 was the introduction of an embedded media player.

I have had occasion to embedd audio files in the past and I used a plugin for the purpose.  However, if I can avoid plugins then all the better, so I ran some tests with the new version.

The first trial showed the player all right, but there were no buttons.

MediaPlayer1

I tried clicking on the left-hand end of the graphic and the player worked.  However I wanted a “Play” button.

I searched the Internet and once again discovered that I wasn’t the only one with this problem  Apparently the breakdown is because of the use of the SVG mime-type, and not all sites support this.

The main solution given was to add the mime-type to the site’s .htaccess file –

AddType image/svg+xml svg svgz
AddEncoding gzip svgz

This solves the problem, but not every site owner has access to the .htaccess file, and some may just be nervous about meddling in that area.  I devised an alternative method.

The button graphic in question is stored in two formats – .SVG and .PNG so a simple tweak to the CSS file changing the file from .SVG to PNG will also work.  However, finding the references is not easy, and anyway any modification will be overwritten by any upgrade to WordPress.  The solution is to add the following to your theme’s “style.css” file –

.mejs-overlay-button {
    background:url("/wp-includes/js/mediaelement/bigplay.png") no-repeat !important;
}
.mejs-controls .mejs-button button {
    background:transparent url("/wp-includes/js/mediaelement/controls.png") no-repeat !important;
}

The “!important” directive will ensure that the code takes precedent over any WordPress CSS.

Either method will have the required result –

Backing up WordPress

A Pipe and a Keyboard Posted on by

One of the more important jobs in running a WordPress site (or any site for that matter) is backing up.

There are two parts to this – the files and the database.

Not all files need to be backed up, as in the event of catastrophic failure, the core WordPress files can be restored using the standard installation.  However the contents of the wp-contents folder are critical, as this is where the images, plugins etc are kept.  Granted, plugins also can be restored using available files from the Web but restoring them from a backup can save a lot of time and effort.

I experimented with several plugins to do my backing up, but had to abandon all as they were unreliable, unworkable or very resource hungry.  I had to find an alternative method, as the idea of connecting to several sites, and doing an FTP download plus doing a PhpMySQLAdmin dump each and every day was a non-runner.

I decided that Cron was my solution.

I set up a couple of small files – one to compress the contents of wp-content and the other to do a mysqldump.

Files –

/bin/tar –czf /usr/local/hosts/webspace/httpdocs/backups/backup-‘date +%d.%m.%y’ .tar.gz /usr/local/hosts/webspace/httpdocs/www/wp-content

Database –

/usr/bin/mysqldump –host=dbserver –user=dbusername –password=dbpassword databasename –quick > /usr/local/hosts/webspace/httpdocs/backups/backupdb-‘date +%d.%m.%y’ .sql

(need I point out that the paths, names and passwords are not the actual ones used?!)

I saved both files on the server and then set up a Cron Tab to run each file.

This worked perfectly on two of the sites I was testing on, but the third refused to work properly.  The ‘mysqldump’ function threw up an empty file each time, despite the code being identical in structure across all three sites.

It took a while to find the problem, but I eventually solved it.  It didn’t accept the password for the database as the password started with an ampersand ‘&’.  I tried various methods, such as escaping the ampersand and inserting quotes around the password but each time it failed.  In the end, I took the simple route – I set up an additional user for the database and gave that user a slightly simpler password.  It worked!

I now have a series of sites set up and all are running smoothly.  Because of the flexibility of Cron I could set the backups to run anywhere from once a minute to once a year.  However I have chosen a more sensible option. The databases are backed up every night and the files are backed up every week. That should be sufficient?

My next job is to refine the Files backup to ignore all cached files, as they are very bulky and aren’t necessary for a restore anyway.

A new home for an old site

A Pipe and a Keyboard Posted on by

There are two ways of moving a WordPress site from one server to another.

One is to create a database, and then copy all files to the new server, point wp-config at the new database and copy the contents of the database across.  This is the simplest way and ideal if, for example you are switching hosts.

The other method is trickier, but a lot more efficient, creating a leaner and faster site.  I have just completed a transfer of Head Rambles using this method.

The first thing is to create a new blank database on the new server, using a spare domain name for access.  Then upload a fresh copy of WordPress and using its built in features, create a new WordPress site.  The new site should be set up with the same Title and Subtitle as the old site, but using the new domain.

Next, copy across the theme files from the old server.  In my case I did a fresh install of Weaver II and then copied over the little backup files.  Any specific image files [such as the Banner and any images in the sidebar] should be copied across also.

At this point the new site should look identical to the old, but contain no posts or pages.

In my case, I then backed up the old database but did it one table at a time.  I then imported into the new database the following tables – Posts, Postmeta, Comments, Commentmeta, Terms, Term_relationships, Term_taxonomy and Links.  If the new database has been set up with a different prefix from the old [for example, if the old was WP_ and the new one is NEW_] then before uploading the files to the database, open them in a text editor and do a simple search and replace.

Don’t forget to copy over a copy of wp-content/uploads.

Now is the time to transfer plugins.  The ideal is to upload fresh copies of each plugin to the new site.  This is the time to decide which plugins are really necessary and which ones can be dumped.  Be ruthless!

At this point the site should be running smoothly and be identical in all respects to the old, apart from the domain name.  Now is the time to test that all the plugins are functioning correctly and that the site is behaving itself.

The next part is the tricky part.

Shut down the old site for changes [for example, disable comments]. Take another backup of the Comments database tables [and Posts if that has changed].  Upload these to the new database.

Now point the domain to the new server.  While that is propagating, open up the Options table in the new database and change every instance of the temporary domain to the permanent domain.

Once the domain has switched and is pointing at the new server the job is complete.  You should now have a much leaner faster site.

In the case of Head Rambles, the database dropped in size from 54Mb to 32Mb and from 34 to 17 tables.  Average page load time dropped from 1.48 seconds to 0.66 seconds which is quite impressive?  The main losses were database entries from redundant plugins and trimming the Options table from 16,225 records to 276 [a saving of 4.7Mb!].

The only problem I had was in switching the domain, where a couple of DNS servers got locked up for some reason.  It meant the whole domain was dead for a while, but the wait and the trouble was worth it.

To be safe, I have kept the old site running but with a different domain name.  It is blanked out for the general public but I can access it, for example if I need to cross check settings or retrieve any logs.  Once I am happy that it is redundant it, and its bloated database can be scrapped.