Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
ReplyTo Version 0.1.4 Released
judgej
✭
This version incorporates some suggested changes and some changes I had been planning for a while:
* New style to apply from level 1 upwards, so all comments that are a reply to something can be styled consistently.
* Styles now moved from the div.Comment element to its parent, the list item. Minor changes to the plugin stylesheet selectors to support this.
* New method of including the indentation styles in the theme; now handled in an event, but a single line of code in the theme is required to expose the classes to the event, for now (vanilla 2.0.11) at least.
* Generation of classes moved to its own function for reuse. If it is possible to put an event in, so people can override the generated classes, then I'll look into that.
* Comments that have a parent on a previous page now get a link pointing to that parent comment in the options list. This link will have class "ReplyToParentLink" in the next release so it can be hidden if not needed or restyled.
Have fun.
* New style to apply from level 1 upwards, so all comments that are a reply to something can be styled consistently.
* Styles now moved from the div.Comment element to its parent, the list item. Minor changes to the plugin stylesheet selectors to support this.
* New method of including the indentation styles in the theme; now handled in an event, but a single line of code in the theme is required to expose the classes to the event, for now (vanilla 2.0.11) at least.
* Generation of classes moved to its own function for reuse. If it is possible to put an event in, so people can override the generated classes, then I'll look into that.
* Comments that have a parent on a previous page now get a link pointing to that parent comment in the options list. This link will have class "ReplyToParentLink" in the next release so it can be hidden if not needed or restyled.
Have fun.
0
Comments
.ReplyToDepth-10plus {
Should read:
.ReplyToDepth-10plus .Comment {
'ReplyToDepth-1plus' is kinda very strange name for all nested comments. I think that 'NestedComment' is much more clear name.
The CSS bug was fixed in 0.1.4
.ReplyToDepth-10plus .Comment { padding-left: 15em; }
Is that it, or somewhere else?
You are disabling ajax for posting. I think you shouldn't do this for root level comments.
I'm assuming it is the redirect *after* posting that you mean, and you aren't seeing the posting form itself appear on a new page. It should only redirect on posting a reply to a comment. If it is redirecting after posting a top-level comment (the box always at the bottom of the page) then that is an unexpected consequence, and I'm not sure why that would be happening.
Please feed back any incompatibility issues with other modules, and I'll do what I can to fix them.
The functionality to close the form is already in the base classes of the theme, so is not added by this plugin. It could be that your theme does not contain that code? Could you try a different theme and see how that goes.
Also you could try this to see if the functionality is there: edit an existing comment using the "Edit" link. The form that pops up should have a "Cancel" button. Pressing that button should close the comment edit form in exactly the same way as the "reply" form. Does that work for you, or is that button also jumping to "/discussions"?
Cancel in default theme also takes to /discussions.
Cancel when editing also takes back to /discussions. In default theme too.
The URL is perhaps not as useful as it could be - it would make more sense to direct the user to the current discussion rather than the discussions index. It's not like the user is cancelling the creation of a new discussion. Raise that one as a Vanilla bug/FR perhaps?
Edit: Just a bit more information. The livequery is in applications/vanilla/js/discussions.js That's where all the hijacking of the Cancel buttons via a live query goes on. The ReplyTo plugin ensures the button gets the "a.Cancel" selector, and then that is where the core Vanilla code comes in to remove the ReplyTo or Edit forms when clicked, whithout jumping to another page.
I'm using version 0.6.1 of QS. I'll have a dig into its JS to see if there are any clues as to what it may be doing.
Edit: oh, hehe, it's your plugin :-) Took me a few minutes to realise that. The jumping issue even happens when editing a comment. If I edit a comment near the top of the page, then do a quote-select into that edit box, it copies the quote into the box okay, but then my browser window jumps to the bottom of the page where the "new comment" form it. I think if it jumps anywhere, it should be the form that it has just pasted into. Of course that *could* be an interaction with ReplyTo.