View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018450 | phpList 3 application | General | public | 15-12-16 17:45 | 31-01-17 21:34 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.3.0 | ||||
| Fixed in Version | 3.3.0 | ||||
| Summary | 0018450: Disallow upgrade to 3.3 if minimum PHP version not met | ||||
| Description | phpList 3.3 requires a newer version of PHP than 3.2.6. To prevent users upgrading phpList, and their database, without meeting the minimum system requirements (and encountering fatal errors), check the version of PHP currently running before the upgrade starts and disallow the procedure if necessary. | ||||
| Tags | No tags attached. | ||||
|
|
changed 3.2.7 to 3.3 in line with new roadmap |
|
|
Interesting. I never thought about blocking upgrade when the PHP version is not correct. Currently it will warn you when the version is not correct, but that's it. THis is web software, not desktop. WHen the code is in place, it has already been upgraded, and there's no going back. In that case blocking upgrade of the DB would be counter intuitive to me. |
|
|
good point, perhaps we should file this under the project to make a one click update feature? If no one disagrees i will do that. |
|
|
This idea was suggested because, a few weeks ago, it seemed that php 5.6 was going to be the minimum required version of php. I don't know whether that is still the case as there are is now a file php_compat.php and a directory random_compat that might be avoiding that restriction. If 5.6 really is going to be the minimum then we need to understand when and how phplist would fail when using an earlier version. Possibly even trying to access the index page would fail. |
|
|
Hi Duncan, I have reviewed the email discussion about PHP version and am looking at how we can be clearer about PHP versions over the coming releases, I agree there is an issue here and so I have marked this as a priority task. Do you have any ideas about M's noted problem though? The problem we have is that the upgrade process is like: Copy config Replace all phpList files with new version using ftp Log in Update database if needed ie: by the time they have shown intent to upgrade the files are already replaced, so if they then got an error, they would actually need to downgrade. I guess it's different with the auto-installers though. I am not sure how we can get around this other than documenting better. We could have a "dependency check" page / button or something? And suggest people use it before they upgrade? |
|
|
What, if anything, to do depends on whether the version of php is a hard requirement or just a recommendation. |
|
|
I remember I used a tool to generate the list on https://resources.phplist.com/system/start but now I can't find it any more. Duncan, do you remember what it was? I'll keep searching. It would be useful to use something like that to figure out where the dependencies are. |
|
|
I think it was this one https://github.com/glenscott/php-dependencies |
|
|
Ah, I just ran it, but it only reports on PHP modules, not on the version of Core required. |
|
|
This package looks useful http://php5.laurent-laville.org/compatinfo/ I don't fully understand its output but it does seem to do a lot of analysis. Attached is the output from analysing phplist 3.2.6. |
|
|
|
|
|
Wow, that's brilliant. Looks like we're ok. I will try to add this to the Travis-CI tests. Interesting is this one: function_exists(cli_set_process_title) 1 standard 5.5.0 5.5.0 |
|
|
I've decided to do the following: PHP < 5.3 -> error showing "please upgrade PHP". We can change that with each release. I've also added "phpList older than 2 years" -> Error showing "Please upgrade phpList". This will mean we have to release at least once every two years. That seems achievable. |
