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. 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.
  2. Events/Listeners blog out now:
  3. Matt

    Embedding Threads

    We're very much keeping an eye on the shift in social media.
  4. 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.
  5. 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.
  6. 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.
  7. It's a cue we took from social media which always has the permalink linked to the date.
  8. 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.
  9. We don't want to be stuck in the past too.
  10. 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")
  11. 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.
  12. 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.
  13. It won't. I believe we'll be requiring 8.1.
  14. 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.
  15. How do you feel about monkey patching being removed? Any concerns? In other news, I just merged 122 commits from the "UI Updates" branch. 👀
  16. 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.
  17. Yes, there's a lot we would love to do, but a tear down and re-write isn't something we have the luxury of time for, so we will need to keep using the "long-ass" methods for now.
  18. The first blog is out now: Keep in mind that it's a 10,000 foot overview, there's much more detail to follow in subsequent blogs.
  19. When planning Invision Community 5, we knew we had a unique opportunity to hit the reset button. It's hard to believe, but how we work with the framework has been the same since 2013. The priorities we held a decade ago no longer align with our current vision. The landscape of modern frameworks has evolved, and we have adapted accordingly. When we initially designed the Invision Community 4 framework all those years ago, our goal was to create an open development platform. We aimed to empower you with the ability to extend virtually every function we built, granting complete freedom to shape our UI, workflows, and functionality according to your needs. However, over the decade, we have realised that this freedom has inadvertently become a prison. While monkey patching allowed the overloading of any method we had written, it came at a significant cost. Even the slightest change to our original method signatures could break an entire community, forcing you to update your applications. Ironically, the more we strived to enhance our framework, the less stable your applications became. We dismissed requests for proper workflows like extensions, webhooks, and event listeners, urging you to rely solely on method overloading, often having to copy chunks of code just to add a few lines of your own. Invision Community 5 represents a much-needed reset. It is a moment to reassess everything we know about extending frameworks and construct definitive pathways and workflows that serve you better. Our aim is for you to continue crafting exceptional applications that bring fresh functionality to the Invision Community while protecting the integrity of our core functionality. Change can be intimidating, but let us embrace this opportunity to bid farewell to outdated and fragile tools and pave the way for a collaborative future with precision-designed resources instead. In the coming weeks, we will delve deeply into the new development tools offered by Invision Community 5, but today, I wanted to give you a brief overview of what's to come for code development. We will do a near-future entry on creating themes with Invision Community 5. Out with the old Monkey patching via code hooks was the primary way to add functionality to Invision Community. However, it meant that we could not update our code base without risking breaking many popular applications, a situation that will only get worse as PHP starts to lock down type hinting and casting. Furthermore, IDEs have a tough time working out relationships between classes requiring special tools to create alias files to allow full use of many advanced tools of PHPStorm and other editors. Finally, monkey patching relied on heavy use of eval() which is not a very efficient PHP method. Monkey patching has been removed in Invision Community 5. Your IDE with Invision Community 4. Your IDE with Invision Community 5. Template hooks, as you know them, have also been removed. I only mention this now as they often go hand-in-hand with code hooks to add items to menus, data-attributes to blocks and CSS classes to many areas. We will do a more thorough blog on theme editing soon, but we still retain a way to hook into key areas. In with the new We will write a series of developer blogs to look in more detail at the new systems, but here is a quick overview of the new tools and a brief description of what they are capable of. Content Menus We have removed much of the menu logic for content items and comments from templates and created a simple, extensible way to add links to commonly used menus, such as the item moderation menu and the per-post 'three dots' menu. You no longer need a template hook to perform such a basic task. UIExtension This framework provides you with an easy way to add CSS, data-attributes and even templated HTML into specific areas within nodes and content items/comments. A common reason to create template hooks was to tweak the CSS classes or add data-attributes for client-side scripting. In the same way that we've stripped menus out of templates, we've removed the content item badges (pinned, hidden, etc.) and into the UIExtension making it easy to add your own badges to this area without the need for template or code hooks. Finally, UIExtension can add form fields into Invision Community content forms. Event Listeners The easiest way to describe this is like MemberSync but for content (items and comments), members, Commerce invoices and Commerce packages. Do you need to run your code each time a forum post is made? Not a problem. Do you need to run your code when a topic is locked? Perhaps when an item is viewed? All this and more is possible via the new listeners. The advantage is that you don't need to copy chunks of our code when overloading a single method in a hook. You write your clean code in an object-specific listener. What else? We have also undertaken a long overdue code clean-up. Every single file has been updated to update return types and function signature types and to use aliases instead of fully qualified names (for example, new Url() instead of new \IPS\Http\Url()). Many methods have been removed from the Content classes and moved into traits. Likewise, many interfaces are now traits to reuse code properly, reducing the behemoth-sized classes. Elsewhere, all the search indexing logic that was entwined in content and node classes has now been moved to the extension system, further reducing the noise and volume of key classes. A Quick Recap Generic broad reaching tools such as monkey patching and template overloading have been removed. New precision tools with a specific use-case have been created. There are less opportunities to overwrite and change our UI and functionality but easier ways to extend and create new functionality. The future We have worked hard on these development tools to ensure that most of what you do now can be achieved in Invision Community 5. We have had input from various stakeholders, including those who regularly create modifications for Invision Community to ensure our new tools are fit for purpose. Through the alpha and beta testing phase, we want your feedback, and we will listen to your suggestions. We cannot promise that you can do everything with Invision Community 5 that you currently do, which is intentional, but we are confident that you can still hit all the major beats. We want to protect our UI and functionality a little more but encourage you to build amazing new functionality to work alongside Invision Community 5. Together, we will shape the next era of Invision Community.
  20. We love updating things because Elon got bored.
  21. Keep an eye out for the UIExtension news coming soon for form fields.
  22. All excellent points. Let me run through them. 1) Agree, that restriction will be lifted in 5. 2) I'll check to see if we have an easier solution for this in 5. 3) Easier in v5. 4) Easier in v5. 5) Will check to see if we have a solution for this in 5. 6) Fixed in v5.
  • Create New...