v5 news coming soon...

[jesuralem]

I do believe pages could really be a killer app woukd it be easier to design pages and to use databases.

Right now it looks to me it still requires technical skills to create a nice site with pages and it could be almost no code with a little more love.

More globally the search engine could be better if you ask me and uses a lot of resources on the server side, there definitely is something to improve.

A real marketplace (multiple sellers for the same product, product catalog automated flow, etc...) would be huge but I guess this would require a lot of dev and it would be hard to compete with pure players.

[Matt]

4 hours ago, teraßyte said:

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.

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.

[teraßyte]

@Matt Another big issue that comes to mind is forms. Currently, it's really difficult to add new fields to most forms (or even modify them), and it's even worse trying to manipulate the values after the form is submitted because there are no hook points available inside the $form->values() IFs that are executed on submission.

 

If each form had a unique ID, with preDisplay() and preSave() hook points, it would save a lot of trouble. We could extend the form class and target the unique ID more easily. I've had to get really creative in some instances to add fields to some forms in 4.x... 🙄

[Matt]

Keep an eye out for the UIExtension news coming soon for form fields. 

[Chris Anderson]

2 hours ago, jesuralem said:

multiple sellers for the same product

IPS has a larger development team and is more familiar with the codebase so they will invariably release a new product or feature that will widely be used by the vast majority of their customers, but occasionally a developer might create a better version that "some" customers may prefer to purchase.  

An open marketplace should encourage innovation by all developers including IPS.

This would also better address continuity of service. 

Products are often supported for finite periods of time by both IPS and marketplace developers and once a product is no longer supported it leaves customers in a precarious position. 

Having the ability to have more than one version of a product in the marketplace gives everyone the option to be able to migrate to a competing product if the need suddenly arrises or a competitor offers a far superior product from other marketplace developers or IPS themselves.

 

 

 

 

 

 

[Daddy]

On 7/22/2023 at 9:08 AM, DawPi said:

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

How's $5

[Matt]

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.

 

[teraßyte]

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

[Daniel F]

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

[Matt]

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.

[Askancy]

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.

[Matt]

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.

[Matt]

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

In other news, I just merged 122 commits from the "UI Updates" branch. 👀

[Martin A.]

14 minutes ago, Matt said:

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

Nope, all good here

[nodle]

26 minutes ago, Matt said:

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

My only concern is who's going to feed all the monkeys now?

[Matt]

9 minutes ago, Martin A. said:

Nope, all good here

What do those hooks do?

[marklcfc]

If hooks are going, whats the process to get my current ones working on the new version? I only use a few, online indicator, EZ scroll top and an adblock checker. Also I have quite big ratings application that I assume will break.

Also, you said ages ago you were going to prepare for removing display name login, there's been no sign of that. I still disagree with this entirely and can't see any benefit, I've not had a single hacking complaint in 19 years on my site.

Edited July 25, 2023 by marklcfc

[Matt]

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.

[Grafidea]

Thorough code refactoring, improved optimization, modernized appearance, full support for SVG graphic files. In my opinion, V5 should not support older versions of PHP older than 8.0 or 8.1.

[Matt]

Just now, Grafidea said:

Thorough code refactoring, improved optimization, modernized appearance, full support for SVG graphic files. In my opinion, V5 should not support older versions of PHP older than 8.0 or 8.1.

It won't. I believe we'll be requiring 8.1.

[Grafidea]

Don't forget about visual experiences as well; most forum owners are laymen and pay more attention to appearance, simplicity, and functionality rather than source code. I hope @Ehren comes up with something cool.

[marklcfc]

39 minutes ago, Matt said:

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.

I meant you suggested you were going to make something available in the software notifiying users to confirm/update their email or something along those lines

Edited July 25, 2023 by marklcfc

[Chris Anderson]

12 minutes ago, Matt said:

we'll be requiring 8.1.

With 8.3 being released at the end of this year do you see any potential problems with the v5 codebase and tools working with that version considering upcoming new features and deprecations?

Is there anything in 8.3 you are at all excited about?

[Matt]

17 minutes ago, Grafidea said:

Don't forget about visual experiences as well; most forum owners are laymen and pay more attention to appearance, simplicity, and functionality rather than source code. I hope @Ehren comes up with something cool.

He has, and editing is much easier.

7 minutes ago, Chris Anderson said:

With 8.3 being released at the end of this year do you see any potential problems with the v5 codebase and tools working with that version considering upcoming new features and deprecations?

Is there anything in 8.3 you are at all excited about?

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.

[Chris Anderson]

30 minutes ago, Chris Anderson said:

we'll be requiring 8.1.

Based on the plusses and minuses of 8.3 you mentioned above, will you skip supporting PHP 8.2 and jump to PHP 8.3 as your next required PHP version once you have updated the calendar app and taken advantage of the new Read-only classes and json_validate() functionality?