I opened a new request Support multiple-reactions per post (Retort style) about multiple-reactions-per-post, since the other link is only for offering more reaction choices for the one-and-only reaction that Discourse Reactions allows.
The Retort plugin isnāt an official one so we donāt have any say in when it stops being actively developed and maintained by the community. The best we can do is try and keep people informed where possible so they have some time to find an alternative (or at least give their members a heads-up to try and soften the disappointment).
Hopefully those two feature requests will be adopted into the reactions plugin at some point, but as yet theyāre still in the ānice ideasā stage. But Iāve got my fingers crossed.
I understand where youāre coming from. The reality is that neither I or James have had the time to properly support Retort for some time. Youāll notice that the last commit on the repository is over a year ago (by me on 21 July 2021). Itās great that the plugin has continued to work this long and it is a testament to the quality of the work James put into building it.
When I say I donāt have the time, believe me, I wish I did! I feel sad every time I have to make one of these decisions (like with the Landing Pages Plugin). I didnāt build Retort, but I have invested time in it. When you decide to retire something, itās like accepting that something youāve created or loved, and spent many hours, days and weeks of your life with, must die. I know it was a tough decision for James to make when he felt he had to move on to other things.
By contrast, the Reactions Plugin is being maintained by Discourse.org, an organisation of over 60 people, on an active basis. Itās in use on a number of the servers used by Discourse.orgās clients. Yes, it doesnāt have the same features as Retort yet, but I would urge you to pursue that feature development as an avenue. Perhaps you could convince someone like me, or another member of Pavilion, to PR a missing feature into the plugin. That would be a smart avenue to achieve your long term goals here.
There is always marketplace if you want to pay a developer to bring it back to life in the meantime. But you may end up having to do this multiple times or agree a maintenance retainer.
I guess the answer is No? I would like to migrate to reactions and try to find the popular onesā¦
I imagine it would be possible as theyāll be stored in the database somewhere. Unfortunately I donāt have this plugin installed on my test site to check the specifics. Is there a discourse-retort-retorts table or similar?
Hereās how to get a |
-separated string for the retorts you currently have in use:
# ./launcher enter app
# rails c
retorts = {}
PostDetail.where(extra: 'retort').each do |p|
retort = p.key.split('|').first
(retorts[retort] ||= []) << p
end
retorts.length
retorts.keys.join('|')
That gives you:
- First the number of unique retort emoji used
- Then the retorts in a form you could paste into Reaction configuration, perhaps after trimming if itās too long to work for the Reactions UI.
For me, I get this string:
tada|rage|money_with_wings|face_vomiting|crossed_fingers|grin|vulcan_salute|worried|slightly_smiling_face|dart|+1|relaxed|star_struck|upside_down_face|sweat_drops|astonished|frowning_face|champagne|heavy_plus_sign|bulb|joy|fireworks|zap|smile|fast_forward|grinning|clap|sandwich|heart_eyes|rofl|smiley|wave|ice_cream|sob|mortar_board|open_mouth|pray|grimacing|roll_eyes|arrow_right_hook|brain|wink|cry|nerd_face|slight_smile|confused|ok|thinking|it|heart|smirk|sleepy|eyes|disappointed|question|laughing|man_shrugging|drum|shushing_face|herb|man_facepalming|ear|scream|ok_hand|mantelpiece_clock|smiling_face_with_three_hearts|confetti_ball|sunglasses|nose|pirate_flag|neutral_face|sweat_smile|gift|pensive|dark_sunglasses|exclamation|call_me_hand|green_heart|face_with_monocle|blush|boom|hugs|stuck_out_tongue|zipper_mouth_face|slightly_frowning_face|face_with_raised_eyebrow|exploding_head|information_source|sailboat|fire|gun|carousel_horse|sparkles|hearts|pizza|frowning|drooling_face|-1|100|metal|partying_face|four_leaf_clover|grinning_face_with_smiling_eyes|scream_cat|person_shrugging|deciduous_tree|sunflower|see_no_evil|hear_no_evil|speak_no_evil|å¾®ē¬|top|face_with_peeking_eye|face_with_hand_over_mouth|stethoscope|money_mouth_face"
If youād like to copy a list of existing retorts into a post in discourse to discuss what to keep when migrating to Reactions, you might instead use this:
":" + retorts.keys.join(': :') + ':'
For me, thatās currently this set:
ā
:å¾®ē¬:
ā
To get a bullet list of emojis with the number of instances of each:
retorts.keys.sort.each do |k|
puts "* :#{k}: #{retorts[k].length}"
end
I wonāt paste the whole bullet list of emoji, but it starts like this:
-
161
-
1
-
1
-
1
-
9
-
2
-
2
-
23
-
3
If you want to see every post that exists for each emoji:
retorts.keys.sort.each do |k|
puts "* :#{k}: #{retorts[k].length}"
retorts[k].each do |r|
p = Post.find_by(id: r.post_id)
next if p.nil?
puts " * #{p.full_url}"
end
end
Thatās way too long to paste here!
What I donāt know is how to migrate all ā or some of ā those retorts to reactions. There is no mention of retort in the reactions plugin so it doesnāt do it automatically. I have 927 reactions with 116 unique emoji that Iād like to migrate to reactions.
I expect that Iāll be faced with dealing this at some point, preferably before Retort just quits working; if I implement the migration Iāll plan to document it here. But at least knowing what you have might help you.
In writing some experimental code to migrate Retort to Reactions, I have discovered that Retorts arenāt updated when usernames are changed.
I think that this will not be true with Reactions because PostActions
joins to actual user records, rather than recording user names in a JSON blob in PostDetail
.
In general, if someone decided that they wanted to adopt and maintain Retort, they should consider migrating from PostDetail
to PostActions
following how Reactions was done.
Similarly, it does not recognize when posts are deleted.
My Script framework to rearrange topics and categories has grown a new function that goes a little beyond rearranging topics and categories!
I usually remember to warn folks that I donāt know ruby or ruby on rails, so my code is idiosyncratic rather than idiomatic. But it seems to work so far in my testing!
def migrateRetortToReactions(allowed:, likes: nil, emojimap: nil)
# migrate where possible without overriding any existing likes
# this is a necessarily lossy conversion, and is consistent only by ordering of PostDetail
# no attempt is made to prefer one PostDetail record over another
emojimap = {} if emojimap.nil?
allowed.each do |a|
emojimap[a] = a
end
retort = "retort".freeze
emojiType = "emoji".freeze
usermap = Hash.new { |hash, username| hash[username] = User.find_by_username(username) }
postmap = Hash.new { |hash, post_id| hash[post_id] = Post.find(post_id) }
likeType = PostActionType.where(name_key: "like").pluck(:id).first
PostDetail.where(extra: retort).each do |pd|
begin
p = postmap[pd.post_id]
rescue
# PostDetail not consistent WRT delete
$stderr.puts sprintf("Could not find post for %d: %s / %s", pd.post_id, pd.key, pd.value)
next
end
emoji = pd.key.split('|').first
users = JSON.parse(pd.value)
users.each do |user|
u = usermap[user]
next if u.nil? # changed user name or deleted user leaves orphaned Retorts
if likes.include?(emoji)
pa = PostAction.where(post_id: p.id, user_id: u.id, post_action_type_id: likeType).first
next unless pa.nil?
$stderr.puts sprintf("Adding like for Retort %s for user %s in %s", emoji, user, p.url)
PostActionCreator.create(u, p, :like, created_at: pd.created_at, silent: true)
elsif emojimap.has_key?(emoji)
e = emojimap[emoji]
r = DiscourseReactions::Reaction.where(post_id: p.id, reaction_type: emojiType, reaction_value: e).first_or_create
ru = DiscourseReactions::ReactionUser.where(user_id: u.id, post_id: p.id).first
next unless ru.nil?
$stderr.puts sprintf("Converting Retort %s to Reaction %s for user %s in %s", emoji, e, user, p.url)
DiscourseReactions::ReactionUser.create(reaction_id: r.id, user_id: u.id, post_id: p.id, created_at: pd.created_at)
else
$stderr.puts sprintf("Ignoring unmapped Retort %s for user %s in %s", emoji, user, p.url)
end
end
end
end
I use the framework I built to provide a yaml configuration that looks like this:
- migrateRetortToReactions:
allowed:
- rofl
- astonished
- crossed_fingers
- sob
- thinking
- grimacing
- frowning_face
- drum
likes:
- dart
- +1
- joy
- "100"
- brain
- heart
- heart_eyes
- hearts
emojimap:
rage: sob
four_leaf_clover: crossed_fingers
cry: sob
open_mouth: astonished
scream: frowning_face
However, you could just wrap that up in a ruby script including making those arguments literal ruby code, drop it in the script/ directory, and run it.
Hey guys, as discussed in the topic above Iāve already written a migration feature of Retort to Reactions, including an admin UI.
For it to be production ready the maintainers of Reactions will need to make a slight change to improve the abstraction of the code in the Reactions plugin.
Supporting a production level migration between two plugins like this requires significant quality assurance otherwise issues like this can easily occur.
Iām sorry! I had missed those post and had merely looked in the main branch. Itās a long threadā¦
I agree. I completely side-stepped it. Itās more than just ReactionManager.toggle! though ā it really needs to pass through created_at
doesnāt it?
The move to Reactions really changes the semantics of ālikeā because you canāt take it back when someone edits their post. I would not have made the same implementation choice.
In any case, what I want to do is drive this from a script, and I have no interest whatsoever in driving it from a UI. Iām not the target audience for the UI, so maybe my hack being available doesnāt hurt.
By all means, I didnāt mean to discourage you writing it for your own purposes, but I wouldnāt advise other sites to use it unless theyāre familiar with the code and the data structure.
The bottom line is that the Reactions Plugin isnāt currently written in a way conducive to a stable migration that will work reliably across environments.
If anyone wishes to migrate from Retort to Reactions, Pavilion is handling these manually on a contract basis (email contact@pavilion.tech or PM me). If the Reactions Plugin is updated to allow for generalized migrations weāll complete the migration work to make this freely available.
Aha. This answers some questions Iāve had. Itās hard to make sense of 450 posts over 7 years.
So do I understand that what āneedsā to happen (anyone is welcome to supply their own definition of āneedsā) is to somehow extend Reactions so that it can more cleanly handle migrating data to it and also providing features that it is missing?
How big a job is that in some wild guess of hours or dollars?
This is broadly still accurate.
If the opportunity for a PR is realistically there Iād probably just do it for a good bottle of red. It is Friday night after all.
But, being slightly more serious, what weāre talking about here is a minor refactor of the Reactions plugin ReactionManager
. That kind of work is typically not accepted via PR. There would need to be buy-in from the maintainers of Reactions.
I think you also would want to make sure the likes are silent
and created_at
is handled for likes and reactions; otherwise users are spammed with notifications from the migration. (I saw this in my test site for my own login.)
For some reason, even with created_by
handled, I still trigger the out of love
max likes, and I didnāt investigate further, because I got rid of all the other notifications.
@joffreyjaffeux any reason not to expose the necessary functionality for a clean migration?
I have just moved to Reactions (because I guess it is official and allā¦ ) but would hate to lose all previous retort data.
Iām sorry, but providing a stable migration is not possible at the moment for the reasons mentioned above.
Well, it now happened, I could not update discourse because of the retort plugin.
This is the database migration error I got:
could not create unique index "index_post_details_on_post_id_and_key_ccnew_ccnew" DETAIL: Key (post_id, key)=(30297, +1|retort) is duplicated.
I used this script as a base for my own migration code. Hereās what I did.
- To get discourse working again, I had to override the āversionā in the template .yml file to a commit from about two weeks ago in discourse repo
- Rebuild with the reactions plugin added to get the site back up
- I configured the reactions plugin with the same set of reactions as retort. I do not use any reaction that could be interpreted as like
- I used @mcdanljās script a bit modified with the following steps (as I wanted to migrate all retorts and I had 1-to-1 mapping between retorts and reactions already):
- Run
./launcher enter app
- Run
rails c
- Paste in the following (it seems that rails console will echo back the code with incorrect line changes, I added double line changes but that didnāt really change the output, but if someone gets a syntax error with the following code, add an extra line after each line):
def migrateRetortToReactions()
retort = "retort".freeze
emojiType = "emoji".freeze
usermap = Hash.new { |hash, username| hash[username] = User.find_by_username(username) }
postmap = Hash.new { |hash, post_id| hash[post_id] = Post.find(post_id) }
likeType = PostActionType.where(name_key: "like").pluck(:id).first
PostDetail.where(extra: retort).each do |pd|
begin
p = postmap[pd.post_id]
rescue
# PostDetail not consistent WRT delete
$stderr.puts sprintf("Could not find post for %d: %s / %s", pd.post_id, pd.key, pd.value)
next
end
emoji = pd.key.split('|').first
users = JSON.parse(pd.value)
users.each do |user|
u = usermap[user]
next if u.nil? # changed user name or deleted user leaves orphaned Retorts
e = emoji
r = DiscourseReactions::Reaction.where(post_id: p.id, reaction_type: emojiType, reaction_value: e).first_or_create
ru = DiscourseReactions::ReactionUser.where(user_id: u.id, post_id: p.id).first
next unless ru.nil?
$stderr.puts sprintf("Converting Retort %s to Reaction %s for user %s in %s", emoji, e, user, p.url)
DiscourseReactions::ReactionUser.create(reaction_id: r.id, user_id: u.id, post_id: p.id, created_at: pd.created_at)
end
end
end
- At this point I made a site backup just in case
- Then run
migrateRetortToReactions
which should take a while. For me I didnāt see or run into any issues. After running the console seems to show all the changed objects so hitq
to exit - Now on the site it should be the case that the data is migrated correctly
- As a final step you need to run:
PostDetail.where(extra: "retort").destroy_all
which will delete the retort data - Now I was able to then rebuild my site with latest discourse version and without the retort plugin
So all in all, not that difficult to migrate but it was pretty scary, and as discussed before this overwrites likes with reactions on posts that had both likes and retorts by the same user.
Agreed! Multiple reactions and being able to pick from all reactions is a must for my community. People have come to expect it from the Discord chat server world so reverting that feature in my community is a no-go. Fortunately, this plugin has not broken yet for me, but I am consigned to the reality that I am slowly counting down the days. I hope the desired solution comes either from the third-party community or Discourse officially in the next six months. Otherwise, I would be forced to hold my forum at an older build version indefinitely if it ends up being that this plugin breaks updates down the line.
With the new Ember 5 changes, Retort is now dead. Exploring options to preserve its functionality.