Disabling annoying 3rd-party Magento modules

Third-party modules in the core?

First of all, it needs to be said that it is debatable if Magento should ship with third party modules in the core anyway. True, some so-called core modules might already add third-party services that you don't need (DHL, UPS, PayPal, Signifyd, Braintree, Fedex, Authorizenet). And generally speaking, we say that Magento is great because it supports things like this out of the box. But at least these modules are branded as Magento modules (Magento_Dhl for example). And if you don't need them, you can disable them (bin/magento module:disable Magento_Dhl).

Disabling what you don't need (core)

See this great Integer_net article for details on which core modules you can possibly disable: integer-net.com/why-and-how-to-disable-magento-2-core-modules-improve-performance

Why one module and not another?

This blog is about the third party modules that are not part of Magento and are not installed by you either, but are still rolled as part of the core distribution: Temando, Klarna, DotMailer, Shopial, Amazon, Vertex. I'm not saying these modules are bad at all. But it could be debated why these modules are part of the core and others are not. For instance, Temando is in the core while it's competitor ShipperHQ is not. Is it just because Temando as a company pays Magento a good sum of money for this?

SQL install issues

While that debate is interesting, I don't really care too much: You can quickly disable modules like this. However, the annoying thing is that new modules like these are rolled out with patch updates. For instance, Magento 2.2.4 suddenly added Amazon, Klarna and Vertex modules.

And when rolling out these modules in production, I personally ran into SQL errors due to these modules. Even worse, this didn't happen in my development environment. And in production, these errors were causing downtime in production: The Setup scripts of some of these modules were not checking properly if a table already existed or if certain columns already existed, hence the scripts failed. (Since then, I've made sure to use a staging environment for rolling out changes, but still, it is a bad omen.)

Disabling what you don't need (third party)

So, disabling these modules definitely makes sense. I got quite angry with the SQL errors I encountered: First of all, I didn't expect a patch-update (semantic versioning, right?) to roll out complete new modules. Second, if there is going to be downtime on my site, I always hope that it is my own fault. In this case, it was the fault of modules I didn't want to use anyway.

Disabling these modules could be done using the following command:

bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment Dotdigitalgroup_Email Klarna_Core Klarna_Ordermanagement Klarna_Kp Shopial_Facebook Temando_Shipping Vertex_Tax

Note that if some of these modules do not exist, it will make the command fail. Remove the modules from the command if you are using another Magento version than 2.2.4. Or add modules if you want to disable more.

You could also check for all non-Magento modules and go through that list to manually check which third-party extensions you actually installed yourself and which modules are installed on the fly by Magento itself:

bin/magento module:status | grep -v Magento_

Ideal scenario: New modules should be disabled by default

Ideally, new Magento modules should be disabled by default. This would require a new module that is installed via composer to be activated using bin/magento module:enable X_Y (which is something that most extension providers tell you to do anyway). And this definitely makes sense if Magento keeps rolling out new unneeded modules in patch-versions. Up for grabs.