“I secretly wish Magento dropped the newsletter functionality entirely. It’s misleading merchants to think its suitable for email marketing” – Ashley Schroder ‏@aschroder.

Ok, so let’s ignore the bit about publicly tweeting a secret wish (!!) and talk about how this can be achieved. But before I do so, another relevant tweet in response.

“Have suggested that several times. Answer is: hard to kill a feature. Only the subscription API is really needed for integration” – Brendan Falkowski ‏@Falkowski.

Yes, it is hard removing features. But there are ways it can be achieved. Here are several levels of involvement, where more involvement is more likely to get your idea done.

Submit an Idea

The easiest way of course is just to submit a feature request on GitHub. It will be reviewed. It might get done, it might get rejected. But if you suggest something and 5 others suddenly agree, as you can imagine it will be looked at more seriously.

However, this is not a request to flood GitHub with marginal requests that are never likely to be done. That would slow things down and not improve things. What I am suggesting is if you have what you believe is a strong justification for a change, others may have it too. Including your reasoning in the request. If its just a random idea, please think whether you really think the team should spend time investigating the idea rather than working on something else for Magento 2. Maybe sleep on it. If you still think its a good idea the next day, then consider submitting it.

Submit a Solution Design

One step further than just saying you want something (and why), why not do a bit of analysis and submit that with your request. That is, don’t write all of the code required but do some of the analysis and design leg work to work out ways to solve the problem.

For example, in the particular case of the tweet, the Newsletter module has a number of other modules that depend on it. If these dependencies were removed, then Magento 2 can ship the Newsletter for backwards compatibility but a site can easily remove it. So why is it not optional today? Dependencies from other modules I can currently see include Customer, CustomerSegment, GiftRegistry, Invitation, Review, and Reward. Customer is a killer – all Magento sites will have the Customer loaded.

Let’s dig into Review. Looking through the code, there is only one dependency on Newsletter. The Review module creates a subclass of a Block from Customer, and to create the parent class it needs a SubscriberFactory instance. Looking in Customer, you can see some calls to wish list and to display subscription data. So eliminating the Customer dependency on Newsletter would also remove the Review dependency.

If you think about it, having a core module like Customer depend on Newsletter is not ideal. Instead, it would be better if the Newsletter module extended the Customer module. For example maybe the Newsletter module should use layout instructions to inject additional blocks into the Customer layout. Or maybe it should use a plugin or event handler.

I am not trying to propose a solution here for this specific problem. But hopefully it is clear that some analysis is required to work out the right way to eliminate such a dependency. A proposal that describes a series of changes to be made to a list of files (layout file changes, changes to blocks and constructors, which classes should move to a different module, maybe even an existing module should be split in two to localize dependencies etc) without actually making the changes in code is still useful. Frequently changing the code itself is the quick part. So if you are keen to make a module optional, why not think about how to refactor the code to eliminate the dependency and include that with the proposal.

Submit a Pull Request

The ultimate is of course to submit code that solves the problem. This can reduce the core team’s effort to get the change into the product. The risk is you make the change in a way the core team does not approve. I don’t have a great answer for this – the core team do want to protect the code. My best advice if you are really keen about an idea, tell the core team you are going to work on it early (to get feedback on likelihood to be accepted), then be prepared for a few iterations of review before it is accepted. This happens internally – we put external contributions through the same rigor.

Conclusions

The Magento code base has evolved over a period of time and has undesirable dependencies as a result. If you take the approach of being willing to edit the core code base, you can remove these dependencies for a specific site. A goal of Magento 2 is to stop this behavior to simplify upgrades and patching. This can be achieved by refactoring the code to get the dependencies correct. It is fine for Newsletter to depend on Customer, but it is strange that Customer depends on what feels like it should be optional functionality provided by Newsletter. So change the code in a way to achieve this.

The core development team has already removed a number of such dependencies and cleaned up the modularity of the code base in areas. For example, Shipping now has USPS, UPS, etc shipping modules as optional. It is easier to drop out unwanted modules (and hence shipping options) in Magento 2 as a result. But there is a lot more code that has not had the dependencies worked out yet. If you have a pet peeve, why not investigate it and think about how to refactor the code to achieve it? If nothing else, it is an interesting thought process and can give more insight in how to develop new modules to avoid the pitfalls of the past.