It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
It doesn’t disable the digest but it does provide another option.
Exactly! If you’re limiting what goes out in the summary, it now becomes a digest. Which is the default setup in Discourse.
hi @joebuhlig and @pfaffman,
thanks for your replies. but i don’t really get it and maybe you can help me out:
what settings would I need to change to change the current behaviour (ALL topics are included in the daily summary even if the reached the user already during the day because the watch the category)?
thanks in advance,
etienne
If I understand correctly, all you need to do is turn off the mailing-list-mode-daily-summary plugin.
The thiing is that the summary might not include ALL of the posts for the day, it chooses just the top 5 or something. You can see what the normal summary looks like at (something like) /admin -> email -> summary.
ah - now i get what you are telling me.
as we need ALL messages to get to our users in the daily summary using the build-in function is not an option. it does not send out all messages.
thats why we are using the mailing-list-mode-daily-summary plugin in the first place.
but now we are getting comments from users about getting messages twice: first as mail during the day because they are watching a topic and then later in the mlm-daily-summary again.
but probably it is not consistent with the idea of a daily SUMMARY to exclude certain messages (that have been send to the user already). so users have to get used to getting things twice i guess.
If your users watch the categories that they want they will get all of the messages. They do get each one individually rather than a single message with all of them.
People who watch a category or visit the site regularly don’t need mailing list mode or the plugin.
Sounds like you have a conflict between the staff’s desires and the users’ desires. Staff wants everyone to see everything, but the users only want to see a summary.
I’m guessing you’ll need to rectify that discrepancy first.
yes, you are right @joebuhlig. we’ll decide on that in the team.
as for your proposal of paying 200$ for the bugfixes: we are discussing that tomorrow in a team-meeting. will let you know.
hi @joebuhlig,
sorry - i forgot to tell you earlier: i couldnt bet through with my proposal of paying you guys for fixing the bug. so we would wait for you and your team to find time to fix it.
we are looking forward to seeing the bug fixed.
best, etienne
你好,@joebuhlig 以及其他使用此插件的用户——自从 Discourse 升级到 2.3.0 版本后,是否还有其他人也遇到此插件的问题?几周前我们的托管服务商将我们升级到 2.3.0 版本后,我们的每日邮件便停止发送。此外,当我访问用户的邮件偏好设置页面时,此邮件选项的复选框无法保存。您可以点击它并点击“保存”,但重新加载后,复选框又变为未选中状态。只是想了解一下是否有人找到解决这些问题的方法。如果有任何见解,非常感谢!
嗨 Leah,请查看我 1 月 29 日发布的帖子,并确认你的问题是否也可能与 user_custom_fields 中的条目有关。问候,Etienne
我有几点更新,很想听听其他使用此插件的用户的反馈,看看它目前运行得如何。我们有数百人订阅了每日邮件,因此我们希望能让此插件重新正常工作。
@etienne,感谢您分享关于 true/false(t/f)的调查结果。我们请人对此进行了检查,他表示代码应该可以正常处理这种情况。因此,就我们的情况而言,我仍然困惑:为什么有些用户收不到每日邮件,而有些用户却每隔几天才能收到一次?我们每天都有新话题和新帖子,所以这封邮件本应每天发送。
我们的 WordPress 开发人员(他并非真正的 Discourse/Ruby 专家,只是愿意帮忙查看问题的人)确实成功解决了前端 JS 错误,该错误导致复选框无法保存。
另外,我想请教任何正在使用此插件的用户:你们是否怀疑此插件存在崩溃并导致表被异常锁定的问题?我们的论坛还遇到了另一个神秘问题,其中一种理论认为这可能是由该插件引起的,因为表被锁定后未能解锁,但我们尚未完全确认这一点。
你好,
我已将 Discourse 更新至 2.4.0 beta2 版本。此后,该插件无法正常工作。
目前我在 Sidekick 中看到的错误代码是:
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined methodapply_notification_styles’ for #UserNotifications:0x00007f1437382668`
希望该插件能尽快得到修复。
我们也遇到了这个问题。
这可能是因为我们在统一所有电子邮件的样式,使其更易于主题化,这要归功于 @neil。
我刚重新构建了系统,使用的是最新的 v2.4.2.beta2 版 Discourse:
我们昨天禁用了 mlm-daily 插件并清空了重试队列。但我们仍在 /logs 中看到错误,Sidekiq 中的重试任务仍在堆积:
Jobs::HandledExceptionWrapper: 包装了 NoMethodError: 未定义方法 apply_notification_styles’ for #UserNotifications:0x00007f6f971b9168`
看起来这影响了所有通知,而不仅仅是每日摘要。在电子邮件样式全面 overhaul 完成之前,有什么临时解决方案我们可以实施吗?
谢谢,
Gunnar
这是由于您使用的第三方插件所致。您需要更新该插件或将其禁用。
我们的安装环境(2.4.0 beta4)也出现了同样的问题。我需要进行哪些更新才能解决此问题?
此外,当用户尝试在个人设置中启用“邮件列表模式”时,系统会保存该设置(至少界面显示如此),但重新打开设置对话框后,复选框又变回未选中状态。因此,我们无法再使用该插件发送每日汇总邮件。我不确定这是否与上面提到的 Jobs::HandledExceptionWrapper 错误有关,但我觉得应该无关。
有什么我可以做的来修复这些问题吗?
Dirk
需要有人更新插件以解决问题。您可以阅读插件开发者的 howto 主题,或者如果您有预算,可以在 Marketplace 中发帖。
你好 @joebuhlig。
你是否仍愿意有偿继续开发此插件,将其更新至即将发布的 Discourse 2.4 版本,并修复此前描述的漏洞?如果你能告知价格(你今年早些时候曾提出修复漏洞的费用为 200 美元),我们将与团队讨论此事。
感谢告知。
Etienne
这实际上并不是对插件的更新,而是一个热修复。它并没有真正修补插件以适配新系统,而是将某些被移除的部分重新集成到了插件中。它不具备未来兼容性。而且,它肯定无法解决 Discourse 团队将每日摘要视为不必要的边缘情况、而非保持邮件偏好用户参与的重要功能这一问题。Discourse 已不再能真正作为邮件列表的替代品,如果您有能力迁移,建议尽快行动。此外,它也无法解决“我们不需要文档或正确的发布说明”这种问题。
话虽如此,我们在生产环境中使用了此方案,似乎可以正常工作。虽然效果不佳,但总比没有强。
现在您应该可以再次切换 UI 按钮了。
def apply_notification_styles(email) email.html_part.body = Email::Styles.new(email.html_part.body.to_s).tap do |styles| styles.format_basic styles.format_html end.to_html email
请注意,原始函数(参见导致问题的提交以了解详情)使用的是 styles.format_notification 而不是 styles.format_html。由于 _notification 已被移除,我们暂时使用 _html。这是否是个好主意?不是。它能起作用吗?看起来可以。至少我们还有微小机会避免它在下次更新中被移除。
我还将整个 mailing_list.html.erb 包裹在一个带有 summary-email 类的 div 标签中,并在设置中禁用了摘要邮件的主题样式。这最初只是绝望的尝试,并未产生任何效果。您很可能无需此步骤即可正常运行,但除非再次出现问题,否则我不会再碰这堆混乱。因此,如果您遇到格式问题,不妨尝试一下。
希望这能帮到您。