Go to your Admin Panel, then Appearance -> Editor -> Theme Functions. At the bottom of the file, add this code.

function modify_post_mime_types($post_mime_types) {
	$post_mime_types['application/pdf'] = array(
							__('PDFs'),
							__('Manage PDFs'),
							_n_noop('PDFs (%s)', 'PDFs (%s)')
							);

	$post_mime_types['application/zip'] = array(
							__('Zips'),
							__('Manage Zips'),
							_n_noop('Zips (%s)', 'Zips (%s)')
							);
	return $post_mime_types;
}

add_filter('post_mime_types', 'modify_post_mime_types');

This is what you get.

(Hattip to the WP support forums for the original code).

So, let’s break that code down. application/pdf and application/zip are the mime types of the files I wanted. You could, however, drop in any mime type that you use frequently. After that, you need to replace PDFs/ZIPs with whatever you want to use to denote that file type. For example, if you want a tab for documents.

$post_mime_types['application/doc'] = array(
						__('Docs'),
						__('Manage Docs'),
						_n_noop('Docs (%s)', 'Docs (%s)')
						);

WordPress will also allow a wild-card mime type search. In essence, that’s all the image/video/audio tabs are. The image tab matches image/*, for example. So, you can create a forth option that applies to “application” – unfortunately, pretty much everything that is not audio, video or image falls under that category. That option will result in a list that displays docs, PDFs, archives and anything else that matches application/*.

As always, this yields wonderful, fun things that make my life easier. WordPress has a constant that defines the site path, specifically for cookies. Ironically, this is named SITECOOKIEPATH.

Without more blabbering, here’s the code. Enjoy. =)

setcookie("your-cookie-name", 1, time()+3600, SITECOOKIEPATH);

I’m using this to see if an ad has already been displayed to a user in the recent past. If you’re planning something similar, here’s how it will work out.

if(!isset($_COOKIE['your-cookie-name'])) {
	// do some PHP stuff here
	setcookie("your-cookie-name", 1, time()+3600, SITECOOKIEPATH);
}

Here’s the PHP.net info on setting cookies, if you’re unfamiliar with the process or just enjoy reading technical documentation.

Without a doubt, the most common reason why your WordPress installation suddenly stopped working is…you tried to change the home page. Yes, that’s it. Although, you probably already knew that, since you’re reading this. Here’s what [probably] happened, here’s what should have happened, and here’s how you fix it.

You [probably] decided you wanted your blog to show up at some nifty, pretty URL. The straight-up URL wasn’t cutting it. You wanted /home or /start or /owmystomachlining.

1. You created a new Page – Ow My Stomach Lining
2. You went to the new page – http://myblog.com/owmystomachlining/ – and saw it working. w00t!
3. You went to Settings -> General and changed WordPress address (URL) to that URL up there. Booo.

Here’s what you should have done. Giving WordPress Its Own Directory. I will not reiterate what’s written, I will only say go there, read that and do it.

The problem you now have is that the WordPress Address is supposed to be reflective of the actual location of the files. Now when WP starts up, it’s looking for something where it doesn’t exist. Woops.

Here’s how you fix it.

1. Either you (or someone capable, should you not be) must open phpMyAdmin.
2. Have them to go the wp_options table.
3. Make sure the keys ‘home’ and ‘siteurl’ match the actual location of the WP files (usually, your URL)
4. Save, test, repeat if necessary.

Part 2 of ??? will come when I find more common ways of breaking WordPress.

wp_delete_post( POSTID, TRUE );
// TRUE|FALSE: Bypass trash. Defaults to FALSE.

wp_trash_post( POSTID );

In version 3, WordPress peeps let out a sigh of relief with the advent of custom post types. No longer would we need to use custom fields to denote a special type of post! Unfortunately, the old school method of removal, wp_delete_post, isn’t equipped to handle custom post types.

wp_delete_post('399', FALSE);

This example will immediately trash whatever 399 is linked to…assuming it’s a standard post or page. wp_delete_post makes a determination when it runs: if the ID doesn’t belong to a post or a page, then it’s removed. If it’s a custom post, tough cookies, it’s insta-deleted, totally bypassing the trash.

The workaround is to use the newer function, wp_trash_post. This just accepts a post ID, and doesn’t particularly care about what type of entry it is. It simply changes the status to trash. If you give it something not trash worthy, and your data disappears into the database ether, that’s your problem.

Upshot: Unless you want to immediately, permanently delete the data, use wp_trash_post.

But, it didn’t work. =(

Oh, it opened it in a lightbox. But the height and width parameters weren’t working. According to the documentation, to use an iFrame you simply append

?iframe=true&width=[theWidth]&height=[theHeight]

Seems straight forward, but it wasn’t working. I tried the obvious – should I add “px”? How about “pixel”? Change around width and height? Then I tried the support forum, saw several other people asking the same question and no reponse. (Get to the point, Becky.)

Go into admin->settings->WP-prettyPhoto and uncheck Allow the prettyPhoto box to be resizeable. Problem solved. Have a nice day. =)

Fortunately, a few minutes of spelunking in the settings resulted in the Media options. If you’re having the same problem, visit ->Settings->Media and unclick “Crop thumbnail to exact…” You can also control the default thumbnail size. I’m a bit amazed that the problem went on for so long before I found this (obvious!) solution.

Long story short, working with Ubuntu was a pain, especially when it came to local WordPress development. In the most recent versions of WordPress, they’ve implemented an extra security feature. If the user running Apache isn’t the same as the user that owns the directory, you need to enter FTP connection information. And even if you do enter information (assuming you have it) it won’t work.

Note that your files all need to be owned by the user under which your Apache server executes, or you will receive a dialog box asking for “connection information,” and you will find that no matter what you enter, it won’t work. [WordPress Codex]

What’s a Windows loving girl stuck in Linux hell to do? The first step is to nag her husband. The second step is to start screwing around with directory ownership until something works.

To turn off the godforsaken FTP connection information dialog, all you need to do is

1. Open Terminal. (Applications -> Accessories -> Terminal)
2. Navigate to the folder directly above your troublesome WordPress installation. (cd /var/www/some/other/directory)
3. Give Apache ownership of the directory. (sudo chown -R www-data.yourusername DirectoryName)
4. Enter your password.

Now, go back to your WordPress admin panel. Try running an automatic update on your installation or a plug-in, or install a new plug-in automatically. If all goes according to plan, you should see the beautiful successful installation screen.

The issues are almost always due to internal server configuration. Just like HTML and CSS, you should follow best practices in PHP to ensure compatibility on any server and save you – and your users – some trouble.

Use only Long Tags

<? echo(“Foo!”); ?>

For some reason, at some point in the past, someone decided short tags were a good idea. This is, without a doubt, the simplest fix of them all. In your php.ini file, there’s an option named short_open_tag. If you’re running a local server, you might have this option on and you might be able to get away with using it.

Most web hosts have the option off. The notes accompanying the option in php.ini tell you to keep it off.

For portable, redistributable code, be sure not to use short tags.

The fix is beautifully simple. Always open your PHP statements with <?php instead of <?. You’ll never have a problem with short tag compatibility.

Don’t Close PHP

While not as dramatic as the short tag fix, sometimes ending a PHP file with a closing ?> can cause header errors. Once you end the PHP block, everything else is considered output. If you’ve next document sends headers, then you’ll get beautiful, infuriating Headers already sent errors. By leaving the block open, you don’t need to worry about the possible white space disturbing the headers for the next function.

There are exceptions to this. In a WordPress theme, for example, you should always close PHP blocks. Since you can never be sure that the subsequent template start with PHP and not HTML, it’s best to close them all and meticulously remove lines afterward.

Be Selective with Your Echo Statements

There’s no graceful way to approach the issue of outputting HTML or JavaScript from a PHP function, especially if you need to echo PHP in the middle of the HTML (as in the WordPress Loop). You have three options

1. Temporarily exit PHP for straight HTML and echo PHP in the middle.
2. Echo HTML lines and denote PHP in the middle.
3. Echo giant chunks of HTML and denote PHP as needed.

You should [almost] never use the third option. It’s messy, error prone and, depending on the code, can cause apostrophe matching issues. I cry a little when I see this option used for a plug-in’s JavaScript. Bonus best practice: put JavaScript in its own file and include that.

To determine whether you should use the first or second option, consider the composition of the line(s). If you have more HTML than PHP and just need to echo a variable or three, you should opt for the first. However, if you have lots of PHP – functions, ternary operators, loops, etc. – you’re best off using the second.

Use Functions

When you’re making major overhauls to a WordPress (or any OS software) template, the temptation is to throw it in for easy access later. You wrote it, you know what it is, no problem, right?

Always assume that you won’t be the first, last and only person to ever touch the code. Maybe next week your brother-in-law’s cousin’s son will ask if you can start blogging with you. Or something breaks and you need to hire a coder to fix it. Or you get an offer for mad cash and sell it to retire in Zimbabwe.

If you add functionality that requires you to dedicate more than a single line to PHP,  you absolutely must a) put it in a function, b) put that function in the template functions file and c) give the function a really obvious name. And, of course, you really have to

Comment Your Code [obligatory reminder]

Way back when, while learning how to drive, my Dad used to joke that I should never let the other guy know what I was doing. If you’ve ever been rear-ended because you forgot to turn on your blinker, you’ll know what a really bad idea this is.

The single worst thing about working with someone else’s code is a complete lack of comments. I don’t look for dissertations on the value of their selected approach, but it would be nice if they’d let me know what they’re doing.

At bare minimum, you should comment each function. Let future developers know what the function does. If you use a relatively obscure native WordPress function, add a comment with its file name and line number, the Codex URL or a short blurb on what it is.

Sidesparks, a chat plugin, gives very helpful comments.

/*
* This will generate a Sidesparks Textlink with the specified link element
* it will either use get_the_tags() in case it returns an array, else the title
*/
function generateSidesparksLink($link, $print = true) {…

MyScorePresenter, a plugin for flash games, gives less helpful comments.

/*
* @brief Expand Score data
*/
function myscore_expand_template($template, $score_result, $score_name) {

See the difference? Sidesparks tells me exactly what the function does. MyScorePresenter gives me no context or instructions.  It actually doesn’t matter at this point which plugin has the “better” code. All that matters is that in one, I can figure out what a function does without reading the whole thing or wading through code.

There’s a bonus here for you: If you comment your code really well, you’re less likely to receive complaints such as “I installed it and my page turned white when I clicked x.” Instead, you might receive something like, “I kept getting a white page after clicking x, so I found the function that handles x in file y on line z and did some magic fix you can see in the new version that I attached.”

Do you find the lightbulb icon to be extremely awesome? I also did and was quite tickled to find it. You can download it – for free! – along with the rest of the Sienna icon pack from Web Designer Depot.

Hacky? Possibly. WordPress can still load RSS feeds without a hitch.

Ah, the mighty RSS feed. Straight from your blog to your subscribers’ readers. There are plenty of plugins for RSS feeds, like FeedWordPress, and WordPress also has a built in RSS widget that can display all sorts of goodies from blogroll feeds.

Maybe you, like me, want to add a page dedicated to an RSS feed. While you could definitely do this with any number of plugins, it’s easier to take advantage of a few native functions. Before you start, familiarize yourself with WordPress’ custom pages.

In another post, I’ll go over using your Blogroll or another link category for the feed. Now, I’ll just cover taking the URL for an RSS feed and generating a list of posts.

$url = “http://notrelated.com/feed”;
$start = 0; // post to start with
$end = 10; // post to end with
$rss = fetch_feed($url); // get the feed
foreach($rss->get_items($start, $end) AS $item) {
$title = $item->get_title(); // post title
$date = $item->get_date(“d.m.Y”); // post date, reference date() for proper inputs
$content = $item->get_content(); // post content
$author = $item->get_author()->get_name(); // post author
// now display is all in HTML
}

The retrieved feed can be displayed just like WordPress posts by using your Loop HTML. To see this in action, visit the demo page. You can also grab the page for your tweaking pleasure.

strtotime() needs a phrase or string to convert into a UNIX timestamp. Usually, you’ll input something like -7 days, +20 days or 02 May 2010. When you put in a string for a date, be aware that it must be in day-month-year format.

Easy example: you want to display yesterday’s date.

$yesterday = strtotime("-1 day");
echo("Yesterday was ".date("F d, Y", $yesterday));
// Yesterday was February 28, 2010

How about something harder? Let’s say you have a blog and want to have a page just for the posts from the last seven days. You’ll need to format your dates a bit for WordPress to understand the request, using the date() function, but it’s easy enough.

$lastWeek = date("Y-m-d", strtotime("-7 days"));
$today = date("Y-m-d");

This section sets the time boundaries. We want the (WordPress formatted) date for 7 days ago and the (WordPress formatted) date for today. The WordPress database formats dates as YYYY-MM-DD hh:mm:ss. Since we aren’t concerned about the hours, minutes or seconds, we’ll just format it for the earliest time one week ago, or 2010-02-21.

Now that we have the date, we can use the custom select query to select only the posts that fall in that date range. The WordPress Codex has a good primer on how to display posts using a custom select statement. I’m basing the below query on that.

$querystr = "SELECT wposts.*
		FROM $wpdb->posts wposts, $wpdb->postmeta wpostmeta
		WHERE wposts.ID = wpostmeta.post_id
		AND wposts.post_date >= '$lastWeek'
		AND wposts.post_date <= '$today'
		AND wposts.post_type = 'post'
		ORDER BY wposts.post_date DESC;";
$posts = $wpdb->get_results($querystr, OBJECT);

In the query, we’re telling WordPress to select the post and post meta data from the appropriate tables, to make sure the IDs of the entries match, and to limit the search based on date and post_type. wposts.post_date is the limiter for date. WordPress will look for any post that occurred between 7 days ago and today.

Now that we have the data, we can pass it into The Loop, which is the WordPressy way to say we’re going to display the posts.

get_header(); ?>

<div id=”content” role=”main”>

<?php

if($posts) {

foreach($posts AS $post) {

setup_postdata($post);

?>

Your template’s HTML goes here

Your template came with the Loop by default, in the form of if (have_posts()) : while (have_posts()) : the_post();. You’ll need to remove these lines. In the end, your front page should look similar to those, using the default Kubrick theme.

<?php

/**

* @package WordPress

* @subpackage Default_Theme

*/

$lastWeek = strtotime(“-7 day”);

$lastweek = date(“Y-m-d”, $lastWeek);

$today = date(“Y-m-d”);

$querystr = ”

SELECT wposts.*

FROM $wpdb->posts wposts, $wpdb->postmeta wpostmeta

WHERE wposts.ID = wpostmeta.post_id

AND wposts.post_date > ‘$lastWeek’

AND wposts.post_date < ‘$today’

ORDER BY wposts.post_date DESC

“;

$posts = $wpdb->get_results($querystr, OBJECT);

get_header(); ?>

<div id=”content” role=”main”>

<?php

if($posts) {

foreach($posts AS $post) {

setup_postdata($post);

?>

<div <?php post_class() ?> id=”post-<?php the_ID(); ?>”>

<h2><a href=”<?php the_permalink() ?>” rel=”bookmark” title=”Permanent Link to <?php the_title_attribute(); ?>”><?php the_title(); ?></a></h2>

<small><?php the_time(‘F jS, Y’) ?> by <?php the_author() ?></small>

<div>

<?php the_content(‘Read the rest of this entry &raquo;’); ?>

</div>

<p><?php the_tags(‘Tags: ‘, ‘, ‘, ‘<br />’); ?> Posted in <?php the_category(‘, ‘) ?> | <?php edit_post_link(‘Edit’, ”, ‘ | ‘); ?>  <?php comments_popup_link(‘No Comments &#187;’, ’1 Comment &#187;’, ‘% Comments &#187;’); ?></p>

</div>

<?php } ?>

<div>

<div><?php next_posts_link(‘&laquo; Older Entries’) ?></div>

<div><?php previous_posts_link(‘Newer Entries &raquo;’) ?></div>

</div>

<?php } else { ?>

<h2>Not Found</h2>

<p>Sorry, but you are looking for something that isn’t here.</p>

<?php get_search_form(); ?>

<?php } ?>

</div>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

If you have any questions on or improvements for this code, let me know. And, as always, enjoy!