Matt

Hi all, We've been working on fine-tuning the PHP8 compatibility scanner to ignore technically incorrect things, but they are still allowed with PHP 8.0 and 8.1. Please see this post for details:

We have released 4.7.2.1 with an update to the PHP8 compatibility scanner to make it less sensitive to issues that PHP8 is not concerned at this time, such as the following: Parameter variable names being different in the extended class, eg: Base: function foo( $node ) Extended: function foo( $forum ) Protected methods becoming public methods in the extended class, eg: Base: protected function foo() Extended: public function foo() Extended methods returning a type when the base class does not have any type, eg: Base: function foo(): Extended: function foo(): \IPS\Member This will reduce the number of third party code flagged and thus fewer plugins and applications being disabled. Posted edited to reflect that 4.7.2.1 has been released.

I've re-opened this topic. Please read the message above the topic, thanks.

I don't know what else we can do. We've given our marketplace authors about a year to prepare. We started releasing betas in May, and we posted the above in August; yet a lot of our marketplace authors seem unaware. However, we do not want to cause our clients a headache, so we're working on a way forward that doesn't leave you without apps and plugins you need.

Please hold while we work on a plan. We are hearing you all loud and clear and are working on a solution. I'll update you when we release a patch.

@Adriano Faria regarding different parameter names, PHP 8 is ok with it... for now. They may change this in the future.

I've opened a bug report for you on this. I agree that this isn't what you'd expect to happen.

But please read this:

I split this from the other topic so we can manage this issue for you.

Possibly not, I will investigate and we can isolate that check. We have to check signatures though, so if the parent was: function foo( \IPS\Member $member ) And third party code overloaded with function foo( $member ) Then you would get an error, so it's probably good practise to match the param signatures exactly moving forwards. Here's a good blog outlining the cool new things PHP 8 brings (and the breaking changes): https://stitcher.io/blog/new-in-php-8 I have updated the release notes to include a link to this topic. This will be visible in the upgrade block in the AdminCP.

Invision Community 4.7.2 now features a third party application and plug-ins PHP 8 compatibility scanner. Please read this post as you may find applications of plugins disabled after upgrading. Why do we need this? The underlying programming language that Invision Community uses is PHP. The latest version, PHP 8 was released in November 2020 and features many breaking changes and incompatibilities that are not backwards compatible. Some of these changes mean that what was a harmless silent notice, is now a fatal error which would mean that if you upgrade with incompatible code, your community would throw a fatal error which results in either a white screen, or a server level error message in your browser. These fatal errors cannot be captured by Invision Community and managed. The fatal errors are deeper in the execution chain. PHP 8 has been out for close to two years, and PHP 7.4 is 'end of life' and security updates will cease from November which means that it becomes insecure, so everyone will have to move to PHP 8 very shortly. What is it The compatibility checker examines all third party applications and plugins that you have added from the Marketplace. We encourage our Marketplace authors to test with PHP 8 but not all do, and as such applications and plugins that work fine with PHP 7.4 will fail with PHP 8. The compatibility checker scans all third party code for issues that could cause fatal errors, and if it finds them it will disable the application or plugin on upgrade. The only way to re-enable the application or upgrade is to update it to a 4.7.2 compatible version from the marketplace. Can I re-enable disabled third party plugins and applications? Yes, if you are confident the plugins and applications are fine to run with your current PHP version then you can re-enable them until our November release which will then enforce the disabling of applications. It's worth reaching out to the authors of key plugins and applications to see if they have a PHP8 compatible version available, or plan to have one by November so you can prepare for the November upgrade. Is this really needed? Unfortunately yes. PHP are making bold changes that are not backwards compatible. Invision Community is fortunate to have so many third party developers releasing apps and plugins to further enhance the feature-set, but we do not have direct control over this code. Our priority is to ensure that your site upgrades smoothly and remains online. Why now? We finally ran out of road. We have been working towards PHP 8 compatibility for a while, and we have encouraged our third party authors to do so too, and to test with PHP 8. We also informed the developers in August about the scanner and what it may do to their applications. We also have been releasing Invision Community 4.7 betas since May of this year to give them as much time as possible to update their applications. Enforcing this change is painful in the short term but benefits everyone in the longer term. What else can I do? Your self-hosting license allows you a test install which you should use as a staging site and test any upgrades on that staging site before performing the upgrade on your production site. This will enable you to capture any issues that may arise before you run it on your production site. As always, we recommend that a back-up snapshot is taken before any upgrade so that you can easily rollback if you encounter any issues. I'm using PHP 7, does this affect me? Yes, the compatibility scanner will still run on the upgrade and check for PHP 8 issues so that when you do upgrade to PHP 8 you won't find that your community is no longer working. Thanks for reading!

You will only have an issue if you are using third party applications that the authors haven’t had a chance to update since we started releasing betas in May of this year. I would think that most sites will be fine. To be clear, PHP 8 made breaking changes that will completely brick your site if we did nothing.

It is also possible that the visual translation tool is still enabled? This can be disabled via the AdminCP.

This is true, however PHP 8 compatibility was a big focus for 4.7, and PHP 8 made a lot of breaking changes (https://www.php.net/manual/en/migration80.incompatible.php). I would encourage all our marketplace developers to ensure they are using PHP 8 when developing and testing their apps to ensure they catch fatal errors before they are published. Wait until PHP 8.2... 🤪

Yes, we have since we started releasing betas for 4.7 in May, and we wrote a dev blog outlining what the scanner will do including locking applications about a month ago.

Yes, because you can upgrade to PHP 8 after the upgrade and then have a bricked install. Given that PHP 7 is EOL and security support ends in November this year, I'd suspect most hosts will start planning their upgrades to PHP 8 very soon. As mentioned above, PHP 8 have made things that used to send a hidden notice now throw a fatal error we cannot capture or adjust.

A pre-upgrade check wouldn't solve much as once you have the files up there, you either proceed, or you restore a back-up which is not a great choice either. We are going to be working through the marketplace queue to ensure we can get as many apps as possible through the approval process.

The way to unlock it is to upload a new version. As mentioned above, it's a bit of a frustrating time given PHP 8s drastic changes.

Yes, it's quite frustrating but the PHP 8 upgrade is very destructive and what were harmless notices are now fatal errors. We had to add quite robust checking and even disabling applications to prevent bricked upgrades. It's taken us a few revisions to get it completely accurate.

Unfortunately not. If your site heavily relies on specific applications or plug-ins, I'd advise checking to see if 4.7 compatible versions exist before upgrading.

We believe this will be fixed in 4.7.2.

It looks like MySQL is treating it as the same word which is interesting. Run the following query, and check to see if the Collation is 'utf8mb4_unicode_ci' show table status where Name='core_profanity_filters' You may need to add your table prefix in the name of the table inside the quotes.

99% of support issues can be dealt with in this forum and others may benefit from the conversation. If you need to post sensitive data, then just state that in the topic and we'll convert it to a ticket for you. "I'm getting an issue with MySQL and I have a slow query log, can I send it privately or have a ticket opened?" is all you need to do. 🙂

Indeed we are! We have plans to change how we package up JS to make it smaller and faster.

Not at all, just trying to keep our platform moving in the correct direction. We would be doing the same as any other modern platform.