Magento2: Front-end is not working after 2.3.3 upgrade to 2.3.3-p1

[not-art]

Preconditions (*)

1. Upgrading from 2.3.3 to 2.3.3-p1
2. Installing via composer
3. Have 2.3.3 supplemental patches applied to your composer.json / in composer-patches (EG: EmailMessageInterface backward compatibility issue patch for Magento 2.3.3, Fixed method chaining contract for Product Collection patch for Magento 2.3.3, etc)
4. Using nginx / php-fpm
5. Local / on-site hosting, not cloud

Steps to reproduce (*)

1. Remove 2.3.3 supplemental patches from composer-patches / from composer.json
2. run composer require magento/product-enterprise-edition=2.3.3-p1 --no-update
3. run composer update
4. clear cache & run a setup:upgrade
5. Log into magento store front-end as a customer

Expected result (*)

1. Front-end should work as expected

Actual result (*)

1. php-fpm throws a fatal error, causing a 500 from our nginx controller

php-fpm: pool www: PHP Fatal error:  Uncaught Error: Cannot instantiate interface Magento\Framework\Filter\VariableResolverInterface in /var/www/html/magento2/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php:116
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 Stack trace:
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 #0 /var/www/html/magento2/vendor/magento/framework/ObjectManager/Factory/Compiled.php(108): Magento\Framework\ObjectManager\Factory\AbstractFactory->createObject('Magento\\Framewo...', Array)
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 #1 /var/www/html/magento2/vendor/magento/framework/ObjectManager/ObjectManager.php(70): Magento\Framework\ObjectManager\Factory\Compiled->create('Magento\\Framewo...')
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 #2 /var/www/html/magento2/vendor/magento/framework/Filter/Template.php(118): Magento\Framework\ObjectManager\ObjectManager->get('Magento\\Framewo...')
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 #3 /var/www/html/magento2/vendor/magento/module-email/Model/Template/Filter.php(234): Magento\Framework\Filter\Template->__construct(Object(Magento\Framework\Stdlib\StringUtils), Array, Array, NULL)
Feb 20 16:13:39 magento-7d4bc8ff7-4hd85 #4 /var/www/html/magento2/vendor/magento/module-widget/Model/Template/Filter.php(74): Magento\Email\Model\Te in /var/www/html/magento2/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 116

We've confirmed that our front-end works as intended when we test on 2.3.3. But once we apply the 2.3.3-p1 security patch, we can't get into our storefront.

Our best guess is that some code in 2.3.4 made it into 2.3.3-p1 that wasn't supposed to, so people still running 2.3.3 are having compilation errors from 2.3.4 changes being in the 2.3.3-p1 branch. Alternatively, we noticed the description, release date, and download link for 2.3.3-p1 on the tech resources/downloads page are referencing 2.3.2-p1. We had concerns perhaps 2.3.3-p1 was actually 2.3.2-p1, or had some code from 2.3.2-p1 left in it, as well.

But clearly something is breaking when we upgrade to 2.3.3-p1, which works as-intended on 2.3.3.

Could something from 2.3.4 have made it into 2.3.3-p1 that would be causing this front-end exception? None of our custom code touches the VariableResolverInterface or the Email Template Filter code. :/ Not sure why this would've stopped working on 2.3.3-p1...

Thanks in advance for any/all help!

[m2-assistant[bot]]

Hi @not-art. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@not-art do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[not-art]

Hello,

I think this is definitely related to the security patch not working, as the first change I saw in 2.3.3-p1 was in the main di.xml injecting a preference for VariableResolverInterface, which wasn't in 2.3.3. :( Did something not get properly patched in 2.3.3-p1, or did 2.3.4 functionality get added to 2.3.3-p1? :(

[hostep]

We are running 2.3.3-p1 on many shops without this issue, are you sure you did everything correct? Some more debugging and trying to figure out what goes wrong in your instance might prove useful here.

Can you double check if your app/etc/di.xml file contains this line:
<preference for="Magento\Framework\Filter\VariableResolverInterface" type="Magento\Framework\Filter\VariableResolver\StrategyResolver"/> ?

Because if that is the case, it should try to instantiate this Magento\Framework\Filter\VariableResolver\StrategyResolver class instead of the Magento\Framework\Filter\VariableResolverInterface class. And you shouldn't see that error.

[not-art]

Hi Hostep,

We've applied supplemental patches in 2.3.3 via composer in the past without issue, so we're confident we applied 2.3.3-p1 correctly, but I will check di.xml on the staging box having this issue and report back, thanks for the thread to pull to help us figure this out.

[hostep]

If you apply 2.3.3-p1 using composer patches (like we do), make sure you also patch the magento/magento2-base package. This one should contain the extra line in the app/ec/di.xml file (amongst a whole bunch of other changes).

[not-art]

Weird...

• I'm seeing magento/magento2-base versioned correctly for 2.3.3-p1.
• I've ran composer update, all packages appear updated to 2.3.3-p1 where applicable
• I've cleared cache and ran setup:di:compile

STILL not seeing a preference for VariableResolverInterface in my app/etc/di.xml. Hmmmm.

Gonna try a fresh install of 2.3.3-p1 locally, rather than running "composer update" on my require version-bump of 2.3.3, maybe my local composer cache is fubared or not downloading all required updates.

I'll report back- thanks for the help / suggestions, @hostep.

[not-art]

Well, adding that one preference line in worked. I have no clue why the composer update didn't update app/etc/di.xml; we've touched it manually to inject an aggregated logger we made- perhaps composer saw our changes and couldn't update the di.xml from our code messing with the version bump diff?

[hostep]

Hi @not-art, sorry for delay, was a bit busy yesterday.

Can you tell me exactly how you are installing 2.3.3-p1?
Previously you mentioned you were patching it on top of 2.3.3, is that statement still correct?

We've applied supplemental patches in 2.3.3 via composer in the past without issue, so we're confident we applied 2.3.3-p1 correctly

If yes, then make sure you are patching the magento/magento2-base module, that patch in particular should contain a lot of things, but one of them is:

diff --git a/app/etc/di.xml b/app/etc/di.xml
index 2863c5d..97ba819 100644
--- a/app/etc/di.xml
+++ b/app/etc/di.xml
@@ -1794,4 +1794,5 @@
                 type="Magento\Framework\Mail\MimeMessage" />
     <preference for="Magento\Framework\Mail\MimePartInterface"
                 type="Magento\Framework\Mail\MimePart" />
+    <preference for="Magento\Framework\Filter\VariableResolverInterface" type="Magento\Framework\Filter\VariableResolver\StrategyResolver"/>
 </config>
...

If you need a script to generate these patches, here's one I'm using: https://gist.github.com/hostep/55c7c5b02b40f8e102720da909a6413f

--

If however, you are not using patches and require the 2.3.3-p1 version directly using composer, then you shouldn't have the problem you are experiencing, unless something goes wrong in the marshalling of files from the vendor/magento/magento2-base/app/etc directory to the app/etc/ directory, which happens during the execution of composer install, but that failure can only happen when you have permission issues I believe.

[not-art]

We had rolled back the supplemental 2.3.3 patches before applying 2.3.3-p1, as they were included in 2.3.3-p1, so that shouldn't be an issue.

I did a folder compare using araxis for the downloaded codebase of 2.3.3 and 2.3.3-p1, and it appears the only thing missing from our upgrade was indeed the di.xml file's new preference. It's seeming like our manual touch of the di.xml might have prevented composer from updating the di.xml file, but why composer didn't complain about it while i was running update is a bit alarming. Either way, thanks for helping us figure out what was going on & we'll keep an eye out on our future composer-based patches to ensure our manual touching of core files is done via patches so as to not impact the composer patching process.