1316534948202_2x1_1280_640

Time To Say “When”

This last year or two has been a pretty crazy one in my life. Some of you know a bit more than others,  but there have been a huge number of things going on. And until recently, I was blissfully unaware of the impact of them.

There comes a time when we have to look around and take stock of what we have, and responsibility for what we have and don’t have.

Vague? You betcha! But I’ll get to all that. First of all, I wanted to let you all know that I’m stepping down as Editor of BlackBerryOS and Gadgism this weekend. It’s a decision I’ve been wrestling with for some time and I hate to go out this way but I believe that it’s for the best.

If you care for the full story then read on.

Continue reading

Tick, Cross and Arrows

My Hate/Hate Relationship With Arrows

When talking about design – in any sense – there are so many conventions that we take for granted and assume that everyone else understands.

Take the tick (✓) for example – that usually means “yes” or something is correct doesn’t it?

Well, no actually. The issue with the seemingly ubiquitous tick is that it isn’t recognised universally in that respect. As Separated by Common Language points out – there have been systems where a checkmark or tick can indicate a wrong answer. Continue reading

secure_your_wordpress_install

2 Simple Tips To Secure Your WordPress Installation And Uploads Directory

Lately, I’ve seen a flurry of WordPress attacks that uploads files or alters the WordPress core files to make your sites do things that they really shouldn’t do.

This nefarious tasks can range from using your site to email spam to making your site a billboard for online drugs sales and injecting visitors’ browsers with malware. You can imagine that it can be quite tricky to hunt these things down – or even be aware that they are happening if you’re not careful.

So here’s a few steps that you can take to ensure that your WordPress site is secure from these attacks. If you manage the server, then you might want to update your httpd.conf and add the following configuration.

<locationmatch "wp-content/uploads/.*\.(php\d?|phtml)$">
 AllowOverride None
 Order Deny,Allow
 Deny from All

What this does is prevent PHP files from being accessed from a browser. Our server is configured to allow PHP extensions with .php2 through to .php5 as well as .phtml. To prevent this from being accessed – I’m using a regular expression to find all of these file types. The AllowOverride directive will prevent any .htaccess files being used as well. If a script has managed to upload files to your server, there’s nothing to stop them allowing access back to the php files so this is necessary to prevent this.

This configuration applies to any location that is matched, which applies to all of your websites, rather than using the Directory method, which is based on the local file system.

Another security measure to consider is making the WordPress site read-only. I know that it’s a chore to manually update your site and plugins – but I have seen WordPress core files modified to inject headers and redirect certain requests. This is a complete pain to find, so save yourself the bother.

If you do find that your site is hacked – the first thing that you should try is to reinstall the WordPress core files. If you haven’t made the files read-only, then you can do this by clicking on the Dashboard > Updates link in WordPress and then click ‘Re-install Now’. This downloads and installs a fresh version of WordPress over your current core files with no configuration changes.

If you’re still noticing unusual behaviour, then you should try removing unnecessary plugins and themes and check the wp-config.php file in in your site.

If you at least use the above two tips, then the chances of your site being exploited are greatly reduced.

php-logo

XMLDom::Save() Permission Problem

I had been hitting my head against the wall when I couldn’t get an edited XML file to save due to file permissions, even though I know that it was OK.

For some odd reason, when I went to save the XML file, it would try to write the file to the root directory, instead of the current working directory (where the file is read from).

As such, using realpath() to keep the complete system path to the XML file when you load it will make sure that DOM isn’t trying to save to the incorrect directory:

$myfile = 'myxml.xml';
$myfile = realpath($myfile);
$doc = new DOMDocument('1.0');
$doc->load($myfile);

// Let's just add a couple of elements for good measure
$root = $doc->documentElement;

$title = $doc->createElement('title');
$title = $root->appendChild($title);

$text = $doc->createTextNode('This is a title');
$text = $title->appendChild($text);

$doc->save($myfile);

a tecchy's blog