Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Make extensions aware of comment editor

edited April 2009 in Vanilla 1.0 Help
This is something I keep hitting with extensions, and suspect the only way around it would be some support in the core (perhaps Vanilla 2.x?).

There are many extensions that add features to the input side of commenting. The problem is, some only work with the textarea editor, and some only work with a GUI editor. Since users are allowed to chose whether to use the GUI editor or not, it is difficult to install these extensions because they will behave differently for different people.

I think what is needed, is either core support so extensions can detect what kind of editor is being used and change their behaviour, or perhaps for the extensions to be able to declare whether they require a GUI editor or not, and get enabled or disabled automatically as appropriate.

An example is the 'quote' extension - there are two versions available, one for GUIs and one for non-GUI commenting. Neither are aware whether the GUI editor is present or not. If I could install both, and have one or the other being enabled automatically when users are writing comments, then that would solve a lot of problems.

I think this is more a question on how it could be implemented, or a heads-up for Vanilla 2.x more than a request for any specific extension or piece of code.

-- Jason


  • edited April 2009
    A solution would an JavaScript framework to to manipulate some area of the forum; so that a quote extension doesn't have to manipulate the DOM directly update the comment area. An extension could extend or overwrite that this framework if it breaks it.
  • Alternatively, you could just build the quoting capability to quote into the editors?
  • judgejjudgej
    edited April 2009
    I like the framework idea. A framework API (and it does not have to be complicated) could allow direct access to the editor DOM, regardless of where it is or how it is wrapped. "We" could build the quoting capability to quote directly into the editors, but "we" are just the users of these extensions, and getting updates to extensions where the author is just no longer interested for whatever reason, is very difficult.

    Quoting is just one example. There are embedded pictures, links to previous comments in the discussion, other embedded media, etc. The point of the framework would be to say to the extension developers, *if* you are going to manipulate the DOM of the editor box, then do it through *this* API and you can be sure it will work across a range of editors that exist or will exist in the future. There is nothing preventing people from ignoring that and going direct, of course.

    So - would a framework itself also be an extension, that other extensions would depend on?

    -- Jason
Sign In or Register to comment.