Individual Eleven – The World's Cyberbrain

This problem has been apparent since WordPress version 2.x. Sometimes it happens when you move your blog to another hoster; it was an intermittent issue for me but still annoying.

There are several solutions I have found, but this one is best as you don’t need to SSH into your web server… and you may not have access anyway if your blog is hosted by a third party. WordPress sometimes has excessive delays for carrying out schedules; by default you only have 0.01 seconds to initiate the cron job for scheduling. Cron is a time scheduler for Unix/Linux based systems, and it is handy for automating tasks. In this case, our automated task is to post blog entries at a specific date and time without manual intervention.

So to fix this issue, use FTP to access your WordPress install and edit cron.php in the wp-includes folder.

• Find this line entry in cron.php: wp_remote_post ($cron_url, Array (‘ timeout’ => 0.01, ‘ blocking’ => false));

• Change the timeout to 20 seconds: wp_remote_post ($cron_url, Array (‘ timeout’ => 20, ‘ blocking’ => false));

Save the file and upload it back onto your webspace.

Tech Wordpress missed schedule

I bought my Shuttle PC awhile back now, I love it to death. I can even play games on it, it’s a great piece of kit as a media center and it’s fully loaded with features. Now, I always planned to install a Blu-ray drive in there to watch high def movies… of course you would, it IS a media center afterall. Well think again, because it wasn’t as easy as I first thought. In fact, for awhile, I thought it might not actually be possible.

But after four days of not sleeping I cracked it. I’m not one for giving up, especially when it comes to technical quandaries of this nature. In fact, I love challenges like these and I’m about to share with you so you can avoid the pain. Lets go back in time for a bit…

The Problem

After installing Windows 7, I bought a LG Blu-ray SATA drive from PC World; not the best place to buy hardware but they had a fairly decent deal on them. So you just buy one, install it in the Shuttle, pop in a Blu-ray disc and away you go right? Wrong. So very wrong. The Shuttle comes with an Intel GMA3100 chipset for the onboard graphics card. The picture quality produced via HDMI is quite good for an onboard, but when it comes to playing Blu-ray, it is one of the most hated chipsets known to man. I have tried both Cyberlink PowerDVD and Corel WinDVD 2010 but they failed to play a Blu-ray disc. You will be greeted with something like this:

Infinite patching for both programs produced the same result. Is it a hardware problem? Well lets go through the motions:

• HDCP compliant graphics card – Check.
• HDCP compliant monitor – Check.
• HDMI connection working correctly – Check.
• Up to date graphics card drivers – Check.

So what on earth is going on?

The Solution

It’s a software problem, as in the main producers of DVD/Blu-ray playback software have limited support for the Intel GMA graphics chipset. Maybe there is a way to get the above programs to work on my system, but I gave up. After trawling through the internet, I stumbled upon one random post on a forum. It mentioned using Total Media Theatre with the Japanese version of the files required for the video renderer. What?! Yes, without the renderers for Total Media Theatre pulled from the Japanese version of the software… it will not work. Don’t ask me how or why or what kind of crazy software development cycle is going on here, but that’s how it is.

So you need:

• Total Media Theatre version 3 installed
• VMR renderer files from the Japanese trial version (linked here for your convenience)
• Save the renderer files to: C:\Program Files\ArcSoft\TotalMedia Theatre 3\Codec

And that’s it! As if by magic, you can fully enjoy your Shuttle as it was meant to be.

My Shuttle and Inglourious Basterds. White Totoro approves.

Tech Blu-ray, Shuttle SG33G5M

My hope is that I don’t have to go through this again, ever. But if I do, it will be much less painful from the lessons I learned. Moving a WordPress blog is not just simply a quick copy and paste of the entire directory… especially if you are also moving it to a new domain name. There are export options within WordPress and other tools, which can be a bit hit and miss so I decided to do it this way. To save others from struggling on their own, I decided to write up a guide and to shed some light on some of the pitfalls.

Back up your files and database!
Before commencing any work, make a back up of the following as a minimum requirement:

1. Load up your favourite FTP client and make a copy of these files and folders from your existing site.

• /wp-content/plugins
• /wp-content/themes
• /wp-content/uploads
• .htaccess file (this is a hidden file by default, view all hidden files within your client to see it listed)

If you can make an entire copy of all folders within your site, then please feel free.

2. Make a copy of the WordPress SQL database by exporting it into a .sql file. Most hosters have SQL tools available, such as phpMyAdmin within cPanel to do an export.

cPanel - phpMyAdmin tool

phpMyAdmin - Export tool along top toolbar

When doing the database export, make sure all tables are selected. It may also be an idea to backup each table into individual files, I’ll tell you why in a moment…

Install WordPress
Now do a new install of WordPress on your new webspace and create a new SQL database. During the install process, make sure the table prefix matches exactly as your existing database. This is defined in the wp-config.php file:

WordPress table prefix

Just to add, I use EditPlus as my PHP editor which works really well.

Once WordPress is installed, delete all the tables in the newly created database using phpMyAdmin etc.

Import and upload
Now to put all your content back in. Import the .sql database file you backed up earlier and import it into the currently tableless database. You should now see all the populated tables, which contains all your blog settings and posts.

Upload the plugins, themes and uploads folders from your backup via FTP to your new WordPress install. Bear in mind to upload them to the same folder structure, replacing any existing folders. If you are using the same domain name as before and just changed website host, then you are pretty much done. You may need to put your old .htaccess file back in, if you cannot get permalinks to work as intended. If you bought a new domain name then you still got some work to do…

Replacing old domain name references with new. Welcome to SQL!
This is where the fun begins, you will now learn a few SQL commands which will come in very handy in this instance. Making SQL changes directly to the database instead of looking through WordPress settings via the GUI is my preferred method. Also some of these changes can only be made via SQL. Go back to trusty phpMyAdmin again, and load up the SQL tool:

phpMyAdmin - Executing SQL commands

• Changing the HomeURL and SiteURL – The HomeURL and SiteURL is an absolute path to your site. Since your site location has changed, we need to update this too or else your blog won’t load.
  • UPDATE wp_options SET option_value = replace(option_value, 'http://www.youroldsite.com', 'http://www.yournewsite.com') WHERE option_name = 'home' OR option_name = 'siteurl';

• Changing the URL for Content – WordPress loves absolute paths instead of relative, so again another change is required to make sure the URL for content in each post record is updated to the new.
  • UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://www.youroldsite.com', 'http://www.yournewsite.com');

• Changing the GUID – This is a very important change. The GUID houses the absolute location of where your posts are. Visitors to your site won’t be able to get to your articles as it will still be pointing to the old address.
  • UPDATE wp_posts SET guid = REPLACE (guid, 'http://www.youroldsite.com', 'http://www.yournewsite.com');
• Changing GUID for attachments/images – You may not need to do this, but if you find images and galleries are broken then you may need to update the GUID for the location of images. The best way is to check the current GUID location for images before making changes:
  

  phpMyAdmin - GUID for attachments

  • UPDATE wp_posts SET guid = REPLACE (guid, 'http://www.youroldsite.com', 'http://www.yournewsite.com') WHERE post_type = 'attachment';

Pitfalls and user awareness

SQL Oops
Not everything went to plan, it was 2am and I think I mistyped one of the SQL commands. Lo and behold the entire GUID column was blank in the wp_posts table. GASP! Remember earlier I mentioned backing up each table into individual .sql files? Well this is where my life was saved. I made several changes to other tables in the database and the last thing I wanted was to restore all the tables and start again. When you do a SQL database backup at the top level, all tables are backed up into a single file. But since I also did seperate table backups, I did a quick restore for wp_posts only and voila! I executed the correct find and replace command again and everything was good to go.

Permalinks and .htaccess
Another issue I came across were permalinks, I like them to look pretty. For some reason, all my permalinks were now coming up with /index.php/2009-01-nameofpost. What was index.php doing there in the URL? It definitely wasn’t there on the old site. I changed the setting within WordPress to try to prevent that from being appended, but it didn’t work. It looked like the .htaccess file was not updating correctly, WordPress normally updates this automatically to set the use of permalinks. If your web host uses Apache, then it will most likely be utilising the mod_rewrite module for this to work. I restored .htaccess from backup which fixed it, but here’s what mine looks like if you need a point of reference:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

And that’s it, job done! It’s actually less painless than it looks, as long as you make backups of your old site then you can always restore back if things don’t go to plan. Good luck!

Tech Moving Wordpress, Wordpress, Wordpress SQL

If you have been living under a small rock over the past few days, then you may not have realised the furore surrounding yet another flaw in a Microsoft product.

Corporations all over the world have been warned to stay away from Internet Explorer version 6, including our very own government. The figures published from another Guardian article outlines just how badly organisations in the public sector need to update their software. I am particularly fond of this:

“More than 750,000 workstations in the NHS and 500,000 in the Department of Work and Pensions use exactly that combination… The DWP installation of IE6/XP in 2002/3 took a total of three years…”

The private sector is not any better. From my own personal experience, businesses still use Internet Explorer 6. It’s almost like a safety blanket that is difficult to let go of. Version 6 has been a browser staple for many years and investing time and effort to roll out new versions is sometimes considered not a priority. Using other browsers is difficult, as Internet Explorer is the main product for domain integration such as the use of group policies.

For many, this is a lesson learned but perhaps a little too late. Details of  the MS10-002 security bulletin issued by Microsoft can be found here.

Tech IE6 vulnerability, Internet Explorer, Microsoft