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
Hallo @joebuhlig und andere, die dieses Plugin nutzen – Hat jemand anderes seit der Version 2.3.0 von Discourse Probleme mit diesem Plugin? Als unser Hosting-Anbieter uns vor ein paar Wochen auf 2.3.0 aktualisiert hat, wurden unsere täglichen E-Mails nicht mehr versendet. Außerdem lässt sich das Kontrollkästchen für diese E-Mail-Option auf dem Bildschirm mit den E-Mail-Einstellungen eines Benutzers nicht speichern. Man kann es anklicken und auf Speichern klicken, aber beim Neuladen ist es wieder deaktiviert. Ich bin einfach nur neugierig, ob jemand einen Weg gefunden hat, diese Probleme zu beheben. Vielen Dank, falls jemand einen Hinweis hat!
Hallo Leah, prüfe bitte meinen früheren Beitrag vom 29. Januar und schaue nach, ob dein Problem vielleicht auch mit dem Eintrag in user_custom_fields zusammenhängt. Grüße, Etienne
Ich habe ein paar Updates und würde gerne von allen anderen hören, die dieses Plugin verwenden, wie es bei euch derzeit läuft. Wir haben Hunderte von Abonnenten für die täglichen E-Mails, also hoffen wir, dass wir dieses Plugin wieder zum Laufen bringen.
@etienne, danke, dass du deine Erkenntnisse zum true/false (w/f) geteilt hast. Jemand hat sich das angesehen und sagte, der Code sollte das problemlos handhaben können. In unserem Fall bin ich also immer noch verwirrt, warum einige Benutzer keine täglichen E-Mails erhalten und andere nur alle paar Tage. Wir haben definitiv jeden Tag neue Themen und neue Beiträge, also sollte diese E-Mail täglich verschickt werden.
Unser WordPress-Entwickler (der nicht wirklich ein Discourse-/Ruby-Experte ist, sondern einfach jemand, der bereit war, sich das Problem anzusehen) hat es geschafft, den Frontend-JS-Fehler zu beheben, der dafür sorgte, dass das Kontrollkästchen nicht gespeichert wurde.
Eine weitere Sache, die ich von allen, die dieses Plugin verwenden, wissen möchte, ist folgende: Vermutet ihr, dass es Probleme gibt, bei denen dieses Plugin abstürzt und Tabellen auf problematische Weise sperrt? Wir haben ein weiteres mysteriöses Problem mit unserem Forum, und eine Theorie besagt, dass dieses Plugin dies verursacht, weil gesperrte Tabellen nicht entsperrt werden. Das haben wir jedoch noch nicht endgültig geklärt.
Hallo,
Ich habe mein Discourse auf 2.4.0 Beta 2 aktualisiert. Seitdem ist dieses Plugin defekt.
Momentan lautet mein Fehlercode im Sidekick:
Jobs::HandledExceptionWrapper: Wrapped NoMethodError: undefined method 'apply_notification_styles' for #<UserNotifications:0x00007f1437382668>
Ich hoffe, dass dieses Plugin bald behoben wird.
Wir sehen das auch.
Wahrscheinlich, weil wir dank @neil alle E-Mail-Stile vereinheitlichen, um E-Mails besser anpassbar zu machen.
Ich habe gerade neu aufgebaut, also basiert dies auf der neuesten Version v2.4.2.beta2 von Discourse:
Wir haben gestern das mlm-daily-Plugin deaktiviert und die Wiederholwarteschlange geleert. Dennoch sehen wir weiterhin Fehler in /logs, und die Wiederholungen häufen sich weiterhin in Sidekiq an:
Jobs::HandledExceptionWrapper: Umhüllter NoMethodError: undefinierte Methode 'apply_notification_styles' für #<UserNotifications:0x00007f6f971b9168>
Es scheint, als ob dies alle Benachrichtigungen betrifft, nicht nur die täglichen Zusammenfassungen. Gibt es einen Workaround, den wir umsetzen können, bis die Überarbeitung der E-Mail-Stile abgeschlossen ist?
Vielen Dank,
Gunnar
Dies liegt an einem von Ihnen verwendeten Plugin eines Drittanbieters. Sie müssen entweder dieses Plugin aktualisieren oder es deaktivieren.
Wir sehen dies auch in unserer Installation (2.4.0 beta4). Muss ich etwas aktualisieren, um das zu beheben?
Zusätzlich wird, wenn Benutzer versuchen, den E-Mail-Listen-Modus in ihren eigenen Einstellungen zu aktivieren, dies zwar gespeichert (zumindest sagt die Benutzeroberfläche das), aber beim erneuten Öffnen des Einstellungsdialogs ist das Kontrollkästchen wieder deaktiviert. Daher können wir mit diesem Plugin keine täglichen Zusammenfassungsmails mehr versenden. Ich bin mir nicht sicher, ob dies mit der oben genannten Jobs::HandledExceptionWrapper-Meldung zusammenhängt, aber ich vermute nicht.
Gibt es etwas, das ich tun könnte, um dies zu beheben?
Dirk
Jemand muss das Plugin aktualisieren, um das Problem zu lösen. Du kannst die #howto-Themen des Plugin-Entwicklers lesen oder im Marketplace posten, wenn du ein Budget hast.
Hallo @joebuhlig.
Bist du noch bereit, an diesem Plugin zu arbeiten, es für die kommende Discourse-Version 2.4 zu aktualisieren und den zuvor beschriebenen Fehler gegen Bezahlung zu beheben? Wenn du uns einen Preis nennst (du hast Anfang dieses Jahres 200 $ für die Fehlerbehebung genannt), werden wir das in unserem Team besprechen.
Danke für die Rückmeldung.
Etienne
Dies ist eigentlich kein Update für das Plugin, sondern eher ein Hotfix. Es patcht das Plugin nicht wirklich, um mit dem neuen System zu funktionieren, sondern integriert stattdessen Teile, die entfernt wurden, wieder in das Plugin. Es ist nicht zukunftssicher. Und es wird definitiv nicht ändern, dass das Discourse-Team tägliche Zusammenfassungen als unnötigen Randfall und nicht als wichtigen Bestandteil zur Bindung von Nutzern, die E-Mails bevorzugen, eingestuft hat. Discourse kann nicht mehr wirklich als Ersatz für Mailinglisten verwendet werden, und wenn Sie die Möglichkeit haben, sollten Sie wechseln. Es wird auch nicht das Problem lösen, dass es „keine Dokumentation oder ordentliche Release-Notes“ gibt
Das sei gesagt: Wir nutzen dies in der Produktion, und es scheint zu funktionieren. Es ist nicht gut, aber egal.
Jetzt können Sie den UI-Button wieder umschalten.
apply_notification_styles wieder hinzu.engine.rb an Zeile 11 (erste Methode der Klasse) Folgendes ein: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
Beachten Sie, dass die ursprüngliche Funktion (siehe den Commit, der alles kaputt gemacht hat zum Nachlesen) styles.format_notification anstelle von styles.format_html verwendete. Da _notification entfernt wurde, verwenden wir einfach _html. Ist das eine gute Idee? Nein. Funktioniert es? Scheint so. Hey, zumindest haben wir eine geringe Chance, dass es beim nächsten Update nicht wieder entfernt wird.
Ich habe zudem die gesamte mailing_list.html.erb in ein Div-Tag mit der Klasse summary-email gepackt und das Theming für Zusammenfassungs-E-Mails in den Einstellungen deaktiviert. Das war zunächst nur ein verzweifelter Versuch und brachte keine Ergebnisse. Sie werden höchstwahrscheinlich auch ohne dies zurechtkommen, aber ich werde dieses Chaos nicht wieder anfassen, es sei denn, es bricht erneut. Falls Sie also Formatierungsprobleme haben, fühlen Sie sich frei, dies auszuprobieren.
Ich hoffe, das hilft.