The What What?

Post Object. WordPress stores all post data (think content, author, tags, etc) in a single object, accessible to themes and plugins on each page load. Basically, this is the place you’re going to go to if you want to get some extra information about a post for whatever clever scheme you’ve got cooked up. Need to know how many “n”s are in this particular post? Talk to the post object. Not sure when this post was originally published? Post object. Looking for lawyers who ride? Now we’re talking – but you want the Law Tigers, not the $post object. Watch their commercials. You won’t regret it.

How do I get at this mystical post object?

Single Posts

The post object is available nearly everywhere you’re likely to be looking at a post. If you’re working with a single post page, or an actual page, you’ve got access to that post’s (or page’s) post object anywhere within your theme file. It’s all held in a variable named $post.

Multiple Posts

If you’re on a page with multiple posts, things are a little trickier but not much. If you’re inside the loop, you’ve got access to a $post object (named $post) referring to the current post in the loop.

Elsewhere

What if you want to get at a post that isn’t the one you’re looking at on a particular page – or what if you want to get at one from a plugin, or somewhere where there isn’t a current post explicitly defined? There’s a function for that:

$id = 41;
$mypost = get_post($id);
print_r($mypost);

get_post() to the rescue! There are, however, a couple of gotchas with get_post.

1. You have to pass it a variable – not an integer. See how in the example above, I set $id to 41, an then used $id as the argument to get_post(), instead of just saying get_post(41)? That’s important. If you try to pass an integer to get_post(), it will blow up. No Joke.
2. You probably shouldnt use the variable $post. Why not? Because WordPress uses $post all the time, and chances are you’ll either overwrite WordPress’ version of $post, or they’ll overwrite yours – either way, somebody is going to be mad. Choose something more clever than $post (like $mypost!). I know you can do it.

What if I don’t like getting the data back as an object? I’m an associative array kind of guy.

get_post() gets you. So do I. There’s a second, optional argument to get_post that determines what it spits out at you. It defaults to OBJECT, but you can also pass in ARRAY_A, or ARRAY_N to get an associative array or a numeric array version of the post data.

Ok, I’ve got a post object – what kind of data is in there?

Find out for yourself! The snippet above uses the function print_r() – it will show you the structure AND data of a particular post object – very useful stuff. Surround it in a <pre> tag, and you’ll be in even better shape – it will display nicely in your browser.

I’m too lazy for that. Didn’t I come here for you to teach me about this?

Well played. Here’s a quick rundown on the data the post object gives you:

Whew!

I think that about covers it. One last question you might have:
How do I get WordPress to spit out properly formatted post content?

Good luck!

Over the past few weeks, I’ve been absolutely inundated with requests to clean up hacks that have exploited the much publicized Timthumb.php vulnerability. I have to assume that the reason most people aren’t plugging up this security hole on their sites is either

1. They don’t feel confident in their ability to find the problem
2. They feel like the process to fix it is too complicated

To combat this, I took a couple of hours this morning to write a plugin that will do the dirty work for you. The WordPress Timthumb Vulnerability Scanner will check your entire wp-content directory (including all themes, plugins, and uploads) for any vulnerable (pre-2.0) instances of the timthumb script, and give you a one-click upgrade to upgrade each script to the latest, secure version.

The process is simple:

1. Download the plugin here:
   http://wordpress.org/extend/plugins/timthumb-vulnerability-scanner/
2. Install and activate using either FTP, or the built in WordPress uploader
3. Go to the “Timthumb Scanner” page, under the “Tools” menu
4. 
   Click the “Scan” button.

5. View your scan results
   
   In this case, I’ve got one vulnerable (outdated) file, and 2 that have been updated, and are safe. I’m going to want to upgrade that one vulnerable file – to do that, I just need to hit the “Fix” button next to it.
   You may not have any instances of timthumb on your site, or all of yours may be upgraded – if so, you’re all done!
6. After hitting “Fix” for my one problem file, I’m showing “No Vulnerabilities Found”, which means I’m all set.

Just like that, you’re done. Quick and painless.

Note: If you’ve already been hacked, this will NOT clean up your site. This plugin fixes your door lock – which doesn’t matter if the burglars are already in your house.

Let me know of any problems or questions you have in the comments.

Good luck!

EDIT
Looking for a solution to scan a whole server, or a site not running on WordPress? By sort-of-popular demand, here it is:
http://codegarage.com/plugins/timthumb-full-server-vulnerability-scanner.zip
It’s much less polished, and much less tested, so use at your own risk.

Yesterday we talked about how to access your WordPress site via FTP – today, we’ll talk about something more important: Upgrading or reinstalling WordPress using FTP instead of the WordPress backend.

Why?

Again – this all comes down to saving your own butt. If an automatic upgrade fails in the middle, you’re in trouble – chances are that some, but not all of the files necessary have been reinstalled/updated. Because of this, the Dashboard is often left inaccessible, and you have to fall back on your old friend FTP.

Other reasons you might do this:

1. You got hacked, and you want to make sure your core WP files are clean.
2. You started tinkering with Core WordPress files, and now the site doesn’t work
3. You uploaded a shady plugin which modified core WordPress files, and now the site doesn’t work

Public Service Announcement

Back up your site before you do this. Please. If you mess it up, and lose all your uploads, you’re going to be really mad, maybe at me. Don’t have a backup service? Good news – I have one that I can shamelessly plug. Check it out at the front page.

Lets get to it. Since we already understand how to access WordPress via FTP, we can get started without fear.

Step 1: Download WordPress

WordPress.org has a handy feature: the latest version of WordPress is always available at:

http://wordpress.org/latest.zip

If you ever need a copy, just enter that address in the url, and it will start downloading. The more traditional page for finding your download is here:

http://wordpress.org/download/

Need an old version of WordPress? They’re nice enough to keep those around too:

http://wordpress.org/download/release-archive/

So you’ve downloaded the version of WordPress you need. Good work!

Step 2: Unzip it

Next, you need to extract the zip you downloaded. Hopefully this isn’t too tricky – as long as you know where your downloads end up. In most cases, it’s as simple as finding the zip file and double clicking it. You should end up with a folder titled “WordPress”, which has the entirety of a WordPress install inside of it.

Step 3: Upload it

All that’s left is to upload. Now – you need to take some special consideration before you just go uploading all these files. Make sure you’re:

• Uploading the right things
• To the right place
Simple, right? Here’s what we need to do: We want to upload the contents of the WordPress folder (which we just extracted) to the directory on our web server where wordpress is installed, with one important caveat:

We don’t want to overwrite wp-content

That deserved to be bolded. The wp-content folder holds your themes, plugins, and uploads – and we don’t want to overwrite it with the default wordpress content. So, we’re going to upload everything except that.




Upload Everything BUT wp-content


Now that we’re ready to upload, we’ll just click and drag that mess into filezilla – making sure that in filezilla, we’re looking at the current wordpress install (you should be looking at the inside of a directory that has wp-load.php in it).

When it asks if you’d like to overwrite files, go ahead and check “Overwite”, as well as “Always use this action” and click “Ok”. Before clicking “Ok” would be a good time to double check that you’ve backed up, adn you’re not overwriting wp-content.

Now, this is going to take a while – WordPress has a lot of files. Go eat a sandwich, it will be done when you get back.

All done. Now what?

Now head back over to your site and get a feel for your handiwork. If you were just trying to fix a problem, ideally at this point your site is working again. If the upload went ok, and your site still isn’t working, the problem lies somewhere else – check your plugins and themes if you haven’t already.

If you were doing this to upgrade your WordPress install, you’ve got one more step. Head over to yoursite.com/wp-admin, and you should be presented with a screen saying you need to upgrade your database. Go ahead and approve that, give it a minute to think, and you should be redirected to the login page – and you’re done!

]]> http://codegarage.com/blog/2011/08/upgrading-or-uploading-wordpress-via-ftp/feed/ 0 http://codegarage.com/blog/2011/08/wordpress-ftp-access-not-as-scary-as-it-sounds/ http://codegarage.com/blog/2011/08/wordpress-ftp-access-not-as-scary-as-it-sounds/#comments Tue, 16 Aug 2011 23:27:03 +0000 Peter http://codegarage.com/blog/?p=324

What is FTP?

FTP is short for File Transfer Protocol. Pretty self explanatory – you have files on your computer, you want them on your website, so you transfer them. FTP facilitates this.

When and Why do I need to use it?

Like I said, WordPress continues it’s relentless path toward becoming completely free of scary acronyms like FTP, but there are still times when you need it – mostly when things go wrong:

• Your WordPress site broke during an upgrade, now you can’t get in.
• You’ve got a broken plugin that has made your site inaccessible
• You were tinkering with your theme, and now you’ve got a big error message on every page of your site – or worse, just a scary blank screen
• You keep getting errors and notices about “Permissions” issues

Ok, so Maybe I Need It. Now what?

Step 1: Get an FTP client.
“FTP Client” is just nerdy talk for “Program you use to upload your files to your website”. There are as many FTP clients as there are fish in the sea, but I’m just going to tell you to use FileZilla, because it’s free, and easy to use. Download and install it, and get back here.

Step 2: Figure out your FTP credentials.
More nerd speak – you just need the login and password (and maybe ftp url) your host gave you for FTP access. This information is often in your “Welcome to your new hosting account” email.

Step 3: Connect!
Alright – fire up your FTP Client (See? You’re talking like a real nerd! Drop that one on your boss. He’ll give you a raise and a new job title.) In filezilla, we’re just going to use the “QuickConnect” bar –
Host: This is usually your site’s url (like codegarage.com), but sometimes it’s something different. If it’s different, they’d have told you in the same place you found your username and password. You did find your username and password already, right?
Username: Your username. Take note: you might have to include the domain name afterward, like an email address (like peter@codegarage.com).
Password: Your Password.

Next stop, the “Quickconnect” button. Go ahead, click it. You’re not in a position to break anything. Yet.

You’re In!

Hopefully. If not, you’ve probably got one of those fields wrong – host, username, or password. Do some tinkering.
If you got in, you’ll see the window on the bottom right corner of the screen fill up with some folders (or maybe just a few). These are the files on your server! Go ahead, do some exploring. When you’re ready to upload a file (send it from your computer to the website), just drag it on into that window on the right, and it will get sent to the website.

That’s it! Good work!

]]> http://codegarage.com/blog/2011/08/wordpress-ftp-access-not-as-scary-as-it-sounds/feed/ 4 http://codegarage.com/blog/2011/08/how-to-change-your-wordpress-table-prefix/ http://codegarage.com/blog/2011/08/how-to-change-your-wordpress-table-prefix/#comments Wed, 03 Aug 2011 17:30:12 +0000 Peter http://codegarage.com/blog/?p=311 Lately, WordPress users seem to have had an increased interest in security – and with good reasons. Yesterday’s timthumb.php vulnerability, plus a slew of others in the past few months have really put most site owners on edge.

Often it’s recommended that as a WordPress site owner, you change your WordPress database table prefix to something other than wp_. It’s not a bad idea – in certain situations, doing so might prevent a hacker from gaining more access to your site, or limit his destructive capability, and it’s a very easy thing to change.

If You’re Installing WordPress

If you’re installing WordPress, and you havent run through the install process, changing your table prefix is incredibly simple. During the install process, just set the Table Prefix to anything you’d like:


If You’ve Already Installed WordPress

If you’ve already installed WordPress, you can still change your table prefix, but it’s a little more complicated. You’re going to need to have access to your database through PHPMyAdmin or a similar system.

1. First, open your wp-config.php file (You’ll need to download this via FTP, or get at it from your host’s file manager). This file is usually located in the web root of your site.
2. Now, scan down until you see a line that starts with ‘$table_prefix’. It will look something like this:

   /**
    * WordPress Database Table prefix.
    *
    * You can have multiple installations in one database if you give each a unique
    * prefix. Only numbers, letters, and underscores please!
    */
   $table_prefix  = 'wp_';
   

   Change the value between the quotes (after the = sign) to whatever you’d like:

   /**
    * WordPress Database Table prefix.
    *
    * You can have multiple installations in one database if you give each a unique
    * prefix. Only numbers, letters, and underscores please!
    */
   $table_prefix  = 'mysecretprefix_';
   

3. Upload the file to your site, replacing the old wp-config.php file (If you made these changes from the built in file editor for your host – like cPanel, you just need to click the “save” button).

   At this point, your site will totally stop working. Yikes! Fortunately, we can fix that by changing some things in the database (Remember how you were supposed to make sure you had database access before we started? If you don’t, change wp_config.php back to the way it was, quick!).

4. Fire up PHPMyAdmin (or the MySQL client of your choice), and connect to the database for this WordPress install.
5. Run through each table starting with wp, and rename it, as follows:
   1. Click on the table name in the left sidebar
   2. Click on the “Operations” tab
   3. Change “wp_” to “mysecretprefix_” in the upper right field
   4. Repeat for each table

   At this point, your site should be working properly again, with one important caveat: You get a permissions error when you try to log in. That leads us to our last set of steps:

   Choose the mysecretprefix_usermeta table, and look for a row with a user_id of 1 (or whatever your user’s id is – it’s probably 1), and a “meta_key” value of “wp_capabilities”. Once you’ve found this. Click the pencil toward the left (edit)

   5. Replace the wp_ in the meta_key row to “mysecretprefix_”
      
   6. You need to make this same change to 2 more records – wp_user_level (located in wp_usermeta – again, make sure you’re changing it for the right user), and wp_user_roles, which is in the mysecretprefix_options table. Both of them should have wp_ replaced with mysecretprefix_.
   7. All done!

   If You’re Installing WordPress, and You’re Not Interested in all that Hassle:

   This one probably should have gone first: The plugin WP Security Scan from WebsiteDefender will do all the dirty work for you in most cases. Just go to the “Database” page, and switch your prefix.
   

   ]]> http://codegarage.com/blog/2011/08/how-to-change-your-wordpress-table-prefix/feed/ 3 http://codegarage.com/blog/2011/03/customizing-wordpress-an-introduction/ http://codegarage.com/blog/2011/03/customizing-wordpress-an-introduction/#comments Mon, 07 Mar 2011 16:00:42 +0000 Peter http://yourcodegarage.com/blog/?p=274 WordPress is an amazingly flexible, powerful content management system – it can do a lot of things for a lot of different people, and can can be contorted to match the requirements of impossibly different businesses. All for free.

   Right, but I just want to change my header

   Of course. Lets talk about how you can go about making small customizations to your WordPress based site. There are routes to take for people of all ability levels – so don’t be afraid if you’re still not exactly sure what “hosting” means.

   I’m going to give 2 paths here, one for people who don’t know html and css from arugula, and one for those who do, even if it’s just barely.

   The easy way out: Choosing a flexible theme

   Over the past 12-18 months, the WordPress community has exploded with a new class of themes – heavily customizable and easy to use, even for those with little or no html and css ability. I’m going to talk about 3 themes here – 2 paid, and one free. Feel free to chime in in the comments with your personal favorite.

   Headway

   Headway is my favorite. It’s not free, in fact, it’s not even cheap – but in my opinion, their visual editor is really fantastic – and just what a beginning WordPress user needs to get them up and running with a great looking, customized theme. Click here to visit Headway.

   Thesis

   Thesis has been around since the beginning of paid themes. It’s hugely popular and has a rabid following. It’s not my favorite for a number of reasons, but how wrong can 35,000 people be? Click here to visit Thesis

   Atahualpa

   Atahualpa is another tricky one. It’s very popular, and refreshingly, it’s free! However, there is a pretty steep learning curve that comes along with it. If you’ve got the patience to power through the learning stage, you’ll no doubt be very excited with the end product. Click here to visit the Atahualpa homepage

   The Road Less Travelled – Modifying theme code yourself

   The other option is a little less glamourous, and a lot more migraine inducing, but the possibilities are limitless. WordPress works on a templating system that is both easy to use, and robust enough to let you do anything you want it to. The kicker is: you need to learn how HTML, CSS, and even a little bit of PHP if you’re going to make this work. You don’t exactly need to be an expert in any of them to make small changes to an existing theme though. Here’s the quick overview, and some links to get you pointed in the right direction:

   WordPress Theme Files

   Nearly every WordPress theme consists of the same basic set of files, listed here:

   • index.php Index.php is your theme’s go-to guy. Traditionally, it controls the homepage (although if your theme has a file called “home.php”, that’s what will control your homepage). When all else fails, index.php is the file that WordPress looks to to generate your page.
   • header.php This one isn’t too tough. Header.php controls – wait for it – your header. In most themes, every single page on your site will share a header – so if you’re looking to add an image into your header, this is a good place to start your search.
   • footer.php Another no brainer. Looking for that hard to find copyright text? Start checking here.
   • sidebar.php More easy stuff – here’s where your sidebar code traditionally goes.
   • single.php This file is in charge of single post pages – like the one you’re looking at right now.
   • page.php This file is in charge of “Page” pages.
   • archive.php This file controls the layout of your archive pages – for example, the pages displayed when you click the “March 2011″ link on this blog, or one of the category links in the sidebar. A warning – categories are sometimes controlled by another file (category.php).
   • style.css Here’s where things get interesting. The style.css file is usually the single source of all CSS (which controls the actual look and feel of your blog – things like colors, layout, fonts, etc) on your theme. Get comfortable with this file, and the CSS that it uses.

   That is, unfortunately, not even close to a complete list. Fortunately, there’s a handy diagram at this page on wordpress.org.

   Now, you at least know where to start looking – all that’s left is to figure out what to do once you get there. Here are a couple of great tutorials to get you on your way:
   HTML Tutorial
   CSS Tutorial ]]> http://codegarage.com/blog/2011/03/customizing-wordpress-an-introduction/feed/ 0 http://codegarage.com/blog/2011/03/wordpress-api-key-what-is-it-and-why-does-it-matter/ http://codegarage.com/blog/2011/03/wordpress-api-key-what-is-it-and-why-does-it-matter/#comments Sun, 06 Mar 2011 21:24:22 +0000 Peter http://yourcodegarage.com/blog/?p=276 EDIT: The process has changed! You now get your api key straight from akismet. You’re going to have to withstand some awfully guilt inducing text to get it free. Consider yourself warned.

   When I was first starting with WordPress, there were a number of things that confused me. The distinction betwen wordpress.COM and wordpress.ORG is not immediately clear, and even if it was, it’s difficult for a beginner to wrap their minds around what the difference actually means to them. I don’t want to derail on this post and talk about that too much, so here’s what you need to know:

   • wordpress.COM is a completely hosted, managed, easy to use blogging system. Users of WordPress.com don’t need to worry about hosting, databases, installation, or any other jargon. Think of it like blogspot.com, but using WordPress instead.
   • wordpress.ORG is the home of the actual software that runs WordPress. The software is free and open source, meaning you and I can download, use, modify, and redistribute (with some limitations) as we see fit.

   Chances are, if you’re reading this blog, you’re using wordpress.org, and you have your own host and domain name.

   I thought we were talking about API Keys?

   Right. Back on track. A few plugins and other services require you to have a WordPress API Key – Most notably, Akismet (the comment spam fighting plugin that comes bundled with WordPress). Now, when you hear WordPress API key, you assume you’ll head back to the place you downloaded WordPress from (wordpress.org), and get it there. This is, however, wrong. WordPress.org is a big site, and it’s possible to have an account there, so you can waste a lot of time looking for the mystical API Key.

   The API Key you’re after is part of the WordPress.COM ecosystem, and is available once you sign up for a free account there. You don’t even have to set up a blog – just head over, sign up (click here to sign up without setting up a blog), and navigate to your profile page, where you’ll find a link to get your API key. Just like that, you’re all set!

   EDIT: The process has changed! You now get your api key straight from akismet. You’re going to have to withstand some awfully guilt inducing text to get it free. Consider yourself warned.

   ]]> http://codegarage.com/blog/2011/03/wordpress-api-key-what-is-it-and-why-does-it-matter/feed/ 0 http://codegarage.com/blog/2011/03/how-to-301-redirect-your-wordpress-blog-to-a-new-url/ http://codegarage.com/blog/2011/03/how-to-301-redirect-your-wordpress-blog-to-a-new-url/#comments Sat, 05 Mar 2011 20:55:21 +0000 Peter http://yourcodegarage.com/blog/?p=262 Having just done this to move from apartmentonesix.com to yourcodegarage.com, I figured it would be fitting to write a quick post about how to handle this sort of redirection.

   What are we trying to do?

   It’s important to know the goal – in this case, we want to move a site from one url to another. For example, from

   http://site1.com

   to

   http://site2.com

   However, we’re actually moving all the content and everything over – so we want to redirect the individual urls, like this:

   http://site1.com/post-1/

   redirects to

   http://site2.com/post-1/

   That way any bookmarks or incoming links pointing at the old site will redirect properly at the new one.

   The Steps

   First things first, you need to duplicate your WordPress installation from the old site onto the new one. Here’s the drive by version of how to do that:

   On the old site:

   1. Grab a backup of your files
      You don’t have to actually grab the whole wordpress install (with it’s roughly 1000 files) to accomplish this – chances are, you’ll be just fine with just the wp-content folder. Download these files to your desktop.
   2. Make a dump of your database
      Using phpMyAdmin (or some other backup utility), get a copy of your database. Download this to your desktop also.

   We’ll be back to thsi site in a bit to implement the redirect, but for now, we’ll move to the new site.

   On the new site:

   1. Upload your file backups from the old site.
      If you only downloaded the contents of the wp-content folder, you’ll need to install a fresh copy of WordPress over here, and then upload your wp-contents folder, overwriting the one that was installed with WordPress.
   2. Import your database backup to the new site
      Again, you’ll need to use phpMyAdmin, or a similar client to handle this. Depending on the new hosting setup, you’re probably going to need to create a database and a database user for WordPress to use – but that should be covered by the WordPress install process from step 1. Take Note! of your database prefix. If you’re not sure what this is, you can look at the wp-config.php file on your old site (look for a line that starts with

      $table_prefix =

   3. Connect to the database
      If necessary, set up or modify the wp-config.php file for your new site, making sure it points to the database tables you just imported. You’ll know you’re on the right track when you load up the new url, and you see your blog content there, waiting for you. The styling might be messed up, and clicking any of the links will take you to the old site – but if you can see your content, you’ve done everything right so far.
   4. Switch WordPress’ location values
      If you’ve tried to log in at the new site before this point, you probably had something confusing happen – you went to wp-login.php, entered your credentials, and suddenly you were back at your old URL! This happens because of some location settings in the database files you just imported. To fix it, you need to change 2 values in your database. Again, you’ll need phpMyAdmin, or similar, to make these changes. The first option you need to edit is id 1, with the “option_name” of “siteurl”. This should currently be the url to your old site – you want it to be your new site. Change it to that, with no trailing slash:
      You need to make one more change, at about id 39 – look for an option with the option name of “home”, and change it appropriately.
   5. You’re all set! The blog should now be working at it’s new location, completely.

   Redirect code for your old site

   All we’ve got left to do is redirect your old site to the new one. Unfortunately, this is often the scariest and most difficult part of the entire process. On the bright side, you should be able to just paste this code in and call it done.

   What are we doing?

   To accomplish our redirect, we’re goign to modify the .htaccess file of our old site. .htaccess is a file that you can use to give your server special instructions on how to handle certain requests to your site. Because it starts with a dot, it’s often hidden by FTP clients – so you may have to do some tinkering to have it visible and editable to you.
   Here’s the code we’re going to use:

   RewriteEngine on
   RewriteRule ^(.*)$ http://yourcodegarage.com/blog/$1 [R=301,L]
   

   Obviously, you’re going to want to replace “yourcodegarage.com/blog” with your own url. Just put that at the top of your .htaccess file, and you should be all set. Here’s the gist of what’s happening:

   RewriteEngine on

   Here, we’re just telling the .htaccess file to make sure the rewrite engine that your webserver uses is running, and able to handle the request.

   RewriteRule

   We start the line with the word “RewriteRule”, because that’s what we’re defining – a rule for the server to use in rewriting the url and sending the user to where we want them.

   ^(.*)$

   I’m not going to get into the nitty gritty of the regular expression being used here, but what you need to know is: This section says “Match the entire url (after the domain name), and store the whole thing for me to use later in this line.”

   http://yourcodegarage.com/blog/$1

   At this point, we give the url we’d like to send the user to. In my case, I needed to send the user to yourcodegarage.com/blog, because that’s where the blog is now located. The $1 after that is telling the server to append whatever we found before to the end of this. So, if the old url was

   http://apartmentonesix.com/my-post/comments

   then “my-post/comments” would be grabbed, and appended to the end of “http://yourcodegarage.com/blog”, ensuring that the user gets sent where he needs to go.
   We finish up with this:

   [R=301,L]

   All we’re saying here is use a 301 redirect (permanent), and don’t listen to any redirect rules after this one.

   And with that, we’re all set! Make sure you use Google Webmaster Tools to notify google of the change, and get to work blogging at your new url!

   ]]> http://codegarage.com/blog/2011/03/how-to-301-redirect-your-wordpress-blog-to-a-new-url/feed/ 8 http://codegarage.com/blog/2010/08/help-all-the-posts-have-disappeared-from-my-wordpress-site/ http://codegarage.com/blog/2010/08/help-all-the-posts-have-disappeared-from-my-wordpress-site/#comments Tue, 17 Aug 2010 19:20:50 +0000 Peter http://apartmentonesix.com/?p=223 I do all of the development work for an SEO/MMO program over at thekeywordacademy.com. As part of the program, we’ve put together a system that facilitates guest posting on other members’ sites easily. That’s all well and good – but one problem we run into fairly often is this: For whatever reason, the posts table on a site goes down, and the owner’s posts are all suddenly gone – without a trace. Naturally, they get pretty worried, and an email shows up in my inbox (or in our forum).

   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

   ]]> http://codegarage.com/blog/2010/08/help-all-the-posts-have-disappeared-from-my-wordpress-site/feed/ 2 http://codegarage.com/blog/2009/05/how-to-display-properly-formatted-content-from-a-post-object-in-wordpress/ http://codegarage.com/blog/2009/05/how-to-display-properly-formatted-content-from-a-post-object-in-wordpress/#comments Fri, 22 May 2009 02:49:05 +0000 Peter http://apartmentonesix.com/?p=185 Occasionally, I’ll run into a situation where I need to call a post specifically using the get_post() function.  get_post() returns a Post object, with a number of member variables – the one that stores the actual content of the post being post_content.

   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.

   Need more info about the $post object? Check out this post: .

   ]]> http://codegarage.com/blog/2009/05/how-to-display-properly-formatted-content-from-a-post-object-in-wordpress/feed/ 10