Matt
Management
-
Joined
-
Last visited
Everything posted by Matt
-
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.
-
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.
-
No date set at this time.
-
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. -
You wouldn't want it released right now. 😅
-
One of these replies is more likely.
-
No, but you can use the new modal view in your content items. You'll just need to drop in the template call in the relevant part of your template to add the button: {template="analyticsItemLink" app="core" group="system" params="$item"}
-
We can probably work on the labelling, but I'm not keen on making it a high level item like that. It's not something most people will want to think about when they are on the site.
-
No, it is not mandatory.
-
Not in this version. This is more about data privacy than a general de-activate/re-activate function. With the functionality we have, when you enact the right to be forgotten, and it has been approved, the data is altered permanently with no way to undo it.
-
For now, we'll keep it so administrators must approve until we get a little more comfortable with the features. We wouldn't want large parts of an established community destroyed by content being de-attributed or removed without a final admin check.
-
You can choose to delete, or anonymise the posts (the IP addresses are removed, and the content presented as if it was from a Guest). When a member requests to be forgotten, it will anonymise their content. Cleaning embedded quoted content is something we're working on for a future version.
-
Not true. We do add a line at the end of every blog explaining which platform the feature is for. We have products and packages for every budget. You don't have to, we have the classic self hosted version. Our "cloud" platform isn't just cloud storage. It's a bespoke platform that happens to use cloud micro services. Cloud storage != Invision Community platform. It's not, we've just committed to self-hosted for Invision Community 5, now in heavy development.
-
That’s fine. We have products for every budget.
-
Earlier versions of Invision Community allowed a simple way to promote content to Facebook and Twitter. We have since removed Facebook due to their increasingly stringent policies and reviews on posting programatically. Recently, Twitter have announced new paid API tiers starting from $100/month. While a limited free tier remains, we feel that it is likely that the free tier will be further reduced or removed making this tool redundant. We have chosen to remove it, but will retain the popular "Our Picks" pages and widgets. For social promotion, we recommend using Zapier or other API methods. We hope that there will be good solutions for social promotions in the future and will certainly keep our eyes open to re-introduce these features.
-
Just to clarify that the Authy code still exists and can still be used, but you cannot create a new 2FA with it. If you wanted to set up a new 2FA with Twilio, then you would use the Verify API. But if you are using Authy, nothing changes, although Twilio have now deprecated the API and at some point will remove it. I'd hope they'd let you know in good time if/when they do. I've edited the change log above to reflect the changes.
