coert_g

Yeah, we've been trying to update for years now, but there's always an issue like this in the process so we've fallen far behind in the updates. I appreciate your help though... When I look at an overview of the DB tables, I see that some of the tables have been converted correctly, and it seems to stop at the table cms_custom_database_5 - do you mind taking a look there and seeing if there's anything that stands out. I'm assuming that's the table that's having the problem if the converter is running alphabetically down the tables. Would I be correct in assuming that it's likely one of the VARCHAR columns within that table? It's really imperative we get through this update process 🙃

Details are shared in the notes of the client area.

Please let me know how to share the database logins with you. In the client area, I only see options for FTP and Admin logins, I'm connecting with MariaDB using Adminer. Shall I drop you a PM? Or am I missing something in the client area?

I've checked the database settings and all row formats are Dynamic, and they're all using the InnoDB engine.

Unfortunately, using the conversion tool doesn't seem to work for our database. I got the following error when trying to convert: I reached out to our hosts and they gave me the following response: Can you please advise?

I ran all queries through SSH now, but same problem. The database is in utf8mb3 though, not utf8mb4. Would you recommend that I update the tables to utf8mb4?

Thanks for following up. Yup, we've only got one database, and several of the queries successfully made changes to the tables they're targeting. Some weren't able to be run through Adminer (Using MariaDB) due to timeout problems but were run via SSH.

I managed to eventually get past the 500 errors in the installation process, but now I'm stuck in a loop where it's asking me to make manual changes to the MYSQL. I've gone through the process of running every line as required. I've triple-checked to make sure I didn't miss any. But when I click the "I have run the queries manually and confirm they were run successfully" button, the installer refreshes and shows the same manual commands to run.

Please advise how I can get this error to you. I've looked at the error log and the error isn't being logged in the file.

Been struggling to update my IBP install for ages now and none of the support so far has been able to address the problem. When I try to do an automatic upgrade, I get an error about the PHP version needing to update. But when I update the PHP version, the entire site crashes and returns 500 errors on every page including the admin. To try and get around this, I tried to do a manual upgrade by changing to PHP 8.1 and then copying the new files to the server. However, after doing so if I go to domain.com/admin/upgrade - the upgrade process starts and then immediately returns another 500 error and cannot proceed. I've looked at the error logs and prior to the manual update attempt there were references to the theme.php, however, no new errors are being logged during these crashes. I've tried just about everything and cannot get our site to upgrade, we're now massively behind in updates because of this.

Thank you - this occurred across multiple devices and had the issue on both mobile and desktop. And each time I attempted to log in, I would note those two errors being logged as new errors in the log. As though it was looking for something to parse the sign-in process but didn't find it. That said, I have tried again with an incognito browser tab and that seems to allow logins now. I've asked our community to let me know of any bugs that may appear. Thanks for your assistance.

We've tried clearing the cache several times with no success. Can you advise which errors these are - as I believe this is the basis for the browser error. This is directly from the IPB error logs: This is what our hosts say they don't understand because they don't know the IPB codes and what this is detailing. I'm looking to understand what IPB is saying with these errors.

As mentioned, that was the first line of communication, but according to them the rollback and restore were a success - and they say I need to speak to you guys, cause according to them it's a software issue. Could you advise what it occurring for you to deem it as a hosting issue? So I can address it with them...

I had previously mentioned in the support forums this week that I was attempting to update our CMS, where I encountered issues, including a database table being dropped. This resulted in us having to roll back the update process. Our hosts (Opalstack) rolled back the server files and the database to just before the update, and while it brought the site back - it is experiencing a few issues I'm hoping you can help us resolve. We already spoke with Opalstack, but they aren't familiar with the IPB codes. The primary issue is an inability to log in. When any user attempts to log in to the front end, it gives an error: I suspect it's related to these errors I'm seeing in the error logs. Could someone please assist? This was done on a live site, so our site is currently inaccessible.

The table is missing from the database, but I have no easy way to restore the table other than asking our host to roll back everything and lose another day of work in pursuing what is supposed to be a simple CMS update. If I restore our database (which is also extremely large), I'll inadvertently remove all the database changes that were just done when upgrading to the latest release. It feels like each time we perform an upgrade it's like pulling teeth, to the point where we've neglected the process solely because we know what it ends up being like. Before I ask our host to roll it back and abandon the idea of upgrading again, is there no other way to resolve this? Or a way to have a less painful upgrade process. It feels almost easier and more affordable to migrate an entire site to another CMS that it is to update the CMS itself ://