Testing the Blogging Clients #2: Review of MarsEdit on Drupal

26 May 2008

MarsEditI have an old, short post about testing blogging client MarsEdit with Drupal. A blogging client is a stand-alone application that posts to your blog or other website; the advantage is that you write and edit in a familiar word processor-like application, without having to log in to your site, navigate to content creation, and work with your site's text editing features. And let's face it: as much as we like our Drupal setups, logging in, creating a new Blog Entry or other node, and manhandling TinyMCE isn't ideal for catching those fleeting epiphanies all lightning-quick.

After experiments with a demo version of MarsEdit 2, I ponied up the $29.95 and bought a license. I left a message asking for "more Drupal support!", and received this email reply from Red Sweater:

...thanks for buying and for the suggestion. Drupal seems to be getting more popular, so I'll be trying to take advantage of anything they support!

Great! So, how Drupal-ready is the software so far?

Well, partially, to give a short answer. MarsEdit is a jack-of-all-trades client for a whole bunch of platforms, meaning it handles many platforms well, but might not handle a given platform wonderfully. (Not surprisingly, its real strength is in the big-name blogging platforms like WordPress and Blogger.) Drupal support still has something of an afterthought feel. There are big hurdles that have me using MarsEdit happily for some Drupal posting purposes, but not most.

MarsEdit features

Setting up a Weblog (a single blog or other destination for posts) is easy; give MarsEdit a name and URL, and it automatically detects use of Drupal. By default, the result is the site's blog with ID 1; to set up other blogs, you have to edit the ID# in the Weblog settings. Easy enough.

That same ID field, less intuitively, enables another vital Drupal trick: posting node types other than a blog. Input "page", "story", or other node type in the Blog ID field, and you've created a Weblog for that node type. (Yes, that means you don't freely choose node type when creating a post; you'll need to set up a Weblog for each desired node type on each desired site.) While it's not something you'll guess without reading the documentation, it does work.

There are plenty of little niceties within Weblogs settings, like configurable warnings for fields left blank, and configurable post-posting pings. Editing and posting are simple too. Menus let you add HTML tags as you go, and the live Preview feature works nicely. MarsEdit automatically reads your taxonomy Terms; these show up as convenient checkboxes on a post (making multiple-Term tagging easier here than within Drupal itself). You can set whether the post is to be published or not, what text input filter to use (lots more on this below!), and whether comments are active or not.

There's an Excerpt field, and it works, though in a single fixed manner: what you put into the field gets prepended to your main post, followed by the <!--break--> tag. If you want to let MarsEdit handle your excerpts, that's the method you'll need to use (among several available Drupal solutions). Be sure not to also include the same Excerpt text in the main post body itself, or you'll get the text showing up twice.

There are yet other features that I haven't explored and can't comment on: the Keywords field, a Slug field (huh?), a tab that takes posts from Body mode to Extended mode (again, huh?), and more.

I have issues!

I use the Trackback module with Drupal. On your posts, MarsEdit kindly includes a drop-down box to input trackbacks (which I assume works) and a "TrackBacks" checkbox to turn on trackbacks. Unfortunately, the latter does nothing for me; I check it when posting, yet trackbacks remain turned off in the Drupal end-product. I have to later enable trackbacks on the post from within Drupal.

Along those lines, you'll have to expect that MarsEdit won't cover a host of Drupal node fields and settings. That's not necessarily MarsEdit's fault; Drupal is infinitely configurable, and the input form for a given node type may differ wildly for any two sites. MarsEdit can attempt to keep up with common Drupal setups and modules, but there's no way to cover every combination. In my case, using this very page as an example, my Drupal form includes settings for gsitemap, a checkbox for Private status, meta tags, log message, file attachment, menu settings, authoring info, URL, and more, all of which can't be set from within MarsEdit.

That wouldn't bother me much, as I typically would be happy to let Drupal handle those settings on autopilot, or could quickly edit the post later to set these. Even with that latter hassle, I'd still be appreciative of MarsEdit's ability to initially create the post with smooth ease. But here's where I run into the single big show-stopper problem: text input format.

Input fuss

When you post, MarsEdit allows a dual choice for "Text Filter": either None, or whatever your Drupal setup's default filter is. For most of my sites, the default filter is Filtered HTML – a "lite" filter that disallows powerful HTML tags, PHP, etc., on sites allowing comments by anonymous visitors. I only set Full HTML as the default on sites without comments or unknown users, or on sites in which I allow Full HTML to users but disable so many Full HTML features it loses potential for mischief.

So for a minority of my sites, I can post via MarsEdit using Full HTML, and everything works well. But most of my MarsEdit Weblogs have to use Filtered HTML. Unfortunately, these posts break. They look OK after posting, but when I edit the post in Drupal (such as to fix trackbacks or change some of the settings mentioned earlier), the post body is reduced to one big paragraph; line break info is lost. Gone. (This despite the fact that my Filtered HTML settings do use "Line break converter", just like my Full HTML settings.)

MarsEdit has set the post to Filtered HTML, as expected. I can now manually switch it to Full HTML, but it's too late to save the paragraph breaks. I have to edit the body by hand in Drupal, re-creating breaks. And that just spoils MarsEdit for any long posts.

I thought the Filter Default module might fix things, but it doesn't. It lets me set the admin default to Full HTML and the main default to Filtered HTML, but MarsEditshow users Filtered HTML by default, but they can still switch to Full HTML; by Drupal decree, the main default input format is always available to all roles.) apparently looks only at the main default. To solve the problem, I have to switch the site to use Full HTML as its main default - but do that, and Full HTML becomes available to all users, and that's risky.

I still like MarsEdit

I haven't found a satisfactory solution to the above problem. For now, I'm using MarsEdit only on those sites that use Full HTML as the default input format, or at times when a Filtered HTML post is so short that I don't need to use paragraph breaks. Otherwise, I sadly watch MarsEdit gather dust as I make longer posts (including this one!) from within Drupal. Having to later rework paragraphs by hand from within Drupal just isn't worth it.

I like MarsEdit. When I do use it in the above limited cases, MarsEdit makes the process much smoother and faster than browser-based posting. It brings me close to that ideal state of being able to dash off a post as soon as I have a thought, without having to wait an instant for browsers and Drupal to slowly do their thing. And if you've got blogging gigs that extend beyond Drupal, you may find MarsEdit the spiffiest thing ever for whatever platform you're on.

I heartily encourage any Drupal site user to at least experiment with the program; it's really quite nice. If my text filter problem is simply a case of missing some key step, please let me know!

Tips

1. Take advantage of your Mac's ability to set keyboard shortcuts for any application, and make MarsEdit easier to use. I, for one, was massively spoiled by the ancient Claris HomePage's built-in keyboard commands for H1, H2, etc. headers (using the wonderfully simple Cmd-1, Cmd-2, etc.); ever since, I've hated any HTML editor forcing me to select those from a menu. MarsEdit lacks these all-important shortcuts, but they're simple to add back in via the Keyboard & Mouse Preference Pane's Keyboard Shortcuts tab, on any recent version of OS X. In practice, having these shortcuts in MarsEdit sure beats using the drop-downs in TinyMCE!

2. As mentioned above, I'm able to avoid the text input format problem if the site uses Full HTML as its input default. If you do this, make sure that both the Weblog settings and the individual post settings are set to Full HTML; if I recall correctly from tests, missing one of these won't get you Full HTML goodness with its nicely-preserved paragraphs.

Comments

drupalace's picture

My apologies to all: I did bone-headed things that led to the loss of individual comments on this post. Here are the lost comments, via paste (with loss of threading):

 

Re: Testing the Blogging Clients #2: Review of MarsEdit on Drupa

Nice review! Thanks for taking the time to make a thoughtful summary of the things that are working, and the things that aren't.

It sounds like the text filtering issue is the top issue affecting you right now. I am going to write myself a ticket to look into this further when I get a chance. The short end of the story, though, is: MarsEdit will present a list of whatever text filters a server provides it. Some servers implement this feature brilliantly (Movable Type), and some not at all (WordPress). It sounds like Drupal might fall somewhere in the middle.

It sounds like Drupal is not returning the complete list of text filters to MarsEdit (and other blogging clients). The good news is if this is something that is limited in the Drupal API, it can be fixed in Drupal and MarsEdit will start behaving more usefully automatically.

Daniel

A little more on MarsEdit with Drupal

Thanks for reading and commenting. Looking over the article again, I think that (at least until the end) it comes across as a little more negative than I'd intended. I should mention again that many of the Drupal node fields that MarsEdit doesn't directly handle are very Drupal-specific things that I wouldn't expect a multi-platform client to tackle. And while I haven't checked this carefully, it appears that where MarsEdit doesn't allow direct editing of a field (say, authoring info, or URL path settings), Drupal applies the expected (and probably desired) default input anyway. So those are mostly non-issues.

That text format issue is my only real gripe, and I fully understand what you're saying: MarsEdit can only work with the info that a Drupal installation provides. It may be up to Drupal devs to figure out how to have Drupal report all possible input formats to a requesting client, not just the default input format.

Where I do use MarsEdit, it's fast and easy. On one site, I input interesting links that I come across (using Jan's Node nodes, an oddly-named contributed-module node type for collecting weblinks). All I want to do is input the article name, URL, and my own category tags, and upload – and with MarsEdit, I'm done in under 10 seconds. So for many, if not all, Drupal posting tasks, it's a great aid.

I'll also add that in my few website or email communications with Red Sweater, responses have been wonderfully fast!

 

Car Seat Support's picture

Loved this post and the tips are very useful, thanks!

Drupaloid's picture

Agreed. Like the way you provide technical help here. Thank you!

Christopher Gervais's picture

Have you tried the Better Formats module? It allows for setting default formats on a per-role and per-content-type basis. While I don't use MarsEdit (yet, anyway), I'm building a site for an associate who does. In fact, it was he that found your informative post. If we mange to find a solution, I'll be sure to post it here.

drupalace's picture

Sorry for the slow reply; I wanted to give your suggestion a proper try. Here's what I found:

First, let me say that I really like Better Formats. I'd never heard of it before; thanks for the tip! Its handling of default input format, by usage and by role, is very nice.

Unfortunately, it doesn't appear to solve the MarsEdit problem for me. Regardless of how I set up Input Format defaults under Better Formats, one given remains: I have to set my desired (editor's) input format as the site default, in order for MarsEdit to "read" that format and allow it as an option for posting. And with or without Better Format, that site default becomes selectable to anonymous users (even if Better Defaults sets another format as the default for those users). Yet per my article, I typically don't want to give anon commenters the same input options as those editors posting the content...

I'm really not sure what MarsEdit is up to anyway. In my experiments just now, even when setting my Full HTML input format as default, and making a MarsEdit post using that Full HTML format, I'm ending up with the "broken" result: a post that looks normal on the site, but loses all line formatting as soon as I try to further edit the post on the site. (Per my article, I believe I wasn't having that problem earlier when using Full HTML, only when using my lesser Filtered HTML format. Now I'm getting it all around.)

Among the source code of a page created by MarsEdit using my Full HTML format, here's the relevant content portion:

<div class="node">

<div class="content">

<p>Paragraph One<br />

Paragraph Two<br />

Paragraph Three</p>

Naturally, I would normally want each paragraph bracketed by proper <p> and </p> tags, not the above!

What happens when I try to edit the node? Not surprisingly, here's all that shows up in the Body field:

<p>One Two Three</p>

Line breaks all gone. : (

Alas. I wonder why MarsEdit doesn't place simple <p> and </p> tags around each paragraph. Time to hit the program's author with a query again.

In any case, thanks for the idea. It was worth a shot!

Add new comment