Did the upgrade today.
Backup made √
Update performed √
Database updated when finished √
The only hiccup for me was the refusal of the installer to proceed due to a empty cgi folder, and a .well-known folder. Both of these are put there by cPanel.
No problem I could delete them, but I would question why they couldn’t just be ignored.
All in all a smooth upgrade, thanks.
@jimlongo Thanks for the feedback!
Is it always safe to delete those folder if they’re empty? I don’t think any of the regular phpList developers use cpanel to be able to test.
If the folders you mention can always be safely deleted then perhaps the updater could check if the found additional files matched with their names, and if they’re empty, just delete them.
The “well-known” folder is automatically created by cPanel in order to validate your domain for AutoSSL purposes. AutoSSL is an added feature of cPanel/WHM which offer you free SSL certificate for your domains, its also known as self-signed SSL certificate. The folder .well-known created while the time of the domain validation process as a part of AutoSSL installation.
It is safe to remove the folder if you want, however when the certificate is renewed every 90 days the folder will be re-created.
So the folder is not required for the SSL cert to work perfectly?
No, I think the cert would still work once it’s been installed, it’s part of the installation
On another note, I see the /texts folder has been replaced and in the process replacing my customized english.inc file.
Also what if there was any edited js files?
I guess it should be clear that any customizations would be lost, but isn’t the texts very commonly edited? It’s very nearly like the config file.
One other note about having to delete folders.
I usually keep the last and the current version readMe files in case I have to RTFM. I would have a folder php-list-337 and another php-list-338, etc.,
I guess the question is why do folders that have nothing to do with the installation need to be removed at all. What’s the harm? Couldn’t you just ignore everything except what you need to update?
What kind of changes do you make to the text files? I think that if those texts are edited so frequently then it should be possible to do so from the Web admin interface.
The readme files change rarely and do not include any kind of change log. Perhaps in the past they included release specific info but not any more. Therefore I don’t think you need to worry about keeping old ones.
I think the auto updater mechanism is to delete and replace the phpList folder. Therefore it’s not currently possible to replace files individually (and leave behind particular files). I believe this is the same concept used by other Open Source Web apps like Nextcloud.
Fair enough regarding the ReadMe files.
Sure the /texts language files can be edited in the UI, but that’s not my point.
They have usually been (at least in my case) heavily edited, and like the config files shouldn’t be overwritten.
@jimlongo happy to hear that you had a smooth upgrade. Regarding some dot files, it’s actually something that is in future development plans to ignore them. The only directory that is not overwritten during the update is the config folder since everything else can be changed in future releases.
If you have made changes to the files, a backup of the files is recommended,
@jimlongo If it is possible to edit them in the UI, then that is a better means of doing it in as much as those translations will be stored in the database and not overwritten even if all application files are.
However it may be possible to check if the MD5 hash of those files indicates they have been modified, and stop the upgrade if it is detected that they have. That way you could not lose changes that you’ve manually applied. Would such a compromise work for you?
Thanks @samtuke
I’m sorry I was thinking I had made those extensive changes in the english.inc file, as I’ve always made sure to keep the old one - I’m pretty sure the upgrade instructions always told me to do that 
I see your point about setting those texts available in Config > Settings and having them stored in the db. I do have plenty of those.
I think your compromise is fine, and then a message to make sure you’ve backed up your files.
Thanks.
You can place a modified front-end language file in the web root directory and that will be used instead of the original file in the “texts” directory. See this piece of code in index.php
// Allow customisation per installation
if (is_file($_SERVER['DOCUMENT_ROOT'].'/'.basename($pagedata['language_file']))) {
include_once $_SERVER['DOCUMENT_ROOT'].'/'.basename($pagedata['language_file']);
}
That doesn’t help with using the new updater as that will be an unrecoginised file but it avoids you having to re-apply changes or save/restore the file.
Actually such a file in the web root directory is loaded after the original file, so it needs to contain only changed translations, no need for items that have not been changed.