@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.
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 ?
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.
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