View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019696||Automatic Updater||[phpList 3 application] Interface - Administrator||public||12-01-19 19:52||14-01-19 17:20|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Product Version||[phpList 3 application] 3.3.7|
|Target Version||Fixed in Version|
|Summary||0019696: Updater: Backup path not editable and block of manual download config.php|
I was using latest phplist 3.3.7 and trying the automatic updater for update to v. 3.3.8 for the first time.
When starting the updater it asked for backup and I confirmed. Then I was show this backup path: /var/backup.zip
I wanted to change that path (and also not knowing *what* will be backed up - config.php or the whole phplist system), but I could not change the path. I am using phplist on a shared hosting environment, so I have no access to /var .... and a changeable backup path would be nice -> Maybe in the future it could also be set in the config.php?!
So I skiped back to my admin panel to first back up my config.php an config_extended.php via ftp. I could *not* download/backup these files any more. They were some kinde of "locked". So I clicked back on the updater, thinking that it would start the task from the beginning, sking for backup etc. - no it seems to remember my last state and downloaded and installed the update immediately!
The update v. 3.3.8 itself went fine, but my config.php file ist still locked and I can't download it via ftp. I'm not shure if that is a updater issue but wanted to give some feedback in case someone else noticed that behavior.
||@blu-IT thanks for the feedback. Can you "download" other files using FTP or is config.php the only one? Can you check if there is error log on your FTP client?|
@xheni Hi, thanks for your help. So I tried again now and suddenly the download worked!
I still would like to understand and modify the backup path in the future - maybe it could be set in the config.php...
Also when switching back to some other site or the admin panel, it would be great if the updater process would be really interruppted and started again from step 1.
@blu-IT I'm glad that it works. It would cause multiple issues if would start again from step 1, eg: if updater could be currently under maintenance mode step, or in the step where old files are deleted and the new ones not yet moved in place etc.
The current step is saved to avoid such issues, but if you want to start from step 1 again and take the risk, you should manually delete actions.txt which is created in config directory when the update process starts.
Saving the back up path in config.php in the future sounds like a good idea.
|12-01-19 19:52||blu-IT||New Issue|
|12-01-19 19:52||blu-IT||Tag Attached: updater|
|14-01-19 10:33||xheni||Note Added: 0061693|
|14-01-19 12:44||blu-IT||Note Added: 0061694|
|14-01-19 13:33||xheni||Note Added: 0061695|
|14-01-19 17:20||xheni||Status||new => closed|
|14-01-19 17:20||xheni||Resolution||open => fixed|