Open marcbria opened 7 months ago
I've just double-checked what happens when the driver isn't specified on a local 3.4.0-x checkout, and running php tools/upgrade.php upgrade
dies immediately with Mailer driver isn't specified in the application's config
error message. The database isn't corrupted in the process, so it should just be necessary to add the missing configuration (as documented in the release notes) and re-run the upgrade.
Can anyone verify that the database can be corrupted without this config being added?
Describe the bug The issue was initially posted in the support forum here.
In short, if config.inc.php is not properly updated between minor upgrades, the upgrade can't finish the process and left a corrupted DB.
To Reproduce Steps to reproduce the behavior:
What application are you using? OJS, OMP or OPS version 3.3.x
Additional information Detailed error log is:
As far as config.inc.php usually change between minor or major upgrades, this becomes a quite usual issue. As far as the DB is left corrupted and some fellows don't remember to backup-before-upgrade, I feel this need to be properly priorized.
A possible minimal solution is adding pre-fight check of the config.inc.php to confirm all the essential/new vars are included (or at least, the new ones added between usual upgrade paths). List of new vars is published in the Release Notes.
A middle ground solution would be adding a config validator that could be cached based on the modified date + application version.
An improved solution (suggested by Andrew Gearhart) would be create a "config builder". It will be able to handle valid, discontinued, and required settings across different software versions, specifying supported values (like "On/Off, True/False, 1/0, String, Integer, Float"). Using YAML/JSON file will facilitate the editing and potentially implementing a front-end TUI for creating the config file can streamline the process and address previous challenges in passing configurations.
The final solution will probably be stop maintaining a homebrew config file and adopt standard tools for config file maintenance. Preferably that would mean Laravel's (since we're going that way with so much else).
For any final solution other issues also need to be taken in consideration as: