Here are some quick tips on migrating code/mindset from 1.x to 2.x.
You actually shouldn’t do as I say btw. You should go read all about Gof, SOLID, DI Rocks, else is bad theory, and every other design pattern book/principle you can find.
And when you get back to reality just re-read this.
Seems to be some confusion here as to whether $ is used or $_ for protected. I’ve gone for $ for all, removing the underscore (as per a github post I saw). Problem is that if I extend a Magento core class then I’m forced back down the $_ route.
Basically be prepared to inject every single thing. Any calls to external objects go in here instead. You can shortcut a bit by finding in Magento code, then using PHPStorm to set the declaration and global variable (cmd-b).
So thats everything, all your references. Just put it in a constructor.
Currently I’m seeing 2 types of classes defined in Constructors:
- Standard definitions of classes that are used to invoke some form of business logic, e.g. a tax calculation model where we request tax details
- Factory definitions where we create the object during runtime e.g. creating a shipping rate
There is also a proxy definition, I’ve not come across yet.
All replaced with using the DI entities. E.g. $this->addressConfig->foo() instead of Mage::getModel(sales/quote_address)->foo()
SQL Install & Migrations
Under setup there is now just one InstallSchema with potential for just one UpgradeSchema.php file. No more migrations per version, you need to keep updating the same UpgradeSchema file. What seems to be important to me is that its idempotent. As you can see from this Magento UpgradeSchema you may need to do version checking.
InstallData.php and Setup scripts are also present. I’ve not yet used these.
So far I’ve determined that Factories are autogenerated. So if you want to dymically create an object at runtime you can take the model class, add Factory on the end and then put in your constructor. You then call create() on this within your method.
then further down:
$error = $this->rateErrorFactory->create();
Observers and Interceptors (Plugins)
I’m internally using the word Interceptor to mean Plugins, as logically it makes more sense to me. When I think of a policeman I think of him standing at the side of the road observing the traffic. Then I see him intercepting when someone breaks the speed limit.
Very similar concept in Magento 2. Observers observe, so they have no direct impact on the flow. Interceptors intercept, so they can alter the behaviour/flow. In Magento 1.x these were called rewrites.
There are before/after/around Plugins. Vaguely is adhering to AOP principles, why they didn’t just go the whole hog I’m not sure.
There is an order to plugins loading, not gone into this yet.
You can create a plugin on a particular method (any method invoked by the object manager) so its much more granular then the class rewrites in 1.x.
Here is a table of quick migration hints
Have Magento 1.x open in 1 window. Lets say you can’t see how to do something in Magento 2.x. Go find in the core code on 1.x that method/type of call/etc. And then find the block of code in Magento 2 that does this same logic. This will tell you how to implement it.
Doesn’t always work but handy when it does.
Search for a file obsolete_methods.php. It tells you which methods have disappeared and sometimes it tells you what replaced them!