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.

How to view the source text of other people's comments?

I would like users to be able to view the source for other people's comment and discussion text. This is useful to be able to see markdown, html and math-text source (in latex, we are using MathJax).

Ideally, what I would see is instead of the "Edit" option which I see for my own comments, a "View source" option, which pulls up the same dialog as the edit window, but which doesn't have all of the buttons at the bottom for saving, etc. (Just one button called Done, for closing the panel.) I like the format of this entry panel, and the way that it is friendly to selection.

Alternatively, the standard Edit button could be left in place, and a permissions check would be performed -- checking whether I am the owner of this comment -- and used to disable the buttons Save, Preview, etc. which are not authorized. Only Cancel would remain enabled.

What do people think about the best / cleanest / easiest way to go about this. As stated in the previous request, it sounds like a core feature request. But do you think that this could be naturally handled through a plugin? I am glad to take this project on, but haven't written any plugins myself, so any guiding comments would be appreciated.

Comments

  • This could easily be done via a plugin.

    Have you written any?

    I highly suggest you check out the quickstart guide here: http://docs.vanillaforums.com/developers/plugins/quickstart/

    I also have a testing ground plugin that I use for testing out plugin ideas here:
    https://github.com/hgtonight/Plugin-TestingGround

    I tried to comment that as much as possible for others benefit.

    Good luck!

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • Thanks for the good pointers.

    I've tweaked other plugins, but haven't yet written any of my own.

    This will be my first. I'll let you know when either I have something that works or...I get stuck :)

    Thanks!

  • Instead of simulating the edit function where content is shown in place, I would preferably show this in a popup. That way users couldn't mix up the functionality and get confused. You can also add some information like the Format to the popup.

  • Thanks for that input. I agree that it should be clear to the user that they are seeing a read-only view of the source.

    I'm looking for a clean, minimally invasive way to do this. If it involves less code it will also be better because I'm not experienced with these web programming languages.

    Conceptually the requirement is simple: if the user does not have permission to edit the message, then, rather than summarily dropping Edit from the options menu, change the menu item to say View Source, and bring up the dialog in a read-only mode.

    I like the idea of reusing the same UI component for View-Source as for Edit, since it can be thought of as a reduced permissions view of the same data. Then, as the Edit view evolves with Vanilla, so would the View-Source. (If I created a new UI component, we could be pretty sure that it would look like it was made by an amateur UI person -- and it would be another UI element to maintain over time.)

    What I've seen from the code so far is that the menu option could easily be changed in the helper_functions.php (for two different views, discussion and discussions), right at the point where it says: if CanEdit then add the edit option. For the view-source option, a variant method for EditDiscussion could be created in class.postcontroller.php, which passes a flag to the function that renders the discussion, telling it to omit the controls that are used to Save, etc.

    But wait a minute, this is hardly minimally invasive surgery! Even if I did it in a plugin, I would be overridding the implementation of functions that are deep into the core of the package (or cloning them into variants) -- and this would not play well with future releases, which are likely to involve development in these parts.

  • You are on the wrong track when thinking about changing core files. Look at that part of the QnA plugin: https://github.com/vanilla/addons/blob/master/plugins/QnA/class.qna.plugin.php#320-333

    If you have a simple plugin skeleton, all you have to do is to implement a public function DiscussionController_CommentOptions_Handler($Sender, $Args) { and a public function DiscussionController_DiscussionOptions_Handler($Sender, $Args) { to have two functions that insert an option to the discussion and the comments.

    See https://github.com/vanilla/addons/blob/master/plugins/QnA/class.qna.plugin.php#332 That line is all that needed (in the right function!) to add an entry to the options menu.

    If you need more, just ask ;)

  • @R_J said:

    ...There is no url that you can call which fetches unformatted Discussion/CommentBody...

    http://vanillaforums.org/discussion.json/comment/225771/

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • @hgtonight: I should have checked instead of assuming... But I like my post anyway :P

  • @R_J said:
    ...I like my post anyway :P

    Me too <3

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • Fantastic, thanks guys.

  • @R_J: This is a great roadmap for how to get started with this kind of plugin, Thanks.

    I have gotten to work all of the elements you described.

    The Vanilla architecture is really nice!

    One issue: whenever the popup comes up with text ABC, a "notification" message is also shown with text ABC, in a grey-backgrounded panel to the left. There is a light-bulb icon at the top left of the panel. One has to X out this panel to dismiss it.

    Is there a way to suppress this notification?

    Here is the code I have:

      public function DiscussionController_CommentOptions_Handler ($Sender, $Args) {
        $Comment = (array)$Args['Comment'];
        $CommentID = $Comment['CommentID'];
        $Path = 'plugin/ViewComments/' . $CommentID;
    
        $Args['CommentOptions']['ViewSource'] = array(
        'Label' => 'View Source',
        'Url' => $Path,
        'Class' => 'Popup Hijack'
        );
      }
    
      public function PluginController_ViewComments_Create ($Sender, $Args) {
        $CommentID = $Args[0];
    
        $CommentModel = new CommentModel();
        $Comment = $CommentModel->GetID($CommentID);
    
        $text = nl2br($Comment->Body);
    
        echo $text;
      }
    
  • Really don't know why. Try to leave out the Hijack but that's only a desparate guess...

  • I think it is because you are not calling the $Sender->Render() function. This function does a lot more than just rendering (like closing the db connection properly) and is essential to getting the right data displayed.

    Set the unformatted comment body as data on the controller, render a view that just spits it out, and call the render function.

    E.g.

    $Sender->SetData('CommentBody', nl2br($Comment->Body));
    $Sender->Render($this->GetView('viewcomments.php'));
    

    Then in your /plugins/GloriousThing/views/viewcomments.php:

    <?php if (!defined('APPLICATION')) exit();
    echo $this->Data('CommentBody', '');
    

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • Very nice, thank you.

Sign In or Register to comment.