What are they?

I think what happened is that the restoration database that we ended up using had been opened in a file/text editor. It’s just a guess, and sort of irrelevant, but the text editor converted our UTF-8 characters into some other character set, like ISO-8859-1. So after restoration, we ended up with hundreds of these weird characters in the database – quotes, hyphens, dashes, and ellipses were all converted to Klingon:

“ = left quote = “
” = right quote = ”

‘ = left single quote = ‘
’ = right single quote = ’

— = en dash = –
– = em dash = —

• = hyphen = -
… = ellipsis = …

Identifying most of these characters was relatively painless, but the en-dash and em-dash characters may be reversed (i.e., – = em dash, and — = en dash). Testing the other character replacements in the database was easy, but discerning between instances of em & en dashes proved futile. So do your own testing and make good backups before making any mass changes. Hopefully someone can help us out with more of the specifics.

Clean ‘em up

Before making any changes to your database, make sure you have a good backup (or three). Then to clean up these weird characters from the WordPress database, use a program like phpMyAdmin to execute the following queries.

Clean up post_content

UPDATE wp_posts SET post_content = REPLACE(post_content, '“', '“');
UPDATE wp_posts SET post_content = REPLACE(post_content, '”', '”');
UPDATE wp_posts SET post_content = REPLACE(post_content, '’', '’');
UPDATE wp_posts SET post_content = REPLACE(post_content, '‘', '‘');
UPDATE wp_posts SET post_content = REPLACE(post_content, '—', '–');
UPDATE wp_posts SET post_content = REPLACE(post_content, '–', '—');
UPDATE wp_posts SET post_content = REPLACE(post_content, '•', '-');
UPDATE wp_posts SET post_content = REPLACE(post_content, '…', '…');

Clean up comment_content

UPDATE wp_comments SET comment_content = REPLACE(comment_content, '“', '“');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '”', '”');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '’', '’');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '‘', '‘');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '—', '–');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '–', '—');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '•', '-');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '…', '…');

Other tables

While cleaning up the DigWP database, several other weird characters also showed up in various places, but they were very few in number. I also noticed several instances of converted quotes, dashes, and hyphens scattered around in some other tables, mostly in the options table, buried deep within temporary rss_ data. So I didn’t bother with anything beyond the post_content and comment_content tables, but easily could have done so by modifying the previous queries like so:

UPDATE [table_name] SET [col_name] = REPLACE([col_name], '…', '…');

Just replace [table_name] with whatever table you want to clean up, col_name with the column name, and then replicate or edit the query with the proper character replacements.

Lesson learned

Take-home message: don’t open your database in a text editor. But if you do, execute these SQL queries for easy clean-up.

© 2011 Digging into WordPress | Permalink | 20 comments | Add to del.icio.us | Post tags: database, mysql, sql, tips

By default, during installation, WordPress creates the database with all of the tables prefixed with “wp_”. There are 11 tables created in the default installation procedure, and all of them will prefixed with wp_:

Install WordPress out-of-the-box and that’s what you’re going to get. And would-be attackers understand this perfectly. Automated scripts that target the WordPress database aim for these default table names during their attacks. I think it’s fair to assume that a vast majority of WordPress databases are using the default wp_ prefix. This is bad because it makes attacking WordPress sites easier for the bad guys.

Fortunately you can improve your site’s security by changing the default table prefix to something completely random and unique. There are two ways to change your database prefix: the easy way and the hard way. Which you use will depend on if you’ve already installed your WordPress site or not..

Changing default table prefix before installing WordPress

First let’s look at the easy way. Before installing WordPress, while configuring the wp-config.php configuration file with your database credentials, scroll down the file a bit until you see this:

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

Just replace the “wp_” with a string of random, unique characters and you’re all set: continue with the installation as normal and your database prefix will have been changed to something more secure. Here’s an example of a strong database prefix generated at Random.org:

wp_VzQCxSJv7uL_

Notice two things that will help keep your database nice and organized:

1. begin the prefix with “wp_” so the tables appear in order among other tables
2. end the prefix with an underscore (“_”) so the actual table names (e.g., posts, users, meta) stand out and are easily recognizable.

But really you can use whatever prefix you want – the take-home message here is that you should obscure your tables’ prefix and it’s easiest to do before installing WordPress.

But wait! I’ve already installed WordPress and have been using it for all sorts of stuff.. is it still possible to change my prefix? Absolutely there is, but it takes quite a bit more time to get it done.

Changing default table prefix after installing WordPress

If you’ve already installed WordPress and want to change your database prefix, you’re stuck with the hard way. But it’s really not that hard, just hard compared to changing a single line in your wp-config.php (as shown above). To change your prefix after installing, set aside around ten minutes and follow these steps:

Step 1: Preparations

Before changing your table prefix, make sure you have a recent backup and about 10 minutes of downtime for your site. It may be a good idea to redirect visitors to a temporary maintenance page.

Step 2: Change table prefix

Change your database table prefix in wp-config.php from wp_ to something more secure, like wp_VzQCxSJv7uL_ or something.

Step 3: Change all WordPress database tables

Go to your database (using phpMyAdmin or whatever) and rename all WordPress table prefixes from wp_ to whatever you specified in your wp-config.php file. Here are SQL commands to rename the 11 default WordPress tables:

RENAME table `wp_commentmeta` TO `wp_VzQCxSJv7uL_commentmeta`;
RENAME table `wp_comments` TO `wp_VzQCxSJv7uL_comments`;
RENAME table `wp_links` TO `wp_VzQCxSJv7uL_links`;
RENAME table `wp_options` TO `wp_VzQCxSJv7uL_options`;
RENAME table `wp_postmeta` TO `wp_VzQCxSJv7uL_postmeta`;
RENAME table `wp_posts` TO `wp_VzQCxSJv7uL_posts`;
RENAME table `wp_terms` TO `wp_VzQCxSJv7uL_terms`;
RENAME table `wp_term_relationships` TO `wp_VzQCxSJv7uL_term_relationships`;
RENAME table `wp_term_taxonomy` TO `wp_VzQCxSJv7uL_term_taxonomy`;
RENAME table `wp_usermeta` TO `wp_VzQCxSJv7uL_usermeta`;
RENAME table `wp_users` TO `wp_VzQCxSJv7uL_users`;

If there are other WordPress-related tables from plugins or whatever, just rename them too. The goal here is to rename all of the tables that begin with the default prefix. If you’re using something like phpMyAdmin to interface with your database, you can execute multiple commands at the same time, so edit the above code with your table prefix, paste it into the SQL field, and WHAM! – all tables changed in the blink of an eye.

Step 4: Edit the WordPress options table

Now search the options table for any instances of the old prefix. To do this, enter the following SQL query:

SELECT * FROM `wp_VzQCxSJv7uL_options` WHERE `option_name` LIKE '%wp_%'

That search will return the wp_user_roles option along with any other options created by plugins, custom scripts, etc. The goal here is to rename any options that begin with wp_ to the new prefix.

Step 5: Edit the usermeta table

Now search the usermeta for all instances of the old wp_ prefix. Here is an SQL command to accomplish this:

SELECT * FROM `wp_VzQCxSJv7uL_usermeta` WHERE `meta_key` LIKE '%wp_%'

Executing that query on a recently installed WordPress database, the following usermeta fields were returned:

The number of fields that you need to rename may vary depending on plugins and other factors, but as before, just remember to rename any entry that begins with the default WordPress table prefix, wp_.

Final Step: Test, backup, and done!

Ideally at this point, all instances of the old table prefix (wp_) have been replaced with the new (wp_VzQCxSJv7uL_ in our example). Once this is done, go check your site for proper functionality. Test the Admin, pages, posts, search, and everything else you can think of (or have time for). If your site seems to be working as before, chances are good that the surgery was a success. Now make another database backup for good measure.

Wrap Up

Securing WordPress involves securing your database. The default table prefix is well-known and targeted by nefarious scumbags across the Web. Changing your prefix to something obscure and difficult to guess is an easy way to stop automated attacks, malicious scripts, and other evilness from compromising your precious database. And remember – always, always, always keep recent backups. If something goes awry with your database, the easiest way to restore sanity is to upload a recent backup and call it done.

© 2010 Digging into WordPress | Permalink | 29 comments | Add to del.icio.us | Post tags: config, database

And it’s pretty easy too – just get your database credentials in place and you’re done. The other settings available in the wp-config.php file will work just fine using the default values, but there are some cool things you can do to customize functionality, tighten security, and improve performance. Once you get the basics of wp-config.php, you can really pimp it out to do some awesome stuff. We’ll break this down into four basic parts:

• Basics
• Security
• Main Settings
• Additional Tips and Tricks

There is no wp-config.php..

When you first download WordPress, the wp-config.php file isn’t included. Instead, you get a file named “wp-config-sample.php” (located in the root install-directory) that contains everything you need. Just rename the file to “wp-config.php” and delete the wp-config-sample.php file from the server if it’s already there. Here is a visual:

With the wp-config.php file now ready to go, it’s time to protect it..

Protect wp-config.php

The first thing you want to do with wp-config.php is protect it. Here is a great way to secure the file using .htaccess:

<Files wp-config.php>
	Order Allow,Deny
	Deny from all
</Files>

This code should be placed in an .htaccess file located in the directory that contains your wp-config.php file.

Once the .htaccess file is in place, ensure that permissions are chmod 640 for both files. This setting returns a “403 Forbidden” error to all external requests. Combining proper file permissions with .htaccess protection is an excellent way to secure your wp-config.php.

Main Configuration Settings

Now that wp-config.php is secure, it’s time to add the required database information and then customize for optimum performance. This section covers the first four configuration settings that you’ll find already included in your wp-config.php. Then in the next section, we’ll explore some awesome techniques and really pimp things out.

1) Database credentials

The first and only required step is to add your database credentials. This should appear after the PHP comments near the top of the file:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

For most servers, you’ll need only the first three bits of information: database name, username and password. If WordPress can’t connect after that, then you may need to change the hostname to whatever your host tells you. Only fiddle with the last two items – charset and collate – if you have need and know what you’re doing.

2) Authentication Unique Keys and Salts

Next up is a section for key/salt definitions. By default it looks like this:

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
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');

/**#@-*/

The eight definitions should be replaced with values generated via the official WordPress.org secret-key service. Visit that link, refresh the page a few times, and paste the results into place, like so:

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         ')` 4yDGc w=*:l8@RD167k0+/+@+rgo(mI-x<_~.=WtCm[qD8<3S)TsR}K~bMLNT');
define('SECURE_AUTH_KEY',  'zO?htRkV.k[vBqn<+.,lorpObkc?@|Vi+8`w=A9,|FjPB&5`5|9<[&&WaUB.pwTS');
define('LOGGED_IN_KEY',    'jtr|J-/.-:6CVh*8h.~bNzc3^#A9@hB9G3E/fx/>k)pmTHbES5^Rq(+EINCW w>8');
define('NONCE_KEY',        'O2Vz+br+`6MqQVv1{-g}sy -CF8M/tldEyWV[W}dnebd7m$6.P,m+.G6Ec]{V@Kl');
define('AUTH_SALT',        '>x,, 8wMLIJCH}i94Ib+}~lR%r_))x@LU3~YJwCok++xaSVE@[My(zAg!Fpi4{NR');
define('SECURE_AUTH_SALT', '7[,gAJ#TQmsw:$!R-n-r%4<UvG7%|-7&jt4]XS-[KX&O)|H,err]<{EuFnmP3,M}');
define('LOGGED_IN_SALT',   '9dJP8uW2E2&.^a|@I|[?qbY%z:&jgnH<OUg+t6Tks,Hox=M@~yx+b;~zU)436q=+');
define('NONCE_SALT',       '=Xv~8+!>l:wy`~w0U-6wO2lmG8l5Xg21$J59T$T~)(h5m<5`|/|dVN{j[80QMV60');

/**#@-*/

Don’t use the example keys shown here though – the whole idea is to specify unique phrases to improve security. And it’s totally fine to replace these keys at any time – the worst that will happen is that currently logged-in users will need to log in again.

At this point, we have our database credentials and secret keys all ready to go. Next we want to further improve security by specifying a unique database prefix.

3) WordPress Database Table prefix

WordPress is a huge target for malicious scripts, hacks, and spam. One of the best ways to secure your WordPress database is to change the default table prefix. The default value, as seen below, is “wp_”:

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

This works, but as the default value, it is heavily targeted by malicious scripts and bad bots. Changing it to something unique essentially immunizes it against automated attacks on anything prefixed with wp_. The more random and unique the better, like a password: “h7G3vcDEo3jDf_” would be a good example. Note that ending the string with an underscore or some other easily recognizable character is a good way to keep things readable and easy to use.

4) WordPress Localized Language

By default WordPress uses the English language, but you can use any available language by following these steps. As a part of that process, you’ll specify your language in this part of the wp-config.php file:

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define ('WPLANG', '');

It’s pretty straightforward: if nothing is specified (as is seen here), English is used; otherwise, you include the .mo language file you are using for the translation.

Additional Tips and Tricks

Now that you’ve got the database connection, security keys, table prefix, and language definition dialed in you’re ready to rock. Most WordPress sites are in great shape at this point, but there is much more that we can do with wp-config.php to maximize performance and make our lives easier.

Pimping Post Revisions

Recent versions of WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, here are a couple of configurational definitions that may prove useful for you:

// Limit the number of saved revisions
define('WP_POST_REVISIONS', 3); // any integer, but don't go crazy

// Disable the post-revisioning feature
define('WP_POST_REVISIONS', false); // kill the bloat

Specify the Autosave Interval

In a similar vein as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want. Don’t get too crazy though, unless you want to stress-out your server ;)

define('AUTOSAVE_INTERVAL', 160); // in seconds, don't go nuts

Automated Trash

Since WordPress 2.9, we’ve had the “Trash” feature to help prevent accidents. So now instead of deleting stuff like posts and comments, you send them to the Trash. By default WordPress deletes the Trash every 30 days, but you can set it to whatever you want by adding a line like this to wp-config.php:

define('EMPTY_TRASH_DAYS', 7); // empty weekly

To ride bareback without the safety net, you can disable the Trash feature by specifying a zero value:

define('EMPTY_TRASH_DAYS', 0); // disable trash

By disabling Trash, you’ll be deleting stuff permanently the first time, just like way back in the day.

Automatic Database Repair

WordPress 2.9 also gave us automatic database repair, which enables you to repair and optimize your database even when not logged in. This functionality should be used on an as-needed basis by first adding the following snippet to wp-config.php:

define('WP_ALLOW_REPAIR', true);

With that in place, visit the following URL to open the “Database Repair” page:

http://example.com/wp-admin/maint/repair.php

There you’ll be able to optimize and repair your database without needing to log in to WordPress. Important: While you have WP_ALLOW_REPAIR set in wp-config.php, the Database Repair page is openly accessible by anyone who finds it. So definitely remove the line to disable the auto-repair functionality after you are done using it.

Block External Requests

If you need to prevent WordPress from making external requests, add this snippet to wp-config.php:

define('WP_HTTP_BLOCK_EXTERNAL', true);

This will prevent things from happening that normally happen, like updates, dashboard feeds, and data reporting. Fortunately, it’s easy to whitelist (allow access) anything that is needed. Here is an example where we grant access to pingomatic.com:

define('WP_ACCESSIBLE_HOSTS', 'rpc.pingomatic.com');

Blog Address and Site Address

By default, these two configurational definitions are not included in the wp-config.php file, but they may be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Example:

define('WP_HOME', 'http://digwp.com'); // no trailing slash
define('WP_SITEURL', 'http://digwp.com');  // no trailing slash

These settings should match those specified in your WordPress Admin. Once you set them in wp-config.php, they will be “grayed-out” when displayed in the Admin.

Debugging WordPress

Since WordPress version 2.3.1, users have been able to display certain errors and warnings to help with the debugging of their site. As of WordPress version 2.5, enabling error reporting raises the reporting level to E_ALL and activates warnings for deprecated functions. By default (i.e., if no definition is specified in the wp-config.php file), error reporting is disabled.

define('WP_DEBUG', true); // debugging mode: 'true' = enable; 'false' = disable

Adding that snippet to wp-config.php tells WordPress to display warnings and error messages with your web pages. This functionality is extremely useful but infrequently used by plugin and theme developers. If you’ve never enabled debugging, you’re in for a surprise – lots of errors even with some of the most popular plugins.

Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called php_error.log, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code and place into your wp-config.php:

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/path/domain/logs/php_error.log');

Error logs are powerful tools for keeping an eye on things and expediently resolving issues. It’s awesome that WordPress makes this so easy. We cover this in greater depth along with a couple of other methods in this post.

Increase PHP Memory

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. As of WordPress version 2.5, the WP_MEMORY_LIMIT definition enables you to specify the maximum amount of memory that may be used by PHP. Here are some examples:

define('WP_MEMORY_LIMIT', '64M');
define('WP_MEMORY_LIMIT', '96M');
define('WP_MEMORY_LIMIT', '128M');

By default, WordPress will automatically attempt to increase PHP memory up to 32MB, so this setting is only needed for values higher than 32MB. Note that some web hosts disable your ability to increase PHP memory, so you may need to ask (or beg) for them to do it.

More info, tips and tricks for wp-config

For more information on the wp-config.php file, check out the WordPress Codex. We also have some awesome wp-config tricks and wp-config optimization tips for your WordPress enjoyment :)

© 2010 Digging into WordPress | Permalink | 44 comments | Add to del.icio.us | Post tags: config, database, performance, Security

Remove all spam comments from the database

This SQL query removes all comments marked as “spam” from the database:

DELETE FROM wp_comments WHERE wp_comments.comment_approved = 'spam';

Works great in all versions of WordPress including 3.0!

Disabling and enabling comments

In the WordPress database, the “wp_posts” table includes a column called “comment_status”, which may contain one of the following values for each row (i.e., post):

• open (comments open to everyone)
• closed (comments closed to everyone)
• registered_only (comments open for registered/logged-in users)

Given this information, we may execute the following SQL queries (via phpMyAdmin or any other method of querying the database) to manipulate our discussion-management settings for comments (note: remember to backup your database):

Globally enable comments for all users

UPDATE wp_posts SET comment_status = 'open';

Globally disable comments for all users

UPDATE wp_posts SET comment_status = 'closed';

Globally enable comments for registered users only

UPDATE wp_posts SET comment_status = 'registered_only';

Globally enable/disable comments before a certain date

For this query, specify the comment_status as either open, closed, or registered_only. Also, specify the date by editing the 2008-01-01 to suit your needs.

UPDATE wp_posts SET comment_status = 'closed' WHERE post_date < '2008-01-01' AND post_status = 'publish';

I run this query a few times each year (or as often as I can remember it) to disable comments on old posts. Ultimately, I will combine this query with a similar one (provided below) for pingbacks and trackbacks to manage discussion options with a single step.

Disabling and enabling Trackbacks & Pingbacks

Similar as before, the “wp_posts” table also includes a column called “ping_status”, which applies to both pingbacks and trackbacks, and may contain one of the following values for each row (i.e., post):

• open (pingbacks/trackbacks open to everyone)
• closed (pingbacks/trackbacks closed to everyone)

Given this information, we may execute the following SQL queries (via phpMyAdmin or any other method of querying the database) to manipulate our discussion-management settings for pingbacks and trackbacks:

Globally enable pingbacks/trackbacks for all users

UPDATE wp_posts SET ping_status = 'open';

Globally disable pingbacks/trackbacks for all users

UPDATE wp_posts SET ping_status = 'closed';

Globally enable/disable pingbacks/trackbacks before a certain date

For this query, specify the ping_status as either open or closed. Also, specify the date by editing the 2008-01-01 to suit your needs.

UPDATE wp_posts SET ping_status = 'closed' WHERE post_date < '2008-01-01' AND post_status = 'publish';

As before, this last query is one that I will be using a few times each year (or as often as I can remember it) to disable comments on old posts. Ultimately, I will combine this query with the comments query to produce the one-step discussion-management query provided below.

Complete, one-step discussion management

Given the queries described above, we may fashion the following “one-step” SQL queries, perfect for complete, plugin-free discussion management:

Globally enable/disable all discussion: comments, pingbacks and trackbacks

For this query, specify the comment_status as either open, closed, or registered_only. Also, specify the ping_status as either open or closed.

UPDATE wp_posts SET comment_status = 'open', ping_status = 'open' WHERE comment_status = 'closed' AND post_status = 'publish';

Globally enable/disable comments, pingbacks and trackbacks before a certain date

For this query, specify the comment_status as either open, closed, or registered_only. Also, specify the ping_status as either open or closed. Finally, specify the date by editing the 2008-01-01 to suit your needs.

UPDATE wp_posts SET comment_status = 'closed', ping_status = 'closed' WHERE post_date < '2008-01-01' AND post_status = 'publish';

That last query is perfect for manual control over the closing of both comments and xbacks for posts from a specific time period. Sure there are plugins for this, but there are also plugins that enable direct SQL commands, making it convenient for granular control over discussion intervals.

Here are some more awesome SQL techniques!

© 2010 Digging into WordPress | Permalink | 9 comments | Add to del.icio.us | Post tags: database, mysql, sql, tips, tricks

• Visitors viewing posts on your blog may be redirected to a third-party site.  This may be a site already blocked by Google.
• Visitors may  also be forwarded to the domain googlesearch.com, which has already been disabled.

They provide steps for clearing things up, but it doesn’t look like the entry-point or source of this hack is known at this point.

The hack injects a short JavaScript string into your database at the end of each your post’s content. There are (so far) two known variations of the inserted garbage:

• <script src="http://ae.awaue.com/7"></script>
• <script src="http://ie.eracou.com/3"></script>

To clean this up asap, backup your database and run the following SQL queries:

UPDATE wp_posts SET post_content = replace(post_content, '<script src="http://ae.awaue.com/7"></script>', '');

UPDATE wp_posts SET post_content = replace(post_content, '<script src="http://ie.eracou.com/3"></script>', '');

And remember to change the query prefix from wp_ to your custom prefix.

© 2010 Digging into WordPress | Permalink | 65 comments | Add to del.icio.us | Post tags: database, hack, mt

• Pharma Hacked
• Security Lockdown

Pharmaceutical Apocalypse

A few weeks ago, DigWP.com was hit with the so-called Pharma Hack. We discovered the hack after some Google results turned up all sorts of spammy pharmaceutical garbage littered throughout posts, links, and titles. The tricky part about the hack is that it injects the spam garbage only when your site’s pages are requested by a search bot (e.g., googlebot). So when you view your pages in a browser, everything seems perfectly normal. Put simply, the hack is cloaked. We had no idea anything was wrong until about two weeks after the attack. During that time a majority of our search engine results were nuked with evil pharma spam. Ick.

Flash forward three weeks later and things are locked-down tight. The Pharma Hack has not returned, and most of the spam garbage in the search results has been filtered out and replaced with clean pages. At the time of the attack, DigWP was running WordPress 2.9/3.0 without any sort of additional site security. We were just using whatever “default” protection available from either WordPress or Media Temple. After detecting the hack, several days were spent cleaning it up and locking things down. At first, it seemed like an impossible hack to fix – nothing seemed to work. We ran through the following routine, hoping to fix it:

• Locate and remove hacked 404.php file
• Locate and remove hacked content from database
• Replace entire set of salt keys
• Upload new WordPress files
• Restore previous versions of other files
• Restore database to previous version

These actions alleviate the symptoms, but they don’t even touch the actual virus, which somehow regenerates the (base64) encoded spam script. As far as we know, the Pharma Hack works like this:

1. Evil script gains access to your WordPress site
2. Encoded spam script injected into database
3. Script inserts spam garbage into pages requested by search bots
4. Script makes no changes to pages requested by browsers

Within the database, the spam script is generated in any/all of these option_name fields:

• class_generic_support
• widget_generic_support
• wp_check_hash
• ftp_credentials
• rss_[string] e.g.,
rss_7988287cd8f4f531c6b94fbdbc4e1caf

If these fields are present and contain super-long strings of encoded gibberish, your site’s infected. You can assess the damages by examining the search results for your site (note: other spam keywords may be used):

site:digwp.com cipro OR meridia OR cialis

If you’re hit, hopefully you catch it before googlebot crawls along. But even if you have thousands of hacked pages appearing in the search index, it’s not too late to clean things up and secure your site. Here is how we did it..

WordPress Security Lockdown

This security strategy is best implemented on new sites. It just makes everything (like renaming table prefixes) so much easier. Either way, you want to start with a clean batch of files. Upload a fresh copy of WordPress, update your plugins, theme files, and so on. You may want to redirect visitors to a maintenance page while you work on your site. That said, here is our five-step Security Lockdown for WordPress:

1. File Permissions
2. File Protection
3. Database Protection
4. Essential Plugins
5. Important Details

[1] File Permissions

After uploading fresh files, the next step is to ensure proper file permissions. WordPress defaults to 644 for files and 755 permissions for folders. Make sure these are set properly. While cleaning up, we noticed some crazy permission settings for sensitive files. For example, wp-config.php was set to 777 – executable and writable by the entire world!! Make sure you don’t see anything like that, and if you do, fix it.

[2] File Protection

In addition to setting proper file permissions, we can also lock down key files with .htaccess. There are numerous files to protect, perhaps most importantly the wp-config.php file, which contains your database login information. Place the following code in your site’s root .htaccess file to protect it:

# SECURE WP-CONFIG.PHP
<Files wp\-config\.php>
 Order Deny,Allow
 Deny from all
</Files>

You may also want to password-protect your wp-admin directory, but it may cause more trouble than it’s worth.

[3] Database Protection

Changing the default table prefix is one of the best ways to protect your database. Malicious scripts need targets, and default targets are easy to hit. Change wp_ to something more like a password. Some random string like “crUQZPadESeKSy8Q_” will make your tables difficult to hit. Like having a built-in password for your database :)

There are two ways to change your prefixes: the easy way and the hard way. The easy way is to add the following line to your wp-config.php file before installing WordPress (important: change the random string to something unique):

$table_prefix  = 'crUQZPadESeKSy8Q_'; // custom table prefix

Do that before running the install script and WordPress takes care of the prefix naming automagically when it creates the database. Going forward, there is no reason not to change default prefixes for all future WordPress installs. For existing sites, you can do it the hard way using a plugin or doing it manually.

[4] Essential Plugins

After exploring the vast crop of WordPress security plugins, we narrowed it down to four plugins that collectively do just about everything in the easiest way possible:

WP File Monitor

This plugin tracks changes made to your files. If/when anything changes, it notifies you via Admin Dashboard alert and/or email alert. So anytime a file is changed, moved, added, or removed, WP File Monitor lets you know. Here is a list of features:

• Monitors file system for added/deleted/changed files
• Sends email when a change is detected
• Multiple email formats for alerts
• Administration area alert to notify you of changes in case email is not received
• Ability to monitor files for changes based on file hash or timestamp
• Ability to exclude directories from scan
• Site URL included in notification email in case plugin is in use on multiple sites

This is one of my favorite plugins. It’s perfect for keeping an eye on things. If anyone gets in and messes around with your files, you’ll know about it immediately, and even better, you’ll know exactly which files have been affected.

WP Security Scan

This plugin scans your WordPress installation for security vulnerabilities and suggests corrective actions. The scan report informs you of any problems with file permissions, system variables, and much more:

• Passwords
• File permissions
• Database security
• Version hiding
• WordPress admin protection/security
• Removes WP Generator META tag from core code

WP Security Scan also provides a nice summary of server information and latest scan information. Performing a new scan is immediate with the click of a button. Very easy.

Ultimate Security Check

This plugin provides even more security information, helping you to identify potential issues with your WordPress installation. It scans your site for “hundreds of known threats,” and then “grades” your level of site security. Here are some of the key things it checks:

• Checks for updates
• Checks configuration file
• Checks if config file is located in unsecured place
• Checks presence of install script
• Checks server configuration
• Checks database
• Checks code

And quite a bit more. The best part about Ultimate Security Check is that it’s so easy to use.

Secure WordPress

This plugin takes care of all those “little” things. Instead of installing a bunch of smaller plugins or custom functions for this stuff, the Secure WordPress plugin does it all for you:

1. Removes error-information on login-page
2. Adds index.php plugin-directory (virtual)
3. Removes the wp-version, except in admin-area
4. Removes Really Simple Discovery
5. Removes Windows Live Writer
6. Remove core update information for non-admins
7. Remove plugin-update information for non-admins
8. Remove theme-update information for non-admins (only WP 2.8 and higher)
9. Hide wp-version in backend-dashboard for non-admins
10. Block Bad Queries

Having all of this (and much more) done with a few clicks in the WordPress Admin is easy and effective.

[5] Important Details

The previous four steps comprise the majority of our security lockdown, but there are some important details to consider:

• Keep your WordPress install, plugins, themes, and scripts updated with current versions
• Use strong passwords and change them often
• Disable user registration if not needed/used for your site
• Check roles and permissions for all users
• Clean up and consolidate old/loose files
• Remove unused plugins and themes
• Check permissions of upload, upgrade, and backup directories
• Keep a backup of your site files
• Keep your database optimized and backed up

We did these things here at DigWP.com, but certain tips may not apply to every site. As a side note, despite our new security lockdown, I am still concerned/confused about how to handle the upload, upgrade, and backup directories. It seems dangerous to leave these folders set with 777 permissions, and for many shared hosts, that seems to be the required setting. I would be interested in hearing any ideas about securing these directories.

Bottom Line

There is no such thing as perfect security. If someone wants in bad enough, they’re going to find a way, despite your best efforts at staying secure. Fortunately, most malicious scripts target the least common denominator, default WordPress installs. At the very least, ensure proper file permissions, secure wp-config.php, and use unique database prefixes. Together, these three steps will put your site out of reach for a vast majority of malicious scripts and other automated attacks. Of course, there are many other ways to strengthen your site’s security, depending on how far you want to go with it. The lockdown strategy presented in this article provides strong security in the most efficient way possible, but there is always room for improvement, so share your ideas and help the community secure their WordPress.

© 2010 Digging into WordPress | Permalink | 44 comments | Add to del.icio.us | Post tags: database, hacking, plugin

Hopefully, you have some experience working directly with the database, but even if you’re new to it, the simple recipes presented in this DiW article will help you find, replace, and delete specific text content using a few simple SQL commands. This gives you incredible power to make sitewide changes to your posts, comments, or any other database table with a few simple clicks.

Before we get started, remember to

backup your database before making any changes!

Once we’ve got our database backup(s), we’re ready to dig into some easy, effective SQL queries for manipulating post content. To give us some context while we go, we’ll assume a hypothetical case: let’s say we want to find and remove all instances of the mystical nofollow attribute, in all of its various incarnations:

• rel="nofollow"
• rel="external nofollow"
• rel="nofollow external"

In addition to these instances of the attribute, our custom query will also match any instances of other attribute values besides “external”. A couple of things to keep in mind about SQL selectors:

%   => this is the "wildcard" selector - will match /any/ character
*   => this is the "all" selector - will match /all/ entries

All right, let’s look at some of the useful things we can do using a few custom SQL queries..

Display all instances of a given text string

Before making any sitewide changes to your database, it’s a good idea to simply search and find all instances of a given text string. So in our example, we are looking for three different nofollow patterns, as described above.

Using phpMyAdmin, click on the “SQL” tab and enter the following SQL query:

SELECT * FROM wp_posts WHERE ( 
post_content LIKE '% rel="nofollow"%'
OR post_content LIKE '% nofollow%'
OR post_content LIKE '%nofollow %'
);

This query selects everything from the wp_posts table that matches any of our three target cases. Note that if you are using a unique table prefix (i.e., anything other than “wp_”), you will need to change the “wp_posts” in the first line to match.

From here, you can check the results by evaluating the overall number of posts and “zooming in” on any specific post(s) of interest. To search for a text string in a different table, replace “wp_posts” with something else, such as “wp_comments” or whatever you like.

If desired, we could locate all instances of each specific pattern individually using each of the following queries:

SELECT * FROM wp_posts WHERE (post_content LIKE '%nofollow %');
SELECT * FROM wp_posts WHERE (post_content LIKE '% nofollow%');
SELECT * FROM wp_posts WHERE (post_content LIKE '% rel="nofollow"%');

So with our nofollow example, let’s say we have 100 posts that contain some instance of the target string. We no longer want these attributes polluting our post content, so let’s remove them..

Remove all instances of a given text string

Once we are ready to actually remove all instances of the target string in our post content, we run the following three queries, either all at once or one at a time:

UPDATE wp_posts SET post_content = REPLACE ( post_content, 'nofollow ', '' );
UPDATE wp_posts SET post_content = REPLACE ( post_content, ' nofollow', '' );
UPDATE wp_posts SET post_content = REPLACE ( post_content, ' rel="nofollow"', '' );

Bam! Just like that, we have removed all of those silly nofollow attributes throughout our entire site without affecting anything else. It’s as if they never existed in the first place. So much power! ;)

How does it work? Easy: each command is saying, “replace all matches in the post_content field with exactly nothing.” As far as I know, there is no way to combine these queries into a single command, so if there are any SQL wizards reading, please enlighten.

As you may guess, the general pattern for removing any text string from all post content in the database looks like this:

UPDATE wp_posts SET post_content = REPLACE ( post_content, 'text to be replaced', '' );

And from here, we can just as easily replace any matching text..

Replace all instances of a given text string

Lastly, let’s look at how to replace our text string with some different text. We’re actually using the same query as in the previous section, only instead of empty quotes in the second argument, we’re going to add our replacement text.

Let’s say that, instead of deleting our nofollow attributes, we want to replace them with “dofollow”. We wouldn’t actually do this on a production site because dofollow is not a valid value for the rel attribute. But for the sake of our hypothetical, let’s just do it anyway. Here’s how it looks:

UPDATE wp_posts SET post_content = REPLACE ( post_content, 'nofollow ', 'dofollow ' );
UPDATE wp_posts SET post_content = REPLACE ( post_content, ' nofollow', ' dofollow' );
UPDATE wp_posts SET post_content = REPLACE ( post_content, ' rel="nofollow', ' rel="dofollow' );

Same idea as before, only now we can see that anything can be used for the replacement text, even imaginary attribute values ;)

And finally, here is the general formula for replacing post content via SQL:

UPDATE wp_posts SET post_content = REPLACE ( post_content, 'text to be replaced', 'replacement text' );

And of course keep in mind that this query may be modified as explained in the article to search for, remove, and replace any content – markup, text, special characters – in your WordPress database. For site admins and serious bloggers, this is an excellent way to speed up maintenance and get things done.

Of course, there’s probably a plugin that will do all of this for you ;)

© 2010 Digging into WordPress | Permalink | 8 comments | Add to del.icio.us | Post tags: database, nofollow, sql, tips, tricks

The question is, could this information help an attacker who has targeted your site? This type of specific information should be going to you, the site administrator — not announced to the entire world. Besides, that message really isn’t helping anyone. To the average visitor, it just means the site is borked and that it’s time to move on to someplace else. And to you, the site Admin, the default error message doesn’t mean anything unless you’re lucky enough to be sitting there looking at your site when it happens. I think it’s safe to say that the default database error message:

• is ugly
• is useless to visitors
• is useless to site admins
• reveals sensitive information

Fortunately, we can improve on all these areas by creating and implementing our own custom database error page. In this article, you’ll learn how to setup your own error page and add some server-side functionality that will improve your ability to respond to database problems as soon as they happen.

How it works

Basically, it all happens automatically: whenever WordPress is unable to connect to the database, it will check for the presence of your custom error page and then serve it up to your visitors; otherwise, if a custom error page is not present, the default error page is displayed. It’s that simple.

How to set it up

To create your own database error page, simply create your custom page, name it “db-error.php”, and upload it to the wp-content directory like so:

wp-content/db-error.php

That’s pretty much all there is to it. Most of the action happens behind the scenes depending on how you set things up. Because this is an actual PHP file, you can implement just about any non-database functionality, along with whatever markup and CSS you desire.

So, now that we know the dark secrets that make this work, let’s look at an actual example..

An actual example of a custom database error page

Here is the code that I use at Perishable Press:

<?php // custom WordPress database error page tutorial @ digwp.com

	header('HTTP/1.1 503 Service Temporarily Unavailable');
	header('Status: 503 Service Temporarily Unavailable');
	header('Retry-After: 3600'); // 1 hour = 3600 seconds
	mail("spamless@domain.tld", "Database Error", "There is a problem with teh database!", "From: Montgomery Scott");

?>
<!DOCTYPE HTML>
<html dir="ltr" lang="en-US">
	<head>
		<title>503 Service Temporarily Unavailable</title>
		<style type="text/css">
			h1, p {
				font-family: Helvetica, sans-serif;
				font-size: 24px;
				color: #333;
				}
			p {
				font-size: 14px;
				}
		</style>
	</head>
	<body>
		<h1>Captain, the ship can&rsquo;t take much more of this!</h1>
		<p>Perishable Press is currently experiencing technical issues &mdash; Please check back soon!</p>
	</body>
</html>

Simple, yes, but more effective than the default error page at facilitating a rapid response. Again, because this is a regular PHP file, we can do just about anything with it — more functionality, elaborate design, etc. — but before we look at some ideas, let’s browse the basics of this file:

The PHP (before the markup)

• Send a 503 server response to let the client know that they should try back later
• Send a 503 status response to let the client know that they should try back later
• Send a Retry-After header to tell the client when to try again (specified in seconds)
• Send an email to the site admin letting them know that “There is a problem with teh database!”

The HTML markup

• HTML 5, baby!
• Give it a title, might as well call it what it is
• Add some CSS to make it all sweet
• Throw down some custom markup and tell the user what’s up

From here, you can do just about anything. The PHP stuff is important to let robots and yourself know about the issue, and the markup is important for your human guests. For them, you may integrate your site’s design as much (or as little) as desired. There really is no reason to get too fancy because ideally the page will be displayed for only a brief period. But I suppose if you’re hosted on a crappy server you may want to pimp it out more fully ;)

In any case, here are some more ideas and tips for customizing your own database error page:

• Make it more official with your logo and other branding embellishments
• Link to some useful resources, perhaps some static stuff not dependent on the database (RSS Feed?)
• Don’t disclose the specific issue (i.e., database) — keep it general, like “technical issues” or whatever
• If your database is down for awhile, save some bandwidth by keeping this file as small and optimized as possible

It would be so cool if..

As it currently stands, this custom database error page is going to send you an email every single time any WordPress page is requested while the database is down. Especially for highly trafficked sites, this could result in thousands of emails flowing into your inbox. On smaller sites, this isn’t really that big of an issue, but for larger sites it would be cool to get a script that would send only one email for each time the database went down. One way to do this would be to use fwrite to alter a static file with some specific text and then check for it before sending the next email, but this would require all sorts of fiddling that seems extraneous. I’m sure there is a better way of doing it.

Last words

Hopefully this post gives you some ideas of what’s possible with your own custom database error pages. It’s nice that WordPress makes them so easy to set up and customize. Even better, because the db-error.php page is located in the wp-content directory, it is not modified or removed during the upgrade process. So just fix it and forget it. Definitely worthwhile to improve your site’s overall visitor experience.

© 2009 Digging into WordPress | Permalink | 17 comments | Add to del.icio.us | Post tags: database, errors, Security

Step 1 – Setting up a secure database

Because the database is associated with virtually everything you do on your site, it is best to perform any modifications before configuring your options, installing plugins, and adding options. During the installation process, there are some effective ways of increasing the overall security of your WordPress site.

One of the first things that you can do to bolster security is to setup a proper database, user, and password. First, create the table that will be used for your WordPress installation:

CREATE DATABASE `wordpress`;

Now we need a user to go with that database. The key here is to create a user with only the required permissions. Enter the following SQL query to create a user that will have access only to the wordpress from the local server:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON wordpress.* TO 'wpuser'@'localhost'
IDENTIFIED BY 'password';

By requiring that the user access the database from the local server only, we mitigate the possibility of remote database attacks. Further, by granting the user access to only the wordpress database, we ensure that other databases will remain safe should an attacker gain access.

Once the database and user have been setup, install WordPress as normal and continue with the next step.

Step 2 – Setting up a secure configuration file

There are two things we want to do with the wp-config.php file: implement Authentication Unique Keys and change the default database prefix. Let’s do it..

Implement Authentication Unique Keys

Directly after your MySQL database credentials in the wp-config.php file, you have the option of specifying a set of Authentication Unique Keys. These keys improve WordPress’ authentication system, providing strong security to your site. It is highly recommended that you take advantage of this feature.

/**#@+
 * Authentication Unique Keys.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
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');
/**#@-*/

To do so, visit the official secret-key generation service and paste the results into your config.php file (replace the four lines beginning with “define”).

While you are you setting up the WordPress configuration file, you also may want to go ahead and optimize performance and implement some other choice configuration tricks.

Change the default database table prefix

While in your wp-config.php file, take a few moments to change your default database table prefix. By default, it’s “wp_”, but this is a well-known fact of which attackers and automated scripts take full advantage. By changing the table prefix to something unknown/random, you are using security through obscurity to help mitigate SQL-injection threats.

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix = 'wp_';

In your wp-config.php file, locate the above lines and change the table prefix to something random or difficult to guess. I like to include the letters “wp” within the new prefix to help me identify tables specific to WordPress. For example, I might change it to something like, “wp_i337”.

Step 3 – Setting up a secure administration

Once you have finished with your database and configuration file, it’s time to setup a secure WordPress Admin area. We can do this by changing the default Admin username and protecting the wp-admin directory.

changing the default Admin username

By default, all WordPress installations have a default Admin username of, creatively enough, “admin”. As with the default database prefix, this fact is well-known to attackers, who target the admin account with password brute-force attacks. Thus, changing the username of your Admin account will help mitigate this potential vulnerability. To do so, execute the following SQL query on your WordPress database via phpMyAdmin:

UPDATE wp_users SET user_login = 'admin', user_login = 'digwp';

Your default Admin username is now changed to whatever you specified in the query. In this example, your new username will be “digwp”, so you will probably want to change it to something that is more difficult to guess.

Additionally, make sure that the password for the Admin account is as strong as possible. Use a random mix of uppercase and lowercase letters, and throw in a few underscores and numbers for good measure.
 

Protecting the wp-admin directory

All of the administrative files for your WordPress site are contained in the wp-admin directory. By protecting this directory against unauthorized access, we greatly strengthen the security of our site. Depending on your particular needs, there are at least two ways to go about doing this. Let’s look at each of them.

Allow open access only to specific addresses

This method uses a few choice HTAccess directives placed in your site’s root .htaccess file:

# SECURE WP-ADMIN
<FilesMatch ".*">
 Order Deny,Allow
 Deny from all
 Allow from 123.456.789
</FilesMatch>

Once in place, this code will deny access to all visits from any IP address that is not listed. Simply edit the “Allow from” line with your actual address, and create additional lines for multiple IPs. You can then check that it’s working by visiting your Admin area via proxy service. This is an effective way of protecting your wp-admin directory, but you may prefer using a password-based method instead..

Password-protect

Another option for securing your Admin area involves implementing secondary password protection via basic HTTP authentication. This is an excellent way to lock things down while still enabling access by anyone with the password from anywhere on the Web. To set it up, we need to create a text file with your desired username/password, and then require the username and password via .htaccess file.

For the username/password text file, use a password-generation service and paste the results into a file named “.htpasswd” (without the quotes!) and place it in a secure location on your server, preferably above your “public_html” or root-web directory.

Once the password file is in place, create an .htaccess file for your wp-admin directory and add the following code:

# SECURE LOGIN PAGE
<IfModule mod_auth.c>
 AuthUserFile /full/path/.htpasswd
 AuthType Basic
 AuthName "Password Required!"
 Require username
</IfModule>

After editing the username and full server path to your password file, you’re good to go. Make sure to test that everything is working before cracking a beer.

Important note about protecting wp-admin

As you implement this method, keep in mind that the wp-admin directory is used by a number of plugins, scripts, and even users. For example, if you allow open registration to your visitors, they will be unable to access the registration pages if your admin directory is blocked. Another good example is the Subscribe to Comments plugin, which provides an admin page through which users may unsubscribe to comments. This ain’t gonna work if they can’t access the admin area.

Just the beginning..

Of course, when it comes to the security of your WordPress site, these techniques are merely the beginning. As you continue in your WordPress travels, you will discover many, many more ways to increase the security of your site. By implementing the methods presented in this article during the setup process, you will be strengthening the security of your site’s foundation, providing yourself a solid platform on which to build.

© 2009 Digging into WordPress | Permalink | 32 comments | Add to del.icio.us | Post tags: database, Security

• The number of database queries that your page is making
• How many seconds it took your server to complete those queries

The number of database queries is generated from the following WordPress template tag:

<?php echo get_num_queries(); ?>

This is a very straightforward, parameter-less function that will output the number of database queries required to generate all of the dynamic content on your page. Then, the amount of time required to complete those “x” number of queries is provided by this template tag:

<?php timer_stop(7); ?>

As shown here, this function accepts a parameter that specifies the number of significant digits to be used for the output. Here, the number “7” tells the function to output the query-processing time to seven digits of accuracy. So we would see a number like this:

.0173788

When used together, these two WordPress functions provide an instant snapshot into the basic performance of your web pages. Here is an example of the statistical output generated by these tags working together:

33 queries in 0.333 seconds

Many of you have probably seen this information while snooping around the far corners of your favorite websites. Lots of people use this code, although not everybody uses it the same way. Here are three great techniques for including this information on your site.

Show it off publicly
If you are particularly proud of your server’s performance and would like to show off these stats to your visitors, place the following code into the footer or sidebar of your active theme:

<p><?php echo get_num_queries(); ?> queries in <?php timer_stop(1,3); ?> seconds</p>

Display it under the hood
If you would rather not clutter your design with extraneous information, but still want to keep an eye on these stats, you can “comment out” the output string so that it only appears as a comment in the source code of your web pages. To do so, place this code in your theme’s footer.php file:

<!-- <?php echo get_num_queries(); ?> queries in <?php timer_stop(1,3); ?> seconds -->

Keep it private
Last but not least, if you don’t like the idea of sharing this information with the entire world, you can limit its display to logged-in administrators only with the following code:

<?php if (current_user_can('level_10')) {

	echo '<!-- ' . get_num_queries() . ' queries in ' . timer_stop(0,3) . ' seconds -->';

} ?>

This tells WordPress to check if the current user is an Administrator (i.e., Level-10 privileges) and if so output the statistical information to the web page. Here we have restricted the display of this information to the source code, but you can change this to display on the page itself by replacing the “<!-- ” and “ -->” with “<p>” and “</p>”, respectively.

Update: note that there are two ways to display the timer_stop output on the page. The timer_stop() function actually accepts two parameters, $display and $precision. Here are their default values:

<?php timer_stop($display = 0, $precision = 3) ?>

As you might guess, $display is an integer that determines whether or not the function outputs the results to the web page (1 for output, 0 for no output). Thus, you may either use 0 for the $display parameter and explicitly echo the results; or else you may use 1 for the $display parameter and omit the explicit echo.

You can see the latter method in the first two examples in this post, and the former in the third. Thanks to Rarst for pointing this out :)

© 2009 Digging into WordPress | Permalink | 26 comments | Add to del.icio.us | Post tags: database, footer, statistics, tricks