digwp.com/thinks/this-is-a-cool-idea

Direct Link to Article — Permalink on DiW

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | Comments | Add to Delicious
Categorized: Links | Tagged:

DiW3 cover by Chris Coyier

Updated Core Material

Much has changed with WordPress since our previous book update (v2), so for version 3.0 we went through the book and updated/removed outdated core content. Everything is now hot-wired and fine-tuned to the latest version of WordPress, with new popouts and fresh links throughout the book. Here’s a close-up of one the updated pages (a flow-chart for templates):

New Chapter on WordPress 3.0

WordPress 3.0 is better than ever. Released on June 17th 2010, WP3.0 features tons of new functionality and CMS capabilities. So much good stuff, that we added an entire chapter covering all the best new WP3.0 features:

• New default theme
• Custom Admin usernames
• How to customize your background
• How to setup and use WP MultiSite
• Custom taxonomies, menus, and post types

Plus a whole bunch of other stuff, including how to use the built-in shortlink feature, author templates, comment-form template-tags, and more. It’s 20+ pages of new WP3.0 content.

Detail-view of new WP3 content

Included with Purchase

Here’s what you get for $27:

• Beautiful, full-color, easy-to-read design
• Nearly 450 pages of practical, how-to WordPress content
• 3 Free Themes: All Ajax, Lines & Boxes, and Plastique
• Free Lifetime Updates (current book owners received version 3.0 yesterday)
• Friendly, helpful customer support :)

Like WordPress itself, Digging into WordPress gets better with each new version. And the nice thing about PDF format is that you can read the book anywhere, even on the iPad. Plus you get useful stuff like actual, clickable hyperlinks and linked Table of Contents. Also the PDF format makes it easy to copy/paste code and other content, so you have everything all in one place. You can learn more and get the book here.

Printed Copies

We were sort of on the fence about printing more physical copies of the book, but after some great feedback, everything fell into place. Our current goal is to make printed copies of v3.0 available in September/October. The printed books seem to disappear quickly, so if you want a copy stay tuned for the announcement post.

Updated Sample PDF

Here is an updated Sample Chapter showing the new Table of Contents and part of Chapter 3. For more information on Digging into WordPress, check out the Official DiW Bookstore at DigWP.com, the free companion site for the book, featuring tons of awesome WordPress tips, tricks, and tutorials. So here’s to DiW version 3.0 and no sign of slowing down ;)

Questions about the book?

Shortlink for this post:

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 13 comments | Add to Delicious
Categorized: Site News | Tagged: 3.0, book

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 | 36 comments | Add to Delicious
Categorized: PHP | Tagged: database, performance, Security

Direct Link to Article — Permalink on DiW

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | Comments | Add to Delicious
Categorized: Links | Tagged:

The scoop via Joost Schuur:
Rasmus is talking about an ‘opcode cache’. It essentially caches the parsed PHP scripts in memory. That means PHP doesn’t have to read it from disk or even convert the humanly readable PHP script code into executable machine code (opcode). The one he’s referring to is APC, which is likely going to be included in the next big release of PHP. Xcache is another popular kind. I run it on my site and got about a 3x performance increase on page request server times, so the numbers add up. The W3 Total Cache WordPress plugin has the option of using Xache or APC to keep popular pages in memory via opcode caching.

Direct Link to Article — Permalink on DiW

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | Comments | Add to Delicious
Categorized: Links | Tagged:

1. Create a page template, publish a page

We need a totally unique page template to work with. So create a new one. You know, just make a file like grid-archives.php in your theme and put this PHP comment at the top and then WordPress will recognize it. Then create a new page, pick this template, and publish it. The name and content absolutely don’t matter, just put something there so you can recognize/find it later.

<?php
/*
Template Name: Thumb Archives - Grid
*/
?>

2. Loop it

This is pretty much the entire page. We’ll link out to an external stylesheet for styling. Then we run a Loop for 25 posts (in our demo, we also remove our link style posts). Each post is an anchor tag, and within, the post title, the post image thumbnail, and the excerpt.

<!DOCTYPE html>
<html>

<head>
	<meta charset="UTF-8" />
	<title>Grid Archives | Digging Into WordPress</title>
	<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo("template_url"); ?>/css/gridarchives.css" />
</head>

<body>
	<div id="page-wrap">
		<?php query_posts('posts_per_page=25&cat=-52'); ?>
		<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
			<a href="<?php the_permalink(); ?>" class="box col<?php echo rand(2,4); ?>">
				<span class="title"><?php the_title(); ?></span>
				<img src="<?php echo get_post_meta($post->ID, 'PostThumb', true); ?>" alt="" />
				<span class="ex"><?php the_excerpt(); ?></span>
			</a>
		<?php endwhile; endif; ?>
	</div>
</body>
	
</html>

3. Masonize

Notice in the HTML above we echo’d out a random number between 2 and 4 as part of a class name. The results classes will be: col-2, col-3, and col-4. These represent columns. So each link box is “randomized” based on this class name. Some post link boxes are 2 columns wide, others 3, others 4. Font sizing and thumbnail sizing also adjusts accordingly.

.box { margin: 10px; float: left; }
.box:hover { outline: 2px solid white; }
.box:hover .title { background: none; }
.box:hover .ex { background: none; color: white; }
.box:hover img { opacity: 0.4; }

.col2 { width: 180px; }
.col3 { width: 280px; }
.col4 { width: 380px; }

.col2 img { max-width: 80px; float: right; margin: 0 0 2px 10px; }
.col3 img { max-width: 100px; float: left; margin: 0 10px 2px 0; }
.col4 img { max-width: 120px; float: right; margin: 0 0 2px 10px; }

.title { background: #237abe; color: white; display: block; padding: 10px; overflow: hidden; }
.col2 .title { font-size: 16px; }
.col3 .title { font-size: 18px; }
.col4 .title { font-size: 20px; }

.ex { background: white; color: #222; display: block; padding: 10px; }
.col2 .ex { font-size: 11px; }
.col3 .ex { font-size: 12px; }
.col4 .ex { font-size: 13px; }

So each of those post link boxes is just floated to the left. That’s going to make a pretty ragged and nasty layout all by itself, because each box will be a different height depending on the length of the title and excerpt. No problem though, we’re going to rearrange the boxes using the jQuery Masonry plugin by David DeSandro. We’ll just call jQuery, the plugin, and the write a quick script to call it. This can go pretty much anywhere on the page. Typically jQuery is run on DOM ready, but in this case we are waiting for the window’s load event, because we want to wait for the thumbnails to load before masonizing.

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js'></script>
<script src='<?php bloginfo("template_url"); ?>/js/jquery.masonry.min.js'></script>
<script>
 $(window).load(function() {
   $("#page-wrap").masonry({
      columnWidth: 100, 
      animate: true, 
      animationOptions: {
          duration: 300,
          queue: false
      }
  });
 });
</script>

Enjoy!

Here is ours. Let us know if you play with this on your own site at all.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 13 comments | Add to Delicious
Categorized: Design | Tagged: archives, grid, jquery

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!

Like the article? Get the book!

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

Below we’ll go through the steps for inserting a custom menu into your theme. Note that many themes will have menu functionality built-in. This is for Do-It-Yourself folks who are trying to add it to their existing theme.

1. Register menus in functions.php file

if ( function_exists( 'register_nav_menus' ) ) {
  	register_nav_menus(
  		array(
  		  'foot_menu' => 'My Custom Footer Menu',
  		  'sidebar_menu' => 'Super Sidebar Menu'
  		)
  	);
}

2. Create menu in Admin

Now that the feature is enabled, go to Appearance > Menus and build and save a custom menu.

3. Attach custom menu to your “declared” menu

Now that you’ve declared a menu (in functions.php) and built a menu (in the admin), you’ll need to connect them to each other.

4. Insert the menu into the theme

Now anywhere in your theme you want to display that menu, use:

<?php wp_nav_menu( array('menu' => 'Footer Menu' )); ?>

Change the name of the menu in the code above to match whatever you named the menu in the admin. This very site uses a WordPress 3.0 menu in the footer. The output HTML looks like this:

<ul class="menu" id="menu-footer-menu"><li class="menu-item menu-item-type-post_type menu-item-2636" id="menu-item-2636"><a href="http://digwp.com/contact/">Contact</a></li>
<li class="menu-item menu-item-type-post_type menu-item-2633" id="menu-item-2633"><a href="http://digwp.com/about/">About&nbsp;Site</a></li>
<li class="menu-item menu-item-type-post_type menu-item-2634" id="menu-item-2634"><a href="http://digwp.com/advertising/">Advertising</a></li>
<li class="menu-item menu-item-type-post_type menu-item-2635" id="menu-item-2635"><a href="http://digwp.com/archives/">Archives</a></li>
</ul>

5. Rejoice

Now any time this menu needs to be updated, we can do it from the comfort of the WordPress admin area.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 31 comments | Add to Delicious
Categorized: Design | Tagged: function, menu

Amazingly, WordPress 3.0 was downloaded nearly 11 million times in 42 days. So HUGE congrats and thanks to the entire WordPress crew for an amazing piece of software.

Direct Link to Article — Permalink on DiW

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | Comments | Add to Delicious
Categorized: Links | Tagged:

Direct Link to Article — Permalink on DiW

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | Comments | Add to Delicious
Categorized: Links | Tagged: