Anthology of Ideas

When XHTML was first released nearly everyone, myself included, rushed headlong into it. Countless websites were shredded, old HTML code was stripped out and rebuilt using XHTML syntax under the watchful eye of the W3 validators. When it was over, the dust settled and, for a time, everyone tried to pretend HTML no longer existed — scorning those who had the audacity to still use HTML.

Time passed. People began realizing that XHTML wasn’t the save all and be all that it was supposed to be: some popular browsers (cough: IE) couldn’t even properly render its content type of application/xhtml+xml, so developers were stuck calling it XHTML and pretending that it was truly XHTML+XML, but they were really just dishing out HTML that was properly formatted.

This is not to say that the “XHTML rush” ™ was bad or that it didn’t advance technologies and the semantic nature of programming: it, with the help of CSS, helped to banish the hack and slash methods that were intrinsic in the 1990′s because people started realizing what each tag really meant and peer pressure abounded.

The average WordPress theme has different files for pages, single posts, archives and the front page; however, most of them are almost exactly the same except for inside the_loop. This is a quick tutorial on how to do the most with the fewest files, and includes a few methods to have custom templates by separating content display from structural elements.

WordPress looks first for special files and then defaults to the index.php file (as shown in this diagram). We can take advantage of this by using only an index.php file and then using conditionals to modify it. While it seems that this method would render the code less readable, it is actually far more readable, and far easier to modify.

Your theme should start off a header.php, footer.php, sidebar.php and an index.php. These files are the “code” files and are fairly self-explanatory, and at this point the only question should be whether you add just the header portion of the file to the header.php or everything including the calls to get_sidebar()—the same goes for the footer.php depending on your theme.

XHTML specifications provide three types of lists ordered lists <ol>, unordered lists <ul> and definition lists <dl>. Ordered lists are meant for content that must be arranged in a specific order — things like instructions, or lines of code. Unordered lists are meant to be used for content that can reasonably be displayed in any order such as navigation menus or shopping lists. The rarely used definition lists is meant to be used where one list item is logically defined by a subsequent item (a definition term <dt> followed by a definition description <dd>) it functions the same way as a FAQ or glossary. However, when specifically used for comments, the only sure bet is that the unordered list is inappropriate — because comments require a specific order to make sense — while the ordered list and definition list vie for being the second worst.

If you have tried to use AJAX with WordPress, most likely you have stumbled upon the wp_die() function which completely kills the response you expect to get. However, we can trap the wp_die() by using PHP’s output buffering and the ob_start callback function to process the output of wp_die() even though a die() is called. This is a very special case, and will only work when you are able to ensure output buffering can be called before the die is called.

The easiest way to get a non-fatal wp_die() error (an error that shouldn’t cause the entire application to stop) is when submitting comments: non-fatal errors occur whenever someone posts too quickly or submits a duplicate comment, so this can be a problem when creating an AJAX app to submit comments (I ran into this problem with INAP.)

Since AJAX makes the entire submit process very quick, so it is easy to trigger the “Posting too quickly” error if the user make short comments, and when this happens an entire page –complete with CSS and headers– is returned as the AJAX response.

Aside from a brief flirtation with a couple payed projects, I’ve been heavily focusing on rewriting the code for INAP 3.0, and it has almost reached the point of a private beta (which means I start running it on this site.) I have selected the new name for INAP 3.0, but I’m not going to reveal it just yet. Here is a small preview of what you can expect from INAP 3.0:

INAP 3.0 is now truly modular with a main Javascript/PHP core that other features hook into to function. This core is easily extensible and the new structure of a main project with many smaller projects will make bugfixes and upgrades less painful, and will allow the user to upgrade the plugin section by section as most changes in the modules won’t effect the core.

For the users:

1. INAP 3.0 will make upgrades far less painful.