Magento 2.x Feature Requests and Improvements

Kruno · ‎01-02-2018

When creating tables in Module/Setup/InstallSchema.php I would like "Magento\Framework\DB\Ddl\Table.php" to support the JSON data type as it has its advantages. For DBs that do not have a JSON data type, they can default to text. At the moment I need to add my column manually to enable the usage of the JSON data type. $sql = <<<EOT ALTER TABLE my_table ADD COLUMN column_name JSON NOT NULL AFTER a_table_column; EOT; $connection->query($sql);

cjake · ‎11-17-2017

We use the salesShipOrder method to post shipping information to Magento2 from our fulfillment software. We're able to successfully create the shipment (along with carrier information, tracking numbers, customer notification), however there is not a way to indicate a shipment date (createdAt) for the package. When the post is made, it uses the current date/time as the shipment date, not the actual date/time that the package was shipped. We began using the salesShipOrder method over the salesShipmentRepository method to combat the Magento2 bug where order status is not properly updated. However this new method does not include the essential element for shipment date.

ashsmithio · ‎11-13-2017

One big issue I find when working with UI Components is that you end up writing deeply nested xml trees. These quickly become hard to read, and are really unmanageable. I'd like to propose two new XML nodes to be introduced: alias and referenceAlias. These would provide a mechanism for reducing the amount of XML I need to write and manage when working with nested components. Consider the following: <?xml version="1.0"?> <page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd"> <body> <referenceBlock name="checkout.root"> <arguments> <argument name="jsLayout" xsi:type="array"> <item name="components" xsi:type="array"> <item name="checkout" xsi:type="array"> <item name="children" xsi:type="array"> <item name="steps" xsi:type="array"> <item name="children" xsi:type="array"> <item name="shipping-step" xsi:type="array"> <item name="children" xsi:type="array"> <item name="shippingAddress" xsi:type="array"> <item name="component" xsi:type="string">Ashsmith_Checkout/js/view/shipping</item> </item> </item> </item> </item> </item> </item> </item> </item> </argument> </arguments> </referenceBlock> </body> </page> It's deeply nested, and all to common when all you want to do is replace a component or alter it's configuration in some way. The alias and referenceAlias solution would result in XML that looks like this: <?xml version="1.0"?> <page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd"> <body> <alias name=checkout_step_shipping_address path=“checkout.root/arguments/jsLayout/components/checkout/children/steps/children/shipping-step/children/shippingAddress” /> <referenceAlias name="checkout_step_shipping_address"> <item name="component" xsi:type="string">Ashsmith_Checkout/js/view/shipping</item> </referenceAlias> </body> </page> Immediately we have less depth, and can still get the job done. Our XML is easier to read and can be quickly understood by anyone jumping in. Furthermore, these aliases could be defined by the Magento core. They would serve as invaluable extension points for developers. Even better this feature request would not introduce any breaking changes. I go over this in a little more detail (and my reasoning behind it) over on my blog: www.ashsmith.io/magento2/suggestions-to-improve-ui-components/

vicary · ‎11-02-2017

When working with products regarding store context, there is inconsistency among Quote, Order and Invoice and Shipment items regarding the getProduct() method. The best implementation as of 2.1.7 is Magento\Quote\Model\Quote\Item\AbstractItem.php, where it supplies store id in the context of the quotation. I suggest that the model of Order and Invoice should follow such practise when getting product from underlying items, since developer expects a certain level of API consistency. I can make PRs if everyone agrees.

BenCrook · ‎10-31-2017

It would be great to be able to manually control the order of static assets added via XML, for example if you are loading 5 CSS files you can set the order they load in. At the moment this is out of a developers control, there are workarounds such as a adding an attribute but this still isn't very useful.There are extensions that add the ability to use so this is possible. Some useful links/discussions: - https://github.com/magento/magento2/issues/1821 - https://github.com/magento/magento2/issues/8406 - https://magento.stackexchange.com/questions/94769/what-is-the-proper-way-of-positioning-ordering-css-files-in-magento-2 - https://github.com/quickshiftin/mage2-ordered-assets I have heard this mentioned several times, in this instance a third party module is adding some CSS which is loading before the custom CSS therefore overwriting it.

brianlabelle · ‎10-18-2017

As a customer, I would like to sort my wishlist or requisition list items individually so that I can can group products together and organize my lists 1. Magento 2.2 w/B2B extension 2. While on a requisition list with more than one item 3. Dragging my items will change their order within the list 4. On drop, the item position will be saved via ajax 5. On refresh, my item positions will be preserved

Apfelschorle · ‎10-05-2017

Hello, Ive started developing magento2 and the cli tool is very nice and easy to use. But I was missing some tools for code generation like modules and themes. Everytime you create a module or theme you have to create the same boilerplate registration.php, module.xml and other config files. For example to create a new module: php bin/magento module:create Vendor ModuleName This code could be generated through the CLI tool. A good example is the @angular/cli tool for Angular.

andrewhowdencom · ‎10-02-2017

Broadly speaking, there is a few different ways of expressing application state in such a way that it's useful debugging: Logs (implemented in M2 with the excellent psr/log interface) Time series data (also known as metrics). Things like Data Dog, Promethiums, Sensu and so on. Traces; primarily expressed by opentracing.io, but also Zipkin, Lightstep This feature request is to track the implementation of #2; the expression of time series data in the application, as well as the export of this data via whatever mechanism might be setup to receive it. Time series data exposed by an application can provide extremely rapid feedback on an applications performance. This information can be used for a number of useful processes such as: Allowing infrastructure to make decisions around whether to modify the applications runtime environment Debugging the application performance during runtime Alerting when an application violates it's SLO Note: I am doing some work on this with PHP more generally tracked on github. Best place to contrib beyond core support is there. There is currently no simple way to express such time series data in Magento. There are several efforts that have been done to implement this in a third party, vendor specific way including: https://github.com/sitewards/magento-prometheus https://github.com/magento-hackathon/Hackathon_Datadog https://newrelic.com/partner/magento https://github.com/janpapenbrock/magento-statsd However, these suffer form a few drawbacks. In particular, There is no standard API (such as the psr/log api) that can be invoked in third party extensions reliably It locks the users into a hosting infrastructure; undesirable for the continuity of the project. Additionally, there are various metrics that would prove extremely useful when debugging Magento: Cache hit rates (https://github.com/magento/magento2/issues/11151) Cron metrics, such as last execution per job, queue length etc. Indexer status (expressed as 1 or 0) Cache enabled status (expressed as 1 or 0) Cache invalidations issued Orders in various states (processing, shipped etc) Customer logins (aggregate, not per customers) HTTP status codes However, the utilities aren't limited to the above. In particular, third party code often has reason to express it's health (such as the code developed by an agency) to ensure custom logic is functioning correctly, and that a feature is delivering sufficient value to jusify it's cost. General Background It is suggested the implementer have some experience implementing and using application instrumentation. There is a body of knowledge in this area that is immense of it's own right, and not a task that is so simple. Beyond that, the goal of the work should be to checkpoint the data, but defer all processing to the implementing time series databases. It should also have minimal impact on performance. Lastly, high cardinarily data can be expressed through logs or traces, and is perhaps not something that is easily expressed by time series metrics (though honeycomb et. al would beg to differ) Primitives The open source monitoring package Prometheus expresses the primitives: counter gauge histograma summary The author has implemented this in several places, and has found uses for counter and gauge in a repeated way, as well as a limited use for histogram. To begin, the implementation of "guage" and "counter" would be amply sufficient to justify the majority of cases. This is supported by both Prometheus and DataDog, and it's presumed the majority of time series databases. Non Goals It should not be a goal of this work to implement the metrics view in Magento. This can be approached as a separate task, but the primary intent of this work is to express time series data in such a way it can be consumed by third party services. It should not be a goal of this work to track the time associated with the time series data. The sampling is left to the third party application implementations. It should not be a goal of this work to instrument third party applications (redis). They have their own implementations, and should be considered separate services. It's unclear whether instrumenting the PHP runtime itself would be beneficial, though this can likely be handled in the bespoke cases it's required by third party utilisation of the above library. Interface Ideally there should be an interface similar to the psr/log exposed that allows the checkpointing of metrics. Something like: <?php class Foo { private $oMetricRegistry; /** * Dependencies automagically wired by DI */ public function __construct( // Singleton injected that stores the metrics. Invariably a global, persists towards the end of the request \Magento\Framework\Metrics $oMetricRegistry ) { $this->oMetricRegistry; // Ensure the metric exists. This operation is an idempotent "create if not exists" type operation. $this->oMetricRegistry->register( // metric identifier 'vendor_extension_foo_thing', // metric type. Can be one of "count" or "gauge"; potentially "histogram". 'count', // label keys. Labels are mechanisms to slice time series data, supported by both data dog and prometheus [ 'attribute' ] ); } public function doThing() { // An operation changing the state of the metric. In this case, an increment -- it's a count. $this->oMetricRegistry->increment( // The metric identifier 'vendor_extension_foo_thing', // The label values. ['value'] ); } } This would allow an extremely simple API to quickly expose the data for ingestion into time series. Storage Ideally, the storage engine should be pluggable, but implement: APCu In Memory (or "null" when considering parity with psr/log) Redis MySQL This would cater the wide range of hosting constraints that Magento can operate with, with a predisposition for not changing exising behaviour (checkpoint to memory but flush at the end of each request) Exposition There are various ways that the data may be exposed. It's suggested the core team deliberately not support any mechanim (except perhaps a native admin panel one, expressed as separate work). Instead, rely on third party / community vendors to provide the required libraries, similar to psr/log. Broader PHP community involvement It is the authors hope that this conversation is extended to the broader PHP community, perhasp through the involvement in FIG. A single interface for time series data would have ramifications for the langauge more generally. Future Work Once implemented, Magento's introspectability could be extended further by implementing traces. Related Reading: http://www.brendangregg.com/usemethod.html https://prometheus.io/docs/introduction/overview/ https://github.com/DataDog/php-datadogstatsd https://github.com/Jimdo/prometheus_client_php

Navarr · ‎08-24-2017

Similar to #9582 - we should eliminate the complicated necessary inheritance for creating Imports and Exports that plug-in to DataFlow

DominicW · ‎08-23-2017

In magento 1 X.commerce produced the following guide http://info2.magento.com/rs/magentosoftware/images/magento-extension-developers-guide-v1.0.pdf Its approximately 70 pages long. I found this invaluable in learning how Magento 1 worked. Put simply it was a short guide that produced an extension from start to finish teaching many basic principals of Magento 1 such as: Code setup and configuration - code structure Design setup - templates and layouts Frontend development - database schema, models, output (blocks), routes, helpers, sample data Backend development - admin configuration, routes, models, output (including grids), helpers, ACLs I believe where this guide succeeds is that it carries a single example across many topics. More importantly it has the right level of detail in terms of producing something useful yet not too much to becoming obsolete overnight. And it focuses on magento in terms of PHP development unlike some of the books I've read through which cover a far wider range of topics and often include a few chapters on installation and setup for example. I realise that Magento 2 is technologically more advanced and perhaps this is too difficult to achieve. However reading through the developer docs many areas still seem disjointed (and by this i mean a common example which is carried throughout - not simply a collection of snippets of information) and I feel it would be really helpful if an all-in-one guide extension guide was put together not only for me but to help the greater community. To give you a bit of history I'm a competent Magento 1 developer but I'm finding some Magento 2 concepts difficult to follow. I'll be honest I've seen https://u.magento.com/training/schedule/ and I believe your pricing will stall the adoption of Magento 2

Wouter Samaey · ‎08-20-2017

Magento 2 stores files on disk in the /media dir, but this makes multi-server setups more complex as this dir needs to be shared by all machines. At the same time, cloud storage is very flexible and scalable (no more running out of disk space for example). By implementing Gaufrette, a well-known file system abstraction layer from the Symfony world, we can put our media files anywhere we like, including S3, Google Cloud, FTP and countless more places. And should a developer ever need more than this, a custom file system can be developed easily too.

kanduvisla · ‎07-06-2017

Bumped into this one yesterday. At our company we like to use semantic correct names for our attribute codes. With middle- to larger sized shops these names tend te be somewhat longer. Attribute codes in Magento 2 are not allowed to be longer than 30 characters. Can anyone explain to me what's the reason behind this? Is there a technical one? Or is it just that someone thought at some time "30 characters ought to be enough for anyone"? I'd really like to know.

MidnightDesign · ‎06-22-2017

(From https://github.com/magento/magento2/issues/7852) Steps: Run "bin/mage module:disable Magento_Review" in a standard Magento installation Actual Result: The module can't be disabled because Magento_Customer depends on it. Expected Result: The module Magento_Review is disabled. Is it really necessary that the Customer module depends on the Review module? It's the only reason why I can't disable the Review module and a quick search for "Magento\Review" in the Customer module's codebase reveals that only a single file references a class in Review: \Magento\Customer\Block\Adminhtml\Edit\Tab\Reviews. I'm sure this can be refactored to remove the dependency, right?

maultby · ‎04-19-2017

Magento 2 REST API get website_ids for product Please provide additional GET REST API method on catalogProductWebsiteLinkRepositoryV1 to allow us to retrieve the website_ids for an sku. Or instead include the website_ids for an sku in catalogProductRepositoryV1 get /V1/products/{sku}

nmulder · ‎03-29-2017

Currently the rest API doesn't send a websiteId attribute when you request a product.This would be really usefull for developers.

maultby · ‎03-28-2017

Mag V2 is missing the magentoInfo method that is available in Mag V1 APIs. Please add this to Mag V2 REST and SOAP APIs. It is necessary for feature validation when writing third party integrations.

michalhosna · ‎03-16-2017

When i have two classes. One extending the other. class Foo { //Some code } class Bar extends Foo { //Some other code } It's common practice to pass Bar instance to functions that requires instance of Foo. For example: magicFunction(Foo $instanceOfFoo){ .... } $instanceOfBar = new Bar(); $result = magicFunction($instanceOfBar); But, auto-generated factory of Bar doesn't extend from Foo autogenerated factory, so you can't do this: magicFunction(FooFactory $instanceOfFooFactory){ .... } $instanceOfBarFactory = new BarFactory(....); $result = magicFunction($instanceOfBarFactory); I think that auto-generated factory of class, that extends some other class, should extend the other class factory as well.

michalhosna · ‎03-16-2017

All auto-generated factory classes, should implement common interface. All factories, have to have public function create(array $data = array()) method anyway. So why they do not implement some common FactoryInterface interface?

kanduvisla · ‎03-06-2017

When you look at app/etc/config.php you see all the modules that are installed. However, whenever a new module is installed or upgraded, the sort order of this file is scrambled. I don't know if this is necessary or not, but it sure as hell makes version control a nightmare: Is it possible to always make sure that this list is ordered alphabetically? It makes resolving merging issues a whole lot easier.

Jezza5 · ‎02-28-2017

It would be so useful to be able to adjust the columns data eg stock levels, quantity and price on the catalog page rather than having to open each individual product.

Magento 2.x Feature Requests and Improvements

Support for JSON Data Type in MySQL.

REST API: Add Ship Date to salesShipOrder

New nodes in Layout XML to make UI Components more managable

Consistency among getProduct() method in quote/order/invoice items

Static asset / css load order

Sortable RequisitionList Items

CLI Module, Theme and other Component generation

Create a mechanism to checkpoint time series data for use in the codebase.

Eliminate the need for inheritance for imports & exports

A PHP Developer guide with an Example Magento 2 Extension with best practices

Implement Gaufrette for /media file storage abstraction

Why are attribute codes limited to 30 characters?

Remove dependency of Customer module on Review module

Magento 2 REST API get website_ids for product

Add websiteId to products in rest API

Add Mag V1's magentoInfo method to V2 REST and SOAP API

Auto-generated factories should extend each other.

Autogenerated Factories should implement common interface

Alphabetical ordering in app/etc/config.php

Be great to alter product info on the inventory catalog page