Re: Http 500 code, moved server, can't install! Help!

[joebrian43]

Hi all,

MY existing forum is 2.0.17. In the last few days since my host helpfully upgraded PHP to v8, I'm now getting 500 error codes. I can't fixed a shared server so I decided to move it over to my small VPS.

I moved the forum files and the database, changed the login details in settings.php and it crashed the apache service repeatedly. I disabled eaccelerator and that made no difference, the error message changed but it still crashed.

So i downloaded a clean version of 2.0.17 and decided to install that.

Requirements page says:
2.0-2.0.6    4.1-5.4
2.0.7-2.0.13    4.1-5.6
2.0.14-2.0.15    5.4-7.1
2.0.16-2.0.17    5.3-7.3  <==
2.0.18-2.0.18    5.3-7.4
2.0.19-2.0.19    5.3-8.0

Interestingly an earlier version up to 2.0.15 requires a later version of php but a later version is good with an earlier version of php?

Anyway, my version of PHP is 5.3.6

Requirements page says: MySQL 4.0.18 or higher (at least 4.1.0 would be better) and PHP MySQL client API 4.0.18 or higher.

I have mysqlnd 5.0.8-dev

When I run install.php and I get this:

Critical Error!
The version of your database server is very old, and does not meet SMF's minimum requirements.

Urgh... yes it does?

So what gives? How do I get my forum back online given that my apache, php and mysql exceed the stated minimum requirements?

Thanks

D

I'm also encountering a similar issue with my existing forum running version 2.0.17. Since my hosting provider upgraded PHP to version 8, I've been consistently receiving 500 error codes. Unfortunately, I can't fix this on a shared server, so I attempted to move the forum over to my small VPS.

After transferring the forum files and the database, updating the login details in settings.php caused Apache to crash repeatedly. Even after disabling eaccelerator, the issue persisted, albeit with a different error message.

Considering a clean install, I checked the requirements page, which indicates that version 2.0.17 is compatible with PHP versions ranging from 5.3 to 7.3. My PHP version is 5.3.6, well within the specified range.

However, during the installation process via install.php, I encountered a critical error stating that my database server version is very old and does not meet SMF's minimum requirements, despite exceeding them.

I'm puzzled by this discrepancy. How can I proceed to bring my forum back online, especially since my Apache, PHP, and MySQL versions exceed the stated minimum requirements? Please help Any insights or assistance would be greatly appreciated. Thank you!

[Arantor]

What version of MySQL do you have? NOTE: the version of "mysqlnd" is *not* the version of MySQL, that's the version of the *connector* to MySQL, not the version of MySQL itself.

[Kindred]

Instead of using an outdated php, why don't you upgrade smf to 2.0.19 which supports php8 (or 2.1.4 which supports 8.1 and higher)

Seriously? You'd rather run versions of php and smf with known issues than upgrade properly?

Also, please start your own topic rather that jumping into someone else's when it might not be the same issue

[Sono]

I am at 2.0.19, I am running my forum on PHP 7.4 but when I switch to 8.0 I get http 500 error as well. So you see it may not mean anything that the SMF version supports that particular PHP version. Why? Another example:

I have been running the forum on PHP 2.0.9 up until this February. I had been hosting this at Namecheap for years. Then I had to move my forum to Fastcomet. I set the same PHP version there like at Namecheap, that was 5.4, I had been running my forum on that for years, yet the forum did not want to load at the new server, got HTTP 500 error. In the end it turned out no matter that I had the same PHP version set at both places, the default PHP extensions set were different at Namecheap and Fastcomet. By luck the extensions at Namecheap had been favourable for the forum, so I had not noticed those matter at all for years. On the other hand at Fastcomet, the default Extension set was different. After I noticed it I logged back to my Namecheap account, checked the extensions, set the same at Fastcomet, and Voila: the PHP 500 error was gone, forum worked. And as I remember the only problematic extension was an sql type extension, so maybe you have the same problem.

I suggest you to do the same. If you can still log into your old hosting where the forum worked, note down what extensions are ticked at the PHP settings, and then go to your new hosting and tick the same, and untick everything else.  If you can't log in to your old hosting any more, take a screenshot of your extension list, and let me check it, maybe you just need to modify the sql extension settings to be the same like mine and it will work.

[meylodie]

Instead of using an outdated php, why don't you upgrade smf to 2.0.19 which supports php8

I have SMF 2.0.19 on a PAAS "Platform As A Service" install (same as VPS but it is managed), and I had upgraded php 7.4 to php 8 then the forum was broken, the index was not accessible, nor the administration backend.

I had to have php reverted to 7.4 : conclusion, 2.0.19 does not support php 8.

Just saying.

[Arantor]

2.0.19 *does*. More likely you have mods that don't. Especially if you have any mods that add bbcode that haven't been updated for PHP 8 because they *will* break.

[Steve]

I had to have php reverted to 7.4 : conclusion, 2.0.19 does not support php 8.

Just saying.

And the official team members are telling you it does. It is as Arantor said.

[Sono]

I had to have php reverted to 7.4 : conclusion, 2.0.19 does not support php 8.

Just saying.

And the official team members are telling you it does. It is as Arantor said.

The recommended PHP extension set should be listed though. If I don't have a slight memory of needing to tick something from years before, I would have never concluded that causes the issue in my case. It is nowhere mentioned.

[Arantor]

I'd love to know which hosting company disables the MySQL extensions by default so I can avoid them.

So much software uses the standard MySQL library that disabling it is hopelessly naive and pushes it to "it's the software's fault" when it really isn't.

[Sono]

At Fastcomet the forum did not work with the default PHP extension settings. The required database related extension was unticked, I just don't remember which, because I have the screenshots, but I forgot to save whether it was the wrong or right setting. As I remember mysqli was selected and the simple mysql wasn't, but not sure.

[Arantor]

SMF moved to MySQLi several years ago based on the fact that PHP *itself* has abandoned it (several years ago, starting with PHP 7)

This was fixed in, what, 2.0.13?

[Sono]

SMF moved to MySQLi several years ago based on the fact that PHP *itself* has abandoned it (several years ago, starting with PHP 7)

This was fixed in, what, 2.0.13?

I can see in my saved settings that for 5.4 I had mysql and mysqlnd ticked, mysqli unticked. Very likely it was the opposite by default, mysqli ticked and mysql not, probably that's why it did not work by default. I have some very hazy memory about that I got some error message as well regarding some database incompatibility, so I guess the user might have this problem, if nothing else changed while moving the forum. But I also remember as if another extension should have been added as well, because something was not working and you suggested to tick that. But that was very long ago. That's why it would be worth for the user to post the settings on his account so see if there is something essential missing.

[Arantor]

SMF prior to 2.0.13(?) needed mysql not mysqli, and mysqlnd is needed either way since it's the underlying connector that they both use to talk to MySQL.

As ever, when there are errors it is always helpful to see what's in the log and therefore the actual error rather than random speculation, or as earlier, outright misinformation.

[Sono]

As ever, when there are errors it is always helpful to see what's in the log and therefore the actual error rather than random speculation, or as earlier, outright misinformation.

True, but it won't hurt checking that setting, considering my case was similar.

[Arantor]

Why do that when you can get the error log and get the actual error *first*?

I'm not being funny but what works for you almost certainly isn't really the problem here. This is why speculating and trying random things isn't actually helpful to anyone.