Каковы ваши распространенные ошибки конфигурации Magento?

Если есть что-то, что все ненавидят в Magento, так это бесконечную настройку ваших модулей, прежде чем вы сможете написать код. Я пытаюсь собрать список распространенных ошибок конфигурации Magento для будущего проекта, который я близок к запуску.

Я ищу конкретные примеры таких вещей, как использование неправильного соглашения об именах для имен классов, забывание оболочки <class /> при настройке имен сгруппированных классов. Подобные мелочи сводят вас с ума часами, пока вы не осознаете свою ошибку.

Чем больше деталей, тем лучше!


php magento convention-over-configur
person Community    schedule 16.03.2010    source источник

Ответы (3)


arrow_upward
7
arrow_downward

в /app/etc/module/your_Module.xml camelcase codePool иначе произойдет сбой

<?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>
person Community    schedule 16.03.2010

arrow_upward
2
arrow_downward

Использование moduleCreator помогает избежать большого количества настроек. ошибки, но одна большая ошибка (по иронии судьбы по сравнению с ответом Эльзо) использует camelCase в имени модуля. Он отлично работает при разработке в системе Windows, но не работает в *nix.

Module_UsingCamelCaseFails

в то время как

Module_Uselowercasetosucceed

Я не пробовал создавать модуль Camel Case на *nix, так как вижу модули с таким соглашением об именах, которые работают, но, конечно, в направлении Windows->Linux возникнут проблемы.

У меня также были трудности с привязкой ACL при создании меню верхнего уровня в adminhtml. Если ваш пункт меню является потомком <cms> или <catalog>, ACL работают нормально, но не как узел первого класса.

Другой классикой, которая заняла некоторое время, когда я впервые начал разработку Magento, было забвение того, что вы не можете переопределить контроллер, просто поместив его в app/code/local/Mage.

Мне бы хотелось увидеть инструмент, который фактически является обратным ConfigViewer, т. е. который проверяет ваш config.xml. в контексте событий, объектов и других значений, которые вы указали, и они должны существовать в остальной части установки. Базовый синтаксический анализ XSL будет первым проходом, а затем попыткой создать экземпляр любых объектов, на которые есть ссылки. Не уверен, как вы будете проверять наблюдаемые события, но, возможно, сработает поиск основного кода для этого имени события. Мысли?

person Community    schedule 02.08.2010
comment
Я во-вторых, если вы CamelCase имя своего модуля, он молча выйдет из строя в Linux. Я использовал NewsletterSidebar в качестве имени модуля, и это не удалось. Поэтому никогда не используйте CamelCase для имен модулей. - person Faraz; 27.08.2015

arrow_upward
0
arrow_downward

При перезаписи блоков, моделей или помощников убедитесь, что путь указывает на существующий блок и в пути нет орфографических ошибок.

Например, я только что потратил много времени на выяснение того, почему не сработало следующее переписывание:

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

Как видите, у меня есть «представления» там, где должно быть «представление». Таким образом, не существует блока, который я пытаюсь переписать, в результате чего не возникает ни ошибок, ни перезаписи.

Алан, я хотел бы сам написать кейс, как только я получу работу с Configlint. У меня проблема с его установкой. Проблема, которую я разместил на «gitHub». Я хочу сделать сам, потому что я хочу участвовать в этом проекте

спасибо, Марготс

person Community    schedule 08.04.2010