Please forgive me the following rant/kvetch, but I'm really at the end of my rope now. I've been using MT since I've forgotten when, and have happily paid for licensed versions, upgrades, the lot. Was a time when MT's documentation and support was second to none. The documentation began to go south around MT3.x and it really tanked with MT4. There are now so many template tags with not a word of explanation it's not funny any more. And the so-called support might as well not exist. Time after time there's some mess up with the code. As far as I can tell, the attitude seems to be: "we're doing all this, so be grateful for what you've got". Somehow, that doesn't work for me. If you're going to put something out, the least we can expect is (a) that it works as it should; (b) that you pay attention to user problems and rectify them before you move on to the next project; and (c) that someone responds.
Take these three examples.
Custom Fields Date Fields/date formats
If you create a custom date field, you can't modify the display format. Why? Because the format is hard coded into the plugin. Go figure. After hours of struggle, I tracked it down to lines 169 through 175 of the ContextHandlers.pm file in Custom Fields. I found a workaround. I posted this as a comment to the MT.org professional pack CF pages here and here. The comments were never approved. I got them out at the wiki in the [template tag recipes[] category
I've been on this since the first release of the professional pack, after CF was taken over by SixApart from Arvind Satyanarayan. Before the take-over, this problem was pointed out on the movalog forums, and he released an update/patch for it. SixApart took the older code without the patch and has never bothered to correct it. "Be grateful you've got Custom Fields kiddo, and don't grip about the details". Really.
AutoLink
Byrne released AutoLink, a successor to the incredibly useful QuickLink. Unfortunately, AutoLink is apparently a stripped down version of QuickLink. The latter allowed for far greater substitution in the replacement text. You could specify an entire string, a target window or frame, replacement text, the title attribute of the href string. AutoLink takes away all that. It only lets you put in a URL. I understand the need to keep it simple, but does it have to be at the cost of functionality? I'm not the only one who pointed this out on the AutoLink page; there have been comments since June. Response to these? No prizes for guessing right.
Also, AutoLink seems to screw up the activity log page. If you have some linked entries, and then want to see the activity log you can't.
Post Office
Probably one of the most useful plugins around post office simply doesn't work. There are complaints on this forum, going back to June 2008, again with no response. The settings form is unhelpful. There is no meaningful readme or help file. You can't easily or intuitively set the polling period (the frequency of checking for emails). PO's link to the email address creates something like "someone+3@somedomain.com". The "+3" is the blogid. Which email provider allows a "+3" in the email address? (a) you can't create such an email address and (b) if you try sending a mail there it's going to bounce.
It is, surely, a trivial matter to change this to "someone@somedomain.com?subject=[myblog] PUT YOUR POST TITLE HERE" and then have PO parse the subject line for an exact match to the blog lable (myblog). All this requires is to fetch the blog label/name from the blog id and use that in the link below the Entry screen.
To say that I'm disappointed is putting it mildly. I have MT in one avatar or the other running on seven different sites all of which I maintain. I've been promoting it wildly, chiefly for its support and documentation. I've even paid for MT (during 4.1) before the free Pro release of 4.2. I'm not a coding guru, I'm not a developer, I'm not even a professional designer. This is a hobby but I'm basically a user who likes to fiddle his own designs and wants complete flexibility and doesn't want to be tied to a boxed product. Is it too much to ask for some decent support and assistance?
I'm seriously considering shifting to ExpressionEngine[]. Their plugins aren't anywhere in the class of MT's, but their support rocks.
Is anybody out there?
Houston calling MT! Houston calling MT!
Reported on Movable Type 4.2
It should read:
[template tag recipes][] category
and
[ExpressionEngine][]
above. Sorry for the snafu in markdown.
[template tag recipes]: http://wiki.movabletype.org/CustomField_Date_Fields "Wiki-Template Tag Recipes-CF Date Fields"
[ExpressionEngine]: http://www.expressionengine.com "Expression Engine"
While I can understand the problems you are facing with CustomFields, I just wanted to point out that your other two problems are with plugins. Although they might have been written by Six Apart employees, they remain unsupported (use-at-your-own-risk) software and so I'm not sure it's right to blame MT's official support for not supporting them.
To say that MT4 has the worst documentation is a just plainly false. Having been around since MT2, I can assure you that the documentation we now have is some of the most verbose, indepth and accessible documentation we've ever had. I don't know when the last time you checked the template tag documentation was but about a month ago, literally **every. single. template tag** (including template tag modifiers) was fully documented (that's a first in a long, long time).
As for the plugin authors supporting you, well that's just a matter of time. I know my plugins have pages and pages of unanswered questions and it's mostly because I really just don't have the time to respond to them!
Sorry, Arvind, but I did _not_ say that MT4 has the worst documentation. What I said was that the once-excellent documentation now isn't, and I stand by that. It's not a matter of quantity and how many pages you fill or even whether you have _some_ text there. It's whether there are helpful, meaningful and reasonably complete instructions. Yes, I grant that after a long, long time all the tags have some text but many of them, especially the new ones, are not immediately intuitive without examples or a more thorough documentation.
There are any number of examples, but take just these: TextileOptions. Example <mt:TextileOptions /> Duh? Or PreviousLink. No example, but it says just this: "A function tag returns the URL points to the previous page of the current page that is being rendered." What?
I guess what I'm saying is that MT and SixApart need to worry a lot less about the competition, take a step back, a few deep breaths and attack the holes in what we have: find the undocumented tags, put in sample code, stuff like that. There was a time when you could download the entire manual and work right through it to a pretty good result. Now it's just a huge effort.
I'm sure many of us would love to help (gratis) in some way with this -- I know I would. Forget what I said about EE, please -- I can't bear the thought of having to fiddle with their URL structure or pay additionally for essential modules. You've got a devoted and loyal family here and that's MT's biggest asset, one it should draw on much, much more frequently.
For this reason, I honestly believe--as a long-time devotee of MT and everything you personally have done for the community--that it is simply irresponsible to put out code that hasn't been sufficiently tested. I'm not blaming MT's official support; I _am_ pointing a finger at the lack of an adequate filtering system that allows possibly useful plugins to be put out on the MT site without sufficiently rigorous testing or checking for usability. The use-at-your-own-risk disclaimer is fine in a court; in every other sense it's unacceptable. It assumes (1) that the end-user is smart; and (2) that the end-user is largely irrelevant. Neither assumption is true, or justified.
As for not having the time, what can I say? As arguments or defences go, that really doesn't cut the mustard. Not for a professional outfit with paid services. And it's not like your users have nothing but idle time to spend fighting incorect code.
MT needs to think about one single _mantra_. No user, free or paid, needs to struggle with code. Pop in the plugin, adjust the settings and off you go. Why on earth should a non-coder have to spend time staring at this jumble of code to try and make sense of it?
Please don't misunderstand this. I think MT is an outstanding product, and it's a matter of great regret and dismay when I see that _my_ product (and I do think of it as mine--don't ask me why) has obvious glaring lacunae. I'm pretty sure I'm not the only one who feels this way.
I stand with Gautam on the documentation. Yes there has been a visible effort very recently to improve it, but many pages just do not do what they're supposed to do: explain things. They're just placeholders. Please keep improving it, it's not finished yet.
I've also left comments on pages that were never approved. This leaves a very bad taste, especially on pages where comments are explicitly solicited [like this one](http://www.movabletype.org/documentation/themes/mid-century.html) where I pointed out that some advertised features are missing, hidden or undocumented, but my comment remains hidden.
Gautam, this:
...results in nothing but myself and others wondering why you haven't submitted a patch if it's so trivial. The readme file, which you of course read, says PO is GPL2. Go nuts.
If you want to argue that things don't work, aren't documented, should be different, etc., you're perfectly entitled, but you crossed the line into presumptuous there.
Unless I misremember, there is no polling frequency in the plugin. That's determined by your cron job.
Why is this still in question? What's stopping you? What information do you need?
I'll be dealing with your PO doc complaint elsewhere. Something does mostly exist, but I'm not comfortable linking to it where more casual users would see it yet. (And yes, it's findable, should someone decide they were determined enough.)
Su,
To answer your first question: I can't do it because, as I said, I'm not familiar with programming. I can sort of muddle my way around a little bit but most of it is totally beyond me. That's _my_ fault and limitation. But it sort of seems to me pretty obvious that if you can write something to decode me+7@mine.com, parsing the other example I gave should be reasonably easy. That's why I haven't, and can't, submit a patch. Why would you assume that if I could submit a patch I wouldn't? I have put in some template tag recipes over at the Wiki and they work; that much I can manage but not more.
About GPL2, all that that license does is disclaim responsibility for damages, i.e., legal damages, and make it free to share with proper accreditation. At the end of the day, all it means is that I am restricted to kvetching if I'm not happy with it. It's certainly not a license to put out stuff that doesn't work.
What's stopping me from helping? I should have thought the answer to _that_ at least was obvious: MT, and the thunderous round of indifference that I am met with time after time after time; and, apparently, I'm not the only one with that experience, so I wouldn't suggest trying to defend the indefensible. I could go into specifics here, but there's no point--my first post does, I think, demonstrate what I mean, as does Arvind's answer. And, by the way, I did manage to put together some extremely clunky templating using the DateTags plugin from Kevin Shay which allows me to auto-expire posts--another feature I've been saying we should have, but which hasn't even been acknowledged either in mail, on forums, or comments. So do please tell: how do we go about assisting when our assitance is clearly not wanted? What's stopping _MT/SixApart_ from being more receptive? And that, Su, is why it is still in question.
I found what seems to be a polling frequency too--not sure it's the same thing--but I have no idea what time interval it refers to.
And, as I said, that's where you crossed over into presumptuousness. You do not actually know what you are saying is true. There's nothing wrong with just asking the question. For one, the query format you suggested is used for pre-filling the subject, etc. in the client application sending the e-mail, not for telling things to the receiving server, which is what's at issue here.
Absolutely untrue; backwards, even. The license's primary purpose is to make the source available to, and editable by, anyone so inclined. And if you aren't inclined, then at least kvetch in a way that doesn't call into question the difficulty of the work someone else will be doing for you.
Really? Because so far as I can see, it's Fogbugz case 64293. You received two responses, responded twice yourself, and then dropped it back around April. There's also a separate case, 64229 opened by Chris Hall himself, on the matter of expiring posts. It's currently assigned to "AFutureRelease" which is a placeholder for what it sounds like; now's the time to bring it up again.
The frequency for tasks is set in seconds. It's set to "1" in PostOffice. So it'll basically check your mail every chance it gets.
Of course I'm being presumptuous. I _am_ presuming that a programmer/coder knows that me+7@whatever.com won't work, and that if there is some hidden secret to this he will say so clearly. I _am_ presuming that he will write code that takes care of this. I _presume_ there is an easier way to do it; it's just that _I_ don't know it. Is there any reason I should? I did not pretend to write code or develop plugins. I took the plugins _presuming_ they would do what they said they would. In pointing out a possible different tack you say I crossed the line. So? Big deal. What's on the other side? Hades? It might be a welcome change after this.
I believe you're in error about what the GPL license means. One of the things the license _permits_ is modification; it clearly disclaims liability and holds out no warranties or assurances. How is that an excuse for bad coding? Consider this: we are batting the meaning of a GPL license back and forth, but it's common ground that the plugins have problems?
I thought--silly me--that plugins were meant to make the end-user's life and experience easier and better, not more miserable. Clearly I was wrong.
And, mind you, it's not everyone who's like this: Beau Smith corrected DashOff in a few hours when I pointed out a conflict with My Blogs (tip of the hat there). Mark Carey's mt-hacks.org has extraordinary documentation and support, and I don't mind paying for some of his work. Kevin Shay hasn't updated his plugins in a year, but whatever he did was always incredibly well documented and he was very quick with his support. Ditto Stepan Riha at nonplus.net. What happened over at SixApart?
I stand corrected on the auto-expire lack of acknowledgement. So we'll wait for that. And wait, and wait, and wait and wait and maybe pray. Meanwhile, Kevin Shay's DateTags plugin can be used for this, though it's not written for MT4+.
I don't know about you, but I'm sick of this. Look, you win, I lose, I give up. I'm very sorry I offended anyone's sensibilities. MT's perfect. Nothing needs improvement. The sun is shining and all is well in the land of SixApart. I'm just a lowly ungrateful end-user worm unworthy of the deities at MT. So be it.
Meanwhile, as we split hairs _ad nauseum_ on irrelevancies, the three plugins at the head of this topic still don't work as promised ...
Nice death scene there. I graciously accept your defeat, and all that. Feel better now?
If you are seriously implying I'm suggesting anything so rosy as the above, then you're paying even less attention than previous comments would indicate, and you're just wasting my time now. As a parting gift, however, I'll let you know that PostOffice works perfectly, barring a couple things I personally don't like. Which is completely different from you not having figured it out. Not that you should have had to figure it out, but that's a separate point from your assumption.
> Feel better now?
Much. Do you? All hail!
> [PostOffice][1] works perfectly
[1]: http://wiki.movabletype.org/Documentation:PostOffice
Excellent. Proves my point. Still quirky, insufficiently tested, apparently restricted to systems that support plus style addressing in a multi-blog environment. Evidently our perceptions of heaven differ wildly.
> Which is completely different from you not having figured it out.
Your assumption, not my statement.
> Not that you _should_ have had to figure it out
Ah. Finally.
Okay, to back up a little, technically the plugin does define a frequency for polling, but it's in the seconds. Had to check as it was bugging me.
Agree on Post Office.
I'm not a perl coder, but it's not more difficult [in php, python, vb] to parse a subject than to parse a subject line than it is to parse the to: address.
I can understand the design concept: having the blog id as part of the to: address makes more sense from a user standpoint. However, it exploits a non-standard feature of some email engines:
From RFC 2821:
Note that there is no provision for an extension of local-part that has meaning other than the destination mailbox.