[Sticky] PHP version requirement to climb to 7.0 and rising
tl;dr: eFiction will require PHP >= 7.0
Well, considering a lot of web hosts still nicely sit on 'ye good ole' PHP 5.x, I was trying to keep requirements as low as possible, even implementing a workaround for a function that was only included in 5.4 or 5.5 ... but that was years ago, and this was somewhat a middle ground between moving onwards and being usable by must users.
Well, more of the latter, but not going to dwell in the past.
And honestly, that was said and done and with more or less time and therefore speed I went on with the project, which has now reached about 90%+ of functionality, a few basics and some extras, and then the bugs of course.
Now yesterday I stumbled over a series of articles regarding the end of life for PHP 5.6, the last of the PHP 5 family, and this has got me to reconsider an old decision. PHP 5.6 will not receive any security fixes com new years eve ... and we are talking about this one. So starting 2019, any old 5.x-run machine will be open season for your un-friendly neighbourhood hacker, and with hacks being traded on the net like comics back in school, expect that to be quite some.
You can read one of the articles here.
Now as once said, you are either part of the problem, part of the solution or just part of the landscape - and eFiction will try to be part of a solution here.
That having said, the PHP requirement will now be PHP version 7.0 for the first release, eFiction 5.0, and will then adopt later versions of PHP as reuirement as they become the last one to receive updates for a decent amount of time.
If your hosting company is not willing to update to at least PHP 7.0, which only receives updates until end of 2019, that should tell you something about them and make you move to a safer haven, as they are willing to let your website get exposed to any form of abuse. The logs was once sent by some helpful members of this community indicate that PHP7 is indeed already well spread, and considering what is said above, now is the time to make the final push and close the book on PHP 5.
For those of us on efic 3.5 still, is there anything tricky about going from PHP 5.6 to PHP 7? I'm poking around our web host and they make it seem like it's as easy as selecting 7 from the drop down and clicking "save changes" but is there anything that needs to be done on the efic side?
I am hosting two archives based on eFiction 3.5.5 on a PHP 7.0 server and they run just fine.
There may be an issue with character encoding, but it's easily fixed:
While not being of utmost urgency, letting you know that eFiction 3.5.x runs pretty smooth on PHP7 (currently testing on 7.0.2) :cool2:
The only thing I found was concerning character sets, but this can be easily fixed modifying header.php:
Search for this:Header('Cache-Control: private, no-cache, must-revalidate, max_age=0, post-check=0, pre-check=0');
header ("Pragma: no-cache");
header ("Expires: 0");
Somewhere there, insert this line:header("Content-Type: text/html; charset="._CHARSET);
In case you have an older version, say 3.5.0 or whatnot, there could be remainders of an old "egrep" function that no longer work, but they have been switched to their updated counterpart quite some time ago in the source files.
Our webhost offers PHP 7.1, 7.2. and 7.3 and under each version it offers CGI or FastCGI, and I'm wondering what the basic difference is and if one is much more highly recommended than the other (our server suggests 7.2 FastCGI). From what I'm understanding, FastCGI allows for browsing to be faster on the site visitor's end but since it's always working it takes up more memory. Since we're mostly dealing with text-based sites here does it make a huge difference in site speeds?
I know this post is quite old, but seeing as we're still working with versions of PHP7, I'm curious about whether the character encoding issue has somehow gotten reintroduced with a minor update. I'm having problems with an e-acute (é) character displaying as a ? character (question mark), even when I use HTML to write it, but I've so far only noticed it on the index page in the Welcome block.
The encoding is style ISO-8859-1 for both pages, and I can't find anything specific about encoding in skin stylesheets or templates. Could it be a tinyMCE issue? Something else?
Latest Patch(es): Yes