I use YARPP on almost all of my WordPress sites, and I’ve started tweaking the plugin’s output, inspired by another related-posts plugin that I saw on DavaoBase recently. That other plugin is called LinkWithin, and I like how it displays related posts with thumbnails. However, this plugin has almost no options, unlike YARPP, which has tons of it! (And I’m suspicious of LinkWithin’s way of inserting redirects — it’s as if, for whatever reason, they’re out to track the clicks…)

DavaoDeli.com screenshot

So, here’s something I’d like to share with those of you who’d like to keep using YARPP and display a thumbnail for every related post displayed on your blog posts. The screenshot here shows a post from my food blog — take a look at the bottom part (in the red square) with the “You might also like…” heading.

YARPP has a set of sample templates that let you control the visual output of the plugin. Instead of settling for the default settings, you can have a higher degree of control over how the related posts are displayed by using the YARPP templates. Simply copy one of those templates (located in wp-content/plugins/yet-another-related-posts-plugin/yarpp-templates) into your current theme’s directory, modify that template to your heart’s desire, then activate it via the YARPP settings page.

The custom YARPP template

Create a template file in your theme directory that will contain the related-posts code. For our purposes, let’s name this file yarpp-template-thumbs.php (N.B., for YARPP to recognize the template, it has to be prepended by “yarpp-template-”). The code I wrote for DavaoDeli.com is the following:

<?php /*
YARPP Template for use with post thumbnails
Requires WordPress 2.9+ and the WooThemes framework
Author: Blogie
*/ ?>

<?php if ($related_query->have_posts()) : ?>

<div class="relthumbs">
	<h5 class="relposts">You might also like...</h5>
	<ul class="relposts-thumbs">

	<?php while ($related_query->have_posts()) : $related_query->the_post(); ?>

		<li class="relitem">
			<?php woo_image('key=image&width=80&height=80&class=relimg'); ?>
			<span class="thumb-ttl"><?php the_title(); ?></span>
		</li>

	<?php endwhile; ?>
	</ul>
</div>

<?php else: ?>

	<p>No related posts at the moment.</p>

<?php endif; ?>

Line 7 above declares the start of the special WordPress Loop that calls the related posts (handled by the plugin). Line 16, on the other hand, is the one that displays the thumbnails. It’s a built-in function in all WooThemes.com themes with WooFramework version 3+.

YARPP settings

For those of you who don’t use WooThemes, don’t despair. There is a YARPP template included with the plugin that you can use. It’s called yarpp-template-thumbnail.php. Just copy that template to your current theme directory, activate the template via the YARPP settings page, and make sure to follow the instructions contained in this page from the WP Codex.

(If you’re using a child theme, place the thumbnail-related WordPress functions in the child theme’s functions.php template.)

That’s it! I hope you’ve found this useful.

For example, I’m working on a classified-ads site and the premium theme package I’ve chosen makes use of custom post types. It’s a wonderful theme (ClassiPress) and I love it. Classified ads appear in their own custom posts called ad listings, and are posted under ad categories. The screenshot of the site’s dashboard (see image) shows an extra menu item that says “Ads”. The ad listings, their categories and tags are accessible under this menu.

The ClassiPress theme (made by Appthemes.com) has lots of cool built-in features, too, such as a way for ad posters — people who submit ads to the site — to mark for-sale items as “sold”. And, when ads are marked thus, the ad page would have a “sold” tag prominently displayed on it. Problem is, I’ve put in other classified-ads sections in the mix: For Hire, For Rent and Personals. It wouldn’t be a good idea to have, say, a caterer’s services advertised under the For Hire section to be marked as “sold”, would it?

The next page shows how I did it.

Remember the <!--more--> tag? It cuts the post where it’s placed when the post appears in the blog’s front page. The <!--nextpage--> tag, on the other hand, works as a ‘paginator’ for single posts, and divides them into sub-pages where they’re placed. You can have as many pages as you like (but don’t over do it).

For example (use the HTML view when inserting the quicktag):

<h3>Step #5</h3>
Consectetuer rutrum urna in, a molestie aliquam gravida, quam vestibulum ac. Consequat ut lacus tempus a ipsum, sociis urna sed, vel tellus maecenas, lorem maecena's tortor. At odio platea etiam. <strong>Euismod libero</strong> pretium accumsan pellentesque ac. Quam semper in vitae dictum eget, ipsum magna orci odio lectus. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit.

Please see the next page for the last 3 steps.
< !--nextpage-->
<h4>Step #6</h3>
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, <em>totam rem aperiam</em>, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.

As you might have seen in my last post:

And we can even do it right now! (Make sure to click on Page 2)

If you promote your blog posts via Twitter or Plurk, you probably use a plugin for auto-posting to those online services. However, if you’re the type who wants to personalize your shout-outs that go with your blog post link — maybe so you can insert hashtags — you’d have to manually add the post URL yourself, don’t you? And if the URL’s too long, you’d have to use a URL shortener like bit.ly or tinyurl.com (or any of the scores of similar services), right?

Not anymore. With wp.me shortlinks, your WordPress blog now has a built-in URL shortener! Don’t you just love WordPress!?!

But wait, there’s more!! (Am I sounding like a TV salesman already? )

What if you wanted to make the shortlink visible on the blog for everyone to see? That’s exactly what I did with my food blog. See, sometimes I go back to old posts and promote them on Twitter and Facebook. Instead of having to go inside the dashboard and get the shortlink from the Edit Post screen, I can now just go to the blog post (or even the search results page) and copy the shortlink from under the title. Take a look at this screen shot of a couple of front-page posts from Davao Delicious:

Notice the “[shortlink]” text below the titles? By using a WP template tag, I was able to output the shortlink of each post onto various locations of the blog: the main page, single posts, archives, and the search results page. (And my other blogs are sure to follow suit.)

Here’s how to do it. There is just one new template tag involved: the_shortlink(). This tag must be placed inside The Loop, otherwise it won’t work. And, according to the Codex, it will only work on WordPress sites that implement pretty permalinks.

<?php the_shortlink( $text, $title, $before, $after ); ?>

Here’s how my code looks like:

<div class="post-title">
	<h2><a href="<?php the_permalink() ?>" rel="bookmark" title="<?php the_title(); ?>"><?php the_title(); ?></a></h2>
	<p class="post-details">
		Posted on <?php the_time('j F Y'); ?> by <?php the_author_posts_link(); ?>
		<?php the_shortlink('shortlink','','[',']'); ?>
	</p>
</div>

The first parameter, $text, can be any string that you’d like to be seen by your site’s visitors. The next parameter, $title, is for the tooltip text that will appear on mouse-over. If you leave it blank, the default is the post’s title. The last two, $before and $after are for HTML codes and/or more text that you’d like to appear before and after the shortlink.

All of the parameters are optional. However, leaving the first one blank will result in this text link: “This is the short link.” Kinda fugly if you ask me, so it might be best to supply your own expression.

That’s it! Have fun with the WordPress URL shortener!

N.B.: Each post (and page, including the front page) actually has an assigned wp.me URL. If you view the page source, you’ll see the shortlink in the header. That is, if you’ve activated the WordPress.com Stats plugin and specified that the shortlink be published as meta data.

Ever got tired of copying over the changes you’ve made to your templates each time your theme is upgraded? Ever lost template changes after upgrading your WordPress theme? Well don’ fret, because here’s something that I’m sure you’ll find heaven-sent.

Child themes have existed since WordPress 2.7 (but I’ve only now gotten around to tinkering with it), and it’s the best way to go about modifying — and keeping the changes to — your themes’ templates.

I’ve started using child themes in some of my blogs. Take a look at the screenshot of Blogie Blog’s dashboard, showing the child theme:

Basically, when you use child themes, you can create a separate theme (based on the parent theme) that will hold all your template modifications. So, when your theme provider publishes an update, you can update the parent theme and keep the changes you’ve made in the child theme.

Child themes inherit all the templates (index.php, single.php, etc.) from its parent — that is, those templates that you don’t override. One template that must be unique to the child theme, however, is style.css. That’s right: when you create a child theme, it must have its own stylesheet file.

If you’ve read the Codex, you’ll know that you’ll need to create a style.css file and that’s where you’ll place your own style declarations for your site. And, to include all the style declarations from the parent theme, you’ll need to import it into your new stylesheet file (using @import). This is all that’s required for you to have a child theme.

If you create a new single.php template for your child theme, it will override the parent theme’s template. This is useful for those templates that you want to modify to suit your needs. The templates that you don’t override will simply be inherited by the child theme. In fact, you’ll notice that the parent theme’s templates will appear in your child theme’s list of templates (Appearance > Editor).

Some things to watch out for when using child themes–

When overriding templates (e.g., header.php), check to see if hyperlink calls are properly formatted. Some theme designers use the WordPress function <?php bloginfo('template_directory'); ?> to call theme images or CSS files. For example:

[php toolbar="false"]

On this blog, the above code will resolve to the following:

[html toolbar="false"]

Please take very careful note of this: Even if the above sample code is placed in a child theme template, the <?php bloginfo('template_directory'); ?> function will still return the URL of the parent theme. On the other hand, the WordPress function <?php bloginfo('stylesheet_url'); ?> will always return the URL of the style.css template of the active theme. So, if you have a piece of code like below placed in a child theme’s template, the latter function will most certainly return the URL of the child theme’s style.css file.

[php toolbar="false"]

Child themes don’t seem to see below its parent theme’s directory. I use WooThemes’ excellent themes, and their theme files (PHP templates, CSS files, images, JS files) are organized in sub-folders. All the main PHP templates (index.php, page.php, archive.php, etc.) are in the root directory of the theme, but most of the support files are placed in sub-folders. It seems that the files in those sub-folders are not accessible to child themes… You see, I tried to override some of the templates existing in the parent theme’s sub-folder by recreating those templates and sub-folders under the child theme’s own directory. No go.

Solution: change the hyperlinks calling those templates (or images, etc.) to reflect the actual locations.

So far, I’ve only been experimenting with the fundamentals of WordPress child themes. I know there’s a lot more to it, especially in the functions.php arena. To get you started on that, do read this article.

For the benefit of those who are as yet unaware, WordPress μ (MU or “multi-user”) is a branch of WordPress that lets super administrators create a network of blogs in one installation. This is, in fact, what powers wordpress.com blogs.

I’ve finally gotten the multi-site (or multi-user) functionality of WordPress 3.0 beta2! And I’d like to share how I did it. You may choose not to use this functionality and use WordPress 3.0 as a single-site blog, but if you do want this awesome feature, do read on!

Here are the salient details of my WordPress environment:

Before installing WordPress, you need to add this entry to your chosen domain name’s DNS table: *.domain.tld. 1400 in A {IP address}. Let’s assume your domain name is myblognet.ph, and the IP address that your web host has assigned you is 222.111.2.3. If you don’t have access to DNS, ask your host to do this part for you. The entry should look something like this:

[bash toolbar="false"]
*.myblognet.ph. 1400 in A 222.111.2.3
[/bash]

Then, you’ll need to change some stuff in your Apache configuration. Please be careful with this and triple-check your work at each step, to ensure you won’t accidentally mess things up. You’ll need to access the httpd.conf file (in my setup, this file is located in /usr/local/apache/conf/), and update the VirtualHost section containing the domain name you’re using for WP3.0. To wit (highlit lines):

[bash highlight_lines="3,4" toolbar="false"]

ServerName myblognet.ph
ServerAlias *.myblognet.ph
ServerAlias www.*.myblognet.ph
# more code here…
# no need to edit them!

[/bash]

You should then execute the following command (via SSH) so that the VirtualHost changes you made will take effect.

[shell toolbar="false"]
>> /usr/local/cpanel/bin/apache_conf_distiller –update
[/shell]

Your hosting environment may be different, so if you’re doing this on your own, please ask your host about the command above. Tip: use the locate command in SSH to find files and executables; e.g., locate httpd.conf.

Then, execute the following to restart your Web server.

[shell toolbar="false"]
>> /etc/init.d/httpd restart
[/shell]

Now, go ahead and install WordPress. Upon successful installation, add the following directive to your wp-config.php file. It would be a good idea to place this line (#83 below) just above the part that says /* That's all, ... */

[php num="83" highlight_lines="83" toolbar="false"]
define(‘WP_ALLOW_MULTISITE’, true);

/* That’s all, stop editing! Happy blogging. */
[/php]

Login to your dashboard and click on Tools » Network. The next screen will guide you through some more setup instructions, particularly for your wp-config.php and .htaccess files. Make sure to choose the sub-domain functionality, to be able to give your users a sub-domained site, such as http://pokerclub.myblognet.ph.

Once that’s done, you will notice a new menu item above the home icon: the Super Admin. And voilá, you now have a working multi-site WordPress installation! Go ahead and test it by creating new sites.

If you have questions, please feel free to drop a line below.

Although WordPress will run on Windows/IIS, chances are, your Web hosting will be on a Linux box running Apache. So, the best way to recreate that environment for local development on your desktop or notebook is to install a local Web server package. What I use now to develop new WordPress sites is WampServer 2.

WampServer emulates the Apache Web server with PHP and MySQL installed. All the necessary modules that WordPress needs (e.g., mod rewrite) are present, and it takes just a few minutes to install and run. Do you feel a how-to coming on…?

OK, let’s get started. I’m assuming here that you use Windows. If not, I’m sure you’ll find something similar for your Mac.

Installing WampServer

Download WampServer 2 from the link above, and install it on your local machine. It will do everything in the background for you, including installing PHP and MySQL. What’s more, you’ll even have access to your own phpMyAdmin and, if you prefer the classic approach, a MySQL console.

After installation and initial launch, you’ll get a WampServer icon on your system tray, looking like half a speedometer. Click on it to bring up the menu. If it’s not online, click on Put Online. If you type “localhost” on your browser URL bar, you will see something like this page:

To install WordPress, follow the steps below. But before that, don’t forget to activate Apache’s rewrite module — without this, you won’t be able to make use of WordPress permalinks. Left-click on the WampServer icon on the system tray, and go to Apache » Apache modules. You’ll then get a long list of modules arranged alphabetically. Look for rewrite_module and check it.

Installing WordPress

OK, now for WordPress. Extract the WordPress .zip file onto c:\ — this will create c:\wordpress. You may change the name of the folder to anything that you fancy, but for our purposes, let’s keep it as is.

Bring up the WampServer menu, and create an alias directory: Apache » Alias directories » + Add an alias. This will cause a command-prompt window to open with the following screen:

Enter your alias.
For example,
 
'test'
 
would create an alias for the url
 
http://localhost/test/
:_

Let’s use blog as our alias. The next screen will show this:

Enter the destination of your alias.
For example,
 
'c:/test/'
 
would make http://localhost/blog/ point to
 
c:/test/
:_

Enter c:/wordpress/, the directory we created earlier. When successful, a message saying “Alias created. Please Enter to exit…” will appear. Now you’ve created a website account with the URL, http://localhost/blog/.

Next, let’s create the database and database user in MySQL. Take a look at this page from the WordPress.org codex for step-by-step instructions on creating databases using phpMyAdmin.

Armed with your database name, username and password, you can now go ahead and perform the famous WordPress 5-minute install. Load http://localhost/blog/ on your browser, and you’ll see that WordPress says it will create the configuration file for you. Go to the next screen and enter the database credentials, and voilá! You now have a WordPress site running on your desktop or notebook!

WP2.8’s theme installation / uploading should work, as well as the similar interface for plugins. Everything should look and feel as if you had a live WordPress install, except that this one’s probably much faster and responsive.

To the bat cave!

After you’ve done your design work, template-tweaking and all your customizations, after publishing your new site’s static pages (”About”, “Contact Form”, etc.), and probably a few blog posts as well, you can now deploy your WordPress site onto your production server.

Backup your database by following this excellent procedure written by Automattic.

Use cPanel or FTP to transfer the WordPress folders and files (wp-admin, wp-includes, wp-content & all the .php and other files in the main directory) to your website account on your production server. No need to reinstall WordPress. Simply transfer the entire local site to the live Web.

WP-DBManager options

If you’ve installed plugins (e.g., WP-DBManager) that have settings asking for server paths, make sure to change them to the proper values as soon as you finish transferring your site. Take a look at the screenshot of WP-DBManager, which I installed in my own WampServer-driven local WordPress site. As you will see, the server paths indicated are those of my local machine’s. After deploying this site to the Web, I should change these values to my production server’s paths. (Good thing this plugin has auto-detect buttons!)

Now for your database. Presumably, you already have a .sql file on your local hard drive, generated by the backup procedure above.

On your production server, bring up phpMyAdmin and create a database with the same name as the one you created earlier on your local machine. Specify the same username and password as well. (Otherwise, if you use different database login credentials, change those values in your wp-config.php file.) Now, choose that new database and select Import from one of the horizontal tabs, and follow the instructions.

And that’s it! Your new WordPress-powered site’s live!