teraßyte

There is a way to import members, but not groups. You'd need a custom modification for that. It's probably faster to setup them from scratch unless you have a lot of groups. (Really a lot to make it worth a custom modification.)

That actually used to be the case at some point, but IPS now suggests always using InnoDB, which is more reliable than MyISAM compared to the past. Even the ACP Support page in 4.x will give you a warning if there are non-InnoDB tables.

That's your fault for quietly updating. Next time hire me from the start! 😋

The main issue is that some of the old upgrade steps aren't compatible with PHP 8. With PHP 7 they simply failed silently. When upgrading from 3.x, I usually upgrade to 4.7.3 using PHP 7.4, and then I upgrade to the latest version available after switching to PHP 8.x. It saves a lot of trouble. 😅

In the recent 4.7.11 update, I've noticed you updated the search filters code in \applications\core\modules\front\search\search.php to cast the variables as (int) types: if ( isset( \IPS\Request::i()->search_min_replies ) AND isset( $class::$commentClass ) ) { $filter->minimumComments( (int) \IPS\Request::i()->search_min_replies + 1 ); $baseUrl = $baseUrl->setQueryString( 'search_min_replies', (int) \IPS\Request::i()->search_min_replies ); $titleConditions[] = \IPS\Member::loggedIn()->language()->addToStack( 'search_blurb_min_replies', FALSE, [ 'sprintf' => [ (int) \IPS\Request::i()->search_min_replies ] ] ); } Note how there are 3 values cast as (int) in the code above. However, in the code for minimum reviews on line 514, the $baseUrl line wasn't updated: if ( isset( \IPS\Request::i()->search_min_reviews ) AND isset( $class::$reviewClass ) ) { $filter->minimumReviews( (int) \IPS\Request::i()->search_min_reviews ); $baseUrl = $baseUrl->setQueryString( 'search_min_reviews', \IPS\Request::i()->search_min_reviews ); $titleConditions[] = \IPS\Member::loggedIn()->language()->addToStack( 'search_blurb_min_reviews', FALSE, [ 'sprintf' => [ (int) \IPS\Request::i()->search_min_reviews ] ] ); } For consistency, it should be: $baseUrl = $baseUrl->setQueryString( 'search_min_reviews', (int) \IPS\Request::i()->search_min_reviews );

Most likely, a function's parameters don't match the changes in the latest version of the files, and that generates the 500 error. Your error_log file on the server should have more details about it.

It's a known issue:

I...see? Guess we'll just keep deleting these useless (for us) system logs. 🤨

This is the support topic for this modification:

Steps to reproduce: Go to ACP > Commerce > PAYMENTS > Settings > Currencies TAB. Enter 1 or more extra currency codes. As an example, let's use USD, EUR, and GBP. Select the DEFAULT? checkbox for all currencies. Hit Save. The form saves all currencies as being the default one, and the frontend always uses the first currency in the list. The form should instead throw an error allowing only 1 currency code to be setup as the default one.

Steps to reproduce: Go to ACP > Commerce > STORE > Settings > Gift Cards TAB. Enter some values in the stack field. Let's use 10, 20, 30, 40, and 50 in this case. Save the changes. After the page reloads the Gift Cards TAB will display the following values instead: 10, 20, 20, 30, 40. The value 20 is listed twice, and 50 is missing. At this point, reloading the page with F5 (without hitting SAVE) loads the proper values. However, if someone clicks SAVE again in another of the tabs, the wrong values are saved in the database this time.

Based on the error it's the block with ID 31 (content_blocks_31) and it's calling some undefined constant: Error: Undefined constant "IPS\Theme\forum_id_79" (0) If you've already deleted all blocks, maybe it's still cached somewhere. Try clearing the cache from the support page.

It's in the same place where you enter the FTP/ACP details. See this guide: https://invisioncommunity.com/4guides/client-services/getting-support-r292/#access

Inside \oauth\callback\index.php on line 108: <input type="submit" value="Proceed to Login" />

Yes. You can find a list of people available for paid work on this page: https://invisioncommunity.com/third-party/providers/ I'm also on that list, and I often help with upgrades. If you want, you can send me a PM with more details about your situation.

All those 4 warnings/errors in your screenshot will go away once you update to the latest 4.7.10 version. Or are you saying you are already on version 4.7.10 and those notifications are still there?

As the error says, the script wasn't able to write the file to your filesystem. Check the permissions for the /datastore folder (either 777 or 755; depending on your server configuration). If permissions are okay check that you still have space available on your server.

Oh wow, it took me a whole minute to realize it's from a widget. I didn't even remember it existed. Looks like it's using a different template so I need to add a new hook for that. I've added it to my to-do list.

Looks like your Pages (cms) application files aren't updated correctly to the latest version. To fix this is should be enough to re-download the ZIP file from your client area and manually re-upload all the files from it. There is a chatbox hook in the error backtrace, so it might be related to that. Try disabling the application and see if that fixes it. If you're using a custom theme try also switching back to the IPS default, non-customized one.

There should be an error_log file on your server (or maybe visible from your control panel; depends on how the server is configured). See if there's anything logged there. If you can't find the file, try asking your hosting for its location. I see Marc also mentioned: Maybe IPS will be able to have a quick look themselves since they have your FTP access.

It was a bug in previous versions because of the new future publish option. The bug was fixed in either 4.7.8 or 4.7.9, can't remember right now. Either way, since you've updated to 4.7.9 the issue won't happen anymore. The only way to fix already edited old posts is to change the post data directly in the database (always make a backup!) or using a modification.

Oh, I missed that part of your post. I can indeed see why it would be a problem with your situation. I can't really think of anything else right now. 🙄

A workaround could be to set up the Members group to not be able to send PMs unless they have at least a few posts. Once they make the required number of posts you can move them with an automatic group promotion rule to another group that can send PMs.

Adding validation for 3rd party login methods is not possible. Unless I remember wrong, they specifically have rules in place that no further validation should be required.

The badge icon is indeed not displayed on posts, you can see the same happening on this site: Once awarded, the badge icon appears only in the user's profile: https://invisioncommunity.com/profile/145950-teraßyte/badges/ => Helpful for a post in a topic