Miss_B

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

I wish we could do multiple reactions here. I wanted to like, agree, meouw and haha this post all at once lol.
Very well said @Matt. Why people are saying that they want to go to a community platform that is as good as dead, with no communication from the management and with very bad support to match, is beyond me. That is the same as turning in your ferrari for a beat up car that won't take you a few km without giving you engline trouble.
 

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

Yea, it's already in the Content\Item and Content\Comment class, you'll just call it in your template or override the method in your content class if you want to add something own.

I was just curious to know if most people just use the base IPS with the official apps and don't care about using third party apps/plugins.
That is indeed an advantage. And third party developers will also save some trouble because there is less risk of new IPS version breaking their apps.
If it's something that needed to be done, i guess we will all survive like it happened in the past with other major changes.

The capability to change how most stuff in IPS works and enhance it with own features/apps isn't going away.
What changed is how things have to be done. Some changes will be much easier, others will be probably annoying as hell for people who are used to how the hooks worked in v4, some will think that it is a huge step backward, but as Matt said, it had to be done, to provide a much more stable and faster-improving code base for v5, because we'll be able to alter or even deprecate methods, method parameters and even deprecate complete (internal) classes much faster, which also 3rd parties and clients will benefit from.
With v5 I'm really expecting fewer "A new community release with some huge under-the-hood BC breaking changes is here, all my apps are now broken and need to be updated ASAP" scenarios.
 
Code listeners are a quite common pattern used in modern applications, most php framework use this approach today. It's the perfect balance between none capability to change the core behavior via 3rd party code and the too-powerful proxy autoloader which we had in 4.x, which as powerful as it was, had also way too many problems.
I've read about concerns about missing event locations which were common in v3 and that it took ages to have new hooks implemented => Keep in mind that we have now a monthly release cycle, so I'm quite sure it's not going to take now that long to ship improvements as long as they make sense and fit into the general vision of the product.

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.

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

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.

Thank you for the well written and detailed blog @Esther E.. I am happy to see that Ipb 5 is coming along very nicely and I am looking forward to the next blogs. And congratulations on joining the Ips team 😊
 

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.

I'm sure there are others who have found in nice to get a glimpse 🙂 No matter which way we do this, releasing everything in a single blog would just be too much. And actually, we announced one yesterday, then release another today. These things are always a "damned if you do, damned if you don't" kind of thing. If we say nothing, some dont like it, if we say something, some wont like it.
There's more to come, as mentioned.

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. 

Not sure about your first example, but the "Delete All System Logs Button" won't be a problem at all!
As Matt or Esther said, just wait for our further blog entries, especially about the new UIExtensions

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

Thank you. It made for a very interesting reading. It looks like developing apps for Ipb 5 will be much easier. I am looking forward to the other blogs. 😃

Thank you. It made for a very interesting reading. It looks like developing apps for Ipb 5 will be much easier. I am looking forward to the other blogs. 😃

Thank you. It made for a very interesting reading. It looks like developing apps for Ipb 5 will be much easier. I am looking forward to the other blogs. 😃