Problem can be seen on both of the following pages:
For the following topic:
Where the topic actually shows 27 votes currently:
@eviltrout can you have a look at this, should the component rendering this be inline with post stream component?
1 Like
The issue here is the plugin depends on it being inside the post stream with the widget framework. Since it is not, it can’t work properly as it doesn’t have access to all the same stuff, so it is disabled using the onlyStream: true flag when initialized.
I can think of two solutions here:
- We adjust other streams (group / user) to use vdom too
- We have the option to render something more clear that the poll is not working.
Neither are super attractive to me, to be honest.
1 Like
I don’t really understand what you mean by this option. Maybe I’m suggesting the same thing here but, another solution might be:
Don’t render full poll anywhere other than the actual topic. So on the group page, just show something like “Go to topic to see poll” inside the poll styling.
I wonder, do polls show up in embedded comments in a WordPress or Jekyll blog? I don’t have an easy way to test that.
Exactly, my choice of words was poor. But the idea is have a second code path that can render something different when the poll can’t be mounted. A message like “Click here to see the poll” might work.
I would be very surprised if polls worked when embedded, since they’d be missing the same client side controls.
3 Likes
Maybe we simply use the same component that does the truncated rendering that we use on the user page? Also not ideal but at least renders correctly.
Yeah render a “click to see poll” as we do in email – email summaries have the same problem, you can’t exactly render a live poll in an email…
1 Like
I added the ability for a plugin to “reduce” the cooked content via an event. The same event is used to strip polls from emails as well as on the group page:
https://github.com/discourse/discourse/commit/e91379916b739ea80178ac1e00b9b2f4b0dff84c
6 Likes