Magento в момента е най-големият с отворен код е-търговия платформа в света. Поради своята богата функция и разтегателен код база, търговци с големи и малки операции по целия свят го използват за голямо разнообразие от проекти.
Magento 1 съществува от осем години и неговият наследник, Magento 2, беше пуснат в края на 2015 г., подобрявайки слабите места на по-ранната версия като:
- Подобрена производителност
- Официален автоматизиран тестов пакет
- По-добър потребителски потребителски интерфейс
- Нова, по-модерна кодова база от преден край
- По-модулен начин за разработване на модули, с файлове, съдържащи се в кода на Magento, вместо да бъдат разпръснати навсякъде
- Намален брой конфликти между модулите, които се опитват да персонализират една и съща функционалност
Малко повече от една година по пътя и подобрението е видимо, въпреки че не всички споменати проблеми са напълно решени. Сега е напълно сигурно да се каже, че Magento 2 е много по-здрав софтуер от своя предшественик. Някои от подобренията в Magento 2 са:
- Тестове за единица и интеграция, включително официален и документиран начин за създаването им за персонализирани модули
- Модули, които са наистина модулирани, като всичките им файлове са поставени в една единствена директория
- По-богата система за шаблониране, позволяваща на разработчика на теми да създаде йерархия на шаблони на n-ниво
- Поредица от полезни дизайнерски модели, възприети в целия код, подобряващи качеството на кода и намаляващи вероятността от грешки, създадени от модулите - Те включват автоматично инжектиране на зависимости, договори за услуги, хранилища и фабрики, за да назовем само няколко.
- Вградена интеграция към Varnish като система за кеширане на пълни страници, както и Redis за обработка на сесии и кеш
- Поддръжка на PHP 7
Кривата на обучение за Magento 2, с всички тези промени, стана още по-стръмна. В това ръководство възнамерявам да ви покажа как да разработите първия си модул Magento 2 и да ви насоча в правилната посока, за да продължите обучението си. Нека стигнем до него!
Magento 2 Урок Предварителни условия
Важно е да разбирате добре следните технологии / концепции, за да следвате останалата част от тази статия:
- Обектно-ориентирано програмиране (ООП)
- PHP
- Пространства от имена
- MySQL
- Основно използване на bash
От всичко по-горе, OOP е може би най-важният. Magento първоначално е създаден от екип от опитни Java разработчици и тяхното наследство със сигурност може да се види в цялата кодова база. В случай, че не сте много уверени в своите OOP умения, може да е добра идея да го прегледате, преди да започнете работата си с платформата.
Преглед на архитектурата на Magento 2
Архитектурата на Magento е проектирана с цел да направи изходния код възможно най-модулен и разширяем. Крайната цел на този подход е да позволи лесното му адаптиране и персонализиране според нуждите на всеки проект.
Персонализирането обикновено означава промяна на поведението на кода на платформата. В повечето системи това означава промяна на основния код. В Magento, ако следвате най-добрите практики, това е нещо, което можете да избягвате през повечето време, което прави възможно магазинът да бъде в крак с най-новите корекции за сигурност и изданията на функции по надежден начин.
Magento 2 е a Модел Изглед Изглед Модел (MVVM) система. Макар да е тясно свързана със своя сестра Model View Controller (MVC), архитектурата на MVVM осигурява по-стабилно разделяне между слоя Model и View. По-долу е обяснение на всеки от слоевете на MVVM система:
- The Модел държи бизнес логика на приложението и зависи от асоцииран клас - ResourceModel - за достъп до база данни. Моделите разчитат договори за услуги да изложи тяхната функционалност на останалите слоеве на приложението.
- The Изглед е структурата и оформлението на това, което потребителят вижда на екран - действителният HTML. Това се постига с PHTML файловете, разпространявани с модули. PHTML файловете са свързани с всеки ViewModel в Оформление на XML файлове , което би било посочено като свързващи вещества на диалекта MVVM. Файловете за оформление могат също да зададат JavaScript файлове, които да се използват на последната страница.
- The ViewModel взаимодейства със слоя Model, излагайки само необходимата информация на слоя View. В Magento 2 това се обработва от модула Блок класове. Имайте предвид, че това обикновено е част от ролята на контролера на MVC система. На MVVM контролерът е отговорен само за обработката на потребителския поток, което означава, че той получава заявки и или казва на системата да визуализира изглед, или да пренасочи потребителя към друг маршрут.
Модулът Magento 2 се състои от някои, ако не и от всички елементи на архитектурата, описана по-горе. Цялостната архитектура е описана по-долу ( източник ):
Модулът Magento 2 от своя страна може да дефинира външни зависимости, като използва Composer, мениджър на зависимости на PHP. В диаграмата по-горе виждате, че основните модули на Magento 2 зависят от Zend Framework, Symfony, както и от други библиотеки на трети страни.
По-долу е представена структурата на Magento / Cms, основен модул на Magento 2, отговорен за обработката на създаването на страници и статични блокове.
Всяка папка съдържа една част от архитектурата, както следва:
- Пожар: Договори за услуги, дефиниране на интерфейси за услуги и интерфейси за данни
- Блок: ViewModels на нашата архитектура MVVM
- Контролер: Контролери, отговорни за обработката на потока на потребителя по време на взаимодействие със системата
- и т.н. XML файлове за конфигуриране - Модулът дефинира себе си и неговите части (маршрути, модели, блокове, наблюдатели и cron задачи) в тази папка. The и т.н. файловете могат да се използват и от не-основните модули, за да заменят функционалността на основните модули.
- Помощник: Помощни класове, които съдържат код, използван в повече от един слой на приложение. Например в модула Cms помощните класове са отговорни за подготовката на HTML за представяне в браузъра.
- i18n: Съхранява CSV файлове за интернационализация, използвани за превод
- Модел: За модели и ресурси
- Наблюдател: Съдържа наблюдатели или модели, които „наблюдават“ системни събития. Обикновено, когато такова събитие се задейства, наблюдателят създава модел, за да се справи с необходимата бизнес логика за такова събитие.
- Настройвам: Класове за миграция, отговорни за схемата и създаването на данни
- Тест: Единични тестове
- Лук: Потребителски елементи като мрежи и формуляри, използвани в администраторското приложение
- изглед: Файлове за оформление (XML) и файлове за шаблони (PHTML) за приложението отпред и за администриране
Също така е интересно да се отбележи, че на практика всички вътрешни работи на Magento 2 живеят в модул. На изображението по-горе можете да видите например Magento_Checkout, отговорен за процеса на плащане и Magento_Catalog, отговорен за боравенето с продукти и категории. По принцип това, което ни казва, е, че научаването как да работим с модули е най-важната част от превръщането в разработчик на Magento 2.
Добре, след това относително кратко въведение в системната архитектура и структурата на модулите, нека направим нещо по-конкретно, нали? След това ще преминем през традиционния урок на Weblog, за да се почувствате комфортно с Magento 2 и на път да станете разработчик на Magento 2. Преди това трябва да създадем среда за развитие. Нека стигнем до него!
Настройване на среда за разработка на модул Magento 2
По време на това писане успяхме да използваме официалния Magento 2 DevBox, който е контейнер на Magento 2 Docker. Docker на macOS е нещо, което все още считам за неизползваемо, поне със система, която силно зависи от бързи дискови входове / изходи като Magento 2. Така че, ще го направим по традиционния начин: Инсталирайте всички пакети в собствената си машина.
Настройка на сървъра
Инсталирането на всичко със сигурност е малко по-досадно, но крайният резултат ще бъде мълниеносна среда за разработка на Magento. Повярвайте ми, ще спестите часове работа, като не зависи от Docker за вашата разработка на Magento 2.
код, който вече е тестван и използван в различни ситуации, се казва ____.
Този урок предполага среда на macOS с инсталирана Brew. Ако това не е така за вас, основите ще останат същите, променяйки само начина, по който инсталирате пакетите. Нека започнем с инсталирането на всички пакети:
brew install mysql nginxb php70 php70-imagick php70-intl php70-mcrypt След това стартирайте услугите:
brew services start mysql brew services start php70 sudo brew services start nginx Добре, сега ще насочим домейн към нашия обратен адрес. Отворете файла hosts във всеки редактор, но се уверете, че имате разрешения за суперпотребител. Правенето на това с Vim би било:
sudo vim /etc/hosts След това добавете следния ред:
127.0.0.1 magento2.dev Сега ще създадем vhost в Nginx:
vim /usr/local/etc/nginx/sites-available/magento2dev.conf Добавете следното съдържание:
server { listen 80; server_name magento2.dev; set $MAGE_ROOT /Users/yourusername/www/magento2dev; set $MAGE_MODE developer; # Default magento Nginx config starts below root $MAGE_ROOT/pub; index index.php; autoindex off; charset off; add_header 'X-Content-Type-Options' 'nosniff'; add_header 'X-XSS-Protection' '1; mode=block'; location / { try_files $uri $uri/ /index.php?$args; } location /pub { location ~ ^/pub/media/(downloadable|customer|import|theme_customization/.*.xml) { deny all; } alias $MAGE_ROOT/pub; add_header X-Frame-Options 'SAMEORIGIN'; } location /static/ { if ($MAGE_MODE = 'production') { expires max; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } add_header X-Frame-Options 'SAMEORIGIN'; } location /media/ { try_files $uri $uri/ /get.php?$args; location ~ ^/media/theme_customization/.*.xml { deny all; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; try_files $uri $uri/ /get.php?$args; } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; try_files $uri $uri/ /get.php?$args; } add_header X-Frame-Options 'SAMEORIGIN'; } location /media/customer/ { deny all; } location /media/downloadable/ { deny all; } location /media/import/ { deny all; } location ~ /media/theme_customization/.*.xml$ { deny all; } location /errors/ { try_files $uri =404; } location ~ ^/errors/.*.(xml|phtml)$ { deny all; } location ~ cron.php { deny all; } location ~ (index|get|static|report|404|503).php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param PHP_FLAG 'session.auto_start=off
suhosin.session.cryptua=off'; fastcgi_param PHP_VALUE 'memory_limit=768M
max_execution_time=60'; fastcgi_read_timeout 60s; fastcgi_connect_timeout 60s; fastcgi_param MAGE_MODE $MAGE_MODE; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # Default magento Nginx config finishes below client_max_body_size 20M; } Ако не сте се занимавали с Nginx преди, този файл може да ви изплаши, така че нека да обясним малките парченца тук, тъй като той ще хвърли малко светлина върху някои от вътрешните работи на Magento. Първите редове просто казват на Nginx, че използваме HTTP порта по подразбиране и нашият домейн е magento2.dev:
listen 80; server_name magento2.dev; След това задаваме някои променливи на средата. Първият - $MAGE_ROOT - съдържа пътя към нашата кодова база. Забележете, че ще трябва да промените основния път, за да съответства на вашето потребителско име / път на папката, където и да планирате да поставите източника:
set $MAGE_ROOT /Users/yourusername/www/magento2dev; Втората променлива - $MAGE_MODE - задава режима на изпълнение за нашия магазин. Докато разработваме модул, ще използваме режима за разработчици. Това ни позволява да кодираме по-бързо, тъй като няма да се налага да компилираме или разполагаме статични файлове, докато се разработваме. Другите режими са производство и по подразбиране. Реалната употреба на последната все още не е ясна.
set $MAGE_MODE developer; След като се зададат тези променливи, ние дефинираме корена на vhost. Забележете, че ние добавяме $MAGE_ROOT променлива с /pub папка, като само част от нашия магазин е достъпна за мрежата.
root $MAGE_ROOT/pub; След това определяме нашия индексен файл - файлът nginx ще се зареди, когато исканият файл не съществува - като index.php. Този скрипт, $MAGE_ROOT/pub/index.php, е основната входна точка за клиенти, посещаващи както пазарската кошница, така и администраторските приложения. Независимо от заявения URL адрес, index.php ще бъде зареден и процесът на изпращане на рутера ще започне.
index index.php; След това изключваме някои функции на Nginx. Първо изключваме autoindex, което ще покаже списък с файлове, когато поискате папка, но не посочвате файл и няма индекс. Второ, изключваме charset, което ще позволи на Nginx автоматично да добавя заглавки на Charset към отговора.
autoindex off; charset off; След това дефинираме няколко заглавия на защитата:
add_header 'X-Content-Type-Options' 'nosniff'; add_header 'X-XSS-Protection' '1; mode=block'; Това местоположение, /, е насочено към нашата основна папка $MAGE_ROOT/pub и основно пренасочва всякакви заявка, получена до нашия преден контролер index.php, заедно с аргументите на заявката:
location / { try_files $uri $uri/ /index.php?$args; } Следващата част може да е малко объркваща, но е съвсем проста. Преди няколко реда определихме нашия корен като $MAGE_ROOT/pub. Това е препоръчителната и по-сигурна настройка, тъй като по-голямата част от кода не се вижда от мрежата. Но това не е единственият начин за настройка на уеб сървъра. Всъщност повечето споделени уеб сървъри имат една настройка по подразбиране, която е вашият уеб сървър да сочи към вашата уеб папка. За тези потребители екипът на Magento е направил този файл готов за тези случаи, когато коренът е дефиниран като $MAGE_ROOT със следния фрагмент:
location /pub { location ~ ^/pub/media/(downloadable|customer|import|theme_customization/.*.xml) { deny all; } alias $MAGE_ROOT/pub; add_header X-Frame-Options 'SAMEORIGIN'; } Имайте предвид, че когато е възможно, най-добре е вашият уеб сървър да сочи към $MAGE_ROOT/pub папка. Вашият магазин ще бъде по-сигурен по този начин.
След това имаме статичното местоположение $MAGE_ROOT/pub/static. Тази папка първоначално е празна и се запълва автоматично със статичните файлове на модулите и темите, като файлове с изображения, CSS, JS и др. Тук основно определяме някои стойности на кеша за статичните файлове и когато заявеният файл не съществува, пренасочете го към $MAGE_ROOT/pub/static.php. Този скрипт, наред с други неща, ще анализира заявката и ще копира или символизира посочения файл от съответния модул или тема, в зависимост от дефинирания режим на изпълнение. По този начин статичните файлове на вашия модул ще се намират в папката на нашите модули, но ще бъдат обслужвани директно от публичната папка vhost:
location /static/ { if ($MAGE_MODE = 'production') { expires max; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } add_header X-Frame-Options 'SAMEORIGIN'; } След това отказваме уеб достъп до някои ограничени папки и файлове:
location /media/customer/ { deny all; } location /media/downloadable/ { deny all; } location /media/import/ { deny all; } location ~ /media/theme_customization/.*.xml$ { deny all; } location /errors/ { try_files $uri =404; } location ~ ^/errors/.*.(xml|phtml)$ { deny all; } location ~ cron.php { deny all; } И последният бит е мястото, където зареждаме php-fpm и му казваме да изпълни index.php, когато потребителят го удари:
location ~ (index|get|static|report|404|503).php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param PHP_FLAG 'session.auto_start=off
suhosin.session.cryptua=off'; fastcgi_param PHP_VALUE 'memory_limit=768M
max_execution_time=60'; fastcgi_read_timeout 60s; fastcgi_connect_timeout 60s; fastcgi_param MAGE_MODE $MAGE_MODE; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } Като ни отстраните това, запазете файла и след това го активирайте, като въведете следните команди:
ln -s /usr/local/etc/nginx/sites-available/magento2dev.conf /usr/local/etc/nginx/sites-enabled/magento2dev.conf sudo brew services restart nginx Как да инсталирате Magento 2
Добре, в този момент вашата машина отговаря на изискванията на Magento 2, като липсва само самия звяр. Насочете се към уебсайта на Magento и създайте акаунт, ако все още нямате такъв. След това отидете на страницата за изтегляне и изтеглете най-новата версия (2.1.5, към момента на писане):
Изберете формата .tar.bz2 и го изтеглете. След това продължете да го извличате и задайте правилните разрешения за папки и файлове, за да може Magento 2 да работи:
mkdir ~/www/magento2dev cd ~/www/magento2dev tar -xjf ~/Downloads/Magento-CE-2.1.5-2017-02-20-05-39-14.tar.bz2 find var vendor pub/static pub/media app/etc -type f -exec chmod u+w {} ; find var vendor pub/static pub/media app/etc -type d -exec chmod u+w {} ; chmod u+x bin/magento Сега, за да инсталираме таблиците на базата данни и да създадем необходимите конфигурационни файлове, ще стартираме тази команда от терминала:
./bin/magento setup:install --base-url=http://magento2.dev/ --db-host=127.0.0.1 --db-name=magento2 --db-user=root --db-password=123 --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=admin123 --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --backend-frontname=admin Не забравяйте да промените името на базата данни (db-name), потребителя (db-user) и паролата (db-password), за да съответстват на това, което сте използвали по време на инсталацията на MySQL, и това е! Тази команда ще инсталира всички модули на Magento 2, създавайки необходимите таблици и конфигурационни файлове. След като приключи, отворете браузъра си и се насочете към http://magento2.dev/. Трябва да видите чисто инсталиране на Magento 2 със стандартната тема Luma:
Ако се насочите към http://magento2.dev/admin, трябва да видите страницата за вход на приложението Admin:
След това използвайте идентификационните данни по-долу, за да влезете:
Android работи на нишка на потребителския интерфейс
Потребител: администраторска парола: admin123
Най-накрая сме готови да започнем да пишем нашия код!
Създаване на първия ни модул Magento 2
За да завършим нашия модул, ще трябва да създадем следните файлове и аз ще ви преведа през целия процес. Ще ни трябва:
- Няколко регистрационни файла, за да информира Magento за нашия модул Блог
- Един интерфейсен файл за определяне на нашия договор за данни за пощата
- Модел на публикация, за да представлява публикация в целия ни код, прилагащ интерфейса за данни на Post
- Модел на ресурс за публикуване, за да свърже модела за публикуване с базата данни
- Колекция публикации за извличане на няколко публикации наведнъж от базата данни с помощта на ресурсния модел
- Два класа на миграция, за да настроите схемата и съдържанието на нашата таблица
- Две действия: едно за изброяване на всички публикации и друго за показване на всяка публикация поотделно
- По два от файловете Blocks, Views и Layout: Един от всеки за действието на списъка и един от всеки за изгледа
Първо, нека да разгледаме набързо структурата на папката на основния изходен код, за да можем да определим къде да поставим нашия код. Начинът, по който инсталирахме, има целия основен код на Magento 2, заедно с всички негови зависимости, живеещи в композиторския vendor папка.
Регистрация на нашия модул
Ще запазим нашия код в отделна папка, app/code. Името на всеки модул е във формата Namespace_ModuleName и местоположението му във файловата система трябва да отразява това име, app/code/Namespace/ModuleName за този пример. Следвайки този модел, ние ще назовем нашия модул ApeeScape_Blog и поставете нашите файлове под app/code/ApeeScape/Blog. Продължете и създайте тази структура на папките.
Сега трябва да създадем няколко шаблонни файла, за да регистрираме нашия модул в Magento. Първо създайте app/code/ApeeScape/Blog/composer.json:
{} Този файл ще се зарежда от Composer всеки път, когато го стартирате. Въпреки че всъщност не използваме Composer с нашия модул, трябва да го създадем, за да зарадваме Composer.
Сега ще регистрираме нашия модул в Magento. Продължете и създайте app/code/ApeeScape/Blog/registration.php:
Тук извикваме register метод на ComponentRegistrar клас, изпращайки два параметъра: низът 'module', който е типът компонент, който регистрираме, и името на нашия модул, 'ApeeScape_Blog' С тази информация, автоматичното зареждане на Magento ще е наясно с нашето пространство от имена и ще знае къде да търси нашите класове и XML файлове.
Едно интересно нещо, което трябва да забележите тук, е, че имаме типа на компонента (MODULE), който се изпраща като параметър към MagentoFrameworkComponentComponentRegistrar::register функция. Не само можем да регистрираме модули, можем да регистрираме и други видове компоненти. Например теми, външни библиотеки и езикови пакети също се регистрират по същия метод.
Продължавайки, нека създадем нашия последен регистрационен файл, app/code/ApeeScape/Blog/etc/module.xml:
Magento_DirectoryТози файл съдържа много важна информация за нашия модул. Те са:
- Името на модула присъства отново, излагайки името на модула ни на конфигурацията на Magento.
- Версията за настройка на Magento, която ще се използва от Magento, за да реши кога да стартира скриптове за миграция на база данни.
- Зависимостите на нашия модул - Тъй като пишем прост модул, ние зависим само от два основни модула на Magento:
Magento_Config и ./bin/magento cache:disable .
Сега имаме модул, който трябва да бъде разпознаваем от Magento 2. Нека го проверим с помощта на Magento 2 CLI.
Първо, трябва да деактивираме кеша на Magento. Кеш механизмите на Magento заслужават статия, посветена на тях самите. Засега, тъй като разработваме модул и искаме промените ни да бъдат разпознати от Magento незабавно, без да е необходимо да изчистваме кеша по всяко време, ние просто ще го деактивираме. От командния ред изпълнете:
./bin/magento module:status Тогава нека видим дали Magento вече е запознат с нашите модификации, като разгледаме състоянието на модулите. Просто изпълнете следната команда:
./bin/magento module:enable ApeeScape_Blog Резултатът от последния трябва да бъде подобен на:
Нашият модул е там, но както показва изходът, той все още е деактивиран. За да го активирате, изпълнете:
module:statusТова трябваше да го направи. За да сте сигурни, можете да се обадите InstallSchema отново и потърсете името на нашия модул в разрешения списък:
Работа със съхранение на данни
След като активирахме нашия модул, трябва да създадем таблицата на базата данни, която съдържа нашите публикации в блога. Това е схемата за таблицата, която искаме да създадем:
кое от следните е отговорен финансов директор?
Поле Тип Нула Ключ По подразбиране post_id int (10) неподписан НЕ PRI НУЛА заглавие текст НЕ НУЛА съдържание текст НЕ НУЛА created_at клеймо за време НЕ CURRENT_TIMESTAMP
Постигаме това, като създаваме app/code/ApeeScape/Blog/Setup/InstallSchema.php клас, който е отговорен за управлението на инсталацията на нашия миграция на схема . Файлът се намира на startSetup(); $tableName = $setup->getTable('toptal_blog_post'); if ($setup->getConnection()->isTableExists($tableName) != true) { $table = $setup->getConnection() ->newTable($tableName) ->addColumn( 'post_id', Table::TYPE_INTEGER, null, [ 'identity' => true, 'unsigned' => true, 'nullable' => false, 'primary' => true ], 'ID' ) ->addColumn( 'title', Table::TYPE_TEXT, null, ['nullable' => false], 'Title' ) ->addColumn( 'content', Table::TYPE_TEXT, null, ['nullable' => false], 'Content' ) ->addColumn( 'created_at', Table::TYPE_TIMESTAMP, null, ['nullable' => false, 'default' => Table::TIMESTAMP_INIT], 'Created At' ) ->setComment('ApeeScape Blog - Posts'); $setup->getConnection()->createTable($table); } $setup->endSetup(); } }
installАко анализирате setup_module метод, ще забележите, че той просто създава нашата таблица и добавя колоните й една по една.
За да определи кога да стартира миграция на схема, Magento поддържа таблица с всички текущи версии на настройките за всеки модул и всеки път, когато се променя версията на модула, нейните класове за миграция се инициализират. Тази таблица е ./bin/magento setup:upgrade и ако погледнете съдържанието на тази таблица, ще видите, че засега няма препратка към нашия модул. Така че, нека променим това. От терминал задействайте следната команда:
setup_moduleТова ще ви покаже списък на всички изпълнени модули и неговите скриптове за миграция, включително нашия:
Сега, от вашия предпочитан клиент на MySQL, можете да проверите дали таблицата наистина е създадена:
И в setup_version таблица, сега има препратка към нашия модул, неговата схема и версия на данните:
Добре, а какво ще кажете за надстройки на схеми? Нека добавим няколко публикации към тази таблица чрез надстройка, за да ви покажем как да направите това. Първо разбийте etc/module.xml на нашия app/code/ApeeScape/Blog/Setup/UpgradeData.php файл:
как работи отзивчивият уеб дизайн
Сега ние създаваме нашите startSetup(); if ($context->getVersion() && version_compare($context->getVersion(), '0.1.1') getTable('toptal_blog_post'); $data = [ [ 'title' => 'Post 1 Title', 'content' => 'Content of the first post.', ], [ 'title' => 'Post 2 Title', 'content' => 'Content of the second post.', ], ]; $setup ->getConnection() ->insertMultiple($tableName, $data); } $setup->endSetup(); } } файл, който е отговорен за миграцията на данни (а не на схема):
UpgradeDataInterfaceМожете да видите, че той е много подобен на нашия клас за инсталиране. Единствената разлика е, че той изпълнява InstallSchemaInterface вместо upgrade, а основният метод се нарича version_compare. С този метод проверявате за инсталираната версия на текущия модул и, когато е по-малък от вашия, активирате промените, които трябва да направите. В нашия пример проверяваме дали текущата версия е по-малка от 0.1.1 в следващия ред с помощта на if ($context->getVersion() && version_compare($context->getVersion(), '0.1.1') <0 ) { функция:
$context->getVersion()setup:upgrade обаждането ще върне 0.1.0, когато setup:upgrade Командата CLI се извиква за първи път. След това примерните данни се зареждат в базата данни и нашата версия се сблъсква с 0.1.1. За да стартирате това, продължете и задействайте ./bin/magento setup:upgrade :
setup_moduleИ след това проверете резултатите в таблицата с публикации:
И в UpgradeSchemaInterface маса:
Забележете, че въпреки че добавихме данни към нашата таблица, използвайки процеса на миграция, би било възможно да променим и схемата. Процесът е същият; бихте използвали само UpgradeDataInterface вместо app/code/ApeeScape/Blog/Model/ResourceModel/Post.php.
Дефиниране на модела за публикации
Продължавайки напред, ако си спомняте нашия общ преглед на архитектурата, следващият ни градивен елемент ще бъде публикацията в блога ResourceModel. Ресурсният модел е много прост и просто посочва таблицата, към която Моделът ще се „свърже“, заедно с това какъв е неговият първичен ключ. Ще създадем нашия ResourceModel на _init('toptal_blog_post', 'post_id'); } } със следното съдържание:
AbstractDbВсички операции на ResourceModel, освен ако не се нуждаете от нещо различно от обичайните CRUD операции, се обработват от app/code/ApeeScape/Blog/Model/ResourceModel/Post/Collection.php родителски клас.
Ще ни трябва и друг ResourceModel, колекция. Колекцията ще отговаря за заявката към базата данни за множество публикации с помощта на нашия ResourceModel и връщането на поредица от модели, инстанцирани и пълни с информация. Създаваме файла _init('ApeeScapeBlogModelPost', 'ApeeScapeBlogModelResourceModelPost'); } } със следното съдържание:
app/code/ApeeScape/Blog/Api/Data/PostInterface.phpЗабележете, че в конструктора просто споменаваме Model, който ще представлява обекта на публикация в нашия код и ResourceModel, който ще извлече информацията в базата данни.
Липсващата част за този слой е самият Post Model. Моделът трябва да съдържа всички атрибути, които сме дефинирали в нашата схема, заедно с всякаква бизнес логика, от която може да се нуждаете. Следвайки модела на Magento 2, трябва да създадем интерфейс за данни, от който ще се простира нашият модел. Поставяме интерфейса на и той трябва да съдържа имената на полетата на таблицата, заедно с методите за достъп до тях:
app/code/ApeeScape/Blog/Model/Post.phpСега към изпълнението на модела, на CACHE_TAG. Ще създадем методите, дефинирани на интерфейса. Също така ще посочим кеш маркер чрез _init('ApeeScapeBlogModelResourceModelPost'); } /** * Get Title * * @return string|null */ public function getTitle() { return $this->getData(self::TITLE); } /** * Get Content * * @return string|null */ public function getContent() { return $this->getData(self::CONTENT); } /** * Get Created At * * @return string|null */ public function getCreatedAt() { return $this->getData(self::CREATED_AT); } /** * Get ID * * @return int|null */ public function getId() { return $this->getData(self::POST_ID); } /** * Return identities * @return string[] */ public function getIdentities() { return [self::CACHE_TAG . '_' . $this->getId()]; } /** * Set Title * * @param string $title * @return $this */ public function setTitle($title) { return $this->setData(self::TITLE, $title); } /** * Set Content * * @param string $content * @return $this */ public function setContent($content) { return $this->setData(self::CONTENT, $content); } /** * Set Created At * * @param string $createdAt * @return $this */ public function setCreatedAt($createdAt) { return $this->setData(self::CREATED_AT, $createdAt); } /** * Set ID * * @param int $id * @return $this */ public function setId($id) { return $this->setData(self::POST_ID, $id); } } константа и в конструктора ще посочим ResourceModel, който ще отговаря за достъпа до базата данни за нашия модел.
app/code/ApeeScape/Blog/etc/frontend/routes.xmlСъздаване на изгледи
Сега се движим с един слой нагоре и ще започнем изпълнението на нашите ViewModel и Controller. За да дефинираме маршрут в приложението отпред (пазарска количка), трябва да създадем файла ApeeScape_Blog със следното съдържание:
app/code/ApeeScape/Blog/Controller/Index/Index.phpСписък на публикациите на страницата на индекса
Тук ние основно казваме на Magento, че нашият модул, resultPageFactory = $resultPageFactory; } /** * Prints the blog from informed order id * @return Page * @throws LocalizedException */ public function execute() { $resultPage = $this->resultPageFactory->create(); return $resultPage; } } , ще отговаря за отговорите на маршрути под http://magento2.dev/blog (забележете атрибута frontName на маршрута). Следва действието, при $context:
$resultPageFactoryНашето действие определя два метода. Нека ги разгледаме по-отблизо:
-
Методът на конструктора просто изпраща Context параметър на неговия родителски метод и задава PageFactory параметър към атрибут за по-късна употреба. На този етап е полезно да знаете Зависим инжекционен модел на инжектиране , тъй като тук се случва това. В случая на Magento 2 имаме автоматично инжекция на зависимост. Това означава, че всеки път, когато възникне екземпляр на клас, Magento автоматично ще се опита да инстанцира всички параметри на конструктора на класа (зависимости) и да го инжектира вместо вас като параметри на конструктора. Той идентифицира кои класове да бъдат създадени за всеки параметър, като проверява подсказките на типа, в този случай execute и MagentoFrameworkViewResultPage.
-
view/frontend/layout метод е отговорен за самото изпълнение на действието. В нашия случай просто казваме на Magento да изобрази оформлението си чрез връщане на blog/index/index обект. Това ще задейства процеса на изобразяване на оформлението, който ще създадем след малко.
Сега трябва да видите празна страница на url http://magento2.dev/blog/index/index. Все още трябва да дефинираме структурата на оформлението за този маршрут и съответния му блок (нашият ViewModel) и файла на шаблона, който ще представи данните на нашия потребител.
Структурата на оформлението за интерфейсното приложение е дефинирана под app/code/ApeeScape/Blog/view/frontend/layout/blog_index_index.xml и името на файла трябва да отразява нашия маршрут. Тъй като нашият маршрут е $block, файлът с оформление за този маршрут ще бъде blog/index/index:
ApeeScapeBlogBlockPostsТук трябва да дефинираме три много важни структури в структурата на оформлението на Magento: блокове, контейнери и шаблони.
-
Блокове са ViewModel част от нашата архитектура на MVVM, което беше обяснено в по-ранните раздели. Те са градивните елементи на нашата шаблонна структура.
-
Контейнери съдържат и извеждат блокове. Те държат блоковете заедно в хубави йерархични структури и помагат за осмислянето на нещата, когато оформлението на дадена страница се обработва.
-
Шаблони са PHMTL (смесени HTML и PHP) файлове, използвани от специален тип блок в Magento. Можете да осъществявате повиквания към методи на content променлива от шаблон. Променливата винаги се дефинира в контекста на шаблона. По този начин ще извиквате методите на вашия блок и по този начин ще ви позволи да изтеглите информация от слоя ViewModel до действителната презентация.
С тази допълнителна информация под ръка можем да анализираме структурата на XML оформлението по-горе. Тази структура на оформлението основно казва на Magento, че когато е направена заявка към ApeeScape_blog::post/list.phtml маршрут, блок от типа app/code/ApeeScape/Blog/Block/Posts.php се добавя към _postCollectionFactory = $postCollectionFactory; parent::__construct($context, $data); } /** * @return Post[] */ public function getPosts() { /** @var PostCollection $postCollection */ $postCollection = $this->_postCollectionFactory->create(); $postCollection->addFieldToSelect('*')->load(); return $postCollection->getItems(); } /** * For a given post, returns its url * @param Post $post * @return string */ public function getPostUrl( Post $post ) { return '/blog/post/view/id/' . $post->getId(); } } контейнер, а шаблонът, който ще се използва за неговото изобразяване, е getPostUrl.
Това ни води до създаването на двата ни останали файла. Нашият блок, разположен на ApeeScapeBlogModelResourceModelPostCollectionFactory:
ApeeScapeBlogModelResourceModelPostCollectionТози клас е доста прост и целта му е единствено да зареди публикациите, които ще се показват, и да предостави create метод към шаблона. Все пак има някои неща, които трябва да забележите.
Ако си спомняте, ние не сме определили get клас. Дефинирахме само $data. Е, как изобщо работи това? За всеки клас, който дефинирате във вашия модул, Magento 2 автоматично ще създаде a Фабрика за теб. Фабриките имат два метода: MagentoFrameworkViewElementTemplate, който ще връща нов екземпляр за всяко повикване и public function __construct( TemplateContext $context, array $data = [] ) { ... , който винаги ще връща един и същ екземпляр, когато е извикан - използван за реализиране на Сингълтън модел.
Третият параметър на нашия блок, CollectionFactory, е незадължителен масив. Тъй като не е задължителен и няма подсказка за тип, той няма да се инжектира от системата за автоматично впръскване. Важно е да забележите това по избор конструктор параметри трябва винаги да бъде позициониран последен в параметрите. Например конструкторът на public function __construct( Context $context, PostCollectionFactory $postCollectionFactory, array $data = [] ) { ... , нашият родителски клас, има следните параметри:
getPostsКакто искахме да добавим нашите create към параметрите на конструктора след разширяване на класа Template, трябваше да го направим преди незадължителния параметър, в противен случай инжектирането няма да работи:
PostCollectionFactoryВ PostCollection метод, който ще бъде достъпен по-късно от нашия шаблон, ние просто извикваме app/code/ApeeScape/Blog/view/frontend/templates/post/list.phtml метод от getPost()->getContent(); ?>
, който ще ни върне нов getPost и ни позволяват да извлечем публикациите си от базата данни и да ги изпратим на нашия отговор.
И за да завършим оформлението на този маршрут, ето нашия PHTML шаблон, app/code/ApeeScape/Blog/view/frontend/layout/blog_post_view.xml:
ApeeScapeBlogBlockViewХубаво и просто, просто достъп до блока View content метод, който създадохме по-рано.
И за да съберем всичко, ние създаваме файл с оформление за новия ни маршрут на ApeeScape_Blog::post/view.phtml със следното съдържание:
|_+_|
Това прави същото, което направихме и преди. Той просто добавя
|_+_|
към |_+_|
контейнер, с |_+_|
като свързания шаблон. За да го видите в действие, просто насочете браузъра си към http://magento2.dev/blog/post/view/id/1, за да заредите успешно публикация. Трябва да видите екран като този по-долу:
как да получа m3u8 url
И както можете да видите, след създаването на нашата първоначална структура е наистина лесно да добавите функции към платформата и по-голямата част от първоначалния ни код се използва повторно в процеса.
В случай, че искате бързо да тествате модула, тук е общият резултат от нашата работа.
Къде да отида от тук
Ако сте ме проследили до тук, поздравления! Сигурен съм, че сте съвсем близо да станете разработчик на Magento 2. Разработихме доста усъвършенстван потребителски модул Magento 2 и въпреки че той е прост по своите характеристики, много земя беше покрита.
Някои неща бяха оставени извън тази статия, за по-голяма простота. За да назовем само няколко:
- Администратор за редактиране на формуляри и мрежи за управление на съдържанието на нашия блог
- Категории, етикети и коментари в блогове
- Хранилища и няколко договора за услуги, които бихме могли да създадем
- Опаковъчни модули като разширения на Magento 2
Във всеки случай, ето няколко полезни връзки, където можете да задълбочите знанията си още повече:
- Блог на Alan Storm в Magento 2 - Алън Сторм има може би най-дидактичното съдържание, когато става въпрос за изучаване на Magento.
- Блогът на Алън Кент
- Документация за Magento: Magento 2 Dev Docs
Предоставих ви изчерпателно въведение във всички съответни аспекти на това как да създадете модул в Magento 2 и няколко допълнителни ресурси, ако имате нужда от тях. Сега зависи от вас да получите кодиране или преминете към коментарите, ако искате да прецените.
Разбиране на основите
Кой използва Magento?
Търговци големи и малки по света използват Magento и Magento 2 за своите уебсайтове за електронна търговия.
Какво е Magento 2.0?
Magento 2.0 е пренаписване на Magento, фокусиращо се върху производителността, автоматизираното тестване, подобреното администриране отзад, модерен потребителски интерфейс (UI) отпред и разширяемост, което улеснява разработването на персонализирани модули без конфликти.
Какво е разработчик на Magento?
Разработчик на Magento може да се позовава на някой, който работи върху основния проект на Magento. Но по-често се отнася до програмист, който инсталира Magento или Magento 2 и работи върху приспособяването на външния му вид и функционалност, за да отговори на потребителските нужди на компанията за нейния онлайн магазин.
Какво представлява рамката Magento?
Magento Framework контролира как компонентите работят заедно. Той включва няколко библиотеки и тяло от персонализиран код и се отнася до зависимости на трети страни, по-специално рамките Zend и Symfony.
Как да инсталирам Magento?
Magento може да се инсталира чрез контейнер на Docker или чрез настройка на специален хост. Горният урок описва как да се постигне последното.
Magento CMS ли е?
Не точно: Magento включва интегрирана CMS, така че като цяло обхватът й е по-голям от това, което CMS обикновено включва.
