Forum offline after (I think) php version change

[Cretster]

Hi folks, looking for a few pointers if possible after spending a while trying to debug this.

My forum was(is) on 4.5.4.2 and then one day recently it went offline suddenly, and I think it was 500 errors I was initially getting from it, and largely since.
If I understand correctly in this version, PHP 7.3 was recommended, and 7.4 was supported at least.  Part of the issue currently is I do not know what version of PHP the host was previously running before a change was made, but I'm going to assume for now it was 5.6.40.  Additionally I don't know what PHP versions were supported with 4.5.4.2 IPB, but am assuming 5.6.40 still was.

The host now only provides PHP 7.2 and 8.1, and I'm assuming it's this change that has broken things, granted completely my fault for not getting everything on the latest patches etc.
I do have other separate hosting and have tried migrating to that to test, since they have additional PHP versions available there, so I have tried different versions, including 5.6.40

Currently though the main issue I am getting either when attempting to just open the forum as is, or to launch the upgrader for 4.7.6 via mycretsterforum.com/forums/admin/upgrade/index.php (or just access the ACP), is I get the following errors logged (after adding an entry for exceptions to write to a log file):

[17-Feb-2023 00:48:14 UTC] PHP Parse error:  syntax error, unexpected ':', expecting ';' or '{' in /home/u436086021/domains/mycretsterforum.com/public_html/forums/init.php on line 962

Line 962 is this line as below:
public static function isThirdParty( string $path ); bool

	/**
	 * Determine if a file is a part of a third party application or plugin
	 *
	 * @param	string	$path	The file path.
	 * @return	bool
	 */
	public static function isThirdParty( string $path ); bool
	{
		$bits = explode( '/', $path );
		
		/* Plugins are always third party */
		if ( $bits[0] === 'plugins' )
		{
			return TRUE;
		}
		
		if ( $bits[0] === 'applications' AND isset( $bits[1] ) AND \in_array( $bits[1], static::$ipsApps ) )
		{
			return FALSE;
		}
		
		return TRUE;
	}

I have tried amending this to use a : instead of ; as I've seen other comments online that a semicolon here causes an issue for the following braced content, and I've also tried combinations of using 7.3 php and with/without this change, but regardless of what I try it seems to just error with the same line in this init file.  So I assume what I am trying here is simply not correct.  Yet in some online PHP checkers it states there's nothing wrong with this code for instance.

I did wonder if there was a way to effectively upgrade the PHP file content offline somehow, but I think even if there is it'll cause me lots of headaches, so I really would just like to find out why it's not working on php 5.6.4 or 7.3 with the alternative host, so that I can get it back running, then carry out the upgrade to the current IPB version, then finally move it back to original hosting again potentially. 

I have also tried having recovery mode enabled and disabled since it seems to relate to that and the impact of third party content etc, still gives me the same error though either way, so I'm a bit puzzled by this, but PHP is not remotely my forte I'm afraid!

Would be super grateful for any assistance thanks.

[Marc]

The first thing I would do here is to upload a fresh set of files from your client area, to make sure the file itself is not corrupt. The reality is though, if it was working before, its likely the server.First thing I would do here is use the requirement checker

https://invisioncommunity.com/files/file/7046-invision-community-requirements-checker/

[Cretster]

Thanks Marc

I did do a compare of the init file using Beyond Compare and I'm sure it didn't flag any differences, but this whole thing about that bit of PHP syntax is bothering me since adding it into online checkers in some cases does give an error, so it's confusing me.
I think I need to make myself a test plan/matrix (spreadsheet or something) to keep proper track of things I've tried in case of any overlap or duplication of effort etc!

I did run the latest version of the checker last night and there were incompatibilities, but I assume that's because it's checking suitability for version 4.7.x?  I.e. should I be using the older version that it shows there from 11 May 2021, since that's the first one after the 4.4 version and my forum files are 4.5.4.2?

[Marc]

Unfortunately we can only provide support for the latest release. Actually if you are using 4.5.4.2 its likely PHP 7 is the issue. You really need to upgrade your site to the latest release of the platform.

[Stuart Silvester]

4.5.x will only work on PHP 7.2/7.3/7.4. The syntax error is because the code is not compatible with PHP 5.

After ensuring your server meets the latest requirements via the requirement checker, you can perform a manual upgrade to the latest version - 

 

[Cretster]

1 hour ago, Marc Stridgen said:

Unfortunately we can only provide support for the latest release. Actually if you are using 4.5.4.2 its likely PHP 7 is the issue. You really need to upgrade your site to the latest release of the platform.

Thanks Marc, totally appreciate that.  And this is the catch22 I kinda have at the minute as I'm basically trying to upgrade it to 4.6.7 but cannot run the upgrade script due to this current issue.  Since I can't access ACP or the forum itself, I can only do it by manual upgrade but just getting php errors. 😞

I've now just updated PHP on the hosting to 7.2 again, and this has moved the errors past the init.php file to the reactable.php file found at mycretsterforum.com/public_html/forums/applications/core/sources/DataLayer/DataLayer.php

With this error:

"syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting '-' or identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING)"

So after some looking online I found that curly braces were apparently needed around the variable in question, i.e. 
$_SESSION['ipsDataLayerEvents'], worked ok when changed to: 

{$_SESSION['ipsDataLayerEvents']}

The issue of course here is that there will be absolutely tons of such instances throughout all the php files on the site.
If I only have to do that formatting to fix it then I will try and find a way or some script that might be able to effectively do a find/replace on that sort of thing, I guess.

 

1 hour ago, Stuart Silvester said:

4.5.x will only work on PHP 7.2/7.3/7.4. The syntax error is because the code is not compatible with PHP 5.

After ensuring your server meets the latest requirements via the requirement checker, you can perform a manual upgrade to the latest version - 

 

Thanks for confirming about the supported PHP version Stuart, that certainly helps.  
As above to Marc, I've changed it to 7.2 now but looks like I might have to somehow manually update everything to that format, because I have already manually FTPd the upgrade files to the site but cannot run them because running mycretsterforum.com/forums/admin/upgrade/index.php is what is giving me all these PHP errors, even after setting it on 7.2 again.

I will run the compatibility checker again tonight anyway in case I missed something.

Really appreciate all the input from you folks though thankyou kindly!

[Stuart Silvester]

4.7.4+ requires a minimum of PHP 8 (4.6 required PHP 7.4+), it will not work on PHP 7.

You will need to update to PHP 8.0 or 8.1 and then perform a manual upgrade.

[Cretster]

Thanks Stuart, pretty sure I did try it on 8 also since that was what the server had been changed to iirc when I first got alerted to site being down and tried to manually run the upgrade.

I will double check though of course thanks.  It may be that there was another error that I already resolve on 8, then tried other versions, but haven't retried since possibly, so I'll revert once I've confirmed that.

Thanks again!

[Cretster]

Right, home from a very long and 'challenging' week at work now!
I ran the compatibility checker and it's all nice and green, no warnings, everything looking very happy.


The main forum URL now is giving an error complaining that a select for a table named core_alerts fails because the table doesn't exist, so I'll check in phpmyadmin on my original hosting to see if it did exist there, and if that's some potential migration issue maybe.

With regard to running the upgrader though, I do have progress at last, since it is at least appearing to try now.  However, it's failing to properly start a PHP session, and telling me to contact my host.  I'm wondering if this could be due to one of the php options/extensions available in hPanel on their site being set incorrectly, but I'm not savvy enough with PHP and its settings/options to know. 

I shall do some digging online before I message the host though as I'd assume it will be something others have run into before, and possibly something I might be able to resolve, if I investigate causes for that scenario happening. 

I could swear I saw something when I first googled saying that might be a permission error but I'll have to find it again now!



For what it's worth, here's the output from phpinfo, in case there's something damning on that!

Edited February 17, 2023 by Cretster

[Cretster]

Also I just spotted this while going through init.php

This is making me think now that since the hosting has been migrated and the new DB has a different prefix and different credentials that I will need to presumably set this variable as described here. 
I must have missed that detail somewhere previous tbh if that's the case.  If this was not set, would it potentially manifest in the error I'm seeing about failing to correctly start the PHP session?  I could imagine it might do potentially.

I hope therefore I can get the correct credentials for that!
Can I just check please the correct format it's saying here would therefore need to be like this?
'TEXT_ENCRYPTION_KEY' => md5(old_database_passOld_database_name),

And that the correct details for these are what I can grab from conf_global.php?

Thank!

[Cretster]

I did go through this page about migration between servers and didn't spot anything about that setting, so perhaps not needed?  Pretty sure the other considerations on that page are taken care of anyway.

[Stuart Silvester]

Since you're upgrading too, you'll need to complete that process (that's why you're seeing a missing table).

The issue with PHP sessions will need to be fixed with whomever manages your server. It could be something like a misconfigured path for storing PHP sessions, or the path isn't writable. The host will know more about that.

`TEXT_ENCRYPTION_KEY` is only used for some areas, such as storing username and password data in Commerce, or storing the answers to the security question MFA. If you don't use either of those, you don't need to worry about that.

[Cretster]

That's great thanks for confirming about that setting Stuart.

Which process needs completing though sorry?
Oh sorry I think I see what you mean now, that the normal forum url has an issue since the upgrade is not completed?
That's fine then if that's the case, I just kind of assumed since the upgrade stopped on that first step (login) that it wouldn't have made changes really yet.

No matter though since the site/forum cannot be used currently anyway.

Great anyway, I will ping the host and ask them if they can advise on that PHP session error.  I was hoping it would relate to something I could find details for either in the hosting settings, or with something in my files, but no point wasting tons of time chasing shadows if only they can advise on it!

Edited February 17, 2023 by Cretster

[Cretster]

Actually I think I just found it anyway!
Looked through the settings in Hpanel and spotted this, which matches the 1440 value in the error.  Seems odd to have a path specified as just a number like this pic.

Have messaged host anyway to ask them about this.
 

[Jim M]

That is quite odd, it should be a path rather than an integer. Hope you get an answer from them soon 🙂 . Please let us know if we can be of further assistance.

[Cretster]

Thanks Jim, appreciate it.

Thankfully at long last I have my forum back online again, so obviously I'm super stoked about that and appreciate very much all the input on here.

The only big issue I still seem to have now is that no images (in respect of avatars and image uploads/gallery images) appear to be working after this migration and getting the forum online again.

When I look at Chrome Dev tools I'm seeing a 403 access denied/forbidden error for each image that tries to load like this, so I'm assuming it's a permissions issue on the directory they're stored.

I've temporarily tried using a 777 permission on the forums/uploads/ directory, to test if that might help but unfortunately it hasn't, so I'm not sure what else might cause a permission error for pictures in the forum?  Or have I got the wrong directory perhaps for doing that?  Just about every setting in the storage settings section of ACP does point to there anyway.

Anyway, if I can sort that out then hopefully I'll have some very happy members now we're on the latest forum version.

Edited February 19, 2023 by Cretster

[Jim M]

Please note that this would need to be applied to uploads and all sub-folders of uploads. If you are running suPHP or similar, this may be 755. Additionally, you will also want to check that all folders there are owned by the correct user/group. Your hosting provider should be able to assist with this as they can run command lines to update this all quickly.

[Cretster]

Thanks Jim, I think I did apply it recursively but I'll check to be sure.
They do have a function for "fixing" file ownership and I did try that but also didn't seem to change anything.
I shall check these bits though and then contact them further.

Really appreciate all the advice from you guys here once again, thanks. 🙂