teraßyte

Well, yes, I could remove them. But if the field is missing, the value is not submitted, and the backend might throw errors about some array keys not existing or some other problem. That's why I think it's important to be able to alter the form fields directly rather than relying on CSS/JS "tricks" to hide or remove them. Yeah, I've been really holding back on saying too much for now. (Really! I had to say it twice.) But, from what I've read, my problem is that I can't do most of the things I need. 🤷‍♂️ Fingers crossed. 🤞

Unfortunately, that won't work: CSS is not an option because it would hide the fields for everyone, not just specific members/groups. In any case, they'd still be there in the output. Javascript would allow hiding the fields based on some extra JS variables in the output. Again, they'd still be there in the output. Since the fields are in the output, a person with some knowledge or a bot can still fill them in without trouble. Removing them completely, and not processing the values when the form is saved were requirements for the modification. (Don't ask me why it needs to be like that, but that was the request.) Being able to easily extend all forms and adding new fields to them is nice, but being unable to alter the other fields is a severe limitation.

@Esther E. Based on what I'm reading, we won't be able to alter the current form fields, only add to them. Is that correct? For example, I have a custom modification that hides some fields when submitting a new Event in the Calendar app. The client wanted those fields to be available only to certain groups. That's not something we can do using UI Extensions, and we can't overload anymore any methods. 👀 Another example in the marketplace is this one instead: It has the option to require the user to enter a message, and even require a minimum number of characters. With UI Extensions I won't be able to update this modification since I can't access the existent form fields.

There's a really easy way to avoid breaking methods: use a single array for every method and pass all values in that array. Need to add a new value? The array has a new index. 😋 😹

No issues there. He won't be able to upgrade 2/3 of them. Lots of time saved! 😂 Seriously, I have several apps and plugins extending classes in the /system folder. That means they're all dead for v5. So far, I don't like the direction v5 is taking at all. No matter what awesome tools you may have in place, being unable to overload (almost) all classes like before is a huge issue. Well, that's it for me for now. I won't say anything further until there is more info about those "awesome tools" you mentioned. But I don't have much hope for them.

To log the download, I have an hook on \IPS\File. I see no way to access it with Listeners? Guess I can only wait and see what comes next for now... 🙄

The second plugin is something that should be included by default really, but, leaving that aside, my main issue is the first one I linked. I have plenty of similar (custom) modifications. That's the biggest problem, and your reply doesn't help at all, unfortunately. 😔

I was silent so far, hoping for some revolutionary idea, but I have to agree with Adriano: with these changes modding is dead. Listeners are basically the old Library hooks from 3.x, and we can no longer overload any other methods (unlike before). I won't be able to update 85%+ of my modifications with this system. @Matt As an example, I see no way to update these plugins for 5.x: Unless I'm missing something, or you have more coming to still allow them.

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

On a site with a lot (really a lot) of clubs, the function \IPS\Member\Club::clubs() becomes rather slow because there are no indexes for the suggested columns in the phpDoc text: /** * Get all clubs a member can see * * @param \IPS\Member $member The member to base permission off or NULL for all clubs * @param int $limit Number to get * @param string $sortOption The sort option ('last_activity', 'members', 'content' or 'created') * @param bool|\IPS\Member|array $mineOnly Limit to clubs a particular member has joined (TRUE to use the same value as $member). Can also provide an array as array( 'member' => \IPS\Member, 'statuses' => array( STATUS_MEMBER... ) ) to limit to certain member statuses * @param array $filters Custom field filters * @param mixed $extraWhere Additional WHERE clause * @param bool $countOnly Only return a count, instead of an iterator * @return \IPS\Patterns\ActiveRecordIterator|array|int */ The description for $sortOption mentions 4 columns (last_activity, members, content, created), but the only indexes available are created and members. The other columns, including name (which isn't even listed in phpDoc), have no index, and any query ordering results by those becomes slower the more clubs the site has. Not to mention that there are queries based on club type, and the type column doesn't have an index either. And finally, there is an index on location_lat, but none on location_long. If you're trying to filter clubs based on location, you'd probably need an index on both columns, not just one. 🤨 We noticed the issue because the site has several Pages blocks that load clubs (2000+) based on various specific queries. P.S.: It would also be nice to have the option to filter the clubs based on their type in case you want to load only public or open clubs only. But that's more feedback that a bug. Just something to consider if you end up updating the clubs() function. (Or maybe look into it for v5. 😉)

Those functions cannot be disabled in php.ini for a single site's folder. They need to be disabled at the server level.

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

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: 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. 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? Payment Gateways: Same issue as Share Links (#2). Payout Gateways: Same issue as Share Links (#2). 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. 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. I'm certain there are more examples I could mention, but nothing else is coming to mind right now.

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. 🤷‍♂️

There is nothing you can change by default. If you want, I made a modification that adds some extra options for banned members: With it, you can block access to banned profiles and you can also automatically move them to a new group to highlight their banned status.

Do not delete them with a SQL query. Member data is all over the place in multiple tables, if you delete it only from the members and topics/posts tables you'll be in for a lot of weird issues all over the place. The best solution I can give you is to create a new group in ACP (call it TO DELETE or whatever), and then update the member_group_id column for all those members you've identified to the ID of that new group. Once that's done filter your members in ACP based on the group, and then prune them from the member search results page.

Check everything in the guides under the Themes and Customizations > Template syntax group: https://invisioncommunity.com/4guides/ This is a link to the guide specific to "request" and other similar shortcuts:

Once upon a time, everyone said so, even myself... 😋

This topic I just posted might be related to the same root cause. 🤔

The filters for the Providers list are broken: https://invisioncommunity.com/third-party/providers/ Here's a list of issues: If you filter by Theme Design it shows only 4 results instead of 20. If you filter by Plugin Programming it shows only 6 results instead of 21. If you filter by Complex App Programming it shows only 5 results instead of 16. If you filter by Data Conversion it shows only 5 results instead of 21. If you filter by External Integrations it shows only 5 results instead of 17. If you filter by Long Term Projects it shows only 5 results instead of 25. If you filter by Pages CMS it shows only 4 results instead of 21. If you filter by Community Managers it shows only 2 results instead of 7. The filter also says Community Managers (plural) while the profiles' badge is Community Manager (singular). If you filter by IPS Legacy Upgrades it says there are no results, when it should show 7 profiles instead.

It really depends on how you "integrated" it. 🤨 That said, the code in your screenshot about is from ipsRegistry_setup.php which is a 3.x file and won't work with PHP 8. That file doesn't exist anymore in 4.x. If you are unsure of how to proceed, the only other option would be to hire someone to deal with the upgrade for you: https://invisioncommunity.com/third-party/providers/ Just look for profiles with the IPS Legacy Upgrades badge.

The manual payout in /applications/nexus/sources/Gateway/Manual/Payout.php has a value in the code that still forces it to be manually approved: /** * @brief Requires manual approval? */ public static $requiresApproval = TRUE;

Both "Account Settings" and "Notifications Options" are available in the frontend, that's why you can't find them in ACP. Here's a link to those pages on this site as an example: Account Settings => https://invisioncommunity.com/settings/ Notifications Options => https://invisioncommunity.com/notifications/options/ You can however change the default Notification Options in ACP by going to ACP > Members > MEMBER SETTINGS > Notifications.

You'll be waiting a long time then. There are countless ways to bypass that kind of restriction as long as the user has access to the source code. Trying to stop piracy is a lost cause, you're better off forgetting about it and using that time on making more themes... 🙄