Recent Posts


Going to the Moon for a Loaf of Bread


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!

Back when Magento 2 was released, I noticed the much touted API didn’t have a method for fetching a product’s canonical URL. A year later that’s still the case. Magento’s reasoning and response, both from an engineering perspective and a product perspective points to a big cultural problem that goes beyond this one small issue.

The engineering team’s response –

Regarding the groundwork for adding Product URL to the ProductInterface.
For now Magento Data interfaces contain entity’s data, and Service Contracts operate with these data. We don’t have services for presentation layer.
Similar issue we have in Customer module, where CustomerInterface provides dedicated methods getFirstname() and getLastname() but most of the business logic needs specific representation – full name (which is a composition of Firstname + Lastname), so we have a Helper

MagentoCustomerHelperView::getCustomerName(CustomerInterface $customerData)

And most of the external modules use this helper to get full name. So, in fact modules are dependent on “private” implementation, but not on the Customer’s service contract which is wrong.

Here is the same story with Product URL, as URL is not data, but some kind of data representation. Moreover, URL doesn’t represent just product data, as “base_url” part belongs to configuration, so product agnostic.

Adding Product URL to ProductInterface actually means – introducing of concept read-only attributes to our Data Interfaces. As we can’t allow to modify product URL by direct setter function call through the ProductInterface. Which is not supported on the level of framework now.

– boils down to “Our conceptual software architecture is more important than our user’s real need for a feature”. If ever there was an example of Architecture Astronauts creating unnecessary barriers, this is it. There’s a certain satisfaction, even work ethic, that comes from strict adherence to these sort of architecture rules, but this sort of inflexibility can send a platform off the rails.

The product team’s initial response is equally worrying

I don’t believe we support that feature. what use cases do you need to support so an API call returns the product page’s URL?

I once heard someone say the three most important things for a product team are

  1. Know the problem you’re solving

  2. Know who you’re solving it for

  3. Know how you’re going to measure success

That these sorts of use cases never came up during Magento 2’s extended gestation period, or that they were discarded, points to an organization that’s either disconnected from its user’s needs, has its eyes on another set of users, or both.

Neither of these are necessary a terminal case for Magento the company, but for developers, new or old, this means most of our time is spent chasing down weird edge cases and gaps in Magento 2’s functionality. This time could, and would, be better spent building new features for our clients and users. Instead of our tool (Magento) being an ally, it ends up being the fly in our ointment that we can never completely trust. That’s not the sort of technology platform that inspires new developers, or engenders long term loyalty.

I’m torn writing this post, because transparency is always a good thing. To seemingly punish that transparency with an accurate-but-not-positive critique won’t encourage more. There’s a tremendous number of hard working, talented, thoughtful people inside Magento, but right now their talents and energies seem targeted elsewhere, and there’s only so much the external Magento community can do on its own before dissolving in the winds of change.

Copyright © Alana Storm 1975 – 2023 All Rights Reserved

Originally Posted: 16th December 2016

email hidden; JavaScript is required