Mini-Patch für reply Modul: Wie könnte das gehen?

muss man den User anders löschen.

Beim Löschen eines Users wird gefragt, ob der User mit all seinen Daten gelöscht, oder diese Daten dem Gast-User zugeordnet werden sollen.

Wählt man letzteres, wird der Gast-User eingetragen, und es gibt diese Fehlermeldung nicht mehr.

Danke für die Tipps.

Ich habe das jetzt genau gestest. Es gibt vier Möglichkeiten beim Löschen eines User:

Hier geht es darum, dass Benutzer vollständig gelöscht werden (manche wünschen das, manche sind Spamer, die muss man löschen!). D.h. es geht nur um die beiden letzten Optionen.

Ich habe jetzt sowohl mit

also auch mit

mehrere Benutzer gelöscht und dann jene Nodes aufgerufen, auf denen der eben gelöschte Nutzer einen reply comment geschrieben hat.

Defenitiv in beiden(!) Fällen gibt es danach beim Aufruf des Artikels, unter dem der gelöschte Nutzer den reply comment geschrieben hat, folgende Fehlermeldung:

Also auch dann, wenn man die Option wählt, die Daten einem Gast-User zuzuordnen.

Ich denke schon, dass Du Recht hast und es so sein sollte, wie Du es geschrieben hast. Aber wohl wegen eines Bugs verhält sich die Sache anders! Daher wäre ein kleiner Patch für das reply Modul eine Lösung, ein Patch für das user Modul wäre auch eine Lösung (siehe oben).

Wie könnte so ein kleiner Patch für das reply Modul aussehen, damit das reply Modul gar nicht erst mal versucht Core-Funktionen aufzurufen, die die Userdaten zurückliefern, wenn der betreffende User bereits gelöscht wurde. Wenn diese Funktionen vom reply Modul gar nicht erst aufgerufen werden (für gelöschte User), dann wird der Fatal error auch nicht auftreten.

Der Vorteil eines solchen Patches wäre: Es gibt aus der Vergangenheit eine undefinierbar aber sehr hohe Anzahl von gelöschten Benutzern, von denen viele solche reply comments geschrieben haben. Diese Lösung würde also auch auf alle in der Vergangenheit gelöschten Nutzer wirken und das Problem vollständig lösen.

Ideen für den Mini-Patch des reply-Modul? Wo im Code könnte man ansetzen? Ich kann es dann debuggen ...

dort sollten alle Kommentare, die von gelöschten Usern stammen, die UID 0 haben.

Die Kommentare stehen in der Tabelle comments.

Sollten diese noch die alten Einträge haben, funktioniert etwas mit dem Löschen nicht richtig.
Das wäre dann auch der richtige Ansatz.

Wenn das Usermodul an dieser Stelle nicht sauber arbeitet (mit Nodes funktioniert es), käme vielleicht Rules in Frage?

Sorry, aber das passt einfach alles nicht zusammen.

Das letzte Mal hast Du geschrieben

und jetzt empfiehlst Du, in der Datenbank rumzufummeln anstatt einen sauberen Patch zu schreiben. Es spricht nichts gegen einen sauberen Patch, tausende andere machen das auch.

Und:
Es gibt keine Tabelle comments weil das Modul Comments (Core) gar nicht eingesetzt wird, davon war gar nicht die Rede.

Suche also weiterhin jemanden, der hilfreich sein kann dabei, hier für das reply-Modul den Ansatz eines sauberen Patches zu liefern (den Rest würde ich selbst machen).
Danke.

Wenn man weiß was man tut, kann man auch in der Datenbank etwas retten, was durch ein unsauberes Modul zerstört wurde.

Man muss aber sehr sehr vor- und umsichtig dabei umgehen, und selbstverständlich vor jeder manuellen Änderung einen Datenbankdump erstellen und die Site offline nehmen.

Du hast genug Erfahrung, solche Vorsichtsmaßnahmen zu kennen.

Nach gutdünken in der Datenbank herumbasteln, möglicherweise ohne Sicherung, ist natürlich absolut tödlich.

Es wird sich sicher eine Lösung für einen Patch finden.

solltest du sauber analysieren, und entsprechend an der Quelle des Fehlers korrigieren.

Ein Patch, der einen Fehler ignoriert, halte ich für den falschen Weg.

Der richtige Ansatz sollte die Deletefunktion des Userobjektes sein.

Dieses müsste beim Löschen ein "update .... set UID=0 where UID=gelöschte Userid" auslösen, wenn der User gelöscht, und seine Daten dem Gastuser zugeschrieben werden sollen.
Und dies für Nodes und Comments.

Änderst du dies im Original, wird es Problematisch mit Updates.

Deshalb mein Vorschlag, dies mit Rules zu simmulieren, und zusätzlich ein issue bei drupal.org aufmachen.

Ja, das Modul hat einen Bug und daher gibt es diesen fatal error, wo dann Nodes nicht mehr angezeigt werden, sondern der Fehler kommt.

Du sprichst davon, wie man für Userlöschungen, die in Zukunft passieren werden, das Problem lösen soll. Nämlich den Bug beheben und eben dafür zu sorgen, dass beim Löschen die uid auf 0 gesetzt wird in diesem reply comment (es sind entities).

Mit ist aber genau so wichtig, dass in der Vergangenheit gelöschte User, die reply comments geschrieben haben, nicht diesen fatal error verursachen auf diesen Nodes.

Wenn man so will, kann man dann das Reply Modul zweimal patchen!

Dein Anliegen:
Wenn ein User vollständig gelöscht wird (zu Gast-User gemacht wird), dann soll die uid in diesen comments, hier sind es entity-Einträge, auf 0 gesetzt werden.

Das müsste theoretisch das User Module (Core) machen. Dieses weiß aber nichts vom Reply Modul.

Daher könnte dies auch das reply Modul machen:
Einfach in dies entsprechende Hook-Funktion "user_deleted" (oder so ähnlich) einhängen und eben dann die entsprechenden replies diese Users, der gerade gelöscht wird, verändern und die uid auf 0 setzen.

Sprich wir brauchen einen Patch für das reply-Modul!

Natürlich kann man jetzt in der Datenbank rumfummeln und dies selbst machen und nachträglich alle reply comments ausfindig machen, wo die User inzwischen gelöscht wurden.
Wie lautet dafür die entsprechende SQL-Abfrage?

Aber damit ist das Problem nicht gelöst, denn sonst müsste man dieses in der DB rumfummeln ja jeden Tag machen, oder eventuell mit Rules steuern, was aber nur dann sinnvoll ist, wenn man keine Patches schreiben kann.

Ein kleiner Patch, der das Reply Modul erweitert und genau das macht, macht es dann immer und zuverlässig.

Wie kann rules denn herausfinden, welche User in der Vergangenheit (es sind wohl hunderte) gelöscht wurden und dann suchen, ob diese gelöschten User (sie existieren nicht mehr in der Tabelle "users") reply comments geschrieben haben. Wenn ja, in der reply tabelle die uid für diese comments auf 0 setzen.

So etwas ist besser mit mysql-Anweisungen per PHP machbar, also mittels Patch, als mit Rules.

Es soll nämlich einerseits alle in der Vergangenheit gelöschten User in den reply comments korrigiert werden als auch immer SOROFT dann korrigiert werden, wenn ein User in der Zukunf gelöscht wird (nicht erst nachträglich per cronjob). Damit keine Sekunde lang der fatal error bei diesen Nodes/comments auftritt.

Also jetzt wissen wir alles, was nötig ist.

Wie könnte der Code für den Patch aussehen?
Oder wie könnte eine vollständige Lösung, die alles berücksichtigt und in allen Lebenslagen und realtime funktioniert aussehen?

Und ein wichtiges Argument:
Natürlich kann man dieses Problem mit Rules (+ Views usw) lösen. Aber hunderte andere User, die das Reply Modul verwenden, werden in Zukunft das gleiche Problem haben. Warum wollen wir nicht etwas zur Community beitragen und einen Patch für das Reply Modul schreiben, der das Problem vollständig löst. Der Patch wird dann allen anderen Usern auch zur Verfügung stehen und mit ein wenig Glück per Commit in eine der nächsten Versionen mit übernommen.

Das macht mehr Sinn, als eine Lösung mit Rules, die durchaus auch funktionieren kann.