Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


 Content Type 


Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory





Everything posted by Matt

  1. 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. 😅
  2. PHP just started crying.
  3. 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.
  4. 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.
  5. He will stare at me without blinking until I add in new tools. He can be quite scary.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. As always, we are listening. We have a lot to announce yet.
  11. We are discussing your feedback Adriano.
  12. 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.
  13. Events/Listeners blog out now:
  14. Matt

    Embedding Threads

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

    Embedding Threads

    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.
  16. 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.
  17. 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.
  18. It's a cue we took from social media which always has the permalink linked to the date.
  19. 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.
  20. We don't want to be stuck in the past too.
  21. 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")
  22. 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.
  23. 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.
  • Create New...