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 :)

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 37 comments | Add to Delicious
Categorized: PHP | Tagged: database, performance, Security

This issue came up while my co-worker Tim at Wufoo was documenting parts of the latest Wufoo API. Some of the API pages have areas on them that are exactly the same as other pages, for example, a chunk of navigation that links to other pages of documentation.

One possible way to deal with this is to make a special template just for these pages and include that chunk inside that template. This solution edges on the issue of template-bloat which I’ve been thinking a lot about lately. Creating a new template every time you need one little change is solving the problem with a sledgehammer rather than a scalpel.

The ideal solution is just to make a shortcode. You pass the ID of the post (in our case, page) that you want to include and the shortcode is replaced with that content. This is the usage, where XXXX would be the ID of the post:

[digwp_include postidparam=XXXX]

To make it work, we’ll add a fairly simple function to the functions.php file in our theme. The function will take the parameter, run a query for it, and return back the content if it finds any:

function digwp_includeContentShortcode($atts) {
  
  $thepostid = intval($atts[postidparam]);
  $output = '';

  query_posts("p=$thepostid&post_type=page");
  if (have_posts()) : while (have_posts()) : the_post();
    $output .= get_the_content($post->ID);
  endwhile; else:
    // failed, output nothing
  endif;
  wp_reset_query();

  return $output;

}

// USAGE
// In the post content, you can use [digwp_include postidparam="1234"]
// "1234" would be the WordPress ID of the Page you are trying to include

add_shortcode("digwp_include", "digwp_includeContentShortcode");

Now you can publish small modules of content, and include them on any Post/Page that needs them! I’d probably create a Page on your site called like “Includes” or “Modules” and post them as Pages with that as the Parent Page. That way you don’t clutter up the root and they all stay organized together.

Check out this graphic (click for full size), which hopefully will drive home the idea:

Random notes:

• This is similar to the custom loop shortcode I previously published.
• This may be good territory for a plugin rather than functions.php code as I have done.
• Notice the function is properly prefixed.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 28 comments | Add to Delicious
Categorized: PHP | Tagged: content, include, shortcode

<?php the_post_thumbnail(); ?>

When included within the loop, the_post_thumbnail() will output the markup for the post’s thumbnail, linked to a full-size or pre-sized version of the image. Of course, there are a few more awesome things that you can do with the_post_thumbnail. Now that we’ve seen how to include thumbnails in post content, let’s do it for feed content..

Display Post Thumbnails in Feed Content

To include post-thumbnails in your feeds, we need to filter WordPress’ feed functionality and inject the required template tag into both feed-excerpt and full-feed content:

// show post thumbnails in feeds
function diw_post_thumbnail_feeds($content) {
	global $post;
	if(has_post_thumbnail($post->ID)) {
		$content = '<div>' . get_the_post_thumbnail($post->ID) . '</div>' . $content;
	}
	return $content;
}
add_filter('the_excerpt_rss', 'diw_post_thumbnail_feeds');
add_filter('the_content_feed', 'diw_post_thumbnail_feeds');

Include that code in your active theme’s functions.php file and your feeds will display the post thumbnail before each post. To display the post thumbnail after the post content, a slight adjustment is made to the fourth line of the function:

$content = $content . '<div>' . get_the_post_thumbnail($post->ID) . '</div>';

The <div> will prevent the post text from wrapping around the post thumbnail, but theoretically its removal would enable the post content to wrap around the image:

$content = get_the_post_thumbnail($post->ID) . $content;

As easy and flexible as it is working with the_post_thumbnail(), there may be situations where you need more control over the appearance and functionality of your posts’ attached images. Fortunately, WordPress’ custom fields and image-attachment functionality enable just about any custom configuration you can imagine.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 16 comments | Add to Delicious
Categorized: PHP | Tagged: feeds, functions, thumbnails, tricks

• posts_nav_link() – for navigating various archive (non-single) pages
• previous_post_link() & next_post_link() – for navigating single-post pages

These template tags output the HTML markup required to create the actual hyperlinks that will appear on your web pages. By default, navigation links for single pages display the title of adjacent posts, while those for archive pages display “Next-Page” and “Previous-Page”.

Of course, the default text, link-position, and just about everything else can be customized and optimized according to your specific needs.

Normally, WordPress’ navigational template tags appear within the loop:

<?php get_header(); ?>

	<?php if (have_posts()) : while (have_posts()) : the_post(); ?>

		<h1><?php the_title(); ?></h1>
		<?php the_content(); ?>

	<?php endwhile; ?>

		<p class="nav"><?php posts_nav_link(); ?></p>

	<?php else : ?>

		<h1>Nothing Found</h1>
		<p>Please try a little harder next time..</p>

	<?php endif; ?>

<?php get_footer(); ?>

This code is typical for index.php and other “Archive-View” pages, such as for Categories, Tags, Search Results, and so on. Similar code is used for Single Page-Views, where single.php would replace the posts_nav_link() ¹ template tag for previous_post_link() and next_post_link() tags.

The navigational template tags are generally placed between the endwhile and else ² statements, along with stuff like post comments, meta information, and social-media links. Within this section of the loop, code is processed only once, as opposed to multiple times in the first part of the loop.

Navigation outside of the loop

The good news is that the template tag for archive-view navigation (i.e., non-single pages) seems to work just fine outside of the loop. So you can just place posts_nav_link() anywhere within your theme template.

Then, to include single-view navigation outside of the loop, we can use query_posts to substantiate the loop anywhere within your single.php file. Here is a simplified version of the code that I am using at Perishable Press:

<?php $posts = query_posts($query_string); if (have_posts()) : while (have_posts()) : the_post(); ?>

	<?php previous_post_link(); ?> | <?php next_post_link(); ?>

<?php endwhile; endif; ?>

That’s all there is to it, really. A nice trick to have in the hat. Then, we can take it a step further and consolidate both types of page navigation (single and archive) in a single chunk of code:

<?php if(is_single()) { // single-view navigation ?>

	<?php $posts = query_posts($query_string); if (have_posts()) : while (have_posts()) : the_post(); ?>

		<?php previous_post_link(); ?> | <?php next_post_link(); ?>

	<?php endwhile; endif; ?>

<?php } else { // archive view navigation ?>

		<?php posts_nav_link(); ?>

<?php } ?>

This code displays the appropriate template tags for both single-page-views and archive-views. If placed in its own file named “nav.php”, including it within your theme files is as simple as a template tag:

<?php include_once("nav.php"); ?>

That’s an easy way to get your Next/Previous page navigation working anywhere outside the loop. This could easily be made into a custom function for your theme’s functions.php file. Or maybe even a plugin..? ;)

For more information on WordPress Page Navigation, check out these fine DiW articles:

• Definitive Guide to WordPress Page Navigation
• Optimizing WordPress Post Navigation

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 15 comments | Add to Delicious
Categorized: Design, PHP | Tagged: navigation, posts, tips, tricks

The answer was creating a custom function for the functions.php file which would output any widget by name. There is a function just for that: the_widget() (incomplete codex page).

The logic

1. Test if widget exists
2. If it does…
   1. Start capturing output
   2. Output widget
   3. End capturing output
   4. Return captured output
3. If it doesn’t exist…
   1. Output fail message

The code for functions.php

function widget($atts) {
    
    global $wp_widget_factory;
    
    extract(shortcode_atts(array(
        'widget_name' => FALSE
    ), $atts));
    
    $widget_name = wp_specialchars($widget_name);
    
    if (!is_a($wp_widget_factory->widgets[$widget_name], 'WP_Widget')):
        $wp_class = 'WP_Widget_'.ucwords(strtolower($class));
        
        if (!is_a($wp_widget_factory->widgets[$wp_class], 'WP_Widget')):
            return '<p>'.sprintf(__("%s: Widget class not found. Make sure this widget exists and the class name is correct"),'<strong>'.$class.'</strong>').'</p>';
        else:
            $class = $wp_class;
        endif;
    endif;
    
    ob_start();
    the_widget($widget_name, $instance, array('widget_id'=>'arbitrary-instance-'.$id,
        'before_widget' => '',
        'after_widget' => '',
        'before_title' => '',
        'after_title' => ''
    ));
    $output = ob_get_contents();
    ob_end_clean();
    return $output;
    
}
add_shortcode('widget','widget'); 

Usage

Now in Post/Page content, you can use the widget just by referencing it by name:

[widget widget_name="Your_Custom_Widget"]

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 15 comments | Add to Delicious
Categorized: PHP | Tagged: functions, Theme, widgets

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 ;)

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 8 comments | Add to Delicious
Categorized: PHP | Tagged: database, nofollow, sql, tips, tricks

if ( function_exists('register_sidebar') ) {

    $allWidgetizedAreas = array("Homepage Left", "Homepage Right", "Sidebar One", "Movies", "Admin");
    
    foreach ($allWidgetizedAreas as $WidgetAreaName) {
    
        register_sidebar(array(
           'name'=> $WidgetAreaName,
           'before_widget' => '<div id="%1$s" class="widget %2$s left half">',
           'after_widget' => '</div>',
           'before_title' => '<h3 class="widgettitle">',
           'after_title' => '</h3>',
        ));
    
    }

}

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 7 comments | Add to Delicious
Categorized: PHP | Tagged: functions, PHP, widgets

<div <?php post_class() ?> id="post-<?php the_ID(); ?>">
   <!-- Post stuff -->
</div>

I was in a circumstance where I wanted to add an additional class to what that was outputting. My thought process went like this:

1. Arg. I guess I’m going to have to write a function to filter the output of that function. Let’s begin the research.
2. Wait. I bet that function has an alternate that returns a string rather than echos it. I’ll just use that, and echo it out along with my own custom class.
3. Double wait. I bet those smart WordPress folks have thought of this…

1. Filtering

This kind of thing is generally beyond my comfort zone, but you’d basically write your own little function which takes in what the output would have been, add you own stuff to it, then return the new value.

Then call the new function with a filter in your functions.php file:

add_filter('post_class','add_my_stuff');

2. Output exiting classes, then add yours

Like most functions that echo stuff, there is a version that doesn’t echo stuff, in which “get_” prefaces the function name. I didn’t even have to look it up I just knew there would be. Since it’s a list, this function returns an array, so to output them, you’ll need to loop through the array:

<div class="<?php $allClasses = get_post_class(); foreach ($allClasses as $class) { echo $class . " "; } ?> group" id="post-<?php the_ID(); ?>">

The cool part here is that is doesn’t add “class=” in the output, you can do that yourself, meaning that I can add my own classes after the output is finished.

3. Built in…

Of course, as it turns out, this is far easier than #2 made it out to be. To add additional classes, just pass them as a parameter!

<?php post_class('special'); ?>

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 2 comments | Add to Delicious
Categorized: PHP | Tagged: classes, functions, Theme

But alas…

This ain’t gonna work “out-of-the-box”

After tinkering with some far-too-complicated solutions, someone on Twitter helped me with a deliciously simple solution: Just add this to your functions.php file:

add_filter('widget_text', 'do_shortcode');

This will ensure that the text content of widgets is parsed for shortcodes and those shortcodes are ran. Awesome.

Stephanie Leary wrote a great article on Using Shortcodes Everywhere, which covers this as well as using shortcodes in a bunch of other places: Comments, templates, excerpts, etc.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 4 comments | Add to Delicious
Categorized: PHP | Tagged: shortcode, widgets

In this DiW tutorial, you’ll learn how to separate your responses and display the comment count for each type. Here is a diagram to help visual the goal:

As you can see, separating these lists gives us a cleaner comments area, making things easier for everyone. Even better news is that we’re going to set it up in two steps. If you would rather group the pingbacks and trackbacks and just segregate the comments, just a few tweaks and you’re off to the races.

First let’s see how to separate everything, then explain the grouping of pingbacks and trackbacks before wrapping things up.

Step 1 – Display separate comments, pingbacks, and trackbacks

The first thing we need to do is separate the different response types. Fortunately, WordPress makes this very easy. First, open your them’s single.php file and use the following template tag to call your comments.php template:

comments_template('/comments.php',true);

This code will enable WordPress to segregate and count each of the different response types using the $wp_query object. Now let’s separate the comments, pingbacks, and trackbacks. In your comments.php file, use the following code as your comments loop:

<?php if (!empty($comments_by_type['comment'])) { ?>

	<h3 id="comments">Comments<h3>
	<ol class="commentlist">
		<?php wp_list_comments('type=comment'); ?>
	</ol>

<?php } if (!empty($comments_by_type['pingback'])) { ?>

	<h3 id="pingbacks">Pingbacks</h3>
	<ol class="pingbacklist">
		<?php wp_list_comments('type=pingback'); ?>
	</ol>

<?php } if (!empty($comments_by_type['trackback'])) { ?>

	<h3 id="trackbacks">Trackbacks</h3>
	<ol class="trackbacklist">
		<?php wp_list_comments('type=trackback'); ?>
	</ol>

<?php } ?>

This symmetrical slice of code will output the following markup, assuming that the post actually has all three types of responses:

<h3 id="comments">Comments<h3>
<ol class="commentlist">
	<li>Comment #1 - Blah blah blah..</li>
	<li>Comment #2 - Blah blah blah..</li>
	<li>Comment #3 - Blah blah blah..</li>
</ol>
<h3 id="pingbacks">Pingbacks</h3>
<ol class="pingbacklist">
	<li>Pingback #1 - Blah blah blah..</li>
	<li>Pingback #2 - Blah blah blah..</li>
	<li>Pingback #3 - Blah blah blah..</li>
</ol>
<h3 id="trackbacks">Trackbacks</h3>
<ol class="trackbacklist">
	<li>Trackback #1 - Blah blah blah..</li>
	<li>Trackback #2 - Blah blah blah..</li>
	<li>Trackback #3 - Blah blah blah..</li>
</ol>

When one of the different response types doesn’t exist on the post, that section will simply be omitted from the markup, keeping things nice and clean.

Step 2 – Display separate response counts

Now, to display the count for each of these response types, we can call upon the $wp_query object to retrieve and echo the information:

<?php echo count($wp_query->comments_by_type['comments']); ?>
<?php echo count($wp_query->comments_by_type['pingback']); ?>
<?php echo count($wp_query->comments_by_type['trackback']); ?>

Each of these lines displays a number corresponding to a specific response type. These response counts may be integrated into our previous code to give us the final result:

<?php if (have_comments()) : global $wp_query; ?>

	<h2 id="comments"><?php comments_number('No Responses', 'One Response', '% Responses' ); ?><h2>

	<?php if (!empty($comments_by_type['comment'])) { ?>

		<h3 id="comments"><?php echo count($wp_query->comments_by_type['comment']); ?> Comments<h3>
		<ol class="commentlist">
			<?php wp_list_comments('type=comment'); ?>
		</ol>

	<?php } ?>
	<?php if (!empty($comments_by_type['pingback'])) { ?>

		<h3 id="pingbacks"><?php echo count($wp_query->comments_by_type['pingback']); ?> Pingbacks</h3>
		<ol class="pingbacklist">
			<?php wp_list_comments('type=pingback'); ?>
		</ol>

	<?php } ?>
	<?php if (!empty($comments_by_type['trackback'])) { ?>

		<h3 id="trackbacks"><?php echo count($wp_query->comments_by_type['trackback']); ?> Trackbacks</h3>
		<ol class="trackbacklist">
			<?php wp_list_comments('type=trackback'); ?>
		</ol>

	<?php } ?>

<?php else : // if there are no comments yet ?>

	<?php if (comments_open()) : ?>
		<!-- comments open, no comments -->
	 <?php else : ?>
		<!-- comments closed, no comments -->
	<?php endif; ?>

<?php endif; ?>

That’s the magic bullet right there. Used as your comments loop, this code will display separate comments, pingbacks, and trackbacks, with each showing their respective number of responses in its heading. Notice we threw in some additional code there to make everything completely plug-n-play. Bottom line: slap it in and test it yourself. Should work perfectly for all WordPress 2.7 and better.

Separate comments from both pingbacks and trackbacks

Note that, alternately, you could segregate comments from both pingbacks and trackbacks, such that your comments display would show something like this:

To do this, we modify the comment loop (from Step 1 above) like so:

<?php if (!empty($comments_by_type['comment'])) { ?>

	<h3 id="comments">Comments<h3>
	<ol class="commentlist">
		<?php wp_list_comments('type=comment'); ?>
	</ol>

<?php } if (!empty($comments_by_type['pings'])) { ?>

	<h3 id="trackbacks">Pingbacks &amp; Trackbacks</h3>
	<ol class="ping-trackbacklist">
		<?php wp_list_comments('type=pings'); ?>
	</ol>

<?php } ?>

Grouping the pingbacks and trackbacks is easy thanks to the “pings” parameter for the second wp_list_comments loop. Then to display the count for our combined pingbacks and trackbacks, we insert the following snippet into our “Pingbacks & Trackbacks” heading (similar to Step 2 above):

<?php echo count($wp_query->comments_by_type['pings']); ?>

That’s all there is to it! Once you get everything in place and working properly, you’ll have some clean HTML canvas to paint with any CSS styles you wish. Sounds like a great way to spend some time ;)

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 15 comments | Add to Delicious
Categorized: Design, PHP | Tagged: comments, tips, tricks