Internal Server Errors when attempting to upgrade from 2.0.13 to version 2.0.14

[top dawg]

Background
I stopped updating my SMF board years ago because I encountered an internal server error when updating SMF 2.0.13 to 2.0.14 using the package manager. At the time, I suspected the reason for the error was an incompatible PHP version of 5.3.29

Today's Problem
My web host (Powweb) is forcing a PHP upgrade to 7.4 within the next 10 days

I am still running SMF 2.0.13 on PHP 5.3.29 and MySQL 5.6.32. I once again attempted to upgrade to version 2.0.14 using the package manager. The package manager stated the update installed successfully, but any action after results in an internal server error.

I contacted Powweb tech support, after a lot of back and forth, they agreed to let me select a PHP version of 5.6.30 thinking this would resolve my issue, however this did not work as I still get internal server errors on any SMF action.

At this point I decided to go with PLAN B and downloaded the large upgrade file to version 2.0.19. I successfully uploaded all files and attempted to run upgrade.php and once again received an internal server error. I reverted my PHP version from 5.6.30 back to 5.3.2 and much to my surprise my SMF board started working. However, when I attempted to run upgrade.php it states my SQL does not meet the minimum requirements, MySQL is 5.6.32, from the documentation this should be adequate?

Summary
My SMF board states it is 2.0.19 however I did not successfully run the upgrade.php file
My SMF board only works on PHP 5.3.29, selecting 5.6.32 or 7.4.10 results in internal server errors. These are the only versions I can choose from in my hosting control panel.
Attempting to run upgrade.php on PHP 5.3.29 states mySQL does not meet minimum requirements. MySQL is 5.6.32

Any ideas on what could be happening?

[Aleksi "Lex" Kilpinen]

When you receive an internal server error, it is exactly what it says - an error internal to the server, and so you should look at the server error log for details on what actually failed, instead of making assumptions.

But, I think your possible PHP compatibility issues could be caused by some of the mods - Which, incidentally, should have all been uninstalled by you uploading the large upgrade, so did you really truly upload all of the contents from the upgrade package, overwriting all old files?

SMF requirements
Upgrading

[top dawg]

I will admit I am a little rusty on SMF, however I am confident I have successfully uploaded all of the large update files. I do believe the mods have been removed as the obvious custom copyright and top menu mods are no longer being displayed. If the mods are installed, should they not have uninstall showing in the package manager?

I was finally able to locate my error logs, this seems to be a reoccurring error when forcing a 500 error:

20240928T145511: hxxp:centrecountyfire.com/index.php [nonactive]
PHP Fatal error:  Directive 'register_long_arrays' is no longer available in PHP in Unknown on line 0

20240928T145745: hxxp:www.centrecountyfire.com/brotherhood/SSI.php [nonactive]
PHP Fatal error:  Directive 'register_long_arrays' is no longer available in PHP in Unknown on line 0

20240928T150354: hxxp:www.centrecountyfire.com/brotherhood/index.php [nonactive]
PHP Fatal error:  Directive 'register_long_arrays' is no longer available in PHP in Unknown on line 0

I am still at a loss as to why upgrade.php states my MySQL does not meet the minimum requirements

[Aleksi "Lex" Kilpinen]

Then, are you running the default theme? Custom themes might retain edits from mods, edits that still might be incompatible.
I have to admit, off the top of my head I don't know what that 'register_long_arrays' is about .

[Sir Osis of Liver]

Two things:

- It is not necessary to run upgrade.php to go from 2.0.13 to 2.0.19.  There were no database changes in 2.0 branch.

- You need to move to a better host.

Directive 'register_long_arrays' is no longer available in PHP in Unknown on line 0

Looks like that's a php directive that was deprecated in 5.3.  See if it's in your php.ini file, or run phpinfo.

[Sir Osis of Liver]

Confirmed, it's a valid directive in php 5.3, gone in 5.4.  You need to remove it from php.ini.  (Your host should know that.)

[top dawg]

Success!

I was able to disable the "register_long_arrays" in PHP.INI and was able to run SMF on PHP 5.6

I next tried the leap to PHP 7.4 but started getting similar fatal errors with "asp_tags", I also disabled this parameter in PHP.INI and now I have a working SMF 2.0.19 board running on PHP 7.4

Mission accomplished, THANK YOU everyone for the help in getting this problem resolved!

[Kindred]

Honestly,  you should be running at least php 8 at this point...