With huge thanks 
to the sponsorship of @Hifihedgehog and the community of:
This has been brought back into compatibility and is no longer broken with 3.2.
NB: as per The Team and Sam, it is intended that the Reactions plugin will take on the additional features of this plugin (mainly the ability for multiple reactions) at some point in the future and hopefully (not yet confirmed) this will include provision of a migration tool.
Seem like there might be an issue 
- I’m going to take a look.
Fix has been merged:
For those who are interested, this fork maintained by SJTU Shuiyuan community staff also works: (
also installing this version will destroy your data used in the primary repo , see @merefield’s post below)
Why was there no PR?
Also I might point out though, on this fork, there are no:
Which are now implemented on the primary repo 
Also installing this version will destroy your data used in the primary repo
I see no warning of this in the README.
So I cannot recommend people even try that fork unless on a fresh instance with no history or you intend to rely on the author to maintain things in the future …
Maybe they are students, who are not fully open source enthusiast, or just lazy?
hmmm … no doubt some significant effort has been put into it, but not actively communicating and sharing this work with the community is not ideal because it leads to some level of duplication and in this case it destroys the data used in the primary repo! That alone should have been a really good reason to PR so the approach could have been reviewed and harmonised across the forks. Now these forks are incompatible and if you install this one, there is no going back! 
I’ve been using this plugin for years.
There was a change that ruined it, they moved the retorts in-line with the post controls, this ruined it on mobile, if the retort container stayed above the post controls like in this post Discourse Retort - #383 by Vaping_Community it would still be amazing, the ability to retort multiple times was a feature enjoyed by all
The new reaction plugin is good but it shows only one reaction.
Is it this line in the code that decides where to put the retort-container?
api.decorateWidget("post-menu:before-extra-controls", (helper) => {
On mobile it should be something like this?
api.decorateWidget("post-contents:after-cooked", (helper) => {
Tried doing something with CSS but no joy
Ok so I did a thing but I have no idea what I’m doing… I’ve been using this plugin since 2018
@merefield Please advise how to credit on my GIT, I really have no clue on how anything works
Git is here: https://github.com/GrubbyVc/Retort-Reloaded
I cloned the retort plugin and edited it to display the retort-container above the controls again, this allows for multiple retorts on mobile. I wanted to change it only for mobile but didn’t know how.
Note: This is the only change I made
retort-init.js.es6api.decorateWidget("post-menu:before-extra-controls", (helper) => {
api.decorateWidget("post-contents:after-cooked", (helper) => {
.topic-post.retort, button.post-retort {
padding: 8px !important;
}
.post-retort {
border: none;
padding: 2px !important;
background: rgb(0, 0, 0, 0);
&:hover .post-retort__tooltip {
opacity: 1;
}
&__tooltip {
opacity: 0;
transition: .5s opacity;
position: absolute;
bottom: 65px;
font-size: 12px;
text-align: center;
min-width: 125px;
max-width: 150px;
background: var(--primary);
color: var(--secondary);
font-weight: bold;
padding: 5px;
border-radius: 5px;
word-wrap: normal;
left: auto;
transform: translate(-50%, 0);
z-index: 1;
pointer-events: none;
word-break: break-word;
&:after {
content: " ";
width: 7px;
height: 7px;
bottom: -5px;
left: 44%;
transform: rotate(45deg) translate(-50%, 0);
position: absolute;
background: var(--primary);
}
}
&__count {
font-size: 12px;
padding: 1px;
position: relative;
bottom: 1px;
left: 1px;
font-weight: bold;
color: var(--primary-medium);
}
}
.post-retort-container {
background: rgb(0, 0, 0, 0);
}
.emoji-picker.opened.has-limited-set {
height: 159px;
background-color: #333 !important;
}
.emoji-picker.opened.has-limited-set {
top: 400px;
}
Generally it’s bad practice to create a new repo with a new name.
What you should consider doing is forking the main repo (which is easy there is a simple button), apply your changes to your fork and then later once you are fully happy and if you think the changes might be generally useful you PR to the main repo. Someone (usually the “maintainer”) will review your PR, possibly make some suggestions, allow you to update your PR and then merge it into the main repo.
That is best practice.
Ah, I will look in to that asap, thanks for the advice
The main reason for doing this is that then all maintenance activity can be focussed on one repo which is far far more efficient. (which you will possibly discover when there is a breaking change!)
Makes a lot of sense