Magento version 2.0 (X.Commerce) and eBay

eBay Acquisition

the bad(maybe?) news.

As everyone may know for the most part, eBay now owns Magento. (at least the details are still being worked out, currently.)

Overall I’ve seen some mixed feelings in regards to this, I myself am pretty up in the air; if it’s a good or bad thing, and I think the only thing that will tell is time.

With all the talk, I’m suspecting a fork or two will show up of Magento granted if the OSL will allow for such which I’m pretty sure it will, long as its made freely available:

arrow Magento Community to Enterprise version when its open source?

With that said, during the developers paradise there was mention that eBay’s X.Commerce package would in fact be “Open Source”.

Related Links:
arrow Inchoo on the acquisition

[warning]…when deep-space exploitation ramps up, it will probably be the megatonic corporations that discover all the new planets and map them. The IBM Stellar Sphere. The Philip Morris Galaxy. Planet Denny’s. Every planet will take on the corporate identity of whoever rapes it first. Budweiser World. ~Chuck Palahniuk, Fight Club, Chapter 23[/warning]

Magento 2.0

the good news.

The most interesting news was information about a 2.0 version of Magento, I’m going to assume this will be under the new name X.Commerce with eBay ownership. It will NOT be backward compatible with 1.0 and is NOT a rewrite but a refactoring. It is due to release around the middle/end of this year.

The list of new shinny exciting things:

  • eregi_replace(“^(.*).js$”,”prototype.js”,”jQuery.js”); // No more Prototype!
  • PHP5.3 Native.
  • Simpler file structure, no more app/etc/modules I believe.
  • GUI Design Editor (WYSIWYG?)
  • Class Mapping: No more searching 3 directories of code pools.
  • EAV can be optional (for performance I presume).
  • A deeper theme fallback support.
  • Unit Testing, Selenium, TDD Support.
  • Staging before applying any core updates/modules.
  • Better server side validation.
  • More database options: Oracle, MSSQL, PostgreSQL, etc.
  • No more Magic getter/setters.
  • More API options: RPC/REST
  • Name space collisions detection with advice on how to resolve dependencies.

Related Links:
arrow Magento 2 (in German)

Magento modules post deployment uninstall & downgrading

An interesting question on StackOverflow about Magento modules and the un-installation or downgrade of code…

[box]Automated instant rollback is an important feature of enterprise-grade deployment mechanisms. Currently, it’s not possible to achieve this using Magento’s built-in installation tools. Given that Magento’s core_resource mechanism allows for the sequential execution of setup scripts for installation or upgrade of modules (via execution of SQL and also PHP), it seems logical that it should support the same process in reverse.[/box]

I have seen some postings in regards to such and have investigated the same scenarios for SQL deployment myself. I would have to agree that being Enterprise grade Magento should have this type of functionality built-in. The good news it IS, at least in SOME form or fashion, how complete it is I’m not really sure. Here’s a sample of a rollback upon exception:

    try {
        $write = Mage::getSingleton('core/resource')->getConnection('core_write');
        $write->beginTransaction();
    // do stuff here
        $write->commit();
    } catch (Exception $e) {
        mage::log(__METHOD__ . ':' . __LINE__ . ': Rollback happened.');
        $write->rollback();
    }

Now if you take a look at app/code/core/Mage/Core/Model/Resource/Setup.php you’ll find quite a bit of interesting methods. In particular: _getModifySqlFiles, _rollbackResourceDb and _modifyResourceDb.

_modifyResourceDb is the most interesting to me, since the $actionType here can be rollback and uninstall as well – also note you can use PHP files for your setup files as well.

    // Read resource files
    $arrAvailableFiles = array();
    $sqlDir = dir($sqlFilesDir);
    while (false !== ($sqlFile = $sqlDir->read())) {
        $matches = array();
        if (preg_match('#^'.$resModel.'-'.$actionType.'-(.*)\.(sql|php)$#i', $sqlFile, $matches)) {
            $arrAvailableFiles[$matches[1]] = $sqlFile;
        }
    }

After this code executes:

    $arrModifyFiles = $this->_getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrAvailableFiles);

But heres where I’m assuming core Magento devs got lost in the bowels of the EAV resource model and just left it partially complete.

    protected function _getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrFiles)
    {
        $arrRes = array();
        switch ($actionType) {
            case 'install':
            case 'data-install':
    ...
            case 'rollback':
                break;
            case 'uninstall':
                break;
        }
        return $arrRes;
    }

I’ve not had a chance to really test out the above, but from just my initial investigations of the ORM that is magento and the Autoloading as well as another developer’s input on his findings as well.

Ultimately it would be ideal if we can keep all of our changes at least module wise within a version controlled system. Obviously huge data sets that need to be imported shouldn’t be managed this way but for these small incremental changes I want to push to staging, production test and if it fails pull it back one version and everything is back to normal.

Obviously theres no one ideal solution for deployment with so many clients having different requirements and needs but a general way of doing this would help with code/SQL deployment. It’s kind of ironic that Enterprise has CMS staging, and the ability for modular development of code, but the DB has not gotten as much love.

There is a related question that is noting how currently we are doing it with some specialized scripts “home-brewed” that essentially do:

Doing a MySQLDump or backup, then doing a replace on the BASE_URLs in the SQL file.

Another tool to look at would be arrow Phing.

[tip]If anyone has time to investigate the “rollback” and “uninstall” processes that seem to be implemented and report their findings would be helpful to me as well.[/tip]

More reading:
arrow Best Practicies for Magento deployment.
arrow My original SO Response.

Debugging tips & tricks with Magento Commerce

If you are new to Magento then the vast amount of code to digest can be quite overwhelming. cold_sweat However, here are some tips I’ve learned about over the past on some means to tear down Magento and figure out what’s making it work.

Zend_Debug::dump

Use Zend_Debug::dump($foo); instead of using var_dump($foo); or print_r($foo); it is essentially the same, just a wrapper with pre HTML tag for formatting and escaping of special characters.

idea More details about arrow Zend Frameworks dump method.

However there will be times that simply dumping objects to the screen can be too much and cause browser hangups or even crashes. The best practice I’ve learned is to always use the getData() method that Magento has built-in to the Varien Object, this way your not getting redundant amounts of data dumped to the screen but only the bits you really care about.


Varien Object getData, debug

Magento also has a built-in debug() method in the Varien Object as well that you can use to display data in a string representation of itself.

exclamation Keep in mind debug does NOT always get attached to every object.

idea More details about the arrow Varien Object debug method, arrow Varien Object getData method


Log files

What if your having difficulty displaying things to screen or don’t want any users to see debug output. With this in mind you can also use a built in logging function, similar to arrow Zend_Log and is essentially a wrapper as well. You can find it defined in app/Mage.php.

    /**
     * log facility (??)
     *
     * @param string $message
     * @param integer $level
     * @param string $file
     * @param bool $forceLog
     */
    public static function log($message, $level = null, $file = '', $forceLog = false)
...

And here is an example:

Mage::Log($foo);

Which will log the output the contents of $foo to /var/log/system.log by default.

You can also specify your own log file with an extra argument, your custom log file will appear in /var/log/mylogfile.log

Mage::log($foo, null, 'mylogfile.log');

You can also use combinations of functions/methods to output the contents of an array for instance:

Mage::log(var_dump($fooArray), null, 'mylogfile.log');

exclamation Logging MUST be enabled within the admin: Configuration -> Developer -> Log Settings -> Enabled = Yes


XML Configuration

Most of the time, I have have issues with my XML configurations. Since Magento is very configuration based driven, one improper case or underscore can render things useless. Magento doesn’t validate the XML or throw any errors when such are encountered but rather ignored. The best means I’ve found to figure out whats going on is to display the entire XML built from all XML configurations files with.

header("Content-Type: text/xml");
die(Mage::app()->getConfig()->getNode()->asXML());

xDebug

xDebug is probably one of the more well known and most used debugging tools available. If your IDE does support it, I would highly suggest taking the time to get your environments setup so that you can connect and use it. I’m not going to cover the general use and configuration of it, however Classy Llama has a nifty post that helps keep Magento from letting xDebug take over error handling.

arrow Classy Llama’s Enable xDebugs Error Handler

exclamation It requires modification to the Core files and cannot be extended since the class is final. Make note of your change when doing this, or merely use it on a per need basis and removing it after your done with it. You can also setup your version control to ignore any changes with it.


Built-in PHP functions

If you’re using a bare bones editor without any type of auto complete looking up available class methods can be a pain digging through Magento’s numerous files and folders. To get all available methods from any class you can use var_export, get_class_methods and get_class in combination.

print "<pre>"; var_export(get_class_methods(get_class($this)));

idea More details on: var_export(), get_class(), get_class_methods()

You can also use it in combination with Magento’s getData() to display data with key values intact.

print "<pre>"; var_export(array_keys($this->getData()));

Developer Mode

One last tip I’ve been doing lately is modifying index.php and adding ini_set('display_errors', 1); to the condition checking for the developer mode flag: MAGE_IS_DEVELOPER_MODE. By default the display_errors ini_set is commented out. Here is what my change looks like:

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) {
  Mage::setIsDeveloperMode(true);
  ini_set('display_errors', 1);
}

Then use .htaccess SetEnv to enable and disable developer mode per environment:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

If you have any tips or if I missed something please feel free to comment and I’ll add it to the article.

Farbrausch: debris

177 kilobytes of awesomeness! I’d highly recommend the link in full HD than my embed to enjoy, or better yet if you’ve got a good graphics card like an late model NVIDIA or ATI then download the tiny executable.

arrow YouTube – Farbrausch – fr-041: debris. [HD].

The secret behind all this is procedural content generation. in a nutshell, instead of storing a movie as-is we’re storing a certain number of mathematical formulas for image and audio manipulation as well as the “recipe” how to apply those small bits of code in a way that what you see comes out. And while it’s running your computer’s graphics card cares for the actual displaying ot the world, just like in modern 3D games. Formulas+recipe are of course way smaller than the end result, and with a few additional sprinkles of magic compression fairy dust we get down to under 200 kilobytes, which is way less than one single high quality image of this show would take.