Archives

Month: January 2019

Maybe it’s just the fresh trauma, but I think the M2 cert exam was much more difficult than my M1 Dev+. Many of the questions were basically ‘here’s some requirements, here are four different ways to fulfill them, pick which one is best’. I don’t think there was a single simple memorization question in the whole 60 question exam.

But at least I’m certified, I guess I somehow managed to accrue the recommended ‘1.5 years of Magento 2 experience’ in about 6 months by leveraging my M1 knowledge, architecting/leading an M1>M2 replatform, building some example modules, and studying my ass off.

I have a module built with over 700 multiple choice questions that I built to help me study, I’ll release that eventually for others aspiring to pass the cert.

Magento 2 upgrade scripts, as I see them written in basically every blog post I find and the Magento 2 docs, blindly upgrade as far as they can. What version you put in ./etc/module.xml before you run ./bin/magento setup:upgrade doesn’t matter. Here’s an example from the dev docs:

$context->getVersion() contains the current installed version of the module, version_compare sees if that is lower than 0.0.2, and if so, whatever upgrade operations exist in the next code block are run.Here’s where that causes problems:

– You’re developing, and need to test incremental upgrades.– Your upgrade script upgrades to version 0.0.2 and 0.0.3– You update ./etc/module.xml’s setup_version to 0.0.2, intending to only execute the 0.0.1 -> 0.0.2 upgrade– You run ./bin/magento setup:upgrade, and your module still ends up at version 0.0.3So, how do you get around it? No idea if this is ‘proper’, but it worked for me:– Inject a \Magento\Framework\Module\ModuleList

– use it to read the setup_version from the ./etc/module.xml file

– update your version testing code to ensure that current version is below the upgrade code version, AND that the upgrade code version is less than or equal to the setup_version in ./etc/module.xml.