Move the existing value of mail_smtp_prefix to mail_smtp_secure

[Jako]

What does it do?

Copy the existing value of mail_smtp_prefix to mail_smtp_secure if the new mail_smtp_secure key exist and remove the mail_smtp_prefix setting on success.

Why is it needed?

The system setting mail_smtp_secure can be created during the update before the upgrade script is executed.

Related issue(s)/PR(s)

#16062

[Ruslan-Aleev]

Maybe the script should be called wider (3.0.0-update-system-settings-keys.php, for example) so that in the future it can be used for other system settings?

[opengeek]

Maybe the script should be called wider (3.0.0-update-system-settings-keys.php, for example) so that in the future it can be used for other system settings?

No. These are specific to a change and are thus atomic to that change. They should not be reused.

[Ruslan-Aleev]

No. These are specific to a change and are thus atomic to that change. They should not be reused.

I understand, yes, but, for example, there are already too many atomic scripts for updating system settings (see the current state).
Wouldn't it be easier to create a common script (one for updating settings, another for deleting settings, a third for updating keys), and add sys keys in this files in the future? And for future versions, just copy the structure of these scripts (but without the code).
It's just a suggestion, maybe it's overkill.

[opengeek]

I understand, yes, but, for example, there are already too many atomic scripts for updating system settings (see the current state). Wouldn't it be easier to create a common script (one for updating settings, another for deleting settings, a third for updating keys), and add sys keys in this files in the future? And for future versions, just copy the structure of these scripts (but without the code). It's just a suggestion, maybe it's overkill.

Actually, the only reason these are even broken out is because we used to have to have separate scripts for MySQL and sqlsrv and these files served as a way to share certain specific parts that were "common" to both. This is no longer the case. So technically, moving forward, we can put all of the upgrade logic directly into the single upgrade file.

[alroniks]

So technically, moving forward, we can put all of the upgrade logic directly into the single upgrade file.

Better to move to approach with migrations, and every migration should be atomic and revertable (usually rollback is rare case, but ideally it would be nice to have such ability).