If you’re signed up to Locker and using Paypal to pay, we’ll need to handle your account a little differently during the pricing increase. As with everyone else, your next payment will be at the old rate, and the new price will take effect after that.
After your next payment, you will receive an email from us with instructions on your options for bringing your subscription up to speed.
Get in touch with us at If you have any questions.
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.
First things first: Yes, you can just replace your old timthumb.php file with the new version of timthumb, found here. If that’s all you were after, move along – if you want a little more explanation, read on:
With all of the hubbub around the recent timthumb vulnerability, lots of people are looking for some easy instructions on how to get it taken care of. You should be, because I’ve cleaned up more hacks in the past 2 weeks related to this vulnerability than I have in the last 2 months – people ARE getting hacked due to this.
Unfortunately, if you’re not totally comfortable with code, upgrading this file can be a little scary. Good news, I’m here to help.
This one isn’t too hard – the easiest way to figure this out is to use a scanner of some sort to search your server for the timthumb script. I’ve written a timthumb scanner that runs as a WordPress Plugin – you can find that here.
If you’re not comfortable with that process, you might be able to just give your blog a once over and figure it out yourself. Are you showing thumbnails on the homepage? If so, you might be using timthumb. Right click one of the thumbnails, and click “open image in new tab” (or the equivalent – that’s what it says on chrome on a mac).
In the new tab that opens, check out the url bar – does it say timthumb.php anywhere in the url (check the text right before the question mark, if there is one)? Note – this might also just say “thumb.php”
Fortunately, this one is pretty easy. Open up the file in the wordpress theme editor, or using FTP (it’s probably in your theme directory, called timthumb.php or thumb.php – the previous step should tell you that). Look for this code, near the top:
// external domains that are allowed to be displayed on your website $allowedSites = array ( 'flickr.com', 'picasa.com', 'blogger.com', 'wordpress.com', 'img.youtube.com', 'upload.wikimedia.org', ); // STOP MODIFYING HERE! // --------------------
To clarify (or make things more confusing): If you see this:
// If ALLOW_EXTERNAL is true and ALLOW_ALL_EXTERNAL_SITES is false, then external images will only be fetched from these domains and their subdomains.
if(! isset($ALLOWED_SITES)){
$ALLOWED_SITES = array (
'flickr.com',
'picasa.com',
'img.youtube.com',
'upload.wikimedia.org',
'photobucket.com',
'imgur.com',
'imageshack.us',
'tinypic.com'
);
}
// -------------------------------------------------------------
// -------------- STOP EDITING CONFIGURATION HERE --------------
// -------------------------------------------------------------
You’re ok. $allowedSites = Bad, $ALLOWED_SITES = Good. For another way to check, if you look up near the top of the file and see this:
define ('VERSION', '2.8'); // Version of this script
You’re good. Version 2.0 and greater are safe to use.
If it doesnt look like you’re using the right version, it’s time to clean it up!
400 words later, we finally get back to the question posed in the title. Can I just replace the old, vulnerable code with new, safe code, and have everything still work? Yes, you can.
From the previous step, you’ve got the file open in your WordPress theme editor. All you need to do is replace the entire contents of the file with the code found here:
http://timthumb.googlecode.com/svn/trunk/timthumb.php
Save the file, and you’re done! Your thumbnails still work, and you can sleep a little easier at night.
Plug Time: I do this service for subscribers to my WordPress backup and security monitoring service – so if you’re not sure you want to take it on yourself, have a look here. If you just have a question, or need some guidance, I’m happy to give that away for free. Get in touch with me at peter@codegarage.com. Good luck!
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.
Yesterday, Mark Maunder over at markmaunder.com managed to track down the source of a pretty clever hack on his site, where the hacker gained access through the massively popular TimThumb image thumbnail creation library. You can read his full post on the matter here:
Zero Day Vulnerability in Many WordPress Themes
He’s made an interesting post detailing the work he did to catch the hack – If you have the time, give it a read.
More importantly – this hack has the potential to affect hundreds of thousands of WordPress installs. Unfortunately, because the timthumb library is generally included in themes (both free and premium), it’s not going to be very easy to get patched. Premium theme sellers will no doubt release updates and notify their users, but free theme users are less likely to have such good luck. As such, it’s going to be a good idea to check your site out for this vulnerability, and fix it as soon as possible.
(Note – Subscribers to Locker have had their sites scanned for this vulnerability, and are being automatically notified if they’ve got a problem right now.)
Nearly anyone using the timthumb library, who downloaded it before yesterday (8/1/11) is likely to be vulnerable. How do you know if you’re using timthumb? The easiest way is probably to check out your theme folders for a file called timthumb.php, using FTP, or your host’s file browser. If you’re using a host with cPanel (like Hostgator), it’s very easy – just load up the file manager, and then use the “Find” box in the upper right corner to search for timthumb.php. No results? Chances are good that you’re safe.
Make sure you check every folder in your theme – it’s likely that if your theme has a lot of included files, this file would be in a directory inside your main theme folder.
Fortunately, thanks to the hard work of Mark in finding this and bringing it to light, Ben (the creator of TimThumb), and a few other folks, there is a more secure version of the script now available for download here:
http://timthumb.googlecode.com/svn/trunk/timthumb.php
To secure your site, save that file (File->Save Page As in most browsers) to your computer, and then upload it to your site via FTP, replacing every instance of timthumb.php with the new version you just downloaded. If that’s beyond you, or you want to be absolutely sure that you’ve closed the hole up, send me an email at peter@codegarage.com, or hit me on twitter @peterbutler, and I’ll help get you straightened out.
Good luck!
Here’s a problem I run into every few months with a customer: Their site is suddenly showing strange characters (strange question marks, accented characters, general gibberish) in place of quotation marks, dashes, etc. Oftentimes this happens after a move, but it could also be the result of a few other things.
The problem is generally a result of pasting straight from Microsoft Word (or similar) into WordPress. Word generates lots of evil characters that WordPress and web servers don’t deal with properly. As a result, you end up with gibberish. And frustration.
The best solution is to stop pasting formatted text from Word into WordPress. That is, however, not useful if you’re already dealing with the problem. You could manually replace the problem characters, but that takes FOREVER, and writing a script to get into the database and do it for you is a chore I havent been confident enough to take on, because of the relative obscurity of the problem ( and how difficult it is to find every problem instance ). So, I generally take the easy way out, which is this:
Yep. Just trick wordpress/web browsers to treat the content with Microsoft’s character set, brush your hands off, and be on your way. Here’s how:
There you go: Band aid applied. Again, this isn’t an ideal solution, it’s more like the “quick, dirty, I’m tired of dealing with it solution”.
Just a quick post – I recently had a friend who was moving from a WP MultiUser setup, where each blog had its own subdomain, to one consolidated blog. He wanted to maintain links pointed to his old blogs, so he needed to 301 redirect all the pages on the old subdomains to the appropriate pages on the main domain using his .htaccess file. The code to put it together wasn’t too tricky:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^yourdomain.com$ [NC]
RewriteRule ^(.*)$ http://yourdomain.com/$1 [L,R=301]
This will take any request your site receives, and make sure that the url starts (after the http://) with yourdomain.com. If it starts with anything else (say blog.yourdomain.com, or even www.yourdomain.com), it will be redirected to http://yourdomain.com. This code also allows for deep redirection – that is, if the user typed in
blog.yourdomain.com/my-favorite-page/
they’ll be redirected to
yourdomain.com/my-favorite-page/
which is definitely what you want.
Recent Comments