Posted on

Design Patterns for Framework Agnostic Extensions/Plugins

My new article series on integer-net.com introduces useful design patterns for decoupled Magento extensions, which are divided in two parts: the Magento module and a framework independent (framework agnostic) library, that is reusable for Magento 1 and Magento 2. Of course, the same principles can also be applied to other frameworks and applications.

Diagram of Magento 2 Extension Dependencies for Framework Agnostic Modules

It will not cover the refactoring process from existing extensions to this model, that’s a different topic and I am going to talk about it at Developers Paradise 2016 in Croatia. Stay tuned!

The first part is about accessing application configuration, using Configuration Value Objects.

Continue reading on integer-net.com →

Posted on

Use Feature Toggles in Magento

Today, Joshua Warren asked an interesting question on Twitter:

I had thought about the topic earlier and if some genereric feature flag module would be worth developing. My conclusion was that it was too trivial in the end and I would just build feature toggles as needed for the respective project.

Feature Toggles: What and Why?

Feature toggles are a way to roll out partially developed features and keep them disabled in production, so it is often mentioned in the context of continuous delivery. They support the “ship early and often” paradigm and decouple code deployment from feature activation.

But feature toggles (or “feature flags”) also can be used to roll out new features gradually, for example only for a certain customer group, based on user location, or for randomly selected users, as with A/B testing.
Continue reading “Use Feature Toggles in Magento”

Posted on

EcomDev PHPUnit Tip #13

For years, the test framework EcomDev_PHPUnit is quasi-standard for Magento unit tests. The current version is 0.3.7 and last state of official documentation is version 0.2.0 – since then, much has changed which you have to search yourself in code and GitHub issues. This series shall collect practical usage tips.

Tip #13: Speed up EAV fixtures

If you use the EAV fixtures to create products, categories and customers for tests, the fixture processor or EcomDev_PHPUnit makes a backup of the according tables before each test and restores it afterwards. Since the “magento_unit_tests” test database is copied from the current Magento database by default, this can result in much unnecessary overhead.

We can speed up tests that run several minutes many times over, by cleaning up the EAV tables in the test database. To do so, delete all rows in the entity main tables of the test DB, the associated attributes etc. are deleted automatically with triggers. With one exception: Do not delete the default root category:

delete from catalog_product_entity;
delete from catalog_category_entity where entity_id > 2;
delete from customer_entity;
Posted on

Show random products in Magento: You are doing it wrong

Well, probably (I certainly have).

A typical requirement is to show random products on the home page, random products of a category on the category page, or similar. Magento offers a simple block that can show a specified number of random products, Mage_Catalog_Block_Product_List_Random. To add filtering, like by category, you still need to write your own block, but it could easily be extended.

This is the CMS code:

{{block type="catalog/product_list_random" num_products="4"}}

But don’t get too excited. This block type will make your site slow, you should not use it. The problem is in this line:

$collection->getSelect()->order('rand()');

I’ve been recently advocating against using ORDER BY RAND() to select random products from a Magento database. 1 Generally, this method is discouraged because of its performance issues.

Continue reading “Show random products in Magento: You are doing it wrong”

Notes:

  1. For example in this Magento StackExchange post: Four Random Products on Homepage ↩
Posted on

EcomDev PHPUnit Tip #12

For years, the test framework EcomDev_PHPUnit is quasi-standard for Magento unit tests. The current version is 0.3.7 and last state of official documentation is version 0.2.0 – since then, much has changed which you have to search yourself in code and GitHub issues. This series shall collect practical usage tips.

Tip #12: Cache

You can turn caches on and off per test, using the following annotations:

/**
 * @test
 * @cache on all
 */
public function testWithCache()

/**
 * @test
 * @cache off all
 */
public function testWithoutCache()

/**
 * @test
 * @cache off all
 * @cache on layout
 * @cache on block_html
 */
public function testWithSomeCachesTurnedOn()


/**
 * @test
 * @cache on all
 * @cache off translate
 * @cache off config
 */
public function testWithSomeCachesTurnedOff()

The annotations are executed in order, so if you use “all”, it should always come before all other @cache annotations.

Posted on

EcomDev PHPUnit Tip #11

For years, the test framework EcomDev_PHPUnit is quasi-standard for Magento unit tests. The current version is 0.3.7 and last state of official documentation is version 0.2.0 – since then, much has changed which you have to search yourself in code and GitHub issues. This series shall collect practical usage tips.

Tip #11: Minimal Fixtures For Product Types

Below are some example fixtures for different product types. They are as minimal as possible to create products and their relationships. In most cases you will want to add more attributes like name, visibility, status, price and stock status.

Continue reading “EcomDev PHPUnit Tip #11”

Posted on

EcomDev PHPUnit Tip #10

For years, the test framework EcomDev_PHPUnit is quasi-standard for Magento unit tests. The current version is 0.3.7 and last state of official documentation is version 0.2.0 – since then, much has changed which you have to search yourself in code and GitHub issues. This series shall collect practical usage tips.

Tip #10: Broken Translations

It happens that translations are not working in unit tests if you replace a helper with a mocked helper, using mockHelper() and replaceByMock(), especially in developer mode where translations only work if defined for the right module.

The module name is determined in Mage_Core_Helper_Abstract by $this->_getModuleName(), so let’s look into this method:

/**
 * Retrieve helper module name
 *
 * @return string
 */
protected function _getModuleName()
{
    if (!$this->_moduleName) {
        $class = get_class($this);
        $this->_moduleName = substr($class, 0, strpos($class, '_Helper'));
    }
    return $this->_moduleName;
}

If your helper class is Your_Awesome_Helper_Data, the mocked helper class will actually be Mock_Your_Awesome_Helper_Data. As a module named Mock_Your_Awesome doesn’t exist, nothing can be translated.

Solution

To make your helpers unit test proof (and as a side effect also rewrite proof), define _moduleName explicitly:

class Your_Awesome_Helper_Data extends Mage_Core_Helper_Abstract
{
    protected $_moduleName = 'Your_Awesome';
}

First described here: http://magento.stackexchange.com/questions/46255/ecomdev-phpunit-translation-not-working-with-mocked-helper

Posted on

My Checklist For Magento Shop Analysis

For me, the first step before starting work on an unknown existing Magento installation,  is always a shop analysis. Not only to understand the requirements and processes of the merchant, but also and above all to evaluate the quality and recognize possible problems early on. Unfortunately, many shops are tinkered without any knowledge of conventions and best practices, which leads to:

  1. Suffering performance
  2. Security vulnerabilities
  3. Impossibility to update
  4. Unmaintainable code

Points 1 and 2 directly affect the merchant, point 3 and 4 lead to bugs being accumulated over time, which results in new changes causing bugs in different places, that get harder and harder to solve.

This bug-ridden cycle is often the reason merchants try a new agency or developer to “fix everything”, so it is no coincidence that most shops that land on my desk are in such a degenerated state. The more important it is to analyze first, before any quote for further development and maintenance, to not fall into the same trap as the predecessor and to add clarity on both sides.

Three-Tier Analysis

The analysis has a three-tier design such that after the first tier (1 to 2 hours of effort) there is already a rough estimation of quality and need for action, and after the second tier it is possible to make a quote for cleaning and updating the shop.

Read more at magenticians.com →

Continue reading “My Checklist For Magento Shop Analysis”