Welcome Guest, Not a member yet? Register   Sign In
Poll: Would you consider upgrading to PHP 8.0?
You do not have permission to vote in this poll.
Yes
88.89%
24 88.89%
No
11.11%
3 11.11%
Total 27 vote(s) 100%
* You voted for this item. [Show Results]

Surprised to see codeigniter 3.x running successfull with PHP 8.0 as well.
#1

(This post was last modified: 11-27-2020, 10:44 PM by rahulswt7.)

Codeigniter 3.x running successfully with PHP 8.0 as well.
Without any changes its working very well.
Great news guys. Smile
Reply
#2

waiting for "Shared hosting" update ........
Reply
#3

(11-27-2020, 10:41 PM)rahulswt7 Wrote: Codeigniter 3.x running successfully with PHP 8.0 as well.
Without any changes its working very well.
Great news guys. Smile

This is good news, and useful to know.
Reply
#4

Thank you for this information, was wondering it myself as well!
Reply
#5

(This post was last modified: 01-14-2021, 05:16 PM by CINewb.)

Today I installed PHP8 and tried it with our CodeIgniter 3 project.

I found 2 issues:

1) We had a controller class called Attribute which it doesn't like.  Perhaps this is a reserved word in PHP8.

2) More serious - flash data doesn't seem to clear.  Once you have a piece of flash data set, for example "Your changes were saved", it continues to persist on every page load thereafter.   I tracked this down to \system\libraries\Session\Session.php Lines 418 to 423:

Code:
// Hacky, but 'old' will (implicitly) always be less than time() ;)
// DO NOT move this above the 'new' check!
elseif ($value < $current_time)
{
    unset($_SESSION[$key], $_SESSION['__ci_vars'][$key]);
}

Looks like in PHP7 "old" was < time(), whereas in PHP 8 it isn't.  I propose changing this to:

Code:
// Hacky, but 'old' will (implicitly) always be less than time() ;)
// DO NOT move this above the 'new' check!
elseif ($value === 'old' || $value < $current_time)
{
    unset($_SESSION[$key], $_SESSION['__ci_vars'][$key]);
}
Reply
#6

Don't kid yourself CodeIgniter 3 and 4 are not compatible with PHP 8.0.1 yet

You just have not hit the errors yet.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#7

Damn, that's a shame. Specific to CI3 - do you think it will be made compatible with PHP 8? I'm not too concerned until November 2022 which is when support for PHP 7.4 is dropped. But after that time I'd like to think our CI projects will still work. I'm going to make a pull request for the above fix, and if there's anything else I can contribute, I will do.
Reply
#8

(01-14-2021, 04:28 PM)CINewb Wrote: Today I installed PHP8 and tried it with our CodeIgniter 3 project.

I found 2 issues:

1) We had a controller class called Attribute which it doesn't like.  Perhaps this is a reserved word in PHP8.

2) More serious - flash data doesn't seem to clear.  Once you have a piece of flash data set, for example "Your changes were saved", it continues to persist on every page load thereafter.   I tracked this down to \system\libraries\Session\Session.php Lines 418 to 423:

Code:
// Hacky, but 'old' will (implicitly) always be less than time() ;)
// DO NOT move this above the 'new' check!
elseif ($value < $current_time)
{
    unset($_SESSION[$key], $_SESSION['__ci_vars'][$key]);
}

Looks like in PHP7 "old" was < time(), whereas in PHP 8 it isn't.  I propose changing this to:

Code:
// Hacky, but 'old' will (implicitly) always be less than time() ;)
// DO NOT move this above the 'new' check!
elseif ($value === 'old' || $value < $current_time)
{
    unset($_SESSION[$key], $_SESSION['__ci_vars'][$key]);
}


Indeed.

I'm guessing the logic was to allow "temporary" variables to store an expiry time when they expire and flash messages to expire straight away and avoiding a dual check. 

PHP8 Changes the behaviour of comparing strings to numbers.

https://wiki.php.net/rfc/string_to_number_comparison


In PHP 7.4 and Below "Old" == <Numeric> would equal True and "Old" < any numeric value would respectively equal true.
This behaviour has now been changed.

So far this has been the only bug I have found. 

Another Gotcha that doesen't affect CI but affects a lot of legacy code I look after is that the charming "STFU Operator" now doesen't STFU.
$variable = @$array['entry']; Now throws an error rather than containing "null" gaaa.
Reply
#9

(This post was last modified: 01-16-2021, 03:12 AM by CINewb.)

unplugged Wrote:Another Gotcha that doesen't affect CI but affects a lot of legacy code I look after is that the charming "STFU Operator" now doesen't STFU.
$variable = @$array['entry']; Now throws an error rather than containing "null" gaaa.

Are there any such STFU operators in the CI framework?  I have nearly always avoided using them in my own code.  I might have some really, really ancient non-CI projects that I'll have to check prior to a PHP 8 upgrade though. Although it looks like it's mainly fatal errors which are not silenced now, which kind of makes sense, as the application would fail at that point anyway.

It also appears there is an issue with Migrations when using PHP 8, although the fix looks simple.
Reply
#10

(This post was last modified: 01-16-2021, 06:10 AM by unplugged.)

(01-16-2021, 03:05 AM)CINewb Wrote:
unplugged Wrote:Another Gotcha that doesen't affect CI but affects a lot of legacy code I look after is that the charming "STFU Operator" now doesen't STFU.
$variable = @$array['entry']; Now throws an error rather than containing "null" gaaa.

Are there any such STFU operators in the CI framework?  I have nearly always avoided using them in my own code.  I might have some really, really ancient non-CI projects that I'll have to check prior to a PHP 8 upgrade though.  Although it looks like it's mainly fatal errors which are not silenced now, which kind of makes sense, as the application would fail at that point anyway.

It also appears there is an issue with Migrations when using PHP 8, although the fix looks simple.

Thankfully no Smile I did have a quick search for "@" however it's nearly all comments as expected and it's use is "discouraged" however it's a staple of PHP if you maintain older code.

In theory it shouldn't be an issue if you're using display_errors=off which should be the case in production although they end up in the logs. I don't know yet what if any impact it will have with CI however it will be in user code I suspect and not the core.

For code I maintain it's largely around file methods that could fail such as unlink() (if it doesen't matter that a a file actually gets deleted) or @unserialize() @json_decode() etc to return null if the data is invalid. I don't know how much of an annoyance this will be to be but I expect lots over the next year or so as I test code for PHP8 Wink
Reply




Theme © iAndrew 2016 - Forum software by © MyBB