Created a fix and submitted a PR since @gdpelican has not responded in the last week. You can use the alternate repo till the fix is integrated into the main repo.
Alt repo: https://github.com/PuttyTribe/babble
PR: https://github.com/gdpelican/babble/pull/302
To switch just change your config and replace the existing babble repo with: https://github.com/PuttyTribe/babble.git and rebuild
Oh, lol, seems like we have a beauty parade 
https://github.com/gdpelican/babble/pull/303
The error is due to this change in core:
@angus I’ll let you be the judge
ooo timing hey! 
no activity for a week and then two solutions 20 minutes apart!
I did originally choose that solution but decided to just go with a catch-all since the param is not used in any case.
I’ve merged @merefield’s PR which fixes the issue here.
@ti0 Thanks also for the PR. The argument is used actually 
If you call super without arguments (i.e. instead of super()) the arguments of the subclass are automatically passed to super. If you take a look at the method that’s being overridden you’ll see where the argument is being used: discourse/lib/search.rb at main · discourse/discourse · GitHub.
@ti0 @merefield As a side note, we should make a PR into Discourse core here to add a hook for adding new type_filters into the Search class from a plugin. It would be more performant / stable than patching the execute method. Could be a interesting little project if you managed to convince the Discourse team it was worthwhile as an addition.
@justin Did you end up resolving this? I found the same issue until I just changed the way babble loads its engine in my own branch. I suspect it’s something to do with how different environments are treating @gdpelican’s method of loading files in the initializer, i.e.
require Rails.root.join('plugins', 'babble', 'app', path).to_s
Hard to pin down exactly. I might make a PR to update the Babble file loading method and see if @gdpelican is on board with changing that to the standard Discourse plugin method of using load with File.expand_path instead of require with Rails.root.
edit I’ve also added Babble to try.thepavilion.io so you can test it in an environment that’s udpated every 24 hours.
In the future, if there’s a critical bug with Babble (i.e. it’s not working entirely) and James is not available, please @angus or @merefield and we’ll fix it (or review a PR ).
I meant the param is not used within the overridden method that we changed. Based on what you are saying, my code should still work, because the super call would just past the **args which collects named arguments, and it is more stable if other parameters get added in the future. Does that make sense ? Or am I missing something there ?
Yes, you’re right
Just did a little test and your way also seems to work for the immediate purposes (i.e. it preserves readonly_mode functionality). It’s a bit conceptually strange when you think about it as the **args theoretically should be set prior to the superclass being called at all. Personally (and perhaps James would have a different view) I think I still prefer the more explicit way, as we’re already passing args implicitly by just calling super, adding some extra implicitness with **args seems like it’s getting a bit too complex.
While I understand what you’re driving at, on balance, I find the better course of action in these situations is to seek to find an explicit way of avoiding conflicts with the core code, rather than via catchall implicit methods. That approach tends to lead to other issues down the line. As mentioned above, I’d prefer if we were able to refactor this by seeking to add a new type_filter in the core codebase. That would be a good little project I reckon.
Is it possible to globally set “open chat automatically on page load” as yes for all users by default?
Is it possible to get URLs to render in Babble like the do in Threads?
Example would be posting a Twitter link in Babble Chat and it shows the tweet contents instead of just the URL.
Has anyone integrated with Memberful and then had their users real name show up under their account name in the chat?
I’d like to hide their real name from showing if at all possible.
Edit: I have a temporary fix, have members use their screen name as their full name during signup, or I manually edit their full name to match screen name after they are onboard.
Does anyone use this as of September 17th, 2020?
just wanted to check if this was not a side project
@angus, you may be the most available Babble helper at this point. So I’m pinging you with a code update request, although I’d be happy for anyone to address this.
I just update our Discourse version to 2.6.0beta2 (specifically this GitHub commit version) and the emoji picker is broken now.
@itsbhanusharma helps with our Discourse install and his initial thought is a compatibility issue with the emoji picker update in Discourse core.
Environment:
Browser: Firefox or Chrome (latest build)
View: Desktop, tablet, and mobile
Ability to Reproduce Issue: 100%
Steps to reproduce:
Expected result:
The emoji picker UI opens
Actual result:
Nothing happens. No emoji picker window opens.
If it doesn’t complicate things, whomever fixes the emoji picker issue may also want to fix a missing translation.
When you click on the “…” icon next to a chat message, the Flag option shows as “[en_US.post.actions.flag]” instead of “Flag”.
The emoji picker in Babble is no longer functioning for my site as well.
Also my chat is randomly scrolling up as well. I believe this was an issue once before as well.
@angus or anyone else who has the tech skills to help with Babble these days – do you have any hope of fixing the two issues I reported three weeks ago in this forum reply?
Thanks for the prompt Joel.
I’ve added support for the new Discourse emoji picker
I’ve addressed this as well.
Hi @angus, thank you for your hard work on this plugin!
My discourse system works with a custom long polling base url. As I just added Babble, I see that it doesn’t add any Access-Control headers (CORS), making a number of requests to fail.
I could possibly write a fix, if you point me to the right direction on the code.
After installing latest discourse updates and the latest version of babble (a couple of days ago, and again yesterday to see if it was fixed), I have problems with sending messages as well as the read indicator is stuck showing there are new messages.
Just now when I was unable to send a message I got a bunch of this error in the browser console:
Uncaught Error: No Reason Phrase
jQuery 13
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
_ember_jquery-865569b174cc91f4563f3552f437b32c6eadf9f6c3d49eae02cfe50e5a8c7dfa.js:38573:14
jQuery 13
u self-hosted:1177
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
There were detected accounts with strange user names (which begin from “f5c…” e.g. f5cfe2e6cc098d ) in the list of forum accounts - This is the problem of a specific user or something else?
Has your plugin seen such a problem before?
