Here’s the sequence I went through to add the Facebook Like control to my blog:

Drop an HTML snippet on your individual blog entry page within iWeb.

Copy the above code into the snippet, verbatim.

Go to the above Facebook page and walk through whatever steps they require at the moment to allow you to download their control code. I needed to give them a cell phone number, and they texted me an “unlock code” that verified I was a person and not a spambot. No big deal.

Fill out the Facebook form on the above Facebook page for the control you want. The only “trick” is to specify the URL as “REFERRER”. Don’t give it a real URL, just the string “REFERRER”.

Copy the control code they provide, and paste it into your HTML Snippet code to replace the gray text above. I tried the XFBML code, and it causes some problems with iWeb: not recommended.

Publish your page.

You can copy and paste this identical HTML Snippet without modifications onto any iWeb page, and it will function properly. That means you can duplicate an existing blog or podcast or photo page (with the HTML Snippet on it), change the title and the content, and simply publish the site. Your Facebook Like buttons will automatically point to the correct pages.

So, what’s the big problem with iWeb and Facebook buttons?

When you drop an HTML Snippet into an iWeb page, it doesn’t drop the HTML code directly into your page. Instead, it puts the HTML Snippet into its own file, and then puts a reference to that file into your iWeb page. With iWeb version 3, they’re using Javascript to pull the information out of this snippet file, while in the past they’ve used other things. No matter, the Snippet is in its own file, and is NOT on your web page.

That means that none of the normal HTML code in the Snippet is going to know anything about the web page it is embedded in. For the Facebook Like button code, it looks something like this:

To make this work, you need to modify the REFERRER portion on every single iWeb page on which the Snippet appears — otherwise, all of your copies of the Snippet on different blog pages will all point to the same REFERRER. Someone reads a blog entry, presses the Like button, and ends up liking a completely different entry, which (perhaps) they did not like at all.

This is annoying. The whole point of iWeb is to make this stuff easy.

However, here’s the real problem with this situation. When I’m writing the blog page, I don’t actually KNOW what the page address will be, because iWeb embeds the date into the page.

So if I write a blog page I call “Important Thoughts” today and publish it before midnight, it will show up as

“…/Blog/Entries/2011/6/10_Important_Thoughts.html”.

However, if it takes a little longer and I publish it just after midnight, it will show up as

“…/Blog/Entries/2011/6/11_Important_Thoughts.html”.

Two totally different pages, and one of them doesn’t exist. Unless I pay very close attention, the Facebook HTML Snippet will point to a page that doesn’t exist. So I end up publishing the page twice, the first time to figure out what iWeb calls it, and the second time to fix the HTML Snippet.

This is completely unacceptable.

Let’s look briefly at what the code above does to solve this problem.

First, the Facebook code we get from their page is their completely generic <iframe> code, except that we use the URL of “REFERRER”. Technically, you can use any string that doesn’t show up in the <iframe> code that Facebook supplies, but “REFERRER” works just fine. When Facebook changes their code, you’ll have to change your code too, but you don’t have to do anything other than keep up with them.

The first trick is to encapsulate the Facebook code in a

section with an ID value. I chose “mycontrol”, but again, this could be anything. This creates a DOM (Document Object Model) object with an ID value of “mycontrol”. You can look up Javascript DOM for more detailed information. I’ve had very good results with

The second trick is to embed document-modifying Javascript code into the HTML Snippet. Inserting the Javascript code as shown causes the script to be executed as the page loads. Remember that the “page load” time is when the iWeb page pulls in the HTML Snippet file.

This Javascript first creates a pointer to the “mycontrol” object, which happens to be the entire

portion of the HTML snippet.

It then creates a regular expression. You can find documentation for this under the RegExp() function in Javascript. This particular format creates a static regular expression that matches all instances of the string “REFERRER”.

The

object has sub-object — a string — called “innerHTML”, which refers to the content of the object. In our case, it includes the text of the Facebook control code.

This next line of code finds all instances of “REFERRER” in the Facebook control code and replaces them with the document.referrer text, which is — drum roll, please — the iWeb page that called out this HTML Snippet. Or, in other words, your current blog page, the very thing that your HTML Snippet didn’t know about.

So what happens is that the browser loads the content of the HTML Snippet, which contains a “REFERRER” string, then immediately executes Javascript code that modifies this string to become the page that loaded the Snippet. What gets delivered to the user’s browser doesn’t have “REFERRER” in it at all — it contains a link to the (correct) iWeb page, magically created on-the-fly by the user’s browser as the page was loaded.

A few caveats.

If the Facebook code contains any text that looks like “REFERRER” (case-sensitive), the code above will break the Facebook code. You can change this text to anything you like, but make sure you change it everywhere.

If the HTML Snippet contains any DOM objects with an ID value of “mycontrol” — or, for that matter, if the iWeb page contains any objects anywhere with an ID value of “mycontrol” — the results are unpredictable. You can change this ID to anything you like, but make sure you change it everywhere. This is especially important if you use this technique to embed multiple controls (e.g. Facebook and Twitter).

If you want your readers to be able to leave Facebook comments as well as merely “Liking” your post, you need to make the control at least 400 pixels wide. In my case, I sacrificed the width of the page to the control, a full 640 pixels. If you use less than 400 pixels, the Facebook control will chop off the “Leave Comment” link.

The minimum and default height for the Like control (without faces) is 35 pixels, but if you want your readers to leave a comment, you should make it at least 42 pixels high. Otherwise, the comment control gets clipped on the bottom and looks funny.

Of course, this might not work on some browsers. I’ve tested it with Safari, Firefox, and Internet Explorer 8. For anything else, you’re on your own.