Posts tagged ‘WordPress’

Have you ever looked at the add_action function in WordPress? Here it is:

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
	return add_filter($tag, $function_to_add, $priority, $accepted_args);
}

I know, right? Some people’s minds just got blown.

What are Filters?

A filter is defined as a function that takes in some kind of input, modifies it, and then returns it. This is an extremely handy little concept that PHP itself uses in a ton of different ways. About half the string functions qualify as a ‘filter’ function.

Look at strrev(). It’s a simple-stupid example. It takes a string as an argument, and then returns the reverse of that string. You could use it as a filter function in WordPress, easily. Like, to reverse all your titles.

add_filter('the_title', 'strrev');

Some filters take more than one argument, but the first argument is always the thing to be modified and returned. PHP adheres to this concept too. Take the substr() function. The first argument is the string, the second and third are the start and optional length values. The returned value is the part of the string you want.

What are Actions?

An action is just a place where you call a function, and you don’t really care what it returns. The function is performing some kind of action just by being called. If you hook a function to the init action, then it runs whenever do_action(‘init’) is called.

Now, some actions have arguments too, but again, there’s still no return value.

So in a sense, a WordPress action is just a filter without the first argument and without a return value.

So why have them both?

Because there is still a conceptual difference between an action and a filter.

Filters filter things. Actions do not. And this is critically important when you’re writing a filter.

A filter function should never, ever, have unexpected side effects.

Take a quick example. Here’s a thread on the WordPress support forums where a person found that using my own SFC plugin in combination with a contact form emailer plugin caused the email from the form to be sent 3-5 times.

Why did it do this? Basically, because the contact form plugin is sending an email inside a filter function.

One of the things SFC does is to build a description meta from the content on the page. It also looks through that content for images and video, in order to build meta information to send to Facebook. In order for this to happen at the right time, the plugin must call the_content filter.

See, what if somebody puts a link to a Flickr picture on their page? In that case, oEmbed will kick in and convert that link into a nice and pretty embedded image. Same for YouTube videos. Or maybe somebody is using a gallery and there’s lots of pictures on the resulting page, but the only thing in the post_content is the gallery shortcode.

In order to get those images from the content, SFC has to do apply_filters(‘the_content’,$post_content). This makes all the other plugins and all the other bits of the system process that $post_content and return the straight HTML. Then it can go and look for images, look for video, even make a pretty 1000 character excerpt to send to Facebook.

But SFC can’t possibly know that doing apply_filters(‘the_content’,…) will cause some other plugin to go and send a freakin’ email. That’s totally unexpected. It’s just trying to filter some content. That would be like calling the strrev() function and having it make a phone call. Totally crazy.

Shortcodes

Shortcodes are a type of filter. They take in content from the shortcode, they return replacement content of some sort. They are filters, by definition. Always, always keep that in mind.

Also keep in mind that shortcodes are supposed to return the replacement content, not just echo it out.

Conclusion

So plugin authors, please, please, I’m begging you, learn this lesson well.

Filters are supposed to filter. Actions are supposed to take action.

When you mix the two up, then you cause pain for the rest of the world trying to interact with your code. My desk is starting to get covered in dents from me repeatedly banging my head into it because of this.

Shortlink:

Was trying to upload some photos and noticed that the captions I had set on the photos in Picasa showed up as titles in WordPress instead of as captions. Examining the core code, I found that it’s a known issue, but that fixing it in the core isn’t so easy, since WordPress has to support a number of different image editing programs and such. Different programs use the EXIF fields in different ways.

But I mostly use Picasa for photo management, so I don’t care about those other programs. So I wrote a quick plugin to fix the problem with WordPress and Picasa photos. Basically it just rejiggers the attachment when it’s added (but not when it’s edited) and puts the caption in the right place.

<?php
/**
Plugin Name: Picasa Captioner
Description: Fix up WordPress to read Picasa Captions from EXIF info properly.
Author: Otto
Author URI: http://ottodestruct.com/
**/

add_filter( 'wp_read_image_metadata', 'picasa_adjust_caption' );
function picasa_adjust_caption($meta) {
	if (empty($meta['caption']) && !empty($meta['title'])) {
		$meta['caption'] = $meta['title'];
		$meta['title'] = '';
	}
	return $meta;
}

add_action( 'add_attachment', 'picasa_adjust_attachment' );
function picasa_adjust_attachment($id) {
	$attachment = & get_post( $id, ARRAY_A );
	if ( !empty( $attachment ) ) {
		$attachment['post_excerpt'] = $attachment['post_content'];
		$attachment['post_content'] = '';
		wp_update_post($attachment);
	}
}
Shortlink:

I have seen many questions from people about how to create photo galleries in WordPress. But often I see these questions answered by somebody recommending a plugin or something like that. You don’t really need plugins to create photo galleries. WordPress has a huge amount of gallery functionality built right in. You just need to make your theme smarter in order to take advantage of it.

Note: Matt has one of the neatest photo gallery implementations around, and he often gets questions about it. So I’m going to refer to it from time to time in this post. Maybe you’ll want to head over there and familiarize yourself with some of the look and features of it.

Understanding the Gallery Concept

One of the first things you need to know is how WordPress organizes Galleries. A gallery is really just a post with a bunch of images attached to it.

While editing a post or creating a new one, you have the option to upload images or other files. When you upload a file through the file Uploader, WordPress creates a post just for that file. This post has a post_type of “attachment”. Images in particular get some extra processing, and they show up in multiple sizes, you can insert them into the posts, etc. You probably already knew that. You probably have seen the gallery inserter, which just inserts the “gallery” shortcode into your post.

What you might not have known is that it’s doing more than you think. It’s not just resizing those images you’re uploading, but it’s pulling out metadata and other information about the image too. It’s grabbing alot of the EXIF data from the image and storing it as postmeta items for that attachment post. The post itself, being a post, gets its own URL, which is the post that it is attached to’s URL followed by the attachment posts title. Basically, an attachment post is sorta like a child of the parent post, which contains the gallery. So all a gallery really is is the sum of the attachments posts that are children of the gallery post itself.

Graph of the Gallery concept

Is that clear as mud? Don’t worry, it’s simpler to work with than you think.

Create an Image Template

First thing you need to do is to edit your theme (or create a child theme, if you prefer). What you’re going to do is to make an “image.php” file.

(Side note: If you browse through the source of WordPress, you’ll never find where it loads the “image.php” file, because it isn’t there. What it is actually doing is looking for the mimetype of the attachment as a filename. So since you uploaded, say, a JPG file, then the mimetype is image/jpeg. It splits that and looks for image.php, followed by jpeg.php, followed by image_jpeg.php, and finally just attachment.php as the generic base. It does this for any and all attachments, and any and all mime types. So you can have a video.php for video attachments, audio.php for audio attachments, etc.)

The image.php file is the template that will load for “single images”. A gallery shows thumbnails, but when you click on them, you go to the attachment page for just that image. An easy way to start with your custom image page is to copy your existing single post page to it. Just copy single.php to image.php. If you don’t have a single.php, maybe you should try copying the index.php file instead.

Modify your Image Template

Since this is an image, it’s going to have things in it that normal posts don’t. It’s also going to need special navigational entries that other posts don’t have.

For starters, it has a parent, which is the post containing the gallery. So what if we want to display the gallery post’s name? Easy, we can reference the parent using $post->post_parent. So code like get_the_title($post->post_parent) will get us that title so we can echo it. Similarly, using something like get_permalink($post->post_parent) will get us the link back to the gallery. So this sort of code in our image template will display that link:

echo "<a href='" . get_permalink($post->post_parent). "'>Go back to ". get_the_title($post->post_parent) ."</a>";

For navigation, we have special functions. previous_image_link and next_image_link will let us display links to the previous or next images in the gallery order. Each of these takes two parameters. The first is the size of the previous or next image we want to display (or false to not show a thumbnail at all), the second optional parameter is some text to put in the link. So to show a couple of text navigational links, this code would work:

echo previous_image_link(false,'Previous Photo');
echo next_image_link(false,'Next Photo');

If I wanted to display image links instead, I could change that false to ‘thumbnail’ to display the thumbnail sized images. Or ‘medium’. Or whatever size I preferred.

Next we want to display the image. The wp_get_attachment_image function takes care of that easily:

echo wp_get_attachment_image( $post->ID, 'medium' );

The second parameter there is the size we want to display it at. You could also use ‘large’, ‘full’, ‘thumbnail’, etc. Any of the image sizes. If you want the image to be clickable, you might wrap it in an A tag and link it to the image itself.

But remember that attachment posts are still posts. All those fields you can enter on the image uploader are available to you to use. For example, the “Title” is stored in the normal Post Title field, so calling the_title() will display that. The Description is stored in the Content field and can be displayed with the_content(). The Caption is stored in the Excerpt field and can be displayed with the_excerpt(). You should use these as needed.

EXIF Information

Here’s an example of one of Matt’s single image pages, showing a balloon: http://ma.tt/2011/05/balloon-ride/mcm_9033/.

Nice shot. Scroll down a bit and look on the right hand side of that page, where it says INFO. Lots of nifty information there. But he didn’t put any of that in, WordPress did it all by itself.

To gain access to that information in your image.php file, you use this code:

$imagemeta = wp_get_attachment_metadata();

If you examine this array, you find that it contains widths, heights, filenames of the various sizes of thumbnails generated, etc. But it also contains an array called “image_meta”. This is an array of information that represents everything WordPress was able to glean from the image itself. After you know this, it’s just a matter of displaying it properly.

For example, to display the camera name, he has code similar to this:

if ($imagemeta['image_meta']['camera']) {
	echo "Camera: " . $imagemeta['image_meta']['camera'];
}

There’s other bits in there, like Aperture, Focal Length, ISO settings, and Shutter Speed. Most of these are straightforward, except for shutter speed which is often not in an easy format to display. Usually it’s a fractional value, represented as a decimal. Often we want to convert this to the fractional display. Here’s a bit of code I wrote to do that. It’s not perfect, but what is?

if ($imagemeta['image_meta']['shutter_speed']) {
	echo 'Shutter: ';

	// shutter speed handler
	if ((1 / $imagemeta['image_meta']['shutter_speed']) > 1) {
	echo "1/";
		if (number_format((1 / $imagemeta['image_meta']['shutter_speed']), 1) ==  number_format((1 / $imagemeta['image_meta']['shutter_speed']), 0)) {
			echo number_format((1 / $imagemeta['image_meta']['shutter_speed']), 0, '.', '') . ' sec';
		} else {
			echo number_format((1 / $imagemeta['image_meta']['shutter_speed']), 1, '.', '') . ' sec';
		}
	} else {
		echo $imagemeta['image_meta']['shutter_speed'].' sec';
	}
}

Ugly, I know, but it gets the job done, more or less. Works on most shutter speeds I’ve tested it with.

Gallery Formatting in the Stream

Now, obviously you want your posts to look good in the normal flow of the blog as well. Twenty-Ten and the upcoming Twenty-Eleven themes both show you how to do this rather easily. Twenty-Ten used the “gallery” category for this at one point, before Post Formats came along and made that method obsolete. Now it uses the gallery post format instead.

So first, obviously, your theme will need to support the gallery post format. This is easy, just add this to your theme’s functions.php if it doesn’t have gallery support already (or add “gallery” to it if it does have post format support).

add_theme_support( 'post-formats', array( 'gallery') );

Now that that’s done, you have the option of choosing gallery as a post format. So you need to edit your theme to use that flag as an indicator to display things differently.

There’s plenty of tutorials on post formats out there, so I’ll assume you’re more than capable of figuring out how to use has_post_format(‘gallery’) or the “.home .format-gallery” CSS indicators to style the posts as needed.

What you need to know for specific gallery formatting in the main stream of the blog is how to display a selected representative image from the gallery there instead of the whole thing. There’s two basic steps to this.

First, you have to write your post appropriately to begin with. Take one of Matt’s posts for example: http://ma.tt/2011/05/20/

Here’s how that post actually looks in the editor:

Description text at the top here... Went for balloon ride, etc.
< !--more-- >
[ gallery ]

In other words, he puts the description first, then the more tag, then the gallery after it. This has the effect of giving a natural separation of the description content and the gallery itself. The gallery is not displayed on the front page, because it’s after the more tag. So a call to the_content() on the stream pages will only show the description.

Secondly, you can easily adapt the Featured Image function to let you choose which image to display in the stream. All the user has to do is to upload their gallery then select one and set it to be the featured image. Voila, it’ll be the main representative one used.

if ( has_post_thumbnail() ) {
        // use the thumbnail ("featured image")
        $thumb_id = get_post_thumbnail_id();
	the_post_thumbnail( $size ); // whatever size you want
}

By tossing a div around that, you can then float it left, or right, or whatever you prefer to do. With some extra code and the use of the get_children function, you can make this default to the first image in the gallery if they don’t choose a featured image.

else {
	$attachments = get_children( array(
		'post_parent' => get_the_ID(),
		'post_status' => 'inherit',
		'post_type' => 'attachment',
		'post_mime_type' => 'image',
		'order' => 'ASC',
		'orderby' => 'menu_order ID',
		'numberposts' => 1)
	);
	foreach ( $attachments as $thumb_id => $attachment )
		echo wp_get_attachment_image($thumb_id, $size); // whatever size you want
	}
}

Using tricks like this, you can get the bits of the gallery yourself and display them in different ways.

Make a Gallery Specific Page Template

Matt’s Gallery Page is itself customized. It displays the galleries in an entirely different way. There’s a big copy of the featured image, along with a few thumbnails below the description, and it even has a count of the images in each “album”. This is all done with a pretty straightforward page template.

So to start, make a Page Template:

/*
Template Name: Gallery
*/

Right at the top of the template, we’re going to add a special taxonomy query, which will get all the gallery posts (as well those in the gallery category, since we’re being backward compatible and all). So here’s the code:

$args = wp_parse_args($query_string);

query_posts(array(
         'tax_query' => array(
                'relation' => 'OR',
                array(
                        'taxonomy' => 'post_format',
                        'terms' => array('post-format-gallery'),
                        'field' => 'slug',
                ),
                array(
                        'taxonomy' => 'category',
                        'terms' => array('gallery'),
                        'field' => 'slug',
                ),
        ),
        'paged' => $args['paged'],
) );

First we parse the normal arguments, then we override them with our own query. The only argument we really use from the normal set is the page number, for multiple paging.

Our overriden query uses an advanced taxonomy query. In this case, it selects any posts in the gallery post format, or any post with a category of gallery. By passing this to query_posts, we override our main page query, and thus our main Loop will now display the gallery posts only.

After this, it’s just a matter of displaying what we want to display.

The main Loop itself is pretty straightforward. To display that featured image, we use essentially the same code as we used before, only passing it a bigger size.

To display the description, we just use the_content() as per usual. One thing we have to do though is to set the global $more value to zero, so that it stops at the !–more– tag, preventing it from continuing to display the whole gallery.

Getting the count turns out to kinda suck. There’s no good function in WordPress to do this for you easily. So, reluctantly, I resorted to an SQL query.

echo $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->posts WHERE post_parent = '$post->ID' AND post_type = 'attachment'" ) .' PHOTOS IN THIS SET';

The four thumbnails you can do using the get_children trick. However, there’s a catch. We don’t want to display the featured image as one of those four thumbnails. So, since we’ve already displayed that image (see the code above), we have the $thumb_id variable still. So we’ll use that to not get that image. Like so:

$attachments = get_children( array(
	'post_parent' => get_the_ID(),
	'post_status' => 'inherit',
	'post_type' => 'attachment',
	'post_mime_type' => 'image',
	'order' => 'ASC',
	'orderby' => 'menu_order ID',
	'numberposts' => 4,
	'exclude' => $thumb_id )
);
foreach ( $attachments as $img => $attachment ) {
	echo '<a href="'.get_permalink($img).'">'.wp_get_attachment_image( $img, $size ).'</a>';
}

By using the exclude parameter, we can get the first four images in the gallery without getting that featured image again, if it’s in those first four images.

Update

Andrew Nacin pointed out that I can combine the act of getting those four children and getting the attachment count into a single new WP_Query, like so:

$images = new WP_Query( array(
    'post_parent' => get_the_ID(),
    'post_status' => 'inherit',
    'post_type' => 'attachment',
    'post_mime_type' => 'image',
    'order' => 'ASC',
    'orderby' => 'menu_order ID',
    'posts_per_page' => 4,
    'post__not_in' => array($thumb_id),
    'update_post_term_cache' => false,
) );

This creates a new secondary query that I can loop through like so, to show the children:

foreach ($images->posts as $image) {
	echo '<a href="'.get_permalink($image->ID).'">'.wp_get_attachment_image( $image->ID, $size ).'</a>';
}

It also has the side benefit of doing the primary counting of the images for me, via the SQL_CALC_FOUND_ROWS that WordPress uses in full-blown queries. However, the count will be off by 1, since we’re excluding the featured thumbnail. Therefore, I just have to add one to it:

echo ($images->found_posts+1) . ' PHOTOS IN THIS SET';

That combines both of those elements into one query instead of two, and eliminates the need for the direct SQL query.

(Side note: I also set ‘update_post_term_cache’ to false to prevent it from doing an extra query to get the terms for these posts into the internal memory cache. This saves us a bunch of unnecessary queries, since I’m not using the terms here anyway. Using full WP_Query objects instead of the simpler ones like get_children can take a little bit more thought and effort, but can save you time in the long run, if used wisely.)

Sizes

Throughout this post I’ve used $size as a generic indicator of where to put the size parameter. WordPress creates sized images by default, as we all know. These are thumbnail, medium, large, and full which is just the full sized uploaded image, unmodified.

But WordPress can create other sizes too, if you like. At different points throughout Matt’s gallery pages, you’ll see images displayed in all sizes. These sizes are custom, and they’re added in the functions.php file.

add_image_size( 'nav-thumbnail', 100, 100, true );
add_image_size( 'random-thumbnail', 200, 150, true );
add_image_size( 'gallery-thumbnail', 250, 200, false );
add_image_size( 'gallery-large', 660, 500, false );
add_image_size( 'gallery-pagethumb', 70, 70, true );

The add_image_size function takes a width, a height, and a flag to cause it to crop or not. So those tiny thumbnails on the gallery are “gallery-pagethumb” sized, and are 70×70, cropped. Anywhere I need one of those sizes, I can just pass that parameter instead of $size and voila.

Obviously though, adding too many sizes is undesirable, because it takes time to create those sizes (they’re created on upload of the images), and it takes storage space to store them. Hopefully a future version of WordPress can work around this issue.

Conclusion

These are the basics of making cool galleries, without plugins, without special uploaders, and while being able to style it to match your theme. Play with it. Experiment. There’s a ton of functions in WordPress specifically for dealing with these. Take a look through wp-includes/media.php and look at some of the function names. You might be surprised.

Shortlink:

A surprising number of people don’t know about or have never used this feature, so it’s something I thought I should point out.

You know all those boxes on the Edit Post page? Did you know you could turn them off? Did you know that WP 3.1 turns many of them off by default?

See? Just click the Screen Options dropdown to show or hide anything you want or don’t want to see. These settings are saved so that you can customize how your own editing screen looks, for you only, every time you go to add or edit a post. Plugins that make meta boxes get their meta box added to this list too, so if you don’t use the manual Publisher boxes from my own Facebook or Twitter plugins, for example, you can just disable them.

People often ask me why there’s a Publish box when they are using Auto-Publish in the SFC or STC plugins, and why I didn’t make that optional. So I just thought it might be worth pointing out publicly that there is already an option for it, built right in. 🙂

Shortlink:

There’s been a lot of articles on this topic over the years (I even wrote one). But I’m going to tackle this from a different angle, one that I’m not used to: A non-technical one.

Fixing a website “hack” is actually a fairly heavy technical thing to do. Most bloggers are not webmasters. They are not really technical people. They’re probably people who simply purchased a web hosting account, maybe set up WordPress using a one-click install, and started blogging. In an ideal world, this sort of setup would be perfectly secure. The fact that it’s usually not is really a problem for web hosts to figure out.

But often I find that the emails/posts I see that read “help me my site was hacked what do I do” or similar don’t get a lot of help. There’s a reason for this. People who are asking this question are not usually the type of people who are technically capable of actually fixing the problem. Guiding somebody through this process is non-trivial. Frankly, it’s kind of a pain in the ass. So those of us capable of fixing such a site (and there are plenty) are reluctant to try to help and basically offer our services for free. The amount of work is high, the frustration is equally high, and there’s not a lot of benefit in it.

So, with that in mind..

Step One: Regain control of the site

By “control”, I basically mean to get the passwords back and change them. Tell your webhost to do it if you have to, and read this codex article on how to change your WordPress password even when you can’t get into WordPress. Also, change your web hosting account password, your FTP password, the database password… Any password you have even remotely related to your site: change it. Note that doing this will very likely break the site. That’s okay, down is down, and it would be better to be down than showing hacked spammy crap to the world.

And that’s another point: take the site down, immediately. Unexpected downtime sucks, but if you’re showing spam to the world, then Google is sure to notice. If you’re down for a time, then Google understands and can cope, but if you’re showing bad things, then Google will think you’re a bad person. And you don’t want that.

The idea here is to stop the bleeding. Until you do that, you haven’t done anything at all.

Step Two: Don’t do a damn thing else

Once you have the passwords and the site is offline, leave it like that.

Seriously, don’t erase anything, don’t restore from backup, don’t do anything until you do what follows next…

Anything you do at this point destroys vital information. I cannot stress this enough.

Step Three: Hire a technically competent person to fix it for you

If you know me, then you know I rarely recommend this sort of thing. I tend to offer technical knowledge and try to help people do-it-themselves. But hey, for some people, there are times when it’s just a hell of a lot to take in. Webserver security is a complex subject, with a lot of aspects to it. There is a lot of background knowledge you need to know.

If you’re reading this and you don’t know how a webserver works, or config files, or you don’t know arcane SQL commands, or you don’t understand how the PHP code connects to the database and uses templates to generate HTML, then trust me when I tell you that you are not going to fix your website. Not really. Sure, you could probably get it running again, but you can’t fix it to where it won’t get hacked again.

So, find a website tech person. Somebody who knows what they’re doing.

(BTW, not me. Seriously, I’ve got enough to do as is. Just don’t even ask.)

How, you ask? I dunno. Look on the googles. How do you find anybody to do anything? There’s several sites out there for offering short-term jobs to tech wizards. There is the WordPress Jobs site, but note that I said you need a website person, not necessarily a WordPress person. A lot of people who know WordPress don’t know websites and security… Although many of them do and this is not an indictment on the community, it’s more a recognition of the fact that working with servers and websites in general is not really the same thing as working with WordPress. WP knowledge is useful, but generic server admin experience is much, much better in this situation.

And yes, I said HIRE. Seriously, pay up. This is a lot of work that requires special knowledge. I know that a lot of people try to run their websites cheaply and such… Look here, if you’re paying less than $300 a year to run a website, then why bother? How serious are you about your website anyway? Quality web hosting should cost you more than that, hiring a specialist for a short term day-job is going to run you a fair amount of money. Expect that and don’t give him too much hassle about it. Feel free to try to argue on the price, but please don’t be insulting. Offering $50 to fix your site is unfair, as that’s less than an hour’s pay for most consultants, and you need one with special skills here. This is a minimum of a day’s work, probably longer if your site is at all complicated. Just getting it running again without doing everything that needs to be done is probably a 4 hour job. Sure, somebody can hack together a fix in half an hour, but do you ask your automotive guy to just throw the oil at the engine until it runs? Have some respect for the fact that knowledge and skill is valuable, in any profession.

Basically, here’s what the website guy will be doing, if he knows his business.

First, he’ll probably backup the site. This includes the files, the databases, any logs that are available, everything. The idea is to grab a copy of the whole blamed thing, as it stands. This is a “cover-your-ass” scenario; he’s going to be making large scale changes to the site, so having a backup is a good idea, even if it is a hacked one. The person will need all of the relevant passwords, but don’t give them out in advance. He’ll ask for what he needs from you.

Second, if you already have regular backups (please, start making regular backups… VaultPress is invaluable in this situation and can help the process out immensely), then he’ll probably want to restore to a backup from before the hack. And yes, you very likely WILL lose content in this restoration. However, since there is a backup, the content can be recovered later, if it’s worth the trouble.

(Note, if you don’t have any backups, then he’ll try to remove the hack manually. This is error prone and difficult to do. It also takes longer and has a much lower chance of succeeding. It’s also difficult to know that you got everything out of the site. If anything is left behind, then the site can be re-hacked through hidden backdoors. This is why regular backups are critically important to have.)

Third, he’ll update everything to the latest versions and perform a security audit of the site. This means looking at all the plugins, themes, permissions on the files, the files themselves, everything. This is to make sure all the main security bases are covered and that it doesn’t get rehacked while he does the next step. They may talk about “hardening” the site.

Fourth, from that backup he made earlier, he’ll likely try to trace where the hack started from. Logs help here, as do the files themselves. This is kind of an art form. You’re looking at a static picture of a dynamic system. And unfortunately, he may not even be able to tell you what happened or how the attackers got in. Attackers often hide their traces, especially automated tools that do hacking of sites. With any luck, the basic upgrades to the system will be enough to prevent them getting in again, and a security audit by a knowing eye will eliminate the most common ways of attackers getting in. That often is enough.

Step Four: Prevention

Once your site is fixed, then you need to take steps to prevent it from happening again. The rules here are the same rules as any other technical system.

  • Regular backups. I can’t recommend VaultPress enough. After my site went offline for a day due to some issues with my webhost (not a hack), I lost some data. VaultPress had it and restoring it was easy. There’s other good backup solutions too, if you can’t afford $20 a month (seriously, don’t cheap out on your website folks!).
  • Security auditing. There’s some good plugins out there to do automatic scans of your site on a regular basis and warn you about changes. There’s good plugins to do security checks on your sites files. There’s good tools to check for issues that may be invisible to you. Use them, regularly. Or at least install them and let them run and warn you of possible threats.
  • Virus scanning. My website got hacked one time only. How? A trojan made it onto my computer and stole my FTP password, then an automated tool tied to that trojan tried to upload bad things to my site. It got stopped halfway (and I found and eliminated the trojan), but the point is that even tech-ninjas like me can slip up every once in a while. Have good security on your home computer as well.
  • Strong passwords. There is no longer any reason to use the same password everywhere. There is no longer any excuse for using a password that doesn’t look like total gibberish. Seriously, with recent hacks making this sort of thing obvious, everybody should be using a password storage solution. I tried several and settled on LastPass. Other people I know use 1Password. This sort of thing is a requirement for secure computing, and everybody should be using something like it.

These are some basic thoughts on the subject, and there’s probably others I haven’t considered. Security is an ever changing thing. The person you hire may make suggestions, and if they’re good ones, it may be worth retaining him for future work. If your site is valuable to you, then it may be worth it to invest in its future.

And yes, anybody can learn how to do this sort of thing. Probably on their own. The documentation is out there, the knowledge is freely available, and many tutorials exist. But sometimes you need to ask yourself, is this the right time for me to learn how to DIY? If you need quick action, then it might just be worth paying a pro.

Shortlink:

I got tired of waiting for a “proper” YOURLS WordPress plugin to come out, so I did it myself. Hey, I’ve got other stuff to do, and I needed a working shortlink solution.

Basically, this is the “YOURLS: WordPress to Twitter” plugin, with all the Twitter bits removed.

While I was in there, I also fixed the password saving bug that I kept having in Chrome (just cut out the submit button JS), switched it to eliminate the Pear_JSON package entirely (WordPress has JSON support built in already), and did some other minor things. I’m sure I missed some bits, but for the most part it was really just a hack and slash job. Eliminated about 30% of the plugin’s main code and all the ancillary Twitter libraries.

On a side note, this sort of thing only reinforces something I’ve said before: Plugins should only try to do one thing, and to do it well. Trying to have a twitter solution in this plugin when I didn’t want to use that bit at all basically just made it stop doing the shortlinks correctly. That’s a real problem when it’s really a shortlink plugin to begin with. I already had a really good twitter solution, trying to have all this extra crap in there just made it not work properly.

If I had more time, I’d also remove all the JS stuff on the settings page too. That’s not really necessary when you only have a few fields to enter. But I guess it works, sort of. Whatever. Not important.

Anyway, here you go. I won’t be putting this in the plugins repository, since it’s not really my code. But I am posting it here in case it helps anybody. And if Ozh changes his plugin to eliminate the Twitter stuff (or to at least make it optional without impacting functionality), then it would be worth switching to that in the future. I won’t be supporting this plugin anytime soon.

YOURLS – WordPress (no Twitter)

Edit: Note that I did this mainly because I wanted to use my own Simple Twitter Connect instead for posting items to Twitter. That works fine and uses the shortlink from this plugin fine. But the extra Twitter stuff in the original plugin interfered with it, and there was no good way to disable that stuff short of editing the plugin. I’m a fan of not editing other people’s plugins, but in this case there really wasn’t a lot of choice. YOURLS is a good system and I like using it, I just wish the WP plugin for it wasn’t trying to do so much. Just so you know. 🙂

Shortlink:

While the WordPress upgrade system is great, sometimes people prefer to use command line tools or similar to manage their sites.

I hadn’t done this much until recently, but when I was at #wptybee, Matt asked me to set up a site using SVN externals. This turned out to be easier than expected, and a great way to keep a site up-to-date and easy to manage. So I thought I’d document the process a little bit here.

This is actually not an uncommon way of creating sites and maintaining them. I’d just never seen it documented anywhere before. If you know SVN, you probably already know how to do this.

Prerequisites

First, you’ll need to have a website on a host. Obviously.

You’ll also need shell access on that host. SSH will do fine.

Next, you’ll need that host to have SVN. Easy way to check: just run “svn –version” at the command line.

Finally, you’ll need an SVN server. A central place to store your files. Some hosts let you set these up easily. Sometimes you’ll have to set one up yourself. How to do this is slightly outside the scope of this article.

Create the SVN environment

The first thing you’ll want to do is to check out your SVN area into a directory on the machine. You can do this part on either your local machine, or on the server. I did it on my Windows 7 laptop, using TortoiseSVN.

The basic idea here is that this site will become your new public_html directory. Alternatively, you can make it a subdirectory under that and use .htaccess rules or any form of rewriting to change where the root of your website is. Regardless, the directory as a whole will be your main website directory.

SVN Externals

Now, we’re going to get WordPress installed into your SVN. To do that, we setup the WordPress SVN to be an external of the SVN root.

If you use TortoiseSVN, then you’re going to right click inside the root of your checkout, then select TortoiseSVN->Properties. In the dialog that follows, you’ll create a new property named “svn:externals” and give it a value of “wp http://core.svn.wordpress.org/trunk/“. Hit OK to make it stick (note, do not select the recursive option).

Note, if you’re using the command line, a guide on svn externals is here: http://beerpla.net/2009/06/20/how-to-properly-set-svn-svnexternals-property-in-svn-command-line/.

What this does is simple, really. It tells the SVN that the contents in the “wp” directory will come from http://core.svn.wordpress.org/trunk , which is the main trunk version of WordPress.

Alternatively, if you’re not brave enough to run trunk all the time, you could use http://core.svn.wordpress.org/branches/3.0, which would make it get the latest 3.0 version at all times (which is 3.0.4 right now). And if you wanted to use a directory name other than “wp”, you could change that as well.

The point being that instead of having to manually update WordPress, you’re telling your SVN server that the contents there actually come from another SVN server. So when you do an “update”, it will go and grab the latest version of WordPress directly, without having to updated by hand.

After you’ve modified the externals setting for that root directory, you have to do a commit, to send the new property to the SVN server. Then you can do an update and watch it go and grab a copy of WordPress and put it into your directory directly.

Custom Content

So now we have a WordPress setup, but it’s not installed. No worries, but we’re going to make a custom installation here, so we’ll hand edit the wp-config file eventually.

Why are we doing this? Well, we want our wp-content folder to live outside of the WordPress directory. It’s going to contain our custom plugins and themes and so forth. That way, no changes to WordPress’s files in their SVN can ever touch our own files.

So we need to make a folder in the root called “custom-content”. Or whatever you want to call it. Since this name will be visible in your HTML, you might want to choose a good one.

Now inside that folder, make a plugins and a themes directory. For the themes, you’re probably using a custom theme for your site, and you can just put it in there directly.

Plugins are a different matter.

Plugins as Externals

I assume that whatever plugins you are using are coming from the plugin repository. Or at least, some of them are. For your custom ones, you can do pretty much the same as the themes and just drop the plugins into your plugins directory. But for plugins from the repo, there’s a better way.

In much the same way as we made the wp directory an external pointer to the core WordPress SVN, we’re now going to do the same for our plugins.

So step one, choose a plugin you want. Let’s choose Akismet for a demo.

Step two, in your plugins directory, do the SVN Properties thing again, and this time, add this as an svn:externals of
akismet http://plugins.svn.wordpress.org/akismet/trunk/” to get the akismet trunk.

Step three, commit and update again, and voila, now you have Akismet.

But wait, we might want more than one plugin. Well, we can do that too. Let’s add the stats plugin.

Step one, go back to the SVN->Properties of the plugins directory.

Step two, edit the existing svn:externals setting. This time, we’re going to add “stats http://plugins.svn.wordpress.org/stats/branches/1.8/” on a new line. Basically, you can have as many externals you want, just be sure to put each one on a new line.

Step three, commit and update and it’ll download the stats plugin.

Repeat for all the plugins you want to keep up-to-date.

You’ll note that I used a branch of the stats plugin instead of the trunk. That’s because the trunk isn’t the latest version in the case of the stats plugin. Not every plugin author treats the trunk/tag/branch system the same, so you should investigate each plugin and see how they keep things up-to-date with their setup.

Theme note

Note that I am using a wholly custom theme, but you might not be. Maybe you’re using a child theme of twentyten. Themes exist inside an SVN too, and you can create externals to them in the same way.

For example, in the themes directory, you could set svn:externals to  “twentyten http://themes.svn.wordpress.org/twentyten/1.1/” and get the twentyten theme for use. Any theme in the Themes directory should be available in this way.

Custom wp-config.php

Now we need to create our wp-config.php file. Grab a copy of the sample wp-config file and put it in the root. Yes, not in the wp directory. WordPress looks in both its own directory and in one directory above it, so having it in the root will still allow it to work and will keep the wp directory untouched.

Edit the file, and go ahead and add all the database details. Then add these lines:

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/custom-content' );
define( 'WP_CONTENT_URL', 'http://example.com/custom-content');

You’ll need to use your own directory names and URL, of course. The purpose here is to tell WordPress that the wp-content directory isn’t the one to use anymore, but to use your custom content directory instead.

Special .htaccess

Because we’ve installed wp in a subdirectory off of what will be the root of the site, it would normally be referenced as http://example.com/wp/ which is undesirable. So I crafted some simple .htaccess rules to move the “root” of the site into the /wp directory, and still have everything work.

Options -Indexes
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteCond %{REQUEST_URI} !^/wp/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wp/$1
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteRule ^(/)?$ wp/index.php [L]

The Options -Indexes just turns off the normal Apache directory indexing. I don’t like it when people try to look through my files. 🙂

The rest basically rewrites any URLs for directories or files that don’t exist into calls to the /wp directory, without actually modifying the URL. The rewrite is internal, so the URL remains the same. This has the effect of moving the root to the /wp directory, but still allowing calls to the custom content directory to serve the right files.

After you’re done, save the file, and commit everything you’ve done so far.

Running it on the site

At this point, you should be capable of going to the site and loading up all that you’ve done onto it. So SSH in (or whatever) and do a checkout of your new SVN setup into the proper location for it. You may need to rename your existing public_html directory and/or set proper permissions on it and such.

If you’re setting up a new site, you’ll be able to go to it and have it create the database tables and such as well.

What’s the point?

Okay, so you may have read through all this and wondered what the point was. Well, it’s simple, really.

Go to your server, and do “svn up public_html”… and then watch as it proceeds to update the entire site. WordPress, plugins, themes, your custom files, everything on the site. The externals makes WordPress and the plugins and such all update directly from the WordPress SVN systems, allowing you to do one command to update them all.

If you didn’t use trunk, then updating is only slightly harder. Basically, you just change the externals to point to the new version, then commit and do an svn up.

In fact, if you want to live dangerously, you can hook everything to trunk and then have it automatically do an svn up every night. Not many people recommend running production sites on trunk, but for your own personal site, why not? You’ll always get access to the latest features. 🙂

An additional thing to keep in mind is that with a system like this, the files on the site are always backed up on the SVN server. For things like inline file uploads, you’ll need to log in every once in a while and do “svn add” and “svn commit” to send the new files to the SVN server, but for the most part, everything on the site will be in your SVN and you can work with it locally before sending it to the site proper.

And it’s expandable too. You can get your sites files from any host that has svn on it. You could run more than one webserver, and have them on a rotation or something. There’s a lot of possible configuration methods here.

It sure is a nice way to update though. 😀

Shortlink:

Saw this post about Chrome voice searching in HTML forms on Google’s blog today. Very cool, so I had to give it a try. If you check the “Search” box in the upper right corner of the page, you’ll see a little icon (if you’re using a dev version of Chrome). Click it to do a search-by-voice.

What I didn’t expect was how totally easy it is to implement. Seriously, it’s less than a line of code.

Example. Say your search box (possibly in your theme’s searchform.php file) looks like this:

<form id="searchform" action="<?php bloginfo('home'); ?>/" method="get">
<input id="s" name="s" size="20" type="text" value="<?php _e('Search') ?>..." />
</form>

All you have to do is to add some bits to the input element box. Specifically, you add x-webkit-speech speech onwebkitspeechchange=”this.form.submit();”. That’s it. Seriously:

<form id="searchform" action="<?php bloginfo('home'); ?>/" method="get">
<input id="s" name="s" size="20" type="text" value="<?php _e('Search') ?>..." x-webkit-speech speech onwebkitspeechchange="this.form.submit();" />
</form>

Note that this won’t validate, if you care about that sort of thing. Works fine though.

You can do a whole lot more with Javascript and events and translations and multiple choices and such, if you’re thinking of developing something cool with it. I’m just shocked and amazed that this is already in my browser and I had no idea it was there. Very cool.

Shortlink: