Magento

Tout sur la solution e-commerce Magento

Me(e)t Magento Polska - było warto

Minął już tydzień od powrotu ekipy Baobazu z pierwszego spotkania MeetMagento w Polsce, emocje trochę opadły, ale wciąż uważamy - warto było!

Baobaz na Meet Magento 2012 w Warszawie

Społeczność Magento

Na pierwszym Meet Magento Polska pojawiło się około setki uczestników z całej Europy. Thomas Fleck, z NetResearch, pięknie ubrał to w słowa - Przyjechałem do Polski z Niemiec, by wysłuchać prezentacji szwajcarskiej firmy, w języku angielskim, na temat doświadczeń z implementacją Magento w Ghanie.

Różnorodność doświadczeń uczestników sprzyjała wymianie wiedzy w przerwach między prezentacjami. Dyskusje toczono także w trakcie After Party w klubie Panorama na 40 piętrze hotelu Mariott. A ponadto - w jakich innych okolicznościach moglibyśmy mieć okazję spotkać na raz kilku z byłych członków Magento Core Team i zadać im pytania, które od dawna zadawaliśmy sobie integrując Magento? Oppa Gagnam Style bros! :)

Doświadczeni prezenterzy

Meet Magento było okazją do wysłuchania 22 prezentacji 23 prelegentów (w tym Piotra Kamińskiego, Damiana Luszczymak, Ivana Chepurnyi i Vinai Kopp), którzy podzielili się zarówno swoimi doświadczeniami z integracją Magento jak i rozwiązaniami dla rynku e-commerce (bramki płatności, obsługa korespondencji e-mail). Dzięki obecności przedstawicieli Magento można było też wysłuchać jak Magento rozwijało się w ostatnich latach, na czym polega certyfikacja programistów Magento oraz co dzieje się w temacie Magento 2.0.

Dla tych którzy z niecierpliwością czekają na nową inkarnację Magento wiadomość jest dobra i zła zarazem. Magento dokłada starań by nowa wersja była sprawdzona testami jednostkowymi, funkcjonalnymi i wydajnościowymi, a także w pełni udokumentowana. Oznacza to jednak, że prawdopodobnie Magento 2.0 nie pojawi się wcześniej niż za rok, bowiem zachodzące zmiany wciąż dotykają rdzenia systemu. W między czasie możemy liczyć na kolejne wydania typu Service Pack dla Magento 1.x, które ma być utrzymywane jeszcze przez kilka lat po wydaniu Magento 2.0.

Organizacja

Wielkie gratulacje należą się organizatorom z ekipy Snowdog.pl - Kubie Zwolińskiemu i Marcie Molińskiej - która, mimo że debiutowała w tej roli, przygotowała to wydarzenie w profesjonalny i niezmiernie sympatyczny sposób. Od samego wejścia do hotelu uprzejme dziewczyny w pomarańczowych koszulkach z logo wydarzenia kierowały uczestników na odpowiednie piętro do odpowiedniej sali. Prezentacje w języku polskim były symultanicznie tłumaczone na jezyk angielski i, w takiej też formie, były dostępne w streamie.

Świetna robota! Z niecierpliwością, i na przekór Majom, czekamy na kolejną edycję Meet Magento w 2013 roku!

Bardzo cieszymy się, że mogliśmy jako sponsor wspomóc organizację tego wydarzenia i dziękujemy audytorium, które bardzo ciepło przyjęło naszą prezentację.

Baobaz na Meet Magento Polska

Po raz pierwszy w Polsce społeczność Magento ma okazję spotkać się w jednym miejscu i podzielić doświadczeniami z najdynamiczniej rozwijającym się systemem e-commerce na świecie na konferencji Meet Magento Polska, która odbędzie się w Warszawie w dniach 23-24 listopada (program).

Meet Magento Polska

Baobaz dołączył do tego przedsięwzięcia jako jeden z partnerów, nie zabraknie nas też wśród prelegentów. Autorami prezentacji o przewrotnym tytule "Ale u mnie działa... - czyli repozytoria kodu i automatyczna publikacja w projektach Magento" są posiadacze certyfikatu Magento Certified Developer Plus - Maciej Krasuski i Kamil Węgrzynowicz.

Wszystkich zachęcamy do udziału i spotkania z nami w Warszawie!

Konfiguracja Magento do pracy z wieloma stronami lub sklepami

Istnieje wiele poradników w których napisano jak skonfigurować Magento do pracy z wieloma sklepami, tak by różne domeny wskazywały na wybrane sklepy. Począwszy od wydań Magento CE 1.4.0.0-alpha2 i Magento EE 1.6.0.0 stało się to wiele prostsze w wykonaniu.

Magento ewoluuje

Rozwiązania stosowane w poprzednich wersjach wymagały od programisty modyfikacji zawartości pliku index.php, jeżeli chciał obsłużyć wyświetlanie różnych sklepów zależnie od domeny. Nowy plik index.php zawiera następujący kod:

$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';

Mage::run($mageRunCode, $mageRunType);

Sprawdza on dwie zmienne środowiskowe i używa ich uruchamiając Magento. Jakie możliwości to nam daje? Możemy teraz ustawić który sklep ma działać pod daną domeną bezpośrednio w definicji wirtualnego hosta a nawet w pliku .htaccess.

Rozwiązanie z użyciem VirtualHost

Aby czerpać z korzyści powyższego kawałka kodu wystarczy dodać następujące linie wewnątrz definicji wirtualnego hosta:

SetEnv MAGE_RUN_CODE "base" # wstaw tu kod strony lub sklepu
SetEnv MAGE_RUN_TYPE "website" # wstaw tu 'website' lub 'store'

Rozwiązanie z użyciem .htaccess

Jeżeli nie masz dostępu do definicji wirtualnego hosta, możesz wciąż wykorzystać w tym celu plik .htaccess, umieszczając w nim następujące linie:

SetEnvIf Host .*yourhost.* MAGE_RUN_CODE=base
SetEnvIf Host .*yourhost.* MAGE_RUN_TYPE=website

Gdzie .*yourhost.* jest wyrażeniem regularnym wychwutującym domenę dla której chcesz ustawić zmienną środowiskową.

Masz zatem teraz możliwość skonfigurować Magento do pracy z wieloma sklepami bez konieczności mieszania w rdzeniu Magento. Powodzenia.

Magento - moduł tłumaczeń

Jedną z najlepszych rzeczy w magento jest możliwość łatwego dodawania nowych wersji językowych do strony. Robi się to używając plików CSV. Dla każdego języka mamy jeden plik na jeden moduł. Dla najpopularniejszych języków gotowe tłumaczenia dostępne są za darmo jako moduły Magento w systemie magento connect.

A co jeśli chcemy zmienić jakieś tłumaczenie i nie zgubić zmian po uaktualnieniu magento i modułów z tłumaczeniami? Lub jeśli chcemy mieć jakieś teksty tłumaczone poza kontekstem jednego modułu? Lub po prostu mieć wykaz wszystkich tekstów które zostały przez nas dodane a nie ma ich w "gołym" magento? Możemy stworzyć swój własny prosty moduł tłumaczeń.

Wystarczy stworzyć 2 pliki:

  • etc/config.xml
     <?xml version="1.0"?>
     <config>
            <modules>
                    <baobaz_translations>
                            <version>0.1.0</version>
                    </baobaz_translations>
            </modules>
           
            <global>
                    <helpers>
        <translations>
        <class>Baobaz_Translations_Helper</class>
        </translations>
        </helpers>
            </global>
           
            <frontend>
        <translate>
        <modules>
                                    <baobaz_translations>
                                            <files>
                                                    <default>Baobaz_Translations.csv</default>
                                            </files>
                                    </baobaz_translations>
                            </modules>
        </translate>
        </frontend>
     
     </config>
     
  • oraz helper/data.php:
    class Baobaz_Translations_Helper_Data extends Mage_Core_Helper_Abstract
    {

    }

 

I to wszystko... Moduł trzeba włączyć (w etc/modules) i wszystko będzie działać.

w app/locale/fr_fr/ tworzymy plik Baobaz_Translations.csv a w nim wstawiamy wszystkie przetłumaczone teksty.

Następnie wszędzie w projekcie - niezależnie od tego czy jest to szablon, blok czy kontroler możemy użyć składni:

echo Mage::helper('translations')->__('tekst do tłumaczenia');

Tak, to jesttak proste.

Dodawawanie tłumaczeń w Magento

Tłumaczenia pomiędzy językami są całkiem proste do zrealizowania w Magento. Dla doświadczonego programisty PHP, który pracował już z frameworkami, nie ma nawet o czym wspominać. Jednak osoba, która stawia pierwsze kroki w budowaniu wielojęzycznej aplikacji. może potrzebować kilku słów wprowadzenia. Teksty, które przeznaczone są do tłumaczenia, przechowywane są w plikach CSV, w katalogu /app/locale/[kod_jezyka]. Część ścieżki oznaczona jako [kod_jezyka] to na przykład 'pl_PL'.

Przyjrzyjmy się teraz zawartości któregoś z tych plików - każdy z nich ma tę samą strukturę. Linie w każdym pliku zawierają dwa teksty oddzielone przecinkiem: jeden w twoim domyślnym języku i jeden w języku docelowym. Aby móc używać tych plików - nazywanych też słownikami - trzeba zadeklarować je w pliku konfiguracyjnym danego modułu (config.xml). Poniższy kod musi zostać umieszczony wewnątrz znacznika frontendu lub admina - zależnie od tego, dla której części sklepu przeznaczone są tłumaczenia.

<translate>
        <modules>
                <nazwafirmy_nazwamodulu>
                        <files>                 <default>NazwaFirmy_NazwaModulu.csv</default>
                        </files>
                </nazwafirmy_nazwamodulu>
        </modules>
</translate>

To wszystko ;) Teraz, aby użyć tekstu, który ma zostać przetłumaczony, napisz:

echo $this->__('tekst do przetłumaczenia');

Magento sprawdzi czy w słownikach znajduje się tekst o treści 'tekst do przetłumaczenia' i wyświetli odpowiadające mu tłumaczenie w języku aktualnego sklepu.

Opcje backoffice (Panelu Admina) w Magento - [Część 1]

Jeśli rozpoczynasz dopiero swoją przygodę z Magento, możesz być przerażony ilością opcji, którą oferuje ci backoffice (nazywany też "Panelem Admina"). Po typowej instalacji dostępne są: Dashboard, Sales, Catalog, Customers, Promotions, Newsletter, CMS, Reports, and System (jeśli nie wszystkie z nich widzisz, upewnij się, że jesteś zalogowany z uprawnieniami administratora). W dalszych częściach omówimy też dodawanie własnych elementów menu. Wszystkie z tych elementów, które widzisz, zawierają podmenu - wyjątkiem jest tylko Dashboard. Czas, aby przyjrzeć się niektórym z nich.

Dashboard to strona domyślna "Panelu Admina". Możesz na niej zobaczyć zestawienie najważniejszych informacji na temat wybranego sklepu - dane najnowszych zamównień, najnowsze zamówienia z wybranego zakresu czasu, kwotę zamówień z wybranego zakresu czasu, najlepiej sprzedające się produkty, produkty najczęściej oglądane, nowych klientów... Jest to zatem właśnie to, czego można się spodziewać po domyślnej stronie "Panelu Admina". Sales umożliwia ci zarządzanie zamówieniami (Orders), fakturami (Invoices), dostawami (Shipments) i podatkami nakładanymi na produkty (Tax). Właśnie tu możesz przyjrzeć się lub modyfikować zamówienia, składane przez twoich klientów. Możesz je przeglądać, odwoływać, wstrzymywać i drukować. Czego trudniej się domyślić, ta sekcja zawiera także możliwość ustalenia warunków sprzedaży (Terms and Conditions).

Kolejny element menu to System. Zawiera kilka opcji wartych zapamiętania. Tools pozwoli ci na wykonanie kopii zapasowej. Chyba nie trzeba nikogo przekonywać, że warto korzystać z tej opcji ;) Jest tu też Cache Management, czyli zarządzanie pamięcią podręczną. A na końcu - konfiguracja (Configuration). Zajrzyj do zakładki określającej wygląd twojego sklepu (Design). Tutaj wybierasz skórkę dla sklepu(skin), rozmieszczenie elementów (layout) i domyślny motyw graficzny (theme). Magento wybierze motyw domyślny wtedy, gdy nie znajdzie tego, który wybierzesz. Możesz też wybrać znak wodny dla obrazków używanych w sklepie. No i w końcu - ustawienie, którego używam najczęściej.

Zajrzyj do zakładki Developer, wewnątrz Configuration. Wybierz swój sklep jako zakres konfiguracyjny (Current Configuration Scope) w polu po lewej. Zauważysz, że sekcja Debug będzie teraz zawierać pola Wskazówki dla ścieżek szablonów (Template Path Hints), and Dodaj do wskazówek nazwę bloku (Add Block Names to Hints). Odznacz Użyj strony web(Use website) i ustaw oba na Yes. Teraz wróć do frontoffice i odśwież stronę (upewnij się, że znajdujesz się w tym sklepie, który wybrałeś w Configuration Scope e Panelu Admina). Otrzymasz nazwy szablonów (template'ów), użytych do wyświetlenia strony, razem z odpowiadającymi im nazwami bloków. Przerywane linie wyznaczają granice szablonów. Wierz mi - warto zapamiętać tę opcję ;)

Magento Dataflow - standardowe adaptery [część 2]

Artykuł " Magento DataFlow - elastyczna wymiana danych" przedstawił globalny koncept frameworka wymiany danych zaimplementowanego w Magento. Dziś chciałbym napisać więcej o standardowych adapterach zaimplementowanych w module DataFlow.

  1. Definicja adaptera

    Adaptery są odpowiedzialne za pobieranie danych z zewnętrznych źródeł albo ich zapisywania do tychże. W tym celu wszystkie adaptery implementują interfejs Mage_Dataflow_Model_Convert_Adapter_Interface, który zawiera dwie metody: load() i save(). Koncept wymiany danych przyjęty w module DataFlow wykorzystuje adaptery w 3 kontekstach:

    • by załadować dane ze źródła - używając metody load()
    • by zapisać dane do źródła - używając metody save()
    • by wykonać operacje na jednym przetwarzanym wierszu - gdy zdefiniowane jako para zmiennych adapter/metoda parsera

    W pierwszych dwóch kontekstach definicja xml adaptera wygląda następująco:

    <action method="load" type="dataflow/convert_adapter_io">
         ...
    </action>

    Tag action posiada dwa parametry: typ i metoda. Typ decyduje, która klasa adaptera będzie wykorzystana w danej akcji. Klasę definiujemy podając jej alias. Parametr metoda mówi, która metoda klasy adaptera zostanie wywołana przez akcję. Jak wspomniałem już wcześniej, domyślnie dostępne są dwie metody: load i save. Wewnątrz taga action definiujemy zmienne, które są parametrami wykorzystywanymi podczas wykonywania metody adaptera. Zmienne definiuje się tak jak w poniższym przykładzie:

     
    <action method="load" type="dataflow/convert_adapter_io">
       <var name="type">file</var>
       <var name="path">var/import</var>
       <var name="filename"><!--[CDATA[products.csv]]--></var>
       <var name="format"><!--[CDATA[csv]]--></var>
    </action>

  2. Standardowe adaptery modułu Magento DataFlow

    Moduł DataFlow Magento zawiera kilka standardowych klas adapterów, które można znaleźć w katalogu app/code/core/Dataflow/Model/Convert/Adapter. Nie wszystkie z nich mają jednak zaimplementowane metody load() i save().

    W przypadku powszechnej czynności odczytywania danych z lub zapisu danych do pliku lokalnego lub zdalnego możesz wykorzystać adapter dataflow/convert_adapter_io (Mage_Dataflow_Model_Convert_Adapter_Io).

    Przedstawione poniżej zmienne pozwalają Ci zdefiniować plik lokalny/zdalny jako źródło danych:

    • type - definiuje typ źródła. Poprawne wartości to: file, ftp
    • path - definiuje ścieżkę względną do pliku
    • filename - definiuje nazwę pliku źródła
    • host - dla źródła ftp definiuje domenę ftp
    • port - dla źródła ftp definiuje port ftp (domyślnie 21)
    • user - dla źródła ftp definiuje nazwę użytkownika (domyślnie jeżeli nie podana zostanie inna wartość przyjmuje 'anonymous' dla zmiennej user i 'anonymous@noserver.com' dla zmiennej password
    • password - dla źródła ftp definiuje hasło użytkownika
    • timeout - dla źródła ftp definiuje maksymalny czas oczekiwania na połączenie (domyślnie 90)
    • file_mode - dla źródła ftp definiuje tryb odczytu pliku (domyślnie FTP_BINARY)
    • ssl - dla źródła ftp definiuje czy korzystać z połączenia ssl
    • passive - dla źródła ftp definiuje tryb połączenia z serwerem ftp (domyślnie false)
  3. Adaptery encji klienta i produktu

    Dla najczęściej importowanych/eksportowanych encji - klienta i produktu - Magento dostarcza w standardzie adaptery: customer/convert_adapter_customer (Mage_Customer_Model_Convert_Adapter_Customer) i catalog/convert_adapter_product (Mage_Catalog_Model_Convert_Adapter_Product). Oba dziedziczą po Mage_Eav_Model_Convert_Adapter_Entity.

    By w najprostszy sposób załadować wszystkich klientów wybranego sklepu możesz użyć następującej definicji:

    <action type="customer/convert_adapter_customer" method="load">
        <var name="store">default</var>
    </action>

    Czasem możesz jednak chcieć załadować tylko wybranych użytkowników z bazy danych. By Ci w tym pomóc dostępny jest następujący zestaw zmiennych:

    • filter/firstname - by załadować tylko klientów, których imię zaczyna się od podanej wartości
    • filter/lastname - by załadować tylko klientów, których nazwisko zaczyna się od podanej wartości
    • filter/email - by załadować tylko klientów, których email zaczyna się od podanej wartości
    • filter/group - by załądować tylko klientów z wybranej grupy zdefiniowanej przez id
    • filter/adressType - by eksportować tylko wybrany typ adresu; poprawne wartości: both, default_billing, default_shipping
    • filter/telephone - by załadować tylko klientów, których numer telefonu zaczyna się od podanej wartości
    • filter/postcode - by załadować tylko klientów, których kod pocztowy zaczyna się od podanej wartości
    • filter/country - by załadować tylko klientów z kraju o podanym kodzie iso
    • filter/region - by załadować tylko klientów z wybranego regionu (dla USA wystarczy podać dwuliterowe kody stanów)
    • filter/created_at/from - by załadować tylko klientów stworzonych po podanej dacie
    • filter/created_at/to - by załadować tylko klientów stworzonych przed podaną datą

    Na przykład:

    <action type="customer/convert_adapter_customer" method="load">
        <var name="store"><![CDATA[0]]></var>
        <var name="filter/firstname"><![CDATA[a]]></var>
        <var name="filter/lastname"><![CDATA[a]]></var>
        <var name="filter/email"><![CDATA[a]]></var>
        <var name="filter/group"><![CDATA[1]]></var>
        <var name="filter/adressType"><![CDATA[default_billing]]></var>
        <var name="filter/telephone"><![CDATA[1]]></var>
        <var name="filter/postcode"><![CDATA[7]]></var>
        <var name="filter/country"><![CDATA[BS]]></var>
        <var name="filter/region"><![CDATA[WA]]></var>
        <var name="filter/created_at/from"><![CDATA[09/22/09]]></var>
        <var name="filter/created_at/to"><![CDATA[09/24/09]]></var>
    </action>

    W ten sam sposób możesz załadować i filtrować produkty z bazy danych, używając następujących zmiennych:

    • filter/name - by załadować tylko produkty, których nazwa zaczyna się podaną wartością
    • filter/sku - by załadować tylko produkty, których sku zaczyna się podaną wartością
    • filter/type - by załadować tylko produkty, których typ odpowiada zdefiniowanemu; poprawne wartości: simple, configurable, grouped, bundle, virtual, downloadable
    • filter/attribute_set - by załadować tylko produkty, których id zestawu atrybutów odpowiada podanej wartości
    • filter/price/from - by załadować tylko produkty, których cena jest nie mniejsza niż podana wartość
    • filter/price/to - by załadować tylko produkty, których cena jest nie większa niż podana wartość
    • filter/qty/from - by załadować tylko produkty, których ilość jest nie mniejsza niż podana wartość
    • filter/qty/to - by załadować tylko produkty, których cena jest nie większa niż podana wartość
    • filter/visibility - by załadować tylko produkty o zdefiniowanej w zmiennej widoczności
    • filter/status - by załadować tylko produkty o zdefiniowanym w zmiennej statusie

    Przykład:

    <action type="catalog/convert_adapter_product" method="load">
        <var name="store"><![CDATA[0]]></var>
        <var name="filter/name"><![CDATA[a]]></var>
        <var name="filter/sku"><![CDATA[1]]></var>
        <var name="filter/type"><![CDATA[simple]]></var>
        <var name="filter/attribute_set"><![CDATA[29]]></var>
        <var name="filter/price/from"><![CDATA[1]]></var>
        <var name="filter/price/to"><![CDATA[2]]></var>
        <var name="filter/qty/from"><![CDATA[1]]></var>
        <var name="filter/qty/to"><![CDATA[2]]></var>
        <var name="filter/visibility"><![CDATA[2]]></var>
        <var name="filter/status"><![CDATA[1]]></var>
    </action>

Wygląda to trochę przerażająco jeśli spojrzeć na konieczność używania wartości id, które musisz podać definiując filtry. Na szczęście dla tych dwóch encji - klientów i produktów - dostępny jest generator profili, który pozwala Ci zdefiniować filtr za pomocą prostego formularza.

W następnej części opiszę użycie parserów i adapterów w kontekście parserów.