Różnice pomiędzy Magento 1 i 2

Nie da się już zaprzeczyć, że Magento zyskuje coraz większą popularność wśród silników e-commerce. Najlepszym dowodem na to, że jest to wartościowa pozycja na rynku, jest sam fakt tego, że został wykupiony przez Adobe, poszerzając ofertę produktową giganta.

Między narodzinami Magento 1, a oficjalnym wydaniem Magento 2, minęło 10 lat. Mimo, iż silnik w wersji 2 wciąż posiada wiele niezałatanych wad, to wydaje mi się, że jest to już dobry moment na przesiadkę. Przemawia za tym przede wszystkim:

• kończące się wsparcie dla Magento 1
• koniec wsparcia dla PHP 5.6
• niesamowita siła architektury Magento 2

Magento “wczoraj i dziś”

Dystrybucje

W przypadku Magento 1 mieliśmy do czynienia z dwoma głównymi dystrybucjami:

• Magento Community Edition (CE) - open source
• Magento Enterprise Edition (EE) - komercyjna

Natomiast w Magento 2 mamy do dyspozycji jedną dystrybucję open source i dwie komercyjne, w tym jedna z pełnym hostingiem:

• Magento Open Source
• Magento Commerce
• Magento Commerce Cloud

Proces zakupowy

Proces zakupowy został uproszczony do 2 kroków z nawet 6 w przypadku Magento 1. Dzięki dopasowaniu do strategii omnichannel, łatwiej pogodzić sprzedaż on- i offline.

Bezpieczeństwo

Również w kwestii bezpieczeństwa, mimo niedawnej wpadki dot. wycieku danych, Magento 2 wygląda lepiej od Magento 1, m.in.:

• wprowadzono zabezpieczenia przed atakami XSS. System uprawnień plików teraz jest bardziej elastyczny,
• poprawione zapobieganie exploitom typu „clickjacking”,
• zrezygnowano z domyślnego adresu url dla panelu administratora.

Najłatwiej porównać ich ilość i wagę przeglądając strony:

• NVD
• CVE

Web serwer

Obydwie wersje Magento można postawić zarówno na Apache 2, jak i NGNIX - poniżej znajduje się zestawienie per konkretna wersja:

• Magento 1: Apache 2.x, NGNIX 1.7.x
• Magento 2.0-2.1 - Apache 2.2 lub 2.4, NGNIX >= 1.8
• Magento 2.2-2.3 - Apache 2.2 lub 2.4, NGNIX 1.x

PHP

Podstawowym wyzwaniem dla twórców każdego większego silnika jest jego wydajność. Zwolennicy Magento 1 są przekonani o tym, iż przejście na Magento 2, równać się będzie jej ogromnemu spadkowi. Zgodzę się tylko w kwestii tego, że M2 jest dużo bardziej wymagającym silnikiem, jednak poprawnie skonfigurowany “ekosystem” aplikacji, potrafi sprawić, że sklep jest w stanie pracować o wiele wydajniej.

Nowością jest przede wszystkim współpraca z prawie najnowszą wersją PHP 7. Prawie, ponieważ ostatnia przetestowana wersja to 7.2.11, a najnowsza - 7.3.3 (stan na kwiecień 2019). Nikomu raczej nie trzeba tłumaczyć przewagi PHP 7 nad PHP 5.6, jeśli chodzi o wydajność. Jednak o ile M2 zostało zaprojektowane pod PHP 7 to, dla większości wersji M1 ( <1.9.4.0) należy zainstalować patch “PHP 7.2 support”.

Poniżej znajduje się zestawienie kompatybilności wersji PHP z wersjami Magento:

• Magento < 1.9.2- PHP: 5.4.x, 5.5.0–5.5.21, 5.5.22–5.5.x
• Magento >= 1.9.2- PHP: 5.4.x, 5.5.0–5.5.21, 5.5.22–5.5.x, 5.6.x, 7.2.x
• Magento 2.0- PHP: 5.5.22–5.5.x, 5.6.x, 7.0.2, 7.0.6-7.0.x
• Magento 2.1- PHP: 5.6.5-5.6.x, 7.0.2, 7.0.4, 7.0.6-7.0.x, 7.1.x
• Magento 2.2- PHP: >7.0.13, 7.1.x, 7.2.0-7.2.11
• Magento 2.3- PHP: 7.1.3, 7.2.11

W przypadku każdej z wersji Magento, będą nam potrzebne dodatkowe biblioteki dla PHP:

• Magento 1- PDO_MySQL, simplexml, mcrypt, hash, GD, iconv, curl, SOAP
• Magento 2.0-2.1- bc-math (dla Magento Commerce), curl, gd, ImageMagick 6.3.7 (=>) lub oba, intl, mbstring, mcrypt, hash, openssl, PDO/MySQL, SimpleXML, soap, xml, xsl, zip, PHP 7 tylko: json, iconv
• Magento 2.2- bc-math (dla Magento Commerce), ctype, curl, dom, gd, ImageMagick 6.3.7 (=>) lub obax, intl, libxml, mbstring, mcrypt, hash, openssl, PDO/MySQL, SimpleXML, soap, xsl, zip, json, iconv
• Magento 2.3- ext-bcmath, ext-ctype, ext-curl, ext-dom, ext-gd, ext-hash, ext-iconv, ext-intl, ext-mbstring, ext-openssl, ext-pdo_mysql, ext-simplexml, ext-soap, ext-spl, ext-xsl, ext-zip, lib-libxml

W przypadku wszystkich wersji Magento 2, w celu zwiększenia wydajności, zalecana jest dodatkowo konfiguracja PHP OPcache oraz wprowadzenie odpowiednich wartości w php.ini:

Warto tutaj wspomnieć o tym, że PHP 5.6 utraciło już wsparcie. Zdaję sobie sprawę, że na wielu hostingach jeszcze znajdziemy tę wersję i (o zgrozo) starsze również. Ale ten stan rzeczy nie potrwa długo, z uwagi na brak łatek bezpieczeństwa. Dodatkowo hostingi powoli wycofują bibliotekę MySQL na rzecz MySQLi. Warto o tym pamiętać przy ewentualnej migracji.

MySQL

O ile w przypadku PHP mamy bardzo duże rozbicie wersji, to po stronie MySQL, sytuacja wygląda o wiele prościej. Magento 1 wykorzystuje MySQL 5.6, od wersji 2.0 możemy wykorzystać MySQL 5.7 i MariaDB, natomiast wersja 2.2 i 2.3 jest kompatybilna również z MySQL NDB Cluster.

Istnieją również rozszerzenia, które pozwalają na użycie PostreSQL. W przypadku MySQL natomiast, Magento działać będzie również na innych kompatybilnych binarnie forkach, ale oficjalnie zaleca się Oracle lub Percone.

Dla uzyskania większej wydajności w Magento 2 Commerce, transakcje, zamówienia i dane produktów mogą korzystać z oddzielnych baz danych (master), które można również replikować. Ta funkcja niestety nie jest dostępna w przypadku wersji Open Source i Magento Commerce Cloud.

Źródło: Magento

SSL

Certyfikaty są potrzebne przede wszystkim dla połączeń HTTPS. Żadna z wersji Magento nie wspiera certyfikatów “Self-signed”. Transport Layer Security (TLS >= 1.1) wymagany jest dla połączeń z PayPal i repo.magento.com.

Mail server

W przypadku wszystkich wersji Magento 2, zalecany jest MTA (Mail Transfer Agent) lub SMTP Server. Dokumentacja Magento 1 nie rekomenduje konkretnego serwera, natomiast istnieją wtyczki, które umożliwiają spięcie Magento z praktycznie dowolnym serwerem mailingowym.

JavaScript

W Magento 1 teoretycznie królowała biblioteka Prototype we wszystkich corowych funkcjach. Mimo wszystko dzięki funkcji jQuery.noConflict(), zdecydowana większość deweloperów przemycała jQuery i na tym opierała swoje rozwiązania. W odpowiedzi na tę potrzebę, w Magento 2 wyparto Prototype, na rzecz Knockout’a, który ułatwia wstrzyknięcie m.in Jquery. Knockout dodatkowo implementuje wzorzec Model-View-View Model.

Jednak to nie koniec zmian. Kolejnym krokiem w dobrą stronę jest implementacja RequireJS, a tym samym ograniczenie niepotrzebnych żądań po stronie klienta. Wprowadzono też możliwość rozszerzania corowych skryptów js bez potrzeby ich nadpisywania za pomocą “miximów”.

Zmieniły się też ścieżki, w których przechowywane są skrypty js. Wcześniej mogliśmy umieścić je w jednym z katalogów z plikami naszej skórki (np. skin/frontend/rwd/default/js), albo bezpośrednio w katalogu js, znajdującym się w głównym katalogu aplikacji. W przypadku Magento 2 wyróżniamy cztery lokalizacje katalogu js:

1. lib/web- zagregowane tutaj biblioteki będą dostępne w obrębie całego Magento
2. <module_dir>/view/<areaname>/web- zasoby będą dostępne, jeśli moduł jest włączony
3. <theme_dir>/<VendorName>_<ModuleName>/web- w tym katalogu możemy umieścić js dostępny dla danej skórki, który będzie nadpisywał oryginalny js modułu, jednak w ramach możliwości powinniśmy korzystać z wcześniej wspomnianych “miximów”
4. <theme_dir>/web- zasoby zgromadzone tutaj będą dostępne w przypadku dziedziczenia

CSS

Magento 2 używa teraz dla prekompilacji CSS LESS-a. Istnieje również możliwość zmiany na SASS-a. Magento 1 nie dostarczało tego mechanizmu domyślnie. Pliki styli umiejscowione są analogicznie do skryptów js, z tą różnicą, że znajdują się w katalogu css.

Pliki XML modułów i szablonów

Żeby opisać, jak wiele zmieniło się w XML-ach, trzeba by było napisać osobny artykuł. W Magento 1 mieliśmy dość ograniczoną liczbę możliwości i sposobów wpływania na wygląd strony. Nasz moduł zgłaszał konkretny module_layout.xml, w który to zamieszczaliśmy odpowiednie bloki i kontenery dla każdej akcji na stronie (np. <catalog_product_view translate="label">). Podobnie rzecz się ma w przypadku Magento 2, jednak poziom precyzji może sięgać wręcz do ID docelowego produktu.

Podobnie jak w przypadku plików js, również pliki layoutów zmieniły swoją lokalizację:

• Podstawowe pliki layoutów, dostarczane przez moduły
• Konfiguracja strony i ogólne pliki układu: <module_dir>/view/frontend/layout
• Pliki układu strony: <module_dir>/view/frontend/page_layout

• Pliki layoutów, personalizacja wyglądu funkcji dla danej skórki
• Konfiguracja strony i ogólne pliki układu: <theme_dir>/<Namespace>_<Module>/layout
• Pliki układu strony: <theme_dir>/<Namespace>_<Module>/page_layout

Inną dość istotną zmianą, którą doceni każdy deweloper, jest rozbicie zapisów w pliku config.xml. W Magento 1 plik ten zawierał praktycznie wszystko, przez co w przypadku większych modułów był totalnie nieczytelny. W Magento 2 zostało to poprawione i możemy cieszyć się z takich zasobów, jak np. events.xml, email_templates.xml, czy chociażby crontab.xml. Zmiana ta przede wszystkim wprowadza większy ład, a intuicyjne nazewnictwo ułatwia odnalezienie się nie tylko nowicjuszom.

Nowości w architekturze Magento 2

Dependency injection

Jeśli już jesteśmy przy XML-ach, to nie sposób nie wspomnieć o di.xml. Plik ten konfiguruje, które zależności będą wprowadzane przez object manager. Za pomocą tego pliku nadpiszemy również corowe zasoby, zdefiniujemy pluginy, API (interface preference, virtual type oraz nowe polecenia CLI).

Jeśli przyjrzymy się bliżej modułom Magento, to rzekłabym, że dependency injection jest kręgosłupem praktycznie każdej funkcji. Trudno się dziwić, skoro silnik w wersji 2 opiera się już nie tylko o Zend Framework, ale też o Symfony, Monolog i wiele innych frameworków oraz bibliotek. DI jednak jest dość dobrze znane wszystkim miłośnikom Symfony, a z kolei Magento 2 nadaje niebywałej elastyczności.

ViewModel

Zadaniem ViewModel (od Magento 2.2.x) jest odciążenie klas bloków oraz przeciwdziałanie powielaniu kodu, poprzez wstrzyknięcie obiektu przy pomocy DI. Dzięki temu wiele bloków może korzystać w prosty sposób z tych samych metod, bez ryzyka wystąpienia problemów z dziedziczeniem.

Extension attributes

Kolejną nowością w Magento 2 są extension attributes. Ich zadaniem jest rozszerzanie funkcjonalności. Często używane są do bardziej złożonych typów, niż standardowe atrybuty. Nie są niestety widoczne w panelu administracyjnym.

Pluginy

Wisienką na torcie, jakim jest elastyczność, stały się Pluginy. Są one odpowiedzią na konflikty, które powstawały podczas rozszerzania corowych funkcji Magento 1, kiedy to kilka modułów rozszerzało, bądź nadpisywało ten sam. Zadaniem pluginów jest umożliwienie wprowadzenia zmian przed, w trakcie, bądź po wywołaniu metody w danej klasie. Można je zastosować jednak tylko do metod publicznych.

Observery

Podobnie jak bałagan występował często w pliku config.xml, tak też można go było spotkać w observerach. W Magento 1 panowała totalna dowolność zapisu. Magento 2 ustandaryzowało sposób tworzenia observerów. Ich pliki zostały wyniesione poza katalog Model, do katalogu Observer, ograniczono je ponadto do jednego observera na klasę, a konfigurację przeniesiono do wspomnianego wcześniej pliku events.xml. Każdy observer zgodnie z założeniami DI, implementuje interfejs - ObserverInterface.

API

Przepisano na nowo API, dzięki czemu funkcjonalność API i modułu nie jest już dublowana w Magento 2. Zamiast tego wprowadzono interfejsy, które spełniają funkcje API i określają, jakie zasoby będą dostępne za pomocą API.

Automatycznie generowane klasy

Automatycznie generowane klasy, to absolutna nowość w Magento 2. Procesowi temu podlegają fabryki, proxy, interceptory etc.

Service’y i repozytoria

Są to wzorce, które pozwalają na stabilne ulepszenia, łatwiejszy rozwój, spójny kod i praktyczne zastosowanie dependency injection.

Aktualizacje bazy danych

W Magento 1 mieliśmy wiele plików aktualizujących, które były dopasowane do wersji modułu i uruchamiane wraz z odświeżeniem strony. Natomiast w Magento 2 wyróżniamy 5 rodzajów plików, które wyzwalane są podczas polecenia ‘bin/magento setup:upgrade’, przez skrypt CLI:

• \Magento
• \Setup
• \Console
• \Command
• \UpgradeCommand

Dwa z nich służą do tworzenia tabel i zaimportowania do nich wierszy podczas instalacji modułu:

• InstallSchema.php - skrypty aktualizujące strukturę bazy danych
• InstallData.php - skrypty zasilające bazę danymi

Dwa kolejne służą do aktualizacji wcześniej zainstalowanych tabel. Uruchamiają się tylko raz w ramach danej wersji modułu - również podczas instalacji:

• UpgradeSchema.php - znajdą się tutaj np. nowe atrybuty produktu
• UpgradeData.php - wprowadzi nowe lub zaktualizuje rekordy

Ostatni plik Recurring.php uruchamia się przy każdym upgrade.

Skrypty CLI

W Magento 1 mogliśmy napisać skrypty, które wykonywały się w CLI, jednak w Magento 2 wygląda to dużo profesjonalniej. Po wpisaniu w konsoli polecenia bin/magento, wyświetli się pełna lista dostępnych skryptów CLI. Oczywiście nie jest ona zamknięta, co daje możliwość tworzenia własnych skryptów .

Narzędzia do testowania

Podczas developmentu funkcji dla Magento 2, mamy możliwość dostarczania w prosty sposób testów takich, jak:

• testy funkcjonalne
• funkcjonalność API
• testy integracyjne
• testy skryptów js za pomocą JsTestDriver
• statyczna analiza kodu
• testy jednostkowe (TDD)

Crontab

Rozwiązano problem zapychających się kolejek cron, poprzez dodanie możliwości stworzenia grup. Dzięki temu zadania, których czas wykonania jest bardzo istotny (np. co minutę), mogą się wykonywać niezależnie od pozostałych zadań, oczekujących na przetworzenie.

Najczęściej wykorzystywane narzędzia

W przypadku Magento 1, rekomendowanymi narzędziami są:

• Redis
• Memcached
• Solr search

Natomiast w przypadku Magento 2:

• Redis
• Varnish
• Elasticsearch
• RabbitMQ

W przypadku Magento 1 musimy najczęściej zainstalować moduł, który pozwoli na integrację z narzędziem. Magento 2 w większości posiada już na start natywne rozwiązania, które zdecydowanie upraszczają ten proces.

Czy warto migrować do Magento 2?

Oczywistym jest, że z racji końca wsparcia dla PHP 5.6, biznes zostanie zmuszony do inwestycji w upgrade silnika. Od tego, jak bardzo zmodyfikowane/nadpisane zostały corowe rozwiązania, zależeć będzie, czy upgrade do Magento 2 nastąpi i czy będzie on jedno, czy dwuetapowym procesem (migracja magento 1 do PHP 7 plus migracja do Magento 2).

W wielu przypadkach niestety przejście na M2 będzie polegało na dosłownie postawieniu nowego sklepu, co wygeneruje spore koszta po stronie biznesu. Dlatego instalacja patcha dla PHP 7, wydaje się tańszym i szybszym rozwiązaniem dla wielu mniejszych e-commerców.

Warto pamiętać, że proces migracji jest zawsze procesem wielowarstwowym. Najważniejszymi etapami migracji są:

• migracja bazy danych- dane klientów, zamówienia, katalog produktów, historia płatności itd.
• migracja layoutu- z uwagi na różnice architektoniczne, jest to praktycznie proces tworzenia layoutu od zera
• migracja rozszerzeń- należy pamiętać, że nie wszystkie rozszerzenia muszą mieć swoje odpowiedniki dla wersji Magento 2
• migracja indywidualnych rozwiązań

Wsparcie dla Magento 1 jednak w końcu się skończy, dlatego też decyzja biznesowa musi opierać się nie tylko o bieżące, ale i przyszłe wydatki związane z migracją zarówno samego silnika, jak i infrastruktury hostingowej.

Czas migracji to czas, w którym warto przedefiniować biznes i to, jak jest obsługiwany przez platformę. Wtedy warto pochylić się nad problemami, które powstały na przestrzeni być może nawet tych 10 lat. Czas, kiedy wszystkie tzw. work around’y wypadałoby uwzględnić zgodnie ze sztuką. Klientom będzie można zaoferować nie tylko nowy wygląd sklepu, ale i nowe funkcjonalności.

W przypadku nowych wdrożeń sprawa wydaje się przesądzona. Osobiście nie zainwestowałbym w produkt, który jest u kresu swej żywotności. Elastyczność i siła architektury Magento 2, również jest bardzo silnym argumentem do tego, by wybrać właśnie tę wersję silnika.

Z punktu widzenia dewelopera, taka migracja to niesamowita przygoda i ogromny skok rozwojowy. O Magento 1 wielu z nas wie już wszystko, bądź prawie wszystko. Z kolei Magento 2 daje niesamowite możliwości rozwoju w wielu obszarach. To dziewicza wciąż jeszcze ziemia, na której można bez problemu odcisnąć swój ślad.

Nie można na koniec nie wspomnieć, że przyszłość Magento wydaje się bardzo ciekawa, odkąd zostało wykupione przez Adobe. Firma ta bowiem ma niesamowite doświadczenie w AI, ML i UX oraz bogaty wachlarz produktów, które mogłyby zostać zintegrowane z Magento np:

• Advertising Cloud - kompleksowa platforma do zarządzania reklamami telewizyjnymi oraz w formatach cyfrowych
• Analytics - odkrywanie grup klientów i podejmowanie decyzji biznesowych na podstawie informacji o klientach
• Campaign - automatyzacja i personalizacja marketingu pod kątem potrzeb wszystkich klientów
• Marketing Cloud - udostępnianie klientom spersonalizowanych materiałów we wszystkich kanałach marketingu