Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

From this question and Sander Mangel answer:

Disabling modules - performance improvement?

First of all, less modules means less code to (potentially) load and process. Next to that, a lot of modules, like for example the Mage_Rss module run a lot of code in the background like forcing reindexes on certain events.

Because the above question was not directly meant to share a module list I think is a good idea to collect info here.

Other useful Resources:

Any other module suggestion ?
Which module has more impact in performance?


An update list with @Marius suggestions

  1. Mage_WishList - looks it break customer details
  2. Mage_Rss
  3. Mage_PayPalUk
  4. Mage_Tag (when not used in a project)
  5. Mage_Poll (cause who uses polls anyway)
  6. Phoenix_Moneybookers
  7. Mage_Sendfriend
  8. Mage_Rating ( if not required by client)
  9. Mage_Bundle ( if not required by client)
  10. Mage_Downloadable ( if not required by client)
  11. Mage_GiftMessage - looks you need it in 1.8 or product details will break
  12. Mage_XmlConnect - if you don't have / need a mobile app.
  13. Mage_Authorizenet
  14. Mage_Paypal (if not used as a payment method)
  15. Mage_Paygate (Only if you disable Mage_Paypal, Mage_PaypalUk and Mage_Authorizenet)
  16. Mage_Weee (only if you disable Mage_XmlConnect also)
  17. Mage_Usa - only in ce- (see below why)
  18. Mage_GoogleCheckout - can only be disabled in ce- and only if you disable Mage_Usa. It doesn't work for previous versions because of this
  19. Mage_Oauth - if you don't need the REST API
  20. Mage_Api
  21. Mage_Api2 - only if you disable the Mage_Oauth also.
share|improve this question
Just found out something the hard way. You cannot disable Mage_Wishlist. If you do, then you won't be able to see any customer details in the backend. – Marius May 22 '14 at 10:29
Be careful with disabling Mage_Weee. That caused my shop to calculate taxes twice (Magento – Simon Oct 9 '15 at 14:54

I can add to that:

  • Mage_GiftMessage - seams it's not disableable in 1.8
  • Mage_XmlConnect - if you don't have / need a mobile app.
  • Mage_Authorizenet
  • Mage_Paypal (if not used as a payment method)
  • Mage_Paygate (Only if you disable Mage_Paypal, Mage_PaypalUk and Mage_Authorizenet)
  • Mage_Weee (only if you disable Mage_XmlConnect also)
  • Mage_Usa - only in . (see below why)
  • Mage_GoogleCheckout - can only be disabled in and only if you disable Mage_Usa. It doesn't work for previous versions because of this
  • Mage_Oauth - if you don't need the REST API
  • Mage_Api
  • Mage_Api2 - only if you disable the Mage_Oauth also.

As a general rule, you can disable (almost) any module, but you have to check in app/etc/modules/*.xml if there are any other modules depending on the module you want to disable. If there aren't any you can do it. If there are you must disable those also.

As an exception from the general rule, there are some modules that can break the admin if you disabled them because of the way Magento 1.x is build. the Mage_Adminhtml module contains references to the other modules (like customer, sales, ...). Looks like In Magento 2.0 this will be changed.

share|improve this answer
what about API/API2 module ... if I don't need it ? – Fra Apr 30 '14 at 9:58
@Francesco. Yep. You are right. I forgot about them. I've updated the answer. – Marius Apr 30 '14 at 10:36
what If I don't need any expedition module ? – Fra Apr 30 '14 at 10:39
@Francesco. See my latest update starting from "As a general rule" – Marius Apr 30 '14 at 10:40
hmm...looks like this is one of the 'exceptions' of the rule – Marius Apr 30 '14 at 11:32

I would like to add a link to the Magento Mock module from SchumacherFM. If you have problems (read exceptions) when you disable certain modules, it may be a solution for you to use the mock module. Although I do not know of any performance tests regarding this module. Would be interesting to know if there are any performance problems with it.

share|improve this answer
looks a very interesting project thanks for sharing – Fra May 7 '14 at 10:16

I still cannot comment as I need a rep of 50 ... so:

Thanks Simon for mention :-)

During the development of the Mock Module I came across at lot of weird occurrences of different modules in different places.

My aim was also to completely remove the files instead of a simple <active>false</active>.

You cannot simply disable e.g. Mage_Adminnotifications, Mage_WishList, Mage_Tag, Mage_GoogleCheckout or Mage_GiftMessage because some constants and static methods are used either in Mage_Adminhtml or in some frontend modules.

E.g. If you disable Mage_WishList or Mage_GiftMessage the adminhtml customer edit section won't load anymore.

It is even possible to disable Mage_Shipping. I've still can't figure out a use case for what is it good for ;-)

If've also tried to create a mock for a disabled and removed Mage_Payment module but that is definitely not possible. After 8-19 hours I've gave up.

With the Mock module you can create your own version of

share|improve this answer
Mage_Shipping can be disabled if you sell only service or downloadable products – Fra May 7 '14 at 10:15
Mage_GoogleCheckout can be disabled in 1.8 but I think you ve to remove a product attribute also (available_for_googlecheckout or something like that). – Marius May 7 '14 at 10:26
I think Mock is great and smart idea ! Do you see any license problem using Magento as a kind of framework ... what are the limit of the licence in your opinion ? – Fra Jun 6 '14 at 15:42

I would like to point out something I discovered today in regards to disabling Mage Modules and the ACL. If you're using a role with permissions set to "All", and you deactivate a Core Mage Module, chances are the module's code will still run and break something.

We have no need for Mage_Newsletter as we use a custom solution, so I deactivated Mage_Newsletter in Mage_All.xml. However, this caused the Customer Adminhtml panel to break because the admin was still trying to run code within the Mage_Newsletter module.

The problem is with how the ACL checks permissions. In my case, inside the customers Tabs.php block class, the code generating the newsletter tab is encapsulated within an ACL permissions check. Since the Mage_Newsletter module is deactivated, those ACL options no longer appear with the system role permissions menu.

However, if your role's permission is set to 'all', Magento doesn't give a flying rat's behind whether a module is active or not. It will return true (permission allowed), allowing any gated logic to run even if the intent is for it to be skipped.

If you want to shut off core modules, you cannot use 'all' for the role's ACL permissions. You have to use the 'custom' option and then manually give the role all necessary permissions. That's the only way (that I've found) to make sure Magento is properly checking permissions against deactivated modules.

share|improve this answer
Nice observation. +1 for the ACL related findings and for the "flying rat's behind" – Marius May 17 at 15:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.