The aim of the plugin is to allow authors to inlcude raw code such as HTML, PHP, JavaScript, etc., in their posts by providing them with an encode filter that will encode any code/markup language they wrap in special quicktags.

To learn more about the plugin, click here: WP Post Encode.

Ultimately the goal was to a have a Page with introductory text that could be edited by the client but that also served up a list of posts tagged with a certain tag. Like so:

Initially the concept was easy enough—create a new Page with multiple loops. The first loop would be the main query that pulled the static content while a secondary, custom loop query pulled posts with a specific tag.

The challenge lay in the fact that the static content would always be one page long, whereas the dynamic content might eventually grow into a really long list of posts that would need to be paginated.

So how do we go about creating a paging system that would move through the dynamically‐generated list of posts? By re‐defining the $wp_query object.

The $wp_query Object

$wp_query is the global variable that receives the parameters for a WordPress Page/Post query. Once it gets this information, it attempts to pull the appropriate content from your data base. If you’re calling a WordPress Page, it will show the content from the Page (the text/images you enter in the Page editor when you create a new Page). If you’re calling a Post, it will pull the information for that post (or posts).

$wp_query receives this information from the WP_Query Class (WP v2.0+). The Codex Page on the WP_Query Class goes into detail on how the WP_Query Class functions, but the short of it is that this Class is the magic that makes the content appear on your blog, whether that content is in a Post or in a Page.

Linking to external resources/documents is a the very idea behind the internet and bread and butter of search engines everywhere. However, handling external links (that open in a new window/tab) in a user‐friendly way can be somewhat of a pain.

Recently, I’ve been looking for a developer‐friendly (read: “easy”) way to handle external links on this site as I tend to reference external resources quite a bit in posts and articles. In the old days, you could specify where an external link would open by placing the target="_blank" attribute within the link like so:

<a href="document_url" target="_blank">This is an external link</a>

However, with the removal of the target= attribute in HTML 4.0, this is no longer valid markup. As Kevin Yank from from Sitepoint states:

The HTML 4.0 specification took away the target attribute, but it added another attribute: rel. This attribute is intended to specify the relationship between the document that contains the link, and the target of the link. The specification defines a bunch of standard values for this attribute (e.g. next, previous, chapter, section), most of which have to do with relationships between small sections of a larger document. However, the spec leaves the developer free to use nonstandard values for site‐specific purposes.

To stay standards‐compliant (because that’s what good web developers do, right?) we can now markup external links using the rel attribute link so:

<a href="document_url" rel="external">This is an external link</a>

That’s all fine and well, but what if you’re lazy busy? And you either forget to mark your external links with rel="external", or you’re updating an old site that you’ve converted to XHTML Strict? What’s more, how do you go about alerting your visitors that the link they’re about to click on will open in a new window? (Because that is the polite—and user‐friendly—thing to do). Fortunately with jQuery it’s easy!

First and foremost, the best way to handle external links is to write them properly from the beginning. This means marking them up with the rel="external" attribute and including a title attribute with an alert that the link will open in a new tab/window. In reality this doesn’t happen all the time, so we can use jQuery to handle some of this for us.

Solutions…and Issues

First Solution

The first solution I came across used jQuery to find external links with the rel="external" attribute and add a target="_blank" attribute to each one. There are a few issues with this solution:

1. It relies on the author to remember to add rel="external" to each external link
2. It adds a target="_blank" to each link, which is no longer standards‐compliant.
3. It relies on the author to remember to add a title attribute with an alert about a new window opening.
4. It broke if the rel attribute had more than one value, such as rel="external nofollow"

Second Solution

The second solution I came across fixed some of the issues of the first by re‐writing the regex to account for additional values in rel attributes and no longer adding target="_blank" attribute to the external links. Further, it removed the need for rel="external" all together by matching all links that started with “http://”, under the assumption all internal links use relative paths and external links use absolute paths like so:

• A typical internal link:
• A typical external link:

Yet another solution approached from a different angle and basically adds a target="_blank" attribute to all links that do not start with the site’s own domain name, nor point to an internal anchor with an href value of “#”.

The issues with this solution are the same as the prior two; relying on the author for the title attribute, and utilizing the target attribute. Additionally, it also adds the additional step of requiring the author to change the script to add his/her own domain name. Testing it, I found it broke if you typed “www.domainname.com” in your script, but not “domainname.com” in your link; or vice‐versa.

Ultimately I was looking for the most developer‐friendly, standards‐compliant, user‐friendly way to handle these external links. On the next page we’ll review the solution I came up with.

This site’s Web Development Questionnaire was nominated for the Best Form Design category and ended up winning with 45% of the total votes! Thanks to all who voted!!

As Jennifer Kyrnin (About.com Web Design Guide) states :

“Forms are challenging to build well and not a lot of thought is given to their design.”

Which is all too true; what started off as a simple form, turned into a complex project complete with usability/accessibility issues as well as cross‐browser bugs (thanks IE6) and lots of hair‐pulling. It employs the jQuery library for certain form functions such as pagination, validation, user interaction, and various aesthetics such as screen scrolling. It also employs a custom PHP script for data verification and validation, as well as MySQL for data storage. It’s cross-browser compatible and validates to the XHTML 1.1 standard.

This form started off as a necessity for gathering information, but ended up turning into a labor of love. I plan on releasing the source code of the form, along with its PHP validation script and jQuery scripts, under a GPL in the coming weeks as well as writing a tutorial on its actual build out.

To see a gallery of all the winners, you can follow the link here: Winners: Reader’s Choice Awards: Web Design.

Again, thanks to all those who voted and participated in the contest and congratulations to all the other winners!!

10 nominees per category were chosen and a gallery for each category was created with screen shots of the sites and links to the respective urls.

This year’s nominees include such powerhouse websites as Apple.com, Amazon.com, and Twitter.com, along with independent web design firms, individuals’ sites, and ecommerce sites. (And since the blog section of this site is powered by WordPress, I should point out that Matt Mullenweg, founding developer of WordPress, was nominated for one of the categories.)

Yours truly is one of the nominees for the “Best Form Design” category for the Web Development Questionnaire I created to use on this site, and since this is my site, here comes the shameless plug!

The Web Development Questionnaire I created allows potential clients to contact me with all the pertinent information needed to get the ball rolling on a new web development project. It employs the jQuery library for certain form functions such as pagination, validation, user interaction, and various aesthetics such as screen scrolling. It also employs a custom PHP script for data verification and validation as well as MySQL for data storage. It’s cross-browser compatible and validates to the XHTML 1.1 standard.

You can see a screen shot of the form here on Jennifer’s Blog on About.com, or you can view the actual form on this site here.

May 4th marked the beginning of the voting period with voting open to everyone. Jennifer Kyrnin, the About.com Web Design Guide overseeing the contest, encourages each nominee to encourage their friends, family, and clients to vote, so go out there and vote! For more information on voting, see Jennifer’s post here.

This year’s categories are as follows:

• Best Use of Colors in Web Design
• Best Use of Images in Web Design
• Best Form Design
• Best Information Page Design
• Best Product Page Design
• Best Ecommerce Site Design
• Most Original Design
• Best Designed Web Designer’s Site
• Best Overall Web Design

Voting is open until May 22, 2009 with the results released on May 25, 2009. Check back here or on Jennifer’s blog to see the results!

Good luck to all the nominees!

The current cproject I’m working on involves using some posts in a non‐traditional manner. They are not meant to be read as traditional posts in the blog section of his site and therefore should not be included in search results. These posts are all tagged with a specific keyword tag that’s utilized by a custom WP get_posts() call that displays them in the site’s header. The whole idea was that these posts with certain tags should be excluded from the search results because they hold no relevance for the site’s readers. And, since I’m using WP as a CMS to manage the client’s site, I also realized I needed the same functionality to exclude Pages from the search results as well.

I did a few searches in the WP forums and on Google and found a few solutions, but none of them worked perfectly for my purposes. The first required throwing a conditional if statement in the Loop on the search results page, essentially removing whatever post or page you wanted to exclude. The second (and this is the one I found the most) involved creating a filter function and hooking it to a WP filter hook.

I chose the second method since I don’t like the idea of retrieving all the information and then looping it through an if statement to cull what I need. The second method, a filter, seems cleaner.

Getting Started

Instead of just throwing the code out there, I figured it’d be best if I showed, step by step, how to accomplish this so you can implement it on your own site. Basically we’re doing the following:

1. Intercepting the main WP query.
2. Checking to see if it’s a search query.
3. Adding our filter to the query before it retrieves data from the database.

In it’s most simple form this is what it looks like:

<?php
function FunctionName($query) {
    if ($query->is_search) {
    $query->set($query_var, $value);
    };
    return $query;
};

add_filter('filter_hook','FunctionName');
?>

I’m not going to go into too much detail about WordPress filters in general, and how they work since the Codex page on them provides a lot of information. Instead, let’s focus on how this particular filter function works. But if you’re interested in learning more, be sure to check the Codex out.

How It Works

In order to understand how the function–and subsequently our filter–works, we need to first understand how WP processes a search request. The Codex page on the WP_Query Class provides some great information on the Methods and Properties of it, but unless you’re familiar with PHP, it may seem a bit foreign. What we’re looking for specifically is what variables WP uses to pull the search results, because after all, these are the results we want to manipulate.

The following is a list of the query variables WP uses to pull search results:

Array (
    [s] =>
    [error] =>
    [m] =>
    [p] =>
    [post_parent] =>
    [subpost] =>
    [subpost_id] =>
    [attachment] =>
    [attachment_id] =>
    [name] =>
    [hour] =>
    [static] =>
    [pagename] =>
    [page_id] =>
    [second] =>
    [minute] =>
    [day] =>
    [monthnum] =>
    [year] =>
    [w] =>
    [category_name] =>
    [tag] =>
    [cat] =>
    [tag_id] =>
    [author_name] =>
    [feed] =>
    [tb] =>
    [paged] =>
    [comments_popup] =>
    [meta_key] =>
    [meta_value] =>
    [preview] =>
    [category__in] => Array ()
    [category__not_in] => Array()
    [category__and] => Array()
    [post__in] => Array()
    [post__not_in] => Array()
    [tag__in] => Array()
    [tag__not_in] => Array()
    [tag__and] => Array()
    [tag_slug__in] => Array()
    [tag_slug__and] => Array()
    [post_type] =>
    [caller_get_posts] =>
    [suppress_filters] =>
    [posts_per_page] =>
    [nopaging] =>
    [comments_per_page] =>
    [search_terms] => Array()
    [order] =>
    [orderby] =>
    )

I won’t go into all of them now, instead let’s focus on excluding Pages from search results and only include Posts, since that seems to be a pretty popular request. For that, we’ll need to use the post_type query variable. (WordPress assigns a value of either “post” or “page” to this variable when you create either a blog Post or a Page.)

Now that we have the variable we need, let’s set our function up. Open your “functions.php” file (located in your theme directory), or create one if your theme doesn’t have one, and add the following:

<?php
function mySearchFilter($query) {
    if ($query->is_search) {
        $query->set('post_type', 'post');
    };
    return $query;
};

add_filter('pre_get_posts','mySearchFilter');
?>

What this does is instruct WordPress to check if we’re on a Search Results page:

if ($query->is_search)

if we are, run it’s search query only on posts:

$query->set('post_type', 'post');

before it pulls posts from the database:

add_filter('pre_get_posts','mySearchFilter');

WordPress will now exclude any Pages from its query and only search Posts. To activate this, just save your “functions.php” file and upload it back to your theme directory. Or if you’re using the built‐in Editor in your WP Admin Section (Appearance→Editor→Theme Functions) add the function, then click the “Update File” button.

Conclusion and References

Using the query variables listed above you can customize your search results in a variety of ways. You can search specific Categories, exclude posts with certain tags, specify to search only specific posts, etc. In a later article I’m going to demonstrate a way to exclude Posts tagged with specific tags.

If you’re interested in learning more, I encourage you to read the following Codex pages:

• The Function Reference on the WP_Query Class, the fundamental function that powers the WP query. Link.
• The Plugin API on Filters. Link.
• The parameters for the query_posts() Template Tag. It’s not an exhaustive list, but touches on the most common ones. These are the same parameters as the query variables noted above. Link.

Whats more this plugin is incredibly user‐friendly, as everything is controlled with CSS and 2 custom quicktags.

Example Output:

From this example you can see what’s possible with this plugin; giving you the ability to create a newspaper or magazine‐style layout within your blog or specific posts. It’s easy to switch between multiple columns and full-width blocks of text such as this paragraph.

The formatting is controlled purely by CSS using two classes; “column-sect” and “post-column”, allowing you to customize it any way you’d like. Simply add these two classes to your style sheet and adapt them to your theme.

Installation

1. Download the “mish_wp_columnize.zip” folder, then extract.
2. Upload the uncompressed folder to your plugin directory (wp-content/plugins).
3. Activate the plugin through your Admin Dashboard.
4. Add the following classes to your style sheet: “column-sect”, “post-column” and set their values.

Parameters

None. Yet.

Usage

It’s recommended you use the HTML editor when writing posts with columns. The WP Columinzer plugin installs two quicktag buttons in the toolbar of HTML editor for your convenience.

To use: Simply wrap whatever you would like to appear in a column in the following tags: “[/col-sect] <p><strong>Note:</strong> a value of &#8220;<code>inline-block</code>&#8221; must be set on the containing <code><!--encode--><div> in order for it to display properly in IE6. Also, setting “display:inline” on “.post-column” prevents the doubling bug in IE6.

Example 1

You can put columns on one line:

Example 2

Or you could put each element on its own line. (Easier to read your markup this way.)

Notes

This plugin has been tested using both the visual editor and the HTML editor in the dashboard and should work as expected. However there isn’t a quicktag button for the Visual editor.

The plugin also attempts to accommodate for the <br /> tags WP adds when you hit “enter” while typing a post, but extensive testing hasn’t been done to test for extreme circumstances.

Also, be sure to check the widths of any element you’re wrapping in the quicktags. At this time, only one width can be set for the columns (since it’s set in your stylesheet), but future upgrades should address this.

Safari Issue: For some reason, Safari chokes if a heading (<h1>–<h6>) starts a column and sits on its own line. (It doesn’t float the columns).

So this is fine:

[column]<h3>An Introduction</h3>

While this isn’t:

[column]
<h3>An Introduction</h3>

This is something only noticed in Safari and only with headings, and only at the beginning of the first column.

Updates

Current Version: 0.6.5

Changelog:

• v0.5 : December 11, 2008 : Initial release
• v0.6 : December 13, 2008 : Added shortcodes and additional filtering.
• v0.6.3 : December 16, 2008 : Added buttons to HTML editor toolbar
• v0.6.4 : December 18, 2008 : Made forward-compatible
• v0.6.5 : December 24, 2008 : Fixed auto-install button option

I’ll expand upon these topics in future posts, but for now let’s cover the basics.

Content Development: Clear Understanding of Intent

Web users skim, they do not read, and they will leave your site if they cannot understand the intention of your site withing seconds of viewing your pages. Concise, descriptive, keyword-rich phrasing and terminology will not only encourage your visitor to read more (stay), but can also inform, and improve your SEO.

Content Development: Information For Your Visitors

Your site’s content is the catalyst to get your visitors to return to your site time and time again, and if you’re a business; to turn potential customers into actual customers.

Content development is not just the creation of the descriptive and informative text (and graphic) content on your site, but also deciding what to include on your site. The information included should be developed with an emphasis on your target audience. Any site created for a purpose other than personal communication (i.e. personal blog), should keep the visitor in mind when developing its content.

Content Development: Quality Over And Quantity

While content is king, bad content is… not. Website owners should not cut corners on the quality of content for their sites. Often, budgets are geared more for the design of the graphical content (images, graphics, icons) rather than the development of quality [text] content.

Unless you are creating a portfolio site to display artwork, visitors to your site are looking for information; be that educational or commercial (i.e. product purchases). Part of your budget should be designated toward content development that will draw your visitor in and persuade them to return.

Simply stuffing your site with as much textual information (copy) as possible is not “content development”. Quality information that your visitor wants is much more effective than an abundance of minimal-quality content that the [potential] customer doesn’t want. Or need.

One other note: The graphical appearance of your site does not assist in search engine placement; the textual content of your site does.

Page Design: Consistent and Clear

Textual content development is all fine and well, but the “fun” is in the graphics, color scheme, and layout of your site. You want a site that not only gives your visitors the information they’re looking for, but one that looks great (for those with visual browsers) as well. The theme of your site is what will catch your visitors eyes’ and turn them from “visitors” into “readers” (and “buyers”). A solid design philosophy–that captures the essence of your message–is the key to engaging the widest base of visitors.

The basis of good design starts with easy (to understand and use) site naviagtion and clear presentation of your information. While (good) content is king (and the primary reason visitors are on your site), it’s also useless unless your visitors can find it easily and enjoy viewing it.

Rule of Thumb: “Fancy” is nice, but “effective” is better.

Conclusion

With the abundance of tools available today to create an online presence, it’s tempting to rush through development in order to get "online" as soon as possible. This often results in sites that are not only poorly executed, but actually harmful to the reputation of the company.

Careful planning of your site and its content, and a clear understanding of your target audience, are the keys to a successful online venture.

Well, that, and having something people want.