New update script made upgrading now impossible

[CodeALot]

(Trying to upgrade from 2.13.8 -r20 to 2.13.9 -r24. PHP version 8.3.24)
The old problem, where the "upgrade" script would overwrite the config.php entirely with EMPTY fields, is now a permanent one.
In earlier versions, I could trick the system by setting config.php to 444 temporarily, but now that doesn't work anymore.

I really don't understand why this problem still persists. I can't be the only one.

[dbs]

by setting config.php to 444 temporarily

you mean temporarily to 644

[crnogorac081]

I Make s copy of confing.php then Rename to config.php

[sternchen8875]

I sent a modified script to CodeALot for testing via email this morning, but I haven't received a reply yet. I'm sure it will come later, but here's the information for everyone affected.

In the upgrade script of version WB 2.13.9 R24, there's a theoretical possibility that the script could be interrupted, for example, if an error occurs during reading. Those for whom it works immediately won't notice anything, which is why it's so difficult to test.

The "normal" WebsiteBaker installation sets the write permissions for config.php to chmod 0644. 664 would also be possible here. The 7xx ranges would be riskier.

To create a kind of write protection, there used to be a tip to protect config.php with chmod 0444. This means the file can be read (by anyone with read permissions on the server). In simple terms, anyone who has access to executable files could, for example, read the database access data. And anyone who can do that can, of course, also change the write protection. So it's not a vault; it's more to protect against unintentional changes or deletions, for instance, during development.

As reported in the other thread, we had the same problem once before in the testing group in the spring. There, too, it was reported that changing the write permissions resulted in success, which defied all logic. After several inquiries, no one was sure anymore exactly what was done when.

In fact, with the current script, chmod 0444 actually accelerated the error, because an interruption was generated at this point (our error message in the popup). Due to the interruption, the data was then empty, and nothing could be written. Writing the data to a temporary file also didn't work.

In the attached script, the logic has now been changed. Now, everything is read first, separately buffered, then a comparison is made against a marker in line 1 of config.php. If the marker is present, a new config.php does not need to be written; the writing process is skipped. This marker was introduced with WB 2.10.x. In other words, if the WB version is newer than WB 2.10.0, the config.php file will no longer be touched.

Further in the process: If the marker comparison is positive and the config.php needs to be rewritten, a check for write permissions is performed first, with two options (error or continue), and only then are the buffered values used.

Regarding the process: anyone who sees this popup already has a newly written config.php and can continue the upgrade by clicking "Restart Program."
https://i.gyazo.com/8c3ff3c5bd8d42b4dbbf51b153e76c6c.png

If there are problems with write permissions or other errors, a message with a red header will appear, for example, like this:
https://i.gyazo.com/d22f85d22ecbf0ad454fca1e8a2b08ee.png

Where the upgrade script starts directly, no modification of the config.php was necessary, and the upgrade can begin immediately.

The attached ZIP also contains a file getRemoveList.php, an upgrade-error.css, and the new upgrade-script.php.

All three files belong in the /install directory. Existing files with the same name must be overwritten.

I hope this problem is now solved and would appreciate your feedback.


german translation

Habe CodeALot heute vormittag ein geändertes Script zum Test gesendet per Email, aber noch keine Antwort, kommt sicher später noch, aber hier für alle Betroffenen.
Im UpgradeScript der Version WB 2.13.9 R24 gibt es eine theoretische Möglichkeit, das das Script unterbrochen wird, wenn z.b. ein Fehler beim Einlesen auftritt. Alle die, wo es auf Anhieb funktioniert, bemerken davon nichts, darum ist es auch so schwer zu testen.
Die "normale" WebsiteBaker-Installation setzt die Schreibrechte für die config.php auf chmod0644. Möglich wäre hier noch 664. Risikoreicher wären die 7xx Bereiche.
Um eine Art Schreibschutz zu generieren, gab es früher mal den Tip, die config.php mit chmod 0444 zu schützen, das bedeutet, die Datei darf (von jedermann mit Leserechten auf dem Server) gelesen werden, heißt in einfachen Worten, wer Zugang zu ausführbaren Dateien hätte, könnte z.b. die Datenbank-Zugangsdaten auch auslesen. Und wer das kann, kann dann natürlich auch den Schreibschutz ändern. Es ist also kein Tresor, es schützt eher vor unbeabsichtigten Verändern oder Leeren, z.b. in der Entwicklung.

Wie im anderem Thread berichtet, hatte wir gleiche Problematik bereits einmal im Frühjahr in der Testgruppe. Auch da wurde berichtet, das mit Änderung der Schreibrechte ein Erfolg stattfand, was entgegen aller Logik stand. Nach mehreren Nachfragen war sich am Ende niemand mehr sicher, was wann genau getan wurde.

In der Tat war es im aktuellen Script so, das ein chmod0444 den Fehler eher noch beschleunigt, weil an dieser Stelle ein Abbruch erzeugt wurde (unsere Fehlermeldung im Popup). Durch den Abbruch waren die Daten dann leer und es konnte nichts geschrieben werden. Das Schreiben der Daten in eine temporäre Datei brachte auch nicht den Erfolg.
Im beigefügten Script wurde nun die Logik geändert. Nun wird zuerst alles eingelesen, separat zwischengespeichert, dann erfolgt der Abgleich auf einen Marker in Zeile 1 der config.php. Ist der Marker so vorhanden, muß keine config neu geschrieben werden, der Schreibvorgang wird übergangen. Dieser Marker wurde mit WB 2.10.x eingeführt. Mit anderen Worten: ist die WB-Version neuer als WB 2.10.0, wird die Datei config.php nicht mehr angefaßt
Weiter im Ablauf: Ist der Marker-Abgleich positiv und die config.php muß neu geschrieben werden, erfolgt erst der Abgleich auf die Schreibrechte, mit den zwei Optionen Fehler oder Weiter und erst dann werden die zwischengespeichert en Werte benutzt.

Zum Ablauf: wer dieses Popup sieht, hat bereits eine neu geschriebene config.php und kann das Upgrade mit Klick auf Restart Program fortgesetzen.
https://i.gyazo.com/8c3ff3c5bd8d42b4dbbf51b153e76c6c.png

Gibt es Probleme mit Schreibrechten oder anderen Fehlern, erscheint eine Message mit rotem Header, z.b. so
https://i.gyazo.com/d22f85d22ecbf0ad454fca1e8a2b08ee.png

Wo direkt das Upgrade-script startet, war keine Bearbeitung der config.php notwendig und das Upgrade kann direkt starten.

Im angehängtem ZIP findet sich noch eine Datei getRemoveList.php und eine upgrade-error.css sowie die neue upgrade-script.php

Alle drei Dateien gehören ins Verzeichnis /install. Vorhandene gleichnamige Dateien müssen überschrieben werden.

Ich hoffe, das dieses Problem nun gelöst ist und würde mich über Rückmeldungen freuen

[CodeALot]

Hi Uwe,

I have just sent you an e-mail with my findings. Unfortunately I did not yet succeed to perform the upgrade, even with your two new files...

[sternchen8875]

with this file from my last post???

not possible (i think), sorry

[CodeALot]

by setting config.php to 444 temporarily

you mean temporarily to 644

No, in the "older" way of upgrading, I could trick the script and keep it from overwriting my config.php with 'nothing'. After that first step, I changed it back to 0644 and continued the upgrade.
In the new situation, this is no longer possible.

[CodeALot]

with this file from my last post???

not possible (i think), sorry

Sorry! I didn't see you posted an even newer version. It works now. Thank you!

[sternchen8875]

  and Thanks for this replay