I ran into the same error in my plugin. Have created a pull request which should hopefully fix the problem. Not extensively tested but seems to work for me
Thanks David . I’m going to enable it again. I hope it will have no other problem.
I did installed back and its working again
Thanks for this plugin, it’s usefull.
I’ve a bug when someone writing a reply and someone else create a new topic:
On the screen, it’s a new topic.
Is this plugin currently working for others?
Following discussion here:
I have been working on improving this plugin. It now works with the latest Discourse, and now works for “editing” as well as “replying”. The indicator has been moved to the top right of the composer, and most importantly the ellipsis is animated!
I have updated the top post with new information and screenshots.
Very nice!! Let’s try it out in core!
PR to include discourse-presence as a core plugin:
I’ll merge it tomorrow morning unless someone else beats me to it
This is now merged - thanks @zogstrip
If you previously had this plugin installed you need to remove it from your app.yml file, otherwise the next rebuild will fail.
Minor nitpick here. I have an ultra-wide monitor. For me, the someone is replying appears way over on the edge of my monitor, far from the composer.
Any chance it could sit above the preview area instead of being flush right?
Side note, loving this new feature. Very helpful for me when dealing with PMs.
I hate when this happens, as unless you’re someone who reads every message here, you’re likely to have no idea that this is going to happen to you. Is there a way to modify the plugin to know to disable itself it it’s being included in a version of Discourse that doesn’t need it?
The issue is not with the plugin “disabling itself” - the rebuild problem occurs because you cannot clone the plugin git repo on top of a plugin that has the same name in core.
The only way would be to rename the core version of the plugin, and then empty the existing GitHub repo. I can make a PR if the team would like to do this.
For this plugin I’m hoping it won’t be too much of a problem, since it has been broken for the last few months anyway.
Thanks. This has happened with a few plugins that have moved to core. It sounds like there’s not an easy solution other than to always rename something as it gets moved into core, which I suppose introduces a whole other set of problems.
yes, if all core plugins would be named
discourse-core-whatever, that would also signal to people what they’re dealing with, i.e. not a “real” plugin!
This is really nice @david excellent work
One suggestion, let’s kill off “is also” and just have “replying” since that says enough, and less words = less translations = less screen space used for jibba-jabba = more betterer.
Sounds good to me
I hope I’ve added the transifex config correctly - if someone who uses it can double check that would be great
I made a couple changes to the plugin this morning. The first thing I did was use
shouldRender on the connector to avoid it rendering if the plugin is disabled which saves some time. There was also a bug for me with regards to the
presenceUsers array not existing by the time it was computed which broke the composer for me.
While I was in there I realized the code has some pretty big issues that need to be fixed:
IMPORTANT: There is no guardian logic to ensure a user can see the composer they’ve subscribed or published to. This means that I can see who is typing on a topic that is private. It doesn’t leak information about the topic but this definitely should not be allowed. I’ve made the plugin disabled by default until this is addressed.
The component is injecting the controller. All of a component’s arguments should be passed in to encourage a clean interface. The injected controller should be removed and replaced with the exact arguments it needs.
The majority of the logic is extended into the composer controller. Why not do it all in the component? You get a lifecycle of
didInsertElementwhen the component is rendered and
willDestroyElementwhen it is removed. This should be a lot simpler than the current code which has to detect if the composer is closed/open/not visible
Thanks for looking over the code and making some changes - I’ll work on those comments today
Thanks for the pull request! I’ve merged it.