The comment previews in 3.0D lose the user's inputted text in the MTCommentFields form. The problem is that there is no code to put those values in anywhere!
I had to make some changes to lib/MT/Template/Context.pm:
sub _hdlr_comment_fields {
my ($ctx, $args, $cond) = @_;
# zig's fix
my $c = $ctx->stash('comment_preview');
my $email = $c->email;
my $text = $c->text;
my $author = $c->author;
my $url = $c->url;
And then I had to put them into the outpu like so, for each fieldt:
<input tabindex="1" id="author" name="author" id="author" value="$author" />
Is this a known issue? Or what is going on here?
Full Version: 3.0D: comment preview not working right
*bump*
I have the same problem.
Yes, this is a known issue, which has been fixed in development, I believe.
I've posted a possible workaround for problems with <MTCommentFields> on my weblog, which addresses the Comment Preview problem and does not require hacking lib/MT/Template/Context.pm.
Zizag's fix works quite nicely!
Kudo's to zigzag!
MT should really QA their product before releasing a new version with a very big bug. Didn't anyone @ MT validate that when you preview a post that none of the values were passed into the form?
It really should be labled as MT 3.0 Beta.
-R
Kudo's to zigzag!
MT should really QA their product before releasing a new version with a very big bug. Didn't anyone @ MT validate that when you preview a post that none of the values were passed into the form?
It really should be labled as MT 3.0 Beta.
-R
QUOTE (zigzag @ May 23 2004, 03:01 AM)
And then I had to put them into the outpu like so, for each fieldt:
<input tabindex="1" id="author" name="author" id="author" value="$author" />
<input tabindex="1" id="author" name="author" id="author" value="$author" />
can MT (shelly) post an official/permanent workaround for this especially for those not terribly proficient at perl??
specifically i neeed to see how each field would be handled on the comment_preview template
(i am new to MT and am having this exact problem with MT 3.0D and would love to fix it thoroughly -- but need to see an example)
thanks!!
Since there is no official workaround, I'd have say that the answer to your question, "Can MT (shelly) post an official/permanent workaround..." is most likely "No." (Now watch Shelley come in here and post an official workaround... 
)
If you're not real proficient at perl, I wouldn't recommend tinkering around in Context.pm (or any other MT application file) - that sounds like a good way to break something to me.
The code zigzag posted was your example - the other places where the code needs to be modified is one of those "exercises left to the reader".
The workaround I posted is not official nor is it meant to be permanent. But you don't need to know any Perl to use it, you don't have to hack any MT files, and when the MTCommentFields tag is (hopefully) fixed in the next release, it is relatively easy to switch your template code back to using the MTCommentFields tag.
I haven't had any complaints (yet) on the code. You might want to give it a try.
)If you're not real proficient at perl, I wouldn't recommend tinkering around in Context.pm (or any other MT application file) - that sounds like a good way to break something to me.
The code zigzag posted was your example - the other places where the code needs to be modified is one of those "exercises left to the reader".
The workaround I posted is not official nor is it meant to be permanent. But you don't need to know any Perl to use it, you don't have to hack any MT files, and when the MTCommentFields tag is (hopefully) fixed in the next release, it is relatively easy to switch your template code back to using the MTCommentFields tag.
I haven't had any complaints (yet) on the code. You might want to give it a try.
thanks tweezerman.... i did try your fix (before trying the more complex one) and it didnt work for me.... i wish it did!!
If your MT3D was installed/upgraded correctly, and the instructions were followed, I don't know of any reason why it wouldn't work. If you're willing to try it again and you still can't get it work, post back here, post in the comments of my weblog post, or contact me via e-mail.
QUOTE (zigzag @ May 23 2004, 03:01 AM)
And then I had to put them into the outpu like so, for each fieldt:
CODE
<input tabindex="1" id="author" name="author" id="author" value="$author" />
I follow these instructions and modified the output lines ~1119 - 1216 such that
CODE
<input tabindex="1" id="author" name="author" id="author" value="$author" />
and...
CODE
<input tabindex="2" id="email" name="email" id="email" value="$email" />
and...
CODE
<input tabindex="3" type="text" name="url" id="url" value="$url">
...and that works for author, e-mail and url. But I can't seem to get the text to carry over. Should it be:
CODE
<textarea tabindex="4" id="text" name="text" rows="10" cols="50" id="text" value="$text">
Am I missing something? Are there more places in Context.pm that need to be modified?
The <textarea> tag has an opening and closing tag (unlike the <input> tag). The initial value you want to appear in the textarea field goes between the opening and closing tags instead of setting it with a value attribute:
CODE
<textarea tabindex="4" id="text" name="text" rows="10" cols="50">$text</textarea>
TweezerMan, I have posted a patch package to fix various MT3 bugs including this bug report. At present, all instructions in my post are written in Japanese. Sorry for inconvenience. The patch package itself is available from here.
To workaround the problem of this bug report, my patch package employs a simpler solution than yours, I guess. Basically I use a brief JavaScript code and don't modify original MT/Template/Context.pm as far as I can.
The outline of my solution is as follows.
First, I prepared the following code:
And, put the following code after every use of MTCommentFields.
Is it simple, isn't it?
To workaround the problem of this bug report, my patch package employs a simpler solution than yours, I guess. Basically I use a brief JavaScript code and don't modify original MT/Template/Context.pm as far as I can.
The outline of my solution is as follows.
First, I prepared the following code:
CODE
function fillCommentFields (f, email, author, url, text) {
if (f.email != undefined)
f.email.value = email;
if (f.author != undefined)
f.author.value = author;
if (f.url != undefined)
f.url.value = url;
if (f.text != undefined)
f.text.value = text;
if (getCookie("mtcmtauth") || getCookie("mtcmthome")) {
f.bakecookie[0].checked = true;
} else {
f.bakecookie[1].checked = true;
}
}
if (f.email != undefined)
f.email.value = email;
if (f.author != undefined)
f.author.value = author;
if (f.url != undefined)
f.url.value = url;
if (f.text != undefined)
f.text.value = text;
if (getCookie("mtcmtauth") || getCookie("mtcmthome")) {
f.bakecookie[0].checked = true;
} else {
f.bakecookie[1].checked = true;
}
}
And, put the following code after every use of MTCommentFields.
CODE
<script language="javascript" type="text/javascript">
<!--
if (document.comments_form)
fillCommentFields(document.comments_form,
'<$MTCommentPreviewEmail encode_js="1"$>',
'<$MTCommentPreviewAuthor encode_js="1"$>',
'<$MTCommentPreviewURL encode_js="1"$>',
'<$MTCommentPreviewBody convert_breaks="0" encode_js="1"$>');
//-->
</script>
<!--
if (document.comments_form)
fillCommentFields(document.comments_form,
'<$MTCommentPreviewEmail encode_js="1"$>',
'<$MTCommentPreviewAuthor encode_js="1"$>',
'<$MTCommentPreviewURL encode_js="1"$>',
'<$MTCommentPreviewBody convert_breaks="0" encode_js="1"$>');
//-->
</script>
Is it simple, isn't it?
The workaround I posted does not modify lib/MT/Template/Context.pm (or any other MT file) at all - it uses a template module to replicate the functionality of the MTCommentFields tag. The template module code was then edited to address a number of problems with MTCommentFields, including the problem with the blank comment fields on the Comment Preview and Comment Error templates.
I guess simpler is in the eye of the beholder. I didn't think my workaround was that difficult to implement, plus it can be reversed / uninstalled just as easily as it was installed. One of the things I thought was a "benefit" to my workaround was that if a user wanted to change something, they just edit a template module instead of having to hack Context.pm or some other MT file.
Personally, I'm resistant to doing too much hacking / patching to the MT3D code, because MT's developers are actively working on trying to fix as many bugs as they can; plus, when I help users here in the forums, I often look at my code for reference, and I need to be looking at the same code they're using.
I guess simpler is in the eye of the beholder. I didn't think my workaround was that difficult to implement, plus it can be reversed / uninstalled just as easily as it was installed. One of the things I thought was a "benefit" to my workaround was that if a user wanted to change something, they just edit a template module instead of having to hack Context.pm or some other MT file.
Personally, I'm resistant to doing too much hacking / patching to the MT3D code, because MT's developers are actively working on trying to fix as many bugs as they can; plus, when I help users here in the forums, I often look at my code for reference, and I need to be looking at the same code they're using.
Basically, my stance is similar to yours. I didn't change the MT codes unless they had unquestionable typo or similar. And I also didn't change the template unnecessarily, and kept changes small if needed. And, my patch is not just for MTCommentFields, but for fixes for Cookie bugs and QuickPost bugs.
Major difference is:
(You) define the semantics of another MTCommentFields by yourself (undoubtfully it's reasonable), separating from MT3's MTCommentFields' implementation. Using a template, there's no modification needed to MT3 core.
(I) don't want to change the meaning of MTCommentFields anyhow. Because it should depend on MT3's core implementation and should be common to all users of the developer edition. I think the (current) meaning of MTCommentFields is putting necessary fields and keeping them blank. So I put small Javascript to fill these fields. Of course I don't need any changes to MT3 core. Even if SA changes its semantics, I just change or remove this Javascript. That's the *benefit* of my approach.
I just want to introduce another solution because I think it may be helpful for you and the forum.
Anyway, unlike you, I don't have energy to support my patch for all of this forum users if I want to do so...
Major difference is:
(You) define the semantics of another MTCommentFields by yourself (undoubtfully it's reasonable), separating from MT3's MTCommentFields' implementation. Using a template, there's no modification needed to MT3 core.
(I) don't want to change the meaning of MTCommentFields anyhow. Because it should depend on MT3's core implementation and should be common to all users of the developer edition. I think the (current) meaning of MTCommentFields is putting necessary fields and keeping them blank. So I put small Javascript to fill these fields. Of course I don't need any changes to MT3 core. Even if SA changes its semantics, I just change or remove this Javascript. That's the *benefit* of my approach.
I just want to introduce another solution because I think it may be helpful for you and the forum.
Anyway, unlike you, I don't have energy to support my patch for all of this forum users if I want to do so...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.