Which version of Magento should I use? This will help you decide

A brief guideline that will help you to choose which version of Magento to use and if you’re on V1 identify if it’s a good idea to migrate your current store to V2.

Overview

Magento is one of the most widely used eCommerce platform today. It has two major versions: 1.x and 2.x. You find yourself asking the question: which one should I choose?

Image from Alan Kent’s slideshare

This would be easy to answer when you’re starting a new project: pick the one with the latest version. But what do you do with an active Magento 1 project? You should ask yourself the question of..  Do you migrate or not?

In this post I will try to bring a guideline that will help with this decision process.

Why should I migrate to Magento 2?

Unfortunately, there is no simple answer to this question as there are list of advantages and disadvantages for both versions. However, I will provide a list of pros and cons that will help you to select the best option for the project you work on.

Pros and cons

Let’s start with advantages of Magento 2

  • The Backend Admin is Designed for Non-Technical Users

The new default theme, “Luma”, provides an eye-catching theme that is drastically improved compared to the previous “Madison Island” theme.

 

  • Improved flexibility

The new platform structure has improved flexibility which consists of high code coupling, enabling developers to create complex features such as checkout, SMS, CRM, and sales.

  • Better code underneath the hood with real unit testing

With a completely overhauled codebase, created with reliable composer packages, the entire application is now covered by unit tests. This greatly improves stability and should put your mind at ease when upgrading.

  • Integrates with Popular Payment Gateways

Magento 2 is able to integrate with many of the popular payment processors, such as PayPalWorldPay, and Cybersource.

  • It is user-friendly

The Magento 2 checkout process is better streamlined, making it easier and quicker for customers to navigate through from the cart to the completed order than Magento 1. The customizable checkout now requires less customer information and steps, therefore it reduces the checkout time, increases sale conversions and minimizes abandoned carts.

  • Improved scalability and performance

Studies have shown that a one-second delay in page load time can result in a 7% loss in sales conversions. Magneto 2 runs approximately 20% faster than Magento 1, which can lead to improved SEO and increased sales. All of the content from a static page can be cached, thus increasing site performance and drastically reducing the server load. This makes the Magento 2 platform more scalable for large eCommerce stores.

But there’s still some disadvantages

  • Magento 1 themes can’t be ported

Magento 1 themes cannot be transferred to Magento 2, it will need to be built from scratch, making it an expensive endeavor.

  • Not All Extensions Are Available Yet

Unfortunately if you are already using extensions for Magento 1, unfortunately, you cannot port them into Magento 2. You’ll need to purchase the extensions and integrate them into your Magento 2 platform, also add to your overall costs.

  • Enterprise Edition Cost Rises

Although Magneto Community Edition (CE) remains free, for the Enterprise Edition (EE) a single license has increased in price from $18,000 to $22,000 per year.

  • It still has A Steep Learning Curve

All that flexibility comes at a cost, and the cost is time. You can manipulate the platform to your heart’s content, but getting over that steep learning curve is already going to be a big obstacle for any developer already unfamiliar with Magento and how it works.

  • … and hosting it can still be tricky

Dedicated file servers that can be configured to Magento’s hosting requirements absolutely must be employed, adds to the true cost of using Magento.

How to migrate

Have you decided to migrate from Magento 1 to Magento 2?

Based on Magento official documentation,  a best practice to perform migration consist in two main steps:

  1. Build and test new Magento 2
  2. Migrate four components: data, extensions, themes, and customizations.

Step 1: Build and test Magento 2

To prepare for the migration, make sure you do all of the following:

  • Set up a Magento 2.0 system using a topology and design that matches your existing Magento 1 system
  • Provide back-up of your Magento 1.x database in case of unexpected issues. We advise you to replicate your Magento 1.x database and use this Magento 1.x data for your migration
  • Install Magento 2 on a system that meets our system requirements

Next steps

Follow the links below to learn more about each of the four components.

  • Theme Migration: Since themes cannot be migrated directly, there are two options provided by official documentation: you can pick an existing theme or work with a front-end developer to create a new theme based on your current theme.
  • Extension Migration: Most of third party extensions providers offer to updated version of the product. In case you want to migrate an extension created by yourself, just refer the next paragraph.
  • Customizations Migration: Most of the code wrote for Magento 1 is compatible with Magento 2, but for those customizations that need a migration, Magento provides a Code Migration Toolkit.
  • Data Migration: Data Migration allows you to migrate several types of data from your Magento 1 store to Magento 2 store. There is a CLI tool that will help you with the process, Data Migration Tool.

Conclusion

As I mentioned above, there is no right answer in choosing between the two versions of Magento as there are advantages and disadvantages to each Magento. If you are about to start a new project, I strongly encourage you to pick the latest, it is optimized to be used with PHP 7 + and nginx server and you will be able to enjoy the goodies of this product. And if you already has a Magento 1 store, sooner than later you will have to move forward, my advise is prepare a good plan for migration and go ahead, you always can outsource this process to an agency like Arroyo Labs.

I’m glad you’re still here! Thank you for reading this post. Please leave us with questions and feedbacks if there are any! Our future post will be about an example of extension migration.

Creating an AngularJS Feature Module with exported components & routing

Creating feature models in Angular JS is a powerful way to create re-usable software. How you expose the module is a very important step. We’ll explore some of the common ways to extend and modify co

Intro

The AngularJS framework is built upon the promise of modularity and we should always strive to write reusable code when applicable. The easiest way to accomplish this is by creating feature modules to encapsulate your services and components.

If you have been following along with our AngularJS series you will know that we have recently spent some time turning an application we created with Angular CLI into a feature module that we have published on npm. If you have missed them, feel free to read up here: Part One, Part Two.

In the code we discussed in our previous posts we explicitly exported our components & services for re-use (you can see this code here) in this post we will talk about why we did this and how to use this exported code. We will talk about how to extend and overload the exported routes and how to extend the provided components so you can add functionality after you import a feature module.

Scope & Encapsulation of your Feature Module

One of the biggest advantages to creating a feature module is that you can encapsulate your services from the parent application. This gives us a whole namespace to work inside and keeps the parent application free from some random services.

Exporting Routes

Routing is a VERY integral part of an AngularJS application because as your application becomes more complex, so will your routing scheme. There are two ways of getting routes contained in your feature module to the parent app module:

  • Lazy Loading
  • Exporting the feature module routes as another module

Plenty has been written on the subject of lazy loading, so I would like to focus on the second option.

This snippet illustrates our feature routing module:


import { AuthGuard } from './auth.guard';
...
import { UserListComponent } from './user-list/user-list.component';
...
// clang-format off
const userAdminRoutes = [
  ...
  {
    path: 'list',
    canActivate: [
      AuthGuard
    ],
    component: UserListComponent
  },
  ...
];
// clang-format on

export const UserAdminRouting = RouterModule.forChild(userAdminRoutes);

And this is how we export the routing module (in an explicit way) so we can use this in our parent application:


export { UserAdminRouting } from './src/user-admin.routing';

Exporting also allows you to add some routing on top of this exported module as well.

Here’s another snippet showing how we import this into our module and add a route not present in this routing definition:


import { NotFoundComponent } from './not-found/not-found.component';

// clang-format off
const appRoutes: Routes = [
  { path: '**', component: NotFoundComponent }
];
// clang-format on

export const AppRouting = RouterModule.forRoot(appRoutes, {
useHash: false
});

We can provide routes not originally provided by the package we import by adjusting the order of our imports. This is most easily explained by an example:


...
import { AppRouting } from './app.routing';

import { UserAdminRouting } from '@erdiko/ngx-user-admin';

@NgModule({
  declarations: [
    ...
  ],
  imports: [
    ...
    UserAdminRouting, // Import the package routes
    AppRouting // import our application routes
  ],
  providers: [
    ...
  ],
bootstrap: [AppComponent]
})
export class AppModule { }

Over-riding your routes with resetConfig

In the example above we show how you can add a route to your module’s exported routes if one does not exist. While this is great, this does not help you overload a route config module that already exists. What if you wanted to replace the “Home” route with a new component, or you wanted to redirect a user when they attempt to go to a route you wish to deprecate? Enter the “resetConfig” method.

This method, which the current AngularJS documentation that leaves something to be desired to say the least, allows you to “reset” your route config and push in new route definitions! If this sounds clunky, that’s because in my opinion it is, but this appears to work well. Let’s take a look at a snippet that improves upon the example above:


// Import Router and Route into your component
import { Router, Route } from '@angular/router';

// Import the component we wish to overload the existing route config
import { NotFoundComponent } from './not-found/not-found.component';

...

export class AppComponent implements OnInit {

// make sure we inject the router into this component
constructor(private router: Router) {

}

ngOnInit() {

 /**
  * Define a new route to overload the existing one for 'list' so
  * we can show the "Not Found" as an example.
  *
  * PLEASE NOTE: cast the object to a Route before attempting to add
  * this to your list of routes
  *
  */
  let r: Route = {
    path: 'list',
    component: NotFoundComponent
  };

  /**
   * call the resetConfig method and push in your newly defined route.
   *
   */
  this.router.resetConfig([r, ...this.router.config]);

  }

}

Here is what the route looks like based on the import routing config from `ngx-user-admin`:

Now here is the route after we use ‘resetConfig’ to overload it to display a component created in our Angular app:

Please note that this example shows a very simple example route defined in a component. It is good practice to move route definitions like this into a separate file for inclusion.

Exporting Components for reuse

It’s always a great practice to be explicit in what you expose to the parent application from your feature module. In most cases, you are creating a feature module to wrap a series of components and related services. The parent application really only needs to have the components exposed for use in its module.

Here is an example where we demonstrate exporting some components from our UserAdmin feature module in `ngx-user-admin`:


@NgModule({
  imports: [
    ...
  ],
  declarations: [
    ...
  ],
  exports: [
     HeaderComponent,
     LoginComponent,
     HomeComponent,
     ...
  ],
  providers: [
    ...
  ]
})

As you see above, we explicitly export our components exactly what we want to expose to the parent application.

Let’s take a look at the snippet below as a practical example of extending a feature module component and route config:

Here we create a new component to extend the existing feature module HomeComponent:


import { AppRouting } from './app.routing';

import { UserAdminRouting } from '@erdiko/ngx-user-admin';

// create a new component we created to extend the ngx-user-admin HomeComponent
import { MyhomeComponent } from './myhome/myhome.component';

@NgModule({
  declarations: [
    AppComponent,
    NotFoundComponent,
    // Include our new component
    MyhomeComponent
  ],
  imports: [
    // include the feature module
    UserAdminModule.forRoot(),
    
    // include the feature module routing defintion
    UserAdminRouting,
    AppRouting
  ],
  providers: [
  
  ],
  // add your new component as an entry point to the application

  // so the routing can access it
  bootstrap: [AppComponent, MyhomeComponent]
})
export class AppModule { }

From the previous example where a new route was created, we overload the “home” route to use the new component below. Now take a look at this new snippet where we overload the “home” route to use a new component:


ngOnInit() {

/**
* Define a new route to overload the existing one for 'Home' so
* we can use our newly extended component instead of the one from
* the feature module
*/
let r: Route = {
  path: '',
  component: MyhomeComponent
};

this.router.resetConfig([r, ...this.router.config]);

}

And finally here is our new component definition where we extend the feature module provided component:


import { Component, OnInit } from '@angular/core';

import { HomeComponent } from '@erdiko/ngx-user-admin'

@Component({
  ...
})
export class MyhomeComponent extends HomeComponent {

}

Here is what the “home” route looks like based on the import routing config from `ngx-user-admin`:

Here is what the “home” route looks like after we extend and overload the routing config:

Conclusion

As you develop Angular applications you will find yourself creating modules to encapsulate feature sets, common utilities and even define basic routes. How you export your code for use is dependent on your application and certainly affects how you can extend these for use in other AngularJS applications.