Otto on WordPress

One of the things that changes in WP 3.0 with multi-site is where file uploads and attachments get stored. This can be confusing to people trying to do export/imports and combine sites together.

In the .htaccess file of a multisite installation, you’ll find this little bit of code:

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

The effect of this code is to redirect requests that have “files” in the name to the ms-files.php. As you may have guessed, ms-files.php is the multi-site file handler.

Files in multi-site mode are stored in the /wp-content/blogs.dir structure. Inside that directory, you will find subdirectories labeled with numbers (1, 2, 3, etc.).  Each number corresponds to the ID number of the individual site in the multi-site installation. Each one of these directories holds all the uploaded files for that installation. The ms-files.php file handles a bunch of caching parameters and then sends the file off to the browser upon request.

So the resulting URLs always look like http://example.com/files/2010/whatever.jpg and so forth. The “files” name is therefore special and reserved and cannot be used as a post slug and such.

When you export a site from somewhere and then import it into your new multi-site system, if you also choose to import the attachments, then you’ll have a minor problem. The attachments will be imported into this new files structure. However, the links from an older system are still referring to the old /wp-content/uploads/ directory structure that non-multi-site installs use. Therefore, you will need to go back through your posts and fix all these links and references to the attachments. I use the Search Regex plugin for this purpose, it works well enough and has some powerful search and replace capabilities.

I am making a theme today and working on the image attachment templates. I found that I needed the next and previous image links (in the single image templates… image.php) to be of a specific size, regardless of what the settings the admin tool were. Specifically, I want them to always be 100×100 pixels in size, and cropped.

Image sizing is always a problem for themes. Theme designers want their theme to be pixel perfect in all cases, but WordPress wants the user to have some form of control. With image sizes, WordPress lets the user pick the size of their image thumbnails and so forth. In that case, using those becomes problematic for certain places in the theme which need pre-defined image sizes.

Here’s the quick and easy solution: add_image_size. This function lets you create custom image sizes that can be used by your theme. Plugins can do the same sort of things, of course, but this really comes in more useful as a theme developer’s tool.

In my functions.php file, I put this code:

add_image_size( 'themename-nav-thumbnail', 100, 100, true );

That creates a new image size for WordPress. When image files get uploaded, that new image size will be magically created along with all the other sizes. In this case, it’ll be 100 by 100 pixels, and cropped exactly to that (that’s what the “true” means).

Note the use of the “themename” prefix? You can use anything you like here, actually, but it’s a good habit to always use prefixes for custom identifiers you ever make. This prevents things from interfering with each other.

Anyway, to then use that size for my navigational thumbnails, this small bit of code works:

<div class="prev-img">
<?php echo previous_image_link('themename-nav-thumbnail'); ?>
</div>
<div class="next-img">
<?php echo next_image_link('themename-nav-thumbnail'); ?>
</div>

I wrapped them in DIVs so that I can float them left and right and style them and such.

So custom image sizes are easy enough to do, but it’s a trick I didn’t know about until I needed it just now. Thought somebody else should know about it too.

I found a really stupid mistake in the STC-Publish plugin this morning, so I went ahead and pushed the fix and all the other changes out as well. Here’s a quick rundown of the new features:

• STC-Publish now doesn’t have that weird case where it posts to Twitter without the shortlink.
• Followers Widget is available. This shows a random selection your followers on Twitter. In order to use it, you have to have the “AutoTweet” user set using the publish plugin, so it knows which user to look at. You don’t actually have to use AutoTweeting though, just have it set to a user. Also, this widget is unstyled, so you’ll have to add styling for it to your theme to make it not look terrible. There’s a sample set of styling rules at the top of the plugin code. Only advanced users should probably use this widget.
• The Follow widget now has a shortcode for use in posts. Just put (tweetfollow user=”username”) to put a follow button into a post. There’s also the stc_follow_button() function for advanced users who want to integrate it into their theme.
• If you have a Multi-Site configuration set up and you want all your sites to use it, then you can define the STC_CONSUMER_KEY and/or STC_CONSUMER_SECRET in your wp-config file.
• John Bloch sent me a Dashboard widget for Tweeting. After suitable modification, it’s in there too.
• The Tweet boxes in the Publish widget and the Dashboard widget now use javascript to resize themselves to the correct sizes.

So there you go. Enjoy!

Tried to install a local Apache this morning and couldn’t get it to start. Turned out Skype was the problem. Matt apparently encountered this years ago, but I never really started using Skype until lately.

Anyway, it still happens. But there’s a simple fix.

Go to the Tools->Options menu. In there, find the Advanced->Connections tab. Turn off the option to use port 80 and 443. These are there to allow Skype to try to get through firewalls. They also, incidentally, block Apache from starting since it can’t grab the port it wants.

Just a heads up in case anybody else encounters the problem.

The other day, Klint Finley wrote a very good walkthrough of using the new Multisite functionality of WordPress 3.0. In the comments, a lot of people wanted to know how to use your own domain names. Since I’m doing that now, here’s a quick walkthrough/how-to guide.

Step 1: Manual Plugin Installation

The Domain Mapping plugin is not your regular kind of plugin. You cannot install it through the normal Plugins->Add New menu. Well, actually, you can, it just won’t work.

So first, download the plugin manually.

Note: For this tutorial, I will be using the WordPress MU Domain Mapping plugin. However, I am using the trunk version of the plugin. It has fixes in it that you will need for proper 3.0 support. Don’t try it with the regular version.

The plugin has two main files you need to put in the proper places.

Domain mapping php file location

The first file is the domain_mapping.php file. This needs to go into the mu-plugins folder. The mu-plugins folder is a special folder, which you may not even have yet. Just create it underneath the wp-content folder and put that file into it.

Sunrise php file location

The second file is the sunrise.php file. This is a special filename for WordPress. Don’t worry about it, just put it in the wp-content folder.

Step 2: Activate Sunrise

Now you need to edit your wp-config.php file. Add this line of code to it:

define( 'SUNRISE', 'on' );

Simple, really. This will cause WordPress to go load that sunrise.php file and use it.

Step 3: Server info

Now you have to configure the domain mapping plugin so that it knows what it’s doing properly. This is easy to do, really. Go to your main domain’s admin page and log in as a super admin. Then go to the new Super Admin->Domain Mapping menu.

Domain mapping setup screen

Here you have a few different options, but two main ones that count. You can either put in the IP address of your server (as defined in your domain’s main A record) or you can put in a CNAME that points to your server. The IP address is what most people will want to use. If your server uses more than one, you can enter them all here, separated by commas.

Other options on this page:

• Remote Login – This will make your login pages for all sites redirect to your main site to do the actual login. The benefit of this is that when you log in to one, you log into all of them. The downside is that the URL changes to another domain in order to log in.
• Permanent redirect (better for your blogger’s pagerank) – This makes your subdomain or subdirectory sites redirect to their domains. You should leave this on.
• User domain mapping page – Turn this on if you want users to be able to put in their own domains for mapping.
• Redirect administration pages to blog’s original domain (remote login disabled if redirect disabled) – This makes all admin pages show up on the original domain instead of on the new domains. You need this enabled for remote login to work.

Generally I leave only the middle two on. Remote-login is iffy at best, and I want my new domain name to show up everywhere.

Step 4: Mapping the Domain

There’s a bit of a prerequisite here before you do this. When you buy a new domain, you will need to edit its DNS settings to actually point to your server IP or CNAME or whatever you do to make the domain connect to your server. For me, I just give it a new A record with my server IP in it. Easy.

Update: Okay, so there may be more to it than just that, depending on your host. Every host is different, and you’ll have to talk to your host to make them able to point the domain name at your existing site. How to do this varies from host to host, but the important thing is that when you visit your new domain (before you do this!) then you want it to go to your main site, as is.

There’s two ways you can actually map a domain to one of your sites. The user screen is the simplest way, if you left that option on before. Log into the site you actually want to map to a new domain, then go to Tools->Domain Mapping.

User Domain Mapping Screen

All you really do is put in a new domain and set it as the primary. Simple.

Note that if you didn’t get the domain pointed at your server before doing this, then your site will instantly vanish from the realm of mortal man. Setting the primary domain takes effect instantly. You won’t be able to access the site through the old domain any more.

The other way to set domain mapping is through the Super Admin->Domains menu. Here you’ll find a list of sites and their ID numbers. You can map an id number directly to a domain name here. The Tools approach is a bit easier to use, but this will allow you to map domains without visiting them, as you can access this list from your main domain. You can also correct broken domain mappings from here.

Step 5: Seeing the Mapped Domains

If you go to Super Admin->Sites, you’ll find this type of a listing:

Sites listing

You’ll note that on the right hand side you can see the column showing the mapped domains.

Special Note: See in the picture how I’m using a subdirectory install? That’s relatively new. In older versions of the domain mapping system, you had to use a subdomain installation and wildcard DNS for domain mapping to work. This is no longer the case, domain mapping works just fine with subdirectories.

Conclusion

And that’s how it’s done. It’s not super complex, but it does require some knowledge of DNS and how servers work. If you can successfully set up a multi-site install to begin with, you can probably do this as well. Just be aware that it is slightly finicky, and know that you will break your site if you put in the wrong settings somewhere. However, your main domain will always be accessible as long as you don’t try to map it, so you’ll be able to go in from there to correct your mistakes.

Been getting a lot more of these sorts of problems cropping up in my email recently, so I figured I’d repost this in the hope that people will read it. The original post is now on the wrong site, so maybe here it’ll get more views.

—

The majority of the email I get from users of the Simple Facebook Connect plugin is questions regarding how to setup their Facebook Application. It’s really not that hard to do, but the plethora of options can seem somewhat intimidating. So here’s the basics of what you need to do.

After creating your application, you’ll need to visit the Apps section in the Facebook Developer Home area. Here you’ll find your application, and the all critical “Edit Settings” link.

Firstly, never give out your Application Secret. If you give this out by accident, then use the Reset Secret Key link to get a new one.

Anyway, from here, you want to go into the settings. The settings area is divided into six main sections, but most of the settings are irrelevant. See, you’re building a “Connect” application, not a “Canvas” one. So most of these are meaningless for you. The following ones are what you actually care about:

Obviously, you want the name of your Application to make sense. I suggest using the same name as your website. You can even use your domain name here if you like. Just be aware that this name is what the Fans of your site will see in their Applications area.

The Basic Information section is important as well, fill it in as you see fit. I also recommend uploading good icons and/or logos for your site. Gives it that finished look.

Contact Information is obviously important as well, but don’t worry about all those extra URLs. They really apply more to Canvas apps. Of course, if you want to make special pages on your site for them and provide the URLs here, feel free.

The Authentication Settings page is surprisingly important. Those top two boxes need to be unchecked for a Facebook Connect application. Why? Because when they are unchecked, your Application becomes an “External Website” as far as Facebook is concerned. If you have either them checked, then your app’s Canvas section becomes active and you might have users trying to add it to their profiles and such, resulting in broken pages and a general bad user experience.

The Connect Settings page is probably the most important one. These settings must be filled in and they must be absolutely accurate. Specifically, the URLs must be the URLs that are actually used by your site. Capitalization matters. The leading “www” or lack of one matters. Whatever the URL your site is in the browser is what you MUST put into these fields. Anything less and your site will not work.

The Advanced Settings screen contains these three fields which you need to set in the same way I did. The email domain no longer exists, however. They removed that in favor of a different approach, so you can ignore that field.

Finally, after you have saved those settings, take the time to go back to the main application screen and click the “Edit Application Profile” link. You’ll be taken here, where you can set up the “look” of your application page on Facebook. This includes what tabs are visible, the stuff in the Info section, etc. You can add extra Applications tabs to this page and generally customize all sorts of stuff. None of that affects your site, but it does affect how the App Page looks in Facebook. The more polished it is, the more likely people will “Fan” your Application. And Fans get updates from when you publish posts to the Wall. Great way to drive traffic to your content.

Hope this helps! Mainly, I hope this reduces the number of questions I get about this process. Enjoy SFC!

There’s been a lot of talk about custom post types, and I know many people are looking forward to it. Unfortunately, I think some (perhaps many) of those people are going to be disappointed. Custom Post Types might not be what you think they are.

I blame the naming, really. “Custom Post Types” makes the implication that these are “Posts”. They’re not. “Post Type” is really referring to the internal structure of WordPress. See, all the main content in WordPress is stored in a table called “wp_posts”. It has a post_type column, and until now, that column has had two main values in it: “post” and “page”. And there’s the big secret:

“Custom Post Types” are really Pages.

Sorta.

For a long time in the early days of WordPress, it just had Posts. But hey, no big deal, because it was just running a big Blog anyway, right? The Posts appeared on the Blog page (and in the Feed) in reverse chronological order. Each Post could appear on its own URL, using the Permalink structure.

Pages came along and changed that.

• Pages don’t appear on the Blog. Or in the Feed.
• Pages don’t even really have dates and times on them that usually get displayed.
• Pages have their own URL at the root of the website, outside the Permalink rules.
• Pages even have hierarchy in their URLs, if they want.

Pages, however, do live in the wp_posts table. So post_type exists to handle that. When WordPress is building the Blog, it looks for post_type = “post”.

Bring on the “Custom”.

Now we have these Custom Post Types. Or rather, custom post_types. Instead of “page” or “post”, we can have “custom”. Or “fred”. Whatever we like.

But how do these new post types get displayed? What do their URLs look like?

Well, these are custom, and they can be customized. You can give them their own space on the website. So if I want them to live at /custom/page-name, then I can. If I want them to have hierarchy, then I can do so. Justin Tadlock explains how they can be made to do this quite well.

But they are still not Posts.
They do not show up on the Blog.
They do not appear in the Feed.

This is a matter of definitions, really. See, the Blog is a reverse chronological order of the Posts. That it what it is defined to be. The Feed is basically the same thing, in feed form.

So all of you thinking of a custom “Podcast” post type, you’re in for a disappointment.

So what’s the big deal?

Well, all that said, custom types can have their own systems of doing things. They are custom, and as such, they are customizable.

If, for example, you wanted to have them appear on their own “blog” area, or in their own “feed”, then sure, that’s entirely doable. You can make a function to produce your custom feed. You can then call “add_feed” to add your feed. You can create single-type.php templates in your theme that will be used for your custom type. You could even make a “blog” out of your custom type.

And doing it the other way is possible too. You can adjust the “Blog” to show your type. You could change the “Feed” to show your type as well.

But these things are NOT the default way of doing things. There’s no code in there to do that, and there’s very likely not going to be. If you want your type in the Blog, in the Feed, then you have to do it yourself. The URL is NOT easy to customize and play around with. The rewrite system is unforgiving, and you have to stick within a set of rules for things to work well.

However, should you? Let’s say you make a “Podcast” custom type. You can go to the effort of putting them in the feeds and making them show special on the blog… but you could already do that with a “podcast” category. And it’s much easier to do a category and customize categories than custom types will ever be.

Something like 80% of the uses I’ve seen for “custom types” would be better served by making normal posts and using some existing method to separate them or to otherwise mark them as special.

So what are they good for?

What if you could install a forum on your site? bbPress is pretty good. But it could get all complicated to set up and such. Well, plugins are pretty easy. But all those forum posts have to go somewhere…

Custom Post Types is a way for plugins to define types of content for themselves.

A bbPress forum could store every post in the forum as its own custom post type quite easily.Or a wiki plugin could store each of its own pages as a custom post type. Things like that.

See, they’d get their own URL handling automatically, and they wouldn’t need weird database handling tricks.. It makes things much simpler and easier for those plugins to do their thing when they have the backend support for it in the core.

Some of you are thinking “Okay, so plugin authors can make better use of them. I won’t have to write a lick of code, I’ll just install a plugin that makes my type and handles the stuff for me.” And yeah, you can do that.

But then you’re wedded to that plugin. WordPress doesn’t know about your custom posts. If you remove the plugin, your custom posts are still there, but now they’re completely invisible. Can’t be pulled up, seen in the admin, the URLs all stop working…

Wrap it up, son…

Using custom post types right now is, for most people, a bad idea. Only specialized usages really exist for them… for now.

For the long term, WordPress will probably use them a lot more extensively. And plugins can make great use of them for all sorts of things. But you, as a user, probably don’t need to be messing with them. Not if you’re just creating a website or writing a blog. Not right now. Wait for the plugin and core development to catch up to the potential. Using them early leaves you open for a world of confusion and grief.

WordPress 3.0 has something very handy that I want theme authors to start implementing as soon as possible.

To show exactly why it’s so useful, I modified my own theme to start using it.

Demonstration

So, here’s a big hunk of code I pulled out of my current theme’s comments.php. This hunk of code has only one purpose: To display the form area where people can leave a comment:

<?php if ('open' == $post->comment_status) : ?>

<div id="respond">

<h3><?php comment_form_title( 'Leave a Reply', 'Leave a Reply to %s' ); ?></h3>

<div class="cancel-comment-reply">
	<small><?php cancel_comment_reply_link(); ?></small>
</div>

<?php if ( get_option('comment_registration') && !$user_ID ) : ?>
<p>You must be <a href="<?php echo get_option('siteurl'); ?>/wp-login.php?redirect_to=<?php echo urlencode(get_permalink()); ?>">logged in</a> to post a comment.</p>
<?php else : ?>

<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform">

<?php if ( $user_ID ) : ?>

<p>Logged in as <a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php"><?php echo $user_identity; ?></a>. <a href="<?php echo wp_logout_url(get_permalink()); ?>" title="Log out of this account">Log out &raquo;</a></p>

<?php else : ?>

<p><input type="text" name="author" id="author" value="<?php echo $comment_author; ?>" size="22" tabindex="1" />
<label for="author"><small>Name <?php if ($req) echo "(required)"; ?></small></label></p>

<p><input type="text" name="email" id="email" value="<?php echo $comment_author_email; ?>" size="22" tabindex="2" />
<label for="email"><small>Mail (will not be published) <?php if ($req) echo "(required)"; ?></small></label></p>

<p><input type="text" name="url" id="url" value="<?php echo $comment_author_url; ?>" size="22" tabindex="3" />
<label for="url"><small>Website</small></label></p>

<?php endif; ?>

<!--<p><small><strong>XHTML:</strong> You can use these tags: <code><?php echo allowed_tags(); ?></code></small></p>-->

<p><textarea name="comment" id="comment" cols="100%" rows="10" tabindex="4"></textarea></p>

<p><input name="submit" type="submit" id="submit" tabindex="5" value="Submit Comment" />
<?php comment_id_fields(); ?>
</p>
<?php do_action('comment_form', $post->ID); ?>

</form>

<?php endif; // If registration required and not logged in ?>
</div>
<?php endif; // if you delete this the sky will fall on your head ?>

Nasty, eh? It’s a mess of if/else statements. It handles cases where the user is logged in or not, where the comments are open or closed, whether registration is required, etc. It’s confusing, difficult to modify, poor for CSS referencing…

Here’s what I replaced all that code with:

<?php comment_form(); ?>

Now then, that’s much better, isn’t it?

The comment_form function is new to 3.0. Basically, it standardizes the comments form. It makes it wonderful for us plugin authors, since now we can easily modify the comments form with various hooks and things. I’ve already modified Simple Facebook Connect and Simple Twitter Connect to support this new approach; if you’re using a theme with this, then the user won’t have to modify it to have their buttons appear on the comments form.

Customizing

Since theme authors love to customize things, the comments form is also extremely customizable. Doing it, however, can be slightly confusing.

Inside the comments_form function, we find some useful hooks to let us change things around.

The first hook is comment_form_default_fields. This lets us modify the three main fields: author, email, and website. It’s a filter, so we can change things as they pass through it. The fields are stored in an array which contains the html that is output. So it looks sorta like this:

array(
	'author' => '<p class="comment-form-author">...',
	'email'  => '<p class="comment-form-email">...',
	'url'    => '<p class="comment-form-url">...'
);

I truncated it for simplicity. But what this means is that code like this can modify the fields:

function my_fields($fields) {
$fields['new'] = '<p>Some new input field here</p>';
return $fields;
}
add_filter('comment_form_default_fields','my_fields');

That sort of thing lets us add a new input field, or modify the existing ones, etc…

But fields aren’t the only thing we can change. There’s a comment_form_defaults filter too. It gets a lot of the surrounding text of the comments form. The defaults look sorta like this:

$defaults = array(
	'fields'               => apply_filters( 'comment_form_default_fields', $fields ),
	'comment_field'        => '<p class="comment-form-comment">...',
	'must_log_in'          => '<p class="must-log-in">...',
	'logged_in_as'         => '<p class="logged-in-as">...',
	'comment_notes_before' => '<p class="comment-notes">...',
	'comment_notes_after'  => '<dl class="form-allowed-tags">...',
	'id_form'              => 'commentform',
	'id_submit'            => 'submit',
	'title_reply'          => __( 'Leave a Reply' ),
	'title_reply_to'       => __( 'Leave a Reply to %s' ),
	'cancel_reply_link'    => __( 'Cancel reply' ),
	'label_submit'         => __( 'Post Comment' ),
);

All the various pieces of html that are displayed as part of the comment form section are defined here. So those can be modified as you see fit. However, unlike the fields, adding new bits here won’t help us at all. The fields get looped through for displaying them, these are just settings that get used at various times.

But filters are not the only way to modify these. The comment_form function actually can take an array of arguments as the first parameter, and those arguments will modify the form. So if we wanted a simple change, like to change the wording of “Leave a Reply”, then we could do this:

<?php comment_form(array('title_reply'=>'Leave a Reply, Stupid')); ?>

This gives us a simple and easy way to make changes without all the trouble of filters. Nevertheless, those filters can be very useful for more complex operations.

But wait, there’s more!

As the comments form is being created, there’s a ton of action hooks being called, at every stage. So if you want to insert something into the form itself, there’s easy ways to do it.

A quick list of the action hooks. Most of them are self-explanatory.

• comment_form_before
• comment_form_must_log_in_after
• comment_form_top
• comment_form_logged_in_after
• comment_notes_before
• comment_form_before_fields
• comment_form_field_{$name} (a filter on each and every field, where {$name} is the key name of the field in the array)
• comment_form_after_fields
• comment_form_field_comment (a filter on the “comment_field” default setting, which contains the textarea for the comment)
• comment_form (action hook after the textarea, for backward compatibility mainly)
• comment_form_after
• comment_form_comments_closed

CSS and other extras

Let’s not forget styling. All parts of the comments form have nice classes and id’s and such. Take a look at the resulting HTML source and you’ll find all the styling capabilities you like. Also, everything is properly semantic, using label tags and aria-required and so forth. All the text is run through the translation system for core translations.

So theme authors should start modifying their themes to use this instead of the existing big-ugly-comment-form code. Your users will thank you for it. Plugin authors will thank you for it. And really, it’s about time we made WordPress themes more about design and less about the nuts and bolts of the programming, no?

For those of you helping me with testing out SFC trunk, there’s a new one in there for you.

The activity feed widget is one of Facebook’s recent addition to their social widgets. Basically, it shows who’s liked and shared your posts recently. The idea is to encourage liking, I suppose.

The latest plugin adds this to WordPress as a sidebar widget, as a shortcode (fb-activity), and enables it for direct theme usage with the sfc_activity_feed() function.

As always, this is trunk beta code here, so if you do use it, don’t expect it to be 100% yet. Still, it works well enough.

Get it here: http://plugins.svn.wordpress.org/simple-facebook-connect/trunk/.

I sort of snuck this into Simple Facebook Connect 0.18 for you all.

If you go to http://facebook.com/insights, then one of the new things they have is “Insights for your Domain”. Basically, this lets you hook the Facebook Insights system up to your own domain.

They give you meta info to add to your site so as to define who has control over that site. This lets them know who should be able to see the insights and such.

Well, if you use SFC, that information is already there for you. Just go over to the insights page, put in your domain, then “Link With” your SFC Application. No need to add anything else to your site, the base SFC plugin is adding that fb:app-id meta tag for you automatically (once you’ve configured SFC itself, of course).

Note that you may have to link it a few times before it actually takes. Facebook has to retrieve your webpage to verify the connection, and it seems to time out rather easily. Took me several tries and I kept getting messages like “Bad Domain” and such. But it finally worked.

Since I just added it, I don’t have any data yet to show you, but basically it will keep track of the “Shares” from your site, so those Share buttons will now give you some useful information and feedback on the Insights page.

Enjoy.

Additional: Note that since I wrote this post, Insights never actually updated or worked at all. Facebook basically dropped the ball and never actually finished this code or turned it on or something. I seriously wonder exactly WTF they are doing over there sometimes. Anyway, here’s the bug if you want to track it: http://bugs.developers.facebook.com/show_bug.cgi?id=10174