Matt

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.

Events/Listeners blog out now:

We're very much keeping an eye on the shift in social media.

I think that is very low on their todo list, so it may be a year or more until we get a way to do that, and if Facebook is anything to go by, the number of hoops to jump through is ridiculous. I'm interested in the AP system too but want to see it implemented in Bluesky and/or threads before we invest time into it.

No major database updates so far. We don’t want to completely destabilise the entire platform. We have a fairly agressive timeline. We did consider foreign keys, etc but honestly the impact to end users is none and the risk of chasing issues for months is high.

What would that look like to you? Any examples you have in mind? I think what was announced in the blog already is more than that. 😅 Next blog will be tomorrow.

It's a cue we took from social media which always has the permalink linked to the date.

Yeah, happy to take a look. There's fewer opportunities for hooking and overloading in v5 so a lot of that likely won't work but I'm curious as to what you need and why. What would you like to see? Email templates are like coding in Dreamweaver in 1998. Design is definitely mobile first and @Ehren has already implemented scrolling tabs over drop downs. App integration, specifically pages records and topics - I see this as a semi-dead feature in that I don't want to invest a lot of time into it (but it remains in v5 and no deprecation plans). I'd rather find a smarter solution to the problem it solved 10 years ago. Other stuff is fine but we want 5.0.0 to be the start of a new journey and not just the end of one, so expect a lot of change over the 5.0 lifetime. We want to do the major things and then ship so customers aren't waiting 2-3 years between versions. A blog on theme stuff is coming but we've got a few things to finish first.

99+1%

We don't want to be stuck in the past too.

Please refer back to this post for my answer (Surely linking to the post is easier than saying "check out my answer on post #34")

Probably not. Things like read only classes are nice to haves, but we'd need to rework some stuff to use them. We tend to just start using new PHP for newer features and any major re-working of existing code.

He has, and editing is much easier. Read only classes, json_validate(). Concerns: DateTime. Calendar app will need updates as it leans heavily into PHP date time functionality. Not a major issue, just a thing we need to do.

It won't. I believe we'll be requiring 8.1.

All v4 applications/plugins will not be compatible with v5. They will all need to be refactored (not necessarily rewritten). Those hooks will need to be migrated across to UIExtension and event listeners. I'm not going to get into the username removal. It's already done. I'm happy that your one site has never had an issue, but we are responsible for tens of thousands of communities and millions of members.

What do those hooks do?

How do you feel about monkey patching being removed? Any concerns? In other news, I just merged 122 commits from the "UI Updates" branch. 👀

No date set at this time.

Again to moderate expectations; this was never a re-write, it was a clean up and new dev tools. I know we have some very verbose structures, but I added shortcuts to my IDE for things like Member::loggedIn()->language(), etc and then forget about them.