The good news is: it’s almost always just a simple myIsam crash – easy to fix, and no data loss. After going through this a number of times with various members, I decided I really ought to put together a quick tutorial on how to fix it.

Symptoms

First – how do you know this is the issue you’re seeing? The most obvious symptom is this: Your posts have just disappeared. The homepage of your blog is giving a 404 (but a pretty one, with your theme), or just telling you it can’t find any posts. You log into your dashboard, and much to your dismay, the edit posts screen is showing not ONE single post. It’s terrifying, because it’s at exactly this moment that you realize you never installed that backup plugin (or more likely, you started to, but never finished, because it got tricky). Much cursing later, you’ve resigned to the fact that all is lost.

Diagnosis

Of course, it’s likely that all is not lost – lets look at how to make sure.

To get this done, you’re going to need to get direct access to your database somehow. There are a number of ways you can do this, ranging from the super nerdy (command line/ssh access), to the moderately nerdy (MySQL gui client like Sequel Pro), to the entirely accessible – the web based interface of phpMyAdmin. I havent run across a host in recent times that doesnt give you access to phpMyAdmin in some form, so that’s what we’ll use here.

First, you’ll need to get into phpMyAdmin. I can’t give you much help there, because it’s a different process with every host. If you’re having trouble, get to your control panel, and just start searching for things – start with “phpMyAdmin”, but if you can’t find that, move on to “MySQL”, “Database” – things of that nature. You’re bound to get on the right track soon enough.
Once you’ve got phpMyAdmin opened up, you’ll end up at a screen that looks vaguely like this:

Find your database

On this main page, you’ve got a list of databases off to the left, and lots of information and settings you don’t need to worry about in the center. You need to choose the database that is running the WordPress install in question off on that left column, and click to open it up. (If you’ve got a number of WordPress installs on one server, this could be a bit tricky. Check out the settings in your wp-config.php file if random guessing doesn’t do the trick).

Now that you’ve chosen your database, you’ll see the list on the left has changed – now you’re looking at tables inside the chosen database instead of databases. Click on the wp_posts table to open it (note – it’s possible that this is something other than wp_posts, especially if you’ve got multiple installs in one database. The table you want will definitely end in “posts”, and whatever comes before that can be found in your wp-config.php file – look for “$table_prefix = “). Clicking on the posts table will either pull up a page describing the contents of the table, or an error message, that looks something like this:

Surprisingly, this is good news. Your precious posts are just one command away.

Repairing the table

Finally, the juicy bits. To repair the table, we’re going to need to run an SQL command on the database – and to do that, we’ll click the “SQL” tab near the top of the page. Doing so should bring up a page with a box that looks something like this:
As shown in the screenshot, you need to enter this:

repair table wp_posts;

In case you hadn’t guessed – if your table didnt start with wp_, you need to adjust that command accordingly.

Double check that you’ve typed the command in properly, and hit “Go” (bottom right of the input box). If all went well, a moment of loading later, you should be presented with this screen:

And with that, you’re back in business. Check your site, and your posts should be back. In some cases, the wp_posts table isnt the only one that goes down, so as long as you’re in phpMyAdmin, you might double check to see if any of your other tables need some TLC from your newfound database administration skills.

On the off chance that none of this worked, the table wasn’t crashed, or repairing it didn’t fix the problem, there’s a fair chance you’re in serious trouble. For problems with that, or any questions along the way, get in touch here, or drop me an email.

Good luck!

Update – All this post disappearing have you hankering for some backup help? Have a look at this post about How to back up your WordPress blog

$tags = get_the_tags($post_id);

This will return an associative array of tags, with all their relevant info.

BONUS
If you need the same thing with categories, here’s your function:

    $args['fields'] = 'all';
    $categories = wp_get_post_categories($post_id, $args);

Including the args bit allows you to retrieve all the category info. If you leave that out (and use only the $post_id argument), you’ll get an array of relevant category ids, but no other info.

Big thanks to Clay Lua at hungred.com and his post Get Tag with Post ID in Wordpress for pointing me in the right direction.

That said, I’m currently working on a project that requires quite a bit of javascript work – specifically involving some animations – slideUp and slideDown stuff mostly.  I put it all together, and it worked beautifully in Firefox and Safari on my mac – smooth animations, perfect transitions.  As though I knew what I was doing.  I fire it up in IE7 just to be sure, and it’s a nightmare.  You can’t really call it “animation”.  Slow, choppy, and unpredictable – legitimately unusable.

A bit of googling around revealed that apparently no one else in the world has this problem, and I am an idiot.  Then I happened upon a gem at stackoverflow.com which mentioned, in passing, that Internet Explorer does an awful job of caching and displaying background images (specifically repeated background images) during animation – basically, he implied that for each frame of animation, I.E. loads, places, and renders each instance of a repeating background image, just one example of how a browser could have issues with animations. The specific elements I’m working with are 1000 px wide rows, and with each animation, about 10 of them have to move 300 pixels or so.  The kicker?  Each one is using a 1px wide repeating background.  1000 background images * 10 rows, and it becomes apparent why the animation was so bad.  I bit the bullet and tried a single 1000px wide background image, and the difference was night and day.

The moral of the story is this: the css techniques you use on elements that will be animated can have a serious affect on animation performance.  If you’re having problems, give some real thought to what the browser will have to do to animate the elements – calculating heights, margins, widths, background images, etc etc.  Experiment with different values, with an eye toward explicitly defining any value that the javascript might have to calculate (i.e. define heights instead of just letting the browser do it), and you can probably make a big difference in your javascript animation quality.

However, if you try just echoing $post->post_content, you’ll get completely unformatted text – which is frustrating, because WordPress uses a great visual text editor on the backend – it’s a shame to not take advantage of it.  Fortunately, WordPress provides a filter to display the text just as it would be displayed in the the_content() function inside the loop.  Here’s how it works:

To get the content formatted properly, we need to apply a filter (which is different from adding a filter – here, we’re registering it so that other filter functions can modify it before it’s displayed).

apply_filters('the_content', $post->post_content);

So, we’re just applying the the_content filter to the $post->post_content variable.  Doing so means that any plugin which adds a filter function to the_content like this:

add_filter('the_content', 'my_content_manipulator');

function my_content_manipulator($content){

//do stuff here

return $content;

}

will be applied to your variable.  Fortunately, it also means that the WordPress core functions which format the post content correctly can also work on it.

get_admin_page_title()

So, if you only want to run a bit of code on the “Edit Posts” page, you’d put together a conditional statement like this:

if(get_admin_page_title() == 'Edit Posts'){
//do something fancy
}

Sometimes, it makes sense to give the user access to a post meta field – for example, if they need to add a thumbnail url to a post, they’re probably going to need to access to those post meta fields.  Other times, having the post meta field visible is only likely to confuse the visitor.  One (extremely popular) place that I’ve seen this is the All in One SEO Plugin.  All in One SEO is wildly popular, and does what it claims well.  It provides a few extra fields, and a nice, easy to use interface to get at them.  Here’s what it looks like when you get started:

Fantastic.  It’s attractive, easy to use, and works well.  So we save our post, and then later on, we go back to edit the meta description.  Here’s what we get:

At this point, its pretty clear what’s going on if you understand the inner workings of WordPress – AIOSEO has saved our values to custom fields, so now they’re showing up there.  However, most users dont understand, or even care about how AIOSEO works, or what custom fields are.  All they know is that strange stuff is showing up, and they’re not sure where to edit their meta keywords, because they’re showing up in 2 places.  Most people have the gumption to just change one and see what happens – but there will always be users who get scared and decide they want to email you about the issue, or worse, just uninstall the plugin and move on.

Underscores to the Rescue

The WordPress developers, fortunately, thought of this.  In fact, they store all kinds of stuff that they don’t want the user to see in custom fields – things like the last time the post was edited, who is currently editing it, and a few others.  A quick look at the database, reveals this:Notice a trend?  The mysterious custom field key values are prepended with an underscore.  Give it a try – enter a new custom field from the edit-post page, and enter a name that starts with an underscore – like _thumbnail, or _meta_keywords.  Hit “Add Custom Field”, and it disappears – but if you check the database, its right where it should be.

Now get out there and start hiding things from your users!

In it’s simplest form, you can point your Wordpress user table at that of another blog on your server. Doing so means both blogs (and why stop at 2?) share user information: passwords, usernames, author bios, etc etc. If you’ve got a site that requires numerous different, separate WordPress installs (think something along the lines of wired.com), but the same authors often write on many or all of them, this is a great, and easy solution.

Enough Already, Give Me the Code

Yes Sir.  Just slap this code in your wp-config file:

define('CUSTOM_USER_TABLE','new_user_table');
define('CUSTOM_USER_META_TABLE', 'new_usermeta_table');

It’s pretty self explanatory from there – just define a custom user table, and a custom usermeta table, and you’re good to go.  Want your users to share login info across different blogs, but be able to have a different bio for each one?  Define a custom user table, but leave the default user_meta table.  Everything stored in the users table (ID, login, password, nicename, email, url, and display name, among other things) will stay the same across all blogs.  Everything else (nickname, user level, First Name, Last Name, and many other things), will be blog specific.

$wp_filter()

As far as I can tell, this holds every currently registered function/filter combination, and all the relevant information.  I can’t quite figure out exactly what determines which filters this grabs – I’ve tried calling it from a few places, and the results are slightly different, but I can’t seem to find a pattern. I initially assumed that you wouldnt be able to see about admin side hooks from the front end, but this isn’t the case. At any rate, you get lots of information from anywhere. Not getting the info you want? Call it from somewhere else! This is a great debugging tool if you’re having trouble with plugin incompatibility – it gives you a list of the filters and actions being called,the matching functions that are working on them, the priority specified for each hook call, the accepted args, and even the order in which same-priority-level hooks are called.  An example:

    [the_title] => Array
        (
            [10] => Array
                (
                    [wptexturize] => Array
                        (
                            [function] => wptexturize
                            [accepted_args] => 1
                        )

                    [convert_chars] => Array
                        (
                            [function] => convert_chars
                            [accepted_args] => 1
                        )

                    [trim] => Array
                        (
                            [function] => trim
                            [accepted_args] => 1
                        )

                )

        )

This is a small snippet I pulled after displaying the contents of this variable in the footer of a theme.  As you can see, the referenced hook is a filter, specifically “the_title”.  It has 3 functions attached to it: wptexturize, convert_chars, and trim.  Each one is at priority level 10 (which is the default), but they are called in the order listed.   Each accepts 1 argument.

Try it Out

If you want to have a look yourself, display the contents of wp_filter with this code snippet:

<?php
global $wp_filter;
print_r($wp_filter);
?>

This is going to dump the contents right to the screen, so you don’t want to do it on a live blog. As with any use of the print_r() function, the results will be formatted nicely in the source code – but not in the rendered html.

Roundup:
Top wordpress plugins
wordpress magazine theme

It’s not the most elegant piece of code in the world, but it works on all the installs I’ve tried it on.  I’ll try to put up a post detailing how it works soon, but in the meantime, feel free to download the plugin and give it a try.

Default Post Content Plugin

More Wordpress Magic

What was happening is referenced here (Right in the codex – apparently the last place I thought to look). My first instinct has always been to post forms on an admin page to itself, then handle checking for the $_POST values, and creating/updating the appropriate options. As is often the case, WordPress makes it even easier than that:

Set Up Your Form Properly

I wont get into the boring details – you can look at the codex page for that – but pay special attention to the hidden fields you set up:

<input name="action" type="hidden" value="update" />
<input name="page_options" type="hidden" value="new_option_name,some_other_option,option_etc" />

Not too tough to understand – the first line tells the system that we’re going to be updating, and the second line lets WordPress know which fields we want to create/update.  These, of course, need to match the “name” attribute of the input elements up above.

But What About Arrays?

I posted a few days ago about the very cool functionality of maybe_serialize(), and its relation to WordPress options.  I often store arrays in options, because they help keep the database free of unnecessary clutter, and they make your plugin even easier to use (from a developers view).  I was a little worried that this “page options” trick would prevent me from saving arrays – but alas, WordPress saved the day again:

<input type="text" name="fruit_colors['apple']" value="red">
<input type="text" name="fruit_colors['carrot']" value="orange">
<input type="text" name="fruit_colors['banana']" value="yellow">

Just make a form field an array, like you would with a set of checkboxes (by adding [] after it).  Pass in the proper values to the page_option hidden field, like so:

<input name="page_options" type="hidden" value="fruit_colors" />

This can get pretty interesting – a few days ago I used to to loop through categories and associate a string with each one – you can do the same for posts, days of the week, whatever suits your plugin.

So there you go.  You’ve got yourself an option without any tinkering with $_POST variables, or checking if you need to update or create an option.  Wordpress even takes care of serializing it for you.  What a world…