One of the nice things about using WordPress’ new post-thumbnails feature is that they provide tons of flexibility in terms of where and how you display your post thumbnails. By design, post thumbnails are not included within post content, so they will not be displayed in your blog posts unless you call them specifically with the proper template tag:
I'm a HUGE fan of being able to link up a CSS file on a per-page basis. I just find it extremely common that a page needs CSS styling unique to it, and I hate litering a sites main stylesheet with customizations that only one particular page needs. We've talked about this before, and even created a custom method for doing so, as well as mentioned the art direction plugin, which makes this easily possible.
The titles of pages are controlled by the <title> tag in the <head> section of a website. They are important for all kinds of reasons. Telling the user where they are. The name of the page when bookmarked both locally and socially. They are important for SEO.
We covered how to run a shortcode in a widget. But what about inserting a widget with a shortcode? I recently had this situation come up. I had a single page where I just wanted to be able to chuck in a widget without the whole rigmarole of creating a special widgetized area and probably a custom page template for that widgetized area and such. I wanted to just put [widget widget_name="my_widget"] in the pages content and have that widget pop in. Turns out it wasn't as easy I wanted it to be, but it's not that bad...
In a recent post, we show you how to clean up and enhance the functionality of WordPress with a custom functions.php template. In that post, we explain how using a custom
functions.php template can speed up development while optimizing many key aspects of WordPress. In this post, we deliver another prime collection of 15 custom functions to enhance your WordPress site. These functions provide all sorts of useful functionality, including stuff like:
When designing WordPress themes, I always add a common set of custom functions to the theme’s
functions.php file. This speeds up development time because I don’t have to hunt for and individually copy the same slew of functions for every theme. I just drop in a copy of my functions.php template and build up from there. This takes care of all those little things that always need to be done:
Have a bunch of different areas you wish to declare as a widgetized area? Save repetative code by creating a quick array of their names, then loop through that array calling the register_sidebar() function on each one. Elementary PHP stuff here, but hey, it just saved me quite a few lines of code in a widget-heavy theme I am working on.
The post_class() function in WordPress is pretty darn useful. It is used like this, in most templates, in a wrapping div of all the content you are outputting:
Displaying all the comments on a Post is incredibly easy. In your single.php file you probably have a line like this:
I had the situation come up where I need a password-protected post in WordPress. Of course that is super easy in WordPress, you can set up a password for it right in the "Publish" box before publishing. But by default, WordPress appends "Protected: " to the front of the post title, before and after the password has been entered. I didn't like that, and thought that the password box was clue enough that the material was password protected.
If you have posts that include the
nofollow attribute on links, you may at some point decide to remove them. By default, WordPress doesn’t insert
nofollow attributes in post content, but there are a variety of plugins that will insert
nofollow into all links in post content. Or perhaps you have been manually adding
nofollow tags to your post links for SEO purposes. Regardless of how they got there, it’s very easy to clean things up and remove all
nofollow attributes from post content.
Tag clouds accomplish their varied font sizes by applying inline styling to each tag. The resulting font sizes can be really weird like style='font-size:29.3947354754px;'. There is nothing inherently wrong about that, but it feels a bit unsettling and less controllable. Mike Summers sent in a solution he uses on his own site. Let's check it out.
I like the idea of shutting off comments after a certain number of days. Here on Digging Into WordPress we do it after 90. After that kind of time, the "community" of the discussion is long over. I think a good practice for turning off comments is to instead leave a message informing visitors that the comment thread is closed, and offer a course of action in case they have something of grave importance to share.