MT-Approval 1.1.0 »
Even though I built an automatic function into MT-Approval (to handle the updating of Context.pm), I wasn't happy with the way it worked. For starters, I hate changing the actual code of Movable Type. The reason for this is mostly because if that code is upgraded to a new version, the install often has to be repeated. I know of at least one MT-Approval user who ran into this problem.
So after thinking on it for a while, I've come up with a way around this problem. Instead of using the installation routine in MT-Approval, you can now use a global filter on the MTCommentFields tag itself.
Like so:
<MTCommentFields approval="1">
This will automatically add the hash to the output whenever the filter is specified on the tag. If you have already installed MT-Approval and you would like to use this new version, you should probably go to mt-approval.cgi and uninstall the software, then make use of the filter on your tags. It will probably work if you do both, but it's a safer bet to remove the old method first.
While I was in there, I also added two other filters:
<MTCommentFields remove_post="1">
<MTCommentFields remove_preview="1">
These work pretty much as you would expect, and remove the corresponding button from the form created by MTCommentFields. This will allow those of you using MTCommentFields to remove the Post button from your initial comment form, so that people don't submit it and get an error message. I'm not sure why you would remove the preview button, but I was there, and it was easy, so I added that function too.
Update: Anyone paying attention will realize that the sole function of mt-approval.cgi was to install (and uninstall) the software for MTCommentFields users. This is absolutely correct, and the file technically isn't needed any longer. If you are a new MT-Approval user who won't use the install function, or an older user who has already removed the integration, then you no longer strictly need mt-approval.cgi or approval.tmpl. You can remove them. By the same token, it probably won't hurt to leave them on your system, and I may have some more functions in mind shortly, so you may want to keep them where they are. Purely your call.
Comments (4)
Hacking through implementing this right now. Some thoughts:
1. it's never explicitly stated in the preceding entry that your design intent is to force the clickthrough into preview before posting.
Is this a requirement? If not, what's the best prcedure to allow users to avoid the extra clicks?
2. implementing MTCommentFields in individula entry pages produces the following error on rebuild:
"Subroutine post redefined at /path/to/lib/MT/App/Comments.pm line 189.
Use of uninitialized value in concatenation (.) at /path/to/plugins/Approval.pl line 56."
It does not apppear to impede the page build from completing, and when completed, the comments run through as expected with preview->post->mt-blacklist moderation message.
Posted by mike | February 26, 2005 7:22 PM
1. The entries I create about this, or any plugin, are by no means meant to be, nor should they be interpreted as, exhaustive. The documentation included in the archive probably isn't either, but I try to make it as complete as possible. And in there, it does explicitly state that a comment preview is required, and also the reason for it.
In case you haven't read that, the reason is because MT-Approval uses fields in the comment preview to generate the hash, so the preview must be performed prior to posting with MT-Approval installed.
Does this mean this is the only solution? By no means. There are a number of solutions similar to MT-Approval, and some do not require preview. I'm sure there are still other options in people's minds (perhaps yours), and those may become plugins at some point. But that's the way MT-Approval works.
2. I've not seen those messages before, but the first, at least, is not surprising. The post subroutine is redefined. The error message should be trapped and you shouldn't see it. Perhaps you have a different server configuration that shows these messages, however. The uninitialized value has to do with using a global filter (that's the line it is on). Can you provide the actual template tag(s) you are using?
Finally, as mentioned (again in the documentation), MT-Approval has not been tested with MT-Blacklist, though I have heard of people using it. I personally do not. Because both plugins redefine the Post subroutine, that might be the problem. You may want to remove/disable MT-Blacklist and see if the problem goes away.
Posted by Chad Everett | February 27, 2005 7:47 AM
Hello,
When I have mt-approval 1.1.0 installed MT display this error in the preview page:
Subroutine approve_comment redefined at lib/MT/App/CMS.pm line 1983.
If I uninstall it this message disapear.
Thank you in advance
Posted by Jorge | March 2, 2005 4:59 PM
I don't know what's wrong, but after I uploaded the plugin and the .pm file, even berfore I changed the MTcommentFields tag the comments didn't work. I was constantly getting the Comment Error page. No matter how I changed the tag (just approve="1", with remove_post="1"), always the same result. And the post button still remained. Any ideas? Probably I installed the plugin the wrong way? I'm running MT 3.121
Maybe it's because I changed the name of the comment .cgi-file?
And when I click the MT_Approval from the main menu of my blog admin page, I get an error due to misconfiguration.
Posted by Max Khokhlov | April 5, 2005 9:27 AM