Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento
front end book you'll ever need. Get your copy
today!

One of the bigger changes to Magento 2’s layout system is how a end-user-programmer uses layout handles. In Magento 1, layout handles were top level configuration nodes in a set of layout update xml files

Magento will merge your values for the name=catalog-search-advanced-link node and name="label" node over the values in Magento’s original file. While this sort of merging happened with Magento 1’s config.xml tree, it did not happen with Magento 1’s layout update XML files.

It’s hard to say if this is a technique developers should lean heavily on or not. Most long-time Magento 1 developers avoided using these sort of layout merges in the config.xml tree due to a lack of clarity around how the merging rules worked. Questions like when does Magento add a new node vs. merging a node? Are node attribute values merged? If node attribute values are merged, does a missing node in the merged XML mean leave the old value, or remove the node? These same questions remain for Magento 2, with the added complexity that there are dozens of classes for XML loading and merging in M2. i.e. tracking down these merge rules is a non-trivial affair, and without any promise of future behavior from Magento’s core team the behavior could easily change out under you.

Regardless of whether using XML merges is a good idea, you will encounter third party Magento code that uses them. Be sure you’re searching all the code in your system when you’re trying to track down block arguments.