teraßyte

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

I take back what I said 😅, I thought this was a different feature . I need more coffee to get past this midday slump. It is indeed elsewhere and the guide is correct. Thank you, terabyte!

Any app that you extend \IPS\Content\MetaData.

The Add Message option is available also in other areas:
Downloads Files Calendar Events Gallery Images Blog Entries Pages Database  
At least I'm seeing it everywhere. 🙄

Logged

@Marc Stridgen The error should still be fixed, though:
Call to undefined method IPS\core\extensions\core\EditorLocations\Contact::attachmentPermissionCheck()  
Even if the ID being looked up doesn't exist, it shouldn't throw a PHP error but show a proper error page at least.

@Marc Stridgen The error should still be fixed, though:
Call to undefined method IPS\core\extensions\core\EditorLocations\Contact::attachmentPermissionCheck()  
Even if the ID being looked up doesn't exist, it shouldn't throw a PHP error but show a proper error page at least.

@Marc Stridgen The error should still be fixed, though:
Call to undefined method IPS\core\extensions\core\EditorLocations\Contact::attachmentPermissionCheck()  
Even if the ID being looked up doesn't exist, it shouldn't throw a PHP error but show a proper error page at least.

It happens... I start typing and then end up going off on a tangent.  

One thing to consider as well...  maybe they're referring to "memory" as RAM and not as disk space usage.  This may not be a storage issue, but them saying your site has too many concurrent users (guests and real).  

Exactly this. I meant to add a mention about the RAM when I said to confirm what the hosting is asking, but forgot to. 😅

Yes, that is correct
Incidentally, also correct 

It's almost like he's been here a while 🙂 

See this topic:

You can't import a CSV list of the active members, it would just duplicate the accounts or skip importing them if the same email already exists (I forget which right now).
 
If you already have a list of active members, it would be best to:
Move all members to a new group. Run a script to move the active members (based on your list) back to the correct group. Mass delete the members that remain in the new group. Delete the new group.  
As I mentioned, you need to write a custom script that accepts the format of the list of active members and updates the accounts. Or, for example, if you have a query based on the email field, you can do step #2 above without a custom script and simply run your query with all the active members' emails.
 
In any case, be sure to do a backup before making any changes.