About Magento 2.x Feature Requests and Improvements
Do you have ideas for new features, improvements to current features, or other suggestions for Magento 2? Then share your ideas in this forum! We love hearing about ways we can improve your experience working with Magento.
Before submitting an idea, be sure to check to see if a similar request has already been posted. You can add your endorsement and comments rather than creating a duplicate submission.
We want to use single image for multiple products to avoid image duplication in pub/media/catalog/product folder. What we understand today is when we import same image for multiple products Magento will create separate directories for each product and copy the same image to each directory. Can we improve this process to have single directory created for both the product which has same image and copy this one image only once to that directory and this used by both the products?
... View more
Feature request from gigadesign1, posted on GitHub Jan 09, 2016
I use a lot of configurable products in combination with tier prices.
The configuration of prices used to be in the configurable product in Magento1.
Now in Magento2 when I want to update the tier prices of my product, I have to edit every single simple product.
Since we have a product in 32 different colors and 3 sizes (so 96 simple products), this is not really user-friendly.
The default price can be configured by selecting a attribute in the configurable product.
It would be great if tier prices can be configured there too!
Or at least through mass-updates of attributes.
... View more
Hi, Is there any plan to include Store pickup feature in Magento Community Edition? If yes, then in which version is it planned to release and also what is the date of release. I am waiting for this feature since long....
... View more
Feature request from airbone42, posted on GitHub Jan 21, 2015
PHP 5.5 introduced a new password API natively to PHP. http://php.net/manual/en/book.password.php
As using BCRYPT for the default hashing algorithm it's not only more secure than the current implementaiton of md5 and sha256. But will even be automatically maintained with newer PHP versions and does not depend on any maintenance or upgrades by Magento.
So my suggestion is to replace the current hashing implementation in the Encryptor with using native password_hash and password_verify. Especially for an e-commerce system security should have a very high priority.
So rumors tell that Magento 2 will soon raise min. requirements to PHP 5.5, so that would be the best point to integrate this. Anyway if that min. version update might not come there's also a backward compatibility library available at https://github.com/ircmaxell/password_compat which could be used for PHP <5.5.
If Magento needs MD5 and SHA256 for b/c to Magento 1 hashes, I would suggest to move that into a separate module, so new Magento 2 shops without old data don't need to bother about this old hasing algorithms and the code coming with it. Even shops with older Magento 1 data could remove that b/c module after all customers have updated their password over time or by enforcing them after the first login. This reduces amount of code and complexity, buy having these Mage1 b/c modules and migrations optional.
Anyway, would Magento be interested in porting the Encryptor into that way? If it will get accepted I would definitely dig into this and try to create a PR to speed up development.
... View more
A big restriction in Magento is that it is not possible to use store view codes multiple times for different stores / websites. For example this should be possible: www.store1.com/en www.store1.com/de www.store1.com/nl www.store2.com/en www.store2.com/de www.store2.com/nl www.store3.com/en www.store3.com/de www.store3.com/nl But this is not possible, because the store view code must be unique. Now we have to do something like this: www.store1.com/en www.store1.com/de www.store1.com/nl www.store2.com/eng www.store2.com/deu www.store2.com/nld www.store3.com/l_en www.store3.com/l_de www.store3.com/l_nl And this just doesn't make sense. It would be nice to have the possibility to use store view codes across different websites / stores. Or to rewrite the storeview codes on the frontend, something like this: code - rewrite to eng - en fra - fr deu - fr english - en french - fr german - de
... View more
Allow a customer-level setting that enables/hides payment methods. For example, I have a small number of customers who cannot be removed from their price group, but who I want to force into Proforma Invoicing rather than Creditcard. By linking the payment method to the price group, I have to double up the number of price groups, one for normal people and one for those with bad credit etc.
... View more
Hi Guys, I would like to request a new improvement for the checkout. Currently users could have trouble finding out about invalid fields which disappear above the screen fold. Scenario: User fills out his address information Scrolls down below to submit the form and go to the next step. Hey! The button is not working. Weird... When the invalid fields are not visible because they are above the fold, the end user is not notified of the problems with his information. In some cases the user may be smart enough to scroll up and see if there are invalid fields, but you may understand that not every user is thinking about doing that. Possible solution Automatically scroll to the first invalid field on the page Notification message below the submit form to inform the user that he has to fill out his invalid forms. I am curious about what you guys think of this user experience issue. Cheers, Clarke
... View more
The "Update" button for the billing address field is completely counterintuitive and bad user design. Customers do not expect to need to (and should not have to) hit an "Update" button for their billing address to take on an order. We've taken hundreds of calls from customers who don't understand why their billing address is incorrect on their order. It would be much more intuitive if, when the checkbox for "My billing and shipping address are the same" is unchecked, address validation on the billing address ran when the customer clicked the "Place Order" button. Conversion rates go down for every step you put between a customer and hitting the "Place Order" button. This counterintuitive "Update" button step undoubtedly has a negative effect on conversion rates and should be fixed.
... View more
The suggestion is to establish a pattern of adding the following code to deprecated functions: // This is just an example. Write whatever -- something to point people in the right direction.
$sMessage = 'save() has been deprecated in favour of using the usage of repositorties, and the deferral of persistence to the persistence layer. See https://h.dev.magento.com/repositories for further details'
@trigger_error($sMessage, E_USER_DEPRECATED); This can be introduced harmlessly to the stack, and does not actually change any error behaviour, or make the deprecated methods more fragile. However the error handler indicated by set_error_handler() will be called; allowing the surfacing of the deprecated methods. This is useful in a couple of ways: Tests can stub the error handler such that it propagates these error messages and fails tests. This clearly indicates that the code is no longer valid. The error handling function can be modified such that in developer mode these errors are surfaced to the user, and either halt execution or are simply logged to the debug log State of "known violations" can be tracked (perhaps simply with a try_catch in tests, with a skip or the like). This means that any new code must either violate the deprecation intentionally (picked up in review) or fail tests (picked up in CI) This pattern has been previously established by Symfony and appears to work as expected there. Such work will allow enforcement of deprecation; something that has proved problematic in the past (particularly in code review where it's not apparent that used functions are deprecated)  http://uk.php.net/manual/en/language.operators.errorcontrol.php  https://twitter.com/andrewhowdencom/status/900675010641133571  https://github.com/symfony/class-loader/blob/b94aa5c3608cd53444fc4c7a2a506d163eb4a8f3/MapClassLoader.php#L14
... View more
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
... View more
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
* Dependencies automagically wired by DI
public function __construct(
// Singleton injected that stores the metrics. Invariably a global, persists towards the end of the request
// Ensure the metric exists. This operation is an idempotent "create if not exists" type operation.
// metric identifier
// metric type. Can be one of "count" or "gauge"; potentially "histogram".
// label keys. Labels are mechanisms to slice time series data, supported by both data dog and prometheus
public function doThing()
// An operation changing the state of the metric. In this case, an increment -- it's a count.
// The metric identifier
// The label values.
} 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
... View more
Feature request from hostep, posted on GitHub May 09, 2015
This is mostly based on Magento 1 experience, but it looks like not much has changed in Magento 2 currently (testing 0.74.0-beta8).
I'm not a VAT expert, I'm simply getting this from feedback we get from store owners who complain about how bad this is currently implemented in Magento 1. So with Magento 2, it would be a good idea to try to get this right from the start.
Here are some suggestions, please review them, maybe there are better solutions then the ones I'm suggesting ...
If you go through the checkout, you should get instant feedback when you enter a VAT number if it is valid or not, and not after you go through the whole purchase process and it is too late. With the instant feedback you can correct your VAT number before purchasing if you made a typo.
We have experienced a lot of issues with the VAT API service which is currently used in Magento (= VIES VAT number validation), it happens very regularly that the API service is down or times out. So you should think about some kind of way to handle this. Maybe there are alternative API services? Maybe you can do a first preliminary check using regular expressions before going to the API service to lower the load on the service? Maybe add a switch in the backend where store owners can choose what happens when the API service is down: allow the customer to proceed, or let them try again until the API service is back up?
Right now you aren't allowed to enter your country prefix in front of the VAT number, since it uses the country from your address. I believe you should clearly state this in a line of text or in a tooltip or something like that, so the customers know what to enter. Also: it makes a lot more sense to put the VAT number field after the country selector field, because it depends on that value (the same thing applies to the state/region field, but that's another issue).
If others have some opinions about these issues or have other suggestions, please leave a comment, so we can try to improve how Magento 2 handles the EU VAT number validation.
Credit where credit's due: most of these suggestions come from a commercial extension we used a few times in the past: https://www.geissweb.de/eu-vat-enhanced-magento-extension.html, but since the current implementation in Magento is pretty broken, we shouldn't depend on an extension to fix these bugs in Magento I believe?
... View more
Hi, I am facing a problem with configurable products. If you create a configurable product and create some product variations based on lets say color & size, if you change the price and image for a specific variation and select this variation on the configurable product page, the price and image will change. This is a very good feature altough the expected behaviour for me would be that the description and specifications for this selected variation would be shown, in stead of the specifications of the configurable product itself. Why does it change the price and image, but not the description and product specifications? I attached a screenshot to give you an idea of the issue. I also used to have this problem in Magento 1 and found a module for this which solved the problem. However this module is not supported for Magento 2. https://www.magentocommerce.com/magento-connect/sdocp-simple-details-on-configurable-products-1.html Is there a way this can be done programmatically or fixed in the core? Kind regards, Falco
... View more
We need an alternative to the customer email login which is phone number login. It may not sound useful in Western countries but in China, it's necessary. Chinese people only use this login method with Taobao (taobao.com), Tmall (tmall.com) or JD (jd.com), they are used to it. Without this basic option, Magento 2 will never make it in China.
... View more
Feature request from aleron75, posted on GitHub May 10, 2016
this is not something which doesn't work but something that doesn't work as expected, so feel free to take it more as a suggestion than as a bug.
As stated in the title, I expected dates saved in UTC just like in Magento 1 but it doesn't seem to work this way in Magento 2.
What's more, the \Magento\Eav\Model\Entity\Attribute\Backend\Time\Created and \Magento\Eav\Model\Entity\Attribute\Backend\Time\Updated attribute backend models don't seem to have the same logic implemented (even if I don't think that any default attribute use them at date).
You can read some considerations and suggestions here: http://magento.stackexchange.com/questions/114706/magento-2-best-practice-to-get-current-date
... View more
Feature request from webtekindo, posted on GitHub Feb 10, 2016
It should be nice to have an option in Admin to display price range for configurable products instead of only displaying the minimal price.
50$ - 90$ (minimal price) - (maximal price)
That range may be display on the product listing, and on the product page when no options selected yet
I beleive many companies have use cases on which they use the configurable product type, but price may vary a lot depending on the configurable options.
... View more
Feature request from hostep, posted on GitHub Aug 17, 2015
Why is the telephone number still required on a customer address?
We hear from our shop owners that a lot of customers refuse to enter something in there or just enter gibberish.
An ideal solution would be if you could add a configuration option in the backend similar to the Gender , Tax/Vat Number and Date of Birth fields.
So an option for showing the telephone number where you can choose between No , Optional or Required . What do you think?
I had to implement this today into a Magento CE 1.x store and it was kind of a terrible experience, changing stuff in the database, remove the hard coded validation of that field (which is still present btw: https://github.com/magento/magento2/blob/93312cae42824274722fe7a285d5ce8e40f177a1/app/code/Magento/Customer/Model/Address/AbstractAddress.php#L572), ...
Related to https://github.com/magento/magento2/issues/624
... View more