2.13.8 Upgrade Script gives error 500

[CodeALot]

This is in my server errorlog:

Code: [Select]

[Fri Aug 22 15:06:03 2025] [proxy_fcgi:error] [pid 1321367:tid 140222830475008] 31.21.129.220:0 AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Undefined constant "WB_URL" in /var/www/vhosts/mydomain.nl/httpdocs/install/upgrade-script.php:277\nStack trace:\n#0 {main}\n  thrown in /var/www/vhosts/mydomain.nl/httpdocs/install/upgrade-script.php on line 277'
PHP-Version: 8.3.24

EDIT:
Solved it by (again, this happened in an earlier version as well) setting the CONFIG.PHP to 0644, start the upgrade script. but ONLY the first step, then set CONFIG.PHP to 0444 and then continue the upgrade. If you don't, the upgrade will erase your CONFIG.PHP after you continued to the second step.

[sternchen8875]

First and foremost, thank you for the information. This issue did surface once before in the spring in a test-upgrade, but we were unable to determine the cause at the time. We really appreciate that you stayed on top of it

(english)
A Dilemma of Responsibilities: CMS vs. User

By design, WebsiteBaker recommends chmod 0644 permissions for the config.php file. However, a user may change this to chmod 0444 to protect the file from write access for security reasons. So far, so good. The issue is that many upgrades require this file to be rewritten because its structure has changed. When upgrading from an older version (I would have to check where the transition was made), the new version of config.php is mandatory. Therefore, we cannot simply decide to skip rewriting the config file just because a user has set it to chmod 0444.

Technically, the script's built-in permission check (is_writable()) can be misleading and return true if the file owner is the same user that the web server process runs as. As the owner—which is the case for most main users—the upgrade script is granted permission to write, causing the is_writable() condition to be met (which is the case you are currently experiencing).

The only truly safe approach is a complete abort of the process, which includes a prompt for the user to change the file permissions for config.php—because one thing is clear: an empty config.php file must be prevented at all costs.

Here is the link to a new version that explicitly checks the config.php file's permissions and correctly triggers an abort, even in cases where the standard ownership check would grant a general (FTP) permission. In this scenario, the script will now abort with a screen that looks like the image shown below.

https://addon.WebsiteBaker.org/en/browse-add-ons/?id=04C12556

The download is a ZIP file. As usual, place this ZIP file in the root directory of WebsiteBaker and unpack it using the Unzip.php. Both files belong in the /install directory.

In an upcoming update, we will further secure this process by using a temporary file. However, we also believe that we should not override a user's settings and bypass their read-only protection. This is why we feel that aborting the process is the only correct solution for now.


(german)
Eine Zwickmühle.... zwischen CMS- und User-Verantwortlichkeiten
 
In der Theorie gibt WB die chmod 0644 für diese Datei vor. Der User ändert dies auf chmod 0444, um die Datei vor Schreibzugriffen zu schützen. So weit, so gut. Nun ist es aber bei vielen Upgrades notwendig, diese Datei neu zu schreiben, weil sich der Aufbau geändert hat. Kommt man von einer älteren Version (ich müßt schauen, wo der Übergang war) braucht es zwingend die neue Version der config.php. Ich kann also nicht sagen, wir übergehen das Schreiben der neue config, weil dort ein chmod 0444 eingestellt ist.
Technisch ist es so, das die im Script eingebaute Prüfung der Dateirechte fehltschlägt bzw true ist, wenn der Eigner im FTP der gleiche ist wie der Benutzer. Als Eigner, der in den meisten Fällen auch der Hauptbenutzer ist, hat man immer diese Berechtigung über das Upgrade-Script, die Bedingung für is_writable() ist dann also true (dein aktueller Fall)
 
Sicher wäre wohl nur ein kompletter Abbruch mit Aufforderung zum Ändern der Dateirechte für die config.php - denn klar ist: eine leere config.php darf dann auch nicht sein

Hier der Link zu einer neuen Version, die explizit die Datei config.php auf ihre Schreibberechtigung en prüft und auch einen Abbruch liefert, wenn die Eignerprüfung eine generelle (FTP)-Berechtigung erteilt.

https://addon.WebsiteBaker.org/en/browse-add-ons/?id=04C12556

In diesem Fall erfolgt nun ein Abbruch, der optisch ausschaut wie unten gezeigtes Bild.

Der Download enthält eine ZIP-Datei (mit zwei Files) legt man, wie gewohnt, ins Hauptverzeichnis von WebsiteBaker und kann sie dann mit der Unzip.php entpacken. Beide Dateien gehören in das Verzeichnis /install.

Im nächsten Update werden wir dieses Problem mit einer temporären Datei zumindest absichern, allerdings sollten wir uns auch nicht über User-Einstellungen hinwegsetzen und den Schreibschutz übergehen. Darum kann der folgende Abbruch nur die eine Lösung sein.