teraßyte

Yes, version 4.5 doesn't support PHP 8 so you can't use the automatic upgrade process from your ACP. You need to perform a manual one: Disable all 3rd party applications & plugins. Switch to a default non-customized IPS theme. Switch your server to PHP 8. Manually upload the files of the new version from your client area (currently 4.7.6) to your server. Visit the url domain.com/admin/upgrade to perform a manual upgrade. After the upgrade is done check if any 3rd party modifications require an update (there's a button to manually check in the applications page). After you apply the updates you can safely re-enable those modifications. Go to your Support Page in ACP and fix any remaining issues listed on the page. If you still have disabled applications and/or plugins after the above steps, re-enable them 1 by 1 to make sure they are compatible with PHP 8.

Try using this query instead (replace DBNAME as needed): SELECT CONCAT('ALTER TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ' ENGINE=InnoDB ROW_FORMAT=DYNAMIC;') FROM information_schema.TABLES WHERE TABLE_SCHEMA='DBNAME' AND ENGINE = 'MyISAM'; This query doesn't check the table type and also forces the tables to use the DYNAMIC row format (in case your server defaults to Compact). I always use it and once I run all the queries the ACP never complains about tables still being MyISAM.

Looks like you have the converter application installed but didn't upload the updated files for it. When downloading the zip from your client area there is a checkbox you need to select in order to include the Convert application in the download. Re-download the zip with the checkbox selected and then upload again the files to your server. Once you do that the errors should all go away.

The buttons are displayed based on the width available. When editing a post the editor's width is smaller compared to the one at the bottom of the page to post a new reply and it ends up using the buttons setup for the Medium size.

While IPS can (and should) make more buttons available by default you can change which ones appear there by editing them in ACP > Customization > EDITOR > Toolbars > Medium TAB. Just drag & drop the ones you want/need. And have a look also at the Small TAB too just in case.

I have not used the plugin myself so I'm not 100% sure but, based on the information the developer added in the Additional Information TAB (on how to add it to Pages databases), I believe it uses Javascript to remove the empty lines after the page is loaded. If I am correct it means the post is saved as-is and simply altered to look different after it's loaded in the user's browser. If you disable the plugin the posts will display again the extra lines. In this case a plugin that removes the extra empty lines at the end before saving would probably be better. It needs to be coded from scratch though.

Since this is a Samsung bug IPS can't really do much about it. Your only solution until they fix the issue on their side would be to use this plugin: The plugin doesn't remove only empty rows at the start and end of the post, but also in between paragraphs though.

The database checker checks only tables in the applications schema.json files. Any extra tables not in there are skipped. And all the utf8_unicode_ci tables in your screenshots are old/unused tables the upgrade process failed to drop. Or probably tables from old modifications that weren't removed properly (like the ipb_jlogica_XXX tables). The 2 tables marked in your second screenshot by that red rectangle are 3.x tables that are not present in 4.x, you can safely delete them.

Yeah, the /cache folder is not used anymore in 4.x. Deleting it before the upgrade shouldn't cause any issues. Everything seems ok in the config file, too. It doesn't matter when you remove the xcache line because 4.x doesn't support it anymore so the value isn't even checked to begin with.

That page might not show if a table is crashed. The best way would be to check from phpMyAdmin (or a similar script) and eventually run also a REPAIR on all tables just in case. If everything is okay nothing will change, if something's broken with the files it will tell you exactly what.

If the upgrader was trying to load a table that doesn't exist the error would be different (Something like "Table XXX doesn't exist"). That error is instead telling you that whatever table the upgrader is trying to load exists in your database, but the file for it on your server doesn't exist. It could also be that the table is crashed and needs to be repaired. Anyway, I usually never see such errors when I do legacy upgrades from 3.4. This makes me think your database (or mysql server) already had some errors before the upgrade even started. With all your posts so far the situation looks really bad. I suggest you restore a backup, double-check all tables are working (nothing crashed, etc.) and then restart the upgrade from scratch. === EDIT I had a look at the code since your error includes the file and line: \IPS\Db::i()->renameTable( 'members', 'core_members' ); It is actually failing when trying to rename the members table to core_members. So yes, you indeed have some kind of error with the members table in your 3.4 database. Some possible issues that come to mind: The table is crashed and you need to repair it. The table is locked / can't be accessed because your server has run out of space. (I actually hit this issue in a recent upgrade.) For whatever reason the table's file was deleted directly from the server (rather than deleting the the table from the database) and that's why you're getting that error.

The issue will still be there even for the next update since it's in your current version. If you're unable to get past that step, no matter how many versions you skip/wait it won't change. Because the new files aren't downloaded at that point yet. If you're uncomfortable doing the manual upgrade yourself maybe you can get someone else to do it for you? Manual upgrades are easy enough as long as you know what you're doing. I do them often myself.

The only way would be to make the user bypass the paywall if their UserAgent is from Google. But then everyone would be able to bypass it just changing their UA. Not to mention that Google penalizes sites that show different content to them compared to a normal guest.

Here's a link to the guide, just look at the Manual Upgrade section:

Yes. As long as the conversion is already complete deleting the XF folder shouldn't be a problem. The background tasks only need to rebuild/resync everything but they won't need anything from the XF folder itself.

The user is probably hitting the Total maximum storage limit setup for their group. Let's say you limit a group to upload 10 MB and the user uploads 6 files large 1.5 MB each (for a total of 9MB). At this point the attachment field would show that your upload limit is 1 MB instead of 2 MB (because you've already used up 9 out of 10 MB available for the account).

Hmm, the code is basically trying to remove any birthday widgets and the table should already be there in theory since the core application upgrade is done. For now you can just open the file \applications\calendar\setup\upg_107305\upgrade.php and comment or remove this code on line 33: \IPS\Widget::deprecateWidget('todaysBirthdays', 'calendar'); As an aside, keep going with the upgrade until the end and once you're done I suggest you immediately restore a backup and redo the upgrade from scratch with all the fixes you've added so far already included.

Looks like the widgets table is not available but the code is trying to load it. Can you take a screenshot just like the one above about the "Unfinished Upgrade"? That way we can see which step is throwing it.

@Adriano Faria That's what I thought initially, but then I looked again at his other screenshot: It's worth a try anyway. Actually, scratch that. Taking a look again at the previous screenshot the issue there is with array_map() rather than array_keys(). They keys related one must be something else because the upgrade is not complete yet. The only possible array_map() culprit in that upgrade file is on lines 236~239, it's the code that converts the image metadata from serialized to json format: if( $row['image_metadata'] ) { $imageUpdate['image_metadata'] = json_encode( array_map( 'trim', unserialize( $row['image_metadata'] ) ) ); } The unserialize() function can indeed return a BOOL (false) value and the code is not accounting for that: Try replacing the code above with this instead: if( $row['image_metadata'] ) { $tmpMeta = unserialize( $row['image_metadata'] ); if( $tmpMeta === FALSE ) { $tmpMeta = array(); } $imageUpdate['image_metadata'] = json_encode( array_map( 'trim', $tmpMeta ) ); } Should be easy enough for IPS to add a fix in a future version even if they don't exactly support anymore upgrades from 3.x.

Removing the /hooks folder won't change anything since the 4.x code doesn't even load the files inside it. That error is most likely from when you switched to PHP 8, but before uploading the files/running the upgrade. That last screenshot indicates that the upgrade is stuck on a step for the gallery application (version 60000) so I initially thought the error must be coming from the file: \applications\gallery\setup\upg_60000\upgrade.php. After taking a look there is no such reference to any array_keys() call in there though. Rather there is no such call at all in the whole \applications\gallery\setup folder. The error must be coming from some other file/function since it's also showing up when you try to access the ACP. If you don't have a more complete error to look at, the only solution left would be to manually add debug code and find where exactly the code is throwing the error. While it looks like a bug, it's a bug from a 3.x upgrade so not sure if IPS would be able to help and take a look at it themselves. 🙄

Yeah, upgrading from 3.x can be as smooth as usual or tricky as hell depending on how many modifications were installed before the upgrade. When I do a legacy upgrade I usually uninstall as many modifications as possible beforehand. (As long as the client doesn't plan to upgrade them for 4.x.) I've had issues with Tapatalk before, mainly because their code is well...let's just skip what I think of it. 😋 That error doesn't really help much though. There no file or line. You should probably have a more complete(?) error logged on the server.

Here's also a screenshot of what I'm seeing in case it's some kind of permission issue:

As per title, downloads embeds are wrongly stating free files are not available for purchase. I noticed the issue when someone posted this link: You can see for yourself the embed says This file is not currently available for purchase. in the row under the version/number of downloads. The file is free and certainly available for download though.

Since you mentioned a live topic, can't you simply add a rule to exclude that specific topic/url and still cache everything else for guests?