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.
So… here’s a ‘neat’ Magento 2 install script ‘feature’:
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.3
So, 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.