I find on nearly every one of the many, many WordPress powered sites I take care of, I have at least a couple of special page templates that I set up and use frequently.
Not everyone loves the post-revisioning feature of WordPress. In fact, some people can’t stand it. On the one hand, it’s nice to have a library of post-draft revisions to drudge through if you should ever make a mistake. On the other hand, multiple copies of every post is a great way to bloat your database with otherwise useless information.
In this DigWP tutorial, we take a look at a the potential security risk inherent in displaying your site's WordPress version number to anyone or anything that happens to stop by for a visit. For anyone who has been working on securing their WP-powered website, one of the most commonly seen security tips around the WordPress-o-Sphere has got to be this:
I usually recommend that people install WordPress at the root directory of their sites. Even if you intend to mostly use WordPress for a blog, and run it at
/blog/, you can still do that when WordPress is installed in the root directory. It's just a matter of changing some simple settings. But just because WordPress is installed and controlling your site from the root directory, that doesn't mean that the WordPress core files need to be located in that same location.
There are so many awesome ways to display your WordPress pages. Out of the box, WordPress provides two different template tags for displaying lists of your site’s pages. The first, most-commonly used tag is
wp_list_pages(), and the second, lesser-known tag is
wp_page_menu(). First we’ll explore the highly flexible
wp_list_pages() template tag, and then we’ll dig into the new
wp_page_menu() tag. Along the way, we’ll check out some delicious recipes, tips and tricks for creating the perfect WordPress Page Menu.
On blogs that like to share snippets of code like this one, it is common to use the
<pre></pre> tag to wrap the code so that the spacing/indenting is maintained and long lines do not wrap. While this is desirable behavior, it can be undesirable to have those un-wrapped lines break out of their containers awkwardly and overlap other content.
As you may recall, there are a ton of configuration tricks available for the WordPress
wp-config.php file. So many in fact, that I think many people may have missed some of the choice definitions aimed at optimizing WordPress performance. In this post, we’ll explore the best ways to improve your site’s performance with WordPress’
Tumblelogs are a great way to streamline mixed-media blogging for different types of content. Commonly used tumblelog topics include “Links”, “Photos”, “Quotes”, “Dialogue”, and “Video”. A good tumblelog presents each these different topics with its own unique format while retaining an overall sense of cohesion throughout the entire design.
There are probably a couple ways to do this, but here is a really easy one:
ob_start(); the_content(); $content = ob_get_clean();
In an effort to inspire more WordPress theme designers to embrace HTML5, I am releasing the “H5” Theme Template. The H5 Theme Template is a bare-bones WordPress theme built entirely with HTML5 and styled with some basic CSS 3.0.
As you may know, HTML5 provides greater flexibility and interoperability than previous markup languages, and enables us to build well-structured themes that are more flexible, interactive, and semantically precise. So using it to build awesome WordPress themes is a no-brainer.
Just recently my other blog CSS-Tricks was hacked. I first found out by a very helpful reader emailing me a screenshot from the mobile version of my site.
Many WordPress users know the
wp-config.php file as the key to the WordPress database. It is where you set the database name, username, password, and location (among other things like security keys, database prefix, and localized language).
Here's a screenshot of
wp-config.php (aka the WordPress configuration file) for those who may not yet be familiar:
I previously posted on how to include jQuery in your WordPress theme the Right Way. That is, to use the
wp_register_script function to register the script first. It's literally a one-liner in your header.php or functions.php file, but by default, it loads the internal version of jQuery that ships with WordPress.