MailMimeParser broken after upgrade to PHP 7.4

[jflores]

I'm updating everything to prepare for the upgrade to version 7.0. I'm currently on Espo 5.9.4

As part of the upgrade, I upgraded PHP 7.2 to 7.4 and I thought everything was working fine...until it seemed like we weren't getting emails anymore.

Turns out...we weren't. And this is what the log says. I'm assuming it's a PHP error, but maybe not?

Espo.ERROR: InboundEmail 5e4344684a6edd9fb (Get Message w/ parser MailMimeParser): [0] NoRewindIterator::__construct(): Argument #1 ($iterator) must be of type Iterator, SplFixedArray given [] []

I'll be upgrading to 7.0 within a few days, but can't go that long w/o email in the system. How can I fix this quickly?

UPDATE:
So, turns out we haven't receive any emails in our system for about 3 days, when we started updating things. What's confusing is that the email logs in the Admin say "Success" for every email poll AND the error message in the logs is somewhat sporadic. It's not triggering nearly as frequently as our emails are being checked. But still, no emails are coming in at all...

UPDATE #2:
I tried to start upgrading en route to 7.0 to see if that would fix the errors.

It got worse.

When I started running the command php command.php upgrade, I got this error:

swp@swp-espo-production:/var/www/hub$ php command.php upgrade
PHP Fatal error: Declaration of PDO::Prepare(string $query, array $options = []) must be compatible with Doctrine\DBAL\Driver\Connection:Prepare($prepareString) in /var/www/hub/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 0

To try and solve this, I downloaded the 5.9.4 zip file, removed the vendor files on my server and did an SFTP upload of vendor files from the 'clean' 5.4.9 install. The error is still there...

I also tried to upload the upgrade package via the UI and the error I got was that this needed to be run from the command line.

So...now email doesn't work AND I can't start upgrading...

[Vadym]

Hi jflores,

I tested upgrading from EspoCRM 5.9.4 version with PHP 7.4.3 version. The instance has been updated.
Maybe you should try to upgrade manually:
https://docs.espocrm.com/administrat...ading-manually

[jflores]

Hi there - Thanks for the reference! Unfortunately, I can't even rebuild at the moment (step 1) because I get the "PHP Fatal error" error from above when I try to run rebuild. Evidently my instance is somehow faulty, but unfortunately, I'm not 100% sure where to even begin to solve this problem.

Thankfully, I have daily DB backups, so I'm not worried about losing data, but am a little nervous about a "clean" install b/c we have a ton of customizations...

What's weird is that I have two other Espo instances on this server that are working just fine. They upgrade just fine (they're both on 6.1) and the rebuild works just fine...there's just something screwy about this one...

[yuri]

Might be you have some files customized or not being deleted during upgrade. Try to download the fresh instance from Github (of your version) and replace all 'application' folder except application/Espo/Modules folder.

[jflores]

yuri Thanks for the pointer! I ran a diff against the production application folder and the 'fresh' 5.9.4 application folder. There were no differences, except the production has the "Advanced" module and the application/.../default/config.php on production has a version '5.9.1' instead of '5.9.4'. My production config.php has the correct version, though...

[yuri]

Maybe your CLI PHP version is not 7.4?

[jflores]

So, it turns out that you're right...my CLI PHP is version 8, but the apache server is running v 7.4.2 (which also what my local install is running). From what I've read, the CLI & Apache can use different versions and it _shouldn't_ break anything on the webserver side. Maybe that's not the case?

In either case, I ran the 'diff' on the whole application and found a few modifications I had made in the client some time back (like adding Google Tag Manager, referencing a custom view for the portal), but that shouldn't impact doctrine/dbal or the MIME/emails, right? Aren't those just backend functions?

[telecastg]

Hi jflores

In my opinion, you should forget about step "updating" Espo in stages and just go for the latest version in a fresh new install since you have DB backups and have the necessary programming skills to update your instance without the need for packaged scripts.

We have a lot of customizations as well, so what I did was to download an xampp instance (I chose one with PHP 8 but you can also download one with PHP 7.4) to play locally and installed Espo 7.0.3 there.(I have previously described this process here: https://forum.espocrm.com/forum/inst...1187#post61187 )

After testing that everything was working fine, I copied our custom module folders (we do not like to dump everything in the generic Custom namespace, we use modules to be able to isolate functionalities and problems as in this instance) and then ran the cli command php preload.php as recommended here: https://forum.espocrm.com/forum/inst...ions#post75236

This will display errors caused by deprecated function calls so you can iron them out one by one. I posted solutions to some that I found so far in our installation here: https://forum.espocrm.com/forum/inst...-with-espo-7-x

I have not finished ironing out all the kinks because of the scope of our customizations and the extensive changes in the latest upgrade but now I have a clean install that will be able to transfer to our production server with confidence once everything is working normally.

Update: I forgot to mention that since you are starting from Espo 5.9.4 you will also need to check for errors in custom scripts resulting from the upgrade to 6.x, here's a link for that too: https://forum.espocrm.com/forum/deve...-with-espo-6-0

[jflores]

telecastg Thank you so much for these super helpful resources! I was a little afraid that I'd have to do a clean install and a ton of refactoring to upgrade to version 7. This affirms that notion and I've started the process already, though a bit earlier than I wanted to. What started out as me trying to figure out why emails aren't coming in anymore has turned into a much more involved initiative than I expected... :-}

The other thing I noticed (though say in some other documenation - and I'm mentioning for posterity) is to make sure that the db is upgraded from MyISAM to InnoDB. I had several tables that were breaking - even locally - and this turned out to be the reason why. I had forgotten that v6 had dropped support for that...

[telecastg]

I'm glad to be able to help and thanks for mentioning the db upgrade, these are things that are easy to miss and can really throw us off when updating.