IRCE Recap 2016

During the week of June 6th, we attended IRCE (Internet Retailer Conference + Exhibition) in Chicago, IL. After conferences and trade shows we typically select one person to write a recap of the event. As we talked over our experiences post-IRCE, we realized how different each of our perspectives and key takeaways are. So rather than a one-person view, below you have 5, ranging from various levels and departments within Classy Llama.


Kurt Theobald, CEO

Based on my informal survey at the conference, the industry is not innovating very quickly.  It’s not stagnant, but the breakthrough innovators are on the periphery, and they’re designing solutions that are either solving problems that are too small and so not worth merchants’ time or that don’t have a path to gain critical mass due to logistical problems.  With that said, the central players continue to slowly, incrementally improve their offerings, which is important; fresh, breakthrough innovation is always built on the backs of that slow, incremental innovation.  However, I foresee a shock wave of innovation coming over the next three years that will shake up the industry and increase its footprint substantially.

Brandon Urich, Solutions Architect

I really enjoyed getting to know the team a little better. I got to connect with other companies in the ecosystem and discover some new solutions that could be beneficial to our customers. It was nice to have some current clients stop by, as well as talk to merchants in need of something to see if we could help them.

Rob Tull, Director of Solutions

It’s always impressive to me every year to see just how much the IRCE show continues to grow. There were more service providers than ever this year, along with what I perceived to be an increase in “core” providers.

The eCommerce space continues to mature and I see that through the increase of vendors offering key services like email, order management, warehouse management, and more. I felt like this year that there were more vendors I found interesting and would like to learn more about than ever before.

It’s also interesting to see how the market’s perspective on Magento is evolving. This year, everyone was fully aware of Magento 2 and talking a lot about what it means. There were a lot of questions about it and it was great to be able to provide a lot of insight to folks about the opportunities we see. I look forward to seeing how this has settled in by the show next year.

Paul with IRCE guestsRob at IRCEHappy Gino chatting

Ben Leach, eCommerce Consultant

Our powerful branding was also enlightening for me – compared to Imagine (where everyone already knows who you are as we have been a part of the Magento ecosystem since the beginning) I didn’t expect our brand to be as well-known as it was.

Lots and lots of companies approached our booth regarding partnerships – this emphasized the power of our branding as well as our status within the Magento community – again – I didn’t expect this at IRCE

Ashlee Colliver, Marketing Strategist

This being my first conference with Classy Llama, there were so many great experiences and takeaways. However, the biggest by far was seeing how our brand and culture translates to the public. It is something that is often talked about internally but to witness it first hand was pretty amazing. From the buzz about our swag to general interest in our services, I saw the joy people have for our company and the love we give back in return.

I also enjoyed talking with service providers, including competitors and asking them how they view the industry, the trends, the new big players and the technology. What a gift it was to gain knowledge from such a variety of people.

My last big takeaway was having the opportunity to speak directly with some of our clients and partners, which I do not have the chance to do on a regular basis. I bring back with me a deeper understanding of who Classy Llama is in the ecosystem and many ideas on how we can project who we are in person to create a bigger digital footprint culturally.

If you attended IRCE, we’d love to hear what your key takeaways were!

Why Magento 2?

Magento 2.0 was announced January 2015 and officially launched last November. Since that time, the hardcore Magento users, agencies, and partners have been plugging away. For those of us dedicated to the Magento ecosystem, it’s been a fantastic experience with some much-needed improvements.

But how do you, as a merchant, know if it’s right for your business? And – is the only reason it’s being talked about because it’s new, or is it because it’s really that good? Let’s delve into that a little deeper, not from a development standpoint, but from a “Why as a merchant should I care?” standpoint.

The truth is, what really makes Magento 2 so great is for developers, but when things are easier (and faster) for them, it will ultimately cost you less in the long run. But to make such a big switch (updating your website either from Magento 1.X or to a new platform entirely) you want to know how it affects the customer experience and in the end, your bottom line right?

Amazing Performance and Scalability

Compared to Magento 1, merchants can process up to 39% more orders per hour and provides up to 51% faster guest check out response times with Magento 2. It also delivers nearly instant response times for catalog pages, while enabling up to 66% faster add-to-cart server response times.

Best-in-class Checkout Experience

On Magento 1, with every step, such as adding a product to the cart, the page has to reload. Every second your customer feels a delay is a time they have to change their mind about the purchase.

With Magento 2, the need to reload the entire page with each change has been removed. Also, there are only two steps to complete the checkout process now as well. Customers no longer have to register to check out, but can do so afterward, removing a barrier to conversions. In addition, shipping rates load automatically once an address is entered.

Mobile-first Responsive Design

Poor performance and bad user experiences on mobile devices frustrate consumers and make them less likely to purchase from your store. Magento 2 fully embraces responsive best practices with its modern front end architecture. It is designed in a mobile-first context, ensuring phone and tablet users have a fast and intuitive experience.

Modernized Admin Panel

If you currently use Magento 1, you know that changing the grid views (adding or removing columns, pre-selecting filters) involve hours of customizing. With Magento 2 this can all be done natively with a drop-down menu. Also, the admin dashboard is now tablet-friendly, streamlined, and easier to navigate.

New Features

Magento is investing all of their development efforts on adding new features to Magento 2, not Magento 1. Meaning, if you are not on Magento 2, you will be lagging behind your competitors when it comes to new solutions and technologies.

Improved Upgradeability

With Magento 1, an upgrade from one version of 1.X to a higher version resulted in a large, time-consuming project. Though the jump from Magento 1 to 2 is significant, upgrades from that point will be much easier, and therefore more cost-effective.

Given what you now know about Magento 2 – should you re-platform? Maybe. If your site is in need of an upgrade as it is, then Magento 2 is a clear choice today. But should you switch just to switch? Probably not – Magento 1 will continue to receive support until 2018, so if your site functions well and provides all of the features you currently need, you could wait for several months before beginning the re-platforming process. Keep in mind that there is some risk in waiting. At the point that Magento stops offering support for Magento 1, there will most likely be a flood of companies wanting/needing to move to Magento 2. When that happens, agencies will be bogged down and project times will be significantly longer.

If your current site isn’t meeting your company’s (or customer’s) needs, give us a call, we’ll answer any questions you have and help you decide if Magento 2 is the right choice for you now.

Get more information about Magento 2 here.

The Importance of A/B Testing

A/B testing (also referred to as split testing) is the process of testing and comparing two different versions of a web page, to determine which “performs” better. Testing uses real-time data and statistics to help determine the effectiveness of proposed changes, resulting in a site that is fully optimized.

The Testing Process

  1. Ask something.
    Determine the question you want to ask.
    Ie: “Why is the bounce rate on X page so high?
  2. Collect relevant data. 
    Utilize analytics tools to determine what pages and content assets are doing well.
    Understanding your customer behavior will help determine which elements to test.
  3. Identify and document your goals.
    Determine which conversion goals will be used as metrics to measure the test’s success.
    Goals can be simply clicking on an add, purchasing a product, completing a contact form, etc.
  4. Formulate a hypothesis: 
    ie: “Updating the graphics on this page will decrease the bounce rate”.
  5. Create test variations. 
    There are multiple ways to create unique variations of each page. You can utilize A/B testing software such as Optimizely or VWO (Visual Website Optimizer).
  6. Put it to the Test: 
    Launch your A/B test in which the variation (version B) has implemented the proposed changes.
    Test this page against the original, and measure each page’s bounce rate.
    Visitors must randomly be directed to either page.
    Analytics tools will track their behavior to determine how well each page performs.
  7. Analyze results and draw conclusions: 
    If the variant page does better than the original, your test is a winner! If not, keep testing other variables until you reach your goals. Each test will reveal something different!

What to Test

The variables you decide to test will depend solely on your goals for the experiment. Once you determine what your end-goal is, the elements to test typically reveal themselves. Feel free to get creative and test subtle details. For a general rule of thumb, the table below lists out key variables to test.

The Importance of A/B Testing

A/B testing allows you to optimize your site on every level, making use of your existing traffic. It gives you an opportunity to make careful, calculated changes while measuring the impact on conversions. You eliminate the risk of guesswork and can prevent immeasurable damage to your site.

Testing one change at a time will help you pinpoint the root – or roadblock – to increasing conversions. You can continue consistently improving and optimizing your site, without the harsh repercussions of launching without being tested.

Things to Keep in Mind

As we’ve been testing, a few key lessons have stuck out to our team.

Always test the control and the variable simultaneously. Split your traffic between the two versions; otherwise, your results may be skewed.

Don’t read too much into the initial results. If you conclude too early, you may find that the initial results weren’t sustainable. You can find online calculators to determine your test’s “statistical confidence.” (Which tells you how credible and relevant your results actually are).

Allow the results to shape your strategy. Too often, we go into a test expecting a specific outcome; when it doesn’t happen that way, it’s easy to disagree with the results. Just remember that the overall goal is a better conversion rate, regardless of what your personal preference may be. Every test can have 3 results: no result, a negative result or a positive result.

Why Classy Llama A/B Tests

Classy Llama tests, because every good marketer does. We love to do good by our clients. One way we can do this is by analyzing our customers’ sites and running A/B test ideas to improve it.

Testing out ideas is important because what may have worked for one site may not work well for another. There is no one right answer when it comes to the perfect mix for a good UX and good conversion rates. The only true way to know what works with your customers is to run a set of A/B tests and measure them against your current conversion rates.

A/B tests help you get to know your customers better and drives in providing them with the best UX. This, in turn, improves conversion rate performance and makes for a very happy client.

Summer of Louie

Recently our friend Jesse set out on a cross country bike ride to raise awareness and funds for the impoverished women of Korah, Ethiopia (read more here). When our Brand Ambassador, Louie the Llama, heard about all of the amazing places Jesse was going to visit along the way, it inspired him to have his own summer adventure.

Turns out, Louie is a pretty popular guy (or, um… llama), and he’s made friends from all over the world. Throughout the summer he’s going to have the opportunity to visit many of them. He is looking forward to seeing new places, but equally as excited to meet a lot of people, eat new foods and spread his love of bow ties around the world.

Louie is starting out in his hometown of Springfield, MO on Memorial Weekend, then ending the trip back in Springfield on Labor Day. The in-between is a global adventure of epic proportions. Have any travel tips for Louie? Comment below!

Louie will be sending us photos and stories of his adventures as he travels, follow along on Facebook and Twitter.

Have a great summer!

Things You Already Know About Magento 2

Magento mastery… You’ve worked hard for it. Your Magento accomplishments have been hard-fought through blood, sweat, and tears. Okay, maybe not blood, but almost certainly some sweat and tears.

Enter Magento 2. You’ve heard about all the great new features: a new marketplace for extensions, new deployment processes, and more dependency-injection than you can shake a stick at. Just like that, your so-called “mastery of Magento” is gone, right? WRONG. Magento 2 introduces some great new elements, but all of the things that made Magento 1 great are still around.

There are plenty of articles out there highlighting what’s new in Magento 2, but I’d like to examine what’s old.
These are the reasons you’re still a Magento master.

Now take a deep breath and let that apprehension over Magento 2 melt away. The more things change, the more they stay the same…

Module Architecture

A quick look at the modules in vendor/Magento will tell you that all the familiar module components from Magento 1 are still there. Some of them work a little bit differently, but their roles are the same. Also, note that many of the additions are components you’re familiar with that have been moved from other areas in the Magento file structure into the module directories. For instance, translations located in app/locale in M1 are now in i18n. Module-specific items previously located in app/design and skin are now located within the module’s view directory.

Module Architecture: M1 vs M2

Block

Blocks have changed so little that you can pretty much use them the way you always have. All your favorite methods like beforeToHtml, afterToHtml, and _prepareLayout are present. There are equivalents for M1’s abstract and template block classes (located in vendor/magento/framework/View/Element).

Controller

Controllers serve the same purpose you’re used to, but M2 has simplified their structure. Instead of multiple actions on a single controller (such as a customer account controller with login, logout, dashboard, etc.) every action has its own controller. You implement the method “execute” on the controller to perform what would have been in the action method in M1.

Magento 2 Product View Controller

etc

If you love xml-based configuration, Magento 2 delivers. The big difference here is that the configuration you’re used to has been divided into more files. For example, instead of having event and cron sections in config.xml, these pieces of configuration have been moved into events.xml and crontab.xml. Global, frontend, and admin nodes in a single file have also been replaced with separate directories. For example, in the catalog module observers in etc/events.xml will function in admin and frontend while etc/frontend/events.xml will only apply to the frontend.

Magento 2 etc

Helper

No special caveats here. M2 helpers work exactly as you’d expect.

Model

Models are very similar to M1. There are models, which represent individual entity instances (such as a particular product), and resource models (including collections) which perform the actual database interactions. When accessing models within your module there won’t be much difference from M1. Accessing models in other modules (such as loading products within your custom module) have some caveats related to the new service layer (the module’s API directory – see Advantages of Service Contracts). However, even these new elements are somewhat reminiscent of models and collections in the way they represent data.

Magento 2 Model and Api directories

It’s also worth mentioning that observers and cron tasks are no longer grouped with models. They each have their own directory in the module.

sql / Setup

In M1 modules contain install and upgrade scripts that are triggered by a discrepancy between the module version (in etc/config.xml) and the module’s record in the core_resource table. This is similar to M2, but the system has been simplified. There are generally fewer files and you don’t have to name them according to the version numbers that apply.

Magento 2 catalog setup

Extensibility

Extensibility has always been a huge focus of Magento, and M2 offers even more options for elegantly modifying how the application runs and appears to the user. However, the M1 concepts are still present and play a big role tailoring your installation to suit your needs.

Frontend Fallback

Magento has always relied on theme fallback to provide presentation flexibility. Files found in your theme will be used. Files that aren’t found will be retrieved from its parent theme. This is the same in M2.

Observers

Throughout the Magento application events are deliberately dispatched to allow interference from other modules. This remains unchanged in M2, and it’s still the best place to make a change to behavior if needed. Observers are now located in their own directory (instead of Model) and, just as M2 controllers have one class per action, observers have one class per event with an “execute” method to be run in response to the event.

Rewrites / Preferences

If observers fail to provide the necessary access in M1, rewrites are the go-to solution to modify a class’s behavior. While it’s important to mention that M2’s plugin functionality would be the next best thing after observers, the concept of a rewrite is still around. The closest thing in M2 is a preference, and it’s related to the dependency injection system. Like an M1 rewrite, it allows you to swap instances of native classes with your own so you can override methods and properties on the class.

Rendering System

If you love M1’s xml-based layout system (and I do), M2 layout doesn’t disappoint. It’s conceptually the same, but the organization is just a little different. Comparing the two makes M1 seem a little free-form. M2 takes a more structured approach to layout. For starters, instead of having multiple layout handles per file every layout file is associated with a specific handle. For instance, the contents of catalog.xml in M1 have been broken out as catalog_product_view.xml, catalog_category_view.xml, etc. in M2. The main body of these files feels basically like M1, but instead of just using block tags you’ll also be using container tags. Containers are equivalent to core text lists in M1. They simply render all child elements in the specified order. Blocks work in the same manner as M1 with a few exceptions such as how the block type is defined and the ability to specify constructor arguments.

Layout files: M1 vs M2

Catalog

If you know the catalog in M1, you know it in M2. The core structure, as well as many of the settings, remain unchanged.

Products

Managing product attribute sets and attributes in M2 is virtually identical to M1. Very little has changed with product architecture as well. The available product types are all the same as are most of the attributes. The biggest change in M2 is the presentation. Magento experts may find themselves searching a bit for the settings they’re used to while Magento novices will find a less overwhelming experience. It’s obvious that the changes were intended to streamline the product management process, and I personally think they’re effective. One other part of the new process worth mentioning is the ability to switch between certain product types after the product is initially created. While M1 makes you choose the product type up front, M2 lets you switch between simple, virtual, downloadable, and configurable product types based on your settings. It should also be noted that configurable product prices now originate from the associated simple products rather than a base price + additional option costs.

Categories

M2 categories are nearly identical to those in M1. The interface for managing them is the same including the category tree and the tabs (general information, display settings, etc). The major change with categories is the new option to populate them using rules instead of making manual associations, though this feature was also available in Enterprise 1.14.

Order Flow

If you’ve spent your fair share of time learning all the elements of the M1 order flow, you’ll be glad to know that it has stayed pretty much the same. Quotes and quote items become orders and order items. Order states and statuses are all familiar, and shipments, invoices, and credit memos are still around. One nice new feature is the ability to customize the sales grids. You can customize which columns display and save the settings as views for easy access in the future.

Magento 2 order grid

Indexing and Caching

You won’t notice many changes with the caches and indexes in M2. The management is what you’re accustomed to. Indexes can be set to update on save or by schedule. The list of available indexes differs a bit, but nothing looks particularly foreign. The caches are equally similar to their M1 counterparts. Cache types can be individually enabled, disabled, and refreshed and the flush Magento cache and flush cache storage buttons are still around. There are a few new cache types, but they’re pretty self-explanatory. One pleasant addition is the page cache in the community edition.

Indexes: M1 vs M2

Caches: M1 vs M2

A Bright Future for Magento and You

If you’re getting ready to jump into Magento 2, I encourage you to do it with optimism. I was personally nervous to get started but I was soon surprised at how familiar it feels. Once you get past the initial learning curve of some of the new concepts (with the help of Magento’s documentation site), you’ll realize you’re more equipped than you realize to step into the next generation of Magento development. Happy developing!

Operating in Trust

One of the things that we treasure most here at Classy Llama is trust. We operate as a very close knit team, in an environment that is open, free and flexible. Its an incredibly powerful way to operate, and makes working together a beautiful experience because we don’t waste time on politics or power plays or jockeying for position. Everyone strives for the good of the team and the growth of our clients, and the synergy that is created by that is very powerful.

But maintaining an operating environment like this isn’t easy, and it requires above almost everything else that everyone on the team has a mutual trust and respect for each other. To work in an environment where you are very open, about everything including your faults means that people have more opportunities than they would in many companies to hurt you. If you’re afraid of being damaged by something you say, or by expressing vulnerability in some fashion, you’re going to have a hard time being open.

In order to be open, to really work together, you have to believe in the quality and the intentions of the people around you. If you doubt your team members, if you always have questions in the back of your mind about whether or not they are really working for your best interest and looking out for those around them, then you won’t be able to be open. Instead, you’ll be operating in a very protective fashion. You have to guard yourself because you are the only one who is looking out for you.

The problem with operating in this fashion is that it is inefficient, stressful and a detriment to building a solid team. When everyone in a team concerned with guarding their rear, jockeying for position and making sure that there are no chinks in their armor, they spend more time being cautious and dancing around trying to find the highest ground than they do actually being productive.

The beautiful thing is that here at CLS, we don’t have to do that. We operate in an environment where it is okay to let down your guard because everyone else on the team isn’t a bunch of bloodthirsty piranhas looking for a weak moment to take you out. Instead, everyone here works toward helping everyone else out.

It really is the best way to operate. When you see a weakness in a fellow team member, you don’t jump on them and find a way to exploit the opportunity to make yourself look better. Instead, you strive to help that team member grow. You show them how to be stronger, how to improve, how to better themselves as a worker and a person. You flex as needed to help everyone find the best fit and role for themselves.

When this is the approach that everyone on a team is taking, you don’t have to defend yourself all the time. Instead, you can focus on doing things to really serve people. Here at Classy Llama Studios our goal is to selflessly serve the best interests of the other people on our team and our clients. It sound dangerous, serving selflessly. Doing things without worrying about yourself. But when you have a team of people who believe in trust and growth, who believe in really serving each other, then it really is very safe. Instead of you looking out for you, you have many people looking out for you. Everyone has your back, and you are free to run with the tasks you’ve been given.

Don’t waste time building an organization based on politicking and posturing and protecting yourself. Instead, focus on building a team where you can trust the people around you. Find people to work with who are solid folks, who care about those around them… and then trust them to be who you believe they are! When you can begin to trust the people around and live and work in an environment where people are watching your back for you instead of trying to stab it, you’ll get more done, you’ll be much happier, and ultimately you’ll be free to serve and protect and build up those around you – because you trust the people around you to do the same for you.

Trust is a choice. You can know a lot about a person, but choosing to trust them is an act of your will. It does mean you’re at risk of getting hurt, but if you are willing to trust the quality people around you, you might find yourself beginning to lose the armor, and instead be free to run a little faster, to work a little better and to breathe a little easier. It’s a beautiful thing.

Cheers!

Llamas hit the Black Market

Here at Classy Llama, we’ve been hearing rumors that people are going to extreme measures to get their hands on their very own limited edition 2016 Louie the Llama. We get it – he’s cute, and soft and makes an excellent desk companion. So, while understandable, it’s completely unnecessary to lurk around your friends and co-workers with the hope their llama will miraculously fall into your hands. Your love for Louie shouldn’t cause undue stress, and your attempts to get one shouldn’t result in bodily harm (yours or someone else’s).

To help relieve the demand of obtaining your own Louie, we’ve stocked our IRCE booth with plenty of them. No back-alley deals or sneaky swipes necessary. You (and your llama) can sleep better at night knowing your own Louie was secured in a friendly, non-black market way.

We hope to see you at IRCE (Internet Retailer Conference + Exhibition) in Chicago, June 7-10. You can find us at booth #937.

Classy Llama Superheroes

And just between you and me – we’ll also have other sweet swag you can nab to make all of your family, friends, co-workers and general acquaintances jealous.

See you in Chicago!

Targeted Dependency Injection

Global Overrides

When setting up class overrides, you generally want them to apply across Magento as a whole. There are times, however, where you might want to override a class only in one specific location. We at Classy Llama were recently developing a module for Magento 2 that required a Magento controller to return a different URL from what was normally provided by that controller’s service dependency. We wanted this modification to apply to this one controller class and nowhere else.

In the following example controller, let’s say you wanted to change the way this controller’s URL helper functions by having the getBaseUrl() method return a different URL, and it is not possible to directly edit the controller or its dependency:

	class Index extends MagentoFrameworkAppActionAction
	{
	    /**
	     * @var MagentoFrameworkUrl
	     */
	    protected $urlHelper;
		
	    /**
	     * @param MagentoFrameworkAppActionContext $context
	     * @param MagentoFrameworkUrl $url
	     */
	    public function __construct(
	        MagentoFrameworkAppActionContext $context,
	        MagentoFrameworkUrl $url
			
	    ) {
	        $this->urlHelper = $url;
	        parent::__construct($context);
	    }
		
	    /**
	     * @return void
	     */
	    public function execute()
	    {
	        echo $this->urlHelper->getBaseUrl();
	    }
	}

You could create a class that extends MagentoFrameworkUrl, override the getBaseURL() function, and then set up a preference. You could even set up a plugin to modify the method’s behavior. Unfortunately for us, both of these options are essentially global overrides. Since the getBaseURL() method is used in many other places, overriding it globally would potentially break other core classes that rely on MagentoFrameworkUrl as a dependency.

There is, however, a way to selectively modify functionality using constructor argument injection. As we will see in the following examples, constructor argument injection can replace a specific class’ dependencies with new or updated dependencies, and as long as the new class you create extends the required class specified in the constructor, Magento 2 will not complain about incorrect types. To illustrate the concept, I have written a small module that you can grab from GitHub.

Dependency Injection

This article assumes familiarity with the concepts of dependency injection as implemented in Magento 2. For further reading, check out the Magento 2 developer documentation. Alan Kent has also written an excellent article about dependency injection that touches on concepts such as injectables, non-injectables, and factories.

Overriding a Dependency’s Method in a Single Location

Extending on our previous example, let’s take a look at how we can use constructor argument injection to selectively modify a class’ behavior. Here is a simple example using the class DholdenDiExampleControllerExampleOneIndex from the GitHub project:

	namespace DholdenDiExampleControllerExampleOne;
	
	class Index extends MagentoFrameworkAppActionAction
	{
		
	    /**
	     * @var MagentoFrameworkUrl
	     */
	    protected $original;
		
	    /**
	     * @var MagentoFrameworkUrl
	     */
	    protected $modified;
		
	    /**
	     * @param MagentoFrameworkAppActionContext $context
	     * @param MagentoFrameworkUrl $url1
	     * @param MagentoFrameworkUrl $url2
	     */
	    public function __construct(
	        MagentoFrameworkAppActionContext $context,
	        MagentoFrameworkUrl $url1,
	        MagentoFrameworkUrl $url2
			
	    ) {
	        $this->original = $url1;
	        $this->modified = $url2;
	        parent::__construct($context);
	    }
		
		
	    /**
	     * @return void
	     */
	    public function execute()
	    {
	        echo '

Original Base URL: ‘ . $this->original->getBaseUrl() . ‘

‘; echo ‘

Modified Base URL: ‘ . $this->modified->getBaseUrl() . ‘

‘; } }

This simple controller calls the getBaseUrl() method from MagentoFrameworkUrl. Notice that $url1 and $url2 both instantiate MagentoFrameworkUrl, yet the output of the “ExampleOne” controller is as follows:

Original Base URL: http://example.dev/

Modified Base URL: http://newurl.dev/

While the exact same method is being called, the output is completely different, and this difference in functionality applies only to this controller class. To understand what is happening, let’s first look at DholdenDiExampleModelModifiedUrl:

	namespace DholdenDiExampleModel;
	
	/**
	 * Returns modified URL
	 */
	class ModifiedUrl extends MagentoFrameworkUrl
	{
		
	    /**
	     * {@inheritdoc}
	     */
	    public function getBaseUrl($params = []) {
	        return 'http://newurl.dev/';
	    }
	}

This simple class extends MagentoFrameworkUrl and overrides the parent function getBaseUrl(). Nothing too special here. We could at this point, setup a configuration preference for the class, but this would override this method across all of Magento 2. We shall instead use dependency injection to selectively override one constructor argument in one class. Let’s take a look at our etc/di.xml:

	
	
    	
        	
            	DholdenDiExampleModelModifiedUrl
        	
    	
    	...
	

We’re replacing the third constructor argument of our controller (i.e. $url2) with the object DholdenDiExampleModelModifiedUrl, and since this class extends MagentoFrameworkUrl, it fulfills the requirement as set in the constructor.

Taking it a Step Further

Great, but let’s say you wanted to do this with a factory. The same principle applies, but with one small caveat, to which we will get shortly. Let’s take a look at DholdenDiExampleControllerExampleTwoIndex from our Github project:

	namespace DholdenDiExampleControllerExampleTwo;
	
	class Index extends MagentoFrameworkAppActionAction
	{
		
	    /**
	     * @var MagentoCatalogModelCategory
	     */
	    protected $categoryOriginal;
		
	    /**
	     * @var MagentoCatalogModelCategory
	     */
	    protected $categoryModified;
		
	    /**
	     * @param MagentoFrameworkAppActionContext $context
	     * @param MagentoCatalogModelCategoryFactory $categoryFactory1
	     * @param MagentoCatalogModelCategoryFactory $categoryFactory2
	     */
	    public function __construct(
	        MagentoFrameworkAppActionContext $context,
	        MagentoCatalogModelCategoryFactory $categoryFactory1,
	        MagentoCatalogModelCategoryFactory $categoryFactory2
			
	    ) {
	        $this->categoryFactory1 = $categoryFactory1;
	        $this->categoryFactory2 = $categoryFactory2;
	        $this->categoryOriginal = $categoryFactory1->create();
	        $this->categoryModified = $categoryFactory2->create();
	        parent::__construct($context);
	    }
		
		
	    /**
	     * @return void
	     */
	    public function execute()
	    {
	        $this->categoryOriginal->load(1);
	        $this->categoryModified->load(1);
	        echo '

Name of Category 1: ‘ . $this->categoryOriginal->getName() . ‘

‘; echo ‘

Name of Category 2: ‘ . $this->categoryModified->getName() . ‘

‘; } }

This controller outputs the name of the category with an id of ‘1’, but like in our first example, the result of calling getName is different even though the same method is called. The primary difference between this example and the previous one is that we are calling factories in the controller’s constructor. We are then instantiating two new instances of MagentoCatalogModelCategory using the factory’s create() method. Our desire is to override the getName() method of MagentoCatalogModelCategory, but only in our specific example class and nowhere else.

Like in our first example, we have created a new class (DholdenDiExampleModelModifiedCategory) that extends MagentoCatalogModelCategory and overrides the getName() method, but now our etc/di.xml looks a bit different:

	
	
		...
	    
	        
	            DholdenDiExampleModelModifiedCategoryFactory
	        
	    
	 

Since we are using factories in the class’ constructor to create new instances of the category class, we need to override these factories in some manner. But we have created a new category class (DholdenDiExampleModelModifiedCategory) that modifies the getName() method. As you may have noticed, factories are not the classes themselves. They only create new instances of the classes whose methods we wish to selectively override.

We obviously need to pass a factory to the controller, so the logical approach is to append ‘Factory’ to the end of our constructor argument, i.e. our new class, in di.xml. Unfortunately, this will cause an error because the factory that will the auto-generated by Magento 2 will not fulfill the requirements of the constructor argument because it does not extend MagentoCatalogModelCategoryFactory as the constructor has specified. If we try to view the controller as-is, the page will return the following error in our browser:

Recoverable Error: Argument 3 passed to DholdenDiExampleControllerExampleTwoIndexInterceptor::__construct() must be an instance of MagentoCatalogModelCategoryFactory, instance of DholdenDiExampleModelModifiedCategoryFactory given...

From the error message, we learn that the factory created by Magento 2 does not extend the factory that is specified in the controller’s constructor. The solution is to have that factory inherit from MagentoCatalogModelCategoryFactory. But how do we do this, since the factory was auto-generated? Fortunately for us, we can manually create our own factories and have Magento 2 use these over its own auto-generated classes. Take a look at the following factory located in the same folder as our new ModifiedCategory class:

	namespace DholdenDiExampleModel;
	
	class ModifiedCategoryFactory extends MagentoCatalogModelCategoryFactory
	{
		
	    /**
	     * {@inheritdoc}
	     */
	    public function __construct(MagentoFrameworkObjectManagerInterface $objectManager, $instanceName = 'DholdenDiExampleModelModifiedCategory')
	    {
	        parent::__construct($objectManager, $instanceName);
	    }
		
	    /**
	     * {@inheritdoc}
	     */
	    public function create(array $data = [])
	    {
	        return $this->_objectManager->create($this->_instanceName, $data);
	    }
		
	}

Here we create a factory that extends MagentoCatalogModelCategoryFactory. The CategoryFactory class will still be auto-generated by Magento 2, but since our factory now extends it, it will now fulfill the requirement of the controller’s constructor argument.

Conclusion

Constructor argument injection allows you to modify a class’ behavior, specifically methods given to you by class dependencies, without directly modifying the classes themselves and without changing their behavior system- or area-wide. I hope this concept will be useful to you in your future Magento 2 projects.

Magento Imagine 2016 Recap

Magento unveiled a number of bold new ideas at Imagine 2016. “We Are Magento” appropriately drives home a simple, meaningful pride that we at Classy Llama share with the greater Magento community. We are poised, ready and thrilled to continue building on a platform that keeps churning out newer and newer innovation. With so many bold ideas, unveiled at the Imagine 2016 conference in Las Vegas, we can’t wait to see the ripple effects this will have on the SMB merchant community.

Magento Unveiled:

For all of these groundbreaking announcements and events at Imagine 2016, one of the most moving and important moments of Imagine 2016 was during the Partner Summit. Perhaps it was my imagination, but on what seemed the verge of tears, Mark Lavelle detailed the Magento story since the eBay takeover. Many of you in the community have your own version of this story. Regardless of your view, I think everyone in that room would agree, Mark’s account was honest, insightful, and very personal.

It was clear that Magento isn’t just another company for Mark to run. He loves it. He loves Magento’s customers. He loves Magento’s community. He loves Magento’s future—empowering commerce in ways that we have yet to realize. Even though he did not found Magento, it feels like he did, like this is his home—his fifth child. This is absolutely key for Magento’s future. To have a leader who is truly invested and is willing to make sacrifices and hard decisions in order to see it succeed. A leader who believes in Magento and the community.

One part of Mark’s account is particularly important: when Mark realized the precarious position Magento was in, he sat down with Paul Boisvert and they made a commitment—that their say/do ratio needed to be as close to one-to-one as possible. Even prior to knowing this detail, I can tell you the Classy Llama team has been very aware of this position, because Magento has been delivering. And while the split from eBay was an important part of Magento’s evolution, we were able to see Magento was on track before the split even happened.

Empowering Others

Mark has done a phenomenal job lifting up and empowering innovative and a diverse set of leaders. Those leaders, in turn, have enabled and empowered their teams to deliver. Not only has Mark empowered the leaders in his organization, but he and his team have recommitted to leaders in the community.

The theme of the conference was “We Are Magento,” and you could feel it. The energy was high. Many people walked away from the conference with the feeling that it was the best Imagine yet. The session content was on point. Shout out to Classy Llama’s Rob Tull for his breakout session talk on requirements gathering, called Winning the Requirements Game. And I want to mention both Rob Tull and Daniel Nettleton for their level of insight on the Payments Panel.

Remaining Committed

Merchants had peer-to-peer engagement and conversations dedicated to discussing their needs and opportunities. A significant portion of the Marketplace was committed to an Ask Magento forum. Magento polled the SI partners; and is making updates to the SI partner program as a result. At the partner summit, Mark made a definitive statement committing Magento to open source and Magento CE. A commitment that was, frankly, already implied when Magento decided to stay open source. In 2015, the Magento community created over 2,500 pull requests and issues for Magento 2.0.

Breaking New Ground

The outcome of all this is that while certain announcements were previously unrevealed, their innovative and groundbreaking nature was not surprising. And these announcements are definitely groundbreaking. Magento Enterprise Cloud Edition is a Platform as a Service (PaaS)—the first of its kind. It will provide merchants with all the flexibility and features of Magento Enterprise and all the benefits of SaaS at the same time. It’s really the best of both worlds, and we look forward to diving in.

The Magento Marketplace is exciting because of the new quality control standards. Many people have described Magento Connect as the Wild West of extension stores. The Marketplace is intended to be the opposite of that, with robust code and functionality testing, curation, and ease of use.

Magento 2.1 (to be released in June), is chalk full of updates and new features, two of which are particularly exciting:

  • ElasticSearch integration which will provide merchants with a powerful search tool that is much easier to leverage than Solr.
  • Content staging, preview, and scheduling tool which will save merchants time and help ensure content is properly formatted and pushed.

On a final note, the food, parties, events, design, and vibe of this show were off the hook. Best ever. If you didn’t attend, you really missed out. Make sure you come next year.

Thank you Magento, for hosting the best Imag… no, I’ll go further. Thank you for hosting the best Commerce Conference in the world.

Classy Llama at Imagine 2016

Of course, no tradeshow experience is complete without some of our signature swag. This year we returned with our third annual edition of our legendary plush llama. “Louie,” as we called him, was a complete hit. In addition, we brought some brand new Classy Llama cape and mask kits. As you’ll see, these were a major success with kids and… uh grown up kids, alike.

Louie the Llama

Classy Capes and Masks

Magento Imagine 2016 Highlights

Still want to know more? Check out the official highlights video from the conference.

Get Prepared for Magento 2 with Classy Llama’s Dev Docs.

As an authority on Magento 2, Classy Llama is prepared to guide your eCommerce business into the future. Several major brands have already used our world-class expertise and service to bring them into the future with Magento 2.

We are one of the largest outside contributors of code to the Magento 2 base. Between retooling our infrastructure, training and other necessary steps for equipping our agency for success, Classy Llama has invested a great deal in preparation for Magento 2.

Magento is a community and we believe collaboration is essential to its success. As one of the first agencies in the world to be certified as a Magento 2 Trained Solution Partner, we find it to be an important role for us to share our knowledge with the Magento community.

The Classy Llama team has prepared multiple Magento 2 dev docs for the benefit of the Magento community. Here are a few:

http://devdocs.magento.com/guides/v2.0/extension-dev-guide/service-contracts/service-to-web-service.html

http://devdocs.magento.com/guides/v2.0/extension-dev-guide/factories.html

http://devdocs.magento.com/guides/v2.0/extension-dev-guide/proxies.html

Contact Us