Here are some relatively simple steps that should help ‘toughen up’ your WordPress installation:

Don’t use the “admin” account.

Either change the username via MySQL

UPDATE wp_users SET user_login = 'username' WHERE user_login = 'admin'

*where “username” is whatever you want to call it.

Or, create a new/unique account with administrator privileges and delete the original admin account.

From WordPress 3.0 you can set the administrator username and password during the installation process, which is a good step forward.

Use secure passwords.

Use strong passwords to protect your website from dictionary attacks. WordPress will tell you when your password is strong (the admin interface for users has a password strength indicator).

Don’t restrict your strong passwords to the WordPress installation, do the same for FTP, SSH and MySQL as well.

Update the folder permissions on your WordPress files.

A good rule of thumb is to set the following permissions:

Files should be set to 644
Folders should be set to 755

If these settings are too restrictive, i.e. you can’t upload files, change the permissions to increase the privileges (e.g. 775 or even 777).

Remember, permission levels vary depending on your specific server configuration, but you can generally set them to the desired level quite easily via FTP or SSH clients.

For example, with SSH:

find [your path] -type f -exec chmod 644 {} \;
find [your path] -type d -exec chmod 755 {} \;

Move the configuration file (wp-config.php).

From WordPress 2.6 it became possible to move the configuration file up a directory and out of the WordPress root folder.

For example, if WordPress is located in the following directory:

public_html/wordpress/wp-config.php

You can move it to the following directory:

public_html/wp-config.php

WordPress automatically checks the parent directory if the configuration file is not found in your website’s root directory.

This makes it nearly impossible for anyone to access your configuration file as it now resides outside the website’s root directory.

Move the wp-content directory.

Like the configuration file, WordPress 2.6 added the ability to move the wp-content directory to another location.

Once moved, make two additions to the configuration file to identify the new location:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content');
define('WP_CONTENT_URL','http://domain.com/blog/wp-content');

You may also need to define the new location for plugins:

define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins');
define('WP_PLUGIN_URL','http://domain.com/blog/wp-content/plugins');

If hackers can’t find your wp-content folder’s location, clearly it becomes far more difficult for them to hack it.

Stay current with all updates.

The main WordPress installation files, plugins and themes can be updated easily via the admin interface. Make sure you do so each time a new version of either are released.

For plugins, the plugin change log makes it easy to see what has changed and therefore ensure compatibility with your version of WordPress.

Remove the WordPress version information from your header.

Viewing source on most WordPress websites will reveal what version of WordPress the website is running.

<meta name="generator" content="WordPress 3.0.1" /><!-- leave this for stats -->

This helps hackers find vulnerable blogs or determine ways to hack a particular version.

To remove, find the code shown below in your header.php file and delete it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /><!-- leave this for stats -->

The wp_head function also includes the WordPress version in your header. To remove, include the following line of code in your theme’s functions.php file:

remove_action('wp_head','wp_generator');

Use secret keys.

A secret key is a hashing salt, which makes your website harder to hack by adding random elements to the password. These secret keys are found in the WordPress configuration (wp-config.php) file.

Visit the following URL to get the secret keys: https://api.wordpress.org/secret-key/1.1/salt/

Replace the following in the configuration file

define('AUTH_KEY','put your unique phrase here');
define('SECURE_AUTH_KEY','put your unique phrase here');
define('LOGGED_IN_KEY','put your unique phrase here');
define('NONCE_KEY','put your unique phrase here');
define('AUTH_SALT','put your unique phrase here');
define('SECURE_AUTH_SALT','put your unique phrase here');
define('LOGGED_IN_SALT','put your unique phrase here');
define('NONCE_SALT','put your unique phrase here');

With the generated keys (example only):

define('AUTH_KEY','*QCT0a,T+3hxeg)ti7k}#~<AQSmm&x+ff=*$d:)<-;+!a?yS{ArmuR-#*GyLCgI)');
define('SECURE_AUTH_KEY','[)|y._i~B5js,h3@4%M[<l:DJ&]Ou$2|n(e?DJ`+R4pk6um/6zS%6@@i{^N-6(4]');
define('LOGGED_IN_KEY','@+l2X{3wvy/1K[zRm|P_r;WixJ:,>V&JL![gyJq ?b[Wf.W|U_MKutdrL*$l][-S');
define('NONCE_KEY','T$R>#*2)2kO?NIr&o|>[L>T5%YGd^yJ+eE$7wkcL-?1v]-X*{f`Pg)NZqKU}^e8R');
define('AUTH_SALT','<8JD%+O!t.F%]6RaO9L_MI<w2Lw_-Bc5u_(WDdPoO0D;j9zwu*?1i{%nH/RBjF6J');
define('SECURE_AUTH_SALT','oS|EP&Pm`bf8iG!C<X8#yFG%8J)x G+3M`wRBtp#]7)&hj}ZV/p> yh-BtbBRbTk');
define('LOGGED_IN_SALT','tW4|J/m|habEJ+BTvF0PfpuiOgf-6,dIav-5K|FTM$&Agy;FqDjp|5Ci7>nJFD/#');
define('NONCE_SALT','T-v&f++w!c%5zs2t8qH?,n,/WE&uWd--o4t{FL49/4e~|e+HV+.~A?JYZ1Ev<5)u');

You can add or amend the secret keys at anytime. This will invalidate all existing cookies and require users to login again.

Change the WordPress table prefix.

You can define the WordPress database table prefix in the WordPress configuration file. By default, the prefix is set to:

$table_prefix = 'wp_';

Change this to whatever you prefer.

If you already have a version of WordPress installed, you will need to manually amend the database table names in MySQL, or do a clean install and data import.

Force SSL on login and admin access.

Set the following option in the WordPress configuration file to force SSL (HTTPS) on the login and admin screens.

define('FORCE_SSL_LOGIN',true);
define('FORCE_SSL_ADMIN',true);

Use IP lockdown on the wp-admin directory.

Create an .htaccess file in your wp-admin directory with the following lines of code:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny, allow
deny from all
#IP whitelist
allow from 72.14.207.99
allow from 216.239.51.99

Where the IP address lines are whatever your chosen IP addresses are. Only users with these IP addresses will have access to the wp-admin folder and hence the admin part of the blog.

Resources:

• http://codex.wordpress.org/Hardening_WordPress
• http://codex.wordpress.org/Changing_File_Permissions
• http://codex.wordpress.org/Editing_wp-config.php
• http://codex.wordpress.org/htaccess_for_subdirectories

If you have any more suggestions, that don’t necessitate plugins, feel free to comment.

1. Download the Mac OSX disk image from the MySQL website:

   http://dev.mysql.com/downloads/mysql/5.1.html#macosx-dmg

   I used the mysql-5.1.42-osx10.5-x86_64.dmg disk image, which seems to work fine. The image contains 4 files including a ReadMe file.

2. Install the following packages found in the disk image to the default location and with the default options:

   mysql-5.1.42-osx10.5-x86_64.pkg
   MySQLStartupItem.pkg

3. Install the following profile found in the disk image to the default location and with the default options:

   MySQL.prefPanel

4. Start the MySQL service in the System Preferences panel and check the Automatically Start the MySQL Service on Startup option.

That is all you need to do. However, if you’re working with PHP, you will need to correctly reference the mysql.sock file in your php.ini file. To do this, find the following line and ensure the reference is correct:

mysql.default_socket = /tmp/mysql.sock

(Remember to restart Apache if you make changes to your php.ini file.)

1. Enable the PHP5 module in Apache:

   LoadModule php5_module libexec/apache2/libphp5.so

   This will normally involve simply removing the hash symbol (#) at the beginning of the line.

2. Restart Apache via the command line:

   sudo apachectl restart -t

   The -t is used to run a syntax check on the Apache file, to ensure you haven’t broken anything.

3. Locate the php.ini.default file in the /etc/ directory and rename it to simply php.ini by running the following commands:

   cd /etc
   sudo cp php.ini.default php.ini
   sudo chmod 666 php.ini

4. Create a file in the web server’s document root, in this case an index.php file, with the following text included:

   <?php phpinfo() ?>

   When you browse to that file, it will display information regarding your PHP installation. (Be sure to remove this after use and certainly don’t include it in a production environment.)

That is all you need to do. Easy huh?

As a point to note, if you need to make changes to either the http.conf file or php.ini, you will need administrative access and will need to restart the Apache server for the chances to take effect.

The 13 points made by Kevlin were:

• 0. Prefer code to comments.
• 1. Follow a consistent form.
• 2. Employ the contract metaphor.
• 3. Express independent ideas independently.
• 4. Encapsulate.
• 5. Parameterize from above.
• 6. Restrict mutability of state.
• 7. Favor symmetry over asymmetry.
• 8. Sharpen fuzzy logic.
• 9. Go with the flow.
• 10. Let code decide.
• 11. Omit needless code.
• 12. Unify duplicate code.

You can see a video of Kevlin’s presentation on the JAOO website.

For example, the following is WordPress’ default URL configuration for a post:

http://www.domain.com/?p=1635

However, buy using a URL-rewriting available in the Apache webserver, we can achieve a far better result, such as the following:

http://www.domain.com/search-engine-safe-urls

NB. It is also possible to achieve a similar result with an ISAPI rewrite for Microsoft’s IIS webserver, but this topic will not be included in this post.

To get your website working with SES URLs you need to enable both the mod_rewite module and AllowOverride directive in the Apache configuration file.

Uncomment (remove #) from the following to enable the re-write rule:

LoadModule rewrite_module modules/mod_rewrite.so

Change the AllowOverride directive from none to all

<directory />
    Options FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
</directory>
 
<directory "C:/WebRoot">
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.2/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks
 
    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride All
 
    #
    # Controls who can get stuff from this server.
    #
    Order allow,deny
    Allow from all
</directory>

On Apache webservers, .htaccess (hypertext access) is the default name of directory-level configuration files. An .htaccess file is placed in a particular directory, and the directives in the .htaccess file apply to that directory, and all its subdirectories. It provides the ability to customize configuration for requests to the particular directory. In our case, enabling search engine safe (SES) URLs.

By setting the AllowOverride directive to All in effect defers configuration settings to the .htaccess file.

An example .htaccess file could include the following code to rewrite the URLs:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,QSA]

Search engine friendly URLs are implemented with Rewrite engines. The rewrite engine modifies the URL based upon a number of rewrite conditions and rules.

The RewriteBase directive explicitly sets the base URL for per-directory rewrites. The RewriteCond directive defines a rule condition, so in this case handling missing files or directories. Finally, the RewriteRule directive is the real rewriting workhorse. In this example, we’re getting everything in the URI — i.e. not including the protocol (HTTP/S) and domain name — based upon a regular expression. This is then appended to the default file reference — index.php — as a back reference. The [L,QSA] refers to the rule being the last rule and append any query string parameters to the default file. It is important to note that this is all done on the server side, the user will never see the website address changing in the browser’s address bar. Furthermore, simply transposing the index.php filename with your default file name — e.g. index.cfm, default.aspx — will have the same result. Indeed, the above rewrite rules are becoming a de-facto standard for web applications.

To fully understand mod_rewrite rules above, look at the Apache mod_rewrite documentation.

Once you have your SES functionality in place on the webserver, it is then the responsibility of your application framework to understand the URL construction and handle it accordingly. Fortunately, frameworks such as ColdBox and Fusebox for ColdFusion, Zend and Symfony for PHP, all contain functionality to do this, but that is the subject of an entirely different post.

Users of web applications prefer short, neat URLs to raw query string parameters. A concise URL is easy to remember, and less time-consuming to type in. If the URL can be made to relate clearly to the content of the page, then errors are not only less likely to happen, but our good friends the search engine robots are able to draw a stronger assumption of the pages’ relevance and content.

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.

In this post I will show you how to implement the AutoCompleter plugin by Harald Kirschner. Kirschner’s AutoCompleter plugin script for MooTools provides the functionality for text suggestion and completion. It features different data-sources (local, JSON or XML), a variety of user interactions, custom formatting, multiple selection, animations and much more.

The Goal

The goal of this post will be the same as the jQuery autocomplete post: Allow the user to type a few characters into a standard form text input field and to automatically provide suggestions from which the user can select.

Prerequisites

1. The latest copy of MooTools
2. A basic understanding of JavaScript and JSON
3. A server-side script that can respond to the AJAX request, in our case ColdFusion

Demo

The demo below will show how to interact with a simple ColdFusion script, but I’ll also provide more (advanced) examples in the download.

How It Works

Once the user begins to type into the form text input field, the MooTools auto-complete is activated. After a set character length and time interval (both optional), a list of items is displayed below the input field. The user can select an item with either the arrow keys or mouse.

NB. Clicking back in the input field will repopulate the auto-complete list, if options are available, so that the user can change the selection. Deleting part of the chosen item will also trigger a new selection list.

The Code

There are three parts to this demo:

1. The page’s HTML.
2. The server-side code to produce the dynamic page (i.e. to load the autocomplete div when the user types something into the input field).
3. The MooTools JavaScript.

HTML Form

<h1>Example: Country Lookup</h1>
<p>Using <abbr title="Asynchronous JavaScript and XML">AJAX</abbr> to interrogate the database.</p>
<p>Example data: Australia, Bulgaria, United Kingdom</p>
<form name="frmAutoCompleteCountry" id="frmAutoCompleteCountry" action="#" method="post">
<p>
<label for="country">Country</label>
<input type="text" name="country" id="country" />
</p>
</form>

ColdFusion

Below is a simple ColdFusion component that takes a string as an argument. This string is part or all of the country name. The query results are parsed as an array and returned from the function, as JSON, to the MooTools auto-complete function.

<cfcomponent output="false">
 
	<cffunction name="getCountry" access="remote" output="false" returntype="array" returnformat="json">
		<cfargument name="country" type="string" required="true" />
 
		<cfset var qryCountry = queryNew('country') />
		<cfset var arrCountry = arrayNew(1) />
 
		<cfquery name="qryCountry" datasource="test">
		SELECT countryName
		FROM country
		WHERE countryName LIKE <cfqueryparam value="%#ARGUMENTS.country#%" cfsqltype="cf_sql_varchar" />
		</cfquery>
 
		<cfloop query="qryData">
			<cfset arrCountry[currentRow] = qryCountry.countryName[currentRow] />
		</cfloop>
 
		<cfreturn arrCountry />
	</cffunction>
 
</cfcomponent>

JavaScript

The JavaScript will attach itself after the DOM is ready — this more or less relates to when the page has loaded in the browser. Each time the text input field, with the ID of country, is changed, the Autocompleter.Ajax.Json event is fired. This makes a call to the ColdFusion component, which returns a JSON object of matched items. This JSON object is interpreted by the plugin and rendered as an HTML un-ordered list.

<script type="text/javascript" src="mootools.js"></script>
<script type="text/javascript" src="Observer.js"></script>
<script type="text/javascript" src="Autocompleter.js"></script>
<link rel="stylesheet" href="Autocompleter.css" type="text/css" media="screen" />
<script type="text/javascript">
window.addEvent('domready', function() {
	new Autocompleter.Ajax.Json(
		'country',
		'data/Country.cfc?method=getCountry&returnformat=json&country=' + $('country').getProperty('value')
		, {
			'minLength': 1, // We wait for at least one character
			'overflow': true // Overflow for more entries'
	});
});
</script>

Where to Take it Next

Unobtrusive JavaScript

As with any page that is loaded with JavaScript and AJAX functionality, it should work without JavaScript.

To achieve this with the above tutorial, you will need to replace the MooTools autocomplete functionality with an ‘interim’ page that allows a user to select from a list of items, effectively turning the input field into a simple search interface. Of course, all other form field information would need to be retained between pages.

Download the Code

The example code can be downloaded from the demo page. Included are ColdFusion and PHP examples.

Happy 13^th Birthday ColdFusion.

Adobe ColdFusion has had a long and illustrious life. The first version of ColdFusion–written almost entirely by one person, JJ Allaire and then called “Cold Fusion”–was released in 1995. This first version, although revolutionising how web applications were built, was primitive by modern standards, doing little more than database access.

Although originally built in Visual C++, Allaire, around 1999, took the decision to rewrite the entire ColdFusion engine in Java–a project named “Neo”–which would allow for greater portability among different platforms. The rewrite, released under the monicker MX 6, would prove to be somewhat problematic and a wholescale update to the version resulted.

In 2001 Allaire was acquired by Macromedia. This union brought with it the integration of Macromedia’s Flash platform via Flash Remoting; a huge step towards rich Internet applications.

In 2005 it was the turn of Macromedia to be acquired and they merged with Adobe. A period of instability in the ColdFusion world resulted, brought about by the knowledge that Adobe was a company that developed tools, not programming languages. However, following a successful release of ColdFusion 8 in 2007 and the announcement that a version 9 would be developed, code-named “Centaur”, fears about ColdFusion’s future have subsided–albeit the continued debate over “ColdFusion is Dead” remains boiling in the background.

The primary distinguishing feature of ColdFusion is its associated scripting language, ColdFusion Markup Language (CFML), which compares favourably to its rivals, JSP, ASP.NET, or PHP and resembles HTML in syntax. “ColdFusion” is often used synonymously with “CFML”, but it should be noted that there are additional CFML application servers besides ColdFusion, and that ColdFusion supports programming languages other than CFML, such as server-side Actionscript and embedded scripts that can be written in a JavaScript-like language, known as CFScript. Adobe ColdFusion also includes native support for Flex, PDF, Verity and the embedded Derby database amongst a host of other features.

ColdFusion 9 is set to be an exciting release, much like its predecessor, with more features added to the core tag set, whilst also integrating other technologies such AIR and Hibernate.

Exciting times lay ahead. Let’s hope Adobe takes full advantage with such a fine product.

See Also:

• ColdFusion Wikipedia entry
• ColdFusion Markup Language Wikipedia entry
• Railo – Free, Open Source alternative CFML Engine
• SmithProject – Free, Open Source alternative CFML Engine
• BlueDragon – Free, Open Source alternative CFML Engine

Richard Titus, the Acting Head of User Experience at the BBC was a key driver of the project.

From a conceptual point of view, the widgetisation adopted by Facebook, iGoogle and netvibes weighed strongly on our initial thinking.

Titus identifies the key features of the new homepage as being:

• Simple, clean and beautiful, the final design, … visually striking yet unpretentious.
• Personalization: you can choose the content that interests you by adding and removing the content boxes via the “Customise Your Homepage” tab.
• Localization: Users can now set their own location, enabling them to access local sites, weather, news, radio and TV schedules without the hassle often associated with user journeys to local content.
• Simplicity: the customization is intuitive and includes an interactive demo and tips to guide users through the process. It is also unobtrusive if the user has no desire to customize their page their experience won’t be compromised.
• Search: The site is much easier to read and scan at a glance. At the top of the page there’s a search function (now reduced from two search boxes to one), and at the bottom a full directory of all BBC sites and a link to the A-Z, allowing users to quickly find what they’re looking for.
• Nostalgia: the new homepage also manages to incorporate eccentricity alongside innovation.

Aesthetically bold and bright.

Aesthetically, the new homepage looks nice. It’s big, bold and bright – a far cry from the old days when BBC sites had text almost too small to read and a fixed-width design optimised for tiny monitors. But at the same time it appears far too clunky! I’d prefer something that would look a little more elegant and understated. Something that doesn’t appeal to The Facebook Generation, who are less likely to read the BBC pages at lunchtime, than update their Facebook, Bebo or Twitter profile during that ‘valuable’ hour. This begs the question, does the BBC know who their core audience is?

Confusing interactions.

The homepage makes great use of AJAX, but at the same time, there are a number of confusing interactions going on. For instance, the ‘Edit’ button next to each area of customisable content seems like the wrong label text. I’m not editing the news, the weather or blogs – I’m selecting which news categories I want to see, where I am and which blogs I want to read. These types of button ought to be contextual rather than generic. Edit is simply too vague.

Also, what’s the idea behind those plus and minus buttons for news? Strange idea. Add or remove articles from the displayed list? Why would you want to remove them from view sequentially? If the idea was to allow the user to asynchronously update a short list of available headlines, then why not move back/forwards in blocks of five? Plus and minus are often used as metaphors for creation/deletion in software, so the usage doesn’t seem right.

Personalisation vs Simplicity … an uneasy relationship

The ability to personalise a website is, in general, a good thing. Google has done it with their iGoogle, Yahoo! with My Yahoo and Microsoft with Windows Live. But I think the balance here is gone too far towards design and borrowing from succesful Web 2.0 sites. The BBC website has always been an impressive destination for (relatively) impartial news and current affairs throughout the world, not a Web Portal. Or is this the point? Does the BBC want to become a destination for all your information needs and compete with Google, Microsoft and Yahoo?

The BBC should consider that 14-25 year old users, what I term The Facebook Generation, will require far greater scope for adding their individuality than is currently available. The social networking generation are page-savvy. They want control of their interface to information, their screen is their window on the world and I don’t think that you have gone far enough in divesting control of the display of that information to the user.

But for those who aren’t part of The Facebook Generation, the people who care about getting to the content fast and with little fuss, is the ability to personalise the homepage worthwhile or even simple? I’m not so sure.

Who needs a clock?

Finally, the clock and date. What an important waste of webpage ‘real estate’, even though in the BBC‘s case I understand it was a throwback to the old clock that preceded individual TV programmes. If you’ve got a modern computer capable of displaying the clock with the Flash plugin, then you’ll almost certainly have the date and time visible to you anyway. It’s needlessly superfluous on a website.

Since I’m a ColdFusion developer, it was necessary to write a language reference file for ColdFusion and in particular, version 8.

You can download the file (30KB) here and upload it into your website’s GeSHi folder. You will need to rename it to cfm.php.

By including the content between a set of pre tags, <pre lang=”cfm”></pre>, GeSHi will implement the correct syntax for ColdFusion.

The task I was trying to achieve was the installation of development versions of WordPress, Drupal, MediaWiki and Moodle, all of which would require a MySQL database. Trying to load the MySQL extension should have been a simple case of uncommenting the line in the php.ini and restarting the Apache service. With Vista, this was certainly not the case.

I set up a very simple page detailing the php configuration in an index.php file:

< ?php phpinfo(); ?>

This showed me the default configuration path of my php.ini and extensions directory, amongst a whole host of other information.

In both cases the paths were incorrect. First and foremost the configuration file path stated C:\Windows when in fact I had installed it in the root (C:\PHP5). So, although I was amending the php.ini file with the correct detail, Vista was using the default values. If there is no php.ini file in Windows, then you’ll continue banging your head against a brick wall.

The problems didn’t stop there. Moving the php.ini file to the Windows directory under Vista isn’t a simple copy and paste task. You need to be administrator. But Vista’s administrator priviledges are more pseudo than actual! In order to amend and save the php.ini file in the Windows directory, you must run Notepad as administrator and save the file as such. Voila! Everything then works. The phpinfo() function returned the correct installation detail and I could continue with the job I was meant to be doing.

PS. Thanks to Rob Douglas for his help.