Discourse Retort

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.

3 Likes

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. :man_shrugging: 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. :crossed_fingers:

3 Likes

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.

7 Likes

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.

2 Likes

I guess the answer is No? I would like to migrate to reactions and try to find the popular onesā€¦

1 Like

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?

2 Likes

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:

ā€œ: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:ā€

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:

  • :+1: 161
  • :-1: 1
  • :100: 1
  • :arrow_right_hook: 1
  • :astonished: 9
  • :blush: 2
  • :boom: 2
  • :brain: 23
  • :bulb: 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.

6 Likes

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.

2 Likes

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.

3 Likes

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. :frowning:

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.

1 Like

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.

2 Likes

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 hit q 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.

6 Likes

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.

1 Like

With the new Ember 5 changes, Retort is now dead. Exploring options to preserve its functionality.

1 Like