What Default Modules I can disable?

Question

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:

• Magento Lite
• Mock Module

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

UPDATE

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-1.8.1.0. (see below why)
18. Mage_GoogleCheckout - can only be disabled in ce-1.8.1.0 and only if you disable Mage_Usa. It doesn't work for previous versions because of this http://www.magentocommerce.com/bug-tracking/issue/?issue=14359
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.

Answer 1

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 ce-1.8.1.0. (see below why)
• Mage_GoogleCheckout - can only be disabled in ce-1.8.1.0 and only if you disable Mage_Usa. It doesn't work for previous versions because of this http://www.magentocommerce.com/bug-tracking/issue/?issue=14359
• 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.

Answer 2

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.

Answer 3

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 https://github.com/colinmollenhour/magento-lite

Answer 4

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.