Throw warning about unsupported PHP versions.

[jdevalk]

In the interest of moving a larger part of our plugin users to more recent versions of PHP, we're going to throw a notice to users.

The notice should mention the fact that newer PHP versions (5.6 or 7+) are both much faster and more secure.

First draft for the message:

Your site could be faster and more secure with a newer PHP version Hey, we've noticed that you're running an outdated version of PHP. PHP is the programming language that WordPress and Yoast SEO are built on. The version that is currently used for your site is no longer supported. Newer versions of PHP are both faster and more secure. In fact, your version of PHP no longer receives security updates, which is why we're sending you to this notice.

Hosts have the ability to update your PHP version, but sometimes they don't dare to do that because they're afraid they'll break your site.

To which version should I update? You should update your PHP version to either 5.6 or to 7.0 or 7.1. On a normal WordPress site, switching to PHP 5.6 should never cause issues. We would however actually recommend you switch to PHP7. There are some plugins that are not ready for PHP7 though, so do some testing first. We have an article on how to test whether that's an option for you here. PHP7 is much faster than PHP 5.6. It's also the only PHP version still in active development and therefore the better option for your site in the long run.

A message from <hostname> (optional) 3-4 lines of text.

Can't update? Ask your host! If you cannot upgrade your PHP version yourself, you can send an email to your host. We have examples here. If they don't want to upgrade your PHP version, we would suggest you switch hosts. Have a look at one of our recommended WordPress hosting partners, they've all been vetted by our Yoast support team and provide all the features a modern host should provide.

Requirements:

• Create a class that would work for other plugins too, and doesn't rely on our Notification Center.
• Add a filter that allows the host to point people to their support pages on how to increase their PHP version. When this filter is used, the message generated should be preceded by a heading like "A message from your host" as seen above. We should limit what this can be in both length and what it can contain, I think only a elements.
• Add a filter or constants that allows hosts to set their name, to be used in the messaging (also useful for our support team).

[moorscode]

Suggest to talk to Hristo Pandjarov/Daniel Kanchev (SiteGround), Mike Schroder (Dreamhost) and/or Aaron Cambell (GoDaddy) about preferred method of supplying the host-specific content. All of them can be found on WordPress slack.

I would think that an getenv option would be one of the easiest ways for them to implement this. Possibly falling back on a filtered string when the environment is not implemented.

Filtering this with strip_tags would provide what we want to offer.

[jdevalk]

Was already talking to Hristo about this, and have mentioned this topic in #meta on WP Slack too. Have contacted Mike and Aaron too.

[moorscode]

Would rephrase the following sentence: Sometimes hosts have the ability to update your PHP version, but don't dare to do that because they're afraid they'll break your site.

It sounds like they 'sometimes' have the ability to update the PHP version, but they always have this ability.

Hosts have the ability to update your PHP version, but sometimes they don't dare to do that because they're afraid they'll break your site.

[willemientje]

In the message I would add subheadings like:

• To which version should I update?
• Can't update? Ask your host

Perhaps add something here about what kind of risks you run (hacks? Lose customer data? etc) "In fact, your version of PHP no longer receives security updates"

[dd32]

As a FYI; I get 3-4 emails a month saying that one of my plugins (which requires PHP 5.4+) is incorrectly stating their version of PHP (and it's a much much smaller plugin, so I expect you'll hit this, which is why I'm mentioning it). It seems that a lot of people have hosting panels which clearly show PHP 5.6/7.0 in use (or php-cli updated to the latest version) but where WordPress is actually being served using an older version of php - .htaccess rules usually, but also mod_php not being updated alongside php-cli, etc). I often find these are PHP 5.2/5.3 users.

[schlessera]

If creating a reusable class that other plugins can use too, please make sure that the behavior is shared (without causing version conflicts), so that people don't end up getting 10 notices on plugin update.

Would also be great to have this class be packaged as a Composer package to allow it to be easily pulled into other plugins.

As @dd32 has already pointed out, be aware of the differences between CLI and SAPI versions.

The idea to let the hosts hook into this via environment variables is great, make sure you make this flexible enough so that hosts are able to provide the best customer experience they are able to offer.

I think I can safely assume that you're aware of the .org plugin repository guidelines and will try to create this in a compliant way. They might be able to provide additional feedback on how tight the hosting integration can be, as this basically means that when this plugin is installed, the behavior is automatically hijacked in parts by the surrounding environment. This could be considered a security vulnerability.

[jdevalk]

@moorscode noted, updating draft.

@willemientje noted, updating draft.

@dd32 ugh. How do you check PHP version? What's the most reliable way you reckon? We could just feature sniff...

@schlessera remarks on your remarks :)

• Agreed on the "not get 10 notices".
• I fail to see where we'd possibly cross the line for .org stuff? This'll never report back to us, actually, @dd32 has already been giving me stats for our current PHP version distribution as measured by .org. We'll also work closely with the large hosts, most of whom I've already been in contact with.
• For as far as "hijacking": we'll only allow text and links in these filterable elements. Nothing else.

[dd32]

ugh. How do you check PHP version? What's the most reliable way you reckon? We could just feature sniff...

phpversion() is the only (and correct) way of doing it. The scenarios I listed are just things where what the user honestly believes they're running, and what actually is running, differ. In my case I explain that it can differ for those reasons, suggest people install a random php-info plugin to verify it's not my plugin.

I fail to see where we'd possibly cross the line for .org stuff?

I don't personally see how any host integration proposed here would be against any .org plugin guidelines - AFAICT there's no intention of the data being collected in any way by the plugin, just nudging users towards updating their software. And optionally pulling an email address, support document location, or host name from environmental variable isn't against any repo guidelines that I'm aware of (note: I'm not a plugin repo reviewer)

[jdevalk]

These are the current PHP version stats for the people running respectively Yoast SEO 3.9 and 4.0:

PHP Version	3.9 Usage	4.0 Usage
5.2	1.9%	1.9%
5.3	9.5%	7.7%
5.4	23.7%	27.8%
5.5	17.3%	17.0%
5.6	39.3%	36.8%
7.0	8.1%	8.8%
7.1	0.1%	0.2%

[tobeycodes]

If a host hasn't been recognised, could we suggest a template they can send to their hosting company?

[jdevalk]

@schrapel most certainly.

[tobeycodes]

The WordPress hosting partners link should probably go to https://wordpress.org/hosting/ if it's going to be shared across plugins

[jdevalk]

@schrapel I think we'll need to make that changeable. The thing is that we actually have a hosting partnership program in which we work with hosts to make sure Yoast SEO works well and ask for more specific other stuff. That's why linking to our own partnership page (to be heavily updated btw) makes sense.

[schlessera]

Regarding .org guidelines, I did not think about collecting data, but rather about having a popular plugin provide overrideable and uncontrollable links to external content.

Potentially, this could be a link to malicious content, officially endorsed by Yoast from within their dashboard.

[stodorovic]

I agree with @dd32. I had a client (3-4 days ago) which tried to switch to newer version via cpanel (shared hosting). Result of this was internal server error (500) because there are some old rules (custom handlers - PHP 5.2) which were in conflicts with new rules (He didn't change anything on the website in last couple years). Basically, I had to remove code from couple .htaccess files. Then we were able to switch to PHP 5.6.

Example for possible code in .htaccess: AddHandler application/x-httpd-php52 .php

Also, I found Apache/1.3.42 and PHP/5.2.17 before a few weeks. (VPS - custom installation - old debian). It was specific case and there is often impossible to update PHP without reinstalling OS. Maybe it's good to check server version (getenv, $_SERVER or whatever) and add notices for outdated web servers (apache, nginx,...).

Related to version checking, I use php_version() or constant PHP_VERSION. It works. (at all systems where I was able to test it)

PS. It's out of topic, but Yoast SEO should check WP version at activation because there are cases where someone tried to update plugin on older WP versions. (result is often broken website)

[tobeycodes]

@jdevalk how would you choose which link to display if you only show the notice once but due to appear multiple times?

[richardtape]

Whilst I encourage this sort of discussion and education, I'm concerned about 1 main thing. The vast majority of users don't know or care what PHP is, let alone what version their site is running. The logistics of how this could be implemented seem to have been hashed out in the last few hours, which is great.

What happens if a plugin with a reach as large as Yoast's implements this and then many other plugin devs do the same? But in slightly different ways. Mixed messages will happen. Multitudes of admin notices create a noise that completely detract the purpose from any of them.

This is an issue, without doubt, and one that the whole WP ecosystem will benefit from it being solved. But imho it's not a user issue. And these notices and warnings will affect users. It's a hosting issue.

Creating panic for our users (and there will be panic if you start using the word 'security') creates a poor impression from the user point of view - "My WordPress is insecure... WordPress must be insecure" and from our hosts in the trenches - "A handful of plugins have caused thousands of support tickets for no actual reason, perhaps we should consider not recommending those plugins"

I am fully on board with leaning on our hosting providers to upgrade the PHP version of their customers. Which is, I believe, what Matt is doing by only having PHP 7+ hosts on the .org hosting page. But what I don't agree with is using our users as leverage to lean on hosts.

I'm not trying to discourage this idea - I believe something needs to be done on a large scale. What I am doing, is trying to encourage a discussion on the why is this the best approach and not the how it can be implemented.

[tnorthcutt]

@richardtape great points. I somewhat agree on why vs how discussion. I do have one or two thoughts on how in the meantime, though 😉. N.B. all of the following is my highly subjective personal opinion, etc. etc.

Creating panic for our users (and there will be panic if you start using the word 'security') creates a poor impression from the user point of view - "My WordPress is insecure... WordPress must be insecure"

1. Good. If they're using out of date, insecure versions of PHP, then "their WordPress" is insecure. They should panic! For a "real business", that's a hair on fire, fix it right now, drop everything problem.

2. I get what you're saying about WP being inherently insecure, vs. it being in an insecure environment. Perhaps the messaging could be tweaked to say something like "Don't worry, WordPress itself is not insecure. But PHP [$version] is, and you should ask your host to upgrade you to a version of PHP that is secure so your WordPress site won't be harmed."

[Ipstenu]

I've dropped a notice to tech support at DreamHost about this. We don't support PHP 5.4 and lower, though some folks with VPS and cloud servers certainly have that still. The same is likely true of most of the hosts on wp.org/hosting though. We don't want old PHP either!

The devils conundrum being, our users are not 100% WordPress users, so we can't just upgrade and dance away without serious consequences. That said, once we moved away from 5.2, I believe most of our drama here at DH washed away. But that move, oy!

I've long thought that PHP versions are a hosting issue, not a user one, and alerting users to using specific versions is not as successful as hosts. Since your plugin interacts with users, who simply don't know things, and you're one of the biggest/most used plugins out there, you can't just cut over and tell people to suck it up :( IIRC you learned that one when you tried to switch to name spaces?

What I'd do is ...

1. Contact partnered hosts "Hey, wanna keep being buddies? We're gonna go PHP 7, and you need to ensure that all your users have 5.6 or 7 and up if you want to keep our partnership."
2. Write a tool in the plugin to check requirements.
3. Public Blog Post "As of date X, we're dropping support for PHP 5.5 and older. Here's why. Here's how you can check with our handy in-plugin magical checker tool. Here's what you can send your host."
4. On upgrade, put an warning in the Yoast Notice Boxes. "Old PHP!" with the same directions from the blog post as to what to do
5. Bonus: Check for eCommerce plugin (Woo, eCommerce, EDD) and if they're not using newer versions, point out that it's insecure and could harm their business and use an alert instead of warning.
6. ON date X, post that v 5, due whenever, is dropping support like you promised. Yoast will stop working. We told you so.
7. After date X, do the major 5.0 version of Yoast and if it's not PHP 5.6 or 7, disable the plugin with a warning. "Ain't gonna work! Read this blog post."

The big thing is to never give users an alert without a way to fix it.

The other one is 'how much time' and I'm gonna say ... a year.

I am fully aware of what I just said. If you're not planning to announce it tomorrow, I would wait till Jan 1 and give it till Dec 31, 2017 because that is soon enough that a business would start planning now and far enough that their sys ops don't want to flip you their middle finger. The larger the business the slower the move.

[jdevalk]

Note, @Ipstenu, that we do not plan to change our required PHP version to anything other than what core does. Only if and when core starts requiring 5.6+, will we. But we're going to try to move the needle so hard that core will do that.

[Ipstenu]

You're in a devils conundrum. The only way for you to effectively move the needle would be to bite the bullet and do it. At the same time, you're big enough that the negative fallout could be too high of a risk.

I personally don't think the needle will move even if Core says "PHP 5.6+ required!" in (say) WP 4.9 and instead we'll see that number of people on 4.8 and under grow.

[asmartbear]

(Summary from Post Status Slack discussion)

The goal is to get this message to 100% of Yoast customers in a reasonable period of time, i.e. measured in months, not years. The problem with dropping this change is that a large number of Yoast customers will start seeing the message in a short period time (days or weeks), and on the scale of all shared and some managed hosts, that will cause an unmanageable surge in support requests, many of which are not resolvable quickly (i.e. "my site isn't working with v5.6; help") or with satisfaction from the customer (i.e. "what do you mean I have to pay a consultant to make my site v7 compatible?"). Even in the best-case of v5.5 -> v5.6 wherein you might have (on the order of) 90% compatibility, that 10% is a huge number on the scale of 6- or 7-figure quantities of installs, which companies like WP Engine and shared hosts have.

So here's a potential solution with a simple implementation:

The first version of this code could come with a WordPress option that hides the message. This option has no admin-screen access. This would allow a host with good intentions to slow-roll the visibility of the message, including any algorithms they chose around which customers to tell first, how and when to accelerate showing the message, etc., by twiddling the option. The management of all that is up to the host; the plugin only needs to supply this binary option.

You would also declare a date upon which you will be removing support for that option, and the message is always displayed. But that date is something like July 1, 2017. This gives hosts enough time to manage the change, but doesn't give them infinite time.

[asmartbear]

Another idea: For "version one" of this change, display the message for PHP versions <=5.4.x rather than <=v5.5.x.

Reason: It's hard to argue that it's secure or otherwise advisable to have anything running on PHP v5.2, v5.3, and v5.4, so it's rational to say that raising a flag in this case is doing the customer a service.

But PHP v5.5 is reasonably secure for many popular distributions of Linux (including Ubuntu and RedHat) because of their commitment to create security-patches. And PHP v5.5 has a big footprint, so including it right off the bat creates a much larger impact.

Thinking of this as one step of a journey of many steps, you might want to take a smaller first step, so you can gauge the result, the reaction, the customer response, host response, and who knows what else.

Then, armed with that info, you can (and I presume will!) decide when to add in v5.5 or -- in future -- even v5.6).

[nstiac]

Having a FIXED NOTICE which you can't get rid off is AWFUL and correlates to SHOUTING! i champion your cause but the way you're doing it is distateful .. FORCING ANYTHING UPON ANYBODY should not be permitted nor allowed in this century.. this reminds me of Rosa Parks at the back of the bus.. it's #versionprofiling #versionseggregation .. either your plugin requires it or not.. if it doesn't require 5.6 o 7 .. STOP SHOUTING AT US TO UPGRADE !

[jdevalk]

Hey @nstiac,

This is going into WordPress core, and not just for 5.2, so point your energy at updating your PHP.

[amityweb]

And how does one remove this notice? There is no means to close it. We are fully aware of what the message is saying and so want this removed. Its quite intrusive. Its OK if it can be closed, but I find it very bad its a permanent message by you. In some cases, as in ours, moving is not a simple process. Our server is 32 bit centos and its not possible to install a later version of PHP on it, we need a brand new server and the move of the site is quite involved. We have a plan in the works, but it will take time, and so in the meantime need the message gone as we are fully aware of it and do not need it in our face whilst using the admin.

There are other plugins that do not provide the facility to close them, so if you had several permanent messages like this its terrible. ALL admin messages should have the means to close them. There is not even a specific class on the DIV to target in our own custom CSS???

Thanks

[amityweb]

And this statement is ridiculous: "Switching to PHP 5.6 should never cause issues."

I have had plenty of sites that break when updating to later versions of PHP due to old PHP code, which needs to be changed before updating. It really is not a simple task for some large scale sites that use legacy code.

And this statement: "Hosts have the ability to update your PHP version, but sometimes they don't dare to do that because they're afraid they'll break your site."

Whats wrong with the hosts reasoning in this case?? A very sound reason to just not flick the switch.

[jdevalk]

@amityweb: this same notice or something similar is coming to WordPress core soon. You can fight it, or you can start fixing it.

[amityweb]

@jdevalk I am fine with the notice and support the movement. Just give me the option to hide/dismiss it. I have read it now. I was aware of it anyway. We do not need the message permanently on the dashboard once we read it. Its a large message. Remind us in a month with a dismissible small one liner if you want to keep pushing it. At least add class to the message so the techs who are fully aware of this can hide it ourselves.

[migash]

Please provide an easy way to hide this message. Currently I have no real choice but to comment a line of wordpress-seo (yoast) core code. Awesome! Thanks Yoast! ... ~/wordpress-seo/admin/class-admin.php ... line 99

[joeblackburn]

+1 on hiding the notice. I understand the idea behind it but the reality is that not every site will be updated.

There are literally hundreds of websites that I've used Yoast SEO on that will be showing this notice. Some will get updated, some will not. Not being able to hide the notice is an extremely poor user experience. This will lead to me having to answer a ton of emails explaining what is happening to many owners of sites. Time I don't have, and am not getting compensated for. I've left a 1-star review on wordpress.org and encourage others to do the same until it's updated.

I'll be looking for a replacement SEO plugin if this isn't corrected in the next update.

[jdevalk]

@joeblackburn this same type of error will show up in core soon. Are you going to leave 1 star reviews for core as well? You're fighting a losing battle. If not all sites will get updated, they soon won't be able to update WordPress anymore...

[joeblackburn]

@jdevalk I'm guessing that the WP team will have the foresight to make the notice dismissable. Again, I don't mind the notice, I mind that you have the hubris to make it non-dismissable with no way to even target with CSS becuase of the use of the generic "error" CSS class used.

[nstiac]

@jdevalk oh you poor little man who can't imagine what will happen to the world when we can't update his plugin or email or wordpress .. the entire world may collapse because of this ... you are right.. we should hurry and do what we all have consciously decided not to do in order to receive the life saving update from yoast that will allow us to do what exactly? Possibly have a different color label? Lol ..

You are the one fighting a loosing battle against people like us .. we're programmers .. we laugh at anyone who tells us "this or that" can't be done on a computer.. Ah! I just figured it out.. You must be a Mac user who believes that if the computer tells you you can't then you can't ... we'll re-compile php and the entire server if we must .. so stop with your religion like harassment of what we should and shouldn't upgrade or not.. piss off

[jdevalk]

We are part of that WP core team. I was at the WP community summit discussing all this.

First of all, let me agree that I'd rather not have to put this notice there. I don't like it either. But the cause for that notice is that not enough people are upgrading PHP and that the core team first wants more people on higher PHP versions before we can bump the minimum requirement for WordPress. So we were in a catch 22.

We've seen that this notice has had great impact and we now have less than half of the PHP 5.2 users WP core has. As annoying as it is, it's working. Which is why I wouldn't bet on the core team doing anything different than what we do.

Also, we're actively discussing upping the minimum requirement to 5.4. You can turn this into a personal attack all you want, none of that changes the trajectory where this is going.

[rklrkl]

I will point out here that LTS Linux distros backport security and bug fixes from later PHP releases but don't change the package version number. For example, CentOS 6 shipped with PHP 5.3.3 seven years ago and it's still called that version (CentOS 6 still has over 3 years of support left too). However, CentOS 6's PHP 5.3.3 has had 49 build releases to date, most of which will have been the backports I mentioned.

Hence, the (ludicrously undismissable) notice that the wordpress-seo now puts up on CentOS 6 systems running the shipped (and maintained) PHP 5.3.3 with WordPress now contains an outright falsehood:

"In fact, your version of PHP no longer receives security updates, which is why we're sending you to this notice."

I will also point out the obvious fact that core WordPress is still supportinig PHP 5.2.4+ (although obviously recommending PHP 7), so the fact that Yoast SEO doesn't support the same 5.2.4+ requirements is a fault of Yoast SEO, not the hoster that could be running a backported PHP release. As you may have worked out, just checking the PHP version isn't good enough - you should allow for backported LTS distro versions too.

[jdevalk]

@rklrkl: well, "you should allow for backported LTS distro versions too" is not true: they don't backport the functionality of PHP as far as I know, and since we plan on dropping support for 5.2 (and possibly even 5.3), both in WordPress core and in Yoast SEO.

[stodorovic]

I've installed a few servers based on CentOS 6.7. There are very good custom repositories which maintain latest PHP versions.

I'm using IUS which is direct replacement for php binaries into CentOS. It's very easy to install it. Also there are Redhat SCL (official redhat repository) and Remi.

So, it isn't too complex to install at least PHP 5.6 into CentOS. Many old plugins/custom code work without a lot of modifications on PHP 5.5/5.6. I was even updating some old code for PHP 7.0. It requires a lot of testing but there are many benefits. (It works 2-3 times faster than PHP 5.3)

[rklrkl]

@jdevalk I'm a bit surprised you're planning to eliminate PHP support for an LTS distro that still has more than 3 years of support left and is likely still to be used by some hosters.

@stodorovic Upgrading PHP even between minor releases can cause issues. I tried to use IUS to move to PHP 5.6.X on CentOS 6 on our dev setup and it broke several sites that were working fine with PHP 5.3.3. So I'm not "afraid" to upgrade PHP (in fact, I've managed to update PHP using IUS on CentOS 7 to 5.6.X OK because that was less of a version jump) like the Dashboard notice claims, but I have legitimate reasons for staying on 5.3.3 (breakage confirmed to be the main one).

Also note that we operate shared environments on our dev, UAT and live machines, each containing dozens of PHP-based sites. Upgrading via IUS in this scenario is a "big bang" and would require a fair amount of work across multiple sites on each environment to get 5.6.X to work. It may indeed be something we have to do eventually if WordPress core really does stop working with 5.3.3, but until then, we'd prefer to stay on the (supported for 3+ years and still working) 5.3.3 release.

[jdevalk]

@rklrkl your petrol car will also still receive support for decades more. Yet Volvo will only make electric cars as of 2019. Progress should never be halted by the slowest of the pack.

[rklrkl]

In fact, Volvo are producing both electric and hybrid cars from 2019 onwards and CentOS 6's PHP 5.3.3 is indeed a "hybrid". So thanks for the car analogy - it just proved my point further :-)

[amityweb]

Hi all, just want to clear something up about the PHP versions on Centos 6 due to some people saying its straightforward...

Centos 6 on a 64 bit distro can have additional PHP versions added using the SCL repo. Its very easy to do on my servers. I use Webmin/Virtualmin which add them as additional PHP versions. I use this guide https://www.virtualmin.com/documentation/web/multiplephp. But I do not know if that is specific to Virtualmin or if any non-Virtualmin server would do the same, so can't comment on how easy it is on a non-Virtualmin server, maybe its the same as its a yum install using a Centos repo, I guess all Virtualmin does is make it easy to switch versions sites use in the admin panel.

But the main issue for me is... you cannot add (or easily add if it is possible) > PHP 5.3 versions of PHP on Centos 6 on 32 bit distros. This is our situation, we have a few older servers on 32 bit and they just cannot be easily upgraded. The Centos SCL only works on 64bit. So we need a new server and migrate everything on it, and this will take time, not an easy task that the Yoast message implies it is.

@jdevalk But the situation here is not about the message itself, its a good message and important. Its about being able to dismiss it. So lets not get sidetracked about whether its possible or not to upgrade etc. but focus on offering a dismissible message. I have seen plenty of plugins that even pop up reminders every so often if you are concerned about it being forgotten. If you did those, those reminders need to be one liner summaries. Offering an option to never show it would be welcome by the many people who've made a conscious decision to not upgrade PHP just yet. What you should definitely not be doing is imposing such big permanent notices onto people. You have developed a very popular plugin, but it does not give you a right to impose such things on us. Notices are fine of course, but this is very intrusive and imposing and that is just wrong for a plugin developer to do it and not give the website developers a say in this.

[stodorovic]

Hi @amityweb

IUS repository provides 32-bit versions. You can look into packages https://ius.io/Packages/. You can install it trough yum and it's very easy. Binary packages use same path as default CentOS packages. (eg. /usr/bin/php /usr/bin/php-cgi). Remi repository also has i686 builds.

Both repositories offer SPRMs and you can easily make your binary (I've already done it - if you want to control entire process). Also, redhat offers SRPMS if you want to build it ( http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/ ). So, it isn't too complex to make/use 32-bit PHP version.

Personally, I recommend IUS because I didn't have any trouble. I've easy installed it with yum, but if you need multiple PHP versions, better choice is RHSCL.

About installation ( https://ius.io/GettingStarted/#manual-install ):

• remove default PHP packages.
• install epel-release if you didn't yet install.
• install ius-release
• install php with yum. (eg. yum install php56u php56u-cli php56u-common php56u-opcache)

I hope that helps.

[amityweb]

Hi @stodorovic

Thanks for that, but about this "remove default PHP packages". So if your process to replace the current package, and not add additional ones? Because that would bring the server and all sites on it down, and the intention is not to have such disruption. And any older sites that wont work on PHP 5.4+ would break. Hence needing additional PHP versions to use different ones for different sites. We have a stable setup and I am reluctant to start messing with live PHP on a live server in case of adding the new one causes issues. Virtualmin do not recommend third party repos (although I have been using epel and remi over the years with no issues). If I am to do that I prefer to start with a new server and move sites over which is what we intend to do.

but anyway, I would love another thread about upgrading PHP as this one is now all about the damn permanent massive annoying message :)