Outstanding queries after upgrading Mautic 4.3.0 and later

Your software
My Mautic version is: 4.2.2
My PHP version is: 7.4.x
My Database type and version is: MariaDB 10.x.x

As mentioned in this post and elsewhere: Outstanding queries after upgrade to 4.4.5

I am seeing outstanding queries reported when running Mautic updates from 4.3.0 onwards. I tested this on a local install. Although the updates always complete - all migrations are completed - the same outstanding queries are listed when running:

console doctrine:schema:update --dump-sql

Can we therefore assume that it is the schema report mechanism that is buggy and that the Mautic upgrades have completed successfully? Running the queries manually through phpMyAdmin proves that the queries reported are false.

If this is the case then can we please acknowledge this bug so people are not wasting their time trying to fix a non-existent fault with their database every time they update?

Or am I using an outdated upgrade method?

I have the same problem.

Here is a thread connected to this:

Thanks @joeyk

So my main takeaway from your thread is that if you stick with Mautic long enough you will end up having upgrade issues that are ‘kicked under the carpet’. What then is the alternative? Is it possible to do a clean install then import data from a previous install?

@plato39 : I’m not sure what feelings are connected to your message, since you didn’t use any emojies. One of the disadvantiges of the internet.

You could say indeed

If you stick with Mautic long enough you will end up having upgrade issues that are ‘kicked under the carpet’

On the other hand, if you are with Mautic since 2.xx, it means you have overcome tremendous issues possible with the help of the community, you educated yourself about mysql, php, basic admin stuff. You can upgrade mysql, php, tweak php settings, and most likely apply PRs. You can singlehandedly fix email template bugs. You are a master of managing mysqldumps, zipping directories and restoring Mautic.

If you started with Mautic 3.xx, you are familiar with command line as well, you understand how Mautic’s local.php works, you can backup and restore. You understand file ownership, can rebuild the cache with ease. You learned and struggled with MJML.

If Version 4 is your first encounter, you probably have very minimal issues with upgrades, apart from learning - never upgrade before others and keep reading the forums.

Mautic 5 will present new challenges, you can’t postpone playing with composer 2.

I think this upgrade issue won’t be kicked under the carpet, once the focus is less on Mautic 5 tests and migrations, someone with coding knowledge will chime in. Once that happens, we can turn it into a how-to knowledgebase article.

I’m a big fan of the show called This is Us. I love this quote:

And I can totally apply it here.

Yes I’ve been through all of the above. However most people who are running a business don’t have time to make lemonade.

I guess then they just have to pay for it. :slight_smile: The good news is: it’s getting simpler every update.

If anyone is interested in the answer to my original question:

Can we therefore assume that it is the schema report mechanism that is buggy and that the Mautic upgrades have completed successfully? Running the queries manually through phpMyAdmin proves that the queries reported are false.

The answer is yes.

I upgraded my production install to 4.4.7 and after a few days extensive testing can find no errors.

The latest upgrade broke my install:

mautic.team9227.com redirected you too many times.

All stages (via GUI) seemed to work fine, apart from the last clear cookies which seemed to hang.

Hi, are you using a container?

No. Straight install under Ubuntu/Apache. As Vanilla as you can get.

Given my lack of skills I think it’s likely to be a reinstall for me.

What happens if you add this to the first line of index.php right after <?php

$_SERVER[‘HTTPS’] = ‘on’;

That fixes it. Crazy. Thank you!

Whilst the server is vanilla, the environment is not. I run everything through Cloudflare (https:// forced) and an HA proxy which tends to just connect to the back end via http and talk to cloudflare via https: