Otto on WordPress

Using the Facebook Debugger Tool

November 30, 2011, 6:27 pm

I frequently get emails from users of SFC saying that their Like/Send buttons or Publish buttons are putting in weird content, or getting the wrong images, or things like that. Many presume it to be a bug in SFC itself or some kind of plugin incompatibility. Actually, it’s neither of those. You’re running into what I call the Facebook Cache.

See, Facebook does more than simply let you send things to their pages and so forth. More and more, they’re becoming a search engine. Facebook actually crawls the web, to some degree.

When you click a Facebook Like button, Facebook’s servers retrieve the webpage you’re viewing, and parse it for the OpenGraph meta tags. These tags tell Facebook what content to display for a link. The title, the image, maybe audio or video, etc. SFC does a pretty good job of automatically populating your entire website with these OpenGraph tags, invisibly (side note, Google+ will use these same tags, although they also have their own set of tags you can use too).

Generally, users who email me about this problem are just using SFC for the first time, and have previously had Like buttons on their page manually, or have been sharing their links on Facebook manually at some other point. This is where they run into the issue: Facebook caches the results of this crawl, usually for a long time. So when somebody clicks a Like button, it doesn’t have to pull the contents of the page if it’s already pulled those contents once before. So since SFC is now populating the OpenGraph meta tags, but FB is reading the cached version instead, the data doesn’t match up.

There’s a simple one-time fix for this problem. Facebook has made an OpenGraph debugger tool:

https://developers.facebook.com/tools/debug

On this page, you’ll find a simple box asking for a URL. Put in the URL of the page having the problem, and the tool will go and force retrieve the content of the page and display the parsed OpenGraph meta tags.

Now, this is meant to be a debugging tool for people trying to add OpenGraph tags to their site, but it has a rather nice side-effect. When it forcibly retrieves the page, it also updates Facebook’s cached info for that URL. So all you have to do to make Facebook see your updated content is to take the problem URL, put it in there, and hit the Debug button. Now go back to the page, refresh it, and try the Like/Send button again. Voila, it’s magically fixed to show whatever the Debugger tool saw.

So if you’re having trouble getting some particular page to work in the way you’re expecting, try the debugger tool on the URL first.

Shortlink:

Tags: debugger, facebook, sfc, simple-facebook-connect
Category: Other | 11 Comments

Random Post snippet

October 31, 2011, 5:20 pm

Wrote this quick WordPress code snippet at WordCamp Louisville. It makes a /random/ URL on your site which redirects to a random post. Thought some people might find it useful.

Not a perfect little snippet, but gets the job done. Note the use of the little-used 307 redirect for temporary redirection. This is to make browsers not cache the results of the redirect, like some of them might do with a 302.

add_action('init','random_add_rewrite');
function random_add_rewrite() {
       global $wp;
       $wp->add_query_var('random');
       add_rewrite_rule('random/?$', 'index.php?random=1', 'top');
}

add_action('template_redirect','random_template');
function random_template() {
       if (get_query_var('random') == 1) {
               $posts = get_posts('post_type=post&orderby=rand&numberposts=1');
               foreach($posts as $post) {
                       $link = get_permalink($post);
               }
               wp_redirect($link,307);
               exit;
       }
}

There’s plugins that do this sort of thing too, but this is such a simple little thing that it doesn’t really need a big amount of code to do.

Edit: Added get_permalink() optimization from @Raherian.

Shortlink:

Tags: post, random, snippet, WordPress
Category: Code, WordPress | 16 Comments

Creating a Site-Specific Snippets Plugin

October 16, 2011, 5:43 pm

If you read “how-to” stuff for WordPress sites around the web, then you frequently run across what many people like to call “snippets”. Short bits of code or functions to do various things. I myself post snippets frequently, usually made up on the fly to solve somebody’s specific problem.

One question I get a fair amount is “where do I add this code?”

The usual answer to this for a lot of people is “in the theme’s functions.php file”. This is a quick solution, but it is often a problematic one.

The reason this has become the more or less go-to place to add these snippets is because it’s complicated to explain to a newbie how to make a plugin and activate it, or to point out the problems with modifying core code, or plugin code. Saying to look for a specific file in their theme, on the other hand, is quick and easy, and until recently theme upgrades have been fairly rare.

However, as themes get upgrades, it becomes more and more incorrect to tell people to modify them directly. And telling people how to create child themes is complex, even if it’s easy to do.

So I’d like to start a new trend, and recommend that people start making Site-Specific Plugins. Most people who run WP sites on a serious level do this in some way already, but if you make it sorta-standard practice, then it’ll make things simpler all around.

How to create a Site-Specific Plugin

1. Create a new directory in the plugins directory. Name it after the site in some fashion. For example, /wp-content/plugins/example.com or something like that.

2. Create a new php file in that directory. Name is dealer’s choice.

3. Put this in the file:

<?php
/*
Plugin Name: Site Plugin for example.com
Description: Site specific code changes for example.com
*/

4. Finally, go activate your new blank plugin on the site.

Now you have a simple and specific place to add snippets. It will survive upgrades of any sort, and you can edit it to add new code on an as needed basis. What’s more, it’s kinda sorta break-proof. If the user uses the built-in plugin editor to edit it, and they add code that breaks the site, then the editor detects that on saving the code and deactivates the plugin, preventing the “white screen of death” for their site.

This is a much better way to use “snippets” than the theme’s functions.php file, and we should really use it more often in our replies to users.

Shortlink:

Tags: plugin, snippets, themes, upgrades, WordPress
Category: Other, WordPress | 33 Comments

Migrated to DreamHost

October 11, 2011, 7:42 pm

If you’re seeing this, then my site has been migrated to DreamHost.

Note that while I set things up, I fully expect the site to break from time to time. So… gimme time to get it working properly.

TODO Step 2: Switch to nginx. 🙂

Shortlink:

Category: Other | 9 Comments

Quick fix for people having SFC problems

October 8, 2011, 4:03 pm

Didn’t know about this one, but if you’re having a problem where the FB login buttons added by SFC don’t seem to do anything, try this:

Go to https://developers.facebook.com/apps/ and click on the App in question.
In the left menu, under Settings, click Advanced and look at the settings in the Migrations section.
Switch the “Encrypted Access Token” setting to ‘Enabled’.

Might fix the issue.

Shortlink:

Tags: oauth, sfc
Category: Code | 12 Comments

GoDaddy Hosting = Epic Failure. Looking for a new hosting service.

October 8, 2011, 12:43 pm

I’ve been hosting my sites on GoDaddy for years, despite everybody saying that they suck and so forth. I’ve even defended them. Their interface is crap, but it’s not terrible once you get used to it. It works well enough. Their shared servers are indeed overloaded, but with a little super-caching they tended to work alright. Their new cloud hosting service is definitely faster.

But if there’s one thing I can not stand, it’s censorship.

I recently discovered that a couple of old posts of mine about decoding code used by hackers were no longer loading up. Everything else worked, but not those posts. I couldn’t even pull them up in the WordPress post editor.

After some trial and error and back and forth, I discovered that any HTTP or FTP request that contains the string “eval(base 64_decode(” or similar variants, is blocked. FTP just stops dead, as does HTTP requests, with a continual spinning loading icon. Apparently they have some form of filtering in the TCP stack somewhere that just stops those connections dead in their tracks.

(BTW, the irony here is thick. GoDaddy’s malicious code scanner was blocking my “Scanning for Malicious Code is Pointless” post.)

GoDaddy… guys, I loved your service in the past, but I have to tell you that this is a *shit* approach to security.

After some tweeting back and forth, I found out from the horse’s mouth that this is intentional and cannot be disabled.

@otto42 Ya we keep that disabled for security purposes. Sorry for any inconvenience this may cause. ^C

— Go Daddy (@GoDaddy) October 8, 2011

@otto42 At this time you can’t disable it on our shared environments. You can on our Vded and Dedicated servers. ^C

— Go Daddy (@GoDaddy) October 8, 2011

And as much as they’d like to claim this isn’t censorship:

@otto42 @heykatieben We aren’t censoring posts, the issue is that you are running into a technical limitation of our shared environment.

— Go Daddy (@GoDaddy) October 8, 2011

Guys, you’re wrong. It is censorship. I wrote that post content, and they’re refusing to serve it over HTTP. You can spin that any way you like, but GoDaddy hosting is now censoring me.

What’s more, this is a *new* problem. Those posts worked fine when I wrote them. What changed? I dunno. I did move to their 4GH hosting, but nowhere did I see in the documentation that they would be intentionally blocking my content.

Anyway, I’ve worked around the problem for now with a plugin to add spaces to the proper places in my HTML content, thus bypassing their filter. However, in the long run, this will not stand. GoDaddy thinks it’s okay to block my personal content. I disagree with them, and no amount of argument is going to make me change my mind on this topic. Blocking my own content from being served is NOT a security measure.

As you might be able to tell, I’m a bit angry.

Therefore, I am now looking for a new hosting service. Some requirements of mine:

Traffic-wise I serve about 6000 page views a day, all told. In terms of total HTTP requests, I’d say somewhere around 30,000 or so.
Bandwidth tends to be in the 1.5 GB per day range. So, 50 GB per month, say.
Obviously, any form of censorship or technical limitations is unacceptable.
SSH access is a must-have.
I don’t necessarily need dedicated hosting or virtual dedicated hosting, shared is fine if it can handle it.
Speed would be nice. GoDaddy has always sucked in terms of time-to-first-byte. Their cloud hosting made it better, but not great.
MySQL Databases. I need at least 10 of them.

So, not too heavy requirements, I’d say.

I’ve heard suggestions for DreamHost in the past, and A Small Orange has always gotten favorable reviews from people I’ve talked to, but what the heck, might as well solicit the opinions of the internets in general, yeah?

Suggestions are happily accepted. If you can provide estimated pricing or links, I’d love to take a look at them. 🙂

Shortlink:

Tags: godaddy, hosting, sucks
Category: Other, Rants | 62 Comments

New in WordPress 3.3: More Useful Help Screens

October 6, 2011, 4:18 pm

Note: Post has been updated for 3.3 beta 2

WordPress plugin and theme authors could get something interesting in WordPress 3.3: a somewhat more comprehensive help screen system.

This is actually just a small part of a more long term makeover involving unifying the admin screen code base, but it’s pretty cool nevertheless. Backward compatibility is sorta fuzzy on parts of it at the moment, but not a lot of authors used these functions previously anyway, from what I can tell.

Anyway, I spent an entertaining half hour reworking the help dropdown for my SFC plugin. Here’s what it looks like in 3.3-aortic-dissection right now (note that the look and feel of this will probably change before final):

SFC Help screen in WordPress 3.3

As you can see, the dropdown Help menu moved into the Admin bar (along with lots of other stuff), and has some tabs on the left hand side where you can make different topics and such for different parts of the plugin.

The code for this is actually fairly straightforward, albeit in a sideways sort of way…

First we have to look at the code that adds my options page in the first place. This would work with any of the add_*_page functions, so add_theme_page and such works fine too.

add_action('admin_menu', 'sfc_admin_add_page');
function sfc_admin_add_page() {
	global $sfc_options_page;
	$sfc_options_page = add_options_page(__('Simple Facebook Connect', 'sfc'), __('Simple Facebook Connect', 'sfc'), 'manage_options', 'sfc', 'sfc_options_page');
	add_action("load-$sfc_options_page", 'sfc_plugin_help');
}

This makes an options page, and then uses the assigned identifier for that page to hook the load-* action. This means that when our page is loaded, the sfc_plugin_help function will get called.

function sfc_plugin_help() {
	global $sfc_options_page;
	$screen = get_current_screen();
	if ($screen->id != $sfc_options_page)
		return;

Here, we call get_current_screen() to get the current WP_Screen object. The WP_Screen object is new to 3.3, but essentially it encapsulates an admin screen. It’s still under active development, but in the long run, it may make the task of creating admin screens much, much easier.

Anyway, right away, I do one thing and that is to check if the ID of the current screen matches the ID I was given for my options page. If it doesn’t match, then the user isn’t on my screen, and so I return having done nothing at all. This is a sort of belt and suspenders approach, since we shouldn’t be here if load-$sfc_options_page didn’t get called, but it never hurts to be sure.

The next bit is where I add my help screens. Here’s an incomplete sample of that code:

$screen->add_help_tab( array(
	'id'      => 'sfc-base',
	'title'   => __('Connecting to Facebook', 'sfc'),
	'content' => "HTML for help content",
));

$screen->add_help_tab( array(
	'id'      => 'sfc-modules',
	'title'   => __('SFC Modules', 'sfc'),
	'content' => "HTML for help content",
));

$screen->add_help_tab( array(
	'id'      => 'sfc-login',
	'title'   => __('Login and Register', 'sfc'),
	'content' => "HTML for help content",
));

I removed the content for each one to make it clearer. Essentially, I’m just calling the object’s add_help_tab function to add my new tabs to the help screen, one by one. Simple, right?

There’s other useful bits in WP_Screen too, such as adding screen options, adding a right hand side sidebar to the help dropdown, and so forth. I haven’t figured out a use for them yet, but they’re still nice to see.

If you have a complex plugin or theme, might be worth looking into this now. Might reduce your need for end-user support. Maybe. Hard to say. People rarely look at the documentation, but inline help might be worth a shot.

Shortlink:

Tags: 3.3, contextual, dropdown, future, help, WordPress
Category: WordPress | 25 Comments

Customizing WordPress Images with a Plugin: ImageFX

October 4, 2011, 8:12 pm

My post about how to customize WordPress images with tricks like greyscale and such got me lots of feedback, so I figured I might as well turn it into a plugin.

The ImageFX plugin allows you to customize the image sizes from WordPress or custom ones for your theme, by applying filters to them.

The way it works is basically identical to my original post on the topic, only it allows the filters to be defined on a per-image-size level. It also allows the addition of a “slug” to be appended to the image filename, which is useful for cases where you want to have two images at the same size, but with different filters.

Since it was easy to do, I went ahead and created several other simple image filters that you can use for your images:

Greyscale (black and white)
Sepia tone (old-timey!)
Colorize with red, yellow, green, blue, or purple
Photonegative
Emboss
Brighten
Greyscale except red, green, or blue (classy!)

Here’s some examples. This a pic of me, Nacin, Rose, and Matt at WordCamp San Francisco. I ran it through the sepia, blue colorize, and grey-except-red filters.

These are some of the default filters included, but since I could, I went ahead and made it easily expandable too. All you have to do to define a filter is to create a function to do the image filtering you want, then call the imagefx_register_filter() function to add it.

To implement your own custom filter, you can do it like this:

imagefx_register_filter('custom-name','my_custom_filter');
function my_custom_filter(&$image) {
 // modify the $image here as you see fit
}

Note that the $image is passed by reference, so you don’t have to return it. This is because the $image resource takes up a lot of memory, so to save on memory usage, you are manipulating it in place, sort of thing.

You can use any of the image functions in PHP to change the image however you like. The filters I’ve implemented are mostly pretty simple. You can see them all in the filters.php file, in the plugin.

Caveats: The plugin will only filter JPG images, to avoid the overhead of recompressing PNGs and to avoid breaking animated GIF files. Also note that I haven’t tested these filters extensively. They’re only a starting point, sort of thing. I spent all of about 20 minutes writing them, so don’t expect miracles. 🙂

You can download version 0.1 of the plugin from the WordPress plugin directory: http://wordpress.org/extend/plugins/imagefx/

Enjoy!

Shortlink:

Tags: filter, gd, greyscale, image, imagefx, manipulation, photos, PHP, plugin, sepia, WordPress
Category: Code, Other | 31 Comments

SFC will NOT require you to use HTTPS

September 27, 2011, 6:13 pm

Seen this a couple of times on various sites and had a couple people ask me on Twitter about it.

Starting October 1st, Facebook will start requiring two new things:

1. OAuth 2.0 support. SFC has this in version 1.1, which will be released shortly (tomorrow, probably).

2. Canvas and Page Tab Applications will require HTTPS/SSL support.

Both of these are true.

However, some people are interpreting that second one to mean that you need to buy an SSL certificate for your own domain to use Facebook Connect type of functionality, like my plugin Simple Facebook Connect provides. This is false.

A “Canvas” application is one that runs on your site, but shows up on http://apps.facebook.com. A “Page Tab” application is similar, but can show up anywhere on the facebook.com website, depending on how it’s written (it makes a “tab” for somebody’s “Page”). Both of those have something in common: Your website’s contents are actually showing up on *.facebook.com.

Simple Facebook Connect does neither of these things. SFC is a way for you to integrate Facebook connection functionality back into your own site. It can publish stories to Facebook, it can let users comment using Facebook, etc., but the whole point of it is to take things from FB and put them on your site. SFC does not enable your site to appear under the *.facebook.com domain name.

You do NOT need an SSL certificate to use SFC, and you will continue to not need one after October 1st.

You will, however, need to upgrade to SFC 1.1. Old versions, including 1.0, will cease to function.

SFC 1.1 will most likely be released tomorrow, and should be a painless upgrade from 1.0. Sorry for the delay.

Shortlink:

Tags: https, sfc, ssl
Category: Other, Rants | 15 Comments

Otto on WordPress

Using the Facebook Debugger Tool

Random Post snippet

Creating a Site-Specific Snippets Plugin

How to create a Site-Specific Plugin

Migrated to DreamHost

Quick fix for people having SFC problems

GoDaddy Hosting = Epic Failure. Looking for a new hosting service.

Customizing WordPress Images with a Plugin: ImageFX

SFC will NOT require you to use HTTPS

Recent Posts

Email Me

Categories

WP Core Contributions

Archives