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

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

@Matt Traits... huh? In that case, please be sure to have a look at this topic: We need a solution to that. The only option currently is to add very specific checks based on URLs, and it doesn't work for every situation, either.

When I replied earlier there was no image in the first post. 🤨 Do you have anything logged in your browser's console?

Stuck how, exactly? Are you receiving some kind of error?

The template /applications/core/dev/html/front/tables/rows.phtml contains this code on lines 46-55: {{if $row->unread()}} <a href='{$row->url( 'getNewComment' )}' title='{lang="first_unread_post"}' data-ipsTooltip> {{if $row->containerWrapper() AND \in_array( $row->$idField, $row->containerWrapper()->contentPostedIn( null, $rowIds ) )}} <span class='ipsItemStatus'><i class="fa fa-star"></i></span> {{else}} <span class='ipsItemStatus'><i class="fa fa-circle"></i></span> {{endif}} </a> {{else}} {{if $row->containerWrapper() AND \in_array( $row->$idField, $row->containerWrapper()->contentPostedIn( null, $rowIds ) )}} <span class='ipsItemStatus ipsItemStatus_read ipsItemStatus_posted'><i class="fa fa-star"></i></span> {{else}} &nbsp; {{endif}} {{endif}} The problem is that the template uses twice the function contentPostedIn() without checking if the Node/container class uses the \IPS\Node\Statistics trait. Both IFs need this check added: \IPS\IPS::classUsesTrait( $row->containerWrapper(), 'IPS\Node\Statistics' )

The best option is to ask the developer, Stuart, directly.

No, they're not needed modules. Unless you use them for some other software, you can go ahead.

I mentioned the issue in my reply above, you need to manually specify the ROW_FORMAT value in the ALTER TABLE query to avoid using the COMPACT format set by default by your hosting. In your example above you're still skipping that part: ALTER TABLE downloads_ccontent ENGINE=InnoDB; instead of: ALTER TABLE downloads_ccontent ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

Try checking which TLS version your server is using. The Marketplace requires version 1.2.

It sounds like you're making a fresh 4.x install. However, to upgrade you only need to upload the new 4.x files over the old 3.x ones and then go to /admin/upgrade to start the upgrade process. IPS Guide link: