teraßyte

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.

The widgets are cached based on the time you have setup in ACP. The default is 5 minutes, but the update delay will be bigger if you've increased the caching time. You can check the setting in ACP > System > Advanced Configuration > Server Environment TAB > Cache sidebar, header and footer blocks. The photo disappearing, I'm not sure. 🤨

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.

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

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.

@micahdg Your screenshot says PHP 8.2. Try downgrading to 8.1 because 8.2 is not supported. This comes up often. IPS should really update the requirements checker script to throw an error for PHP 8.2+. I've already seen some people use even 8.3... 🙄

@Marc Stridgen While it's not strictly a bug, I suggest making an internal bug report to add a check to disallow a global banned entry like that.

Because of the error the code button popup keeps loading indefinitely and you can't insert any code in the editor.

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

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.