teraßyte

You also need to upload the files to the server before clicking Continue. Have you done that step?

You also need to upload the files to the server before clicking Continue. Have you done that step?

Edit the theme's settings (pencil icon; not the HTML/CSS) and you'll find a color setting with the name Tags Background in the Front-End Colors tab.

While members can disable it from their profile (admins can also edit profiles in ACP), there is no global setting to disable it for everyone.
You can either remove the block from the profile's template or hide it with a custom modification.

@superaven Have a look at this post from Matt for a (rough) timeline: 
 

There is some unused code in the Authy handler file /system/MFA/Authy/Handler.php in the verifyApiKey() function at the end of the file:
public static function verifyApiKey( $val ) { try { return \IPS\Http\Url::external("https://api.authy.com/protected/json/app/details")->setQueryString( 'api_key', $val )->request()->get()->decodeJson(); } catch ( \IPS\Http\Request\Exception $e ) { throw new \DomainException( $e->getMessage() ); } if ( !$response['success'] ) { throw new \DomainException( $response['message'] ); } }  
The IF after the TRY/CATCH is never executed, it either returns inside the TRY or throws an exception in the CATCH:
if ( !$response['success'] ) { throw new \DomainException( $response['message'] ); } It can be removed.

While members can disable it from their profile (admins can also edit profiles in ACP), there is no global setting to disable it for everyone.
You can either remove the block from the profile's template or hide it with a custom modification.

I agree, and reported. 

We released Beta 5 a short time ago to address this issue.

Trying to use the Code button in the editor on this site throws a JS error in the browser's console:

Trying to use the Code button in the editor on this site throws a JS error in the browser's console:

Trying to use the Code button in the editor on this site throws a JS error in the browser's console:

They moved support from tickets to this forum, if a specific issue requires a more private discussion they'll create a ticket for you.
 
In this case, it's a known issue:
 
You can either ask your hosting to disable STRICT MODE for your MySQL server or wait for 4.7.16 (currently in beta) which contains a fix for this issue.

I want to thank @teraßyte for outstanding guidance.
We were able to complete the upgrade from an outdated community forum from 4.2 to 4.7+ with his support.
His service is top notch and I highly recommend reaching out to him for help.
Respectfully,
Shyrax

Ive logged a bug for that, cheers 🙂 

I'm confused. Are you converting an SMF forum or are you upgrading from an old 4.2.9 version?
What kind of permission error are you receiving exactly? Without more details, it's impossible to tell what the problem is.
 
If you're indeed upgrading from 4.2.9 to 4.7.15, you need to perform a manual upgrade: https://invisioncommunity.com/4guides/advanced-options/server-management/install-and-upgrade-r259/#manualupgrade
 
The auto-upgrade in ACP won't work because you need to change the PHP version along the way.

Are you using this SMF forum? Based on your reply, you didn't even know it was there, I guess not. You can ignore/remove it. Or, if there are some posts or other content, and you want to preserve/import it, you can use the converter application after upgrading to 4.7.
 
As for the steps to upgrade to 4.7, what you're doing won't work because you also need to change the PHP version as I mentioned before. You need to proceed with a manual upgrade. If you follow the instructions in the IPS guide I linked, you'll be okay and the data will be retained.
 
If you're still uncomfortable doing the manual upgrade yourself, there's also the option of hiring a 3rd party Provider to do the upgrade for you: https://invisioncommunity.com/third-party/providers-directory/
I'm also on that list if you want to send me a PM.

The \IPS\Helpers\Form\Date class does not account properly for a member's timezone when the min and/or max options are set.
 
This is the file's code on lines 303-314 in the validate() function:
if ( $this->value and $this->options['min'] !== NULL and $this->options['min'] > $this->value ) { $string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_min', FALSE, array( 'sprintf' => array( $string ) ) ) ); } /* Check maximum */ if ( $this->value and $this->options['max'] !== NULL and $this->options['max'] < $this->value ) { $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_max', FALSE, array( 'sprintf' => array( $string ) ) ) ); }  
The code doesn't account at all for the timezone when checking the min/max values against the entered value:
$this->options['min'] > $this->value $this->options['max'] < $this->value The timezone is added only inside the IF check to display the error, but not before it for the check:
$string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() );  
This causes the check to fail for a user close to the UTC timezone, while it passes for a user with a more distant timezone.
 
Here is an example with 2 different timezones (Rome & New York):
DEBUG CODE: ================================================== print_r( $this->value ); print_r( $this->options['min'] ); print_r( $this->options['min']->setTimeZone( $timezone ) ); var_dump( $this->options['min'] > $this->value ); exit; ================================================== OUTPUT FOR ROME TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 00:01:00.000000 [timezone_type] => 3 [timezone] => Europe/Rome ) IPS\DateTime Object ( [date] => 2024-03-02 00:58:41.440303 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-02 01:58:41.440303 [timezone_type] => 3 [timezone] => Europe/Rome ) bool(true) ================================================== OUTPUT FOR NEW YORK TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 02:41:00.000000 [timezone_type] => 3 [timezone] => America/New_York ) IPS\DateTime Object ( [date] => 2024-03-02 00:52:00.648474 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-01 19:52:00.648474 [timezone_type] => 3 [timezone] => America/New_York ) bool(false)  
As you can see from the debug output above, the member with a Rome timezone fails to pass the check (TRUE triggers the error), while the New York timezone passes the check (FALSE doesn't trigger the error).
 
The timezone must be added to the min/max checks before the check is done, and not after to display only the error.

The \IPS\Helpers\Form\Date class does not account properly for a member's timezone when the min and/or max options are set.
 
This is the file's code on lines 303-314 in the validate() function:
if ( $this->value and $this->options['min'] !== NULL and $this->options['min'] > $this->value ) { $string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_min', FALSE, array( 'sprintf' => array( $string ) ) ) ); } /* Check maximum */ if ( $this->value and $this->options['max'] !== NULL and $this->options['max'] < $this->value ) { $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_max', FALSE, array( 'sprintf' => array( $string ) ) ) ); }  
The code doesn't account at all for the timezone when checking the min/max values against the entered value:
$this->options['min'] > $this->value $this->options['max'] < $this->value The timezone is added only inside the IF check to display the error, but not before it for the check:
$string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() );  
This causes the check to fail for a user close to the UTC timezone, while it passes for a user with a more distant timezone.
 
Here is an example with 2 different timezones (Rome & New York):
DEBUG CODE: ================================================== print_r( $this->value ); print_r( $this->options['min'] ); print_r( $this->options['min']->setTimeZone( $timezone ) ); var_dump( $this->options['min'] > $this->value ); exit; ================================================== OUTPUT FOR ROME TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 00:01:00.000000 [timezone_type] => 3 [timezone] => Europe/Rome ) IPS\DateTime Object ( [date] => 2024-03-02 00:58:41.440303 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-02 01:58:41.440303 [timezone_type] => 3 [timezone] => Europe/Rome ) bool(true) ================================================== OUTPUT FOR NEW YORK TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 02:41:00.000000 [timezone_type] => 3 [timezone] => America/New_York ) IPS\DateTime Object ( [date] => 2024-03-02 00:52:00.648474 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-01 19:52:00.648474 [timezone_type] => 3 [timezone] => America/New_York ) bool(false)  
As you can see from the debug output above, the member with a Rome timezone fails to pass the check (TRUE triggers the error), while the New York timezone passes the check (FALSE doesn't trigger the error).
 
The timezone must be added to the min/max checks before the check is done, and not after to display only the error.

The \IPS\Helpers\Form\Date class does not account properly for a member's timezone when the min and/or max options are set.
 
This is the file's code on lines 303-314 in the validate() function:
if ( $this->value and $this->options['min'] !== NULL and $this->options['min'] > $this->value ) { $string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_min', FALSE, array( 'sprintf' => array( $string ) ) ) ); } /* Check maximum */ if ( $this->value and $this->options['max'] !== NULL and $this->options['max'] < $this->value ) { $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_max', FALSE, array( 'sprintf' => array( $string ) ) ) ); }  
The code doesn't account at all for the timezone when checking the min/max values against the entered value:
$this->options['min'] > $this->value $this->options['max'] < $this->value The timezone is added only inside the IF check to display the error, but not before it for the check:
$string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() );  
This causes the check to fail for a user close to the UTC timezone, while it passes for a user with a more distant timezone.
 
Here is an example with 2 different timezones (Rome & New York):
DEBUG CODE: ================================================== print_r( $this->value ); print_r( $this->options['min'] ); print_r( $this->options['min']->setTimeZone( $timezone ) ); var_dump( $this->options['min'] > $this->value ); exit; ================================================== OUTPUT FOR ROME TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 00:01:00.000000 [timezone_type] => 3 [timezone] => Europe/Rome ) IPS\DateTime Object ( [date] => 2024-03-02 00:58:41.440303 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-02 01:58:41.440303 [timezone_type] => 3 [timezone] => Europe/Rome ) bool(true) ================================================== OUTPUT FOR NEW YORK TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 02:41:00.000000 [timezone_type] => 3 [timezone] => America/New_York ) IPS\DateTime Object ( [date] => 2024-03-02 00:52:00.648474 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-01 19:52:00.648474 [timezone_type] => 3 [timezone] => America/New_York ) bool(false)  
As you can see from the debug output above, the member with a Rome timezone fails to pass the check (TRUE triggers the error), while the New York timezone passes the check (FALSE doesn't trigger the error).
 
The timezone must be added to the min/max checks before the check is done, and not after to display only the error.

The \IPS\Helpers\Form\Date class does not account properly for a member's timezone when the min and/or max options are set.
 
This is the file's code on lines 303-314 in the validate() function:
if ( $this->value and $this->options['min'] !== NULL and $this->options['min'] > $this->value ) { $string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_min', FALSE, array( 'sprintf' => array( $string ) ) ) ); } /* Check maximum */ if ( $this->value and $this->options['max'] !== NULL and $this->options['max'] < $this->value ) { $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_max', FALSE, array( 'sprintf' => array( $string ) ) ) ); }  
The code doesn't account at all for the timezone when checking the min/max values against the entered value:
$this->options['min'] > $this->value $this->options['max'] < $this->value The timezone is added only inside the IF check to display the error, but not before it for the check:
$string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() );  
This causes the check to fail for a user close to the UTC timezone, while it passes for a user with a more distant timezone.
 
Here is an example with 2 different timezones (Rome & New York):
DEBUG CODE: ================================================== print_r( $this->value ); print_r( $this->options['min'] ); print_r( $this->options['min']->setTimeZone( $timezone ) ); var_dump( $this->options['min'] > $this->value ); exit; ================================================== OUTPUT FOR ROME TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 00:01:00.000000 [timezone_type] => 3 [timezone] => Europe/Rome ) IPS\DateTime Object ( [date] => 2024-03-02 00:58:41.440303 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-02 01:58:41.440303 [timezone_type] => 3 [timezone] => Europe/Rome ) bool(true) ================================================== OUTPUT FOR NEW YORK TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 02:41:00.000000 [timezone_type] => 3 [timezone] => America/New_York ) IPS\DateTime Object ( [date] => 2024-03-02 00:52:00.648474 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-01 19:52:00.648474 [timezone_type] => 3 [timezone] => America/New_York ) bool(false)  
As you can see from the debug output above, the member with a Rome timezone fails to pass the check (TRUE triggers the error), while the New York timezone passes the check (FALSE doesn't trigger the error).
 
The timezone must be added to the min/max checks before the check is done, and not after to display only the error.

If you have that code in your htaccess file then the Rewrite URLs? setting in your screenshot (which is disabled) needs to be enabled.
Also, this is the latest .htaccess file:
<IfModule mod_rewrite.c> Options -MultiViews RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteRule \.(js|css|jpeg|jpg|gif|png|ico|map|webp)(\?|$) /404error.php [L,NC] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> Yours is missing the webp extension.

No...  not really.  Those are default values... not necessarily YOUR values.  For example, settings.json has existed for literally a decade.  The schema data is not sensitive data either.  If an attacker can run direct queries on your database, you've got much bigger problems than knowing failed_login_count cannot be null or a default value is no.  And for furls, if you're not using them, you would see the complete URL anyway.   There is no extra security by going to /login vs /index.php?app=core&module=system&controller=login
If someone is REALLY that interested in knowing the default out of the box settings as an attacker, they could simply download the software source code itself (legally or illegally) to find them.  But there is nothing there that exposes anything about your install vs a vanilla fresh/clean install.  
 
 
 

Honestly that broken app is not worth the trouble nowadays, and their support being crap doesn't help either. It had a place before when the forum's theme was not responsive / good enough for mobile, but with the newer versions the situation has changed drastically.
Most of the sites I've updated in the last couple of years decided to drop it, especially after they started forcing forum owners to pay to upload the files to their own servers instead of tapatalk's cdn.
 
My opinion is that you shouldn't install it, no matter what your users say. Try mentioning instead that using Tapatalk makes them lose a lot of functionality compared to using the site in a normal browser. This is especially true if you have modifications installed on your forum, those will never work on Tapatalk.

The extra free months are if you convert your current license (with only some applications) to a classic license (with all applications). If you click the Click here to change under the Change your license to new Invision Community Classic terms title, you'll get a summary of your situation and the free extra months. Clicking that button won't change anything just yet, you have to confirm again on the page that loads, and only after choosing either the month or year renewal option.
Be aware that after clicking the button it might take a while to load all your data to calculate the extra free months. (At least it took more than a minute when I did it).
 
There are no issues. I've helped several clients switch from cloud hosting to self-hosting. You can ask IPS to provide you with a backup of your data anytime, purchase the self-hosting (classic) license, and import the backup on your new hosting. 👍