Hi all,

Next week we plan on releasing a few blogs outlining what development looks like for Invision Community v5.

I was curious as to what changes you'd like to see, and what changes do you think are coming?

A new UI, hopefully from @Ehren. Cleaned up code (if needed). More SEO (if needed). Faster rendering time (if needed). Maybe some fun new features like when Ranks were introduced. 

 

I was curious as to what changes you'd like to see

There have been quite a few developers and theme designers that have left the marketplace or are on the fence as to whether they will continue developing for v4 let alone the v5 platform.

Your team has been working extensively on two different codebases and have become quite intimate with it. 

I would recommend trying to visualize how difficult it would be for a developer new to the platform to setup a development environment and learn how to effectively create programs that meet your marketplace acceptance criteria.

Things to generally think about:

• How closely do your programmers adhere to common programming methods for each of the languages you utilize?

• Is your codebase entirely PHP 8 compliant or are you still utilizing code written for earlier versions?  

• Are your APIs intuitive to use?

• Is the cost for entry too high for the first couple of years a developer is learning how to write really good programs and their sales are next to none?

• Could your error messages be more informative?

• How does a programmer effectively test their apps? 

• What lessons learned from your testing team could be useful to a new programmer or to your customers that help beta test two different versions of your suite until such time as v4 is fully deprecated?

• Would it be beneficial to put a little more structure around public beta testing to minimize the number of additional betas or dot releases after final release.

• What might you do differently to make becoming a developer more appealing to make recruitment "MUCH" easier and to keep the ones you already have for the long term?

Will code hooks disappear?

 

Hi all,

Next week we plan on releasing a few blogs outlining what development looks like for Invision Community v5.

I was curious as to what changes you'd like to see, and what changes do you think are coming?

Full in-depth developer documentation with proper real-life full working examples on how to implement framework features.

 

I was curious as to what changes you'd like to see, and what changes do you think are coming?

• constant adoption of new php features and faster bumps in the min. required PHP. PHP is releasing newer versions faster than ever before and killing off the older versions just as fast. the biggest problem i had with IPS 4.x, was that it never really evolved. sure it changed, but it never really embraced features even found in php 5.4, let alone features added thru out 7's life. 
• Adoption of PSR for your code standards. gonna be honest here, i find your "coding standard" (the formatting of your code) to be the visual equivalent of an angry monkey biting down on a vibrator.  it is a serious amount of unpleasantness to view your code. i think the adoption of PSR, would be more welcoming to third party who has worked out in the wild on other things that use the PSR standard (which most frameworks/libs do now days and by nature a lot of apps have just adopted it from them). 
• this is a minor one, the embracing of imports+aliases when needed over FQN. FQN can make code look ugly,messy and add a fair amount of bulk. using imports, i can just look at the top of the file and see instantly what it is using.
• full adoption of semantic versioning. a lot of the problems that you have with 3rd party is cause you guys never stuck with a standard. you would throw in backward breaking changes in patch versions. it is pretty insane that a professional level software company wouldn't use a standard like semantic at the very least.
• Events Manager. i like the hook system just as much as the next guy, but i think polling of all the apps in the market place to see what is being hooked and how often, and then prioritize event triggers for those, you could probably ease a lot of your woes. 
• a better form class. i've said it plenty of times over the last several years, i really dislike the form building in 4. i think it was a step in the right direction, but i honestly think it could've been done better. i think it produces an extremely ugly code that could've easily been abstracted better.
• better use of traits/interfaces/abstract.  there are a lot of times where traits/interfaces/abstract classes should be used in 4.x, and they are simply not. a good example of this is extensions. there have been times where you have updated an extension, where you have removed methods or added in new ones and i had no idea. this is a good place where each extension gets an abstract class, where you can add/remove these methods, so if we don't implement them, they wont blow up. 
• search. have the search actually use the objects. you currently have things like "titleFromIndexData" and "urlFromIndexData", amongst other methods that attempt (and poorly i might add) to usurp the object class you have given us to do these very things. there are a few of my apps, who do not use the cookie cutter nature you've assigned here, so these methods require addition work from me and at times, impossible to do anything with the provided data, so i have to load the object anyway. 
• clubs. clubs are sort of a nightmare to implement. cause they are implemented on the item class, but god forbid you use a container/sub container class. then it becomes a huge annoyance to properly implement. clubs should be seriously revisited and much better implemented.

i'm sure i have more, but i get the feeling as it is, its already too late in the development of 5.x to serious take into consideration anything i would like to see changed. too bad you guys didn't ask this at more of the start of the development, we might've been able to create something wonderful together :). 

first, clean up the code.

Code clean up ✅

Import over FQN ✅

Better use of traits ✅

Search code clean up ✅

Happy PHPStorm without hacks/class_alias ✅

More recent PHP versions needed ✅

Better use of newer PHP functions ✅

More to follow, but I think you’ll be content with the changes to be announced.

 

Hi all,

Next week we plan on releasing a few blogs outlining what development looks like for Invision Community v5.

I was curious as to what changes you'd like to see, and what changes do you think are coming?

Well, that's what I would have liked to see asked before you guys started working on v5. Nothing's going to change at this point, even if we answer. 🤷‍♂️

Has v5 been released and no one told me ? 😀

We have built new tools but will listen to feedback and there is plenty of time to tweak and adjust. 

Allow us to choose whether we want load fonts or js via cdn or local. (CDN add unnecessary delays for some, so it's not always useful)

My wishes centre on internationalisation and localisation because I run a site which must give equal standing to two languages.

• Allow admins to provide a FURL for every aspect of a URL. In 4.x the app names are fixed because they come from /applications/[app]/data/furl.json, meaning that non-English sites are condemned to have English words such as files and store in their URLs.
• Allow admins to create and match equivalent pages depending on the language with their own slugs. For example, you have invisioncommunity.com/features/clubs/ on this site. If it were necessary for you to have a multilingual site, you would be able to create an associated page (very likely with the same content aside from text) with its own slug, such as invisioncommunity.com/trajtoj/kluboj/. When a link is created in the Menu Manager or written within content, the site would know that on click it is to load the language-dependent associated page; is somebody manually types <a href="invisioncommunity.com/features/clubs/"> within a post, the site would redirect to an associated language-dependent associated page.
• Please move away from the approach of concatenating different language strings as a short-cut. What works in English often doesn't in other languages, and I'm forced to present grammatical mistakes in some parts of my site because words which are plugged in interchangeably in English strings take different forms depending on their grammatical role. My word for a post will have different forms in the superficially similar: {!#[?:%s liked]} %s and %s reacted to %s:, for example.
• A long shot but please consider providing occasional context of how a language string is used. Translators need to know, for example, whether Report is a noun or a verb. (Incidentially, because of the previous point, I have instructions in an email notification inviting moderators to "Click to see this To report" because if I change to our equivalent noun, then the instruction "Report" on the content containers is the wrong word.) 
• It might be possible already for people more knowledgable than me but it would often be useful to be able to change the user's language setting via something in the URL. We're a UK-based charity so have English as our default language but our activity is worldwide using another. It'd be great for me if the language could be set as the second one for a visitor following a link such as invisioncommunity.com/cy for Welsh, for example.

Improvements are nice, but my main concern is maintaining existing projects. I would want to know everything that is not possible anymore and learn if there are alternative ways. This includes hacky solutions like putting a MySQL query in a theme template and things like that. I have lots of customized installations and I don’t want them to be stuck with 4.x.

I like unified developing environment for v5 in Themes and Apps. easy to work when it's come to adding basic functions and features and at the same time, open for extensive coding outside. basic functions and features like adding new language strings, settings, tabs, separators should be all handled smoothly inside the development area. manage settings in v4 Themes, is what i like to be implement for app/theme creation for v5... with more integrations and features.

One more thing is about implementing new measures to prevent piracy. personally have little knowledge about what already is done and how people can find ways to get around it, but it should be effective methods to prevent it.

From a non-developer point of view: There's so much. For example,

• I hope for an easier user search, so that more connections among users are created.
• And I hope for the possibility to use tables of contents in Pages.
• The tag sites should not look like a simple search results page, we should at least be able to add an image and an intro. And they should be indexable for Google, for example.
• I would also like to be able to create custom fields in Events.

Surprise me!

A better mobile experience.

A fresh new look but don't strip it completely down so its as bare as IPB 4 was initially (it was basically mostly white)

my point of view as a consumer: notify third-party applications before launching new versions, because in some cases they are mandatory and the purchased products are no longer compatible, which for many like me, we have functions that are not included in the forum and we must buy a plugin to solve it. but we find updates that throw away critical functions and we must indefinitely "patch" something until it is updated, when that update arrives there is already a new one and so the snowball. Therefore, there is a lot of communication between collaborators, I think this has been going on for many years, perhaps one option would be to open a "development team" no longer from third parties but from invision in the market place in such a way that we avoid having prolonged falls in the pages that we manage due to communication problems between you and third-party applications. The only thing that works without fail in these 11 years of IPB despite big changes in versions, are the credit card charges.

 

perhaps one option would be to open a "development team" no longer from third parties but from invision in the market place in such a way that we avoid having prolonged falls in the pages that we manage due to communication problems between you and third-party applications

Great! 🤪 One question - who and how much will pay for something like that?

 

Great! 🤪 One question - who and how much will pay for something like that?

It always depends on what you are looking for, in our case we have paid extras to fix something already in the market place, we have had to buy add-ons again because others stopped having updates. precisely now we need a php block that does not use cache (page php does not work for us), the plugin that we had for 2 years stopped working 2 updates ago. therefore we are patching one from June 20. Now in the last update I let the page gallery assign prefixes to the images, messing up our organization of the content and overwriting images with the same name (let's pray that in the next update they correct this error or add new "details" that impair the proper functioning). For that, a communication team for application creators would be essential or if that channel does not work then they could create a personalization team directly as invision.

 

we have had to buy add-ons again because others stopped having updates.

This is the risk of buying any add-ons. I'm glad IPS checks add-ons before they enter the marketplace. I honestly don't expect more.

Edited July 22, 20231 yr by Claudia999

I see this got forgotten or not even taken into consideration, there are enough people so to say who agrees with my suggestion, but I see no implementation of it or even mentioning it in any way 😑😑🫤

 

 

 

I see this got forgotten or not even taken into consideration…….

This is incorrect. Items in the feedback area would always be taken into consideration. However this doesn’t mean they will be implemented as it would depend on whether they fit into our internal goals for the platform. And those which are added would not always fit within the development plan of a specific version. 

 

This is incorrect. Items in the feedback area would always be taken into consideration. However this doesn’t mean they will be implemented as it would depend on whether they fit into our internal goals for the platform. And those which are added would not always fit within the development plan of a specific version. 

Yeah. But if you take a second to think about it, first thing when people are installing their suite will immediately search for those plugins, but when uploading they get errors cuz the plugins are out of date. Thats Why i think this should be added. Anyway, I’m not running Invisioncommunity, I’m not part of the management staff or such. But please speak with your management team and consider adding those. It would be a life savior for all of us!

 

notify third-party applications before launching new versions

We do get notified, with (almost always) plenty of time to update. It's just that some of us have a large number of marketplace resources and so those resources may not be updated the very second that a release is available. Additionally, each update has to go through a review before it's available.

In most cases, the monthly releases don't break the marketplace resources. You should only (potentially) have issues when upgrading to a bigger release (e.g. 4.6 -> 4.7), at which point you should reach out to the plugin developer to check compatibility.

 

Has v5 been released and no one told me ? 😀

We have built new tools but will listen to feedback and there is plenty of time to tweak and adjust. 

Since you're asking nicely, and leaving aside things already mentioned (like not being able to overload trait functions), the biggest problem I can think of is that extensions are useless or not properly implemented.

 

The system has several issues:

1. Extending the Member and Group classes: before it was easy enough, but then IPS forbid adding extra columns to the default tables. Now we have to implement our own code to save the fields in an extra table, add a join to load the data together with the load() function, etc. Those extensions should be updated to automatically take care of all that for us, without the developers having to implement their own code each time. It's seriously time-consuming and annoying, even more so because we have to add hooks all over to handle it.
2. Share Links: to add new share link options, we have to hook into a function that contains a hardcoded array of options. This should be handled with extensions, too. Why do we have to search in the code for the function to overload with a hook to add them?
3. Payment Gateways: Same issue as Share Links (#2).
4. Payout Gateways: Same issue as Share Links (#2).
5. Account Settings: there are plenty of applications that add new tabs/sections in this area. IP.Board 3.x had an extension for that, but it was removed in 4.x and never re-added. This is the same situation as #1. Why do we have to handle everything by adding hooks all over? This should be made into an easy-to-add extension, too.
6. User Menu: Again, plenty of applications add new links in the logged-in user menu. Right now we have to rely on theme hooks to add new options, and sometimes themes are so modified that the hook fails to work. If we had an extension that passed the links together with the default ones it would make things much easier.
7. I'm certain there are more examples I could mention, but nothing else is coming to mind right now.

Edited July 23, 20231 yr by teraßyte