Matt

I agree. It wasn’t to suggest mods aren’t popular just that statistically more people choose to run “vanilla” installations. There has been a shift downwards in new applications for sure. I think that is just a byproduct of the forum market maturing and changing.

I’m unsure what the question is there. 🙂

Yes.

I'll repeat what I said in my first blog: We are being very intentional in restricting what can be changed with regards to our functionality and UI. None of this is by accident or an unintended consequence. We are providing tools to create features that side alongside our functionality, and less opportunities to replace our functionality. We will have a better suite of development tools to enable this. The third party developers are very important to us, but most customers choose to not use add-ons or modifications. Based on statistics we collect, the most popular plug-in on the marketplace has less than 250 current installations, and the most popular application has less than 600 installations.

I'd be surprised if only 20% of currently available plugins and applications were possible with v5. There may need to be some refactoring, some adjustment of the feature set but it's too early to say "well, we're going to lose 80% of the marketplace".

No. It's not the same as it was in CKEditor v5 due to how they changed building the editor. We will ship with more plugins though, and you can drag them into the toolbar as normal.

It is being done as we speak.

What version of Invision Community are you running?

For v5, correct.

It's hard to give dates, but we have a fairly aggressive timeline to meet and we're on track. I would say we should be in a position to showcase Invision Community 5 in some way during Q4 this year. I hope this doesn't become a "coming weeks" moment for me. 😅

PHP just started crying.

I completely understand the anxiety and I get the fatalism, but please have patience. Wait until we have laid out the suite of tools. Then consider if some of your mods are even worth porting over. Consider your highest quality apps and then let us know if you need guidance on how to migrate them to v5. Remember this is breaking news. Some of this code was only finished a few days ago. We are in the pre-pre-alpha phase. We are releasing news and listening to feedback, so there is no need to panic. Also keep in mind that v4 will be maintained until 2025 at least.

But it can’t continue. In the past, we’ve changed the signature params in getItemsWithPermissions() and had to patch the release as tickets pile up as apps which overload that just break. Internally we have a rule not to touch function params of commonly hooked methods. It means we can’t make changes to our PHP code without breaking loads of client sites. This means we can’t clean up and modernise our own code. Pretty sure it’s alpacas.

He will stare at me without blinking until I add in new tools. He can be quite scary.

No, code hooks are no longer in Invision Community 5. We have the listeners, UIExtension, menus and more limited theme-hooks as the primary toolkit.

Correct, there is less opportunity to overload/hook into/touch Invision Community 5. If you can give me some examples of why you'd want to overload those methods, we can help guide you to newer tools or understand why there is a need and consider adjustments to the dev toolkit. Monkey patching (code hooks) were convenient but the cost was very high in that we couldn't significantly alter our code without destroying most existing modifications causing WSOD, ISE500 or other errors on client communities. As PHP 8 becomes more strict about typing, return types, etc - a simple function signature change could break modifications. Clearly, allowing almost every single class and method to be overloaded is not something that we could continue doing. We also want to be a little more protective of some of our UI and flows. We want to build a toolkit that lets you build amazing add-ons and extra functionality but it will mean there is less scope for smaller apps that change some of our existing functionality. The good thing about these blogs is that we get to have a conversation and learn from each other.

I'm always keen to get information out as soon as we have it fixed on our end. There are pros and cons but the earlier the feedback, the more chance we have at addressing it and making sure we've not missed any angles. Give it a few months and the v5 codebase will be much stabler and we'll be more reluctant to make big changes. Some of the tools we're still actively working on, and stuff like theme tools are only about 80% complete, so there may be some gaps between blogs but we'll post them as soon as we have them ready. Not exactly, it's more like the JS event system, you can listen in on events and execute your code when those events are triggered.

As mentioned in my first blog, there will be things you can’t do in 5 and this is deliberate. But there is still a lot you can do.

As always, we are listening. We have a lot to announce yet.

We are discussing your feedback Adriano.

In this case, just create a listener for every applications Review class. This allows you to be intentional what you want to happen for each class and application. So you can still create this app in v5.