Public Magento 2 Interfaces

  • Products
  • Product Attributes
  • Product Attribute Types
  • Product Attribute Media Gallery
  • Product Links
  • Categories
  • Category Attributes
  • Category Product Links
  • Directories
  • Files

It’s SAFE and highly encouraged to use these classes in your work injected to your own classes.

All developers can contribute to this page and it’s highly appreciated. When adding new items, please make sure your description is clear and consistent, it will help other developers in their work immensely and save hours of investigation.

Please be discrete; this page must not contain arbitrary “useful” classes and interfaces, only those which fit the following note.

This section mentions only STANDARD Magento 2 interfaces, marked with @api annotation (otherwise called Service Contracts), or classes PREGENERATED by Magento internally.

Products

Interface

Description

\Magento\Catalog\Api\Data\ProductInterface

A product entity interface. Represents the product model. You should NEVER instantiate implementations of this interface (for example, \Magento\Catalog\Model\Product) directly. You should always use the ProductFactory::create() method.

\Magento\Catalog\Api\ProductRepositoryInterface

Products repository is responsible for implementing CRUD and also to list a collection of products. Note that by default SKU is used to get an item, use getById() to fetch an item by the internal ID.

\Magento\Catalog\Api\ProductManagementInterface

An instance of this interface would have a product collection injected. The only method, getCount($status), would return a number of products filtered by a specific status, or not filtered at all. It’s impossible to modify a filter with something else directly.

\Magento\Catalog\Model\ProductFactory

This class doesn’t exist in the codebase, it’s being generated during code generation. Generates instances of \Magento\Catalog\Model\Product on demand.

\Magento\Catalog\Model\ResourceModel\Product\CollectionFactory

This class doesn’t exist in the codebase, it’s being generated during code generation. A product collection factory that is used to instantiate concrete product collection instances.

Please note that product collection is not considered standard, it doesn’t have a service contract defined. In common cases, if you need to work with a list of products, use \Magento\Catalog\Api\ProductRepositoryInterface::getList(), otherwise instantiate product collection using this factory injected into your service class.

Product Attributes

Interface

Description

\Magento\Catalog\Api\Data\ProductAttributeInterface

A product attribute interface. Represents the product attribute model. You should NEVER instantiate implementations of this interface.

\Magento\Catalog\Api\ProductAttributeRepositoryInterface

Product attribute repository is responsible for implementing CRUD and also to list a collection of product attributes.

\Magento\Catalog\Api\ProductAttributeManagementInterface

This interface implements getting a list of attributes from an attribute set, assigning and un-assigning the attribute to/from specific attribute set.

Product Attribute Types

Interface

Description

\Magento\Catalog\Api\Data\ProductAttributeTypeInterface

A product attribute type interface.

\Magento\Catalog\Api\ProductAttributeTypesListInterface

Implements fetching a list of product attribute types. 

Product Attribute Media Gallery

Interface

Description

\Magento\Catalog\Api\Data\ProductAttributeMediaGalleryEntryInterface

Implements a media gallery entry for a gallery attribute. 

\Magento\Catalog\Api\ProductAttributeMediaGalleryManagementInterface

A media gallery entries management interface, implements methods to create entries, to fetch, update and remove them, as well as getting a list of media gallery entries by specific product SKU.

Product Links

Interface

Description

 

 

Categories

Interface

Description

\Magento\Catalog\Api\Data\CategoryInterface

A category entity interface. Represents the category model. You should NEVER instantiate implementations of this interface (for example, \Magento\Catalog\Model\Category) directly. You should always use the CategoryFactory::create() method.

\Magento\Catalog\Api\CategoryRepositoryInterface

Categories repository is responsible for implementing CRUD and also to list a collection of categories. It alternatively provides a way to delete by a category object, or by category ID.

\Magento\Catalog\Api\CategoryManagementInterface

An instance of this interface would have a category collection injected. There are three methods implemented:

  • getCount() — returns a number of categories with parentId > 0
  • getTree([$rootCategoryId], [$depth]) — builds a subtree of categories for specific parent and specific depth (if provided)
  • move($categoryId, $parentId, [$afterId]) — moves the category across the category tree. If $afterId is not specified, doesn’t rearrange the order.

\Magento\Catalog\Model\CategoryFactory

This class doesn’t exist in the codebase, it’s being generated during code generation. Generates instances of \Magento\Catalog\Model\Category on demand.

Category Attributes

Interface

Description

\Magento\Catalog\Api\Data\CategoryAttributeInterface

A category attribute interface. Represents the category attribute model. You should NEVER instantiate implementations of this interface.

\Magento\Catalog\Api\CategoryAttributeRepositoryInterface

Category attribute repository is responsible for getting an instance of an attribute and also to get a collection of category attributes. It does not provide full CRUD interface.

Category Product Links

Interface

Description

 

 

Advertisements

Migrate Existing M1 Customer to M2

Backend Estimations

Overview

We got the task to estimate a migration of Björn Borg to Magento 2, here is how we attacked the issues and what we learned from it.

First thing to do is to explain to the customer that this is not a simple conversion, it basically means writing the entire thing from scratch, with other base modules and a new theme. So it’s a large project, however you choose to look at it.

 

Step 1 – Create a list of all installed modules

When the list is complete, you are pretty sure you won’t miss any features (we assume the M1 site is an AJA project).

Add all modules to a document. In Björn Borgs case it was over 110…

Step 2 – Create a list of major functions

Look both at frontend and backend, make a list of what you think are major features.

Major features could be: Integrations, Checkout, Payment and Shipping methods used, custom modules, Themes, External modules used for example Search etc

Now take each major function and add the modules you think belong to that major function, for example like this:

INTEGRATIONS

Modules involved

 

Module

Comment

vaimo/navisionfile

Integration code for Björn Borg

icommerce/integrationcontroller

Toolkit

icommerce/attributebinder

Binding certain attributes to a smaller set ot attributes

icommerce/categoryattributebinder

Same as above, but for categories

icommerce/scheduler

Runs tasks at convenient times

icommerce/utils

Toolkit

vaimo/lib

Toolkit

icommerce/configurablebinder

Toolkit to bind configurable products to simple products

Step 3 – Examine the list of modules not included in any major function

Make a list of all modules to remove, you can make one for frontend and one for backend.

In that list you place all frontend support modules, for example page manager, quick view, wysiwyg, jquerypack etc

All backend tool modules, such as default, redis, mlib, utils goes on the list

All modules that are installed but not used, for example payment methods, goes on the same list

Step 4 – Examine the list of modules now remaining

Go through all remaining modules one by one, figure out if they are needed and in use. If you are unsure, discuss with the customer if they think they use it. Move any modules no longer used to the list of modules to exclude, with a comment why.

Split the remaining modules into two lists, modules that we already have a M2 replacements for and modules that don’t.

The large task there is to find the modules, which will be a smaller task if we keep the M2 module list up to date.

Step 5 – The customer specific module

All installations have their own highly custom module called something with their name, in our example Vaimo_BjornBorg. It is a collector for many minor and some major features, that just isn’t large enough to end up in it’s own module. This module is usually very difficult to estimate. The important part is to exclude all frontend type of code when considering the size of this module. Any frontend requirement for M2 will be very different from M1, frontend support modules should be treated as a blank page.

Björn Borg custom module was filled with Widgets, triggers, mini routines etc. You can sit down and estimate each features if you want, but I did not, I made that a time bank type of estimate. This time bank should be used for supporting frontend and to transfer all those mini backend functions they really do use and need. That time bank can not be a fixed amount that you aren’t allowed to pass, it should simply be a “we are confident it will be enough, but if we see we will pass this limit, we need to have another meeting”, type of time bank…

Step 6 – Frontend

The theme for M2 will be a brand new one, all the tools we use to build the new theme will have nothing in common with the old M1 installations. That’s why frontends estimate will be very important and also very tricky.

Therefore, any modules or major functions related to Theme, Checkout or Ajax features, should simply not be part of the backend estimate. It makes no sense. They should be kept in the document, for reference, but it should be clear that these modules and major features will be part of the Theme/UX estimates.

Step 7 – Finalise module list

If you follow the above mentioned steps, not only will you now have all modules in neat little lists, you can not have missed any, which is very important.

Now each module and major function needs an explanation and a comment on how to attack the rewrite to Magento 2. Following the integration example mentioned above:

Description

Integration with Navision. Exporting orders, importing products, shipments and stock levels.

Rewrite to Magento 2

Using vaimo/module-integration-base as the core toolkit we will write this custom integration from scratch, with the knowledge of the existing formats in mind. If Navision can change the format to work with our standard XML formats, the estimates made for the integration will be substantially reduced. 

Step 8 – Data Migration

Moving from M1 to M2 is a little bit of a nightmare. Magento has built a migration tool that I have just looked at very briefly, but judging by some comments, it’s not the solution to everyones problem. It can help, but it won’t solve everything… My estimates on this could be very wrong.

I have suggested to migrate non-transactional data, such as Products, Categories, Customers, Stores etc. URL Rewrites is also part of this “core” type migration. Price Rules are usually not that many to make a migration for, so I suggested to transfer them manually.

I also suggested we do NOT migrate any transactional data, such as Orders, Payments, Invoices, Shipments and Quotes. One very important point here is payment methods. You are unable to open an order if the payment method it was placed with, is not available in Magento. Some payment methods will change, some are called different even if they are the same etc. So actually moving orders might just prove contra productive, since you can’t open them anyway… And even if you could, the payment method you have for M2, might not work the same way as it did in M1, so you probably won’t be able to capture or credit anything placed in M1.

To solve that, I recommended that we keep the M1 site running, behind password protection, to ship and capture manually, until all orders are dealt with. Future credit notes on old orders can either be dealt with inside the payment gateways, or in the old installation. The integration will NOT be up between old site and their ERP, all this has to be done manually, during the transition period.

I urge anyone to have any actual hands on experience with the Magento Conversion tool to spread some wisdom of it’s quality.

Step 9 – Estimation

 Each major function will get it’s own estimate, same with the list of modules that are needed but haven’t yet been written for M2. You should also try and find external modules that might solve things in a similar way, that might be an option to use, instead of migrating an old Icommerce module to M2.

After working a little bit with Magento 2 I noticed that working locally is a lot slower than working with M1, it’s also new code to most people, so do not be optimistic on your estimates. I usually am, but in my two M2 estimations so for, I have taken the estimate I might consider for M1, increased it a little and then increased it some more… Well, not in all situations, but pretty much. When we get more experience, the estimates will go down I’m sure, but no good will come from being optimistic when estimating M2 projects. Especially if the team is new to M2.

It is not simply an update of a site, it is a lot closer to a brand new installation than it is an update, therefore we should treat it as such as well, also in our estimates.

Give the customers choices in the estimations, for example option 1 is for Vaimo to build module X while option 2 could be for the customer to purchase the official module XY that probably does the same, but slightly different.

Step 10 – Confere

Discuss your estimates with a colleague, explain why your estimates are as they are, double check that all modules you say doesn’t exist in M2 in fact doesn’t (and of course vice versa). Feedback from someone else is very important and can give good insights of things you might have missed.