I Am Blogie

I got an inquiry from one of my blog’s readers about post pagination, which I used in my previous post. Well, it’s very simple. To split your post into separate sub-pages, simply use the WordPress Quicktag, <!--nextpage-->.

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

[html toolbar="false" highlight_lines="5"]

Step #5

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. Euismod libero 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-->

Step #6

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
[/html]

As you might have seen in my last post:

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

Since WordPress 3.0 was launched, I’m sure you’ve noticed the Get Shortlink button below the post title input field in the Add New / Edit Post screen, beside the post’s permalink. (See image below.) It’s a nifty feature made available to us by good old WordPress.org for shortening our posts’ URLs. Clicking on it will give you a wp.me URL which will redirect to your blog post. (This post’s shortlink, for example, is http://wp.me/pqxl6-Y.)

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 toolbar="false" gutter="false"]

[/php]

Here’s how my code looks like:

[php toolbar="false" highlight_lines="5"]

[/php]

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.

Oyako (親子) is a Japanese term that means “parent-child”. In Japanese cuisine there’s a tasty dish I like that’s called oyako-don, which is a bowl of rice toppings of chicken and egg. And why am I talking about this? WordPress’ child themes!

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.

WordPress 3.0 is set to be released this month, and I can’t tell you how very excited I am to get my hands on it. I do have the beta2 version, and I’ve been playing around with it. There are quite a few new stuff you can expect from WP3.0, but the most significant update (in my view) is its multi-site functionality. Read: WordPress and WordPress MU are now being merged.

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.

You’re a Web developer and you need some sort of staging for your WordPress-powered site. You don’t like developing your site directly off of your production server because (1) Internet connectivity isn’t always reliable or fast, (2) you prefer to keep your site under wraps until it’s ready for the public eye, (3) some other reason I haven’t thougth of yet.

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!