Stuart Silvester

Considered and decided against it faster than a quantum computer could have managed it.

Already in v5.
I think the sensible thing to do is wait for all the news of v5 to come out and then make an informed decision on your future. Trying to extrapolate v5 from a few dev blogs may lead to rash decisions.
I'd love to keep you as a customer, but if you do wish to move to xF then on the plus side you won't need to worry about new versions and there being significant changes in your future. 😄

💩

We literally changed code this morning because of your feedback on adding a listener to base classes. 🤔

Listeners is just one tool in the box. I would suggest waiting until you see the full structure before worrying about what you can and cannot do.

You'll have to manually open it with a database edit. For plugins just the 'disabled' and 'requires manual intervention' fields in the entry need adjusting (to zero); ditto for applications. You probably need to dump your datastore after making the manual edits.
Also, you are right @aXenDev, this current beta 5 still locks on upgrading. If they are making just an IN_DEV check, then yeah, it would still lock as we upgrade outside of dev mode. If IPS is actually checking for the -TESTINSTALL flag on the key, then it's just broken.
I suppose I'm lucky. Just one thing locked for me... that has been running on PHP 8 for a year. I'm more weirded out by all the log messages saying it can't parse the plugin directories as they think they are not there.
EDIT: The latter is caused by missing widget and tasks directories. They can change the log message for that to better indicate that is the problem rather than just say the plugin directory itself is the problem.

In 4.7.2 beta 4+ apps will no longer be locked disabled if you are using a development install.
Updating via uploading a new version or updating from the Marketplace should remove the lock. I will check this further to make sure it's working as expected.

In 4.7.2 beta 4+ apps will no longer be locked disabled if you are using a development install.
Updating via uploading a new version or updating from the Marketplace should remove the lock. I will check this further to make sure it's working as expected.

It's all versions. Since we're preparing to move our platform and self hosted requirements to PHP 8 this change is aimed at getting communities ready and also preventing a complete fatal error when upgrading PHP. I'm sure you'll have seen many of the support issues recently where customers have 3rd party resources that won't work.

It is included in 4.7.2. You can see it via the AdminCP > Support page (if there are any changes needed, it'll show up in the top left block). It'll also run on every upgrade to make sure your third party resources are not going to break the new release.

It's all versions. Since we're preparing to move our platform and self hosted requirements to PHP 8 this change is aimed at getting communities ready and also preventing a complete fatal error when upgrading PHP. I'm sure you'll have seen many of the support issues recently where customers have 3rd party resources that won't work.

It is included in 4.7.2. You can see it via the AdminCP > Support page (if there are any changes needed, it'll show up in the top left block). It'll also run on every upgrade to make sure your third party resources are not going to break the new release.

They'll only be automatically disabled if the scanner knows they will break (and I mean completely take your community offline). If you have a plug-in that will cause such an error it will need to be updated by someone. You might need to hire a developer to update it for you if the original author isn't active.

It's all versions. Since we're preparing to move our platform and self hosted requirements to PHP 8 this change is aimed at getting communities ready and also preventing a complete fatal error when upgrading PHP. I'm sure you'll have seen many of the support issues recently where customers have 3rd party resources that won't work.