Matt

It's mostly focused around post-registration content detection.

Happily, this isn't the case, and marketplace sales have declined by 75% over the past few years showing that sales are not on the strength of after-market add-ons.

Most of those successful companies have taken millions in VC funding so they can pay people until some point in the future they start making a profit.

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

Esther is probably the most trusted name in that space, so we do indeed have that covered.

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. 😄

That is correct, you can add, but you cannot remove or modify existing data. We do have a limited template front-end hook system (yet to be blogged) but that again does not have a replace option.

What do you need to do that custom profile fields can't do?

What other forms do you want extended? We did discuss internally the registration form where custom profile fields aren't powerful enough (in that there requires some PHP/SQL processing of input data).

For now.. dum dum duuuuuuuuum. We have no plans to remove it.

Great modification, and that will still be possible in v5.

I'm not really sure what is driving customer habits beyond what we're seeing as trends in the industry. The community market has become more professional and hobbyist communities which used to keep the marketplace alive by spending $5 to $50 on something they felt they needed for their members are being consumed by social media or other hosted apps like Discord. My hope is that after market developers focus on few projects but more impactful ones. Wordpress has WooCommerce and Yoast which are incredibly popular and generate a lot of revenue. Proxy classes/code-hooks just couldn't continue. Our code base was years overdue a clean up but it would have caused massive support overhead and massive after market development headaches were most of the marketplace needed updating. What modifications do you have?

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. 🙂

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".

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.