teraßyte

Downgrade to PHP 8.1, the 8.2 version is not supported yet.

From which version did you upgrade? Also, are there any errors logged in ACP > Support > System Logs?

Based on your reply, it shouldn't reappear anymore now that you closed it.

There isn't any need to make a copy of the database. Unless you made one and then cleaned infected tables/content from there, too? The best option is to re-upload a fresh set of files, and then compare the folder to check if there are any extra folders/files. Comparing the database tables to a fresh installation helps find the extra ones there, too. You also need to account for 3rd party applications and plugins, though. If you'd like, I offer a cleanup service. You can check my site or send me a PM.

I've seen several people make that mistake so far. 🤷‍♂️

@Safety1st I sent you a PM. 👍

I'm not sure how the scanner works right now, but I guess it scans the used language strings and checks if they exist in the lang.php file? If so, it should also check for required language strings that the system expects when you add a specific extension/feature/node/etc. For example, when you add a Node/Item that supports search, you need to add specific language strings for the quick search menu, contextual search menu, etc. All those language strings are not documented anywhere. Another thing to check are the required language string for admin/moderator restrictions in ACP. There are a few more areas, but I can't remember them now.

None that I can think of without editing the code/database. I managed locally by temporarily altering the code to disable the json_decode line and saving the settings page. Updating the setting's default value in the DB and clearing the caches from ACP should work too.

Do note also that the message doesn't disappear automatically even if you fix the issue. If you disabled the function after you saw the message in ACP, you need to close it yourself. Also, if you want to double-check that the functions are indeed disabled, there is a phpinfo link on the support page. See what it says there rather than testing with an external phpino().

Yes, there are not such big tables based on your screenshot. You could also order them by their size by clicking on the table's header. In any case, it seems like your hosting is calculating wrongly the database size. Unless you have more databases on your account other than the forum one? P.S.: You might also want to switch your board_url to use HTTPS:

While the link is now visible, the suggested robots.txt file in the guide is outdated. For example: Profiles are not disallowed anymore The tags page is not included The cookie page is not included The embed controller is not included

You can't use the upgrader in ACP because you also need to change the PHP version for this particular upgrade. Try doing a manual upgrade instead: https://invisioncommunity.com/4guides/advanced-options/server-management/install-and-upgrade-r259/#manualupgrade

Don't. Simply don't. It will cause all kinds of issues. And if you enable IN_DEV mode on the dev forum, there's no way to know what will happen. If you want to have a dev forum, make a copy of both database and files.

The wrong JSON format also causes the manifest URL to throw an error on the front end.

The template parameters for "nexus > global > forms > businessAddress" are the following: $name, $value, $googleApiKey, $minimize=FALSE, $requireFullAddress=TRUE, $htmlId=NULLs, $vat=FALSE The $htmlId parameter wrongly uses NULLs (extra s at the end) instead of NULL.

After a fresh install, going to "ACP > System > SETTINGS > Web App" throws a TypeError: TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given (0) #0 path\to\system\Dispatcher\Controller.php(118): IPS\core\modules\admin\settings\_webapp->manage() #1 path\to\applications\core\modules\admin\settings\webapp.php(39): IPS\Dispatcher\_Controller->execute() #2 path\to\system\Dispatcher\Dispatcher.php(153): IPS\core\modules\admin\settings\_webapp->execute() #3 path\to\admin\index.php(13): IPS\_Dispatcher->run() #4 {main} The issue is this code: /* And finally, additional manifest and livetile details */ $manifestDetails = json_decode( \IPS\Settings::i()->manifest_details, TRUE ); $form->add( new \IPS\Helpers\Form\YesNo( 'configure_manifest', \count( $manifestDetails ) > 0, FALSE, array( 'togglesOn' => array( 'manifest_shortname', 'manifest_fullname', 'manifest_description', 'manifest_defaultapp', 'manifest_themecolor', 'manifest_bgcolor', 'manifest_display', 'manifest_custom_url_toggle' ), ) ) ); The problem is that $manifestDetails at this point is NULL because the json encoded data is wrongly using square brackets: ["cache_key":1692875360] Instead of curly brackets: {"cache_key":1692875360}

That is really strange. I think it's a problem with your language pack. 🤨 This is the message I get locally:

Maybe you could use multiple alerts that shows only to specific groups?

Looking at the code, there are 3 places the EasyPost Rates API is called: Testing the settings in ACP. Viewing a physical product's page (to figure out shipping rates/time) The shipping step in the checkout process. The code tries to retrieve the rates automatically only if you enabled the Allow Customer to Choose Rate? option in ACP. When this setting is enabled viewing a physical product makes 1 request to the rates API. If a member refreshes the page 10 times or views 10 separate physical products, without purchasing anything, that makes it 10 API requests with no purchase. This happens also when the page is being viewed by a bot. Maybe some bot aggressively indexed your site and caused all those requests? At the very least it should not execute the API call for bots, but I don't see any kind of block in the code right now. I think there should be a warning added for this. Maybe this was not something EasyPost did when the API was initially implemented into Invision Community. 🤷‍♂️

Adriano's file is still available in the new marketplace directory: https://www.invisioneer.org/files/file/200-choose-topic-embed-image/ I can't find the other 2.

No, it's not possible to make the field automatically fix the inserted value. You'd need a custom modification for that. I think it would be easier to simply enforce the full URLs and show an error that mentions the correct format if the regex returns an error.

Also, considering the database's size, I would never recommend doing the "optimization" from phpMyAdmin. I'd rather do it from SSH to avoid timeouts. As opentype already mentioned, it's probably time to change hosting. Your site is not a good fit for that limit.

You can compare your current address with the one listed in your Client Area. If the URL is different, you can reset it from the same client area page. Then remove the key from your ACP and re-enter it to update the URL. If the URL is the same, you'll have to wait for some IPS staff to check and confirm what is going on.

Did you add the license key to the site and then moved it somewhere else after? Like a different folder or (sub)domain?