[#93] - Editor Object
- Closed
- 24 Jun 2013
- Medium
- Build: master
- # 93
JEditor is coupled to the CMS too much to use. So, we need to build the editor object for use on the issue description field. I'm a fan of how it is implemented now (looks and feels just like the GitHub editor here), so if possible, replicate it.
- Implement editor object
- Preview function parses user input (code in Platform version of the app should be usable with tweaks)
- Prevent abuse of the preview function (#62)
Nice!
hmmm... having a triple backtick button would save me six key strokes.....
Bring it in ! 
Just done it :)
BTW I did it with two commits: to editor branch on my local machine and then merge into framework. But these has the same code diff. How to avoid this in the future?
@mbabker I can not think of a way to abuse the preview function.. As you wrote in #60
As for the rate limit, items will only be parsed in the hooks and preview, which is the only potential place for abuse. User input text should not have to go through the parser when submitted from within the app.
Is this still valid ?
Preview requests are now made on behalf of the currently logged in user. So every user get's 5000/hour. If he/she manages to pass the limit, subsequent requests to the GitHub API will only be denied for that specific user.
What am I missing here ?
At this point, nothing. If the request is against the user's rate limit, I have no clue how anyone would manage to get that many requests in with the UI.
-
Fixed & closed
There is a teeny-tiny editor "thingy", which is not more than a
<textarea>contained in bootstrap tabs right nowhttps://github.com/joomla/jissues/blob/framework/templates/editor.twig
It supports however a preview functionality by making AJAX requests to GitHub.
On the "abuse" side:
Every request is made on behalf of the currently logged in user. So every user has a rate limit of 5000 -- hard to exceed for a human being...
There is no "preview" functionality for guests.