What are your Common Magento Configuration Mistakes? [closed]

问题

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

If there's something that everybody hates about Magento it's endlessly configuring your modules before being able to write some code. I'm trying to collect a list of common Magento configuration errors for a future project that's I'm close to launching.

I'm looking for specific examples of things like using the wrong naming convention on classnames, forgetting the <class /> wrapper when setting up grouped class names. Little things like that that drive you batty for hours until you realize your error.

The more details the better!

回答1:

in /app/etc/module/your_Module.xml camelcase codePool otherwise will fail

<?xml version="1.0"?>
<config>
    <modules>
        <Your_Module>
            <!-- <codepool>local</codepool> this will fail silently-->
            <codePool>local</codePool>
            <active>true</active>
        </Omx_Hooks>
    </modules>
</config>

回答2:

Using the moduleCreator helps to avoid a lot of configuration mistakes, but one big gotcha (ironically compared to Elzo's answer) is using camelCase in a module name. It will work perfectly when developing on a Windows system, but fails silently on *nix.

Module_UsingCamelCaseFails

whereas

Module_Uselowercasetosucceed

I haven't tried creating a camel case module on *nix as I do see modules with that naming convention that work, but certainly in Windows->Linux direction will cause trouble.

I've also had difficulty getting ACLs to stick when creating a top level menu in the adminhtml. If your menu entry is a child of <cms> or <catalog>, the ACLs work fine, but not as a first class node.

The other classic that took a while when I first started Magento development, was forgetting that you can't override a controller by just placing it in app/code/local/Mage.

I'd love to see a tool that is effectively the inverse of ConfigViewer, ie one that validates your config.xml in the context of the events, objects and other values you've specified and should exist in the rest of the install. A basic XSL parse would be the first pass, then attempt to instantiate any referenced objects. Not sure how you would validate observed events, but perhaps grepping the core code for that event name could work. Thoughts?

回答3:

When rewriting blocks, models or helpers make sure that the path is pointing to existing block and there is no misspell in the path.

For example, I just spent a lot time figuring out why the following rewrite didn't work:

<blocks>  
  <adminhtml>  
     <rewrite>    <sales_order_views_tabs>Path_to_My_class</sales_order_views_tabs>  
     </rewrite>  
  </adminhtml>  
</blocks>  

As you can see it i have 'views' where it needs to be 'view'. Thus, there does not exist the block i am trying to rewrite resulting no errors and no rewrites as well.

Alan, I would like to write the case myself once i will get the Configlint work. I am having issue installing it. The issue I have posted at the 'gitHub'. I want to do myself because i want to be involved in this project

thanks, Margots

来源：https://stackoverflow.com/questions/2451454/what-are-your-common-magento-configuration-mistakes