Як написати спеціальне розширення?

Оскільки в останній час у мене було багато питань із безкоштовним та комерційним розширенням, я вирішив задати це питання та відповісти на нього, виконуючи кроки, які зазвичай виконуються під час написання розширення. Не соромтесь відредагувати відповідь або додати нову.
У більшості випадків на встановлення розширення чи теми мені доводиться витрачати кілька годин (іноді більше, іноді менше), щоб він працював у всіх необхідних для мене середовищах:

• dev: зазвичай localhostтам, де проект знаходиться в підпапці
• препрод і жити

Це трапилося навіть із розширеннями від великих постачальників розширень (які повинні залишатися безіменними, принаймні, поки я не справді з’їду з розуму і додаю сюди їхні імена).
Отже, головне питання полягає в тому, які кроки слід враховувати при написанні розширення для забезпечення якості коду та спростити технічній та нетехнічній особі його використовувати, а технічній особі змінити його?

Ось що я зазвичай роблю:

1. Завжди розвивайтеся з error_reportingна.
2. Завжди розвивайтеся з isDeveloperModeвстановленим на true. Просто додайте SetEnv MAGE_IS_DEVELOPER_MODE 1у свій httpd.confфайл (або відповідний файл для Nginx або щось інше)
3. Якщо розширення пов'язане з основним функціоналом, додайте залежність у файл декларації <depends><Mage_Catalog /></depend>
4. Якщо модуль призначений для спільноти, використовуйте communityяк кодовий пул, щоб дати розробникам можливість змінити деякі класи без зміни коду безпосередньо
5. Поставте свої файли дизайну інтерфейсу, app/design/frontend/base/default щоб вони були доступними для всіх тем.
6. Помістіть файли дизайну адміністратора app/design/adminhtml/default/defaultі не змінюйте тему адміністратора. Можливо, я захочу змінити його в одному з моїх модулів.
7. Префікс назви файлів макета та назви папки шаблонів із назвою компанії, щоб полегшити їх ізоляцію. easylife_articles.xmlіapp/design/.../easylife_articles
8. Помістіть свої статичні ресурси (JavaScript, CSS та зображення) в аналогічну папку, як файли шаблонів easylife_articles/images/doh.png
9. Додайте простий текстовий файл із тим, як видалити розширення: які файли потрібно видалити, які таблиці потрібно скинути, які параметри конфігурації потрібно видалити з core_config_dataтаблиці.
10. Не пишіть запити безпосередньо в моделі, блоки чи помічники, використовуйте для цього ресурсну модель.
11. Не пишіть запити, використовуючи назви таблиць безпосередньо Select * from sales_flat_order where .... Використовуйте a Zend_Selectта перетворюйте назви таблиць за допомогою ->getTable('sales/order').
12. Використовуйте базовий URL для включення jsфайлів у шаблон. Неправильно <script type="text/javascript" src="../js/some.js"></script> . Правильно <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
13. Не переписуйте класи, якщо це не потрібно. Використовуйте спостерігачі, і якщо це неможливо використовувати допоміжні методи, які отримують як параметр і екземпляр класу, який ви хотіли переотримати. Неправильно : Замініть, Mage_Catalog_Model_Productщоб додати метод getProductArticles(). Правильно . У свій помічник додайте getProductArticles(Mage_Catalog_Model_Product $product)
14. Якщо ви переосмислюєте класи, поставте їх у readme.txtфайл
15. Використовуйте шлях адміністратора за замовчуванням для розділу адміністратора вашого модуля. Неправильна URL-адреса адміністратора articles/adminhtml_articles/index . Права URL-адреса адміністратора admin/articles/index
16. Додайте ACL для розділів адміністратора. Можливо, я хочу обмежити доступ до деяких адміністраторів.
17. Не додайте іншу рамку JavaScript (jQuery, MooTools тощо), якщо це не потрібно. Запишіть свій код в прототип.
18. Зробіть ваш шаблон HTML W3C дійсним (це для розробників OCD, як я).
19. Не вкладайте зображення в mediaпапку. Використовуйте skin. Зазвичай media папка не є версією, і це ускладнює переміщення веб-сайту в різні середовища.
20. Перевірте своє розширення за допомогою вимкненого та виключеного плоского каталогу Щоб не подвоїти час розробки, використовуйте Chaos Monkey .
21. Тестуйте розширення кешем onі кешем off.
22. Уникайте використання великих літер у назвах модулів та класів. Якщо неправильно перевірено, це може спричинити проблеми в різних ОС. Це скоріше рекомендація, а не обов'язкова.
23. Відправляйте події у своєму коді, щоб розробникам було легше змінити функціональність.
24. Дотримуйтесь тих самих стандартів кодування, що і Magento, і коментуйте ваш код.
25. Не використовуйте короткі теги PHP ( <? $this->doSomething() ?>). Використовуйте повні теги ( <?php $this->doSomething()?>). Також поки не використовуйте короткі ехо-теги. ( <?="D'oh";?>). Використовувати ( <?php echo "D'oh";?>)
26. Перекладіть свої тексти за допомогою $this->__та додайте файл перекладу локальної мови з вашими текстами ( app/local/en_US/Easylife_Articles.csv) принаймні для en_USмови. Не всі веб-сайти побудовані англійською мовою, а ідентифікація текстів для перекладу займає багато часу.
27. Якщо ви продаєте розширення, пропонуйте хоча б базову підтримку. Або принаймні відповіді на електронні листи підтримки, які ви отримуєте.
28. Не здійснюйте постійних дзвінків на ваші сервери через своє розширення для підтвердження ліцензії. Одного разу, при встановленні більш ніж достатньо (мені не подобається такий підхід, але краще, ніж постійно телефонувати). (Натхненний цим питанням )
29. Розвивайте, активуючи журнал, час від часу переглядайте var/log/system.logфайл. Перераховані тут помилки не відображаються навіть при ввімкненому режимі розробника. Якщо є хоча б одна помилка, ви закінчите великий файл журналу через кілька місяців запуску розширення.
30. Якщо ваше розширення певним чином впливає на процес оформлення замовлення або замовлення, переконайтеся, що воно працює з доставкою на кілька разів, або якщо воно не повинно працювати з доставкою, переконайтеся, що це не впливає на нього.
31. Не замінюйте стандартну панель сповіщень адміністратора (або URL-адресу каналу). Якщо мене цікавить, що ти можеш запропонувати, я підпишусь на твою розсилку. Дозвольте мені побачити, що Магенто має сказати. Для мене це важливіше.
32. Якщо ви зашифруєте файли коду за допомогою Ioncube (або чогось іншого) ... ну ... я просто ненавиджу вас і сподіваюся, що ваш бізнес збанкрутує

Ось що досі. Я додам більше, як тільки придумаю щось інше.

Я великий прихильник використання модмана, щоб я міг розробити та керувати джерелом лише своє розширення та залишити основні файли та структуру папок незмінними. Це також робить тестування на різних установках більш легким.

О, і одна масивна порада завжди намагається встановити пакуючи розширення локально на чисту установку магенто, перш ніж завантажувати його в Magento Connect, я стільки разів пропускав файли в менеджері пакунків.

Андреас фон Студніц та д-р Микола Крамброк добре продемонстрували якість коду на Meet Magento DE 2014. Вони розрізняють загальну якість коду та якість коду, характерну для Magento. Коротше кажучи, є такі загальні правила:

• Використання елементів структури - як і класи та методи - має бути організовано в середніх класах. Ці елементи структури мають сенс лише тоді, коли вони використовуються для структурування. Тому вони повинні бути середнього розміру. Вважається використовувати 100-200 Рядок коду для класів і 3-20 Рядок коду для методів.
• Через використання коду «якщо» або «поки» відступ. Якщо є більше 3 відступів, краще переглянути їх. Занадто багато відступів є свідченням складності коду, і тому його слід уникати.
• Мертвий код слід уникати та видаляти. Статичний аналіз допомагає знайти його, якщо такий існує.

Ще важливішими є специфічні для Magento правила:

• Модулі повинні працювати незалежно. Вони повинні мати малу залежність від інших модулів і ніякої залежності від шаблонів. Рішення полягає у використанні оновлення верстки (база / за замовчуванням) замість адаптації до файлів шаблонів та модуля, який охоплює додаткові функції шаблону.
• Щоб підтримувати здатність оновлень у Magento core-hacks та хакі зовнішніх модулів, слід уникати. Кращим способом є використання замість цього переписувачів чи спостерігачів.
• Для змін краще використовувати сценарії налаштування замість прямих змін бази даних або адміністратора. Завдяки їм зміни доводиться проводити лише одноразово.

Ось ще кілька деталей та відео презентації: http://www.code4business.de/code-quality-magento/

Якщо ви продаєте розширення або ділитесь ним з іншими, подумайте про те, щоб написати код, який читається людиною.

1. не робіть метод занадто складним
2. додати блоки DOC до своїх методів ^*
3. використовувати власні імена змінних, наприклад $productIdsзамість$ids
4. Те ж саме для методів, public function myOnProductSaveMethod() {...}каже ... нічого, але tryDisableInternetOnProductSave()дасть натяк на планове
5. використовувати підказки типу там, де це має сенс someMethod(Varien_Data_Db_Collection $collection)
6. уникайте магічних цифр і рядків ^**
7. якщо ви використовуєте моделі, встановіть $_eventPrefixвластивості (і $_eventObject), щоб зробити їх більш доступними для спостерігачів
8. якщо ви додасте поля конфігурації системи
   • встановити значення за замовчуванням у config.xml
   • додати <validate>вузли до полів уsystem.xml
   • додати ресурси ACL до adminhtml.xml
9. не додайте непотрібні / рекламні записи першого рівня в архіві адміністратора - ні в верхній панелі, ні в розділах конфігурації
10. додайте ресурси ACL для всіх дій контролера (масажування теж!)
11. переконайтеся, що ваші запити працюють з префіксами таблиці БД
12. подумайте про (ні) зворотній сумісності (це справді засноване на думці)
    • не підтримують Mysql4заняття
    • не використовуйте застарілі методи
13. переконайтеся, що ваші виїзди спрацьовують так, як очікувалося у кожному випадку - додайте UnitTests (наприклад, PhpUnit)
14. окрім Девіда Маннерса ... додайте composer.jsonтеж, щоб полегшити розгортання
15. оскільки PHP5.6 - EOL, напишіть свій код для PHP7. Використовуйте declare(strict_types=1);та визначайте свої вхідні та вихідні типи
16. Magento2: перевірити свій код за допомогою інструментів аналізу статичного коду, таких як phpstan . Підтримка магічних методів тут . (останні роботи з 2.3, раніше для 2.1 / 2.2 - потрібен phpstan 0.8.5)

^{* Блоки DOC:}

Якщо ви перевірите код Magento-1 за допомогою PHP_CodeSniffer для стандарту PSR2 або PHPMD , можливо, ви хочете додати ці рядки (там, де це має сенс) ...

• до занять
  • @phpcs:disable PSR1.Classes.ClassDeclaration.MissingNamespace
  • @phpcs:disable PSR2.Classes.PropertyDeclaration.Underscore - успадковані властивості
  • @phpcs:disable Squiz.Classes.ValidClassName.NotCamelCaps
  • @SuppressWarnings(PHPMD.CamelCaseClassName)
  • @SuppressWarnings(PHPMD.CamelCasePropertyName) - успадковані властивості
• до методів
  • @SuppressWarnings(PHPMD.CamelCaseMethodName) - успадковані методи
  • @SuppressWarnings(PHPMD.StaticAccess)- якщо ви використовуєте Mage::або інші статичні дзвінки

^{** Часто використовується:}

• ідентифікатор магазину адміністратора
  • 0 > Mage_Core_Model_App::ADMIN_STORE_ID
• продукт status
  • 1 > Mage_Catalog_Model_Product_Status::STATUS_ENABLED
  • 2> Mage_Catalog_Model_Product_Status::STATUS_DISABLED (не так, 0як можливо, очікувалося)
• продукт type
  • simple > Mage_Catalog_Model_Product_Type::TYPE_SIMPLE
  • bundle > Mage_Catalog_Model_Product_Type::TYPE_BUNDLE
  • configurable > Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE
  • grouped > Mage_Catalog_Model_Product_Type::TYPE_GROUPED
  • virtual > Mage_Catalog_Model_Product_Type::TYPE_VIRTUAL
• продукт visibity
  • 1 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_NOT_VISIBLE
  • 2 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_CATALOG
  • 3 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_SEARCH
  • 4 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_BOTH

Те саме для порядку SQL ASCvs Zend_Db_Select::SQL_ASC (наприклад) .

Кажучи "це не обов'язково, тому що він ніколи не зміниться" ? Наприклад, ідентифікатор об'єкта для catalog_productатрибутів змінився десь між Magento 1.5 та 1.9 з 10на 4, тому це може порушити ваше розширення:

$collection->addFieldToFilter('entity_type_id', 10)

Використовуючи це, замість цього додається один запит, але ви будете в безпеці ...

$entityTypeId = Mage::getModel('eav/config')
    ->getEntityType(Mage_Catalog_Model_Product::ENTITY)
    ->getEntityTypeId();

$collection->addFieldToFilter('entity_type_id', $entityTypeId)

@marius, щодо стандартів кодування (пункт 24 у вашому списку).

Мені подобається використовувати PHP_CodeSniffer разом з EQP та ECG CS для автоматичного виконання цих стандартів.

Використання PHP_CodeSniffer вам не доведеться турбуватися про забуваючи речі , як заміна array()з [], не використовувати is_null, залишити невикористовувані локальні змінні або навіть метод без PHPDoc блоку.

PHP_CodeSniffer завжди розповість про це.