teraßyte

PHP 8.2 is not supported, and the upgrade script from 3.1 was never really tested using PHP 8. Even the 3.4 version was barely tested with it. Downgrade PHP to version 8.0 and try again. You'll still get a few errors most likely, but far less than using an unsupported PHP 8.2 version at least.

You can find the SVG files inside this XML file in your ZIP: \applications\core\data\achievements\ranks.xml In the same folder, you can also find the Badges in badges.xml. Both files have the images encoded with base_64.

Version 4.7.14 adds 1 new setting and removes 2 others: { "added": [ "x_hashtag" ], "edited": [], "removed": [ "mp_onboard_complete", "twitter_hashtag" ] } The mp_onboard_complete setting is removed in the \applications\core\setup\upg_107720\queries.json file: "8": { "method": "delete", "params": [ "core_sys_conf_settings", [ "conf_app=? AND conf_key=?", "core", "mp_onboard_complete" ] ] }, The twitter_hashtag setting is instead left so that the upgrade.php script in the same folder can copy the value into the new x_hashtag one (step2). However, once the copy is done, the old twitter_hashtag setting is not deleted from the database.

On a fresh install, both Twitter and X share links are inserted in the core_share_links table. This happens because the file \applications\core\data\schema.json was updated in 4.7.14 to insert a new row (ID 10), but the old one (ID 0) was not removed: "inserts": { "0": { "share_id": 1, "share_title": "Twitter", "share_key": "twitter", "share_enabled": 1, "share_position": 1, "share_groups": "*" }, [...] "10": { "share_id": "13", "share_title": "X", "share_key": "x", "share_enabled": "1", "share_position": "13", "share_canonical": "1", "share_groups": "*", "share_autoshare": "0" } },

In the latest 4.7.14 version, the template core > front > global > siteSocialProfiles was changed to add support for X (former Twitter) share link, but the <LI> element was mistakenly changed to an <A> element instead. 4.7.13 version: <li class='cUserNav_icon'> 4.7.14 version: <a class='cUserNav_icon'> You can easily compare it in the Theme Differences tool, too: https://invisioncommunity.com/index.php?app=core&module=system&controller=plugins&do=diff

Ah, yes. If the forum is in a folder the .htaccess above won't work (the one he posted didn't have a folder, either). It's best if you download the file again directly from the ACP.

What kind of custom changes exactly? It's possible that IPS simply applied patches for bugs they investigated, which aren't exactly "custom changes". However, based on Jim's reply, rather than IPS doing something for you, it seems you hired a 3rd party provider.

Is there some kind of error code, file, or row number together with that error? With just that alone, it's hard to understand where the issue could be.

You're missing a couple of rows. The latest .htaccess for 4.7 is this one: <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> Re-download the file from your ACP, or use paste the content above in it.

The tables look fine. Just to double-check, is the warning message in ACP the same as before? The warning might have changed from the tables being MyISAM to the InnoDB tables using a COMPACT row format instead of DYNAMIC.

Does it work in incognito mode or with another browser? Sometimes Chrome is too aggressive in caching pages, and it might have cached that error page.

Some language keys are empty on purpose. They're needed because the framework expects them to exist and would throw errors while developing otherwise. If you find an empty string just ignore it. 🙂

At the end, the upgrade tries to fix any wrong or missing columns/indexes in the database. To avoid the error be sure that your tables are all InnoDB and with a DYNAMIC row format.

@Trevor Carey I offer a cleanup service if you're unsure and don't want to proceed by yourself. Contact me if you're interested. 🙂

The support page will show an error and list any edited files, but from the screenshot you sent me there are no edited files.

Yes, this was a bug they fixed in 4.7.12. The fix for it was in the globalTemplate template, which is one of the most edited. You're missing that change most likely.

Yes, theme updates count, and most likely the size is the problem. The marketplace allows files up to 2 MB. That file is at least 8 times larger. Your server doesn't have enough time to process the entire file. Usually, I would simply suggest asking your hosting to raise the timeout value, but given the size, I'm also curious as to what application you're trying to upload. Maybe you could also look into reducing the TAR's size by asking the developer if it's possible.

Yes, that. However, the console is showing a generic 500 error, so you need to check your server's logs to find out the real error.

Yes, it's possible to create a private page for moderators only if you have the Pages application. Simply select only the Moderators group after creating the page. Or you can edit a current page's permissions by clicking on the Menu and then the Lock icon. No, the only place you can add a link is the menu by using the Menu Manager. If you want a link on the ModCP page, you'll have to edit the template or have someone make a quick plugin for you. (Using a plugin allows the templates to auto-update in future versions)

Steps to reproduce: Setup an RSS Feed Import for a Pages database and enter a value in the Title Prefix field. Check the imported feed items and you'll see the prefix is missing. If you setup the same feed to import into a forum instead, the title prefix is properly used.

That doesn't tell much, unfortunately. Try looking at your browser's console, there should be a more specific error logged there.

How big is the TAR file you're uploading? Have you tried installing any other applications or plugins? A timeout error means the server didn't have enough time to process it. I can think of various possibilities: The TAR file is too big The TAR file is corrupt or badly formatted (maybe it wasn't exported correctly or the install files aren't correct) Your server's timeout value is too low (you said installing from the marketplace works, so this is unlikely)

Check your conf_global.php file and be sure the ibf_ prefix is properly set: <?php $INFO = array ( [...] 'sql_tbl_prefix' => 'ibf_', [...] );

Just to confirm, when you look at the database on the old VPS, is the table also missing there? Or maybe it's marked as crashed? If it is, I can't see how the forum was working without it. That said, you're lucky because the table in the error doesn't hold any permanent data, but only temporary caches that can be recreated. You can recreate the table manually on the new server by running this query: CREATE TABLE `core_store` ( `store_key` varchar(150) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Key', `store_value` longblob DEFAULT NULL COMMENT 'Value', PRIMARY KEY (`store_key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; If your tables use a different collation be sure to change "utf8mb4 / utf8mb4_unicode_ci" to whatever other collation the database is using. The only problem now is to understand if this is the only missing table, or if there are others. 🤷‍♂️

Indeed, you're missing a table. Looks like the database wasn't restored properly.