Older

• Dec 19, 2008

  issue 32 (Patch for "Preview comment" feature) commented on by SirYes   -   Since I posted a new issue at http://code.google.com/p/briansthreadedcomments/issues/detail?id=33 this one may probably be closed. PS. When writing this very comment, the "Attach a file" action below comment area magically appeared. Now I look silly posting two issues for the same feature :oops:

  Since I posted a new issue at http://code.google.com/p/briansthreadedcomments/issues/detail?id=33 this one may probably be closed. PS. When writing this very comment, the "Attach a file" action below comment area magically appeared. Now I look silly posting two issues for the same feature :oops:
• Dec 19, 2008

  issue 33 (Improved patch for "Preview comment" feature) reported by SirYes   -   This one refers to http://code.google.com/p/briansthreadedcomments/issues/detail?id=32 Here I include a new, improved patch, which should hopefully work. I cleaned it a bit, added missing "el" variable, moved "visibility: hidden" style to a div tag, and provided the logic for changing the button's text from "Preview comment" to "Update preview" (and back after pressing "Hide preview"). I saw this on osnews.com and thought it was cool, but actually this made the mechanism a little flashy. If you think that changing button's text is unnecessary, just remove "var btn = ...; btn.value = ..." lines in onPreviewComment() and hidePreview() functions. I opened a new issue because I was unable to attach another file to the original issue. This looks like a bug in Google Code itself... ;)

  This one refers to http://code.google.com/p/briansthreadedcomments/issues/detail?id=32 Here I include a new, improved patch, which should hopefully work. I cleaned it a bit, added missing "el" variable, moved "visibility: hidden" style to a div tag, and provided the logic for changing the button's text from "Preview comment" to "Update preview" (and back after pressing "Hide preview"). I saw this on osnews.com and thought it was cool, but actually this made the mechanism a little flashy. If you think that changing button's text is unnecessary, just remove "var btn = ...; btn.value = ..." lines in onPreviewComment() and hidePreview() functions. I opened a new issue because I was unable to attach another file to the original issue. This looks like a bug in Google Code itself... ;)
• Dec 18, 2008

  issue 32 (Patch for "Preview comment" feature) commented on by setien   -   Cool that you made this, but I am afraid that it doesn't work. In the line where you assign something to innerHTML, you are assuming the presence of an "el" variable that has no value on my system. I suspect you are accidentally referring to a global variable that is accidentally set on your setup. I'll be happy to roll it into the codebase when it works properly.

  Cool that you made this, but I am afraid that it doesn't work. In the line where you assign something to innerHTML, you are assuming the presence of an "el" variable that has no value on my system. I suspect you are accidentally referring to a global variable that is accidentally set on your setup. I'll be happy to roll it into the codebase when it works properly.
• Dec 14, 2008

  issue 32 (Patch for "Preview comment" feature) commented on by SirYes   -   Err... What I really meant was: [Hide preview] button - instead of [Hide comment] This applies to attached .diff as well (sorry!)

  Err... What I really meant was: [Hide preview] button - instead of [Hide comment] This applies to attached .diff as well (sorry!)
• Dec 14, 2008

  issue 32 (Patch for "Preview comment" feature) reported by SirYes   -   In default installation there is no "Preview comment" feature at all. However, it's pretty straightforward to do. In 'comments.php': 1. Add [Preview comment] and [Hide comment] buttons before [Add comment] 2. Add a new <div id="preview"> below the buttons In 'briansthreadedcomments.php': 3. Add styles for #preview 4. Add new functions: hidePreview, onHidePreview, formatComment, onPreviewComment 5. Add "hidePreview()" call at the end of existing functions: moveAddCommentBelow, reRoot() 6. Enjoy satisified readers :) Attached is the .diff with said functionality, against briansthreadedcomments-1.5.20. With best regards, Wiktor Wandachowicz

  In default installation there is no "Preview comment" feature at all. However, it's pretty straightforward to do. In 'comments.php': 1. Add [Preview comment] and [Hide comment] buttons before [Add comment] 2. Add a new <div id="preview"> below the buttons In 'briansthreadedcomments.php': 3. Add styles for #preview 4. Add new functions: hidePreview, onHidePreview, formatComment, onPreviewComment 5. Add "hidePreview()" call at the end of existing functions: moveAddCommentBelow, reRoot() 6. Enjoy satisified readers :) Attached is the .diff with said functionality, against briansthreadedcomments-1.5.20. With best regards, Wiktor Wandachowicz
• Oct 26, 2008

  issue 31 (Addition of "Your comment is awaiting moderation." nessage) reported by ottantaventi   -   What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? I would like to show the message: "Your comment is awaiting moderation." when a comment ends in the moderation queue (like in the default comment.php) What version of the product are you using? On what operating system? 1.5.20 Please provide any additional information below.

  What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? I would like to show the message: "Your comment is awaiting moderation." when a comment ends in the moderation queue (like in the default comment.php) What version of the product are you using? On what operating system? 1.5.20 Please provide any additional information below.
• Oct 19, 2008

  issue 30 (Assumptions) reported by francesco.gavello   -   What steps will reproduce the problem? 1. Normal usage of the plugin What is the expected output? What do you see instead? Let the user select a custom content DIV tag, in case "content" is already taken by other parts of the template What version of the product are you using? On what operating system? All version. Please provide any additional information below. The plugin assumes that the default content DIV tag has the ID "content". Many users use custom templates with different content DIV tag, that makes the plugin not working.

  What steps will reproduce the problem? 1. Normal usage of the plugin What is the expected output? What do you see instead? Let the user select a custom content DIV tag, in case "content" is already taken by other parts of the template What version of the product are you using? On what operating system? All version. Please provide any additional information below. The plugin assumes that the default content DIV tag has the ID "content". Many users use custom templates with different content DIV tag, that makes the plugin not working.
• Sep 16, 2008

  issue 29 (Anchor link to post comment is incorrect, not working) reported by farialima   -   in version 1.5.20: on line 137 of comments.php, there's: <a href="#postcomment" title="<?php _e("Leave a comment"); ?>">&raquo;</a> but the anchor "postcomment" is defined nowhere ! which makes that the link doesn't work. Replacing the line 137 by the line below fixes the problem: <a href="#addcommentanchor" title="<?php _e("Leave a comment"); ?>">&raquo;</a>

  in version 1.5.20: on line 137 of comments.php, there's: <a href="#postcomment" title="<?php _e("Leave a comment"); ?>">&raquo;</a> but the anchor "postcomment" is defined nowhere ! which makes that the link doesn't work. Replacing the line 137 by the line below fixes the problem: <a href="#addcommentanchor" title="<?php _e("Leave a comment"); ?>">&raquo;</a>
• Sep 16, 2008

  issue 27 (Fatal error: Call to undefined function btc_has_avatars() wh...) commented on by farialima   -   Here's a workaround (actually a proposed fix): in file comments.php (for version 1.5.20) change the line 53 from <?php if (btc_has_avatars()) { // Gravatar support ?> to <?php if (function_exists('btc_has_avatars') && btc_has_avatars()) { // Gravatar support ?> that will fix it

  Here's a workaround (actually a proposed fix): in file comments.php (for version 1.5.20) change the line 53 from <?php if (btc_has_avatars()) { // Gravatar support ?> to <?php if (function_exists('btc_has_avatars') && btc_has_avatars()) { // Gravatar support ?> that will fix it
• Sep 16, 2008

  issue 23 (+/- icon does not show up) commented on by farialima   -   This may be the same as issue 28; there's a proposed fix there.

  This may be the same as issue 28; there's a proposed fix there.
• Sep 16, 2008

  issue 28 (Images (spacer.png, subscribed.png) not served because of er...) commented on by farialima   -   The workaround is to change the line 46 from: if(isset($_GET['image']) && 'briansthreadedcomments.php' == basename($_SERVER['SCRIPT_FILENAME'])) to: if(isset($_GET['image']))

  The workaround is to change the line 46 from: if(isset($_GET['image']) && 'briansthreadedcomments.php' == basename($_SERVER['SCRIPT_FILENAME'])) to: if(isset($_GET['image']))
• Sep 16, 2008

  issue 28 (Images (spacer.png, subscribed.png) not served because of er...) reported by farialima   -   In version 1.5.20, the images aren't served for me because on line 46 of briansthreadedcomments.php, there is: if(isset($_GET['image'])) && 'briansthreadedcomments.php' == basename($_SERVER['SCRIPT_FILENAME'])) and on DreamHost (my host), "echo basename($_SERVER['SCRIPT_FILENAME']);" shows "php.cgi". So, the images aren't served and the script fails afterward. This is usually caught by a fix in wp-settings.php (line 91 on WP 2.6.2): // Fix for PHP as CGI hosts that set SCRIPT_FILENAME to something ending in php.cgi for all requests if ( isset($_SERVER['SCRIPT_FILENAME']) && ( strpos($_SERVER['SCRIPT_FILENAME'], 'php.cgi') == strlen($_SERVER\ ['SCRIPT_FILENAME']) - 7 ) ) $_SERVER['SCRIPT_FILENAME'] = $_SERVER['PATH_TRANSLATED']; but when serving image, the script doesn't go through this file...

  In version 1.5.20, the images aren't served for me because on line 46 of briansthreadedcomments.php, there is: if(isset($_GET['image'])) && 'briansthreadedcomments.php' == basename($_SERVER['SCRIPT_FILENAME'])) and on DreamHost (my host), "echo basename($_SERVER['SCRIPT_FILENAME']);" shows "php.cgi". So, the images aren't served and the script fails afterward. This is usually caught by a fix in wp-settings.php (line 91 on WP 2.6.2): // Fix for PHP as CGI hosts that set SCRIPT_FILENAME to something ending in php.cgi for all requests if ( isset($_SERVER['SCRIPT_FILENAME']) && ( strpos($_SERVER['SCRIPT_FILENAME'], 'php.cgi') == strlen($_SERVER\ ['SCRIPT_FILENAME']) - 7 ) ) $_SERVER['SCRIPT_FILENAME'] = $_SERVER['PATH_TRANSLATED']; but when serving image, the script doesn't go through this file...