teraßyte

It calls this domain to check the license: Make sure your server can reach it. The editor's code button doesn't work, so I put it inside a quote. (I'll make a separate bug report for it.)

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.

Please send me a PM. 🙂

Ignore the version in cPanel, as long as it's not set for the domain correctly, it won't be found. Check the box in ACP, what does it say? If it still says PHP 8.0.XX like in the image above, the domain's PHP version in cPanel is not set correctly.

Install the patch in your ACP to fix the error:

If I remember correctly, that option appears only for images you have uploaded in the gallery. If the users don't upload images themselves, they can't use the option. It can't be used to insert images uploaded by others in the gallery.

The warning should go away as soon as you switch to PHP 8.1. What PHP version is the support page detecting? Maybe the switch was not successful and you're still using 8.0?

To start the upgrade you need to go to /admin/upgrade rather than /admin/install.

Since it's 3 major versions behind, I wondered if the site has outdated info and if the converter is actually updated for the latest version. P.S.: @Marc Stridgen The list in the box mentions wpForo 1.9.x, but clicking on it the version available in the dropdown is wpForo 2.1.x. It's just a minor bug, but I thought I'd let you know. 😋

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 conversion page lists Woltlab 3.1.x as available, but I'm not sure if it also works with 6.x: https://invisioncommunity.com/services/convert/ This migration will redirect your existing URLs WoltLab Suite (3.1) to Invision Community - Convert Profile Field Groups - Convert Profile Fields - Convert Emoticons - Convert Ignored Users - Convert Member Groups - Convert Members - Convert Private Messages - Convert Private Message Replies WoltLab Suite Forum to Forums - Convert Forums - Convert Topics - Convert Posts - Convert Attachments You can check this guide for how to use them: If you're not comfortable doing it yourself, it's also possible to hire a 3rd party Provider to do it for you: https://invisioncommunity.com/third-party/providers-directory/ However, as I mentioned above, I'm not sure if the current version of the converters supports the 6.x version. You'll need to wait for IPS to confirm whether that's the case. If 6.x isn't supported, developing a custom converter is the only option.

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.

You need to check the tables. The individual tables can have a different charset than the database one. If your tables aren't utf8mb4, the ACP support page should show a warning about it.

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.

Is your database using the utf8mb4 charset or something else?

That's a rather unique problem, I've never heard this before. 😮 The quote javascript already moves the cursor after the quote, but maybe you could change it to add also some text like "REPLY HERE" or something similar? However, it will require a custom modification since JS is not something you can edit directly like a template.

The only other thing that comes to mind is that your site (or at least the new server's IP you're on) is under a DDOS attack, and that's filling up the user connections. You'd still need to check with your hosting about that, though.

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.

Since you have the index.php? part in your URLs, I don't think you ever enabled the htaccess redirect option for Invision Community in your ACP.

Do you mean a particular topic perhaps? There has never been a feature for individual posts, I'm not even sure how you'd track that even if you used to have a modification for it.

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

The column cache_sm is not a default one in the forums_topics table. It must have been added by a modification at some point. Either the modification is now disabled or uninstalled, but the column is still there, and since it doesn't accept a NULL value, the database throws that error. The column name itself doesn't tell what kind of modification it could be. The only way is to investigate the database/modifications on your site and pinpoint where it's coming from. And, in case the modification is already uninstalled, the column needs to be removed manually. 🤔 This is not something IPS can assist with since it's caused by a 3rd party modification. Unless you know how to do it yourself, you'll need help from a 3rd party developer/provider. If you send me a PM with more details, I can take a look.

The EasyPost integration is a Community Enhancement. You can refer to this guide to find the setting I mentioned (see the 2nd and 4th screenshots):

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

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