Spryker vs. Magento

Recently I had the opportunity to take a peek into the source code of Spryker, the e-commerce framework that’s composing itself to be the new player in the enterprise area. Spryker was originally developed by the Berlin based incubator Project A to be used in the companies that they build up and is supposed to be released to the public this year. While “public” is not enirely true, I can say so much in advance: An open source version is not planned, licenses will cost about 100.000 € / year. Agencies can register as partner, to get access to source code and documentation without a license. With the first sold license they get access to additional training material. Freelancers are not addressed. Already listed as partner are the agencies CommercePlus and Symmetrics that are well-known in the German Magento scene.

What is special about Spryker?

Spryker doesn’t consider itself as ready-to-use product but as framework that provides the building blocks for an individual e-commerce solution from which you can choose and extend for your project. This takes the reality into account that no project is equal to the next and each shop has its own processes and infrastructure, which you have to address individually.

The core of Spryker are two separate applications, Yves and Zed. In short, Yves is a lightweight application for the frontend, Zed the big gun for the backend.

Discover Spryker
Image: http://spryker.com/product/

Yves (in the first version developed with Yii, now with Silex) reads any needed data from an in-memory NoSQL backend such as Redis.
Zed (Zend Framework 2) handles communication with MySQL, message queue and external systems, and contains the business logic for order processes and so on.

Read more at magenticians.com Continue reading “Spryker vs. Magento”

Magento: Lost Block Content After core_block_to_html_after Event

Be careful if you use Mage_Core_Block_Abstract::toHtml() inside an observer for core_block_to_html_after. I did that to inject HTML from another block into an existing block with the result that everything except this new block was removed from output.

Digging through the core, I found the cause in how the event is dispatched:

        /**
         * Use single transport object instance for all blocks
         */
        if (self::$_transportObject === null) {
            self::$_transportObject = new Varien_Object;
        }
        self::$_transportObject->setHtml($html);
        Mage::dispatchEvent('core_block_abstract_to_html_after',
            array('block' => $this, 'transport' => self::$_transportObject));
        $html = self::$_transportObject->getHtml();

As you see, the transport object that is used to allow modification of the HTML in observers, is a class variable of Mage_Core_Block_Abstract, so basically acts like a singleton. I cannot think of a good reason for this, but it smells ridiculously like premature optimization.

Now what’s happening is, that during the event is processed, the new block sets its own output to the same transport object in its toHtml() method and the original output is lost, if you didn’t save it before.

The solution to my particular problem was to generate and pre-render the new block elsewhere but if you don’t, you need to copy the output at the very beginning:

$html = $observer->getTransport()->getHtml(); // should be the first statement

// now you can do what you want, create other blocks, modifiy $html ...

$observer->getTransport()->setHtml($html); // should be the last statement

Why I Am Actively Going to Drop PHP 5.3 Compatibility

PHP Supported Versions

It’s simple and elegant, since PHP 5.4 introduced short array syntax:

$everySingleArrayInitializationFromNowOn = [];

Why this step? An alarming large amount of websites still runs on PHP 5.3, which does not get updated anymore since 2014/08/14, after one year of “security only” support. In other words, the next critical security hole will only be fixed for versions above 5.4. By the way, active development of the PHP 5.4 branch was discontinued on 2014/09/14. it’s already in the “security only” phase. On 2014/08/28, PHP 5.6 has been released, on 2013/06/20, almost 1.5 years ago, PHP 5.5.

So, by now, in the year 2014 everybody should work on PHP 5.5, right? That’s the theory, in practice it looks like this:
PHP versions statistics - October 2014 - Pascal MARTIN
Source: http://blog.pascal-martin.fr/post/php-versions-stats-2014-10-en

Almost half of the Alexa Top 1M Sites that run on PHP, state the version 5.3, ca. one quarter even 5.2, which is not supported since Jan. 2011. PHP 5.2.17 even is the most used patch version in this statistic.

There are probably many reasons:

  • “never touch a running system” mentality
  • Not or not sufficiently maintained servers
  • Incompatible frameworks and legacy applications

I want to go into some background briefly.

Continue reading “Why I Am Actively Going to Drop PHP 5.3 Compatibility”

Magento: How To use the Secure Base URL for Custom Controllers

This question came up on Magento.SE and more people should know, how dead simple it actually is.

If you look at core/Mage/Checkout/etc/config.xml you can see how Magento defines for the checkout to use the secure base URL, i.e. HTTPS:

<frontend>
    <secure_url>
        <checkout_onepage>/checkout/onepage</checkout_onepage>
        <checkout_multishipping>/checkout/multishipping</checkout_multishipping>
    </secure_url>
</frontend>

That’s all. You can configure your own controllers to use the secure URL in the same way and now Mage::getUrl() returns the secure URL for the configured routes and any unsecure request will be redirected.

Allow SVG Images in Magento Uploader

If you want to change the allowed image extensions for product images in Magento you will find out that they are hard coded in Mage/Catalog/Model/Product/Attribute/Backend/Media.php and Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

However, I found an observer that allows you to change them along with other configuration of the uploader. This post explains how to create an extension to allow uploading of SVG files. Foundations of Magento extension develoment are presumed.

Continue reading “Allow SVG Images in Magento Uploader”

The Magento buyRequest Object – A Reference

Whoever looked at the Magento source code or database in the context of orders, probably encountered the parameter $buyRequest in many methods or the option info_buyRequest in quote items and order items. Its purpose is not immediately obvious since it contains seemingly redundant information. Also it does not have its own model class, it’s just a Varien_Object and a serialized array when stored to the database.

Example:

mysql> select code,value from sales_flat_quote_item_option where option_id=2359;
+-----------------+------------------------------------------------------------------------------------------------------------+
| code            | value                                                                                                      |
+-----------------+------------------------------------------------------------------------------------------------------------+
| info_buyRequest | a:4:{s:4:"uenc";s:140:"[...],,";s:7:"product";s:4:"5000";s:15:"related_product";s:0:"";s:3:"qty";s:1:"1";} |
+-----------------+------------------------------------------------------------------------------------------------------------+

In short: The $buyRequest object represents the customer request coming from a click on “Add to cart”, all related data can be derived from this object. It’s basically a generator for quote items. The minimal necessary data is thus the product id (product) and quantity (qty).

Where is the $buyRequest object needed?

For example it is created when you add a product to the wishlist, so that it can easily be transfered to the cart with the same configuration. When reconfiguring a product, i.e. editing it from the cart, the buyRequest is passed to the product view to preselect all options.

Also for recurring profiles and reordering the buyRequest objects get “reused” to generate a new order.

Use Cases

Some examples, when it is useful to deal with the buyRequest:

Continue reading “The Magento buyRequest Object – A Reference”

PHP: Mock header() to Unit Test Controllers

In 2011 I suggested a technique to mock functions in PHP Unit Tests that takes advantage of the name resolution rules of PHP namespaces. You can read it here:

It makes me proud that the great Matthew Weier O’Phinney 1 now describes the same technique to test code that emits output, especially code that sends headers with the built-in header() function. Read more in his post here:

In my opinion this is a great example of how useful this method is. “Headers already sent” errors in your unit tests can drive you crazy. Unfortunately, there are still many applications that do not use namespaces (*cough* Magento *cough*) where it does not work.

Notes:

  1. for those who don’t know him: He’s the Zend Framework Project Lead and you should follow his blog at http://mwop.net/blog.html!