Image submit buttons and Movable Type

Do you use Movable Type and want to submit forms using an image? You’ll need to edit your Movable Type installation to work around a 4 year-old bug.

Movable Type is listening for the “post” or “preview” parameter but if you use an image as a submit button these parameters have x and y values corresponding to your mouse click. You need to teach Movable Type how to listen for these different parameters before your comments will work.

Fix it

  1. Open MT/App/ inside of your server’s Movable Type installation.
  2. Search for “So we hack it” to find the commentary around the code in question.
  3. Include post.x and preview.x as valid inputs by copying the code below.
    if ($q->param('post') || $q->param('post.x')) {
        } elsif ($q->param('preview') || $q->param('preview.x')) {

You can now use image submit buttons for your Movable Type comments.

  • Posted
  • Updated at
  • Comments [4]


Commentary on "Image submit buttons and Movable Type":

  1. Anil Dash on wrote:

    Good news, this was (coincidentally) fixed in development on MT a little while ago and is already in the next release.

  2. Ian Fenn on wrote:

    Anil, that’s good news, but not as good as it would have been had Six Apart released the bug fix when the bug was noticed. Please can Six Apart reconsider its rather odd policy of only bundling bug fixes with ‘feature releases’?

  3. Jay Allen on wrote:

    Ian, I appreciate your feedback and certainly understand where your coming from. As a user, why should you have to live with bugs any longer than necessary? That said, the “bug fix” that Niall talks about here was implemented only about two weeks ago. Furthermore, it’s not a “bug” but instead a feature request. It’s also not something that most people would consider high priority, certainly nothing to spawn a release for.

    That aside, if you think about it you’ll realize that just about every other software company in the world bundles bug fixes into feature releases. I mean, if you’re going to release something, why not fix the bugs too?

    Of course, I realize that’s not what you’re asking for. You’re asking for more frequent bug fix releases. And we’re actually with you on that. Our ideal release cycle alternates between feature releases and maintenance releases. This system provides platform advancements in the feature releases and the cleanup of the inevitable bugs that are found after it’s release.

    Since bugs can also be fixed in the feature release, it provides a lot of bug squashing opportunity. Plus, since we’re already fixing bugs in the development branch, the work comes mostly for free since the bug fixes are simply checked into both branches.

    However, there are some constraining factors to consider (which bear opportunity costs which are not insignificant) when you talk about even the smallest of releases:

    Release overhead

    There is an overhead to every public release which is felt most strongly on the engineering, product and QA teams. Each public release, no matter how small must go through a full-cycle of QA testing (which is not a process to be taken lightly), release notes must be generated, documentation must sometimes be updated, the release must be packaged and readied for download.

    Balancing looking backward (maintenance releases) and looking forward (feature releases) is a tricky but crucial part of Product Management. When you’re as resource constrained as we are, preparing a release means directing our resources away from developing features that people want so if we’re going to do it, there needs to be a good reason. That is, a bug needs to be severe enough or there need to be enough bugs of sufficiently high priority to warrant it.

    Because MT 3.2 went through such a long QA and beta process (34 releases!), it’s an extremely solid release with no high priority issues.

    Support burden

    Our excellent technical services staff is amazing when it comes to doing their job. They support customers running on a wide variety of MT versions: 3.1, 3.11, 3.12, 3.121, 3.14, 3.15, 3.16, 3.17 and 3.2. Just reading that list makes me shudder. Each version we release creates a bigger burden on the support team to keep track of which bugs and features were included in what release.

    Worse, the burden isn’t simply additive, it’s highly multiplicative. Movable Type runs on over something like 13,000 different server environments. Every time we release new software, we add over 13,000 more potential surprises for our support team. That’s really incredible when you think about it and I really appreciate their excellence and proficiency in what they do.

    Attention management

    Each release is a communication with customers and is something that any software maker must manage. To take it to extremes, if you were to release a new official version every day (i.e. not systematic daily builds), how would your users know that yesterday contained a massive and critical bug fix? I’m not talking about the ones who get your RSS feed or read release notes religiously. I’m talking about the blogger off in their little corner of the web doing their thing.

    Fewer releases mean more attention paid to them and less of a chance that we’ll have people sitting on 2 year old versions of the software. I realize that you’re not asking us to release that often, but I wanted to make this point because in the past, customers have told us that they **were** experiencing upgrade fatigue. When I joined Six Apart, one of the first things we did was to be more controlled with our releases. The addition of a QA team later on really helped this effort.

    The tip of the iceberg factor

    There is one last issue which really specific to the present time and is the primary reason we strayed from our ideal release cycle this time around: There were and are a LOT of things going on underneath the surface of the water you’re floating on. Our massive Yahoo Small business intergration was the first of those and the only one that’s public thus far.

    If you understood all of the internal activities and constraints we have and the three points above, you would certainly understand why a maintenance release to fix a number of non-critical bugs took a backseat. Luckily, all of the work we’ve been doing under the covers will be a benefit to you and everyone when we’re finished with it.

    All of that said, I really don’t think that we’re very far apart on your request. Our ideal sounds like it matches your desires and that’s a good thing for both of us. It’s just that this time around, our priorities lay elsewhere.

  4. JDG on wrote:

    Niall, your site is gorgeous. Good work.

    And thanks for addressing this question. I actually just ran across this problem for the first time about 3 days ago; how amazing that i’ve found this fix right here. Thanks!