Why do you want to add it? Joomla runs good on all supported php versions. So there is imo no need for something like that aborts in the installer if you are not on php7 :)
But we could add another pre check warning that would not abort but shown that to the user in the installer.

I started with a message in the installer only. Users not using our installer would never see it.

I thought about having it in both the installer and the backend. That seemed excessive.

So, it's just something on your admin control panel. And at this point it's not much different than if you installed an old Joomla version and immediately saw a "update now!" notification. We don't alert over that in the installer either.

Bit of a moot point

What is?

I think what he is getting at is that we are warning people after they install which is kinda negative. But I don't think it's a big issue.

@Webdongle This warning does not say that your system is not able to handle Joomla or anything similar. It warns you about the current technology so that you are aware of it in case you are not. I think it is good to push people forward and have smart users than let users sleep in darkness by showing them only green happy messages. If you think about it, Joomla is not a smartphone app or anything like that. Plus, you can hide the warning and it goes away.

@mbabker your answer was very wise.

@eorisis
Yes I agree ... my point is that it's inconsitant not showing the warning during installation. Although that is a moot point because in the backend it always active and will provide a warning in the future.

Webhosts change server configuration AFTER Joomla is installed all the time - most commonly recently is that people are selecting PHP 7.x in their shared host, and don't select all the required modules for PHP (like php-xml php-mbstring) etc.. and so Joomla still runs... but certain features break...

For this reason I think the System Information page of Joomla Admin should re run all the requirement checking that the installer does... again... so that these issues can be quickly identified.

@PhilETaylor is there a list of required modules for PHP, so that when people like me select PHP 7.x in their hosting, we also know which modules to select? Might save lots of questions in the forum, etc, in the long run? Many thanks :)

You need to meet the requirements to run Joomla

https://downloads.joomla.org/technical-requirements

Packages like php-xml php-mbstring are the two most common that I see people forgetting to install

If you have a half good web host all the standard modules should be preselected.

However, it's not a bad idea to have these listed somewhere I suppose for the poor hosts.

On 10 May 2017, 06:50 +0100, DavidBoggitt notifications@github.com, wrote:

@PhilETaylor (https://github.com/PhilETaylor) is there a list of required modules for PHP, so that when people like me select PHP 7.x in their hosting, we also know which modules to select? Might save lots of questions in the forum, etc, in the long run? Many thanks :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#15845 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVgllR1-qi9fbleKQxUxPyL56L6SqQWks5r4VAzgaJpZM4NScO2).

If you have a half good web host all the standard modules should be preselected.

Incorrect. The preselected PHP modules are normally the default set provided by which ever control panel you use, E.g. cPanel.

That's true by the cPanel. But any half decent web host pre-selects the modules to be selected for all php versions available to run Joomla, Wordpress, Drupal and Magneto for exams. Hence how when people first install Joomla! It works out of the box, thus changing PHP Versions shouldn't make a difference.

This is from my experience with good an poor hosts too. agree or disagree that's up to you.

On 10 May 2017, 06:53 +0100, Phil Taylor notifications@github.com, wrote:

If you have a half good web host all the standard modules should be preselected.

Incorrect. The preselected PHP modules are normally the default set provided by which ever control panel you use, E.g. cPanel.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#15845 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVglpJ4UqoLxXA-iyXNAJdALOI9ngVLks5r4VDmgaJpZM4NScO2).

I have installed php7 since it's beta state, various of versions of it in all my development machines in the studio running Debian Jessie, but not my production servers yet because there are some things missing still and I need to find the time to dig into it to find alternatives in some cases such as GeoIP (currently using pecl geoip on php5). Although this one maybe slightly off topic, if anyone knows about php7 and geoip please send me an email.

Use Perlc geoip-v1.1.1

On 10 May 2017, 07:34 +0100, George notifications@github.com, wrote:

I have installed php7 since it's beta state, various of versions of it in all my development machines in the studio running Debian Jessie, but not my production servers yet because there are some things missing still and I need to find the time to dig into it to find alternatives in some cases such as GeoIP (currently using pecl geoip on php5). Although this one maybe slightly off topic, if anyone knows about php7 and geoip please send me an email.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#15845 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVglqwFM0SrfuXxzHToaZqUtmzZ8ujfks5r4Vp3gaJpZM4NScO2).

@tonypartridge thanks :-) but ..
root@dev-main ~ # pecl install geoip-1.1.1
pecl/geoip is already installed and is the same as the released version 1.1.1

Can we discuss the geoip stuff please on the forums? Please keep the issue on topic.

Sure I'll pm you on Glip George.

On 10 May 2017, 07:46 +0100, Thomas Hunziker notifications@github.com, wrote:

Can we discuss the geoip stuff please on the forums? Please keep the issue on topic.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#15845 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVgliInc_PGhiI6LMoZNP4ZFyN5TFesks5r4V1fgaJpZM4NScO2).

sure @Bakual I am positive.

is there a list of required modules for PHP

Just for reference the requirements page basically lists what you would need on top of a "default" PHP installation (ya I realize that term is going to be relative based on a lot of factors, but for the sake of argument let's just say the result of sudo apt-get install php7.0). So what's on the tech requirements page is the bare minimums needed to get the app installed.

There's also https://docs.joomla.org/Optional_Technical_Requirements linked from there which lists out additional requirements for the various library APIs. These are all optional requirements (but stuff like a working HTTP adapter are highly recommended) and aside from having one functional database driver setting those up only gives you additional options/features to work with.

It makes sense to run a "pre-flight" check before install.

This issue was raised about the warning of outdated PHP versions in the cpanel. It's not a technical requirement, just best practice.
So I'm not sure what a pre-flight check before install would help. There is also not much sense to display a warning before installation because the CMS works absolutely fine on that PHP version.

"pre-flight" runs after the package download and file changes so technically your are in the middle of the update process and you can't rollback at this point.

Can we just close this issue? I don't see anything which needs fixing.

Agree with Thomaz.

I suppose a feature could be added to Joomla! Screen, 'check server settings link' for instance which then advises them of their settings and optimum and require settings.

On 15 May 2017, 07:29 +0100, Thomas Hunziker notifications@github.com, wrote:

Can we just close this issue? I don't see anything which needs fixing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#15845 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABVgls7osQWG0SpHiqOWOg0NcsmRniiHks5r5_C8gaJpZM4NScO2).

"pre-flight" runs after the package download and file changes so technically your are in the middle of the update process and you can't rollback at this point.

@rdeutz this is about new installs not upgrades

There is also a "pre-flight" of sorts in the install app that runs server checks. Most people will never see the result of it because their server passes our checks. Though to be honest, I don't think a "software/server outdated" message really belongs in the install app unless it doesn't pass minimums; in that context we are more focused on making sure you can actually get Joomla set up and running, not so much about whether you're on the latest versions of all the things. We don't even have a notification for an outdated Joomla version in the installer, why should PHP be special?

We don't even have a notification for an outdated Joomla version in the installer, why should PHP be special?

Not special just different in that php's development is not controlled by Joomla. It is up to the servers to update the php and apply security patches for it. The warning in the Joomla admin does not take into account (nor can it) the application of any security patches on the server. So either Joomla should not warn of potential security issues that it has no control over or it should be consistent and warn when it is installed. Both or neither.

There would be no point in warning (during install) of an out of date Joomla because Joomla controls it's own updates.

But users control applying those updates (either through a contract with a hosting provider, individually maintaining a server stack, etc.). So by that argument it is perfectly valid to warn in both locations about installing an outdated Joomla version.

The warnings and notifications in the context of the install application are by design limited. We don't want to bombard the user with a lot of information that might make it look like Joomla is complex to install. This is why the "hard" warnings are limited to absolute requirements and everything else is shown as suggestions basically.

So if we were to make any change to the install app, at most I would suggest that we just add another row to the Recommended Settings block showing whether the user is running a supported PHP version (based solely on PHP project support, not dealing with the Linux distros and their forks).

@mbabker
Very elegant. +1.
I would only tweak the "5.6+" to "5.6 or higher" just in case some don't get it, but that makes the box big.

@mbabker That looks like a great "pre-flight" improvement +1 ?

A big NO on forcing the PHP information in the area you have listed.
You should be displaying what the MINIMUM and RECOMMENDED version are, PERIOD. Stay away from phrases like "do not quite match", we need absolutes, not generalizations.

Additionally for the love of god REMOVE the great wall of red error text when you click on the Control Panel view. First, it's a message (blue) or warning (orange) informing the user of their acceptable but very low version of php, it is not an ERROR. Be brief, absolutely no reason for that amount of text.

That is an improvement but not address two issues

1. The inconsistency of placing a warning after an installation and not during. Much like putting a 'Shallow water no diving' sign at the bottom of a pool ... so people see it after they have dived in.
2. Displaying a warning when the server is using well patched php. If anything it should be information not a warning.

There is no such thing as point 2.

See that is were I think you are confused, that error message is not coming up "After" installing or updating. It is the Control Panel view you are sent to after an upgrade or an install is complete. It is not an error. Joomla is running, nothing came to a halt.

So technically there are no errors after installation or updating. It is just because you are redirected to the Control Panel view.

Yes there is because it has been stated in the thread in the Forum.

I keep the server patched, and want to move to PHP 7, but I have to think of the other websites on the server that are running their own scripts. Most of the Joomla and Wordpress sites on the servers have been kept updated, but there are always some that fall behind. And there are websites with their own PHP scripts that may break if the servers are updated, so as a server admin I have to try to protect those other sites from breaking as I put more pressure on those old sites to upgrade.

Thankfully, we can turn off the warning so I don't scare the paranoid users.
https://forum.joomla.org/viewtopic.php?f=706&t=950116#p3474009

Has the server patched but still receives a warning. It is not logical to give a 'one size fits all' warning when it does not apply to all.

See that is were I think you are confused, that error message is not coming up "After" installing or updating. It is the Control Panel view you are sent to after an upgrade or an install is complete

If it is not present during installation but can be seen after an install has been completed then BY Definition that is AFTER

There is no such thing as a well patched php.

On 15 May 2017 at 17:30, Kevin Griffiths notifications@github.com wrote:

See that is were I think you are confused, that error message is not
coming up "After" installing or updating. It is the Control Panel view
you are sent to after an upgrade or an install is complete

If it is not present during installation but can be seen after an install
has been completed then BY Definition that is AFTER

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#15845 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8U_DTVa0rZKUSOdtJqLyu63ZMWPyks5r6H24gaJpZM4NScO2
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

The checks are based on a default install of PHP. Because variants of it (the "forks" the Linux distros create for their repositories) cannot be adequately checked for support or whether various patches have been implemented. So the warning as written, as has been said numerous times now, is a statement of fact based on the core PHP project support timeframes and us making checks against the present date, the active PHP branch, and where those two values fall into the data array of PHP branches regarding each branches' end of general maintenance date (security only updates after that) and full end of support date.

We cannot adequately implement checks for anything other than the base PHP installation.

Accept my apologizes, I was wrongly thinking that "after the update" was based solely on an install or update. And I was pointing out that at anytime you view the Control Panel, that error is displayed.

I just want to get rid of that big red error box, when it is not even an error. A Brief, very brief statement containing the bare minimum, and what the server is running should be suffice. And make it a Warning, not an Error.

Server admins can run multiple php versions on the same machine and use a different one on each vhost. On the other hand I notice some confusion. First the warning is a warning (yellow/orange) not an error. Then it appears only on php versions below 7. Then it is informative, saying that one day soon php 5.6 will stop being supported all together (it cares about you). Then, this warning can be turned off, it is a plugin which can be disabled in the "quickicon" section of plugins. The only reason I can see someone go mad about this warning is if they don't want their customers to get afraid and get a load of support emails. I believe surely the way it appears, where it appears, etc can be improved, but I don't see anything wrong with it, not as wrong as you present it.

Our core Joomla and extension update windows are also an error when those should be informative only as well. The logic used was to mark it as an error indicating the branch is no longer supported at all and a warning if the branch is nearing end of support (security only, generally within 12 months of the present date). And that was mainly because there is a limitation on what combinations of alert types are available to us, and IMO it is not appropriate for an outdated software notification (regardless of context) to show using a success or informative notification type (our green and blue alerts). So it should remain as either a warning or error context, and precedent has been set by using an error context for updates that can be performed within Joomla itself.

Odd, I am staring at a red error message when I am in my Control Panel view:

We have detected that your server is using PHP xxxxx which is obsolete and no longer receives official security updates by its developers. The Joomla! Project recommends upgrading your site to PHP 5.6 or later which will receive security updates at least until 2018-12-31. Please ask your host to make PHP 5.6 or a later version the default version for your site. If your host is already PHP 5.6 ready please enable PHP 5.6 on your site's root and 'administrator' directories – typically you can do this yourself through a tool in your hosting control panel, but it's best to ask your host if you are unsure.

This is all in red and labeled as ERROR
Secondly, that is way too much to inform someone of their PHP version.

One final thought, then I will leave it to you all. ERROR to me means there was a halt, or a stop, that the program was not able to execute fully or at all.

The checks are based on a default install of PHP. Because variants of it (the "forks" the Linux distros create for their repositories) cannot be adequately checked for support or whether various patches have been implemented. So the warning as written

My point exactly ... Joomla admin gives a Warning about something it can not check fully.

If "your php version 5.6.19 is only receiving security fixes at this time from the php project" is accurate then it should be displayed during update and be informational not a Warning. If it is not accurate and distros are applying security patches as well then it should not be displayed at all.

I just cant believe we are having this discussion yet again - its 2017 - just use the best PHP version released, or move to a decent webhost that provides this. Why should Joomla have to support ancient buggy slow crap. Its time to move on, its time to lead and leave those behind that dont want to follow.

The message we are displaying is accurate regardless of whatever spin you want to put on things to create fear and doubt. We aren't scanning your local PHP binaries to figure out what has been patched and what hasn't. That's impossible. The simple facts are that the PHP core project is only providing security fixes for PHP 5.6 at this time and that the PHP core project is not providing support at all for PHP 5.5 and earlier. That is what our message communicates, nothing more, and nothing less. That is all we can check at our level without mandating a C extension being written and included in your PHP installation to run Joomla.

My point exactly ... Joomla admin gives a Warning about something it can not check fully.

One could argue that forks including backports, without changing version number are actually MORE INSECURE than official builds because you (the average user) dont know EXACTLY what issues are resolved, backported, and fixed and you can make wrong assumptions and rely on those assumptions.

@PhilETaylor I find it's the internal intranets usually setup and managed by small businesses that typically push back for staying on minimum versions. They often care little about security and are overly focused on "it just works". I'm still surprised that the user statistics show about 48% using less than 5.6

The checks are based on a default install of PHP. Because variants of it (the "forks" the Linux distros create for their repositories) cannot be adequately checked for support or whether various patches have been implemented.

Whilst this is true, this issue is also fairly trivial to resolve.

There are a finite number of LTS distros, and in CentOS the PHP version never changes (that's sort of the point). If phpversion returns 5.3.3 it's more likely that the user is on CentOS 6 than that they've left PHP festering for years (and if the latter is true, the error is unlikely to force an upgrade).

So something as simple as
`
$excludes = array(
'5.3.3', // RHEL6/CentOS6
'5.4.16', // RHEL7/CentOS7
);

if (in_array(phpversion(),$excludes)){
doNothing();
}
`
Would do.

For debian, phpversion will include a reference to the Debian version

php -B 'echo phpversion();' 5.6.30-0+deb8u1

That way, you can exclude the LTS installs (which are almost certainly up to date in terms of security patches) and still show the warning/error for at risk installs.

Just by targetting RHEL and Debian derivatives, you'll cover most of the LTS market (so the majority of people impacted this). Maybe include Ubuntu LTS as well, but there isn't much more work to it than that - major releases don't happen often, so there's not much overhead in maintaining that list.

You're not checking patch level for other things anyway (for example, have I patched heartbleed? Or Shellshock?), if you're really concerned with going to that depth, there may be a way anyway, I haven't looked in much depth.

I just cant believe we are having this discussion yet again - its 2017 - just use the best PHP version released, or move to a decent webhost. Why should Joomla have to support ancient buggy slow crap. Its time to move on, its time to lead and leave those behind that dont want to follow

Right, if you're using the version number for an assessment of security, you are eventually going to get burned badly.

Work with me here, let's take a recentish CVE - CVE-2016-10158 (the most recent that actually affected 5.6.x as well as 7.x). It's actually a reasonably harmless issue as they go, but the principle remains the same.

• On a server running PHP 7.0.14, Joomla won't show an alert. But it's vulnerable (fixed in 7.0.15).
• On my Debian 8 server, the PHP version is 5.6.30 - Joomla shows an alert. But actually, I've got unattended upgrades enabled so that patch was installed automatically (and they normally come down before the vulnerability has even been publicly disclosed)

Version numbers exist to asses the available functionality, do not make the mistake of using them for security.

Moving onto your "good" webhosts. Have you checked how they're providing PHP7? Is the server running a LTS distro? If so, they've gone out-of-band to provide you with PHP7. This isn't instantly bad, but there are a number of possibilities

1. They've compiled mod_php with PHP7 (very common with CPanel as it's a few clicks in EasyApache). You won't get an update until it's next recompiled, which may or may not be automated. Bang, you're potentially vulnerable
2. They're using a third-party repo. You at least get automatic updates, but you're reliant on the maintainer of that repo providing (and testing) patches in a timely manner. Whether that matters depends on who the 3rd party is, but they almost certainly don't have the resources the likes of the Debian project do.

Both of which provide a means to be insecure but get a warm false sense of security from the fact that Joomla isn't yelling at you for being out of date.

Conversely, your "bad" host (they only provide 5.4.16) may be completely up to date with the necessary security patches.

Why should Joomla have to support ancient buggy slow crap.

Sorry to requote this sentence, but it's important to point out that Joomla does support it. If you think dropping support for PHP < 5.6 (to pick a number) is the way to go, then that's an entirely different argument to one about security.

One could argue that forks including backports, without changing version number are actually MORE INSECURE than official builds because you (the average user) dont know EXACTLY what issues are resolved, backported, and fixed
apt-get changelog php5 rpm -qp /path/to/package
You can see exactly what has been fixed.
Not to mention, most people who are on LTS are going to have unattended-upgrades and their ilk installed, so they're getting patches - the average user doesn't bother checking the minor version of PHP anyway, so may well be running 7.0.14 (from the example above)

There's a (valid IMO) argument to be made about not holding the project back because you can't use functionality that isn't in 5.3.3 (or have to spend time coding defensively to compensate), but couching that argument in security is not a good approach.

Ultimately, though, there are a number of (very good) reasons people go for LTS distros - especially in large scale deployments - and I don't think it's a good idea to exclude them when a little bit of care could easily solve the issue.

Just disable the freaking plugin if you have an issue with the warning.
Or test the PR which will only show the warning of the EOL is less than 3 months away: #16017

Closing this issue as there is a PR to test and this discussion leads nowhere.