teraßyte

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:

Try using this kind of query which sets the table to use the DYNAMIC row format by default instead: ALTER TABLE nexus_licensekeys ENGINE=InnoDB ROW_FORMAT=DYNAMIC; That is, as long as your host has it enabled. I've seen plenty of hosting with only the COMPACT option available, unfortunately.

Click on Optional patch available in the first box (Invision Community) in your screenshot.

I think we need to take a step back and start from scratch here. What are you trying to do exactly? If you just need to load a member by using their ID, you don't need the hook or the remote_id value. Or are you trying to load a member based on some kind of external ID after adding a remote_id column to the core_members table in the database? Knowing your goal would help guide you in the correct direction.

I just had a thought. They could use the converters app and stop after converting (importing) the groups? 🙄 I think I did the same at some point with an older version, not sure if it's still possible on the latest version, though.

@Marc Stridgen The problem was indeed what I mentioned above. A call to getItemsWithPermissions() was missing the newest $location value at the end. I've already resolved the issue for them. 👍

@Marc Stridgen I'll turn it into your worst nightmare ever then. 😋 Jokes aside, there is a problem where that setting that is supposed to be for "records per page" controls also the "comments" per page. I made a bug report a whole year ago for 4.7.0, but it was ignored: Can you open an internal bug report about it?

Yes, that seems indeed correct. Try adding this code right before the parent call: var_dump( static::$databaseIdFields );exit; If the hook is being loaded properly, you should get an output of 3 values: name, email, remote_id. If you don't get anything, maybe there's a typo in the class you're trying to extend. Something like \IPS\Members instead of \IPS\Member. I had it happen a few times. 😅

As long as you fixed the parent call being outside the function in the example, it should work. I you post here the hook's code I can take a quick look maybe.

You can only use the allowed values in the \IPS\Member class for the second parameter: /** * @brief [ActiveRecord] Database ID Fields */ protected static $databaseIdFields = array( 'name', 'email' ); If you want to load based on the member_id column, simply skip the second parameter. You need to provide it only if you're loading a member based on their name or email address.