Learn Refactoring to Framework Independent Code

I’m proud to annouce that I will present the Nomad Mage session of January 2017. Nomad Mage is the Magento offspring of Nomad PHP and describes itself as:

Nomad Mage® is a virtual user group for Magento developers who understand that they need to keep learning to grow professionally. We meet online monthly to hear some of the best speakers in the community share what they’ve learned.

My topic: “Keep Magento Out of Your Magento Extensions – Refactoring to Framework Independent Code”

To port an existing Magento 1 extension to Magento 2, it can be helpful to first extract the business logic into a reusable library. This also makes for more testable and future-proof code. But how can it be done?

On Nomad Mage I’m going to walk through real examples to show you how such a refactoring can be approached. Although we will focus on refactoring existing Magento 1 extensions, the patterns you will learn are also useful for new extensions, Magento 1 or Magento 2.

Continue reading “Learn Refactoring to Framework Independent Code”

Isolating Domain Logic in Magento Customizations

Lately I’ve been advocating decoupling business logic from the framework (i.e. Magento) a lot.

This has multiple advantages:

  • Benefit from test driven development (TDD) without having to mock a bunch of core classes.
  • Possible reuse in different applications (for example Magento 1 and Magento 2)
  • Having separated bounded contexts helps to view parts of the domain isolated and without distraction.

Even in chirurgic modifications that we often have to do in Magento projects, it is worth identifying the actual logic and extracting it from the actual Magento classes.

Let me demonstrate it with a real-world example:

Read more at integer-net.com

PHP: Using class_alias to maintain BC while moving/renaming classes

Sometimes you want to rename a class or move it to a different namespace. But as soon as it is used anywhere outside the package, this is breaking backwards compatibility and should not be done lightheartedly.

Luckily there is a way in PHP to have both, the old class and the new class, while deprecating the old one: class_alias().

How to use class_alias() without messing up class autoloading

Let’s say, the old class is OldClass and we want to rename it to NewClass.

First, we rename the class and move it from OldClass.php to a new file NewClass.php.
Continue reading “PHP: Using class_alias to maintain BC while moving/renaming classes”

Magento Theme Refactoring

A very common issue in 2014 was „I updated to Magento 1.8 and now my (login|cart) form is not working anymore”. The reason for this happening was that starting with Magento 1.8, the form key was used in more forms as a security feature (it prevents CSRF attacks). But any theme that had its own version of the according templates did not include the form key, so that the server side validation of the form silently failed.

Of course there are themes whose markups are so different from the default theme, that most templates are overridden with good reason. However I see at least as many themes, especially custom themes, where all templates were copied from base/default and then modified. There is almost no excuse to overwrite layout XML files because one can modify the layout in many ways with an additional theme specific local.xml file.

The issue mentioned above is a good example of the reasons for the „pay attention to updatability“ mantra. The errors could have been avoided if only files had been copied, that really required adjustment(s).

With this article I want to explain the process I’m following for theme refactoring (just the structural part, the HTML source will look exactly as before afterwards — except from changes in newer versions of the default templates).

Read more at integer-net.com