Windows Live Writer plugin to prevent internal pingbacks on WordPress.com
As I wrote about and posted a workaround for not too long ago, internal pingbacks really annoy me (when you link to a previous post of yours and it generates a pingback in the comments of the post to which you linked). In general I think pingbacks are excellent, but when they are from me, to me, I think that they look untidy and unprofessional, and they annoy me. What also bugs me is going back and manually removing them, especially when I don’t write my blog posts using the in-browser editor.
Plugin solution
So I decided to write a plugin for Windows Live Writer which automatically turns absolute links to posts on your own blog into relative ones, preventing a pingback being generated.
Note: RSS READERS DO NOT LIKE RELATIVE LINKS – if someone subscribes to your blog by RSS, if you have a relative link in your post, their RSS reader will not be able to handle the relative link (if they click on the link in the RSS reader they won’t be taken to the link destination). Source – thanks to Joe on the WLW dev team for pointing this out.
There are plugins for various blogging packages which prevent internal pingbacks, including WordPress, but as I host my blog for free on WordPress.com I can’t use plugins.
So I may well be the only person to ever use this.
How it works
What the plugin does is search through your blog post when you press Publish, and it it finds the string
<a href="<http://your blog.com>/<some blog post>
it changes it to
<a href="/<some blog post>"
(Actually it doesn’t include the “<a “ bit but I included that so that the Source Code Formatter plugin would get the colours right)
And that’s it.
To install, download the installer from codeplex (the source code is also available) and run it. Enable the plugin in Tools | Options | Plug-ins. The first time you Publish after enabling it you’ll be asked if you want to activate it for the particular blog, as it is a blog-specific (PublishNotificationHook) plugin – you can manually enable it per-blog by going to Blogs | Edit blog settings | Plug-ins.
Development and references
I originally coded this plugin as a ContentSource plugin which incorporated a form like Insert Hyperlink. However this seemed to me to be too fussy and annoying to have to remember to distinguish between links to your own posts and other links, so I re-created it as an inline “set and forget” plugin.
For the first version I found Scott’s guide very easy to read and helpful, and I also found Keyvan’s write-up useful.
For the second – final – version I did some more reading and found that Scott had already written a plugin which made all hyperlinks bold, which did almost exactly what I wanted. He wrote a very nifty WriterUtilities class (unsupported by him or the WLW team) which allows you to edit the contents of the blog post (by plugin) before it gets published. When I emailed him checking that it was ok to re-use his class he couldn’t have been nicer or more friendly.
I re-used Scott’s Bold Hyperlink Plugin almost in its entirety, so Scott, thanks for inventing this wheel!
When it came to building the installer I had a quick peek at Ben Hall’s post as I haven’t created an installer since I was coding in VB 6.0.
Codeplex project page: http://www.codeplex.com/RelativeInternalLink
Windows Live Writer – how to use IE8 beta’s rendering engine in standards mode
Windows Live Writer uses Internet Explorer’s rendering engine to show you how your post will look in the WYSIWYG editor and in the Preview view.
Differences between Preview and published versions
This can cause some differences in how the post looks in Windows Live Writer compared to how it actually looks when published and viewed through another browser such as Firefox or Opera which conforms a bit more closely to the W3C’s specifications in terms of rendering HTML.
Internet Explorer 8 (beta currently) is significantly more standards compliant than previous versions. Windows Live Writer uses the latest newest version of IE installed to render the WYSIWYG editor and Preview view…but if you install the beta and open up Windows Live Writer you will find that Writer is still using IE7’s engine for backwards compatibility reasons.
This information about the cause and the fix is courtesy of Brandon, a very friendly and helpful developer on the Writer Team.
Allow use of IE8 beta’s engine in standards mode
To let Windows Live Writer use IE8 beta’s engine in standards mode, open up the .htm files Writer uses as templates for the editor/preview and add the following line to the head:
<META http-equiv="X-UA-Compatible" content="IE=8" />
You’ll find these files in the App Data folder. In XP they’re in Documents and Settings\<username>\Application Data\Windows Live Writer\blogtemplates\<id> and in Vista they’ll be in Users\<username>\AppData\Roaming\Windows Live Writer\blogtemplates\<id>.
The files you need to edit are named index[X].htm, where X in my case was 2 and 3. index[2].htm is the template for my editor and index[3].htm is the template for my Preview view – opening it up in Notepad/another text editor shows that it contains the code for all the posts which are shown in Preview view under the current one you’re previewing.
Both index[2].htm and index[3].htm have the same content in their Head sections (the bits between the <HEAD> and </HEAD> tags) and it’s in this section that you need to add the line quoted above.
Issues with the IE8 beta’s standards mode
As IE8 is still in beta there are unsurprisingly a couple of issues which arise as a result of using the standards mode.
Issues in the WYSIWYG editor
Although the Preview view rendered as expected, using IE8 beta’s engine for the editor caused several problems for me, including not being able to enter a title for the post and paragraphs randomly being occluded:
I therefore only have the line in index[3].htm – the template for the Preview view/tab.
This issue will surely be fixed, although probably not any time soon.
Odd – but irrelevant – behaviour in Preview mode
I also got odd behaviour in Preview mode using IE8 beta’s engine when I clicked on a heading where the entire post slid to the left so that only half of it was visible on the screen…going back into the editor then back to Preview returned it to the expected position. This only happened when I had a heading which hadn’t been saved in the draft.
As I said this is functionally irrelevant because I can’t think of any reason to click on the post when previewing it.
Another method of forcing the use of standards mode
It should be possible to force the use of IE8 beta’s engine in standards mode on a per-application basis by adding a registry key and a value for each application for which you want to force (I tried it for Firefox to get IETab to use IE8’s engine in standards mode) but I couldn’t get this to work for Firefox or for Writer, and considering the problems I had in Writer’s WYSIWYG editor mode, this probably wouldn’t be a good solution.
More Windows Live Writer goodness
On a separate note, I continue to be impressed by Writer’s effects for images…being able to add a custom watermark in different places kicks ass, as do the quick sizing, borders, effects and text wrapping options.
Windows Live Writer, WordPress & Headings
I like to format anything I write, whether it be a letter, a report, a blog post etc
Formatting improves readability and , for me, structured presentation helps to promote structured and more comprehensive thinking/analysis.
Problem – My headings don’t work
Accordingly I’ve been frustrated by one aspect of the WordPress – Windows Live Writer integration, which is that when I use headings and subheadings in WLW my post looks great. However when I publish the post to WordPress, my nice headings disappear and my post loses much of its structure. Update: This only happens when using browsers other than Internet Explorer. My apologies to anyone (including the developers) who I mislead regarding this. Update #2: Apparently IE8 will fix this, as WLW renders the WYSIWYG editor and preview using Internet Explorer’s engine, and the IE8 beta is much closer to Firefox/Opera etc in its standards compliance.
See what I mean here.
It finally got to the point today that I had to find out why it was happening.
Cause
Looking at the Source View in Windows Live Writer I found out that the Heading (1-6) formatting is represented in HTML as the <h1>-<h6> tags, which is logical and as it should be. And looking at the WordPress posts a little more analytically I saw that it was just the <h1>-<h3> tags which didn’t seem to display as expected.
After a little bit of research, I found out that most WordPress themes already use the <h1>-<h3> tags in their themes, and have customised their attributes. Updating the theme in Windows Live Writer doesn’t seem to integrate this aspect of the theme’s CSS.
This is pretty basic stuff which anyone who puts a bit of time into WordPress/blogging would probably have caught from the start, and had I bothered to have a look at the CSS files being served with my blog page I’d have realised it too. For a casual blogger like myself though, or someone who knows nothing about HTML/CSS, it could be a source of frustration.
Solution
The workaround for this is to only use Heading styles 4-6 when writing posts in Windows Live Writer, or to modify your WordPress style CSS file. Bear in mind that modifying is going to change the look of the places where Headings 1-3 are already used, generally the blog title, post title and comments.
Anyone using blogging as a means of generating money should be aware of the implication Headings have for SEO.
Update:
The behaviour described above only occurs when using browsers other than Internet Explorer, such as Firefox and Opera (I haven’t tested Chrome). I should have checked those browsers before posting this. My apologies to anyone (including the developers) who I mislead regarding this.
Update #2:
Apparently IE8 will fix this, as WLW renders the WYSIWYG editor and preview using Internet Explorer’s engine, and the IE8 beta is much closer to Firefox/Opera etc in its standards compliance.
