The following SQL can be used to delete the old post revisions and free up some space for your database.

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Of course, it’s a good idea to back up your database prior to deleting anything.

If you don’t want or need post revisions, you can add this line to your config.php to turn them off completely.

define('WP_POST_REVISIONS', false);

jQuery, a JavaScript library, is definitely something worth knowing. Here are some resources to help you learn and master it.

• jQuery Fundamentals by Rebecca Murphey, with contributions from James Padolsey, Paul Irish and others, is a free e-book available in HTML. It includes an overview of JavaScript as its first chapter, to help developers get up to speed.
• Essential JavaScript & jQuery Design Patterns by Addy Osmani is a free e-book of design patterns for those who already know jQuery but want to take their skills to the next level.
• Official jQuery Documentation

ANALYZE TABLE table_name

However, this doesn’t give you much information beyond “status=OK”.

Alternatively, the ANALYSE() procedure built into MySQL can give you a wealth of information about your database tables, making it easy to find out which tables need optimising.

SELECT * FROM table_name PROCEDURE ANALYSE()

NB. change table_name to be your desired table name…obviously! Oh and “analyse” is the English (UK) spelling.

You’ll get a number of results back including the minimum/maximum value, minimum/maximum length, number of empty or zero strings, number of nulls, the average value/length, the standard deviation, and a suggested optimal field type for every row in the queried table.

Of course, optimising your tables isn’t necessarily that helpful if you don’t have much data. Furthermore, optimisation isn’t simply a case of running the OPTIMIZE TABLE function on each of your tables.

The essay contrasts two different free software development models: The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers; and, The Bazaar model, in which the code is developed over the Internet in view of the public.

The essay helped convince most existing open source and free software projects to adopt Bazaar-style open development models, fully or partially

Raymond posits that there are 19 guidelines for creating good open source software:

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. Plan to throw one away; you will, anyhow.
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible – and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

1. Open up your Applications folder and find your old version of Firefox.
2. Right click -> Get Info.
3. Rename to “Firefox36.app”.
4. Download Firefox 4.0 and install as normal.

Voilà! You now have more than one Firefox browser to play with.

That was really simple huh? If someone knows how to do this on the Windows and Linux side, I would love to hear how.

The most common mistake people make when thinking of URL redirection with mod_rewrite, is they believe it creates something, or changes something. It doesn’t.

Here is a simple example, redirecting a page dependent upon its query string. The rewrite condition and rule looks like this:

RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^page\.php$ http://www.example.com/page/%1.php [R=302,L]

The rewrite condition matches a numerical ID between 0 and 9. According to the official documentation, you would expect the following behaviour:

/page.php?id=1 -> http://www.example.com/page/1.php
/page.php?id=10 -> http://www.example.com/page/10.php

However, if you don’t append something new, then the original query is passed through by default. This results in the following:

/page.php?id=1 -> http://www.example.com/page/1.php?id=1
/page.php?id=10 -> http://www.example.com/page/10.php?id=10

If you want to discard the original query string you must append an empty question mark at the end of the rule; the query string not append or query string discard flag.

RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^page\.php$ http://www.example.com/page/%1.php? [R=302,L]

Putting it all together, here’s a quick reference for dealing with query string in a RewriteRule.

Keep original query (i.e., the default behaviour)

RewriteRule ^page\.php$ /target.php [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?foo=bar

Discard original query

RewriteRule ^page\.php$ /target.php? [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php

Replace original query

RewriteRule ^page\.php$ /target.php?bar=baz [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?bar=foo

Append new query to original query

RewriteRule ^page\.php$ /target.php?bar=baz [QSA,L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?foo=bar&bar=foo

Dave Child has created a great mod_rewrite cheat sheet; a one-page reference sheet, listing flags for the RewriteRule and RewriteCond directives, list of server variables, a regular expression guide and several examples of common rules.

Redirect /page.php http://www.example.com/target.php

More commonly, however, you’re likely to want to do a mass-redirection of pages. To accomplish this, you may use the RedirectMatch directive.

RedirectMatch ^/category/(.*)$ http://www.example.com/topic/$1

This will redirect any page from the category folder to the corresponding one in topic folder with a convenient one-by-one redirect.

However, neither Redirect nor RedirectMatch allow you to specify a query string for the redirect source. In other words, the following statements are invalid and they’ll simply be ignored.

# single page redirect
Redirect /page.php?id=1  http://www.example.com/page/1
Redirect /page.php?id=10  http://www.example.com/page/10
 
# multi-page redirect
RedirectMatch ^/page.php?id=([0-9]*)$  http://www.example.com/page/$1

The solution requires a change of focus from Apache’s mod_alias module to the mod_rewrite module. Here’s an example.

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/page\.php$
RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^(.*)$ http://www.example.com/page/%1.php [L,R=301]

The mod_rewrite module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, of server variables, environment variables, HTTP headers, or time stamps.

So what does this all mean with respect to the above example?

The first line enables the RewriteEngine module. Note that mod_rewrite Apache module must be installed and enabled in order to use the RewriteEngine.

The RewriteCond statements set all the rewrite conditions. The fourth line, the real rewrite directive, will be executed if and only if all conditions are satisfied by the current request.

The first condition is for the page I need to redirect. This condition is included to prevent any unexpected errors if other pages are using the ID variable. Next, I base the rewrite rule on the value for the current request’s query string. The ID value within the regular expression is “wrapped” to be able to reuse the match later as a back-reference.

The final line is the rewrite rule. This line looks similar to the RedirectMatch statement. It specifies the redirection source, then the redirection target. The value captured by the second RewriteCond is referenced in the target with the %N keyword (in this example %1). The RewriteRule also includes a comma-separated list of flags that should be applied to the rule. In this case, L stops the rewriting process immediately whilst R=301 specifies a permanent external redirect (301 is an HTTP Status Code).

Further reading:

• Apache URL rewriting guide
• Apache mod_rewrite
• Apache mod_alias

/usr/sbin/apachectl: line 82: ulimit: open files: cannot modify limit: Invalid argument

After a little investigating it turned out to be caused by an update in the apachectl script to OSX 10.6.5.

The ULIMIT_MAX_FILES variable increases the maximum number of file descriptors allowed per child process. This is critical for configurations that use many file descriptors, such as mass vhosting, or a multithreaded server.

A quick edit of the the apachectl script and it’ll be back working.

I use TextMate, so the command is:

sudo mate /usr/sbin/apachectl

You’ll be prompted for your password.

Once the apachectl file is open, look for the following line (for me it was line 64):

ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"

and replace with the following:

ULIMIT_MAX_FILES="ulimit -S -n"

This will set the correct command that increases the maximum number of file descriptors allowed per child process.

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.

If you want — and this is the default setting for WordPress, themes and plugins — you can just download jQuery, put it on your server and link to it from your header.php file in the <head> section.

However, it is better to use the proper wp_register_script() function, which can be achieved in your functions.php file:

if( !is_admin() ) {
   wp_deregister_script('jquery'); 
   wp_register_script(
   	'jquery',
   	("http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"),
   	false,
   	'1.4.2'
   ); 
   wp_enqueue_script('jquery');
}

The reason we use the wp_register_script() is to ensure that WordPress and its themes and plugins are aware that the script has been loaded and therefore not to load an additional copy.

I have also used the is_admin() function to prevent conflict and therefore errors, in the WordPress administrator.

Of course, this method is not only restricted to jQuery, you can do the same for other popular JavaScript frameworks such as Mootools.

Further information on the wp_enqueue_script can be found on the WordPress Codex.