Du hast recht. Der Sortierfehler in der Überprüfungs-Warteschlange tritt auf, weil sich nach der Deinstallation des Plugins noch Akismet-Überprüfungsobjekte in der Datenbank befinden. Ich sehe hier zwei mögliche Lösungen:
Ein Rake-Task bereitstellen, um diese Datensätze aus der Datenbank zu entfernen, bevor der Benutzer das Plugin dauerhaft deinstalliert.
Einen Standard-Bereich (default scope) für die Klasse Reviewable anwenden, der diese Datensätze ausschließt, falls das Plugin deaktiviert ist.
Noch etwas: Bilder scheinen in der Vorschau des Editors unsichtbar zu sein, wenn du ein Warteschlangenthema oder einen Warteschlangenbeitrag bearbeitest.
Passt das auf, wenn der Beitrag auf Prüfung wartet? Oder nachdem er abgelehnt wurde? Wie bereits erwähnt, werden hochgeladene abgelehnte Warteschlangenbeiträge automatisch vom System entfernt.
Ich habe versucht, die Option ‘Benachrichtigung über in der Warteschlange stehende Beiträge nach’ zu deaktivieren, indem ich sie auf 0 und auch auf 2000000000 gesetzt habe. Trotzdem erhalte ich weiterhin viele häufige Benachrichtigungsnachrichten wie „x Beiträge müssen überprüft werden“.
Das System sendet sie, weil noch Elemente in der Warteschlange stehen. Die Einstellung, die Sie geändert haben, betrifft Erinnerungen für Warteschlangen-Beiträge. Setzen Sie stattdessen notify_about_flags_after auf 0.
[quote=“eviltrout, Beitrag: 202, Thema: 112837”]
Ich finde es wäre vernünftig, wenn wir eine Rake-Aufgabe hinzufügen würden und diese dann im README unter einem Abschnitt „Deinstallation
Danke @Roman – ich kann bestätigen, dass die Änderung von notify_about_flags_after auf 0 die Benachrichtigungen gestoppt hat
Ich schätze es wirklich, dass du diesen Rake-Task hinzugefügt hast! Ich werde Akismet später heute neu installieren und den Rake-Task ausführen, wenn der Verkehr auf einem Tiefpunkt ist, und dann diesen Beitrag mit den Ergebnissen aktualisieren.
Es scheint, dass Nutzer, deren Beiträge direkt in die Warteschlange zur Überprüfung gelangen, eine ganze Reihe von Ratenbegrenzungen für die Erstellung von Themen und Beiträgen/Antworten umgehen können.
Ratenbegrenzungsoptionen, die umgehbar zu sein scheinen:
Ratenbegrenzung Thema erstellen, Ratenbegrenzung neuer Benutzer Thema erstellen, maximale Themen pro Tag, Ratenbegrenzung Beitrag erstellen, Ratenbegrenzung neuer Benutzer Beitrag erstellen, eindeutige Beiträge pro Minute, maximale aufeinanderfolgende Antworten.
Zusammen mit der Verhinderung von Aufwertungen (Bump) durch das Plugin „No Bump“: Discourse No Bump - #26
Optionen zum direkten Senden von Themen und Beiträgen in die Warteschlange zur Überprüfung:
„Anzahl der zu genehmigenden Beiträge“ (neue Benutzer, deren erste Themen/Beiträge genehmigt werden müssen) sowie die individuellen Kategorienoptionen „Genehmigung aller neuen Themen durch Moderatoren erforderlich“ und höchstwahrscheinlich (ich habe nur die Option für neue Themen getestet) „Genehmigung aller neuen Antworten durch Moderatoren erforderlich".
Ah, verstehe. Danke für die Erklärung. Ich werde einfach meine Erfahrungen dazu teilen, als Referenz.
Ohne durchgesetzte Limits können neue Benutzer (Genehmigung von Beiträgen) die Review-Warteschlange frei und ohne oder mit minimalen Einschränkungen überfluten, während ältere vertrauenswürdige Konten durch die Ratenbegrenzung eingeschränkt sind. Ausgenommen davon ist der Fall, dass die Kategorienoptionen zum Genehmigen aller Themen oder Antworten aktiviert sind; dann unterliegen auch ältere vertrauenswürdige Benutzer keinen oder nur minimalen Einschränkungen.
Es wäre zwar viel Arbeit, aber durchaus machbar, alle neuen Themen sowie die ersten Beiträge von neuen Benutzern (falls ratenbegrenzt) zu genehmigen. In meinem Fall ist es jedoch nahezu unmöglich, wenn Benutzer die Warteschlange überfluten können.
Wie auch immer, vielen Dank für die Klärung, dass dies beabsichtigt ist. Das ist sehr hilfreich. Ich werde meine Strategie überarbeiten und die Optionen deaktivieren, die Themen oder Beiträge direkt in die Review-Warteschlange senden, und diese hauptsächlich für gemeldete Inhalte vorbehalten. Dann einfach die ratenbegrenzten Live-Einreichungen im Nachhinein moderieren – das sollte gut funktionieren und für die Benutzer auch zügiger sein.
Ich habe kürzlich die Site-Einstellung invite only aktiviert, und nun wurde im Prüfqueue ein vom System generierter Eintrag für ein Benutzerkonto erstellt, der als Needs Approval markiert ist.
Das Seltsame daran ist, dass es sich um ein bestehendes Konto (vier Jahre alt) mit mehreren Beiträgen und dem Trust Level 2 handelt, das jedoch in letzter Zeit nicht aktiv war (der letzte Beitrag stammt vor zwei Jahren). Heute hat sich der Nutzer jedoch eingeloggt, woraufhin der Prüf-Flag gesetzt wurde.
Ich habe „Benutzer genehmigen“ noch nicht verwendet, und der Eintrag befindet sich immer noch im Prüfqueue. Dennoch scheint das Konto aktiviert zu sein und kann das Forum nutzen (wie es sein sollte).
Scheint es, als würde der Prüfqueue neu reaktivierte Konten als neue Konten identifizieren und bei aktivierter Einstellung invite only zur Prüfung markieren?
Edit: Dies ist nun auch bei einem sehr neuen Konto passiert, das nur wenige Tage vor Aktivierung dieser Einstellung erstellt wurde.
Ich habe dies weiter untersucht, und das einzige, was diese Konten (insgesamt vier) gemeinsam haben, ist, dass sie sich alle nach der Einstellung von invite_only über einen der E-Mail-Login-Pfade (entweder über forgot_password oder direkt über email_login) angemeldet haben.
Gab es bereits Überlegungen, die Sperroption für von Akismet gemeldete Themen/Beiträge in der Prüfung hinzuzufügen? Dies wurde auf unserer Instanz vorgeschlagen, einfach weil wir SSO nutzen. Das Löschen von Mitgliedern bringt selten etwas, da sich das Mitglied einfach erneut bei seinem Konto beim primären Anbieter anmelden und sofort wieder in das Forum eingeloggt werden kann, um einfach weiterzumachen. Eine Sperre macht es ihnen schwerer, da sie ein neues Konto beim Anbieter mit einer neuen E-Mail-Adresse erstellen müssen.
Ich weiß, es ist eine etwas seltsame Anfrage, aber eine, die meine Moderatoren ziemlich häufig stellen. Heute gehen sie manuell durch das System, um den Benutzer zu sperren, was zusätzlichen Aufwand für sie bedeutet, sich aber lohnt, da der Benutzer letztendlich nicht bereit ist, eine weitere E-Mail-Adresse aufzugeben.
