Problems with the upgrade procedure from 2.4.x to 2.5

Hello

During the last weeks we saw a few error reports about issues during the upgrade from a 2.4.x version to the currently latest stable version 20220803.1 (2.5.4). Some of these issues are caused by previous tests of a development version of the 2.5-branch and a later downgrade to a 2.4-x version with orphaned but remaining tables for 2.5 in the database. That broke the upgrade script because we never thought about such a situation when writing the code. Some other issues are caused by our (mainly my) carelessness and for us unexpected server configuration.

I opened a pull request on Github as work in progress (unfinished at the time of writing) to solve the issues, where possible. To keep the reports at one place where i can find them easily I will tie them now to this thread.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

folgende Randbedingungen:
- 1000 Danke erstmal für die ständige Unterstützung!

- gestartet mit 2.3.5 unter Mysql 5.7
- durch IONOS eingeschränkt in der Auswahl der PHP Version (entweder 5.6 - 7.3 oder 8.1)

Ziel: neueste Version unter MariaDB 10.6 und PHP8.1
- Update auf 2.3.7 - PHP5.6- OK
- Update auf 2.4.24 - Update auf PHP7.3 - OK
- Update auf 20220803 - PHP7.3 und PHP8.1 - fast ok

Forum ist zu Beginn komplett geklont+Backup worden.
Forum läuft grundsätzlich, aber folgende Fehlermeldungen:

[31-Mar-2023 19:00:30 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 851
[31-Mar-2023 19:00:58 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 840
[31-Mar-2023 19:00:58 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxxforum_php8/includes/posting.inc.php on line 851
[31-Mar-2023 19:12:39 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 855
[31-Mar-2023 19:12:39 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 866

und

[31-Mar-2023 19:32:03 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[31-Mar-2023 19:32:03 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

Mir raucht da grade der Kopf...
Mein Skill: root Zugang zum Server, etwas Mysql Erfahrung, Linux Erfahrung, nicht genug PHP Erfahrung....

Bei Bedarf kann ich Dir die Webseite sagen, sie ist ja online.
Irgendwelche Ideen?

Gruß
Andi

Hallo

… ohne jetzt in den Code geschaut zu haben …

Die immer wieder selben, nicht vorhandenen Indexe riechen für mich nach nicht aktualisierten *.lang-Dateien. Dort haben wir mitten im 2.4-er Zweig dieses Schlüssel-Wert-Paar eingeführt, weil das Trennen der Worte mit Leerzeichen zu ihrer Überprüfung (Länge, Bad Words) in der chinesischen Sprache nicht funktioniert.

Kopiere bitte noch einmal die Sprachdateien der passenden MLF-Version in deine Installation und teste, ob die Fehler verschwinden.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

nach dem Kopieren nur noch 2 dieser array key Fehler (reproduzierbar):
Die Dateien waren aber im diff identisch...

[01-Apr-2023 10:16:53 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[01-Apr-2023 10:16:53 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

aber beim ersten Aufruf und nur genau 1 Mal (nicht reproduzierbar):

[01-Apr-2023 10:15:18 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209

Ein anderes Gimmick sind die Prozentzeichen beim Datum/Uhrzeit:

[image]

Gruß
Andi

Hi,

in den Sprachdatei steht aber der Schlüssel word_delimiters bei Dir drin, oder?

Bist Du bereits bei der letzten Version angekommen oder noch bei einer Vorversion? Verschwinden die Fehler, wenn Du wieder auf PHP7.3 gehst?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

in den Sprachdatei steht aber der Schlüssel word_delimiters bei Dir drin, oder?

ja, tut es. In /lang/german.lang:
[image]

Bist Du bereits bei der letzten Version angekommen oder noch bei einer Vorversion?

sollte die letzte sein:
[image]

Verschwinden die Fehler, wenn Du wieder auf PHP7.3 gehst?

Nein, keine Änderung mit 7.3.33

Die "Undefined index ..." Fehler entstehen beim Antworten oder beim Erzeugen vom neuen Thema.

Danke fürs Kümmern!

Gruß
Andi

Hallo,

die ganzen updates waren letztlich doch nur notwendig, um die Datenbankänderungen alle durchzuführen. Wenn wir davon ausgehen, dass alle UPDATE, INSERT usw. Statements korrekt waren und die SQL-DB auf dem aktuellen stand ist, dann würde ich mal _alle_ Dateien aus der aktuellen version hochladen, sodass wirklich alles vorhanden ist und sich auf die aktuelle Version bezieht. Kannst Du das mal bitte machen?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ja, mach ich gleich; soll ich mit PHP7.3 oder 8.1 testen?

Gruß
Andi

Hallo,

mit 8.1, da Du bereits auf der gegenwärtig aktuellen Version bist.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ich habe aus dem Download nun alle Dateien drüberkopiert.
# cp -vr * /forum

Keine Änderung beim Fehler "Undefined index: word_delimiters".

Neuer Fehler:

[image]

unter dem Feld E-Mail-Benachrichtigung sind nun 3 Radio Buttons ohne Text aufgetaucht.
(identisch wie bei den Einstellungen - anderer Thread hier)

Status ist jetzt mit PHP 8.1

Gruß
Andi

Hi,

kannst Du mal bitte den Inhalt vom "templates_c" Verzeichnis leeren?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

hab ich natürlich vergessen; nachgeholt.
Das Avatar wird jetzt wieder angzeigt.

Fehler "Undefined index..." ist jetzt ein anderen, aber die gleiche Zeile.

[01-Apr-2023 13:29:55 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[01-Apr-2023 13:29:55 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

Da hab ich aber jetzt nicht aufgepasst, ob das mit dem Wechsel von PHP7 zu PHP8 synchron ging.

Fehler in der Datumsanzeige besteht weiter.
Fehler der Fußzeile besteht weiter.

Gruß
Andi

Hi,

bei 2 Einstellungen (Admin/Einstellungen) fehlt Text.
Diese Einstellung gab es in 2.3.5 nicht.

[image]

Gruß
Andi

Hallo

bei 2 Einstellungen (Admin/Einstellungen) fehlt Text.
Diese Einstellung gab es in 2.3.5 nicht.

#1

Dort sollte analog zu den darüber befindlichen Einstellungen zu den Nutzungsbedingungen jene für die Datenschutzerklärung zu sehen sein. Diese wurden mit Version 2.4.10 eingeführt.

#2

Dort sollten die Einstellungen zum Gelesen-Status zu sehen sein. Eingeführt wurde die neue Funktion mit einer der ersten Versionen des 2.4-er Zweigs.

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt? Hast du zusätzlich das Forum noch einmal mit [STRG]+[F5] neu geladen, um eventuell im Browser-Cache vorhandene veraltete Versionen von Dateien (z.B. style.min.css oder JS-Dateien) zu aktualisieren?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt?

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt?

nein

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.

Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.
Checke dann das Design und die von mir genannten Dinge.

Dann der Update auf 2.3.7 - prüfen
Update auf 2.4.24 - prüfen

Erst wenn das fehlerfrei ist, (in allen Punkte) - neuer Download, neuer Versuch - prüfen.
Ich melde mich hier dann mit dem Status.

Gruß
Andi

Hallo

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.

Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.
Checke dann das Design und die von mir genannten Dinge.

Mir schwant etwas. Du führst die Upgrade-Tests in einer separaten Installation aus? Benutzt du als Nutzdaten eventuell die des Livesystems beziehungsweise eine Eins-Zu-Eins-Kopie der Livedaten? Auch die Einstellungen? Vielleicht diese auch gegenüber dem Livesystem unverändert?

Wenn ja, dann stehen dem Testsystem an der einen oder anderen Stelle vielleicht die Pfade des Livesystems und damit falsche Pfade zur Verfügung. Dass im Testsystem laut deinen Angaben die korrekten Sprachdateien installiert sind, aber dennoch (die) Teile fehlen, die nach der Version 2.3.5 hinzugekommen sind, sieht für mich überaus verdächtig aus.

Auch deine Meldungen bezüglich verschobener oder fehlender Elemente sieht für mich danach aus, dass auch die geladene CSS-Datei die falsche ist.

Wenn du das Testsystem für den neuen Durchlauf aufsetzt, gehe bitte nach der Installation in die Einstellungstabelle (am besten mit phpMyAdmin oder einem vergleichbaren Tool, das unabhängig von der MLF-Oberfläche funktioniert) und prüfe die dort bereitgestellten Pfadangaben darauf, dass sie auf das Testsystem verweisen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.
Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.

Wenn du das Testsystem für den neuen Durchlauf aufsetzt, gehe bitte nach der Installation in die Einstellungstabelle (am besten mit phpMyAdmin oder einem vergleichbaren Tool, das unabhängig von der MLF-Oberfläche funktioniert) und prüfe die dort bereitgestellten Pfadangaben darauf, dass sie auf das Testsystem verweisen.

Das wäre durchaus eine plausibele Erklärung für das Verhalten.
Es war in jedem Fall eine 1:1 Dateikopie vom Pfad des originalen Forum und
eine Backup/Restore Funktion der Datenbank über das Ionos Tool.
Nur die db_settings.php habe ich anschließend von Hand kopiert/angepasst damit die kopierte Datenban genutzt wird;
sonst keinen Pfad.

Da ich noch nicht mit einem erneuten Lauf begonnen habe, kann (würde) ich solche Checks
bei der 2.3.7 und der 2.4.24 machen.
Dabei würde ich (nur um sicher zu gehen) auch die Dateien nach alten/falschen Pfaden durchsuchen
ob evt. ein hardcoded Pfad drinsteckt.

Da ich die SQL Kommandos auf dem Server von Hand ausführen kann, sollte das mit "select * from "
und einem grep hoffentlich sichtbar werden.

Danke für euren Support!

Gruß
Andi

Hallo

Da ich noch nicht mit einem erneuten Lauf begonnen habe, kann (würde) ich solche Checks
bei der 2.3.7 und der 2.4.24 machen.

Mache das einfach direkt nach der Installation des Testforums. Durchforste die Tabelle mlf2_settings nach dem Schlüssel forum_address und passe den Wert auf die reale URL des Testforums an. Ändere bitte vorsichtshalber auch den Wert des Schlüssels session_prefix, um Kollisionen mit einem eventuell offenen Tab des "echten" Forums zu vermeiden. Hänge einfach noch eine Ziffer an den Session-Namen. Du wirst, falls du das in den erweiterten Einstellungen des Forums tust, nach dem Absenden des Formulars ausgeloggt, kannst dich aber sofort wieder einloggen.

Im weiteren Verlauf der Update-Arie dürfte sich an den Pfaden, die aus den Einstellungen stammen, nichts mehr ändern.

Dabei würde ich (nur um sicher zu gehen) auch die Dateien nach alten/falschen Pfaden durchsuchen
ob evt. ein hardcoded Pfad drinsteckt.

Das sollte nicht der Fall sein … aber wer weiß.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

die Fußzeile ist verschoben.

[image]

nach dem "antworten" scheint ein Zeilenumbruch zu fehlen,
die Ausrichtung des Minimenu ist nicht mehr nach rechts..

[image]

Gruß
Andi

Hi,

das Avatar wird nicht angezeigt.
Das entsprechende Verzeichnis ist mit den Rechten 777 versehen.
Die Datei die im Quelltext genannt wird, ist vorhanden.
Die Datei ist im direkten Zugriff mit dem Browser aufrufbar und wird angezeigt.

[image]

Im Quelltext ist das Avatar aber angegeben....

[image]

Ein Rechteproblem?

Gruß
Andi

Hier hat geholfen:

- aus dem Download der aktuellen Datei alle Dateien ins Verzeichnis vom Forum kopieren
- in templates_c alle Dateien löschen

Gruß
Andi

Bei den Einstellungen ist ein(für mich) neues Symbol wie ein Bild, aber ohne Text.

[image]

darauf klicken, dann sieht man:

[image]

kann die Markierungskästchen klicken und unten "löschen".

Sollten die Bilder hier angezeigt werden?

Gruß
Andi

Hallo

Bei den Einstellungen ist ein(für mich) neues Symbol wie ein Bild, aber ohne Text.

So soll es aussehen.

[image]

darauf klicken, dann sieht man:

kann die Markierungskästchen klicken und unten "löschen".

Sollten die Bilder hier angezeigt werden?

Ja, dort sollen die Bilder als Thumbnails zu sehen sein.

[image]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

danke;
ich werde nochmal komplett von vorne mit den Updates beginnen.
Erst wenn die 2.4.24 fehlerfrei läuft, würde ich hier wieder melden.

Gruß
Andi

Hi,

habe heute einen neuen Versuch gestartet.
Beginnend mit der 2.3.5 bin ich auf 2.3.7 gegangen.

Die Empfehlung auch in der Datenbank die Foren-Adresse anzupassen, berücksichtigt.
Die 2.3.7 lief auch fehlerfrei, keiner der von mir genannten Fehler sind aufgetreten.

Vor dem nächsten Schritt:
theme ist default
templates_c Dateien gelöscht
Backup von Dateien der 2.3.7 und der DB
PHP war aber noch auf 5.6

Der Schritt zur 2.4.24 ist dann allerdings gescheitert.
Verschiedene Fehler, aber der wohl wichtigste: es ist https scheinbar zwingend vorgeschrieben.

Firefox meldet:
Beim Verbinden mit xxx-forum.de trat ein Fehler auf. Die Gegenstelle meldet, dass sie auf einen internen Fehler gestoßen ist.

Fehlercode: SSL_ERROR_INTERNAL_ERROR_ALERT
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.

Da ich die hierfür genutzte Domäne noch nicht auf https umgestellt hatte, komm ich hier nicht weiter ohne erstmal Geld an Ionos zu zahlen.

Mit Chromium wird das Forum zwar angezeigt, aber sowohl "antworten" als auch "neues Thema" springen um auf "xxx-forum.de/index.php?mode=login&action=tou" (kein Schreibfehler, exakt das).
"der Server hat eine falsche Anwort geliefert".
Sichtbar ist nur ein ausgegrautes Feld und 2 kleine Pseudobuttons drunter.

Als Fehlermeldung im Log:

06-Apr-2023 21:02:03 Europe/London] PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in xxx/htdocs/forum_php8/includes/main.inc.php:8
Stack trace:
#0 xxx/htdocs/forum_php8/index.php(35): include()
#1 {main}
thrown in x/htdocs/forum_php8/includes/main.inc.php on line 8
[06-Apr-2023 21:02:12 Europe/London] PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in xxx/htdocs/forum_php8/includes/main.inc.php:8
Stack trace:
#0 xx/htdocs/forum_php8/index.php(35): include()
#1 {main}
thrown in xxx/htdocs/forum_php8/includes/main.inc.php on line 8

Auch mit frisch gelöschtem templates_c Verzeichnis, keine Änderung.
Kopieren vom kompletten Dateibaum aus dem Archiv 2.4.24 - keine Änderung.

Würde es was bringen, vor dem Update von 2.4.24 auf PHP7.3 zu gehen?
Den Versuch kann ich ja noch machen.

Gruß
Andi

Hi,
ich werde versuchen, das Forum innerhalb der gültigen https Umgebung zu klonen.
Vielleicht ist dann der Fehler weg.

Gruß
Andi

Hallo

MLF 2.4.24 läuft explizit nicht unter PHP 8. Du musst an dieser Stelle also zwingend bei PHP 7.3 bleiben.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,
ok; ich bin bis 2.4.24 gekommen und dort ohne Fehler.

Da ich das Forum erst in 3. Generation übernommen habe und es eben seither lief,
hatte ich mich nicht so intensiv damit beschäftigt.
Es lagen nur Fehler vor, die auf Grund vorheriger Änderungen entstanden sind.
Zusätzlich eben, dass https inzwischen berechtigtiger Weise zum Standard wurde.

Als nächstes steht das Update auf die aktuelle Version an.
Ich werde berichten....

Gruß
Andi

Hallo

ok; ich bin bis 2.4.24 gekommen und dort ohne Fehler.

Sehr schön. Das läuft jetzt unter PHP 7.3?

Da ich das Forum erst in 3. Generation übernommen habe und es eben seither lief,
hatte ich mich nicht so intensiv damit beschäftigt.
Es lagen nur Fehler vor, die auf Grund vorheriger Änderungen entstanden sind.
Zusätzlich eben, dass https inzwischen berechtigtiger Weise zum Standard wurde.

Ich würde dir empfehlen, dich als nächstes um ein Zertifikat zu kümmern. IONOS ist ein großer Hosting-Anbieter. Ich würde vermuten, dass die kostenfreie Let's-Encrypt-Zertifikate anbieten. Wenn ja, sieh zu, dass du etwaige Subdomains in das Zertifikat einbeziehst oder, wenn verfügbar, ein Wildcard-Zertifikat bekommst, das sich automatisch auf alle, auch zukünftig anzulegende, Subdomains bezieht.

Dann hast du erst einmal dieses Thema vom Tisch. Selbst wenn du vorerst bei MLF 2.4.24 bliebest, wäre der Traffic inklusive zu übertragender Zugangsdaten verschlüsselt. Das ist heutzutage einfach Stand der Technik.

Als nächstes steht das Update auf die aktuelle Version an.
Ich werde berichten....

Wir harren der Berichte. :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,
beim Durchprobieren bin ich hier drauf gestossen:

[image]

Der Beitrag hat keine Antwort, wurde vor Sekunden bearbeitet (als Admin),
kann aber nicht gelöscht werden.
Eine Sperrung ist nicht erkennbar.

Wie lautet die Einstellung für das Sperren(bzw der Zeitablauf dafür)?
Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Gruß
Andi

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Nachtrag:

ich bin dem Eintrag von candleman nachgegangen (gleiches Problem).
Ich habe in der posting.inc.php vom Download der 2.4.24 die entsprechende Zeile NICHT gefunden.

Muss jetzt weg; ich melde mich erneut dazu.

Gruß
Andi

Hallo,

ich bin dem Eintrag von candleman nachgegangen (gleiches Problem).
Ich habe in der posting.inc.php vom Download der 2.4.24 die entsprechende Zeile NICHT gefunden.

Ein Link zu diesem besagten Posting wäre ggf. hilfreich.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

vorab: möglicherweise passt die Zeilennummer aus dem Beitrag von candleman nicht.

Der Verweis zum Thread:
https://mylittleforum.net/forum/index.php?id=11863

Der Verweis, wo es in der posting.inc.php stehen soll:
https://github.com/My-Little-Forum/mylittleforum/pull/469/files

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry

In der von mir mit 2.4.24 eingespielten posting.inc.php befindet sich in Zeile 1373 folgendes:

if ($authorization['delete'] === true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] == $_SESSION['csrf_token']) {

und das entspricht syntaktisch nicht dem was hier
https://github.com/My-Little-Forum/mylittleforum/pull/469/files
erwähnt wird.
Dort:
if ($authorization['delete'] == true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] === $_SESSION['csrf_token']) {

sind die Prüfungen "==" und "===" anders geschrieben.
Scheint aber keine Rolle zu spielen, im Versuch war es das gleiche Ergebnis: nur die Methode 2 (markieren und mit der "markierte löschen") funktioniert mit beiden Schreibweisen.

Meine bescheidenen Versuche das einzugrenzen enden dahingehend, dass in Zeile 1374 der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.
Das explizit im Logfile auszugeben war nicht möglich.
Den Token für die $_SESSION konnte ich aber anzeigen.

Gruß
Andi

Hallo Andi,

vorab: möglicherweise passt die Zeilennummer aus dem Beitrag von candleman nicht.

Mit scheint, dass auch das Problem nicht kompatibel ist. Bei candleman fehlte doch offensichtlich der Token. Soweit ich Deine URI sehe

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry
[...]
dass in der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.

ist dieser bei Dir vorhanden. Insofern erscheint mir das Problem nicht vergleichbar. Du kannst Dir in der PHP-Datei ja gern eine temporäre Ausgabe machen direkt hinter der if-Bedingung:

var_dump($_REQUEST);
exit;

sodass Du den Inhalt von $_REQUEST prüfen kannst.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,
hab das mal eingebaut und getestet.
Allerding VOR der IF-Prüfung in Zeite 1372, da diese ja fehl schlägt.

array(8) {
["mode"]=> string(7) "posting"
["delete_posting"]=> string(6) "169462"
["back"]=> string(5) "entry"
["delete_posting_confirm"]=> string(13) "OK - Löschen"
["m237_usersettings"]=> string(9) "0.0.1.0.0"
["m237_last_visit"]=> string(21) "1680856233.1680856233"
["m237_auto_login"]=> string(52) "caDCzn68QrqoPPJ3Ts1lNY2wx3RwITC97hPmx9qih5c2P4wkOc12" ["PHPSESSID"]=> string(32) "9ec3abd3986bf2b1f64f5209ad0a70c9"

}

Gruß
Andi

Hallo Andi,

hab das mal eingebaut und getestet.
Allerding VOR der IF-Prüfung in Zeite 1372, da diese ja fehl schlägt.

Ja, dass ist natürlich noch besser (ich bin davon ausgegangen, dass die Bedingung erfüllt ist)

array(8) {
["mode"]=> string(7) "posting"
["delete_posting"]=> string(6) "169462"
["back"]=> string(5) "entry"
["delete_posting_confirm"]=> string(13) "OK - Löschen"
["m237_usersettings"]=> string(9) "0.0.1.0.0"
["m237_last_visit"]=> string(21) "1680856233.1680856233"
["m237_auto_login"]=> string(52) "caDCzn68QrqoPPJ3Ts1lNY2wx3RwITC97hPmx9qih5c2P4wkOc12" ["PHPSESSID"]=> string(32) "9ec3abd3986bf2b1f64f5209ad0a70c9"

}

Hier fehlt nun leider der Eintrag des Tokens. In Deiner URI steht aber csrf_token=6432aa163870b5.99373782 (natürlich mit einem anderen Token als Inhalt)? Wenn ja, muss der auch im globalen $_REQUEST-Array enthalten sein. Dieses Array enthält schließlich alles, was $_GET, $_POST oder auch $_COOKIE enthält. Es ist also das "übertragungsunabhängige" Array.

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

/Micha

ich kuck:

<h1>Eintrag löschen</h1>
<p class="caution">Achtung!</p>
<p>Sicher, dass dieser Eintrag und alle Antworten gelöscht werden sollen?</p>
<p><strong>test 6</strong> - <strong>Andreas Schneider</strong>, Freitag, 07.04.2023, 11:31</p>
<form action="index.php" method="post" accept-charset="utf-8">
<div>
<input type="hidden" name="mode" value="posting" />
<input type="hidden" name="delete_posting" value="169462" />
<input type="hidden" name="back" value="entry" /><input type="submit" name="delete_posting_confirm" value="OK - Löschen" />
</div>
</form>
</div>

nee, das hat mit Deinem Beispiel nur sehr rudimentär was zu tun.
Damit hätten wir wohl die erste Spur.

Gruß
Andi

Hallo,

ja, das ist ein heißes Indiz. Du könntest nun die Template-Datei mal aktualisieren aber andererseits auch das Forum updaten. Ich gehe im Moment davon aus, dass wir es in einer der nachfolgenden Version behoben haben. Ich zumindest entnehme der Antwort von Auge, dass wir das schon mal gefixt hatten.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ich lösche mal die erzeugten templates und prüf es nochmal.
Aber Plan A lautet: Update.
Ich mach morgen weiter.

Danke und Gruß
Andi

Hallo,

ja, das ist ein heißes Indiz. Du könntest nun die Template-Datei mal aktualisieren aber andererseits auch das Forum updaten. Ich gehe im Moment davon aus, dass wir es in einer der nachfolgenden Version behoben haben. Ich zumindest entnehme der Antwort von Auge, dass wir das schon mal gefixt hatten.

Viele Grüße
Micha

Hallo

ja, das ist ein heißes Indiz.

Was in mir die Frage aufkommen lässt, wie das so lange unbemerkt geblieben ist. Version 2.4.24 ist am 12.10.2020 erschienen, die erste stabile Version des 2.5-er Zweigs (Version 20220508.1) am 08.05.2022. Wir haben im hiesigen Projektforum knapp 19 Monate mit der Version 2.4.24 gearbeitet. Auch andere Betreiber haben auf diese Version gesetzt. In keinem Forum soll aufgefallen sein, dass eine Version mit einem derart groben Schnitzer eingesetzt wurde?

Ich meine, selbst wenn hier das löschen von eigenen Postings überaus selten vorkommen dürfte, in anderen Foren sollte das hin und wieder vorkommen. Und da hätte es auffallen müssen.

Eines haben wir aber noch überhaupt nicht geklärt. Wie sehen denn die konkreten Einstellungen, die die Möglichkeit, ein eigenes Posting zu löschen, steuern, in Andreas' Forum aus? Und hat er seine Tests eventuell nicht als Admin sondern als normaler Benutzer durchgeführt, der seine eigenen Postings tatsächlich nicht löschen kann? Nicht, dass wir uns hier völlig umsonst die Köpfe heißreden und stattdessen eine Empfehlung zu den Einstellungen zielführend wäre.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast, aber in keiner der 2.4.x-Versionen vor 2.4.99.1, deren Stand ich per umschalten zwischen den Tags (Umschalter befindet sich im Screenshot links vor dem Pfad) geprüft habe, gibt es in posting_delete.inc.tpl dieses Feld. In der fraglichen Version 2.4.24 ist es also nicht vorhanden. In der Skript-Datei posting.inc.php ist ein CSRF-Token bei $action == 'delete_posting' auch nicht erforderlich. Das hat sich erst mit Version 2.4.99.1 geändert.

[image]

Erst bei $action == 'delete_posting_confirmed' wird ein CSRF-Token eingefordert, den es, wie schon gesagt im Template posting_delete.inc.tpl der Version 2.4.24 nicht gibt.

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme. Wenn ich ein Posting in der Einzel- oder Threadansicht öffne und es über den Link in den Management-Funktionen unterhalb des Postings löschen will, wird mir ein JS-Modaldialog (Sind sie sich sicher … bla bla bla …) angezeigt. Wenn ich es über das Kreuz hinter dem Betreff im Threadbaum löschen will, wird mir ebenfalls dieser JS-Modaldialog angezeigt. Wenn ich Postings im Threadbaum markiere und diese löschen will, wird das Template posting_delete_marked.inc.tpl angezeigt. Gehe ich über den Weg, ein Posting als Spam zu klassifizieren (alter Weg ohne B8-Training), wird posting_delete.inc.php auch nicht benutzt. Bin ich zu doof oder wird das Template vielleicht überhaupt nicht benutzt?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast,

Den aktuellen, welchen sonst. ;-)

Aber klar, ich habe jetzt nicht geschaut, wann welche Modifikation durchgeführt wurde. Insofern kann ich bestimmte Äußerungen auch nicht direkt reproduzieren. Auf meiner Seite versuche ich das Forum aktuell zu halten.

Im Moment plädiere ich daher, mal das Update durchzuziehen. Mir scheint, dass dieses Problem bereits gelöst wurde.

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme.

In der aktuellen Version kommt es, wenn man sich im Posting befindet und auf löschen klickt - würde ich sagen. Das konnte ich zumindest in Deinem Forum gerade so nachvollziehen. Hierzu musst Du das Löschen in einem neuen Tab vornehmen, sodass das JS-Alter nicht erscheint (klick mit der mittleren Maustaste).

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast,

Den aktuellen, welchen sonst.

Aber klar, ich habe jetzt nicht geschaut, wann welche Modifikation durchgeführt wurde. Insofern kann ich bestimmte Äußerungen auch nicht direkt reproduzieren. Auf meiner Seite versuche ich das Forum aktuell zu halten.

Im Moment plädiere ich daher, mal das Update durchzuziehen. Mir scheint, dass dieses Problem bereits gelöst wurde.

So sollte er es auch tun. Vorsichtshalber sollte Andreas aber ein Backup des gegenwärtigen Datenbankstands erzeugen, der die Datenbankstruktur der Version 2.4.24 widerspiegelt. Dann muss er, falls irgendetwas schief läuft, nicht wieder am Ausgangspunkt beginnen. Und er muss prüfen, ob sich mehrere Accounts finden, die die selbe E-Mail-Adresse benutzen. Weil dann das Update unweigerlich schief gehen würde.

Das lässt sich in einem Datenbanktool wie der MySQL-Workbench oder phpMyAdmin mit dem folgenden Query prüfen. Die Tabellennamen sind bei Bedarf anzupassen.

SELECT
  `user_id`,
  `user_name`,
  `user_email`
FROM `mlf2_userdata`
WHERE `user_email` IN(
  SELECT
    `user_email`
  FROM `mlf2_userdata`
  GROUP BY `user_email`
  HAVING COUNT(`user_email`) > 1)
ORDER BY `user_email` ASC, `user_name` ASC

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme.

In der aktuellen Version kommt es, wenn man sich im Posting befindet und auf löschen klickt - würde ich sagen. Das konnte ich zumindest in Deinem Forum gerade so nachvollziehen. Hierzu musst Du das Löschen in einem neuen Tab vornehmen, sodass das JS-Alter nicht erscheint (klick mit der mittleren Maustaste).

Ahh, das geht tatsächlich nur mit der mittleren Maustaste oder über das Kontextmenü. Wenn ich stattdessen die Kombination [STRG]+[Linksklick] benutze, die ebenfalls einen neuen Tab öffnen sollte, wird mir, wie beim einfachen Linksklick, der JS-Modaldialog angezeigt. Und ja, da gibt es in der Version 2.4.24 keinen CSRF-Token, egal ob in meinem Theme oder dem mitgelieferten.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

habe grade das Update von 2.4.24 auf 20220803.1 durchgezogen.
(Backup der Files und Backup der DB vorher).

Die bei mir aufgetretenen Fehler von damals und die neuen im Schnelldurchgang:

#1 Datumsanzeige mit unerwarteten % Zeichen - fehlerfrei
#2 Fußzeile versetzt - fehlerfrei
#3 Einstellungen ohne Text (Adminbereich - Einstellungen) - fehlerfrei
#4 Adminbereiche Symbol für die Bilder ohne Text - besteht
#5 Symbol ist klickbar - aber es werden weder bestehende, noch frisch hochgeladene Dateien angezeigt (ich kann die Bilder die im html Quellcode genannt sind aber übers Web aufrufen)
#6 neuer Eintrag (Posting) - fehlerfrei
#7 löschen nicht möglich - keine der 3 Methoden funktioniert
(der von Micha genannte "erwartete" hidden Eintrag mit dem csrf_token fehlt)

#8 Geschwindigkeit in der Bedienung ist unterirdisch

Der Hinweis mit var_dump vom Token:
Wird posting.inc.php mit delete_posting aufgerufen, ist der Token vorhanden.
Wird sie mit delete_posting_confirmed aufgerufen - fehlt er.
Testhalber bei den case Varianten "edit" und "posting" - fehlt ebenfalls.

Gruß
Andi

Hi,
da ich von einer fehlenden/falsch kopierten Datei ausgegangen bin,
habe ich ein neues Forum aus den neuesten Quellen aufgesetzt.

#7 löschen nicht möglich - keine der 3 Methoden funktioniert
(der von Micha genannte "erwartete" hidden Eintrag mit dem csrf_token fehlt)

obwohl ich gemäß Anleitung aus den Quellen themes/default/* kopiert hatte,
gab es hier Unterschiede.
Ich habe dann aus der Neu-Installation themes/default/* rekursiv erneut drüberkopiert.

-> Fehler 7 ist verschwunden, der Token steht jetzt korrekt im html-Quellcode.

Im Forum welches die Updates erlebt hat, ist der Dialog zum löschen noch klassisch
(Text mit Button).
Beim neu installierten Forum dunkelt der Browser ab und ein Popup erscheint.

Ich check mal weiter ob die anderen Dinge auch machbar sind.

Gruß
Andi

Hallo

-> Fehler 7 ist verschwunden, der Token steht jetzt korrekt im html-Quellcode.

Ok, es hätte mich auch gewundert, wenn das prinzipiell nicht funktioniert hätte. Es gibt ja einige Installationen und ich gehe davon aus, dass ein solcher Fehler, wäre er im Programmcode verborgen, nicht erst ein halbes Jahr nach Veröffentlichung der aktuellsten Version aufgefallen wäre. Aber schön, dass du es, wenn auch erst einmal im Testlauf, hinbekommen hast.

Im Forum welches die Updates erlebt hat, ist der Dialog zum löschen noch klassisch
(Text mit Button).
Beim neu installierten Forum dunkelt der Browser ab und ein Popup erscheint.

Wie von Micha und mir in den Vorpostings erörtert (meine Frage, Michas Folgeposting und meine Reaktion (im letzten Absatz)), sieht das schon in meiner MLF-2.4.24-Installation so aus. Nur wenn man den Löschen-Link für ein Posting auf eine ganz bestimmte Art öffnet, sieht man die Seite mit dem Formular, das den CSRF-Token enthalten soll. Ansonsten bekommt man den JS-basierten Modal-Dialog zu sehen.

[edit]: Wenn das in deiner Installation, die du mit den Updates auf den neuen Stand gebracht hast, nicht so ist, dann könnte es sein, dass du entweder vergessen hast, die JavaScript-Dateien hochzuladen oder, dass dir dein Browsercache einen Streich spielt und meint, es gäbe keinen neueren Dateistand, als den, der im Browsecache bereits vorhanden ist. Lade die Dateien aus dem Unterverzeichnis javascript bitte noch einmal in deine upgegradete Installation hoch und lade in deinem Browser eine Seite des Forums oder alle geöffneten Tabs mit Seiten des Forums mit [STRG]+[F5] neu. Auf diese Weise werden alle Dateien neu vom Server geholt.

Ich check mal weiter ob die anderen Dinge auch machbar sind.

Mache das bitte.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Der Verweis zum Thread:
https://mylittleforum.net/forum/index.php?id=11863

Der Verweis, wo es in der posting.inc.php stehen soll:
https://github.com/My-Little-Forum/mylittleforum/pull/469/files

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry

Bei Candleman war das Problem, dass er offensichtlich vergessen hatte, beim Update einige Subtemplates hochzuladen, was dazu führte, dass der ab der Version 2.4.20 an der Stelle vorausgesetzte Token nicht im Template stand und somit auch nicht an den Server übertragen wurde, als er gebraucht wurde. Das ist bei dir aber der Fall. Das Token steht in der URL als deren Parameter csrf_token drin. Das ist es also nicht.

In der von mir mit 2.4.24 eingespielten posting.inc.php befindet sich in Zeile 1373 folgendes:

if ($authorization['delete'] === true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] == $_SESSION['csrf_token']) {

und das entspricht syntaktisch nicht dem was hier
https://github.com/My-Little-Forum/mylittleforum/pull/469/files
erwähnt wird.
Dort:
if ($authorization['delete'] == true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] === $_SESSION['csrf_token']) {

sind die Prüfungen "==" und "===" anders geschrieben.

Die Prüfungen sind unterschiedlich streng. Mit zwei Gleichheitszeichen wird in PHP "nur" geprüft, ob die Werte gleich sind, mit drei Gleichheitszeichen zudem, ob sie vom selben Datentyp sind.

Kleiner Exkurs:

Da PHP automatische Typumwandlungen bereitstellt, ist nicht nur "2" == "2" (zwei Zeichenketten, die jeweils aus der Ziffer 2 bestehen) wahr, sondern auch "2" == 2 (eine Zeichenkette, die aus der Ziffer 2 besteht und ein Integerwert 2). Wenn man typsicher vergleicht (mit drei Gleichheitszeichen), ist "2" === "2" wahr, aber "2" === 2 unwahr, da es sich um unterschiedliche Datentypen handelt.

Was den von dir gezeigten Code betrifft, gilt, dass man für die Prüfung der übermittelten Zeichenkette des Tokens gegen eine auf dem Server gespeicherte Version der selben Zeichenkette keine Typsicherheit braucht, für die Prüfung der als boolescher Wert gespeicherten grundsätzlichen Erlaubnis, ein Posting zu löschen ($authorization['delete'] === true), aber schon, da die automatische Typumwandlung in PHP bei der Prüfung mit nur zwei Gleichheitszeichen auch 1 zu true machen würde. Wir wollen aber explizit auf den aus der Funktion get_edit_authorization, in der der Wert für $authorization['delete'] ermittelt wird, gelieferten Wert (true oder false) prüfen.

Meine bescheidenen Versuche das einzugrenzen enden dahingehend, dass in Zeile 1374 der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.

Woran machst du das fest?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

mich würde gerade mal interessieren, inwieweit wir alte Versionen supporten. Wenn ich mir die Changelog der Nachfolgeversion ansehe, dann wurde da erneut an der Delete-Funktion gearbeitet (added a CSRF-token to posting delete function calls). Wäre es nicht erst einmal ratsam, auf die letzte version zu updaten und dann zu schauen, ob es noch Probleme gibt?

Frohe Ostern wünsche ich Dir natürlich!
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

würde ich sofort mitmachen; das Update steht bereit.
Ich wollte nur den Fehler nicht mitziehen.

Falls es Sinn ergäbe: in der Testumgebung kann ich für euch ja nen Admin Account
einpflegen; dann könntet ihr wenigstens reinkucken.

Gruß
Andi

Hallo

Ich habe das mal umsortiert.

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Gut, damit kennen wir die Grundlage.

beim Durchprobieren bin ich hier drauf gestossen:

Der Beitrag hat keine Antwort, wurde vor Sekunden bearbeitet (als Admin),
kann aber nicht gelöscht werden.
Eine Sperrung ist nicht erkennbar.

Wie lautet die Einstellung für das Sperren(bzw der Zeitablauf dafür)?

Diese Einstellungen haben mutmaßlich nichts mit dem Problem zu tun, aber die relevanten Einstellungen lauten (Erklärungen sind der Wiki-Seite Configuration entnommen und mehr oder minder exakt übersetzt):

edit_max_time_period

maximale Zeitspanne während der ein Posting bearbeitet werden kann (in Minuten)
ergänzt user_edit und user_edit_if_no_replies

edit_min_time_period

Zeitspanne, während der ein eigenes Posting noch bearbeitet werden kann (in Minuten), obwohl es schon eine Antwort hat und user_edit_if_no_replies nur das Bearbeiten von Postings ohne vorhandene Antwort erlaubt (1)
übersteuert user_edit_if_no_replies für X Minuten

user_edit

Erlaubnis oder Verbot der Bearbeitung eigener Postings
- nicht erlaubt (0)
- erlaubt für registrierte Benutzer (1)
- erlaubt für alle Benutzer und Besucher (2)

user_edit_if_no_replies

Schalter für die Bearbeitung von eigenen Postings
- nur ohne bereits vorhandene Antworten (1)
- oder auch bei bereits vorhandenen Antworten (0)
ergänzt user_edit

Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Ich vermute, dass das die Ursache dieses Problems ist. zu diesem Problem gab es im Laufe der Zeit mehrere Meldungen. Wir haben dann versucht, die Ursache zu finden und Micha hat da auch ein paar Spezialfälle entlarvt und den Code angepasst, damit das nicht mehr geschieht.

Zu deinem Fall habe ich Fragen.

- Gibt es dieses spezielle Posting noch?
- Wenn ja, hat es in der Übersichtsseite einen Autor, der nicht "unbekannt" heißt?
- Wenn ja, was ist bezüglich des Autors in dem zum Eintrag gehörenden Datebankeintrag angegeben? Das ist ja entweder ein Eintrag in dem passenden Feld des Postings in mlf2_entries (nicht angemeldeter Bsucher) oder im selben Eintrag die User-ID aus mlf2_userdata (registierter und eigeloggter Benutzer).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Diese Einstellungen haben mutmaßlich nichts mit dem Problem zu tun, aber die relevanten Einstellungen lauten (Erklärungen sind der Wiki-Seite Configuration entnommen und mehr oder minder exakt übersetzt):

danke, da grabe ich mich jetzt durch

Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Ich vermute, dass das die Ursache dieses Problems ist. zu diesem Problem gab es im Laufe der Zeit mehrere Meldungen. Wir haben dann versucht, die Ursache zu finden und Micha hat da auch ein paar Spezialfälle entlarvt und den Code angepasst, damit das nicht mehr geschieht.

Zu deinem Fall habe ich Fragen.

- Gibt es dieses spezielle Posting noch?

ja, gibt es noch; lässt sich jederzeit wiederholen.
Neues Thema schreiben, abschicken. Sofort wieder rein, löschen über die Methode 1+3 nicht möglich.

- Wenn ja, hat es in der Übersichtsseite einen Autor, der nicht "unbekannt" heißt?

korrekt, mein Name steht dort; der Name "unbekannt" wird erst mit der Fehlermeldung angezeigt.
Bis zum drücken von "OK" -> also jetzt löschen steht der korrekte Name dort.

- Wenn ja, was ist bezüglich des Autors in dem zum Eintrag gehörenden Datebankeintrag angegeben?

Das ist ja entweder ein Eintrag in dem passenden Feld des Postings in mlf2_entries (nicht angemeldeter Bsucher) oder im selben Eintrag die User-ID aus mlf2_userdata (registierter und eigeloggter Benutzer).

Wenn ich Dich richtig verstanden habe, folgendes Ergebnis:

SQL-Abfrage:
sql_mlf2 "select id,pid,tid, edited,user_id,name,subject, text,marked,locked,sticky from mlf2_entries where id='169464'"

Antwort der DB:

+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
| 169464 | 0 | 169464 | 0000-00-00 00:00:00 |   12 |  | test 8 | asdf asdf a |    0 |    0 |    0 |
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+

Es steht die richtige User-id (=12) drin, aber kein Name.

Gruß
Andi

Hallo,

SQL-Abfrage:
sql_mlf2 "select id,pid,tid, edited,user_id,name,subject, text,marked,locked,sticky from mlf2_entries where id='169464'"

Antwort der DB:
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
| 169464 | 0 | 169464 | 0000-00-00 00:00:00 |   12 |  | test 8 | asdf asdf a |    0 |    0 |    0 |
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
Es steht die richtige User-id (=12) drin, aber kein Name.

Ja, dass ist mMn. auch in Ordnung. Das Feld `name` wird nur ausgefüllt, wenn der Eintrag von einem unregistrierten Nutzer erstellt wird. Ist der Nutzer registriert, so wird anhand der `user_id` der Name aus der Nutzertabelle abgefragt und dann eingesetzt - also theoretisch. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

RSS Feed of thread