Quick Messages Plugin

Anpassung Plugin
410

Versuchen Sie, das Problem mit der mobilen Version von Google Chrome oder der mobilen Version von Firefox (oder einem anderen mobilen Browser) zu reproduzieren.

2 „Gefällt mir“
411

Ein Cache-Clear hat geholfen! Danke! EDIT: Oder doch nicht. :frowning:

1 „Gefällt mir“
412

Entschuldigt bitte die Vernachlässigung hier; ich war mit anderer Arbeit beschäftigt. Ich werde mir dieses Plugin bald wieder ansehen.

@DaleKramer @Hifihedgehog Falls ihr ein dringendes Problem habt, lasst es mich wissen, und ich werde es diese Woche prüfen.

4 „Gefällt mir“
413

Tatsächlich ist das Problem nach dem Update des Servers wieder aufgetreten. Es tritt auch auf allen meinen mobilen Browsern auf:

image
image828×1792 96.6 KB

414

Ich habe die Schnellnachrichten auf thepavilion.io wieder hinzugefügt. Kannst du das Problem dort reproduzieren?

1 „Gefällt mir“
415

Vielleicht könntest du dir dieses Problem ansehen, das auf dieses Plugin als Verursacher hindeutete…

416

In der neuesten Version funktioniert die Schnellnachricht nicht. Bei jeder Nachricht erhalte ich folgende Meldung:

Entschuldigung, Sie können keine PN in einem bestehenden Thema erstellen.

417

Stimmt, ich bekomme denselben Fehler: Entschuldigung, Sie können keine private Nachricht in einem bestehenden Thema erstellen.

1 „Gefällt mir“
418

Ich erhalte weiterhin denselben Fehler „PM kann nicht erstellt werden“. Könnte das an diesem Commit liegen?

https://review.discourse.org/t/fix-ensures-we-dont-attempt-to-create-a-new-pm-on-an-existing-topic-9029/9319

419

Danke für die Berichte. Ich werde mir das so schnell wie möglich ansehen.

1 „Gefällt mir“
420

Das war das Problem. Die Lösung besteht darin, die Funktion valid? zu überschreiben, ohne die Änderungen aus diesem Commit. Führen Sie dies also in plugin.rb oder einer ähnlichen Datei aus:

require_dependency 'post_creator'

class ::PostCreator

  def valid?
    # Schreiben Sie hier neu, minus 4 Zeilen
  end
end
421

Ich werde morgen einen PR dafür einreichen, falls niemand anderes etwas unternimmt, da ich den ganzen Morgen damit beschäftigt war.

4 „Gefällt mir“
422

Das wäre sehr nett. Im Moment ist hier ziemlich viel los :grimacing:. Danke!

1 „Gefällt mir“
423
1 „Gefällt mir“
424

Obwohl ich eine Lösung so schnell wie möglich hätte, mache ich mir Sorgen um die langfristige Nutzbarkeit dieser Lösung. Was, wenn sich die Logik innerhalb dieser Kernimplementierung der Funktion ändert?

1 „Gefällt mir“
425

Ja, ich stimme zu, das ist nicht der richtige Weg – besonders bei einer valid?-Methode. Das lädt förmlich nach einer Sicherheitslücke. Wir wollen nicht, dass Discourse in dieser Hinsicht zum nächsten WordPress wird … aber was wäre eine gute Alternative?

Ich kämpfe seit Kurzem auch mit ähnlichen Problemen: Eine lange Methode voller Prüfungen, und ich möchte nur eine einzelne Prüfung umgehen, genau in der Mitte der Methode.

Man kann nicht einfach prüfen, ob :create_pm_on_existing_topic der einzige Fehler war, denn der Code bricht sofort ab, sobald dieser gesetzt wird. Es könnte sein, dass danach noch eine weitere Prüfung fehlgeschlagen ist.

Ich würde dieses Modul zumindest voranstellen und dann in der neuen valid?-Methode prüfen, ob es sich um eine „Quick Message“-Szenario handelt. Falls ja, führe den modifizierten Validierungscode aus; falls nicht, gib einfach return super zurück, um den Kerncode aufzurufen. Wenn sich die Kernfunktion ändert, wird dadurch nur die Plugin-Funktionalität beeinträchtigt, nicht aber der Rest der Forensoftware.

Ich musste die beiden Funktionen Zeile für Zeile vergleichen, um herauszufinden, dass die entfernte Prüfung folgendermaßen aussah:

if new_topic?
  ... 
else
  if @topic.present? && @opts[:archetype] == Archetype.private_message
    errors.add(:base, I18n.t(:create_pm_on_existing_topic))
    return false
  end
...

Ein Kommentar hätte nicht geschadet :wink:

Weiß jemand einen besseren Weg, um sicherzustellen, dass solche „Monkey Patches“ wartbar bleiben?

(Habe ich tatsächlich „Monkey Patch“ und „wartbar“ in einem einzigen Satz verwendet? :thinking:)

426

Eigentlich bin ich immer noch nicht sicher, warum die Schnellnachrichten durch [FIX: stellt sicher, dass wir nicht versuchen, eine neue PN in einem bestehenden Thema zu erstellen #9029] beschädigt werden. Die Korrektur 9029 funktioniert für PNs und Themen – warum sind dann die Schnellnachrichten kaputt? Liegt das an einer bestimmten Art und Weise, wie Schnellnachrichten eine neue PN erstellen, die mit 9029 kollidiert?

427

Ja, ich denke, das ist es. Und #9029 hat diese spezifische Prüfung hinzugefügt.

428

Ich habe gerade einen Fix für dieses Plugin eingespielt. Lass mich wissen, wie es läuft.

@Oliver_Walker danke für den PR. Wie andere bereits erwähnt haben, ist es am besten, große Methoden nicht zu überschreiben, aber danke, dass du es versucht hast :+1:

Mit der Gefahr, in 95 % der Fälle wie ein abgegriffenes Glückskeks zu klingen: Wenn du darüber nachdenkst, einen Teil einer großen serverseitigen Methode zu überschreiben, kämpfst du gegen die Logik des Frameworks (es gibt vielleicht ein paar Ausnahmen davon).

In diesem Fall ist die erste Frage: Wie werden normale PMs zu bestehenden normalen PM-Themen hinzugefügt? Es stellt sich heraus, dass das Problem darin bestand, dass das Plugin versuchte, das private_message-Archetyp auf jeden Beitrag zu übertragen, anstatt nur auf den ersten Beitrag, der das Thema erstellt.

5 „Gefällt mir“
429

Danke @angus. Ich nehme an, du konntest dies testen? Außerdem: Soll ich unseren Hosting-Partner (Communiteq (ehemals DiscourseHosting)) einfach bitten, das Plugin für uns neu zu laden?