Upgrade from MAUTIC 4.4.10 --> 5.0.1 problem

Your software
My Mautic version is: 5.0.1
My PHP version is: 8.0.28
My Database type and version is: MySQL 8.0.35

Your problem
My problem is:
After upgrade from 4.4.10 → 5.0.1 I’m getting red offline error message (see screenshot below) in the browser along with the ‘parameter x must be defined’ error(s) when running commands such as (doctrine:migrations:migrate) via CLI.
I am currently running 4.4.10 again (restored from backup).

*Had no problem upgrading from 2 → 3 and from 3 → 4 with all the intermediate stable version upgrades.

These errors are showing in the log:

When running commands from like (e.g. doctrine:migrations:migrate OR mautic:clear:cache) get multiple but same errors:

In AppKernelProdContainer.php line xxxxx:

** The parameter “yyyyy” must be defined.**

Steps I have tried to fix the problem:

  • Tried moving local.php from app/config to config
  • Tried chmoding (755) and chowning directory for www-data as usual
    *Tried switching NGINX php-fpm from 8.0 to 8.1

Nothing worked.

Please share the logs from var/logs so we can help you figure out what’s going on. Thanks!

@rcheesley He did. Just boiled down to the relevant part. :slightly_smiling_face: (In fact, the log isn’t getting any more useful in this particular case)

The config migration messed up your config. If you search for parameter yyyy you’ll find it in your local.php under the mailer_dsn key. That’s causing the issue.

To get your backend running again:

  1. open local.php
  2. look for 'mailer_dsn' => 'mautic.transport.
  3. comment that out
  4. flush cache

Your backend should work now. BUT: Your email transport is not configured. You need to do that.

According to this:


And this:

Would it be a safe bet to assume that this issue has been resolved in the “freshly baked” version 5.0.2 ?

I’m kind of reluctant to try… :slight_smile:

Yes! I’m back in business!

To be fully transparent: I attempted to incorporate the proposed fix into my 5.0.1 installation, but it was still broken after I tried it. My day job is NOT in computer science, so I assumed it was a break based on my ignorance of the appropriate procedure. Now that 5.0.2 has been released, I tried again with it, and it worked for me. Specifically, my workflow was:

  1. Install Mautic 5.0.2.php bin/console doctrine:migration:status
  2. Upload my backed-up SQL into the appropriate database.
  3. Copy the 4.x configuration file (local.php) into the correct place for 5.0. Note that the directory location changed!
  4. php bin/console doctrine:migration:status ← to identify the need to migrate the db
  5. php bin/console doctrine:migration:migrate ← to actually migrate

and now I can log in and do all the things Mautic. Please note there are also cron job changes, and I haven’t fully addressed that just yet.

1 Like

So I noticed a 4.4.11 upgrade recently…
Performed the upgrade…
Upgrade from 4.4.10 to 4.4.11 went by smoothly it seems.
Now 5.0.2 is available again.
Should I take the risk and upgrade?

Just make a full backup of mautic (database + source) before.

That still doesn’t seem to work.
I am now on 5.0.2.
Still getting the red “offline” message.

How would I go about defining my amazon ses api transport in this?

I had a nightmare trying to get Amazon SES to work after an upgrade to 5.0.2

  1. The upgrade resulted in a broken setup due to the migrated mailer_dsn containing %…%, had to remove the mailer_dsn line from local.php
  2. I installed symfony/amazon-mailer, but it gave an unrecognised schema error in the config page. You need to install a specific version - “composer require symfony/amazon-mailer=5.3 -W”
  3. Pasting in the password to the email config page leaves the cute little lock emoji in the field by default, resulting in the wrong password being saved. Make sure you clear the lock (why is not a placeholder attribute?)

Anyway, I now have Mautic 5.0.2 running with Amazon SES, but it seemed to be much harder than it needed to be

But does this symfony amazon mailer properly handle bulk sending. There is a reason why mautic has dedicated transports to integrate with different email providers and its because using default mailer packages makes separate request to an api for each message.

For our usage I expect the standard symfony Amazon SES integration with an API call per message will be performant enough (We can always look to move to a queuing later if needed).

For others moving to the new mailer integration in Mautic 5 may be more of an issue. We just wanted it to be able to work at all :slight_smile: