Jump to content
Matt

Introducing Invision Community 5's development tools

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.

Confused High Quality GIF

Your IDE with Invision Community 5.

brent rambo thumbs up GIF

 

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.

Could contain: Page, Text, File

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.

Could contain: Page, Text

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.

Could contain: Page, Text, File

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.

Comments

Recommended Comments

3 minutes ago, annadaa said:

can developers make improvements to your applications like LMS if they are only available on the cloud and therefore they have no access to the source files

It depends on what you’re trying to achieve, but devs can indeed to do a lot with help of GraphQL, REST and webhooks.

Link to comment
Share on other sites

Hi,

I have spent a number of days reading your IC5 development blogs and reviewing our plugins and applications to see what problems may arise and how we might solve them. Some changes are easy under your new system but others appear to have no obvious solution - and that will be a major problem for us.

adminCP reports that we have 62 hooks in our applications and plugins - that is "hook files" and as some of our hook files actually contain a number of hooks (e.g. one of our Theme hook files actually hooks into 13 different places) we could have around 150 actual functional hooks.

Many of the problems that we will face with IC5 appear to be because we cannot use hooks to remove functionality from the system. The following is a summary of some of the issues:

  1. Need to remove author (and any other personal information) from content displayed to certain groups. Our website is for a member organisation but also part of the website is visible to Guests (and a few other non-member groups) - and for security reasons we must conceal all personal information from Guests and non-member groups but allow it to be seen by members. We have 11 code hook files and 2 theme hook files to hide author information (replacing it with Guest information) as well as hiding the jsonLD information. Besides generic 'hide the author' it also took application specific hooks to hide download data, CMS data and calendar data - which also included RSVP sections of the calendar (no point in showing the RSVP if all the details are hidden).
     
  2. Hide "follow" buttons for Guests and all non-member groups.
     
  3. Hide comments and reviews from Guests and non-member groups. It is a member organisation so members can read content and post comments and reviews that can be seen by other members. Although we have content that can be viewed by Guests and other non-members we do not want the non-members to be able to see comments or reviews posted by members - there are two obvious reasons: (1) that some members post derogatory comments that are tolerated for viewing by other members but are not appropriate to show to non-members (2) part of the added value of being a member is that comments and reviews are visible as well as being able to post one's own comments and reviews.
     
  4. Disallow upload of attachments in various places - in particular, cannot add images to album descriptions, image descriptions, image comments, blog comments etc... Disallowing attachments is selective, so for example attachments can be added to forum topics and posts.
     
  5. Enforcement of "gallery rules". Simplistically, the gallery rule is that all uploaded images must have a meaningful and unique title and a similarly unique and meaningful description. Currently, this is enforced when uploaded images are submitted - the hook checks that suitable titles and descriptions have been entered and reports an error if the checks fail.
     
  6. Resizing (shrinking) images on upload. The standard IPS image size limits don't really work the way we need. File size (kB or MB) does not really relate to resolution (H and W in pixels) and in any case setting a limit gives a bad user experience as they don't know how to reduce image size to meet whatever limit we set. Our solution is to accept pretty much any image size and then reduce it to the size (HxW) that we want. This is selective according to where the image is to be stored so different resolutions are set for gallery, blogs, forum, profile, status updates, etc.
     
  7. Displaying maps - two actions: (1) filtering who can see maps (only member groups can) and (2) caching maps. The issue is that Google Maps started charging for use of the maps API - there is a free allowance every month but if we didn't take the above actions then we would massively exceed the monthly allowances and it would cost us a lot. Firstly, it is a member organisation so allowing non-members to run up costs (by viewing calendar maps) would not be acceptable so non-members cannot view maps - instead they are presented with a standard outline and a message stating that members can view the maps. Secondly, each event tends to be viewed multiple times by different members and if we did not take action then every view would generate a Google Maps API call which would cost us. We cache map lookups using the coordinates as the key and this reduces our costs. (This applies to other maps such as images and CMS/database maps as well.)
     
  8. Remove all references to the IPS newsletters and bulk mailing as we have an alternative system. (Our newsletters are managed through our membership system in conjunction with Mailchimp.) We have hooks to remove the standard newsletter widget and replace it with our own and another hook to remove notifications relating to newsletters/bulkmail.
     
  9. Add additional information to members displayed  in the staff directory. Specifically, the hook adds the member's organisation email address (rather than their personal email address).
     
  10. Selectively hide poll results from SOME members for SOME polls. Specifically, forum polls are used for voting on AGM motions and it is believed that showing the current voting levels could influence voters so the results are hidden from all members (except the people collating the votes). Other polls (i.e. not AGM voting) behave normally.

There are some that I have missed out that also don't have obvious solutions. Obviously, I've missed out all the hooks for which I believe there may be a solution (based on your blogs).

How can I solve the above?

Thanks.

John

Link to comment
Share on other sites


×
×
  • Create New...