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 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.

3 hours ago, Manuel Monroy said:

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.

7 minutes ago, teraßyte said:

@Matt Taking a look at the included images, I see you guys are still using that same long-ass code for language strings:

Member::loggedIn()->language()->addToStack( LANG_KEY );

 

Can't you make it more simple with something like:

# Automatically uses Member::loggedIn()
Language()->addToStack( LANG_KEY );

# Make it use another member
Language( $member )->addToStack( LANG_KEY );

It's always been something that annoyed me. 😋

Personally I would love to have some helper methods like in Laravel.
We‘ve been talking about this and Matt wasn’t that annoyed by the idea. 😂

13 minutes ago, Daniel F said:

Personally I would love to have some helper methods like in Laravel.

It would be really nice to have strings like Laravel uses, i.e., @lang('application.string').

With IP.Board 5, please consider us translators as well, allow us a copyright string and a tool for differences at every update.

2 minutes ago, Matt said:

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.

Since you were rewriting the template, I think it would have been the right time to implement a change like that.

14 minutes ago, Matt said:

How do you feel about monkey patching being removed? Any concerns?

Nope, all good here

20 hours ago, Matt said:

What do those hooks do?

This is an app whose only purpose is to get the suite to function how we'd like it to. It's those 50 code hooks, and then an additional 25 template hooks. The most recent one is to the promote class in order to get the text you enter in the promotion popup over to Zapier. Another one is to allow a member to sign in once using their display name, which on successful login will reveal their email address. Some are bug fixes that have been reported but you can't reproduce it.

Also have one that adds analyzers and filters to the Elastic index which we need to get a proper autocomplete in a different app. 

One that I really like is one that posts log entries of interest to our Slack channel.

Can send it to you if you're curious.

9 hours ago, FanClub Mike said:

1. When a URL changes, custom Page Titles don't follow. They show in the adminCP under the previous URL.

How it is ralized now for SEO reasons is perfect, you avoid 301 redirects and 404 errors.

the slug of the page is commanded by the topic id. If you take this url as an example, the slug is: 475095-new-spam-prevention-features and the id: 475095

https://invisioncommunity.com/forums/topic/475095-new-spam-prevention-features/

The same topic will be accessible from:

https://invisioncommunity.com/forums/topic/475095-qw4124

https://invisioncommunity.com/forums/topic/475095-nerqwrqw2154w-spam-prevention-features/

So if the url changes, it doesn't create indexing problems for you.

9 hours ago, FanClub Mike said:

2. I would love to be able to create my own Title Templates for specific URL Paths. I realize that might be a bit of a niche request, however.

AdminCP->System->Advanced Configuration->Friendly URLs, Isn't this what you are looking for?

On 10/12/2023 at 4:14 AM, Daniel F said:

There were few changes which will affect own REST API endpoints.🫢

We'll cover this in an upcoming dev blog entry 🙂

Love to see the attribute use! Can’t tell you how many times I’ve screwed up the docblock formatting for my API docs and not realized it. Game changer! Hopefully this applies to the apiOutput method as well or something similar has been created!

On 7/22/2023 at 4:50 PM, HeadStand said:

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.

hi @HeadStand

Can you check your pms as awaiting a reply to pm from March regarding one of your apps

thanks

Edited June 5Jun 5 by sound