Ah, fair $post object. Lets talk about how great you are.
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.
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.
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.
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.
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.
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.
Well played. Here’s a quick rundown on the data the post object gives you:
| Property | Example | Explanation |
|---|---|---|
| $post->post_title | The WordPress $Post Object and You | Title of post. |
| $post->post_excerpt | Learn about the WordPress $Post object! | Manually created post excerpt. If you didn’t purposefully create an excerpt on the add post page, you’re not getting anything here. |
| $post->post_status |
|
Current status of the post. |
| $post->comment_status |
|
Comment status for this particular post. |
| $post->ping_status |
|
Does the current post accept pingbacks and trackbacks? |
| $post->post_password | 123456 | The plaintext password for this post, if there is one. Empty otherwise. |
| $post->post_name | the-wordpress-post-object-and-you | A normalized, sanitized version of the post title, used to generate pretty permalinks. |
| $post->to_ping | http://technorati.com http://someothersitetoping.com | Space separated list of sites to ping which have not been pinged yet. Modified by “Send Trackbacks” field on add post page. |
| $post->pinged | http://technorati.com http://someothersitetoping.com | Space separated list of sites already pinged for this post. |
| $post->post_modified | 2011-09-15 21:21:59 | Time this post was last modified, based on local server time. MySQL timestamp format. |
| $post->post_modified_gmt | 2011-09-15 21:21:59 | Time this post was last modified, based on GMT timezone. MySQL timestamp format. |
| $post->post_content_filtered | Post Content | This field is designed to hold a version of the post for caching, in situations where filters are being run on the post that are “expensive” (slow), and undesireable to run every time. Not used in WP core, may be used by plugins. |
| $post->post_parent | 0 | ID of the parent post. Posts that have parents are generally revisions, or attachments. If the post_parent is 0, this is a bona-fide, original post. |
| $post->guid |
http://codegarage.com/blog/?p=41 |
Global Unique Identifier for the post. According to the documentation page on wordpress.org, this can’t be relied on to actually work as a link to the post, but I’m not totally sure why. Maybe in cases where the site url has changed? |
| $post->menu_order | 0 | Integer determining the order in a list of posts. Generally used for pages in menus, but can be used by plugins for special ordering. |
| $post->post_type |
|
The particular type of post this is. Attachments are generally images, pdfs, etc. Posts and pages are self explanatory. |
| $post->mime_type | image/png | Mime type for attachments. |
| $post->comment_count | 14 | Number of comments on this post currently. |
| $post->post_ancestors | array | Array of parent posts for this post. |
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
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.
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.
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:
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.
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!
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.
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:
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, 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.
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!
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.
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:
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.
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!
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, 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, 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.
/** * 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_';
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!).
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)
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.
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.
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.
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 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 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 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 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:
Nearly every WordPress theme consists of the same basic set of files, listed here:
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
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:
Chances are, if you’re reading this blog, you’re using wordpress.org, and you have your own host and domain name.
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.
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.
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.
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:
We’ll be back to thsi site in a bit to implement the redirect, but for now, we’ll move to the new site.
$table_prefix =
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.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.
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!
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.
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.
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:
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.
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
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: .
Recent Comments