Jerome's TOTs

The official release of WordPress 3.0 being a bit recent, I’ve had a hell of a time trying to find bit.ly plugin that supports WordPress 3.0. The idea is to get your bit.ly short URL instead of the WordPress 3.0 short URL that uses your own domain name when you press the “Get Shortlink” button of a post editor.

I found the “WP Bit.ly” plugin which looks pretty good but does not yet support WordPress 3.0.

So what does an unsatisfied geek do on a Friday evening instead of having dinner? He finds a solution.

1. Download the WP Bit.ly plugin

2. Fix the plugin code

In file wp.bitly.php, put lines 47-48 in comment:

/*add_action( 'wp',      'wpbitly_shortlink_header' );
add_action( 'wp_head', 'wpbitly_shortlink_wp_head' ); */

If you too are a geek and you need to know, this will make sure WordPress 3.0 continues to take care itself of the HTML response header and the Web page HTML header as per the rel=”shortlink” proposed standard. Otherwise, the WP Bit.ly plugin would add these twice to a page which wouldn’t be clean.

3. Modify your theme’s function.php

Add the following code to your theme’s functions.php file:

/* bit.ly shortlink */

function get_bitly_shortlink($shortlink, $id, $context, $allow_slugs) {
   if (function_exists('wpbitly_get_shortlink')) {
      $slink = wpbitly_get_shortlink($id);
      if (empty($slink)) {
         wpbitly_generate_shortlink($id);
         $slink = wpbitly_get_shortlink($id);
         }
      return !empty($slink) ? $slink : $shortlink;
      }
   return $shortlink;
}
add_filter( 'get_shortlink', 'get_bitly_shortlink',10,4);

This code links the plugin code to the new WP 3.0 shortlink feature. It also makes sure that WordPress 3.0 will continue to operate as before if you do not enable the WP bit.ly plugin or you disable it.

Generate the bit.ly links from the plugin

So that the “Get Shortlink” button gets you a bit.ly link (instead of the default permalink), these should be generated once from the plugin’s settings. For new posts new bit.ly links should be created automatically.

Be aware that visits and crawls to your site will generate bit.ly links for each visited posts if no link already existed for each visited post. This is due to the fact that the short links are included in the code of each of your page to support new standards.

I’ve been helping At Home with Kim Vallee support the Open Graph Protocol promoted by Facebook. It’s easy to implement and great research that we’ll be adding immediately to Shwowp. If you want to learn a bit more why it’s important for your site to implement the Open Graph Protocol, read this article: “Facebook Unleashes Open Graph Search Engine, Declares War On Google”.

URL Linter is a handy Facebook Developer tool that allows you to analyze a Web page meta data to see how Facebook understands it.

The problem is that URL Linter was working for the home page but not for the article pages. After much lost sleep and a call for help on Facebook Developer Forums, Paul from Facebook confirmed it was a bug:

• WordPress 3.0 added a shortlink feature
• If you changed your WordPress permalinks to friendly names instead of the default, it adds an HTTP header variable in the form
  • Link    <http://domain.com/?p=12345>; rel=shortlink
  • This new header variable is part of a proposed microformat standard.
  • The Facebook URL Linter and crawler currently has trouble parsing the page when it sees this HTTP header

The Fix

The bug should be fixed by Facebook in about a week. In the meanwhile, if you run WordPress 3.0 and are implementing Open Graph Protocol support to your site, you can add the following code in your theme’s functions.php to disable the shortlink in the HTTP header output:


/* Remove WP 3.0 shortlink */
function empty_shortlink($shortlink, $id, $context, $allow_slugs) {
return NULL;
}
add_filter( 'get_shortlink', 'empty_shortlink',10,4);

My wife Kim is the successful editor behind At Home with Kim Vallee. She uses the WordPress platform.

With success and a popular platform, problems with comment and contact form spam becomes quickly a pain to manage. That’s why you need a good toolset to keep your sanity intact. Good WordPress plugins to protect against spamming and keep your installation secure include:

• Akismet – protects against spam
• Login LockDown – adds extra security to your login form
• WP Security Scan – security
• WP-SpamFree – extra spam protection

WP-SpamFree is quite invaluable against robots and contact form spam. However, it came to our attention that some people would see the following message instead of the contact form:

Your location has been identified as part of a reported spam network. Contact form has been disabled to prevent spam.

See the message when it would appear instead of Kim’s contact form:

This was really annoying. People were telling Kim they couldn’t send comments.

By chance, one PC at our office had this bug. The unique IP address assigned to our network by Videotron seemed clean. So I dug further and looked at the plugin code to understand and debug what’s happening. It seems some browsers in some configurations (in our case a particular Firefox installation on Windows XP) do not transmit the HTTP_ACCEPT_LANGUAGE variable to servers. There is a check in the WP-SpamFree plugin that identifies the visitor as a spammer if this variable is empty.

Once the problem identified, the fix is easy: simply disable this verification. The quick fix to the plugin is to modify the wp-spamfree.php file in the plugin directory to put this condition in comment. See my changes in red:

/*
            $user_http_accept_language = trim($_SERVER['HTTP_ACCEPT_LANGUAGE']);
            if ( !$user_http_accept_language ) {
                $contact_form_blacklist_status = ’2′;
                $spamfree_error_code .= ‘ CF-HAL1001′;
                }
*/
            // Add blacklist check – IP’s only though.

            if ( $contact_form_blacklist_status ) {
                $spamfree_contact_form_content = ‘<strong>Your location has been identified as part of a reported spam network. Contact form has been disabled to prevent spam.</strong>’;
                }
            $content_new = str_replace(‘<!–spamfree-contact–>’, $spamfree_contact_form_content, $content);

That’s it. No more false positives for Kim’s visitors!

I’ll send this issues to the WP-SpamFree devs.

I finally managed to get my setup fine-tuned to debug Facebook FBML applications using Visual Studio 2005. Chances are that the same procedure will work under Visual Studio 2008. Since I struggled a bit to get my setup right, I thought I should share my findings.

I am using Nikhil Kothari’s excellent Facebook.NET API because I think it’s very good for FBML applications. I also tried the Facebook Developer’s Toolkit and I found it easy to use for IFrame applications, but a bit buggy. I also had to make corrections to the source code to improve performances and solve some bugs. In any case the following recipe to debug applications would work with any API.

Getting your PC to serve HTTP request over the Internet

Since Facebook FBML applications work though REST requests that are incoming from Facebook’s servers, you will need to setup your PC to respond to HTTP request from the outside.

The first thing in order, is to setup your rooter and or firewall so that your PC can respond to external HTTP requests. In general, you need to:

1. Open the HTTP (80) port on your router to forward requests to your PC’s LAN address
2. Configure your firewall to let HTTP requests through

In my case getting this to work was a bit of a struggle, because my Bell Canada service supplied me with a dreaded SpeedStream 6300 router/modem. To make a long story short, I had to use a second router, plug it in the WAN port and setup the DMZ address to the second router’s address on the SpeedStream.

You will also need to setup a DNS Server so that the name server reaches the public IP address your are connected to. To do this, you either need a fixed IP address and setup a DNS server or need to use a dynamic DNS service. In my case, I’m lucky, I have a fixed IP address and have my own DNS servers.

To test correctly that you can serve external HTTP requests, the following is recommended:

1. If not already installed, install IIS on your PC (you will need it later, anyway)
2. Configure IIS to serve a static HTML page, start the IIS service and test your page on localhost
3. Test your HTML page using your external IP or fully qualified domain name. Here, chances are you will need to test the page from outside the network. Ask a friend to try the URL from a remote location.
4. As a basic security measure, make sure to configure the IIS service to start manually and start it only when you need it or to change the port forwarding on your router to make sure your PC is not constantly available to respond to external HTTP requests.
5. If your Web page is not responding, check the IIS logs. It will tell you if your Web server is being hit or not. If it’s not being hit, there’s surely a problem in routing external HTTP requests to your local Web server.
6. In order to resolve external URLs that point directly to your domain name, you will need to add an entry for your fully qualidfied domain name in windows\system32\etc\hosts.

Testing your Facebook FBML application

Once you know your local Web server can answer external requests, make sure your Facebook FBML application is working. If you have access to a hosting service (you will need one if you wish to publish your application), publish your application, configure your Facebook Developer account for the application and test it.

Once you know your “Hello World” application works, you can now try and setup you debugging environment.

Debugging the FBML application

To debug a FBML application, you will need to setup your project as a Web Application Project. You might not need to, but I was never able to allow external HTTP requests to be served by the Web server included in Visual Studio 2005, even when configuring it on port 80 and disabling IIS. With Web Application Projects, you can use IIS. You can learn more about Web Application Projects here. To migrate a Web Site Project to a Web Application Project, I recommend this excellent article by Scott Guthrie.

Once your Web Application Project is ready for your Facebook application, go in your project’s properties and set up your project to use IIS:

If you start the debugger for your project you will be asked to log in your application. Instead, go to http://www.facebook.com, log into your account and install your application. You will probably get an error because it did not respond to the installation URL. It does not really matter, if there was an error while installing your application in Facebook, it will be installed anyway for your profile and your will see a link for your application in the left menu. If you browse to your application, you will probably get the following error (if you set up your Web.Config to show errors):

If you don’t get this error, but instead get a default Facebook application error, check your IIS logs to see if Facebook is reaching your local copy of IIS. If not, recheck your routing configuration, your firewall and your application’s configuration in the Facebook Developer application.

The above error happens because the debugger is not attached to the right process. Here’s how to solve it:

1. Stop your debugger
2. Restart the IIS Service.
3. Use any browser to browse your application, you should finally see it served from your PC!
4. Then, start your Visual Studio Debug to attach to the ASP.Net worker process (aspnet_wp.exe) using the “Debug/Attach to process” menu item:

Redo the above 4 steps anytime you get an HTTP 500 error.

It should now work. If you refresh your application’s page in your browser, it should still show correctly and if you add a breakpoint in your code, you should see that you are debugging Facebook’s requests!

I’m developing a Facebook application for fun in my free time and found the solution to a problem that nagged me for a while.

To develop a Facebook application, you use the Facebook Developer application and create a new application. You can even define a localhost application so that you can debug your application locally. Once all the required parameters are well defined for you application and you begin to test the Facebook integration, you may encounter the following error when following you Canvas Page URL:

When this was happening to me, my application wasn’t being called at all by Facebook. If you have a real error in your application, your application should be called and you should be able to debug it or you should be at least getting a 404 error from your server.

The solution

With trial and error, incomprehension and a lot of swearing, I finally found out that this is a bug in Facebook and pinpointed exactly how it happens for me.

Ensure that the Canvas Page URL and that your Side Nav URL are both in lowercase! There is something in the Facebook folks code that forbids you to add any uppercase letters to the Canvas Page URL and Side Nav URL. So, to be on the safe side, for every URL defined in your application’s settings in Facebook, use lowercase letters!

By the way, it now looks like this problem is now specific to the Side Nav URL being in lowercase. I am pretty sure that there was a similar Facebook error when the Canvas Page URL was in uppercase.