Scott Allen Posted January 14 Share Posted January 14 I'm getting the error on the 'login' part of the upgrade process  Quote We were unable to start a PHP session. You will need to contact your host to adjust your PHP configuration before you can continue. The error reported was: Return type of IPS\_DateTime::format($format, $memberOrLanguage = null) should either be compatible with DateTime::format(string $format): string, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice  I'm not sure this is a 'host' issue as much as it is an issue with the code... I can fix the issue if someone will tell me what the error actually means. Link to comment Share on other sites More sharing options...
teraßyte Posted January 14 Share Posted January 14 Sounds like not all new files were correctly uploaded on the server. Re-download a fresh copy of the ZIP from your Client Area and re-upload all files. Be sure to double-check all all files are being correctly overwritten. Some FTP apps skip uploading certain files stealthily. Also, which PHP version are you using for the upgrade? Link to comment Share on other sites More sharing options...
Scott Allen Posted January 14 Author Share Posted January 14 Hi, I'll give it a shot. PHP 8.1 Going from 4.7.6 -> lastest Link to comment Share on other sites More sharing options...
teraßyte Posted January 14 Share Posted January 14 Ok, if you're on 4.7.6 and PHP 8.1, and are upgrading to 4.7.14, we can exclude the PHP version. Reuploading all the files is your best option as a first step. Link to comment Share on other sites More sharing options...
Miss_B Posted January 14 Share Posted January 14 2 hours ago, Scott Allen said: Return type of IPS\_DateTime::format($format, $memberOrLanguage = null) should either be compatible with DateTime::format(string $format): string, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice This error indicates a php version incompatibility. It can come from one of third party apps. #[\ReturnTypeWillChange] is a new attribute introduced in PHP 8.1, which signals that a mismatching tentative return type should not emit a deprecation notice. PHP versions prior to 8.0 parses the attribute syntax as a code comment, and does not cause any syntax errors. Adding #[\ReturnTypeWillChange] attribute to a class method does not cause any issues, but omits the deprecation notice in PHP 8.1. If the overwrite of the files will not fix the error, can you try to disable all third party stuff that you might have instaleld and give the upgrader another go? Link to comment Share on other sites More sharing options...
Adlago Posted January 14 Share Posted January 14 1 hour ago, Scott Allen said: Hi, I'll give it a shot. PHP 8.1 Going from 4.7.6 -> lastest Are you sure that your installation has PHP 8.1. Have you checked in your PHP manager on your server host? Why do I think that you have a lower version of the PHP? Link to comment Share on other sites More sharing options...
Scott Allen Posted January 14 Author Share Posted January 14 Yes, its PHP 8.1 PHP Version 8.1.27  30 minutes ago, Miss_B said: This error indicates a php version incompatibility. It can come from one of third party apps. #[\ReturnTypeWillChange] is a new attribute introduced in PHP 8.1, which signals that a mismatching tentative return type should not emit a deprecation notice. PHP versions prior to 8.0 parses the attribute syntax as a code comment, and does not cause any syntax errors. Adding #[\ReturnTypeWillChange] attribute to a class method does not cause any issues, but omits the deprecation notice in PHP 8.1. If the overwrite of the files will not fix the error, can you try to disable all third party stuff that you might have instaleld and give the upgrader another go? Unfortunately, reuploading the files did not work. I dont really have third party plugins installed, I have disabled the chatbox I had and I *think* I've restored the default theme. Still seeing the same issue.  Link to comment Share on other sites More sharing options...
teraßyte Posted January 14 Share Posted January 14 How did you reupload the files? Maybe trying a different FTP app (or even cPanel file manager or similar) might have different results. Miss_B 1 Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 I downloaded, unzipped them and used filezilla to upload the contents over sftp, setting the default action to overwrite. I tried again with no result. Link to comment Share on other sites More sharing options...
teraßyte Posted January 15 Share Posted January 15 The user in this topic had the same issue:  It seems their solution was to convert the database tables to InnoDB (?), but it's not clear if it's the solution for the error, or if they did that after managing to fix it by doing something else first. Are you using MyISAM tables by any chance? Link to comment Share on other sites More sharing options...
Marc Stridgen Posted January 15 Share Posted January 15 From that ticket, it sounds like there was an issue with the database tables too. Check you dont have tables that are crashed too. Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 I'm not sure that it makes sense that MyISAM would be causing an issue where a PHP session cannot be created.. Also, this issue happened immediately after uploading the Invision Community files - it hasnt reached the DB part yet. If there was an issue with one of the plugins, I would have seen it when I upgraded to PHP8.1. Â Nevertheless, I have converted the remaining tables from MyISAM over to InnoDB and I'm still seeing the same issue. Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 Did you recently upgrade PHP as a part of this process prior to running into the error? It could be that PHP sessions are indeed not configured properly for that part of the error. You would want to check the directory which they are stored and ensure that it exists and is writable. If that all checks out, I would confirm what Marc stated about crashed tables. Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 (edited) Hi Jim, No, not for this upgrade. When I did the previous upgrade I think I was running php7.4 which was no longer supported, so it failed the system check part of the upgrade. I upgraded to php8.1 and did the upgrade without an issue. The community has been running fine on php8.1. Its only this recent upgrade which has caused the issue. Edited January 15 by Scott Allen Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 I checked the status of the db and ran a mysqlcheck, but the tables are all coming back as "OK". Again, it doesnt necessarily make sense to me that this is a database issue? Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 Going to the upgrader now, I am seeing the below: The error reported was: session_start(): Failed to read session data: files (path: /var/opt/remi/php81/lib/php/session) You will want to check your PHP session configuration as it cannot read/write to the location there. You will want to ensure it exists. Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 Well, thats embarrassing. Its owned by apache and not nginx. I just read that upgrading php sometimes resets that folder back to root:apache. Where did you see that error, though? I hunted all over for a php error message and I couldn't find anything? Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 12 minutes ago, Scott Allen said: Where did you see that error, though? I hunted all over for a php error message and I couldn't find anything? /admin/upgrade . Showed it right there on the UI. Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 It wasnt visable for me. I even enabled set 'display_errors' = on and still saw nothing. I only saw an error when I restarted the DB. Maybe I should have used another browser. Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 It would have been in the red box on the page mentioned 🙂 . Could have just been at the right time. Unsure if you didn't see it honestly as it would have been displayed to anyone there. Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 Are you using the URL which you have on file here? If so, I get "No applications to upgrade" Link to comment Share on other sites More sharing options...
Scott Allen Posted January 15 Author Share Posted January 15 Sorry, yes. I was just showing you the screenshot from before to show that I didnt see any PHP error. The forums are working fine. Link to comment Share on other sites More sharing options...
Jim M Posted January 15 Share Posted January 15 Glad to hear everything is working now 🙂 Scott Allen 1 Link to comment Share on other sites More sharing options...
Recommended Posts