| Comments

Before Windows Live Writer was even publically released, I was glad to have been an early beta user/tester of the product.  The team thought early about an extensible model and it has been my content authoring tool ever since.  It has allowed me to use *my* preferred content workflow with my cloud providers/formatters/tracking and other such plug-ins due to this extensibility.

Flickr4Writer screenshotOne of the first plugins available was one of mine I called Flickr4Writer.  It was pretty popular (as most ‘firsts’ are) and I got a lot of good feedback that changed the functionality and user interface.  Is it the best design/code?  Probably not, but it seems to have served the needs of many folks and I’m happy about that.  I put the code into the Open Source world around the same time and it never received much uptake there and only one contribution of literal code (plenty of feedback). 

I depended on an early library that was created called FlickrNet.  I contributed a few small fixes during my development of Flickr4Writer to the cause.  This has been a very popular library and I think even used in some close-to-official Flickr apps for the Windows platform.  It served my purpose fine for a LONG time…until 2 days ago.

Because Flickr4Writer was pretty much complete and ‘bug-free’ for the mainstream cases, it hadn’t been touched in years and there was never any need.  I felt no need to fiddle with code at all that didn’t need to be messed with.  Another factor also was that Live Writer plugins are pretty locked on .NET 2.0 for loading, so there was no real incentive for me to move to anything else.  Two days ago I started getting emails that Flickr4Writer was not working anymore.  One writer sent me a very kind note detailing what he felt the problem was due to the recent API changes required by Flickr.  One 27-June-2014 the Flickr API went SSL-only and pretty much all my code broke.  Well, to be true, the version of FlickrNet I was using no longer worked.  It was time for me to update.

I spent a few hours today switching to the latest FlickrNet library (and using NuGet now since it is published that way now) and take the time to switch over all the now-obsolete API usage my app was using.  I hit a few speed bumps along the way but got it done.  I sent the bits to a few of the folks that emailed me and they indicated it was working so I’m feeling good about publishing it.  So here is the update to Flickr4Writer, version 1.5 and the steps:

  1. Close Windows Live Writer completely
  2. Uninstall any previous version of Flick4Writer from Control Panel on your machine
  3. Run the new installer for Flickr4Writer by downloading it here.
  4. Launch Windows Live Writer again
  5. Go to the Plugin Options screen and select ‘Flickr Image Reference’ and click Options
  6. Step #5 should launch the authentication flow again to get new tokens. 
  7. Pay attention to the permission screen on Flickr web site as you will need the code provided when you authorize
  8. Enter the code and click OK
  9. Resume using Flickr4Writer

This worked for a set of folks and a few tests I did on my machines.  Performing the re-authentication is key to get the updated tokens for the API usage for this plugin.  I apologize about making folks uninstall/re-install but the installer code was one thing that was really old and I just didn’t want to spend too much time getting that working so I just created a new one.

I’m really glad people find Flickr4Writer useful still and I apologize for not having an update sooner (I actually didn’t get the notice that Flickr indicates was sent out…probably in my spam somewhere) but I appreciate those users who alerted me to the problem quickly!

Hope this helps!

| Comments

From time to time I’ve gotten a few inquiries as to what platform my blog is, what tools do I use, etc.  After a recent trip to Redmond and visiting with the Live Writer team, I got another inquiry while talking with a customer.  I thought I’d just spit out my thoughts.

First, my platform.  Yes there are many platforms out there for blogging.  Probably the most popular are Wordpress and Blogspot.  I think those are popular because you can get up and running for free and have it hosted.  My wife and her friends mostly use Blogspot for that reason.  Only a little customization is allowed, but skilled people can get creative.  For us propeller heads though, we don’t like hosted solutions :-).  I started a long while back on the .TEXT platform.  When Scott Watermasysk had started working with Telligent and Community Server, the .TEXT project was at a bit of a stand-still for growth.  A few picked up the project source code, forked it and created Subtext, which is the platform I now use.  Subtext has a good developer ecosystem around it and led by Phil Haack, there are constant improvements being discussed on the developer list.  It has served me well since I made the move and I’ve contributed features/fixes myself to make it better for me to use!  I’ve tinkered with Graffiti CMS, but for now, Subtext is my comfort zone and has given me no reason to leave.  There are a few things in the overall engine that are a bit dated, but heck the team is all volunteers and open source, so I’m not holding that against anyone.

As for tools, I’ve come to love Windows Live Writer.  Honestly, if you are a blogger and don’t use Writer, I have to ask why.  Seriously…even if you are the casual blogger.  I’ve heard my wife’s friends complain about formatting pictures in Blogspot…then they see Writer and love it!  When I first started blogging I would use the web site and my blog engine.  But quite honestly that is limiting to very basic posting information.  It doesn’t make authoring easy.  I initially started using BlogJet in the early days.  Honestly, it’s a good tool and I happily paid for it.  Probably my only reason for switching to Live Writer was because of the programming model.  As a developer I wanted to be able to customize it and take advantage of other customizations from others.  I remember getting word that Live Writer was available internally.  I took a look at it. 

The moment I downloaded it and installed it I knew we were going to be on to something.  But there were glaring holes.  That being said, I was a responsible beta user and gave feedback…very blunt feedback.  I remember within a week being invited on a phone call with the team to help them understand my feedback.  It was GREAT!  I told them that as-is they shouldn’t release…there were too many holes and releasing without a few key features would be detrimental to future releases.  Quickly I was introduced to some APIs and we talked through certain scenarios.  A few we agreed at the time couldn’t be core, and I volunteered some time to look at building some plugins with their help.  That was the birth of a few of my tools (Tag4Writer and Flickr4Writer).  Tag4Writer was a stop-gap until the Tags feature could get into the next release (which the functionality has and much better).  Flickr4Writer was a great learning experience in client development as well as working with a great team.  I’ve constantly stayed close to the feedback loop with the team to make it a better product.  To date, there is no better authoring product for me than Live Writer.

That being said, here’s my complete tools for blogging:

  • Subtext – my blog engine
  • Windows Live Writer (WLW) – authoring tool
  • Flickr4Writer – a plugin for WLW that enables browsing and insertion of pictures from Flickr and also has BlogThis support
  • S3Browser - a plugin that enables insertion/upload of bits to Amazon S3 storage.  I wrote this along with tremendous help from Aaron Lerch.  This enables me to keep my images/files stored on a reliable network and reduce overall bandwidth usage.
  • Leo Vildosa’s Code Snippet plugin – another plugin for WLW which enables me to insert formatted code snippets.  I know people have their favorites (and there are a lot of them) – this one is mine.
  • Dynamic Templates – a WLW plugin from one of the developers of Writer that enables you to provide your own “macros” within the plugin, helpful in a lot of cases
  • Creative Commons footer – a WLW plugin to append a Creative Commons note to every post without having to think about it.
  • Twitter Notify plugin: a WLW plugin to automatically update Twitter after posting
  • Templates: every blog should be as unique as you can make it.  Some of us are more skilled in design than others.  I’m not one of them.  I get my inspiration from others.  Wordpress has the best ecosystem of templates…learn from them.  There are a few sites that advertise templates like wpSnap.com and others.  Also look at SmashingMagazine.com always, they have some great stuff they find/provide with liberal licensing.

As you can see, my tools completely revolve around Live Writer.  There is only one instance where I can’t use it to do what I need: Enclosures – and I’ve been providing the team feedback around this feature to hopefully get it into their next release. 

For Mac Users: No, there isn’t a version of Writer for Mac :-(.  I’ve heard a lot of people on Mac say they keep a Windows virtual image around just for using Live Writer…wow.  There are some other tools (ecto and Mars Edit) but I haven’t used them extensively to know if they are good or not.  I know they don’t provide the suite of tools that I use so I don’t even bother exploring for now.

I’ve made a lot of investment in making Writer+Subtext an easy authoring setup for me and it has paid off in productivity savings.  Hopefully you have a set of tools on your own as well that keep you productive!

| Comments

This is a public service announcement for my Flickr4Writer project.  It was recently brought to my attention that Flickr has some privacy settings that users can opt-in for in their account to protect their images.  Some users felt that my plug-in for Writer was not honoring these settings.  Truly, I didn’t know about them.  You can read the thread on the discussion lists here if you are so inclined.  For me it came down to a couple of items:

    • Flickr enables users to set a flag to prevent “blogging” of their images
    • Flickr enables users to be hidden from 3rd Party/API searches

First, a note on the “blogging” flag.  This is a setting under your Flickr account privacy tab labeled Who can blog your photos or videos?.  To me, this setting is a little misleading because the description of it actually reads:

This means that anyone who does not match at least the contact level you select will not be able to see the "Blog This" button. (Source: http://www.flickr.com/account/prefs/blogging/?from=privacy 07 NOV 2008)

This setting is clearly for the “Blog This” functionality that shows up if you are logged into Flickr as a non-anonymous user and browse photos.  There is some functionality for them to integrate directly with your blog engine to do some one-click blogging of photos and videos.  Because of the way the setting is named however, some users interpret “blogging” in the broader sense.  flickr4writer was challenged as one violating the principal of this setting.  Since the setting ONLY enables authenticated users to even blog (the setting options go from any Flickr user (non-anonymous) to your specific friends/family settings.  flickr4writer does not use any authentication, so browsing any photos has the appearance to violate this term if the plugin enables an anonymous user to browse and select photos in a tool that is build for “blogging.”  While I draw the correlation that flickr4writer is basically a shell to the web site and does not do anything different than an anonymous user being able to browse and grab an image URL, it is the essence of the rule that I was alleged to violate.  One challenge here is also that the API is poorly designed in this regard because the “canblog” setting is returned only at the photo level even though it is an uber setting for the user’s account.  I think it should be a filter param of the photos.search API call.

The second setting about 3rd Party/API blocking from searches gets even more interesting.  First, this totally makes sense.  Again, it was a setting I wasn’t aware of.  You can change your setting under a section titled Hide your photostream from searches on 3rd party sites that use the API?  Great.  You’d think that once a user selected this setting that any search would filter out their photos/vidoes at the API level right?  Wrong.  flickr4writer uses photos.search calls to query data (actually technically the library that Flickr4Writer uses does).  Again, by definition of this API, only public searchable photos will be returned.  UNLESS you specify a user name.  What?!?!  Yes, that’s right…if you specifc a user name, their results will come back in the API call.  Read that again.  If you specify a user name in flickr.photos.search it will not honor the user’s privacy setting.  So this sucks for me as an API developer/consumer who wants to honor those settings.

So on to the resolutions.  First, I added authentication.  flickr4writer now requires you to have a valid Flickr account to even use it (their accounts are free).  This helps with the first part about blogging.  If a user has specified they do not want their content to be blogged, I honor that and will alert the flickr4writer user with a message that the user they searched prevents blogging and no search results will display.  I feel that this complies with that setting within my application.  If a user wants to bypass my app and copy/paste the URL to the photo/video still…that’s Flickr’s problem now, not mine.  Adding authentication also enabled me to comply with the blogging settings of users because it identifies who the user is and whether or not they can blog the content.

The second thing I modified was to only return content that had Creative Commons or No known license attributes.  This actually makes sense and I needed to do it for a while.  The licenses I filter for are identified in the flickr.photos.licenses.getInfo API.  So if a user has content that is “All rights reserved” then it will no longer show up in the search…even if you are the owner of that content.  I’m interested in feedback on this one if you think I should do a check to see if you are the owner and allow you to see licensed content…leave a comment on how you feel about this one.

For the setting of hiding from 3rd parties…I cannot resolve this.  There is no setting for me to look at.  I’m quite disappointed that Flickr isn’t doing this at the API level as I think that they are violating the user preferences by enabling a loophole.  Should they enable a setting for this (I think they just need to fix the API), I will enable my application to comply even more.  Please if you are a Flickr user who has set this privacy setting, let Flickr know that you want it to be honored.

The authentication adds some initial screens to the use of flickr4writer.  When you launch the plug-in from within Writer, you’ll now see some prompts to authorize the application with Flickr.  There will be a button that will take you to Flickr to authorize the action.  This is only required one time and you won’t see it anymore unless you de-authorize the application on your account (which you have the complete control to perform).

Please upgrade to the latest version.  You will have to uninstall any previous version before installing, but will not lose any settings.  Thanks for your assistance in helping keeping flickr4writer compliant.

| Comments

Hot off the press, a new drop of Windows Live Writer was just released.  Get it here.  This is one of my favorite tools from Microsoft and the update brings a few new changes.

First, I’m happy to report that Flickr4Writer and S3Browser still work fine and require no adjustments.  The other thing announced today from the Writer team is an updated SDK.  This new SDK includes a new type of plugin which enable plug-in activity for pre- and post-publish events.  Some of you following me on Twitter may have noticed something every so often that said “blogging: blah blah” and a link to the post.  This is done automatically for me from Writer using a plug-in.  It actually is one of the ones included in the updated SDK (along with another example for adding a Digg badget to your post).

Recently there’s been some discussion of people re-aggregating/posting blog content to other sites.  Even though I had a Creative Commons license on my blog’s footer, etc, it wasn’t in my content so when someone re-posted my stuff automatically, it wasn’t visible.  Using the new Writer SDK, I created a quick little plug-in that would add a notation about the Creative Commons license I was using to every post.  Again, automatically now and I don’t have to write anything.  I’m making this one available for free/test and you can get it here.  These plug-ins are accessed in the same way through the Tools…Options menu in Writer.  Here’s the configuration for mine:

If you click the Preview tab (a new feature in Writer preview – tabs instead of menu options to switch between Edit, Preview, Source), it will show you what it will look like as well.  These types of plugins can also be enabled per weblog so if you have more than one weblog defined for Writer, you can choose which one you want these post- and pre-publish event plug-ins to be turned on for. 

For some existing plugins out there, this is a more natural fit.  When I heard about this new model, I joined up with Alexander Groß who wrote the Now Playing plug-in which is awesome and flexible (he’s also involved in a great Graffiti template for user groups).  But it seemed a more natural fit to use this model of automatically appending the information instead of having the user remember to click the button to insert the information.  I’ve submitted my changes to Alexander and hope they make it into his next build of Now Playing.  It looks the same in config and here it is in preview mode in Writer:

I love the new Writer with the subtle changes it has made and the additional plug-in model.  Get your update today!

| Comments

This blog runs on SubText.  I heart SubText.  I know there are others out there but for me SubText has met most of my needs.  And when it hasn’t I modify it.  Which brings me to this post.  There was a thread on an email list I belong to about Windows Live Writer (I heart Live Writer too :-)) and categories (adding new categories on the fly).  This got me to crack open the source and hunt.  Alas, there was no support for this.  I’ve been ranting about WordPress API support for SubText on the developer list and I think if I rant one more time it will probably get assigned to me.  Please keep in mind that my modifications were solely intended to make Live Writer the best tool for me…these are targeted at Live Writer functionality and may/may not add value to other areas of functionality.  So on with the show…

The Slug

One of the features in SubText is the ability to auto generate URLs based on the title of the blog post.  Well, I didn’t like that.  I usually want my URLs to be a slight derivative of the URL.  My workflow, then, has been to post as draft, go to the web interface, change and then enable the syndication.  I am sick of doing that.  So let’s start with that first.  You see in blog terms the end part of your URL in called a “slug.”  SubText calls this a ‘friendly url’ and other engines may call it something else.  Here I’m going to call it a slug.  My colleague Jason Mauer has a custom blog engine he uses where he’s implemented almost every blogging API in his set.  I’ve been geekly jealous of his API for some time…now it is time to change that.

I’m not going to go into the philosophical reasons why I want a different URL slug and why I want different ones.  We can debate that over a Mt. Dew some time if you’d like.

SubText uses the MetaWeblog API by default.  The developers chose to implement the spec of MetaWeblog (as they should have) and thus the slug is not a part of the newPost spec and the Post struct used to identify the structure of a post.  So my modification was a few steps.  If you are familiar with the latest source (1.9.5b) of SubText, I’ll be referring to line numbers in there.  First, I had to modify that Post struct for the MetaWeblogAPI implementation.  Now some may shirk that this is a no-no…and I might agree…so if modifying something that isn’t going to conform to a spec that really isn’t full anymore, then move along.  I modified about line 63 and added the following:

public string wp_slug;

I actually could have used wp_slug or mt_basename, both of which mean the same thing and both of which are sent to the API by Live Writer…so I just picked one.  Now my struct has the information when it passes it along for creation/edit of the post via Live Writer.

The next step was to modify the implementation of the post.  In MetaWeblog.cs at about line 234 I added:

if (!string.IsNullOrEmpty(post.wp_slug))
{
    entry.EntryName = post.wp_slug;
}

I also added this to the editPost method to ensure compatibility on edit.

The final step was to modify my wlwmanifest.xml file to announce to Live Writer that I now support this feature.  This is done by adding to the <options> node of this manifest:

<supportsSlug>Yes</supportsSlug>

Then do a refresh of the account settings in Live Writer.  When you do that, in a new post click the little ‘up’ arrow just underneath the editing area and you should now see a Slug field:

Now I don’t have to post a draft and login to change!

New Categories

The thread actually started with wanting to create new categories during a post.  SubText is one of the engines that doesn’t expose this API directly just yet, so some altering had to be done.  Here’s what I did.  I chose to mirror the WordPress newCategory method to do this. 

First I added IWordPressApi.cs to Subtext.Framework.XmlRpc.  The complete code within it is:

using System;
using CookComputing.XmlRpc;

namespace Subtext.Framework.XmlRpc
{

    public struct WordpressCategory
    {
        public string name;
    }

    public interface IWordPressApi
    {
        [XmlRpcMethod("wp.newCategory", 
            Description = "Adds a new category to the blog engine.")]
        int newCategory(
          string blogid,
          string username,
          string password,
          WordpressCategory category);
    }
}

I then went into MetaWeblog.cs and implemented that interface with:

public int newCategory(string blogid, string username, string password, WordpressCategory category)
{
    LinkCategory newCategory = new LinkCategory();
    newCategory.CategoryType = CategoryType.PostCollection;
    newCategory.Title = category.name;
    newCategory.IsActive = true;
    newCategory.Description = category.name;

    newCategory.Id = Links.CreateLinkCategory(newCategory);

    return newCategory.Id;
}

I chose to ignore the slug/description fields (again, thus ignoring the spec which isn’t ideal) at this time, partly because I was getting errors and partly because I decided that I didn’t need them anyway.  I don’t use the description field in categories in SubText, so I just set the description to also be the title.  I also had to modify the wlwmanifest.xml file with:

<supportsNewCategories>Yes</supportsNewCategories>

and refresh my Live Writer account profile to pick up the changes.  The result is now my category options in Live Writer include an “add” feature:

Done with both of those.

Future Posting

This is something I started to look at and added the information to the MetaWeblog API, but it seems that SubText doesn’t filter out future posts in the UI – or at least my quick scan didn’t reveal it did.  I’ve moved on away from this one since I don’t future post right now, but I’ll come back to it in a while.  What I did do, however, to prevent me from thinking SubText supported this was modify my wlwmanifest.xml file to include this definition in the options:

<futurePublishDateWarning>Yes</futurePublishDateWarning>

This way at least if the idiot in me *thinks* I can do it, Live Writer will warn me.

So that’s it!  These little adjustments make my Live Writer + SubText experience AWESOME.  Live Writer truly is one of the best tools Microsoft puts out (aside from Silverlight of course).  I’m going to submit these modifications to the SubText team and see what sticks.  I assume none will since they are admittedly partial.  But I’ve been suggesting on the dev list that SubText expose a WordPress API and I have a feeling I’ll need to start working on that for the team.

Hope this helps some of you!