Termék importálás Magento webshopba a Magmi rendszerrel

Tartalom

    • Mi is az a Magmi?
    • A Magmi és a Magento 2.0
    • A Magmi telepítése
    • A Magmi alapbeállítása
    • Magmi plugin-jainak a beállítása
  • Egyszerű termék importálása
  • Hogyan kell csoportos árat (Group Price) importálni?
  • Hogyan kell mennyiség kedvezmény árat (tier prices) beállítani?
  • Hogyan tudom a termékeket hozzárendelni a több website-os áruházban?
  • Hogyan kell importálni?
  • Konfigurálható termék importálása
  • Kötegelt termék importálása
  • Csoportos termék importálása
  • Letölthető termék importálása
  • Virtuális termék importálása
  • Jellemző és jellemzőhalmaz importálása
  • Termékkategóriák importálása
  • Többnyelvű importálás

Mi is az a Magmi?

A Magento egy erőteljes, a legtöbb e-kereskedelemmel kapcsolatos feladat ellátására alkalmas platform. Alapértelmezett kezelőfelülete azonban hagy némi kívánnivalót maga után. A Magmi, azaz a Magento Mass Importer feladata, hogy segítsen ezeknek a réseknek a kitöltésében, és könnyebbé tegye a Magento rendszeren üzemeltetett webáruházunk működtetését.

Gyakran merül fel az igény például arra, hogy egyszerre több száz, vagy akár több ezer termékből álló online katalógus hozzunk létre és kezeljünk, a lehető legegyszerűbb és leghatékonyabb módon. Ennek kivitelezése a Magento kezelőfelületén keresztül, manuális módon egyáltalán nem egyszerű feladat.

A Magmi egy olyan, nyílt forráskódú rendszer, melynek segítségével egy sor olyan import/export opcióhoz férhetünk hozzá, amelyek alapból nem találhatóak meg a Magento rendszerében, ám rendkívül megkönnyíthetik az ilyen, és ehhez hasonló munka elvégzését. Lényegében egy külső felhasználói felület, mely segítségével könnyedén importálhatunk termékeket (akár nagy számban is) egyszerű CSV-fájlokból a Magento alapú webáruházunkba.

Sajnos az adatbázist valamilyen módon mindenképpen nekünk kell kialakítanunk, ami azt jelenti, hogy az ehhez használt .csv kiterjesztésű fájlokat továbbra is nekünk kell létrehoznunk. Ezek a fájlok azonban az MS Excel vagy a LibreOffice Calc segítségével is könnyen szerkeszthetők, a Magmi segítségével pedig gyorsabbá és egyszerűbbé tehetjük az adatbázis feltöltésének feladatát. Legnagyobb erőssége, hogy olyan dolgokat is megtehetünk a segítségével, mint például a képek tömeges importálása, vagy éppen a kategóriák automatikus létrehozása termékeink importáláskor.

A Magmi használatának hátránya mindössze annyi, hogy a már megszokott magento kezelőfelület mellett egy újabb adminisztrációs interfész használatát meg kell tanulnunk, a tapasztalatok szerint azonban ez egyáltalán nem teljesíthetetlen feladat. Az applikáció bőséges dokumentációja ugyanis lépésről lépésre vezet minket végig minden fontos funkción, a fejlesztők pedig még saját Wikit is létrehoztak annak érdekében, hogy segítség a Magmi használata mellett döntő felhasználókat..

A Magmi és a Magento 2.0

Mint azt már nyilván sokan tudják, a Magento 1.x verzióinak hivatalos támogatása 2020 júniusában véget ér. Ez azt jelenti, hogy a keretrendszer 2.0-nál korábbi verziói ettől az időponttól kezdve sem szoftveres, sem pedig biztonsági támogatásban nem részesülnek hivatalosan, így használatuk veszélyessé válik.

A legtöbb e-kereskedő éppen ezért árhatóan a Magento 2.x verzióira vált majd, ezzel a váltással pedig óhatatlanul felmerül a kérdés: mi a helyzet a Magmi-val, ami a Magento 1.x verziói esetében olyan jó szolgálatot tett, ha a webruházba történő importálás és expotálás feladatáról volt szó?

Nos, van egy jó hírünk! A Magmi természetesen a Magento 2.0 verziójához is elérhető, habár bizonyos funkciói egyelőre kevésbé működnek hatékonyan, mint a rendszer korábbi változatai esetében. A Magento 1.x támogatásának megszűnésével azonban várható, hogy a fejlesztők belevetik magukat a Magmi új rendszerrel kompatibilis verziójának tökéletesítésébe, és hamarosan egy minden funkciójában tökéletes, az export és import feladatokat hibátlanul ellátó kiegészítőt köszönthetünk a legújabb Magmi-frissítés személyében.

A Magmi telepítése

A Magmi telepítése

A Magmi telepítése némi gyakorlatot igényel, azonban az interneten rengeteg segédanyagot találhatunk azzal kapcsolatban, hogyan is csináljuk helyesen, és természetesen most mi is azért vagyunk itt, hogy segítsünk.

A cikkben a Magmi 0.7.22 verziójának telepítését és alkalmazását fogjuk bemutatni.

  • Első lépésként töltsük le a Magmi-t a GitHub-ról. A Magento 2.0 verziójával kompatibilis változat az oldalon, ide kattintva érhető el.
  • Ha ez megtörtént, az FTP-kliens segítségével másoljuk fel a magento root könyvtárunkba.
  • Aki régebbi Magmi verziót használ (< 0.7.22) annak ajánlott a Magmi mappát átneveznie, és e mellet még htaccess-es megoldással levédeni a magmi/ root mappáját. Ha ezeket a beállításokat nem végezzük el, akkor bárki elérheti a Magmis felületünket.

 

Magmi plugin-jainak a beállítása

Magmi pluginjainak a beállítása

A Magmi kiegészítőinek beállításai a Configure Current Profile opció alatt, illetve a general és az itemprocessors résznél találhatók.

Mindegyik plugin-nál található egy Info gomb, melyre rákattintva rövid leírást kapunk az adott kiegészítőről. A Documentation gomb (mely nem biztos, hogy minden felhasználónál megjelenik) pedig a Magmi Wiki oldalára visz, ahol részletesebb leírást is találhatunk az adott pugin-ról.

Ha az egyik plugin-t aktiváljuk, megjelenik egy Configure gomb is, melynek megnyomása után be tudjuk állítani a kiegészítőhöz tartozó, fontos beállításokat.

Most minden plugin-ról leírunk pár fontos tudnivalót, a teljes, részletes ismertetőket a plugin-ok fentebb említett dokumentációjában találhatod meg.

Magmi beállítás általános

Remote Agent Plugin v0.0.1

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin lehetővé teszi a távoli rendszeren való működést, akkor használatos, ha a Magmi távoli rendszeren van telepítve
  • Beállításai:
    • HTTP Url for magento base dir: távoli rendszer magento mappa url-je

Attribute Cleanup v0.0.1

  • Fejlesztette: 5byfive GmbH
  • Leírás: ez a plugin eltávolítja azokat a jellemzőket, melyek az adott terméknél nem használunk
  • Beállításai: nincs

Attribute Set Importer v0.0.2

  • Fejlesztette: 5byfive GmbH
  • Leírás: ez a plugin lehetővé teszi a jellemzőhalmazok és jellemzők importálását.
  • Beállításai:
    • Enable attribute import (Engedélyezzük-e a jellemző importálását)
      • CSV import mode: fentebb részletezve (a további beállítások is ugyanazok, mint a CSV options-nál)
      • Set default values for non-existing columns in CSV (JSON): ide kell beírni azokat az értékeket, amelyek mindegyik jellemzőnél ugyanazok, JSON formátumban kell megadni, pl. {“is_user_defined”:1,”is_visible”:1,”default_value”:”Test”}
      • Prune attributes which are not in CSV from database: ha ez be van kapcsolva, akkor először lefutatja a jellemző-importot, majd az összes olyan jellemzőt törli, ami nincs a csv-ben. Ez akkor jó, ha mindig az összes jellemzőt importáljuk és szeretnénk, ha a felesleges jellemzőket a plugin törölné.
      • Don’t touch non-user attributes when pruning (ha a prune attributes be van kapcsolva): Ezt akkor kell használnunk, ha csak azokat a jellemzőket szeretnénk törölni, amik is_user_defined = 1, vagyis a nem rendszer attribútumok. (ezt az egyedi fejlesztések során létrejött jellemzőkre szoktuk állítani)
      • additionally, keep following attributes when pruning, even if not given in CSV (comma-separated): Ebbe a mezőbe azoknak a jellemzőknek a kódját kell beírni (vesszővel elválasztva), amelyeket nem szeretnénk törölni (ezt akkor érdemes használni, ha a csv-ben nem adjuk meg a jellemzőt, de mégse szeretnénk, hogy a rendszer törölje)
      • Delete attributes marked “magmi:delete” = 1: ha ez be van kapcsolva és a csv-ben a magmi:delete oszlop létezik, amelynél 1-es értékre van állítva, akkor azt a jellemzőt törölni fogja
      • Create attributes from CSV which are not in database: ha ez bevan kapcsolva, akkor a plugin létrehozza azokat a jellemzőket, amelyek még nincsenek az adatbázisban. Ha nincs bekapcsolva, akkor a csv-ben lévő jellemzők
      • Update attributes from CSV which are already in database: kapcsoljuk be, ha szeretnénk, hogy frissítse a csv-ben megadott jellemzőket (ami szerepel az adatbázisban)
    • Enable attribute set import: engedélyezzük a jellemzőhalmaz importálását, Az itt található többi beállítás ugyanaz, mint a jellemzőnél.
    • Enable attribute association import: Ezzel tudjuk összepárosítani, hogy melyik jellemző melyik jellemzőcsoportba tartozzon.
      • CSV import mode: fentebb részletezve (a további csv beállítás is ugyanaz, mint a CSV options-nál)
      • Add these attribute associations to given CSV data: ide lehet plusz jellemző párosítást beletenni, vesszővel kell elválasztani ilyen formában: (attribute_set_name,attribute_code,attribute_group_name)

Ehhez tartozó beállítás ugyanaz, mint az előbbiekben leírtaknál.

Import Report Mail Notifier v1.0.0

  • Fejlesztette: Dweeves
  • Leírás: ezzel tudunk jelentést küldeni az importról
  • Beállításai:
    • Email report to: Kinek küldje a jelentést. Vesszővel elválasztva több e-mail címet is megadhatunk.
    • Report sender: küldő e-mail címe
    • Report sender alias: küldő alias-a
    • Subject: tárgy
    • Body: tartalom
    • Attachments: csatolmányok:
      • Attach import log: csatolja-e a jelentés log-ot
      • Attach source CSV: a csv forrást csatolja-e
      • Zip attachments: összecsomagolja-e a csatolmányokat

Magmi Import Url UI v1.0.3

  • Fejlesztette: Dweeves
  • Leírás: ez nem befolyásolja az importot, csak kiírja nekünk, hogy milyen url-en lehet meghívni. Ezeket általában cronjob-okba szokták írni.
  • Beállításai: nincs

Magmi Optimizer v1.0.5

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin indexeket tesz pár olyan táblára, ahol észleli, hogy szükség van rá.
  • Beállításai: nincs

Magmi Magento Reindexer v1.0.3a

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin a Magento-s reindexet hívja meg shell-ből, vagyis reindexelést végez.
  •  Beállításai:
    • PHP CLI command: php cli parancs
    • Indexing : Ki kell választani, hogy melyik index típusokat szeretnék, ha újraindexelné.

On the fly category creator/importer v0.2.5

  • Fejlesztette: Dweeves
  • Leírás: ezzel lehet importáláskor a kategóriákat létrehozni.
  • Beállításai:
    • Assign product to: Melyik kategóriához rendelje a terméket.
      • all categories in tree: az összes kategóriához a kategória fában (pl. Fő kategória/Alkategória/ ebben az esetben mind a 2 kategóriába bele fog tartozni)
      • last category of each branch: itt csak az utolsó szinten lévő kategóriába teszi bele a terméket.
    • Tree level separator: Alkategória elválasztójel (pl. / ebben az estben Kategória 1/Kategória 2)
    • base category tree: főkategória, ezt akkor ajánlott használni, ha mindegyik kategóriánk ugyanabba a főkategóriába tartozik.
    • url ending: url utótag, általában ajánlott a .html végződés

Downloadable products importer v1.0.0.1

  • Fejlesztette: Tangkoko SARL
  • Leírás: ez a plugin importálja a letölthető termékeket
  • Beállításai: Bővebben a „Letölthető termék importálása” résznél foglalkozunk vele

Group Price Importer v0.0.4 info

  • Fejlesztette: Tim Bezhashvyly és Dweeves
  • Leírás: csoportos árakat lehet importálni vele
  • Beállításai:
    A csv-ben ezt az oszlopot kell megadni:
    “group_price:groupName” ahol a groupName a vevőcsoport neve.
    Bővebben kifejtem a „Egyszerű termék importálása” résznél.

Image attributes processor v1.0.33a

  • Fejlesztette: Dweeves és Tommy Goode
  • Leírás: ez a plugin importálja a termékekről készült képeket.
  • Beállításai:
    • Image search path: melyik mappákban keresse a képeket (ezeket előzőleg fel kell tölteni a szerverre, ajánlott a media/import mappa), pontosvesszővel kell elválasztani, ha több mappát szeretnénk megadni
    • Image Renaming: átnevezze-e a képeket; hagyjuk üresen, ha az eredeti fájlnevet szeretnénk megtartani.
      Itt lehet dinamikus változókat használni.
      Ha szeretnénk átnevezni a képet, a következő formátumot javaslom:
      {item.sku}_{meta.attr_code}_{meta.store}.{meta.imagename.ext}
    • Image import mode: importálás módja
      • Keep existing images: ebben az esetben nem írja felül, vagy nem fogja letölteni (távoli url-ről) azokat a képeket, amelyek ugyanazon a néven léteznek.
      • Overwrite Existing Images: felülírja és újra letölti (távoli url-ről) az ugyanazon a néven szereplő képeket.
    • Assing only existing images: (ezt a beállítást nem figyeli a rendszer ebben a verzióban)
      • Import into DB: adatbázisba importálja-e; ezt csak akkor állítsuk Enabled-re, ha be van állítva a Magento-nkba a Media storage.
      • Debug mode: hibakeresés be legyen-e kapcsolva
      • Remote Image root: tavoli képek útvonala (ha nincs, üresen kell hagyni)
      • Remote root Authentication: szükség van-e távoli bejelentkezésre
      • Pre-download check: (ezt a beállítást nem figyeli a rendszer ebben a verzióban)

On the fly indexer v0.2

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin importáláskor ír néhány index táblába (url_rewrites és a category_products)
  • Beállításai:
    • URL endings: url végződések, legyenek-e használva, és ha igen, akkor mik legyen azok.
    • Use Categories in Url: kategoriák legyenek-e az url-ben

Custom Options v0.0.7a

  • Fejlesztette: Pablo és Dweeves
  • Leírás: ezzel a plugin-nal lehet beimportálni a termékekhez az egyedi opciókat
  • Beállításai: a következőképp kell beállítani a csv-ben a custom optionokat:
    Name:Type:Is Required:sort number
    vagyis pl. Size:drop_down:1:1, és a terméksorba pedig pl: Small|Medium|Large
    A többi részletes variációt megtalálhatjuk a plugin dokumentációs oldalán.

Product Deleter v0.0.2

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal termékeket lehet törölni
  • Beállításai:
    • Delete Children products: törölje-e az alá tartozó termékeket. Ez a konfigurálható és kötegelt termékeknél lényeges.
      A csv-be új oszlopként fel kell venni a magmi:delete-et, és a törlendő termékeknél 1-re kell állítani.

Product Tags Importer v0.0.3

  • Fejlesztette: Dweeves, Pawel Kazakow
  • Leírás: termék címkéket lehet importálni vele
  • Beállításai:
    csv-ben vesszővel elválasztva kell beírni a címkéket a tags oszlopba

Tier price importer v0.0.9a

  • Fejlesztette: Dweeves, bepixeld
  • Leírás: ezzel lehet mennyiségre vonatkozó, kedvezményes árat importálni
  • Beállításai:
    Bővebben az „Egyszerű termék importálása résznél” foglalkozunk vele.

Weee Tax importer v0.0.5

  • Fejlesztette: Garbocom & Dweeves
  • Leírás: ezzel lehet a Weee-ket, vagyis környezetvédelmi adókat importál
  • Beállításai:
    • Weee Tax Attribute name: a környezetvédelmi adó jellemző kódja
    • Weee Tax Country code: az adó ország kódja (pl. FR)

Column mapper v0.0.3b

  • Fejlesztette: Dweeves
  • Leírás: ezt a plugin-t akkor érdemes használni, ha az import fájlban eltérőek az oszlopok nevei a Magento jellemzőkódoktól.
  • Beállításai:
    • Mapped columns list: ide kell felsorolni, vesszőkel elválasztva a Magento-ban szereplő jellemzőkódokat
    • New name for col X: ide írjuk be az import fájlban szereplő nevét az adott jellemzőnek (ha a Mapped columns listbe újat írunk be, akkor jelenik meg a New name for col …)

SKU Finder v0.0.3

  • Fejlesztette: Dweeves
  • Leírás: ezt a kiegészítőt akkor kell használnunk, ha nem adjuk meg az import fájlunkban az SKU vagyis cikkszám oszlopot, helyette egy másik termékjellemző alapján kell összepárosítani
  • Beállításai:
    • sku find attribute code: a párosítandó jellemző kódja.

Default Values setter v0.0.5

  • Fejlesztette: Dweeves
  • Leírás: ezzel lehet beállítani az olyan értékeket, amelyek mindegyik jellemzőnél ugyanazok, így nem kell az import fájlba beírni
  • Beállításai:
    • Default attribute list: vesszővel elválasztva be kell írni a jellemző kódjait, ahogy a Magento-ban szerepel, majd az alatta lévő oszlopokba pedig az értéket

Magmi Import Limiter v0.0.7

  • Fejlesztette: Dweeves
  • Leírás: ezt akkor kell használni, ha limitálást szeretnénk az importjainkra tenni, vagyis pl. csak bizonyos jellemzőket szeretnénk beimportálni, vagy csak bizonyos sortól sorig használni azokat.
  • Beállításai:
    • Column filter: melyik jellemzőket importáljuk, pl. sku,price,qty
    • Limiter ranges: pl. 1-100, vagyis hogy melyik sortól kezdve meddig importáljon
    • Limiter filters: csak azokat a termékeket importáljuk, amelyek bizonyos szűrési feltételnek megfelelnek,
      pl. sku::00.* – vagyis csak azokat a cikkszámokat importálja, amelyek 00-val kezdődnek
      pl. sku:00.*;;!name::.*blue.* – vagyis a 00-val kezdődő cikkszámokat és a név nem blue-val kezdődik.

Generic mapper v0.0.6a

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal a Magento-s értékekkel való értékpárosítást lehet elvégezni. Tipikus jellemző a page_layout és a visibility.
  • Beállításai:
    Ha szeretnénk használni, akkor az adott jellemzőre létre kell hoznunk a jellemző nevével egy csv fájlt a „magmi/plugins/itemprocessors/genericmapper/mappings” könyvtárba, pl. „magmi/plugins/itemprocessors/genericmapper/mappings/is_recurring.csv”
    Ennek a tartalmába be kell az érték párost írni. pl.
    „Yes”,1
    „No”,0
    Részletesebb leírást a plugin dokumentációjában olvashatunk.

Value Replacer v0.0.8a

  • Fejlesztette: Dweeves
  • Leírás: ezzel a plugin-nal jellemzők értékeit tudjuk lecserélni. Dinamikus változókat is használhatunk, vagyis pl. ha az összes termék cikkszámához szeretnénk perfixet tenni, akkor a következőképp kell beírni a mezőbe: prefix-{item.sku}
  • Beállításai:
    • Replaced attributes: fel kell sorolni a jellemzőkódokat, amelyeknél szeretnénk cserélni az értéket (vesszővel elválasztva)
    • New value for X: ide kell beírni az értéket
      További leírás a dokumentációban található.

Value Trimmer for select/multiselect v0.0.3

  • Fejlesztette: Dweeves
  • Leírás: ez a plugin automatikusan levágja az üres helyeket a többszöri vagy sima kiválasztós jellemzők értékénél
  • Beállításai: nincs

Grouped Item processor v1.4.1

  • Fejlesztette: Alpine Consulting, Inc & Dweeves
  • Leírás: ezzel lehet csoportos termékeket importálni
  • Beállításai:
    • Perform simples/group link: összekapcsolja-e az egyszerű termékeket a csoportos termékkel.
    • auto match simples skus before grouped: ezzel tudjuk beállítani, hogy automatikusan keresse-e meg a csoportos termékhez tartozó egyszerű termékeket, ha nem, akkor az import fájlban léteznie kell a „grouped_skus” oszlopnak, ahol pontosvesszővel elválasztva fel kell sorolni a hozzá tartozó egyszerű terméket.
    • Force simples visibility: az egyszerű altermékek láthatóságát állítsa-e, ha igen, akkor mire.

Bundle Item processor v1.1

  • Fejlesztette: Björn Tantau, Dweeves, igi8819
  • Leírás: Kötegelt termékeket importálhatunk vele
  • Beállításai:
    A „Kötegelt termékek importálása” résznél bővebben kitérünk rá, de mindegyik beállítás arra szolgál, hogy beállítsa az értékeket a megadott típushoz, abban az esetben, ha az import fájlban nem írjuk be azokat.

Configurable Item processor v1.3.7a

  • Fejlesztette: Dweeves
  • Leírás: Segítségével onfigurálható termékeket lehet importálhatunk.
  • Beállításai: ugyanazok, mint a csoportos terméknél, melyek fentebb olvashatók.

Cross/Upsell Importer v1.0.3

  • Fejlesztette: Dweeves
  • Leírás: Segítségével cross- és upsell termékeket importálhatunk.
  • Beállításai:
    Az import fájlban két új oszlopot kell beírni:
    us_skus – Upsell
    cs_skus – Cross sell
    Mindkettőnél cikkszámokat kell felsorolni, vesszővel elválasztva.

Product relater v1.0

  • Fejlesztette: Dweeves, jwtechniek
  • Leírás: Segítségével hasonló termékeket impotálhatunk.
  • Beállításai:
    Az import fájlban a re_skus oszlopba kell beírni a cikkszámokat.
    Részletesebb leírást a plugin dokumentációban olvasnhatunk.
    A plugin beállításait a lenti Save Profile gombbal kell elmenteni.

 

Egyszerű termék importálása

Egyszerű-termék-importálás

Első lépésként fontos, hogy konfiguráljuk a plugin-ok legfontosabb beállításait.
Ezután leírjuk, hogyan is kell egy import fájlt létrehozni. Mint ahogy az elején említettük, ezt egy CSV-fájlon keresztül fogjuk bemutatni.

Mielőtt azonban nekikezdenénk, bizonyosodjunk meg róla, hogy van olyan programunk, ami alkalmas a CSV-fájlok kezelésére. Amennyiben még nem rendelkezel ilyennel, azt javasoljuk, hogy szerezd be a következő két, ingyenes program valamelyikét:

  • Open Office (azon belül is a Calc)
  • Libre Office (azon belül is a Calc)

Fontos, hogy a CSV-t mindig UTF-8 beállítással és a megadott elválasztó paraméterekkel kell megnyitnunk/mentenünk.

Magmi CSV szöveg import

Miután megnyitottuk, a következő oszlopokat kell beírni fejlécként a CSV-be:

  • sku: termék cikkszáma, ezzel fogja a rendszer módosításkor beazonosítani a meglévő terméket
  • attribute_set: jellemzőhalmaz neve, ugyanúgy kell beírnunk, mint ahogy a Magento-ban szerepel, pl. Default
  • type: a termék típusa, lehetőségek:
    • simple – egyszerű
    • configurable – konfigurálható
    • downloadable – letölthető
    • bundle – kötegelt
    • grouped – csoportos
    • virtual – virtuális
  • websites: Ez a 0.7.17 verziótól elavulttá vált.
  • store: ide kell beírni, hogy melyik store view-hoz rendeljük hozzá (mindig a store view kódot kell megadnunk). Ezzel lehet a nyelvesítést elvégezni, amit bővebben a „Többnyelvű importálás” résznél fejtünk ki. Ha egy store view-nk van, vagyis egynyelvű az áruházunk, akkor nem kell, hogy szerepeljen az import fájlban. Illetve a képen látszik, hogy admin van beírva a store-nak, ilyenkor ez ugyanaz, mintha be se írtuk volna az oszlopot.
  • categories: ide kell beírni, hogy mely kategóriákhoz rendeljük a terméket (ha nincs bekapcsolva az „On the fly category creator/importer v0.2.5” plugin, akkor a beírt kategóriáknak léteznie kell a rendszerben, még mielőtt importálunk. A beírt adatok szintaxisa:
    • Kategória1
    • Főkategória/Alkategória
    • Kategória1;;Kategória2 – vagyis ha több kategóriába is beletartozik egy árucikk, akkor kettő darab pontosvesszővel kell elválasztani
    • Kategória1/Alkategória1;;Kategória1/Alkategória2;;Kategória2/AlKategória3
  • name: a termék neve
  • description: termék hosszú leírása, html tag-ek engedélyezve vannak
  • short_description: termék rövid leírása, html tag-ek engedélyezve vannak
  • price: a termék ára, itt mindig az alapértelmezett pénznemben kell beírni, adó nélkül (tehát nettó árat), pl. 150
  • special_price: a termék kedvezményes ára, ha nincs, akkor 0
  • special_from_date: ha a terméknek van kedvezményes ára, akkor ide be lehet írni, hogy mikortól legyen akciós (pl. 2016-05-20), ha mindig, akkor üresen kell hagynunk
  • special_to_date: meddig legyen akciós a termék, üresen hagyva a végtelenségig akciós lesz
  • news_from_date: újdonságnak jelölt termék kezdeti dátuma
  • news_to_date: újdonságnak jelölt termék befejezési dátuma
  • qty: ha van készletkezelés, akkor a termék raktáron lévő mennyisége (pl. 5)
  • in_in_stock: van-e raktáron, értékek: 1 – igen, 0 – nem
  • manage_stock: használja-e ennél a terméknél a raktárkezelést (ha használunk raktárkezelést, ki lehet egyes terméknél kapcsolni, hogy legyen-e vagy sem), értékek:1 – igen, 0 – nem
  • use_config_manage_stock: használja-e a rendszerbeállításban megadott raktárkezelést. Ha állítani akarjuk az előbbi manage_stock értéket, akkor itt 0-át kell megadni, hogy ne a rendszerbeállításból olvassa ki az értéket, hanem az ennél a terméknél megadott manage_stock értékből.
  • status: engedélyezve van-e a termék, értékek: 1 – igen, 0 – nem
  • visibility: a termék láthatósága, értékek:

1 – egyedileg nem látható, ezt általában a konfigurálható, csoportos termékeknél szokták használni. Ebben az esetben a termékadatlap sem érhető el, a többinél a termékadatlap elérhető
2 – csak a katalógusban, vagyis a kategória oldalakon látható, a keresésnél nem
3 – Csak a keresésnél látható
4 – Mindenhol látható

  • weight: a termék súlya, pl. 0.5. Ha ezt nem szeretnénk használni, akkor a jellemzőnél át kell tenni, hogy ne legyen kötelező megadni.
  • tax_class_id: az adóosztály id-je vagy a neve, pl. Taxable goods
  • thumbnail: a termék bélyegképe, pl. ball-for-football.png
  • small_image: a termék kis képe
  • image: a termék főképe
  • media_gallery: termékgaléria, itt a képek nevét pontosvesszővel kell elválasztani, pl. ball-for-football.png;ball-for-football2.png

Magmi CSV minta

 

A képeket csak akkor fogja importálni a rendszer, ha a „Image attributes processor v1.0.33a” plugin be van kapcsolva.

Természetesen a többi jellemzőt bele kell írni az import fájlunkba.

A select, vagyis egyszeri kiválasztós jellemzőknél a szöveges értéket kell beírnunk. (pl. a color jellemzőnek a Red szót írhatjuk.)

A többszöri kiválasztós értékeknél ugyanúgy kell tennünk, mint a select-nél, csak ha több értéke van, akkor a Magmi beállításában megadott Multiselect Separator-nál megadott karakterrel kell elválasztanunk (pl. Red|Green|Blue)

Magmi csoportos ár

Hogyan kell csoportos árat (Group Price) importálni?

A csoportos ár importálásához a CSV-fájlba fel kell vennünk egy “group_price:groupName” oszlopot, ahol a gropName a csoport neve, ahogy a Magento-ban szerepel.

Ha több csoporthoz szeretnénk árat importálni, még ha egyformát is, akkor külön oszlopba be kell azt beírnunk.

Ha nem létezik az adott vásárlócsoport, akkor a Magmi létre fogja azt hozni.

Hogyan kell mennyiség kedvezmény árat (tier prices) beállítani?

Az import fájlban egy új oszlopként be kell írnunk a következőt:
tier_price:group1 – ahol a group1 a vásárló csoport nevét jelöli.

Ha szeretnénk, hogy az összes csoportra érvényes legyen, akkor tier_price:_all_
Ha több csoportnak szeretnénk beállítani, akkor ugyanúgy, mint a csoportos árnál, új oszlopban kell felsorolnunk.

A terméksorba pedig:
25:10.00;50:9.00;100:8.00 – ami annyit jelent ebben az esetben, hogy 25 mennyiségnél vagy felette 10-be, 50 felett 9-be, 100 felett pedig 8-ba kerül.

Százalékos kedvezményt is meg lehet adni, ilyenkor pl. 25:85%, vagyis 25 mennyiségnél vagy felette 85 százalékos kedvezményt adunk.

Magmi CSV kedvezmény ár

Hogyan tudom a termékeket hozzárendelni a több website-os áruházban?

Ha olyan áruházat üzemeltetünk, mely egyszerre több weboldallal is rendelkezik, és vannak olyan termékeink, amelyek csak egyes oldalakon érhetők el, akkor a CSV-ben a store oszlopba azokn üzletek a store_view kódjait kell felsorolnunk, amelyekben a termék elérhető. Bemutatom egy példával:

8-Magmi-egyszeru-weboldal-aruhaz

A következő képen látható, hogy van 2 weboldalunk. Mindkettőnél 1 store van, az US store-nál csak angol nyelv, az EU store-nál pedig három nyelv is szerepel.
American English store_view kódja legyen:us, eu store-nál az Engilsh legyen: en, a German: de, a Hungarian pedig: hu.

  • Ha pl. a test 1-es termékünk, csak az us websopban van, akkor a store oszlopba az us kódot írjuk be.
    • Ha pl. az test 2-es termékünk csak az eu storokban szerepel, akkor fel kell sorolni mind a 3 nyelvet, vagyis en,de,hu
    • Ha a termék mindegyiknél szerepel, akkor az admin szót kell beírni.

Magmi egyszerű weboldal áruház csv

A többnyelvűség beállításával a „Többnyelvű importálás” részben bővebben foglalkozunk.
Itt található példa egy egyszerű termék importjára: magmi_simple_example.csv

Hogyan kell importálni?

A Magmi oldalán láthatunk egy Run Magmi feliratot, ott kell kiválasztanunk, hogy melyik profil alapján, milyen módban szeretnénk elvégezni az importálást.

Importálás után szükséges a reindexálás kell (reindex plugin a Magmiban is elérhető), illetve törölni ekll a cache-t a Magento-ban.

  • Update existing items only, skip new ones: csak a már Magento-ban létező termékeket frissíti, az újakat figyelmen kívül hagyja.
  • create new items & update existing ones: újakat is és a meglévőket is frissíti
  • create new items only, skip existing ones: csak az újakat hozza létre

Ezután a run import gombot kell megnyomnunk az importálási folyamat elvégzéséhez.

Konfigurálható termék importálása

A konfigurálható termék importálás funkció eléréséhez be kell kapcsolnunk a „Configurable Item processor” plugin-t. A konfigurálható terméknél most csak az egyszerű termékhez képesti különbségeket foglaljuk össze, mivel a többi beállítás gyakorlatilag megegyezik.

Magmi CSV konfigurálható termék

A konfigurálható termék több egyszerű termékből áll össze. Az import fájlban mindig az egyszerű termékeket kell előre tenni, és utána jön a konfigurálható termék.

Konfigurálható termék importálásakor először is meg kell adnunk, hogy mely jellemzők lesznek választhatóak a vásárlók számára (pl. méret, szín).
Csak „Globális” hatókörű, „Lenyíló” típusú jellemzőt lehet használni konfigurálásra és be is kell, hogy állítsuk a jellemzőnél, hogy konfigurálásra használható.

Fontos továbbá, hogy az a jellemző az adott jellemzőhalmaz része legyen.
Ha nem írjuk bele a fájlba a párosítandó cikkszámokat, akkor a plugin-ban be kell kapcsolnunk, hogy automatikusan megkeresse az altermékeket („auto match simples skus before configurable”), ilyenkor a cikkszámot a következőképp kell elnevezni:

Magmi CSV konfigurálható auto match

A konfigurálható cikkszáma (pl. testconf) Az altermékek cikkszáma: testconf1*** – a csillag helyére bármi mást be lehet írni, javasolt a konfigurálható jellemző értéke, (pl. testconf1-white-s, testconf1-white-m).

Ha pedig egyedi cikkszámot szeretnénk a termékeknél, akkor a simple_skus oszlopba kell beírni, hogy mely cikkszámok tartoznak alá.
Ha eltér az altermékek ára (pl. az M-es méretű drágább, mint az L-es) akkor a fájlba be kell írnunk a „super_attribute_pricing” oszlopot, amibe a konfigurálhatónál a következőképp kell  megadni:
jellemzőkód::érték:ár;érték:ár, jellemzőkód::érték:ár;érték:ár

vagyis pl. size::L:43;M:55

Ha fix ár helyett százalékos növelést szeretnénk, akkor pedig:
jellemzőkód::érték:ár:százalékos-e;érték:ár:százalékos-e
size::L:15:1;M:20:1 – vagyis, ha 1-es, akkor százalék, ha 0 akkor fix ár.

Ha nem adjuk meg ezt az értéket, a rendszer alapból fix árat fog használni.

Magmi CSV konfigurálható példa

Itt található egy konfigurálható termék import példa: magmi_configurable_example.csv

Kötegelt termék importálása

Ebben a részben azt mutatjuk be, hogy mit kell beállítani az import fájlban annak érdekében, hogy kötegelt termékeket tudjunk importálhassunk.

A Magmi plugin-jai között először is kapcsoljuk be a „Bundle Item processor” plugin-t.
Itt ugyanúgy kell létrehozni és kitölteni a CSV-fájlt, mint az egyszerű terméknél, ezért csupán a két módszer közötti különbséget mutatjuk be.

A következő oszlopokat kell beletennünk:

bundle_options:

Magmi CSV kötegelt opciók

-*;Code,Option name;type:is_required;position

pl.

-*;CPU:Central Processing Unit:radio:1:0;RAM:Random Access Memory:select:1:1;MOUSE:Mouse:checkbox:0:2

Ahol:

  • -* ha ezt az elejére írjuk, akkor a rendszer törli az előzőleg beírt opciókat a Magento-ból. Ha ezt nem írjuk, akkor a meglévőkhöz hozzáteszi a beírtakat.
  • Code: ez lesz a kódja az opciónak, ezt használjuk a bundle_skus-nál az összepárosításra
  • Option name: ez a neve az opciónak, ez a szöveg fog látszódni a terméknél
  • type (radio, checkbox, select, multi): ez az opció típusa
  • is_required: kötelező-e a vásárlónak választani az adott opcióból (1-igen, 0-nem)
  • position: a termék adatlapon milyen sorrendbe jelennek meg (számokat kell írni)
  • bundle_skus:

Magmi CSV kötegelt SKUS

Code:sku:selection_qty:can_change_qty:position:is_default:selection_price_value:selection_price_type
pl.
CPU:cpu1:1:0:1:1:0:0;CPU:cpu2:1:0:0:1:0:0;RAM:ram1;RAM:ram2;MOUSE:mouse1:1:0:0:1:50:1

Ahol:

  • Code: a bundle_options-nál is megadott kód
  • sku: az altermék cikkszáma
  • selection_qty: a kosárba helyezés mennyisége
  • can_change_qty: kiválaszthatja-e a vásárló, hogy az adott opcióból mennyit vásárol
  • position: opciók pozíciója
  • is_default: alapértelmezett-e az adott opció
  • selection_price_value: a kiválasztás ára (ez csak akkor érvényesül, ha a csv-ben a bundle-nél vagy a plugin beállításánál a price_type 1-re (Percent) van állítva
  • selection_price_type: az ár típusa (0 – Fixed, 1 – Percent)
  • price_view: az ár megjelenési típusa, 1 (Legkisebb ár, amelyen megveheti), 0 (ár tartomány, tehát x összegtől y összegig)
  • price_type: ár számítási típusa, 0 – dinamikus, 1 – fix ár
  • options_container: Hol jelenítse meg az opciókat (container1, container2), ez témától függ
  • shipment_type: a kötegelt elemek szállítása, 1 – elkülönítve, 0 – egyben
  • sku_type: cikkszám típusa, 0 – dinamikus, 1 – fix
  • weight_type: súly típusa, 0 – dinamikus, 1 – fix

Magmi CSV kötegelt egyéb

Importálás után csináljunk egy reindexet és cache-frissítést. Ha mindent jó állítottunk be, akkor a képen látható módon kell a termék adatlapnak megjelennie.

16-Magmi-kotegelt-Frontend

Itt található egy kötegelt termék import példa: magmi_bundle_example.csv

Csoportos termék importálása

A csoportos termék beállításai nagyon hasonlóak a konfigurálható termékéhez.
Először is, a Magmi plugin-jai között be kell kapcsolnunk a „Grouped Item processor” plugin-t. Eztuán az import fájlba a grouped_skus oszlopot kell beillesztenünk, amiben az egyszerű altermékek cikkszámai szerepelnek.

17-Magmi-csoportos-pelda

Itt található egy példa a csoportos termék importjára: magmi_grouped_example.csv

Letölthető termék importálása

A letölthető termék importfájlja hasonló az egyszerű termékéhez. A „links” oszlop kell bele, amit a következőképp kell kitölteni:

file:link,sort_order :position,title:file title,sample :example link,is_shareable :config or 0 or 1,number_of_downloads :value

  • file: ide kell a letölthető fájl linkje, url vagy teljes útvonal, ha lokálisan szerepel
  • sort_order: pozíció (ha több links van)
  • title: fájl neve
  • sample: betekintő fájl
  • is_shareable: a vásárló megoszthatja-e mással a fájlt
  • number_of_donwloads: hányszor töltheti le a fájlt

Ha több fájlunk van, akkor csak a fenti sort kell duplázni, pontosvesszővel elválasztva (pl. file:https://aionhill.com/test.zip,sort_order:1,title:Test,sample:,is_shareable:1,number_of_downloads:100;file:https://aionhill.com/test2.zip,sort_order:2,title:Test2,sample:,is_shareable:0,number_of_downloads:1; )

Magmi letölthető példa

Itt található egy letölthető egy példa a letölthető termék importjára: magmi_downloadable_example.csv

Virtuális termék importálása

Virtuális termék importálása ugyanaz, mint az egyszerű terméké, annyi a különbség, hogy a type nem simple, hanem virtual.

Magmi Virtuális példa

Itt található egy példa a virtuális termékimportra: magmi_virtual_example.csv

Jellemző és jellemzőhalmaz importálása

Jellemző vagy jellemzőhalmaz importjához először is be kell kapcsolnunk és beállítanunk az „Attribute Set Importer” plugin-t.
Itt három CSV import fájlt kell létrehozni: egyet a jellemzőkre, egyet a jellemzőhalmazokra és egyet a párosításokra.
A jellemzőnél kötelezően meg kell adnunk az attribute_code-ot, vagyis a jellemző kódját (pl. color).
A többi oszlop megadása nem kötelező, csak akko, ha nem az alapértelmezett értéket szeretnénk használni.

Jellemző, magmi

A jellemzőcsoport esetében meg kell adnunk az attribute_set_name-et, vagyis a jellemzőcsoport nevét (pl. Ruházat).
A többi oszlop megadása nem kötelező, csak akkor szükséges, ha nem az alapértelmezett értéket szeretnénk használni.

Jellemzőhalmaz, Magmi

A jellemző és jellemzőcsoport párosításánál pedig a következőket kell megadnunk:

  • attribute_set_name: jellemzőhalmaz neve
  • attribute_code: jellemző kódja
  • attribute_group_name: melyik jellemzőcsoportba kerüljön a halmazon belül

Jellemzőhalmaz, Magmi, jellemző, párosítás

Termékkategóriák importálása

A termékkategóriák a termék importáláskor jönnek létre, ha a Magmi-ban be van kapcsolva az „On the fly category creator/importer” plugin.
Leggyakrabban a képen látható beállítás alapján használják a plugin-t.

Magmi kategória importer beállítás

Ez alapján a következőképp kell a CSV-ben a kategóriát beállítanunk.

Magmi kategória Importer CSV

A képen látható példában a termék a „Football” főkategóriában szereplő „Ball” és „Accessories” kategóriákba fog bekerülni.

A per (/) jellel lehet az alszinteket megadni, pl. Elsőszintű/Másodszintű/Harmadszintű.
A kettő darab pontosvesszővel tudjuk több kategóriába is besorolni, pl. Elsőszintű/Másodszintű/Harmadszintű;;MásikElsőszintű/MásikMásodszintű/MásikHarmadszintű
Új kategóriáknál megadhatjuk azt, hogy aktív-e, link-e, és hogy a navigációs menüben benne legyen-e, szintakszisa: category name::[is_active]::[is_anchor]::[include_in_menu]
pl. Football/Ball::1::0::0

Többnyelvű importálás

Többnyelvű (ami több store view-t jelent, ahol webáruházunk más-más nyelven jelenik meg) importálásnál minden terméket annyiszor kell a beírnunk az import fájlba, ahány nyelven azt szeretnénk megjeleníteni.

magmi többnyelvű importálás

Ahány nyelv, annyi sor, a store oszlopba kell beírni annak a store_view-nak a kódját amelyik nyelvű boltnézetbe szeretnénk beletenni.

A kategóriáknál sajnos a rendes fordítás nem megoldott, így vagy adminból fordítunk, vagy minden nyelvnek saját kategóriafát hozunk létre, pl.:

  • English Root
    • Ball
  • German Root
    • Ball
  • Hungarian Root
    • Labda

A name, description stb. oszlopba az adott nyelven kell beírni a szövegeket.

A lenyílós jellemzőknél a következőképp:
Adott nyelvű érték::[Admin érték]
Az első elem az adott nyelven megírt fordítása, a kapcsos zárójelbe kell az admin vagyis a default nyelven létező string-et írnunk. (pl. Red::[Red], Piros::[Red] )

Itt található egy példa többnyelvű importra: magmi_multilanguage_example.csv

Összegzés

A Magmi előnyei:

  • Telepítése és beállítása egyszerű
  • Használata felgyorsítja a munkát (egyszerre akár több ezer terméket is pár perc alatt importálhatunk a segítségével)
  • mind a 6 terméktípus importálására képes
  • automatizálható (vagyis automatikusan futó importokat is létrehozhatunk)

A Magmi hátrányai:

  • az importfájlok létrehozása kicsit bonyolult, maximális pontosságot igényel annak érdekében, hogy minden adat megfelelően jelenjen meg
  • mivel nyílt forráskódú, így sajnos akadnak benne apróbb hibák, egyes kiegészítők nem működnek mindig tökéletesen
  • a termék mentésekor futó observerek enm futnak le, mivel direkt SQL-el dolgozik
  • a Magento mellett még egy adminisztrációs felület használatát meg kell tanulnunk

Reméljük, sikerült minden részletre kiterjedően bemutatnunk a Magmi tulajdonságait, beállításait és használatát. Ha bármilyen témába vágó megjegyzésed vagy kérdésed lenne, ne habozz megírni alább, a komment részlegben. Ahol tudunk, segíteni fogunk abban, hogy a Magento és a Magmi segítségével te is kihozhasd saját webáruházadból a maximumot!

 

Magento AWS hoszting – a teljes útmutató [+INFOGRAFIKA]

Ezekről a témákról lesz szó:

 

Cloud Computing és az AWS Kinek ajánljuk a felhőt? Feltételek Telepítés Mi a menedzselt hosztolás? Tárgyalás a szolgáltatóval Biztonságos az AWS? AWS EC2 Instance-ok Magento telepítési útmutató

 

Cloud Computing és az AWS

 

felhő alapú számítástechnika (angolul: cloud computing) a számítástechnika egy ágazata. Többféle felhő alapú szolgáltatást különböztethetünk meg, a közös bennük az, hogy a szolgáltatásokat nem egy dedikált hardvereszközön üzemeltetik, hanem a szolgáltató eszközein elosztva, ezért

  • a szolgáltatás üzemeltetési részleteit a felhasználónak nem kell ismernie,
  • nincsen szükség az infrastruktúra kezeléséhez szükséges kompetenciára,
  • a technológia használata, az erőforrások elérése a lényeg.

 

Ezekhez a szolgáltatásokhoz a felhasználók hálózaton keresztül csatlakoznak.

Az elérés szempontjából megkülönböztetünk publikus és privát felhőt.

A felhőnket az interneten keresztül, és helyi hálózaton is elérhetjük, de a különbség elsősorban abban áll, hogy a hálózat kinek a birtokában van. Gyakorlatilag privát felhőnek nevezhetjük azt az infrastruktúrát, amelynek minden eleme saját kezelésben van és csak 1 ponton (tűzfal) csatlakozik a nyilvános hálózathoz.

Az érthetőség kedvéért, nagyon leegyszerűsítve: a felhő alapú szolgáltatás az, ha a szolgáltatást a saját környezetünkben vesszük igénybe, lokálisan, de a szolgáltatás nyújtásáért felelős infrastruktúra nem cégen belül működik, illetve nem helyben vannak üzemeltetve a szerverek.

Sőt, azok nem is a mi tulajdonunkban vannak, sok esetben nem is tudjuk, hogy pontosan mi és hol helyezkedik el, viszont pontosan definiálva van, hogy mit nyújtanak, milyen rendelkezésre állással, biztonsággal és természetesen mennyiért.

 

A „cloud” számítástechnika a 2000-es évek közepe óta az IT világ egyik fő irányának számít.

Hogy honnan, és mikortól eredeztethető a szemlélet, és a megvalósításra tett kísérletek, arról egy jó áttekintést olvashatunk az IBM oldalán. Mindenestre J. C. R. Licklider fejéből már a hatvanas években kipattant az ötlet, egy mindent behálózó computer-hálózatról, melynek erőforrásait annak használói „távolról” érik el (J. C. R. Licklider informatikus és pszchiológus volt, az ARPANET fejlesztéséért felelős személy.)

Az Amazon 2006 óta aktív a felhőszolgáltatások terén.

 

A szolgáltatások három fő csoportra oszthatók:

 

 

Számtalan kisebb-nagyobb vállalat nyújt felhő-alapú szolgáltatásokat ügyfelei számára, azonban a piacot döntően uraló 4 cégóriás infrastruktúrája mellett a többiek szinte eltörpülnek. E négy gigász

  • az Amazon, aki az AWS-t (Amazon Web Services) nyújtja,
  • a Microsoft az Azure szolgáltatáscsomagjaival,
  • az IBM (IBM Cloud),
  • valamint a Google aki egyszerűen a Google Cloud-dal szállt versenybe az ügyfelek kegyeiért.

 

Magento alapú webshopunk igényeinek tökéletes kiszolgálása érdekében – amennyiben annak megbízható és zavartalan működését tartjuk szem előtt – kötelességünk azt a legmegfelelőbb hardware-es környezetben futtatnunk.

Mi az AionHill-nél hosztolt Magento-s oldalakat az AWS szolgáltatásait igénybe véve futtatjuk. Ezek között vannak oldalak, amelyek hibrid környezetben, egy részük AWS-ben és egy részük a saját vagy az ügyfelünk privát felhőjében fut.

Rengetegen használják már ezt a technológiát, köztük a legnagyobb cégek, és tartalomszolgáltatók, mint például a

  • Netflix,
  • Dropbox,
  • HTC,
  • Hitachi,
  • de nem elhanyagolható a NASA,
  • a Soundcloud,
  • a Spotify vagy
  • a SAMSUNG jelenléte sem.

Az sem egy szem elől tévesztendő tény, hogy az AWS-nek – akárcsak másik három, nagy vetélytársának – robusztus, a világon szinte mindenhová kiterjedő infrastruktúrája van. Természetesen redundáns adatközpontokról beszélünk, így gyakorlatilag sosem tapasztalható kiesés a szolgáltatásaikban.

Az AWS felhő 42, úgynevezett Availability Zones (Elérhetőségi Zónából) épül fel, 16 földrajzi régióban, szerte a világon. Csak Európában 7 adatközpont található Frankfurtban, Londonban és Írországban. A fejlesztések, bővítések folyamatosak: egy új kínai, és egy párizsi központ is átadásra került az év elején.

 

graphic-info-on-hosting-providers

 

Kinek ajánljuk a felhőt?

 

Tapasztalataink szerint leginkább két szegmensben terjed ez a megoldás.

A kevésbé tőkeerős kis- és közepes vállalkozásoknál és a nagyvállalati szegmensben. Itt olyan erősen hatnak a felhőből jövő IT-szolgáltatások melletti érvek, hogy könnyű a döntés.

Sokan vallják, hogy ez a számítástechnika jövője, ellenzői éppúgy akadnak, elsősorban biztonságtechnikai kérdések felvetése miatt.

 

Felhő-alapú megoldások pro és kontra:

Nem minden vállalat számára előnyös:

A felhő-alapú számítástechnika bármilyen kis- és nagyvállalat számára előnyös lehet, de ehhez megfelelő szolgáltatási típust kell kiválasztani és meg kell határozni, hogy az informatikai környezet melyik részét telepítik a felhőbe. Előnyös elsősorban azokat az alkalmazásokat telepíteni át, amelyek egyébként is külső alkalmazásokhoz és szolgáltatásokhoz kapcsolódnak.

 

Nem biztonságos (?):

Egyes feltételeknek, mint az amerikai PCI biztonsági szabvány, amely a bankkártya adatok kezelését köti meg, nehéz megfelelő környezetet találni a felhő szolgáltatók között, ezeket nem minden szolgáltató biztosítja. Az Amazonnál azonban elérhetőek olyan VPC-k, amelyek nyújtják a PCI-DSS szabványt. Persze ennek ára van.

 

A felhőben tárolt adatok feletti ellenőrzés elveszítése:

Megoldás lehet erre, ha a szolgáltatásra egy megfelelő referenciákkal rendelkező céget keresünk, amely biztosítja, hogy az adatok biztonságban lesznek és a vállalat által előírt igényeknek megfelelnek, akár egy pénzügyi vagy jogi profilt képviselő vállalat esetében is. A mindennapi gyakorlatban azonban ezt a problémát könnyen áthidalhatjuk, ha egyszerűen napi biztonsági mentéseket készítünk lokálisan, a szerverek állományairól.

 

Ár:

Felhő-alapú szolgáltatások esetében nincs mindig szükség dedikált hardver vásárlására, ami jelentősebb megtakarítás a legtöbb esetben. Gyorsan változtatható az allokált erőforrások mérete is, ami további előny.

A legnagyobb előny viszont, hogy nem kell magas, kezdeti beruházással számolnunk, sem TCO szerint évekkel előre kalkulálni, hiszen az eszközök nem a mi birtokunkban vannak. Ezek a költségek leggyakrabban havi kiadásként jelentkeznek a számlánkon ‒ persze ha el tudjuk magunkat kötelezni hosszabb távon, azzal komoly, a bérleti díjat csökkentő kedvezményeket tudunk elérni.

További előnye a rendszernek a kiváló skálázhatóság, felfelé és lefelé is, tehát viszonylag kis költségvetés mellett ki lehet próbálni egy új szolgáltatást, és amennyiben az hasznosnak bizonyul, könnyen lehet alakítani a hatékony működés érdekében, és gyorsan meg is lehet válni egy felesleges erőforrástól.

 

Egyre kevesebb olyan cég van, amelynek nem ajánljuk a felhőt.

Pár évvel ezelőtt a nagymennyiségű adatokat kezelő, komoly sávszélességet felhasználó cégek nehezen vagy sehogyan nem tudták ezt a szolgáltatástípust használni. Mára ez is megoldott. Jelenleg már DVD-nyi adatok mozgatása is pár perc. Terrabyte-nyi adatok esetén az AWS SnowBall szolgáltatást érdemes használnunk, dedikált, garantált nagysávszélességű kapcsolathoz pedig az AWS DirectConnect szolgáltat megoldást.

 

Mi a feltétele annak, hogy a Magento webáruház az AWS felhőbe kerüljön?

Az Amazon Web Services lehetőségei rendkívül flexibilisek, testre szabhatók, és rugalmasan skálázhatók, terheléstől függően.

Az AWS költség kalkulátorának köszönhetően nincsenek rejtett fizetési tételek.

Minden előre tervezhető, gyakorlatilag egy HDD esetében, pontosan megmondható a winchester fejének olvasási/írási anyagi feltétele. Ez így talán elsőre furán hangzik, de ennek köszönhetően valójában csak azokért a szolgáltatásokért kell fizetnünk, amelyeket valóban igénybe is veszünk.

 

A Magento telepítése az AWS felhőbe

 

Amennyiben nincs egy-két év üzemeletetési, és sysadmin/devops tapasztalatunk, úgy a teljes folyamatot érdemes szakemberekre bízni. Különösen, ha a költséghatékony működtetés mellett az üzletfolytonosság is kiemelt szempont.

 

A lényeg: Az AWS lehetővé teszi számunkra, hogy a Magento-t támogató flexibilis, jól skálázható infrastruktúrát hozzunk létre.

 

Az árazás természetesen az üzembe helyezni kívánt erőforrás számítási kapacitásától, és az igénybe vett tárhely méretétől is függ.

Az alábbi táblázat néhány felhőbeli erőforrás fontosabb paramétereit és árait tartalmazza. Az egyes virtuális gépeket az AWS „Instance”-ként nevezi meg. Az alábbi táblázatban bemutatunk pár fontosabb AWS szervert és főbb paramétereit:

 

Instance típusa

t2.medium

vCPU

2

Memória (GiB)

4

 Tárolás (GB

Kizárólag EBS

Hálózati telj.

Alacsony – közepes

Fizikai proc.    

Intel Xeon család

Órajel (GHz)

3.3-ig

t2.large 2 8 Kizárólag EBS Alacsony – közepes Intel Xeon család 3.0-ig
t2.xlarge 4 16 Kizárólag EBS Közepes Intel Xeon család 3.0-ig
t2.2xlarge 8 32 Kizárólag EBS Közepes Intel Xeon család 3.0-ig
m4.large 2 8 Kizárólag EBS Közepes Intel Xeon E5-2676 v3 2.4
m4.xlarge 4 16 Kizárólag EBS Magas Intel Xeon E5-2676 v3 2.4
m4.2xlarge 8 32 Kizárólag EBS Magas Intel Xeon E5-2676 v3 2.4
m4.4xlarge 16 64 Kizárólag EBS Magas Intel Xeon E5-2676 v3 2.4
m4.10xlarge 40 160 Kizárólag EBS 10 Gigabit Intel Xeon E5-2676 v3 2.4
m4.16xlarge 64 256 Kizárólag EBS 20 Gigabit Intel Xeon E5-2686 v4 2.3
m3.medium 1 3.75 1 x 4 SSD Közepes Intel Xeon E5-2670 v2 2.5
m3.large 2 7.5 1 x 32 SSD Közepes Intel Xeon E5-2670 v2 2.5
m3.xlarge 4 15 2 x 40 SSD Magas Intel Xeon E5-2670 v2 2.5
m3.2xlarge 8 30 2 x 80 SSD Magas Intel Xeon E5-2670 v2 2.5
c4.large 2 3.75 Kizárólag EBS Közepes Intel Xeon E5-2666 v3 2.9
c4.xlarge 4 7.5 Kizárólag EBS Magas Intel Xeon E5-2666 v3 2.9
c4.2xlarge 8 15 Kizárólag EBS Magas Intel Xeon E5-2666 v3 2.9
c4.4xlarge 16 30 Kizárólag EBS Magas Intel Xeon E5-2666 v3 2.9

 

tips Tipp : A „t” jelzésűek általában a tesztelésre használatosak, az „m” típusúakat (memória intenzív) érdemes a nagyobb adatbázisok, vagy single server telepítésekhez használni, és a nagyobb kapacitású, „c” instance-okat (CPU intenzív) érdemesebb Magento áruházak mögé rakni.

Az EC2 szerverek specifikációit, valamint a teljes listát meg tudjuk tekinteni az AWS oldalán.

 

AWS Szolgáltatások

 

Az alábbiakban felsoroljuk egy Magento próbaáruház hosztolásához szükséges főbb Amazon szolgáltatásokat, és rövid leírásukat.

  • Amazon EC2– Az Amazon Elastic Compute Cloud (Amazon Felhő Infrastruktúra) lehetővé teszi virtuális gépek indítását, a rájuk telepített operációs rendszerek széles skálájából választva. Dönthetünk már meglévő AMI (Amazon Machine Image), azaz Amazon Virtuális Gép image-e, képfájlja, vagy épp egy máshonnan importált képfájl között.
  • Amazon VPC– Az „Amazon Virtual Private Cloud” (Amazon Virtuális Magánhálózat) segítségével egy jól izolált, magán hálózatot definiálhatunk a felhőben, ahol szolgáltatásokat és egyéb erőforrásokat kapcsolhatunk be. Teljesen szabad kezet kapunk a virtuális hálózatunk beállítását illetően, beleértve saját IP tartományunk, alhálózat létrehozását, és a routing táblák, hálózati átjárók konfigurálását.
  • AWS CloudFormation– AWS CloudFormation egy könnyű módja annak, hogy létrehozzunk és felügyeljünk kapcsolódó AWS szolgáltatásokat, és előre tervezetten frissíthessük őket. Egy sablont használunk az összes erőforrás leírásához (pl.: Amazon EC2 instance-szok). Ily módon ezeket az erőforrásokat nem kell konfigurálnunk, vagy magunknak rájönni a kapcsolódásuk összefüggéseire, ezt mind megoldja helyettünk a CloudFormation. Lényege, hogy hasonló infrastruktúrákat gyorsan létre lehessen hozni.
  • Amazon RDS– Amazon Relational Database Service (Amazon Relációs Adatbázis)-t könnyű létrehozni, kezelni, és skálázni. Ezzel a szolgáltatással percek alatt telepíthető MySQL adatbázis, újratervezhető hardveres kapacitással.
  • Auto Scaling– Az Automata Skálázás segít helyreállítani, fenntartani a szerver elérhetőségét, azáltal hogy automatikusan növeli, vagy csökkenti a számítási kapacitást Amazon EC2 instance-szok hozzáadásával, vagy lekapcsolásával.
  • Elastic Load Balancing– A terhelés elosztás automatikusan kezeli és szétosztja a bejövő hálózati forgalmat, amennyiben a flottánkban egyszerre több Amazon EC2 Instance-ot is futtatunk.
  • Amazon S3– Amazon Simple Storage Service (Amazon Egyszerű Adattárolási Szolgáltatás) a biztonságos és hatékony módja a fájlok, adatok felhő-tárolásának. Leginkább multimédiás tartalmak tárhelyéül szolgál, az EC2 web szerverek innen érik el az áruházunkban megjelenő termékek képeit.
  • IAM– AWS Identity and Access Management (Felhasználó Hozzáférés és Kezelés) lehetővé teszi az AWS felhőben felhasználók létrehozását, és felügyeli azok jogosultságait, hozzáféréseit a különböző szolgáltatásokhoz és erőforrásokhoz. Az IAM-mel egyéb biztonsági intézkedéseket is tehetünk, például létrehozhatunk hozzáférési kulcsokat, engedélyeket, házirendeket, hasonlóan az ismertebb operációs rendszereken tapasztaltakhoz.
  • CloudFront – vagy rövidítve CDN a statikus tartalmakat kezelő szolgáltatás. Azt segíti elő, hogy a felhasználóknak ezek a tartalmak (például képek) mindig a legközelebbi szerverről, a lehető leggyorsabban legyenek elérhetőek, ezzel javítva az oldalak betöltési idejét.

 

Természetesen van lehetőségünk ingyenesen kipróbálni az AWS felhőjét. Erre két lehetőségünk is nyílik.

 

AWS Free Tier

Ha kalandkedvelőek vagyunk, vagy rendelkezünk a korábbiakban említett üzemeltetési tapasztalattal, akkor az Amazon-on tett személyes regisztrációval 1 év ingyenes hozzáférést kapunk az AWS bizonyos szolgáltatásaihoz.

Ne lepődjünk meg, ha a regisztráláshoz bankkártyánk adataira is szükség lesz, erre a telefonos visszaigazolás, valamint az alábbiakban említett körülmények miatt van szükség.

Körültekintően kell mazsoláznunk a lehetőségek között, mert könnyen bekapcsolhatunk, vagy konfigurálhatunk olyan erőforrásokat, melyek használata a számlánkat terheli majd a periódus végén.

Szerencsére a Dashboard-on nyomon követhetjük fogyasztásunkat, de mindig tájékozódjunk mielőtt valamilyen szolgáltatás működtetésébe kezdenénk. Ezt segítendő, az AWS külön megcímkézi azokat az erőforrásokat, melyeknek a kipróbálása nem kerül pénzbe.

Ami mellett a „Free Tier Eligible” jelzést lájuk, attól nem kell tartanunk.

  • Tárolhatunk fájlokat a felhőben,
  • létrehozhatunk felhasználókat, jogosultsági szintekkel,
  • üzleti analitikai szolgáltatást is igénybe vehetünk,
  • mikroszervert is élesíthetünk, megválasztott operációs rendszerrel, amelyen indíthatók szolgáltatások,
  • és a termináljában parancsokat is futtathatunk.

 

Illúzióink persze ne legyenek, ez az ingyenes szerver nem fogja kiszolgálni Magento webshopunk technikai igényeit!

De ha kedvet kaptunk hozzá, hogy közelebbről is megismerjük az AWS-t, akkor ezen a linken elindulhatunk a felfedezőúton.

Hosting Provider Demók

 

Sok szolgáltató igyekszik magához csábítani az ügyfeleket egy hetes, vagy maximum egy hónapos, ingyenes megoldásokkal, vagy előre konfigurált környezettekkel.

Bár roppant kényelmesen hangzik webáruházunk 5 perces kiköltöztetése a felhőbe, a legritkább esetekben fognak az ügyfél igényei, elképzelései igazodni, közelíteni a díjszabás nélküli hosztoláshoz. Az előre megtervezett környezetek értelemszerűen nincsenek felkészítve, hozzászabva szükségleteinkhez.

Ennek okán nagyon nehezen, vagy egyáltalán nem lehet személyre szabni, optimalizálni ezeket a „demo-shop”-okat. Az ügyfél előbb vagy utóbb rákényszerül, hogy megfizesse a szolgáltatást, hogy naprakész, gyors, stabil és megbízható webáruházzal várja a látogatóit.

 

Mi is az a menedzselt hosztolás?

 

Mielőtt webshopunkat el kívánjuk helyezni a felhőben, mindenképpen érdemes tájékozódni a piacon, kik és milyen megoldásokat kínálnak e téren.

Ha boltunk még fejlesztés előtt áll, érdemes olyan szolgáltatókból választani, akik fejlesztéssel és hosztolással is egyaránt foglalkoznak. Ennek főleg a jövőre nézve van előnye: elkerülhető későbbi félreértés, és egymásra mutogatás a fejlesztő és a hoszting cég között.

 

Miből lehet nézeteltérés, aminek esetleg az a vége, hogy a tulajdonos a fejlesztő és a hoszting cég között ül tanácstalanul, jelentős forgalomveszteséget elszenvedve? Számtalan probléma merülhet fel, de itt egy igen…

 

tips egyszerű és gyakori példa: Ha a webshop oldalán érezhető lassulás tapasztalható, akkor erre értelemszerűen a tulajdonos magyarázatot szeretne kapni. Első útja a fejlesztő céghez fogja vinni, aki a hosztingot nyújtó céget jelöli meg hibásként, mivel valószínűleg nem megfelelő környezetbe helyezték az oldalt.

A hoszting szolgáltató válasza erre valószínűleg az lesz, hogy a kód nem optimalizált, vagy annyira hibás, hogy gyorsításért felelő cache-eléses megoldások nem implementálhatók.

És ez a kör akár a végtelenségig tud folytatódni…

Ügyfélként érdemes lehet egy olyan megoldáson elgondolkodni, ahol mindkét forrás a szolgáltatást nyújtó cégnél összpontosul.

Vagyis ha a hosztoló és a fejlesztő ugyanaz, nagyobb eséllyel van birtokában annak a kompetenciának, ami a megbízható futtatáshoz kell, amely az áruház teljesítményét és az adatok biztonságos kezelését is szem előtt tartja.

 

A manage-elt hosztolás tulajdonképpen a normál hosztolásnak (legyen az dedikált vagy megosztott környezetben) olyan kibővítése, ahol a szolgáltató nemcsak az alap infrastruktúrát adja bérbe, hanem a futtatandó üzleti alkalmazáshoz (pl: Magento) igazítja a környezetet.

Minden olyan szükséges mikroszervizt, amely segíti az alkalmazást ‒ hogy gyorsabban, stabilabban, biztonságosabban fusson ‒ telepíti és karban is tartja azokat.

 

Magento esetében ilyenek például

  • a MySQL,
  • Redis,
  • Varnish,
  • CDN
  • és Search szerverek.

 

Lehetnek ezenkívül más szükséges mikroszervizek is, hiszen minden eCommerce alkalmazás nagyon eltérő tud lenni.

A manage-elt hoszting keretében ez a rendszergazdai vagy sysop tevékenység benne van a szolgáltatásban. Az árazás a különböző cégeknél ezért is nagyon eltérő, mivel ezek nagyon komoly kompetenciát érintő szolgáltatások és mindenki más és más szolgáltatásokból építi fel a portfólióját.

 

Tehát összefoglalva: manage-elt hoszting szolgáltatás keretében a hardveres infrastruktúrát csupán béreljük és a telepítéshez, futtatáshoz szükséges kompetenciát megvesszük.

 

Ezután nekünk csak az alkalmazást kell kezelni, de kizárólag üzleti szempontból. Ezért nagyon fontos, hogy a felelősségi körök, jogosultságok mindkét oldalon tisztázottak legyenek.

Sokan sokféleképpen definiálják a manage-elt hosting feladatköreit, az igénybe vett szolgáltatás szintje, annak minősége alapján. Ez a lista felfelé és lefelé is módosulhat, ami a megállapodás függvénye.

 

Nézzük meg, hogy melyek a legfontosabb tényezők:

  • Szerver Monitorozás– A szerver vagy szerverek aktív felügyelete, mellyel preventíven felismerhetők és orvosolhatók a kisebb hibák, mielőtt nagyobb problémává duzzadnának, a szolgáltatás kiesését elkerülendő.
  • Biztonság– Ide tartozik a vírusvédelem, a spam szűrés, tűzfal konfigurálás, és az operációs rendszer konfigurációja, frissítése is. A biztonság minden gépen és hálózaton kiemelt fontosságúnak tekintendő, különösen olyan esetekben, ahol személyes vagy üzleti adatok sérülhetnek. Ide soroljuk az áruház üzembiztonsági (Operation Security), hozzáférés és adatbiztonsági (Security and Safety) feladatait, a szolgáltatást, az adatok elérését, mentését az SLA-ban leírtaknak megfelelően. Az áruház biztonsági tanúsítványai is kiemelt fontosságúak, hiszen eddig csak a payment gateway-ek és a bankok figyelték ezeket, de most már a Google is rangsorol ez alapján!
  • Teljes biztonsági mentés (back-up) és tárolás– Egy cég számára az adatvesztés többszörösen is veszteség: időt, pénzt és az ügyfél elégedettségét emészti fel. Ennek okán a szolgáltatónak fel kell készülnie, hogy rendszeres mentéssekkel, azok tárolásával, archiválásával növelje a stabilitást.
  • Támogatás (Support)– A szolgáltatók egyik vonzó előnye, hogy rendelkezésre állási idővel támogatják az üzletfolytonosság fenntartását. Ha bármi probléma adódik, azt az ügyfél azonnal jelenteni tudja a szolgáltató felé, és a holtidő minimalizálásával megkezdődhet az elhárítás. Sokféle konstrukcióban kínálják ezt a szolgáltatás típust: telefonos, email-es összeköttetésben, akár az év minden napjára, 24 órában kiterjesztve.

 

A jól megtervezett és működtetett manage-elt hoszting szolgáltatásnak nemcsak követelményei, de üzleti előnyei is vannak.

Összegezzük ezeket:

Csökkentett üzemeltetési költségek – A hardverek és a működtetésükhöz szükséges erőforrások nagyon sok cég számára megterhelők lehetnek, ezek folyamatos cseréje az amortizáció és a mögé helyezett tudásbázis napra készen tartása végett.

Az invesztálások kiadási oldala és az ezekből realizált haszon között nincs egyenlőség, nem tudnak ebből hathatós előnyre szert tenni. A szolgáltatóknak ezzel szemben megvannak az erőforrásaik, melyek így az ügyfél szempontjából költséghatékonnyá teszik az infrastruktúra igénybevételét. Az alacsonyabb beruházási költség mellett a skálázhatóság is fontos szerepet játszik az ésszerű, hatékony forráskezelésben.

Példa: kiemelten terhelt időszakok (peak-ek) esetén, ha nagyobb számítási kapacitásra van szükség (pl. karácsonykor), akkor erre nagyobb erőforrásokat különíthetünk el. Ezt kompenzálandó az év fennmaradó időszakában olcsóbb üzemeltetéssel működtethetjük tovább az áruházat.

Hatékonyabb erőforráskezelés – Ha az ügyfél cége IT munkatársakat alkalmaz, akkor pontosan tudja, hogy a jó szakembereket meg kell fizetni, ezért kiemelten fontos ezen erőforrások ésszerűsítése. Ha a hosztinghoz szükséges kompetenciákat egy külsős szolgáltatónál találja meg, akkor az ügyfél „belsős” informatikusai több időt és energiát fordíthatnak saját cégük mindennapi feladataira és munkatársaik támogatására.

 

Hogyan és miért fizetünk az AWS-nek?

 

Az AWS az úgynevezett „pay-as-you-go” (csak-azért-fizetsz-amit-használsz) rendszerben kínál több mint 70 felhő-alapú szolgáltatást.

Valóban csak az kerül kiszámlázásra, amit igénybe is veszünk, csakis a használat időszakát véve alapul, nincsenek kötelezően hosszú távú szerződések (de a kedvezményekért érdemes elgondolkodni rajta), vagy beüzemelési díjak. Hasonlóan a közüzemi fogyasztásinkhoz, mindent mér az Amazon, és erről pontos kimutatást is kapunk az elszámolás időszakában – általában havonta – és ha valamilyen komponensre már nincs szükségünk, egyszerűen felhagyunk a használatával.

Az egyik legnagyobb előny, hogy nem kell tetemes beruházási, vagy upfront költséggel számolnunk.

A hardveres összetevőkről (szerverek, aktív hálózati eszközök), adatközpontunk tárolásához szükséges terem-, vagy ingatlanköltségek, a szoftverek licenszei benne vannak a szolgáltatás árában. Tervezhető és jóval alacsonyabb üzemeltetési díjakkal kalkulálhatunk.

A „pay-as-you-go” modell lehetővé teszi, hogy rugalmasan igazodjon IT infrastruktúránk a hirtelen vagy gyakorta változó üzleti körülményeinkhez. Ahogy korábban említettük, az erőforrások gyorsan aktivizálhatók, vagy kapcsolhatók ki, így megspórolhatjuk a túlköltekezésből, vagy épp az alulbecslésből származó anyagi kiadásokat.

 

tips Hasznos:  Ezzel elérhetjük, hogy a forrásainkat előre tervezetten, nagyobb hatásfokkal tudjuk a vállalkozásunk fejlesztésére fordítani, és dinamikusan reagálhatunk a piaci változásokra.

 

Az AWS nyitott rá, hogy ügyfelei számára mennyiségi kedvezményt nyújtson, ahogy növekszik a fogyasztás. Az olyan szolgáltatások esetében, mint az S3, vagy az adat export az EC2 szerverekből szintezettVagyis minél nagyobb az adatforgalmunk, annál kevesebbe kerül gigabájtonként a szolgáltatás.Mindemellett az adatimport ingyenes. Ennek következtében, mivel az AWS használati igények növekednek, életbe lép a méretgazdaságosság elve, amely lehetővé teszi a költségek ellenőrzés alatt tartását és a költségoptimalizált használatot.Ahogy vállalkozásunk fejlődik, az AWS is lehetőséget ad, hogy könnyebben szerezzük meg azokat a szolgáltatásokat, amelyek az új üzleti igényeket segítenek kezelni. Például az AWS adattárolási portfóliója lehetőséget kínál az áraik csökkentésére az alapján, hogy milyen gyakran és milyen gyorsan kívánunk hozzáférni adatainkhoz.Hogy optimalizáljuk a megtakarításokat, ki kell választanunk a megfelelő tárolási megoldások azon kombinációját, amelyek segítik a költségek csökkentését, miközben megőrizzük a teljesítményt és a biztonságot.
Bizonyos szolgáltatásoknál, mint az Amazon EC2 és az Amazon RDS, hasznosíthatjuk a fenntartott kapacitást. A fenntartott instance-ok esetén akár 75% kapacitást is megspórolhatunk.Ezeket 3 opcióban kaphatjuk a fizetési módozatok alapján: teljes induló költséggel – All up-front (Auri), részleges indulási költségekkel – Partial up-front (Puri) vagy előre nem fizetést – No up-front (Nuri) választva.

A fenti példát folytatva, minél nagyobb lesz a kezdőrészlet, annál nagyobb a későbbi, megkapható kedvezmény.Ahhoz, hogy maximalizáljuk a megtakarítást, érdemes kifizetni minden kezdeti költséget és a legnagyobb kedvezményre leszünk jogosultak.Részleges induló fizetéssel alacsonyabb kedvezményt biztosítanak, de jóval kisebb a szolgáltatás induló költsége.Végül, ha nem kívánunk up-front költségeket fizetni, a legkisebb kedvezményt szerezzük csak meg, de lehetővé tesszük, hogy a felszabadított tőkét a projektünk más részein tudjuk hasznosítani. A lekötött kapacitás segítségével minimalizálhatjuk a kockázatokat, kiszámíthatóbbá tesszük a költségvetésünket.

Milyen költségekkel jár a Managed Magento Hosting?

Milyen információkból tudja meghatározni a managed Magento hosting szolgáltató a költségeket?Egyrészt adottak és nyíltak az infrastruktúra használatáért fizetendő összegek. Ez bárki által megtekinthető az AWS kalkulátorában. Mégis, ha egy szolgáltatótól árajánlatot kérünk, ettől jóval eltérő számokkal fogunk találkozni, ami nyilván nem szorul különösebb magyarázatra.A hosting provider-nek, vagyis a szolgáltatónak ugyanezek a kiadásai, ezeket az erőforrásokat veszi igénybe az Amazon-tól. A szolgáltató hozzáadott értéke a csapatában lévő szakértelem:

  • az AWS finomhangolása,
  • testre szabása webshopunk részére,
  • a migrálás,
  • a szerverek konfigurációja, frissítése,
  • az adatbázis back up-ok kezelése
  • és minden olyan IT kompetencia, amivel az ügyfélnek nem kell foglakoznia,

így teljességgel webáruházának működtetésére fordíthatja a figyelmét.

Az ügyfélnek ezt a szolgáltatást és tudást kell a különbözetben megfizetnie.A legtöbb szolgáltató nyílt árakkal is hirdeti magát, de sok esetben a „pricing” fülre kattintva pusztán egy levelezési linket kapunk, és egyéni árszabásban gondolkodnak. Ahol láthatók az alapárak, mint sok más helyen, itt is előszeretettel alkalmazzák a különféle árkategóriákat, ezáltal „csomagosítva” a szolgáltatási portfóliót.Összehasonlítva ezeket, azt láthatjuk, hogy nincsenek kiugróan nagy különbségek, általában 4-5 csomagajánlattal találkozunk havi költségeket illetően, mindezek egy egész széles skálán: $35 ‒ $5000 között mozognak.

 

tips Fontos: az AWS mindig USD-ben adja meg a díjakat, ezért legyünk körültekintőek, amikor egy szolgáltató ajánlatával foglalkozunk, különösen, ha más devizában számolunk el!

 

Ez igaz miránk, az AionHill-re is, ezért az egy szerveres környezetet $150 ‒ $760, a többszerveres megoldásokat egy $500 ‒ $1600 közötti sávban kínáljuk ügyfeleinknek.

Nincs két egyforma elképzelés, ahogy két egyforma webshop sem.Ezért teret kell engedni, hogy a hoszting szolgáltató IT-s munkatársai a lehető legoptimálisabb környezetet állítsák össze az ügyfél számára. Ehhez azonban nem csupán az ötletek szükségesek, hanem a szakembereknek ismerniük kell jó pár technikai paramétert is, a lehető legpontosabb kalkuláció érdekében.

 

Mire készüljek, ha a felhő szolgáltatóval tárgyalok?

 

A technikai paraméterek felmérése vagy előzetesen, email-ben vagy személyesen, az AWS specialisták bevonásával történik meg. Ügyfélként tisztában kell lenni azzal, hogy miért szeretnénk a felhőbe költöztetni a shop-unkat, mik ezeknek az előnyei, átlagosan mekkora költséggel és / vagy szolgáltatás kieséssel jár a migráció.

Értelemszerűen minél egyedibb, több összetevőből áll a rendszerünk, annál komplexebb megoldásra kell számítanunk. Minél inkább egyedi megoldásokat szeretnénk gyakorlatba fektetni – és ez nem csupán a cloud szolgáltatásokra vonatkozik – annál inkább forrásigényes a folyamat.

Azonban ha átszámoljuk a felmerülő költségeket a saját szerverpark beszerzésére, beüzemelésére, annak fenntartására vonatkozóan, és ezt szembehelyezzük a manage-elt hoszting áraival, akkor látni fogjuk, már középtávon meg tud térülni a befektetés.

A legfontosabb technikai adatok kinyerhetők a Google Analytics-ből. Ezen már el tud indulni a szolgáltató. Viszont adódhatnak olyan kérdések, melyekre a cégünk rendszergazdái vagy a korábbi fejlesztők tudnak csak releváns válaszokkal szolgálni. Érdemes egy vázlati rajzot készíttetni a szervertopológia publikus részéről, és annak specifikációiról (Visio).

 

Nézzük meg, hogy milyen kérdésekkel találkozhatunk:

  • Mekkora a látogatók száma az oldalon naponta?
  • Mekora az indított munkamenetek száma egy hónapban?
  • Peak-ek esetén mi volt a legnagyobb munkamenetérték a periódusban?
  • Mekkora ezeknek a csúcsoknak az előfordulási aránya egy adott üzleti évben?
  • Milyen verziójú Magento Shop-ot szeretnének készíttetni, illetve melyik verziót szeretnék migrálni?
  • Jelen webshopban mekkora az SKU (Stock Keeping Unit)?
  • Az aktuális szerver vagy szerverek milyen specifikációval rendelkeznek?
  • Milyen külső rendszerekkel kommunikál a webáruház, és vannak-e tervek ennek bővítéséről (adatbázis típus-méret, számlázó szoftverek, ERP, CRM, stb.) ?

 

Milyen szolgáltatásokat, technológiákat várjunk el a felhő szolgáltatótól?

 

Ahhoz, hogy Magento áruházunk a megfelelő minőségben szolgálhassa ki vevőinket egy sor követelménynek kell megfelelnie. Kezdve az üzemeltető szakmai felkészültségétől, a használt és napra készen tartott technológiákon keresztül, az ügyfél támogatásáig bezárólag.

 

  • A bérbe adott infrastruktúrán felül milyen szolgáltatásokat nyújt az ügyfélnek, és ebből a webshop tulajdonos hogyan tud profitálni?
  • Hogyan garantálja az adatai biztonságát?
  • A kommunikáció, hibabejelentés milyen csatornákon és hatékonysággal történik?

 

Kicsivel fentebb összegeztük, hogy mik az alapvető feladatkörök, de ha hosztingcég számára fontos az ügyfél megelégedettsége, akkor ennél több is kell.

 

Mire figyeljünk oda ügyfélként a felhő kapujában?

 

Migráció

Amennyiben már meglévő, kész áruházunkat szeretnénk a felhőben látni, a szolgáltató szakemberei fogják a teljes folyamatot lebonyolítani, de ehhez valószínűleg együtt kell működniük a webshop tulajdonosával vagy az áruház informatikai szakembereivel.

Ügyfélként, kapcsolattartóként ezt ajánlott megkönnyíteni, és minden lépést kétoldalúan dokumentálni a nyomon követhetőség érdekében.

 

Figyeljünk oda a következőkre:

  • A szolgáltató tájékoztat-e a migrálás körülményeiről?
  • Külön árazás alá esik a folyamat, vagy beépíti a szolgáltatás árába?
  • Milyen időbeni vállalást tesz ennek kivitelezésére, és mennyiben érinti ez az üzletfolytonosságot, mekkora kiesést jelent a webshop számára?

 

Legyünk következetesek és körültekintők, ne csak az üzleti partnerünkkel, de magunkkal szemben is! Inkább tegyünk fel egy kérdést többször a tárgyalási folyamatok során, mint hogy valamilyen technológiai akadályra kritikus időben derüljön fény.

 

Kódaudit

Amikor a szolgáltatót megbízzák egy webáruház felhőbeli migrációjával, jogosan várják el annak zökkenőmentes, gyors üzemeltetését is. A megfelelő működés, és hatékonyság azonban nem pusztán a szerveres környezet, hanem a környezet és a fejlesztés együttes függvénye.

A hosztingot végző cégek – ahogy a fejlesztők is – használnak olyan cache-elési eljárásokat, technológiákat, melyek használata gyorsítja az oldalbetöltést, optimalizálja a statikus tartalmak elérését, vagy az áruház látogatói szokásaiból, analitikai módszerekkel teszi láthatóvá az értékes adatokat, amelyek hozzásegítenek az úgynevezett „Data Driven Decision” (Adatalapú döntések) meghozatalához.

 

tips Figyelem!:  Ezeknek a technológiáknak a használatához hozzá kell férni a webshop kódjához, hogy egy megfelelő vizsgálattal kiderüljön kód minősége, illetve, hogy ezek technológiák alkalmazhatók-e! Amelyik szolgáltató nem veti fel ennek lehetőségét egy migrálandó oldal esetében, kezdhetünk gyanakodni!

 

SSD és EBS

Ma már egyre nagyobb azoknak a szolgáltatóknak a száma, akik a gyorsabb írási/olvasási érték elérése végett adatinkat „Solid State Drive”-on tárolják.

Ezek a meghajtók a lakossági felhasználók körében is elterjedtek már az elmúlt években. Egy cloud hosting esetében pedig már szinte elvárható ez a technológia. Az Amazon felhőjében egyaránt találunk SSD és úgynevezett EBS (Elastic Block Storage) tárolási megoldásokat.

Fő különbségük flexibilitásukban van: az EBS-t bármikor hozzá tudjuk kapcsolni, vagy leválasztani egy instance-ról, vagyis szerver független, míg az SSD fizikai értelemben is szerverhez kötött.

 

Apache és NGINX

Az Apache és NGINX a két leggyakrabban használt nyílt forráskódú webszerver a világon. Együttesen, az interneten lebonyolított forgalom 50%-át teszik ki. Mindkét megoldás lehetőséget ad különböző munkaterhelésekre és másik szoftverekkel való dolgozásra, egyfajta web stacket alkotva.

 

Apache

Rugalmasságának, erejének és széles körű támogatottságának köszönhetően gyakran választják ezt a megoldást. Egy dinamikusan terhelhető modulrendszerrel lehet kiterjeszteni, amely képes megannyi nyelv feldolgozására is anélkül, hogy ehhez egy különálló szoftvert kellene igénybe vennie.

 

NGINX

2002-ben Igor Sziszojev kezdett el dolgozni az NGINX-en, problémát keresve a C10K-s problémára (10.000 egyidejű kapcsolat kezelése), ami akkoriban kihívást jelentett a webszerverek számára, márpedig ez alapfeltétele volt a modern világhálónak. A kicsi erőforrás kihasználása és minimális hardveren való hibátlan működése miatt az NGINX népszerűsége kiadása óta is folyamatosan nő. Az NGINX kiválóan kezeli a statikus tartalmakat, és úgy hozták létre, hogy a dinamikus igényeket egy másik szoftverhez irányítja, amely annak kezelésére jóval alkalmasabb.

 

Varnish Cache

Ez a gyorsítótárazási eljárás széles körben elterjedt, mivel rendkívül hatékonyan növeli a weboldal teljesítményét azzal, hogy csökkenteni képes a szerveroldali töltési időt. Ez a tulajdonsága nemcsak a felhasználói élmény növelését segíti elő, de üzemeltetési szempontból is közkedveltté teszi. A töltésoptimalizálás mellett másik erős oldala az ESI (Edge Slide Includes), mely az oldalt komponensekre bontja, és ezeknek az elemeknek külön-külön, egymástól függetlenítve oldja meg a gyorsítását.

 

Biztonságban az AWS felhőjében?

 

Egy cég életében, legyen az középvállalkozás, vagy induló webshop, sokszor nem is kapacitásbeli problémák gátolják meg a felhőbe költözést, hanem a szemlélet, a szokások. A fejlődő országokban gyakorta uralkodik a görcsös ragaszkodás a saját tulajdonú gépparkhoz, a karnyújtásnyira lévő szerverekhez, mintha pusztán fizikai közelségük szavatolná a cégadatok biztonságát.

Az AWS számos megoldást nyújt a kritikus adatok, a munkahelyi hálózatok, és a gyors, de megbízható hozzáférés biztonságának érdekében:

  • A hálózati tűzfalakat beépítették az Amazon VPC-be, és az AWF WAF (Web Application Firewall) lehetővé teszi magánhálózat létrehozását a felhőben, valamint a hozzáférés korlátozható a szerverekhez és az alkalmazásokhoz
  • A TLS titkosítás kiterjed minden szolgáltatásra
  • Privát vagy dedikált kapcsolódási lehetőségek, munkahelyről, vagy kívánt megbízható környezetből

 

DDoS (Distributed Denial of Service – Masszív, elosztott túlterheléssel járó támadás)

 

  • Az elérhetőség kiemelkedően fontos a felhőalapú szolgáltatásoknál. Az AWS által használt technológiák ma már ellenállók a túlterheléses támadásokkal szemben.
  • A szolgáltatások megfelelő kombinációja biztosítja a DDoS elleni stratégiát. Egy ilyen támadás érzékelésekor a különböző szolgáltatások automatikusan jeleznek a rendszer többi része felé minimalizálva az esetleges időkiesést és támadás hatását.
  • Az AWS autoskálázása, a CloudFront és az Amazon Route 53 (ami egy DNS szolgáltatás) együttesen segít kivédeni, illetve enyhíteni egy esetleges DDoS támadást.

 

AWS titkosítás

Az AWS titkosítása egy újabb védelmi szint a felhőben lévő adatok megvédésére. Szintén jól skálázhazó, hatékony:

  • A titkosítás elérhető az adattároló és adatbázis szolgáltatások számára, mint az EBS, S3GlacierOracle RDS, SQL Server RDS és Redshift.
  • A rugalmas kulcs kezelési beállítások, mint az AWS Key Management Service, lehetővé teszi annak beállítását, hogy hogy az AWS vagy mi gyakoroljunk teljes hatalmat a hozzáférések kezelésében.
  • Dedikált, hardver alapú titkosítási kulcs tároló segítségével az AWS CloudHSM, amely lehetővé teszi, hogy eleget tegyünk a megfeleltetési követelményeknek

 

Ezenkívül, az AWS biztosít API-kat, melyeken keresztül telepíthetők egyéb titkosítási és adatvédelmi megoldások, illetve alkalmazások.

 

Monitorozás és log-olás

Rendelkezésre állnak azok az eszközök és szolgáltatások, melyekkel pontosan láthatjuk és felügyelhetjük az AWS rendszerünkben zajló folyamatok, eseményeket:

  • Az API hívásokra kiterjedő teljes felügyeletet, hogy láthassuk mi, mikor, mit és honnan hívott meg azAWS CloudTrail végzi el
  • Jelentések, vizsgálatok, aggregációs beállítások teljes naplózása
  • Figyelmeztetések, riasztások beállításainak lehetősége az Amazon CloudWatch-csal, mikor bizonyos események bekövetkeznek, vagy meghatározott limitet átlépünk

 

Ezekkel az eszközökkel megfigyelhetünk és felügyelhetünk adott eseményeket, mielőtt azok kifejtenék hatásukat. Ezzel is növelhetjük stabilitásunkat a felhőben, csökkentve a rizikófaktort.

 

Felhasználó és hozzáférés vezérlés

Az Amazon felhőjében lehetőségünk nyílik létrehozni és kezelni felhasználókat és a rájuk vonatkozó házirendeket, szabályokat:

  • Az AWS Identity and Access Management (IAM)-mel mi definiálhatjuk a felhasználói fiókokat és rendelhetjük hozzájuk az engedélyeket, jogosultságokat.
  • Az AWS Multi-Factor Authentication segítségévela kiemelt fontosságú felhasználóknak hardver kulcsos azonosítást hozhatunk létre.
  • Az AWS Directory Service a Microsoft Active Directory-hoz hasonló user kezelést valósít meg, lecsökkentve ezzel az adminisztrációs kérésekből, feladatokból álló időkiesést.

Az AWS támogatja a felhasználói fiókok és hozzáférés-felügyeleti alkalmazások integrációját a saját szolgáltatásaikba, valamint az API integrációt is, bármilyen saját alkalmazással vagy szolgáltatással.

 

Következtetés: Látni, hogy az Amazon mindent bevet annak érdekében, hogy jól skálázható, biztonságos felhő infrastruktúrát adjon ügyfelei kezébe. Kijelenthető akkor, hogy az AWS Cloud biztonságos? Igen, kijelenthető, hogy semmivel sem veszélyesebb, mint a dedikált, helyi szerverek üzemeltetése.

 

Összegzés

Napjainkra a legnagyobb márkák mögött húzódó cégek – néha tudtunk nélkül – a felhő mögül kommunikálnak velünk. Ezek a nagyvállalati struktúrák robusztus voltuk miatt mind profitáltak a cloud computing nyújtotta előnyökből, az erőforrások optimalizálásából, a költséghatékony üzemeltetési modellből.

A hoszting piacon is egyre több a szereplő, növekszik a lehetséges megoldások száma, és ehhez mérten, egyre többen választják annak lehetőségét, hogy adataikat a felhőben helyezik el.

Sokkal inkább áll az utunkba a szemlélet, a bizalmi, biztonsági aggályok, amelyeken ha túl tudunk lépni ügyfélként, egy új fejlődési pályára állíthatjuk áruházunkat, cégünket. Nem csupán a multik kiváltsága, hogy a hatékonyságunkat a felhőben lévő számítási kapacitások kihasználásával növeljük. A BuiltWith oldal szerint a felhőbe telepített Magento piacterek száma közel 12 000!

Érdemes elgondolkodnunk egy új megoldáson, hogy ha webshopunk nem tudta vevőinket maradéktalanul kiszolgálni a legutóbbi terhelések során, ha újra szeretnénk kalkulálni a működésünket érintő IT beruházásokat, ha korszerűsíteni szeretnénk vállalati infrastruktúránkat.

Keressünk meg referenciákat felmutatni tudó szolgáltatókat, és kérjük ki véleményüket, hogy milyen módon tudják szakértelmüket és a felhőben rejlő óriási kapacitást kihasználni webáruházunk érdekében.

 

tips UPDATE: Az olvasói kommentek alapján két alfejezettel egészítettük ki cikkünket.

Az első segít kiválasztani a Magento webshopodhoz leginkább megfelelő AWS EC2 infrastruktúrát. Ezt Mikó János, tapasztalt rendszeradminisztrátor kollégánk írta.

A második útmutatót az AionHill IT vezetője, Bognár Tamás írta, aki lépésről lépésre megmutatja neked, hogyan installálható a Magento az AWS felhőkörnyezetbe.

 

Melyek a Magento webshopodhoz leginkább illő AWS EC2 instance-ok, vagyis virtuális gép-példányok?

 

A fejezet címében szereplő kérdést kicsit átértelmezve – és kihagyva belőle a „leginkább” szócskát – gyors, egymondatos választ tudunk adni, hiszen a legkisebb példányokon kívül szinte bármely AWS Instance képes lehet egy Magento 1-es webáruház futtatására.

Ami nem mindegy, az a hogyan.

A válasz legtöbb esetben nem egyszerű, kifejezetten több tényezős játszma, rengeteg körülményt kell mérlegelni. Ebben a részben ezeket a tényezőket fogjuk kategorizálni, majd elemezni, hogy átfogó képet festhessünk arról, hogy melyik a te webshopodhoz leginkább illő megoldás.

Fontos szem előtt tartani, hogy a Magento 1-es és 2-es főverziói között óriási ugrás történt, szinte a teljes rendszert újra írták, minden szempontból erőforrásigényesebb lett.

Ettől eltekintve azonban két nyomvonal mentén határozhatjuk meg azokat a tényezőket, melyeket figyelembe kell vennünk, amennyiben egy AWS EC2 Instance-ra Magento-t szeretnénk telepíteni (és később az elvárásainknak megfelelő stabilitást tapasztalni rajta).

 

Ezek a kategóriák a következők:

  • A technológiai környezet felépítése, minősége, komplexitása:
    • a webszerver és a php motor, valamint ezek optimalizáltsága
    • cache mechanizmusok használata (OPcache, Varnish, Redis, Elasticsearch)
    • adatbázis mérete, elhelyezése
    • „külső” megoldások használata
    • a futtatott kód minősége
  • Az oldal látogatottsága, a terhelés eloszlása

 

A Webkiszolgáló és a PHP feldolgozó

 

Elsőként a rendszer kisebb erőforrást igénylő elemeiről is szót ejtve a webszerverről beszélnénk.

Bár manapság igen széles választék áll rendelkezésünkre, a Magento hivatalos dokumentációja szerint kettő hivatalosan is támogatott webkiszolgáló áll rendelkezésünkre, ezek az Apache Foundation által fejlesztett Apache HTTP Server és az Igor Sysoev nevével fémjelzett nginx.

A kettő között – ahogyan sebességben – manapság erőforrásigényben is egyre kevésbé jelentős a különbség, azonban szigorúan a teljesítménynél és a memóriafogyasztásnál maradva számunkra az nginx lehet a megfelelő választás. Természetesen rengeteg szempont van, melyeket az üzemeltetés során figyelembe kell vennünk, finomhangolhatjuk a webszerverünk memória-, és processzoréhségét.

Ismerve a webszerverek funkcióit (nagyon leegyszerűsítve ez nem más, mint a statikus tartalomra irányuló kérések közvetlen kiszolgálása, dinamikus tartalom során pedig a kérések továbbítása a PHP feldolgozónak) kijelenthetjük, hogy megfelelően optimalizált webszervernek egy Magento webáruház minimális kiszolgálásához 1-200 MB memóriánál többet nem szabad elfogyasztania. (Természetesen több 10 000 felhasználó kiszolgálásakor ez a szám ugrásszerűen megnő!)

Ami lényegesen nagyobb befolyással bír a kiszolgálás sebességére, az a merevlemez olvasási sebessége, ami miatt mindenképp érdemes a manapság egyre szélesebb körben elterjedő SSD-k mellett letennünk a voksunkat ha Magento tárhelyről beszélünk, mert nagymértékben megnő a teljesítmény a hagyományos, mágneses merevlemezekhez képest.

A PHP motor számára ajánlatos memórialimitet közel sem ennyire könnyű meghatározni.

Már a Magento 1 minimális memóriakövetelménye is 256 MB, az ajánlott pedig 512 MB, azonban ez a szám megugrik Magento 2-t futtatva, ahol 2 GB memória alatt lapozómemória (swap) használatát javasolják.

Ezen számok ismeretében kijelenthetjük, hogy Magento 1 futtatásához az AWS legkisebb Instance-án kívül (t2.nano), szinte bármelyik elég lehet, azonban ha Magento 2-es webshopot szeretnénk futtatni, azt mindenképpen olyan rendszerrel kell megtámogatnunk, amely legalább 2 GB memóriával rendelkezik.

Azt azonban semmiképp se felejtsük el, hogy ezek a számok jelenleg csak a minimális futtatókörnyezet kiszolgálására elegendőek, tehát még nem számoltunk azzal, ha cache mechanizmusokat (pl.: Varnish, Redis) szeretnénk beépíteni a rendszerbe, továbbá saját, dedikált adatbázis-kiszolgáló futtatásának a gondolata sem merült fel egyelőre.

 

Cache mechanizmusok használata a rendszerben

 

memory-cache-example

 

Ahhoz, hogy megértsük a különböző gyorsítótárak (cache-ek) erőforrás szükségletét, mindenképpen érdemes legalább pár szóban beszélnünk arról, hogy hogyan is működnek és mi a céljuk.

Gyorsítótárakon olyan átmeneti tárolóelemeket értünk, melyek célja az adatok hozzáférésének gyorsítása.

Egyszerű szemléltető példaként képzeljük el azt, hogy egy képet szeretnénk kiszolgálni a felhasználóink kérésére.

 

Ennek a menete elnagyolva a következő: A HTTP szerver a kérést megkapva a merevlemezhez fordul, onnan beolvassa azt, majd továbbítja a felhasználónak. Most képzeljük el, hogy a következő 50 felhasználó mind-mind ugyanezt a képet szeretné megkapni.

A HTTP szerver minden alkalommal a merevlemez irányába irányítja a kérést. Ismerve a merevlemezek (különösen a mágneses lemezek) és RAM-ok közötti olvasási sebességkülönbséget (kiugróan magas – HDD-SSD: 30-500 MB/másodperc, RAM: 4-10 GB/másodperc), adódik az ötlet, hogy mi lenne, ha az olyan adatokat, amelyekre gyakran szükségünk lesz, a memóriában tartanánk?

Ezzel a felismeréssel tulajdonképpen eljutottunk a különböző gyorsítótár megoldások szükségességéhez.

 

 

PHP OPcache

A címben említett gyorsítótár a PHP 5.5 óta a PHP csomag része, korábbi verziókhoz kiterjesztésként lehetett letölteni. Egyszerű, könnyen konfigurálható cachelési megoldás, így ajánlatos a használata. Memóriaigénye: 64–256 MB

 

Varnish

A Varnish szoftver működésébe ebben a cikkben nem mélyednénk bele, azonban itt bővebben is olvashatsz róla.

Használata – különösen Magento 2 webáruház esetén – erősen javallott, az oldalbetöltési idő töredéke lesz a Varnish nélküli rendszeréhez viszonyítva. Működésükből kifolyólag a gyorsítótárak memóriaigényesek.

Az oldalon tárolt tartalomhoz mérten 128 MB-tól kezdve, több GB-os memóriamennyiség adható a Varnish-nak. Ezzel mindenképpen érdemes számolni, ha webáruházunkat AWS-be szeretnénk költöztetni.

 

Redis

A Redis egy opcionálisan használható objektum cache – key/value store –, amelyet a Magento a konfigurációs paraméterei, illetve akár teljes oldalak (FPC) és sessionök tárolására is tud használni.

Használata a hivatalos Magento 2 fejlesztői dokumentáció szerint is ajánlott. Bár a gyári konfiguráció szerint nincs meghatározva hozzá alapértelmezett memóriakorlát, a tapasztalat azt mutatja, hogy nagy látogatottságú, sok termékkel rendelkező webáruházaknak is elegendő 64–1024 MB-ra állítani a Redis által felhasználható memória méretét.

 

ElasticSearch

Az Elasticsearch egy kereső és analitikai motor, amellyel többek között a webáruházunk termékei között gyorsíthatjuk meg a keresést. Kevéssé elterjedt, nagy számítási- és memóriaigényű megoldás, melyet hivatalosan csak a Magento 2 Enterprise Edition támogat.

Community Editionhöz és korábbi kiadásokhoz modul formájában érhető el. Minimális memóriaigénye 256 MB, az ajánlott pedig 1 GB körülire tehető.

 

Adatbázis

A futtatókörnyezet felépítése során magától értetődőnek tűnhet, hogy az adatbázis egyazon szerveren helyezkedjen el, ahol a webkiszolgáló (Apache/nginx), illetve a PHP kéréseket feldolgozó modul (php-fpm) található.

Kisebb, induló webáruházaknál (kevés termék, alacsonyabb látogatottság) még nem szükséges számottevő erőforrással támogatni az adatbázis-kiszolgálót, viszont soktermékes, nagy látogatottságú oldalaknál az adatbázis kiszolgálásához erős processzorra és rengeteg memóriára lesz szükség.

Ebben az esetben már érdemes elgondolkodnunk rajta, hogy másik szerveren, akár több másik szerveren is, esetleg az AWS adatbáziskezelő megoldásában dedikáltan és skálázottan futtatjuk webáruházunk adatbázisát.

A fejezet elején említett, kis látogatottságú, kevés termékkel rendelkező webshop megfelelően finomhangolt adatbázisához kb. 256–512 MB memóriának bőven elégnek kell lenni, viszont mindenképp fontos kiemelni, hogy ez a szám erősen nőni fog, ha sikeressé válik webáruházunk.

 

„Külső” megoldások használata

 

A külső-t itt képletesen kell érteni, hiszen ezek is AWS szolgáltatások, azonban az EC2 Instance-unkon kívüli szolgáltatásokról beszélünk.

Ha már eldöntöttük, hogy AWS-be szeretnénk költöztetni webáruházunkat, és épp azt mérlegeljük, hogy milyen méretű EC2 Instance-t válasszunk, említést kell tenni azokról a „külső” megoldásokról, melyeket az AWS kínál.

Ezek a fenti szolgáltatásokra nyújtanak AWS által menedzselt megoldást. Előnyük, amellett hogy nagyban lecsökkentik a szükséges EC2 Instance méretét az, hogy jól skálázhatók, illetve az üzemeltetésük könnyű.

Cserébe elég drága szolgáltatásokról beszélünk, így ha van egy olyan szakember a közelünkben, aki magabiztosan üzemelteti ezeket számunkra, akkor jobb választásnak bizonyulhat, ha magunknak telepít(tet)jük őket az EC2 Instance-unkra.

A szolgáltatásokat és azok AWS által nyújtott megfelelőjét az alábbi táblázat foglalja össze:

 

Szolgáltatás neve Szolgáltatás AWS-beli megfelelője
MySQL Amazon RDS
Redis Amazon ElastiCache
Elasticsearch Amazon Elasticsearch Service

 

A futtatott kód minősége

 

Az üzemeltetési oldal mellett van lehetőségünk Magento webáruházunk kód szintű optimalizálására is, mellyel további értékes erőforráspazarlástól kímélhetjük meg magunkat és pénztárcánkat.

A témával kapcsolatos optimalizálási tanácsokat ezen a linken találhatsz.

 

Az oldal látogatottsága, a terhelés eloszlása

 

Az eddigiekben összegyűjtött szempontokkal összefüggésben kiemelten fontos beszélnünk a technikailag kevésbé kézzel fogható (ha áll rendelkezésünkre korábbi adat, akkor mérhető, becsülhető) tényezőkről.

Meg kell vizsgálnunk azt, hogy áruházunknak napi szinten mennyi látogatója van, illetve, hogy melyik napszakban érkezik a legnagyobb terhelés.

Ha magas ügyfélelégedettséget szeretnénk elérni, akkor úgy kell megválasztanunk az erőforrásainkat, hogy a legmagasabb látogatottságot is képesek legyünk kiszolgálni.

A fentebb említett minimális rendszerigények ténylegesen csak a rendszer minimális futtatására és nagyon kevés felhasználó kiszolgálására elegendőek!

 

Ha a legmagasabb látogatottságot is ki szeretnénk szolgálni, annak behatárolására két módszert tudunk javasolni:

  • költséghatékony: kisebb teljesítményű instance-t választunk és a terhelést figyelve felskálázzuk az instance méretét,
  • drága, de biztonságos: nagy teljesítményű instance-t választunk és a terhelést figyelve addig csökkentjük az erőforrásokat, amíg el nem érjük a stabilitás határát.

 

Arról, hogy hogyan tudjuk mérni áruházunk maximális terhelését, korábban itt írtunk.

Bár eddig többnyire a memóriaméretekkel foglalkoztunk, fontos megjegyezni, hogy a látogatószámmal arányosan a processzorhasználat is nő, így 1 VCPU-val rendelkező, kisméretű EC2 példányokat nem tudunk ajánlani a futtatáshoz.

Amennyiben a látogatószámunk már igen magas, úgy érdemes a számítási teljesítményre optimalizált (C3-C4) példányokra beruháznunk.

 

Melyik a legkisebb EC2 instance, amelyen még képes lehetsz futtatni egy Magento 2.0+ környezetet?

 

Az összefoglaló táblázatból kiderül, hogy Magento 2 futtatásához elegendő lehet egy t2.medium példány, azonban ha sikeres webáruházat szeretnénk és a célunk nem 3-5 felhasználó egyidejű kiszolgálása lesz, akkor mindenképp érdemes a nagyobb instance-ok felé (ha hosszú távra tervezünk, akkor pedig több példány használata felé) irányítani a figyelmünket.

 

Konklúzió

Ebben a részben megismerkedhettél azzal, hogy nagyjából milyen szolgáltatásokra (és ezek futtatásához milyen erőforrásokra) lesz szükséged ahhoz, hogy Magento webáruházad kényelmesen üzemeltethesd AWS környezetben, azonban az erőforrások összeszámolására eddig nem került sor.

Az alábbi táblázatban megpróbáljuk összefoglalni, hogy milyen EC2 instance-ra lesz szükséged webáruházad biztonságos kiszolgálásához, de a megfelelő instance-ok mérete nagymértékben a forgalomtól is függ, amely a kiszolgálón landol.

Tehát a táblázatban feltételezzük azt, hogy az áruház látogatottsága nagyon alacsony (3-5 konkurens felhasználó, maximum ~300 látogató/nap ).

Ennél magasabb látogatottságú áruházak költöztetésekor a döntéshez mindenképp szakértői segítséget javaslunk, mert a vásárlóink áruházunkba és annak zavartalan működésébe vetett bizalma az egyik legnagyobb érték!

Látogatók száma Szolgáltatáskészlet Magento 1 Magento 2
300/nap, max 1-3 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL t2.small+ t2.small+
300-400/nap, max 2-3 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL t2.medium+ t2.medium+
300-500/nap, max 3-5 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis t2.medium+ t2.large+
400-800/nap, max 3-8 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis t2.large+ m4.large+
400-800/nap, max 3-8 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis + Elasticsearch t2.large+ m4.large+
600-1200/nap, Max 5-15 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis + Elasticsearch m4.large+ c4.xlarge+

A táblázat tehát tájékoztató jellegű és a minimális követelményekre koncentrál (mind hardver, mind látogatottság tekintetében).

 

 

Hogyan telepítsd a Magento-t AWS-ben? (Gyakorlati útmutató)

 

A Magento napjaik egyik legelterjedtebb ingyenesen használható webáruházmotorja. Egy egyszerű áruházat pár kattintással létre lehet hozni.

Ez az alap oldal persze az esetek nagy részében nem használható komoly online kereskedésre, kisebb-nagyobb átalakításokra szüksége lesz, hogy vásárlóbarát kinézete legyen.

A webáruházak hosztingjára egyre népszerűbb és kényelmesebb megoldást nyújt az Amazon felhő szolgáltatása, az Amazon Web Services (AWS).

Mi az AionHill-nél is ezt ajánljuk és használjuk több okból, melyet egy másik cikkünkben részletesebben kifejtettünk már.

Ebben a részben lépésről lépésre bemutatjuk, hogyan lehet egy Magento áruházat telepíteni AWS környezetben.

 

A sokféle telepítési lehetőség közül hármat szeretnénk kiemelni:

  • 1) Egy teljesen üres gépre kézzel feltelepítjük a szolgáltatásokat (web és adatbázisszerver, php) és beállítjuk a saját magunknak a konfigurációt. Majd telepítjük a Magento-t.
  • 2) Keresünk egy meglévő, előre telepített AMI-t (Amazon Machine Images), amire előre fel vannak telepítve a szükséges szolgáltatások. Mi is rendelkezünk egy ilyen előre elkészített rendszerrel.
  • 3) A harmadik lehetőség, hogy keresünk egy Magento hosztinggal foglalkozó céget és megbízzuk, hogy az igényeinknek megfelelően végezzék el nekünk a beüzemelést. Legyen szó egy meglévő áruházról, vagy egy teljesen újról.

 

A fent említett pontok közül részletesebben a második lehetőséget mutatjuk be, miszerint egy meglévő AMI-t használunk a Magento webáruház beüzemeléséhez.

A leírásban végigmegyünk azon, hogyan készítsük el a saját EC2 gépünket, majd azon telepítünk egy Magento áruházat.

 

 

EC2 instance létrehozása

 

Első lépésként jelentkezzünk be az AWS fiókunkba. Ha ez megtörtént válasszuk ki a megfelelő zónát, ahol a gépet szeretnénk futtatni.

Segít ebben az alábbi kép, ha ezt látjuk jó úton indultunk el:

 

01-aws-account

 

Majd lépjünk az AWS EC2 menedzsment felületére és kattintsunk a Launch instance gombra.

A következő képernyőn – Choose an Amazon Machine Image (AMI) – lehetőségünk van kiválasztani az előre elkészített sablonok közül a nekünk megfelelőt.

A cikkben, ahogy azt korábban említettük, az AionHill által előre elkészített nyilvános sablont fogjuk használni. Ezen előre fel van telepítve az adatbázis és a webszerver, valamint a php.

A Community AMIs fülön az AIONHILL-Magento-Public sablont kell megkeresni és kiválasztani.

 

 

Ezután tudjuk beállítani a szerverünk erőforrásait: Choose an Instance Type.

A leírásban – alapbeállítás – t2.mirco instance-ra fogjuk telepíteni a Magento webáruházat.

Ezt a változatot éles környezethez semmiképpen sem ajánljuk!

 

02-aws-instance-configure-magento

 

Következő lépésként a hálózat beállítását fogjuk elvégezni.

A network és subnet paraméterek, valamint a hálózati eszközök adatait szükséges megadni. Itt használhatunk egy meglévő hálózatot, vagy készíthetünk egy újat külön ennek a szolgáltatásnak.

Ezután a szerverünk tárhelyének adatait tudjuk megadni.

A sablonban előre be van állítva egy 10 GB-os lemez a rendszernek. Az a javaslatunk, hogy a Magento-t ne erre, hanem egy másik, dedikált lemezre telepítsük.

Adjunk hozzá, egy 20 GB méretű lemezt és fontos megjegyeznünk, hogy az extra lemezt milyen néven (Device) adjuk hozzá a géphez. Az utolsó betűt (esetünkben a b) jegyezzük meg, mert ezzel a jelöléssel fogjuk megtalálni a lemezt a gépen belül.

 

03-aws-instance-storage-magento

 

A következő fülön a hálózati beállításokat tudjuk személyre szabni.

Az általunk telepített géphez a következő szabályokat kell beállítani, hogy elérhetőek legyenek mindenhonnan:

  • SSH eléréshez: 22-es port
  • HTTP és HTTPS eléréshez a 80-as és 443-as port

 

Miután ellenőriztük a gépünk beállításait, minden akadály elhárult az elől, hogy el tudjuk indítani.

Végső lépés, hogy meg kell adnunk egy SSH kulcspárt, amellyel távolról be tudunk lépni a gépünkre.

 

Magento 1 telepítése

 

1)

A gép telepítés és indítás utolsó lépéseként megadott SSH kulcspár privát kulcsával belépünk a szerverünkre. A publikus részt az AWS beilleszti a megfelelő helyre a telepítés után.
Windows-on erre alkalmas program a Putty, a Linuxon a következő módon lehet belépni a terminál segítségével:

ssh [email protected]ím -i /útvonal/a/privát-kulcsunkhoz

2)

A belépés után első lépésként frissítsük a rendszerünket a legfrissebb állapotra:

apt update && apt upgrade

3)

A gép telepítése során kiemeltük, hogy a Magento dedikált lemezre kerüljön. A használatbavétel előtt szükséges pár parancsot futtatni:

 

 # először létrehozunk az eszközön egy új partíciós táblát  
 # valamint egy darab partíciót, amely a teljes lemezterületet felhasználja  
 sudo parted -s /dev/sdb mklabel msdos mkpart primary ext4 1MiB 100% print  
   
 # az új partíciót ext4 fájlrendszerűvé formázzuk  
 sudo mkfs.ext4 /dev/sdb1  
   
 # a partíció csatolási pontját rögzítjük az fstabban  
 sudo /bin/bash -c "echo '/dev/sdb1  /var/www/webapp/  ext4  defaults,noatime  0 2' &gt;&gt; /etc/fstab"  
   
 # majd felcsatoljuk a /var/www/webapp/ könyvtár alá  
 sudo mount /var/www/webapp/  
   
 # végül beállítjuk a könyvtárhoz a megfelelő tulajdonost  
 sudo chown webapp:webapp /var/www/webapp  

 

4)

Adatbázis beállításainak módosítása, személyre szabása:

Az AionHill által biztosított AMI teljesen publikus, így kérjük, mindenképp változtasd meg a MySQL jelszavakat, mert más felhasználók számára ugyanaz lesz az alapértelmezett jelszó, mint számodra.

Ezen jelszavak megváltoztatására szintén az alábbi egysoros szkripteket ajánljuk. Az általad választott jelszót írd be a sorok elején a változók értékadásához.

Például:


 SQLROOTPWD='általad-választott-jelszó'
 SQLWAPWD='általad-választott-jelszó-2'
 SQLROOTPWD='PASSWORD-FOR-ROOT'; sudo -i mysql -e "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('$SQLROOTPWD');" && sudo sed–i "s/^password=.*/password=$SQLROOTPWD/g" /root/.my.cnf
 SQLWAPWD='PASSWORD-FOR-WEBAPP'; sudo -i mysql -e "SET PASSWORD FOR 'webapp'@'localhost' = PASSWORD('$SQLWAPWD');"

 

Ezek a jelszavak nagyon fontosak, jegyezzük fel őket, mert a későbbiekben (10-es lépés) még használni fogjuk őket! (Root PWD: adminisztrátori jelszó, WA PWD: web alkalmazás jelszó [ezt a Magento fogja használni])

 

5)

Ha ezekkel készen vagyunk, akkor be kell szereznünk a Magento forráskódját, hogy nekifoghassunk a telepítésnek. Ezt érdemes egyből a Magento-t futtató felhasználó nevében csinálni.

sudo su -s /bin/bash webapp

 

6)

Felhasználóváltás után lépjünk abba a könyvtárba, ahová a Magento-t fogjuk telepíteni:

cd /var/www/webapp/www

 

7)

Töltsük le a forráskódot és csomagoljuk ki, az alábbi parancsokkal:

wget https://github.com/OpenMage/magento-mirror/archive/magento-1.9.zip

unzip magento-1.9.zip

mv magento-mirror-magento-1.9/ magento

rm –f magento-1.9.zip

 

8)

A következő mappák jogosultságait szükséges módosítani a megfelelő működéshez:

chmod -R o+w app/etc/

chmod -R o+w var/

chmod -R o+w media/

 

9)

A telepítés megkezdése előtt már csak egy dolgot kell beállítanunk: a webszervert.

Ehhez ismét egy szkriptet biztosítunk, amelynek elkészítéséhez a Magento telepítővel érkező konfigurációs fájlt vettük alapul.

Az lenti kódot a terminálba illesztve egy nginx konfigurációs állomány fog létrejönni a következő helyen:

/etc/nginx/sites-available/webapp.conf

 

A konfigurációs fájlban a server_name változó „mage.dev” értékre lesz beállítva, amely azt jelenti, hogy az nginx a mage.dev domain nevet fogja megfelelően kiszolgálni.

Ha más néven szeretnénk használni Magento-nkat, akkor a server_name mezőt át kell írni az általunk választott domainre a későbbiekben.

 


sudo /bin/bash -c 'echo -e " server {
    server_name magedev;

    listen              80;
    ssl off;

    root               /var/www/webappp/www/magento;
    access_log         /var/log/nginx/access.log  main;
    error_log          /var/log/nginx/error.log  warn;

    location / {
        index  index.html index.htm index.php;
        try_files $uri $uri/ @handler;
        autoindex off;
    }

    location /app/                { deny all; }
    location /includes/           { deny all; }
    location /lib/                { deny all; }
    location /media/downloadable/ { deny all; }
    location /pkginfo/            { deny all; }
    location /report/config.xml   { deny all; }
    location /var/                { autoindex on; }
    location  /. {
        return 404;
    }

    location @handler {
        rewrite / /index.php;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

        location ~ .php/ {
        rewrite ^(.*.php)/ $1 last;
    }

    error_page  404              /404.html;
    location = /404.html {
        #root   /usr/share/nginx/html;
        return 404;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        #root   /usr/share/nginx/html;
        #return 404;
    }
}” > /etc/nginx/sites-available/webapp.conf'

 

A konfiguráció engedélyezéséhez egy szimbolikus linket kell készítenünk a fájlról a megfelelő mappába, majd újra kell indítanunk az nginx webszervert.

sudo ln -s /etc/nginx/sites-available/webapp.conf /etc/nginx/sitesenabled/webapp.conf

 

sudo systemctl restart nginx.service

 

 

10)

Elérkeztünk a Magento  telepítéséhez. Kedvenc böngészőnk címsorába gépeljük be a következőt:

http://az-általunk-választott-domain/setup/

Ha mindent az útmutatásnak megfelelően csináltunk, akkor a következő ablak fogad minket:

 

04-aws-install-magento

 

Az „I agree to the above terms and conditions.” jelölőnégyzetet bepipálva lehetőségünk van tovább haladni a telepítésben.

Első lépésként be kell állítani a lokalizációs adatokat:

 

05-aws-install-magento-localization

 

Következőként a Magento-t kiszolgáló adatbázis hozzáférést kell beállítanunk.

Ezt a leniti ábra szerint kell kitölteni, a User Password mezőbe pedig azt a jelszót kell beírnunk, melyet korábban (4-es lépés) a második szkripthez adtunk meg (SQLWAPWD).

 

06-aws-install-magento-configuration

 

Az adatok kitöltése után tudunk tovább haladni.

 

07-aws-install-magento-admin-account

 

A Create Admin Account fülön egy adminisztratív felhasználó hozzáféréseit rögzíthetjük.

A felhasználónév, e-mail cím és a jelszó megadása, majd megismétlése után a „Continue” gombra kattintva elérkeztünk a végső lépéshez.

 

Itt lehetőségünk van megtekinteni a backend és frontend oldalt:

 

08-aws-install-magento-all-set

 

Ha minden jól csináltunk, az alábbi oldalakat kell látnunk a böngészőben.

 

Frontend:

 

09-aws-install-magento-frontend

 

Backend:

 

10-aws-install-magento-backend

 

A cron jobok, vagyis időzített folyamatok beállításához az alábbi parancsot kell kiadnunk, amely egy lépésben engedélyezni fogja a Magento-t futtató felhasználó (webapp) számára a cron jobokat a hivatalos Magento dokumentáció alapján:

 

sudo /bin/bash -c “echo -e ‘*/5 * * * *     (cd /var/www/webapp/www/;/bin/sh ./cron.sh) >/dev/null 2>&1’ | crontab -u webapp -”

 

Tovább fejlesztési lehetőségként említenénk meg, hogy a következő szolgáltatások cseréjével jobb teljesítmény érhető el egy nagyobb áruháznál. A Mysql adatbázis szervert kiválthatjuk az Amazon RDS szolgáltatásával. A Redist cserélhetjük az Amazon EleasticCache-re. Ha élünk ezzel a lehetőséggel, akkor az AMI-ból telepített gépen állítsuk le a Mysql-t és Redist, majd vegyük ki az automatikusan induló programok közül.

 

</p

Magento frontend sebesség gyorsítás és mérése

Tartalom

  • A gyorsaság arányos a bevétellel
  • Oldalsebesség hatása a keresési helyezésekre
  • Frontend gyorsítás a Magento-ban
    • Szerveroldal
    • Varnish
    • Statikus tartalmak – JavaScript, CSS fájlok és képek
    • Frontend optimalizálása a design függvényében
    • Képek méretének optimalizálása
    • Megjelenítést gátló elemek minimalizálása
    • Szerveroldali tömörítés engedélyezése
    • HTML, CSS, JavaScript lekicsinyítése
  • Befejezés

 

Induljunk ki abból, hogy rákeresel valami kifejezésre a weben, és a kiszemelt oldal, amire rákattintottál lassan töltődik be. A következő kérdésekre kell választ adni magadban:

 

  • Mennyi idő után fogod azt mondani, hogy nem vársz tovább, és inkább visszalépsz a keresőoldalra?
  • Mennyire szívesen látogatsz vissza később a kérdéses oldalra, ha tudod, hogy nagyon lassan töltődik be?
  • Milyen bizalommal ajánlod az ismerőseidnek az adott oldalt?
  • Mi fog akkor történni, ha egy olyan szituációban vagy, ahol kénytelen vagy a mobilodat használni böngészésre és azonnal el kellene intézned az adott dolgot?

 

A válaszok egyértelműek, és mint weboldal, illetve webshop tulajdonos, pontosan ezeket a problémákat kell elkerülnöd azért, hogy több látogató használja a te oldaladat.

A céged presztízse múlik azon, hogy milyen gyorsan töltődik be az oldalad, ráadásul, ha lassú a betöltés, akkor nem is fognak visszatérni, keresnek másik hasonló oldalt, ahol a felhasználói élmény számukra sokkal jobb.

A sebesség a weboldalaknál mindig is nagyon fontos tényező volt, ám az idő előre haladtával az oldalakkal szemben támasztott követelmények is egyre komolyabbak.

A 2011-es adatok például így festettek:

 

oldalsebesség

 

Mára azonban az oldalaknak már sokkal gyorsabban kell betöltődniük.

A Google által a webmestereknek készült videóban kiderül, hogy egy webshopnak 2016-ban elfogadott érték 2 másodperc, viszont a Google-nél a jónak számító idő a 0,5 másodperc.

 

 

A Financial Times idei kimutatása szerint a következő tendencia figyelhető meg a cikkek olvasottságánál:

 

oldalak betöltési ideje

 

Vagyis jól megfigyelhető, hogy ha gyorsabb a konkurenciánál az oldalunk, akkor előnyre tehetünk szert, de ez természetesen fordítva is igaz.

A következő statisztika azt szemlélteti, hogy melyek azok a webshopokban problémás részek, amelyeket az Egyesült Királyságban nehezményeznek (Econsultancy, 2012).

 

területi problémák

 

Tisztán látszik, hogy a betöltési idő a megkérdezettek első számú problémája, mintegy 66,8%-uk nincs vele megelégedve.

Néhány további hasznos tudnivaló az oldal gyorsaságával kapcsolatban:

  • Ha 3 másodpercnél tovább kell várni az oldal betöltésére, akkor a felhasználók 40%-a inkább meg sem várja
  • Egy átlagos felhasználó mindössze 2,078 másodpercet hajlandó várni egy oldal betöltésére
  • Ha az oldal 1-2 másodperc alatt betöltődik, az 2%-os látogatószám növekedést eredményez
  • Ha 1 másodperc alatt teljesül a betöltés, akkor 4,6%-os a javulás

 

A gyorsaság arányos a bevétellel

 

Általánosságban elmondható, hogy 1 másodpercnyi oldal gyorsulás átlagosan 7%-os növekedést eredményez a konverzióban.

Megjegyzés: Akkor történik konverzió, ha valaki a hirdetésre kattint, majd olyan műveletet hajt végre, amelyet Ön a vállalkozás szempontjából értékesnek határozott meg. Ilyen lehet például az online vásárlás vagy a bolt telefonos megkeresése.

 

Ez a webshopok esetében természetesen a számokban is megmutatkozik. Érdekesség, hogy a Walmart és az Amazon egymástól függetlenül, de rájöttek, hogyha 0,1 másodperccel tudnak gyorsítani az oldal betöltésén, akkor az 1%-os növekedést jelent a bevételeikben – ekkora cégeknél az 1% is óriási pénz!

 

Néhány adat a webshopok esetében:

  • a felhasználók 83%-a elvárja, hogy a weboldal 3 másodperc alatt töltődjön be
  • ha 3 másodpercnél többet kell várnia, akkor a felhasználók 44%-a elpártol az oldaltól
  • 79% ezek után megfontolja, hogy egyáltalán visszatérjen-e az oldalra
  • 46% pedig még el is meséli az ismerőseinek az érzéseit ezzel kapcsolatban

 

Érdemes elgondolkodni azon, hogy növeljük az oldalunk sebességét, hiszen, másodpercenként általánosságban 7%-os növekedést érhetünk el, amit ha a napi bevételünk 100 000 Ft, akkor éves szinten megközelítőleg 2 500 000 Ft plusz bevételre tehetünk szert (100 000 * 0,07 * 365).

 

Oldalsebesség hatása a keresési helyezésekre

 

John Mueller SEO szakértő utánajárt a témának, és egyik cikkében kifejtette, hogy a lassú oldalak hátrébb vannak sorolva, viszont a gyors weboldalak között már nem játszik nagy szerepet pár ezredmásodpercnyi különbség.

 

Két fontos tényezőt kell megvizsgálni a weboldalak gyorsaságát illetően:

Az egyik – amit a felhasználó érez, azaz számára milyen gyorsan jelenik meg a tartalom,

A másik – ami a Google számára fontosabb –, hogy meg tudja különböztetni a lassú weboldalakat a normális sebességűektől. Kihangsúlyozta azt is, hogy minél gyorsabb az oldalunk, annál több felhasználó használja, így sokkal több aloldalt tudnak megtekinteni adott idő alatt, így több információt ismernek meg.

 

Frontend gyorsítás a Magento-ban

 

Mivel a legelterjedtebb keresőportál a Google, ezért célszerű az általa támasztott elvárásoknak megfelelni, amit legjobban a saját sebességmérő alkalmazásában lehet kipróbálni, és az ott kapott válaszok alapján javítani rajta: Google PageSpeed

Első projektünk, amiben megvizsgáltuk, hogy mivel tudjuk gyorsítani az oldal betöltési sebességét a Fradi webshop-ja, ezen a példán keresztül mutatom be a lehetőségeket:

 

Szerveroldal

 

Természetesen ahhoz, hogy a frontend tartalmak gyorsabban legyenek láthatóak a böngészőkben, a szerveroldalon is végre kell hajtani bizonyos optimalizálási folyamatokat annak érdekében, hogy a válaszidő a lehető legrövidebb legyen.

 

Varnish

 

Az egyik legelterjedtebb gyorsítótár (cache) megoldás a dinamikus tartalmak kiszolgálására, amiről már egy korábbi cikkünkben részletesen írtunk.

 

Statikus tartalmak – JavaScript, CSS fájlok és képek

 

Ezek gyorsítótárazásához az AWS CDN megoldását használjuk.

 

Frontend optimalizálása a design függvényében

 

A mai trendeknek megfelelően reszponzív design esetén a megjelenő képek mérete a böngésző méretétől függenek. A következő példában szemléltetem is, látszik, hogy a design és a sitebuild eltér az egyes töréspontok után (az AionHill a Bootstrap töréspontjait veszi alapul az általunk készítendő oldalak megvalósításakor):

 

webshop-design-1

1. ábra – minimum szélesség 1200 px

 

webshop-design-2

2. ábra- minimum szélesség 992 px

 

webshop-design-3

3. ábra – minimum szélesség 768 px

webshop-design-4

4. ábra – maximális szélesség 768 px

 

 

Fontos, hogy a megjelenő kép mérete megegyezzen annak a területnek a méretével, ahol azt megjelenítjük. Ez nem jelentene gondot akkor, ha mellőzzük a reszponzivitást, hiszen a Magento-ban le lehet kérdezni a képek átméretezett példányát:

 

$this->helper('catalog/image')->init($_product, 'small_image')->resize(710, 710);

 

Vagyis meg kell oldanunk, hogy mindig az adott böngészőmérethez jelenítse meg az átméretezett képet. Erre a legmegfelelőbb megoldás a <picture> HTML tag

A lényege, hogy meg lehet adni, hogy milyen felbontásoknál melyik kép jelenjen meg, végül pedig magát a kép <img> tag-et, hogyha a böngésző nem támogatná még ezt az új bevezetett szabványt:

<picture>
 <source srcset="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(360, 365); ?>" media="(min-width:1200px)">
 <source srcset="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(293, 297); ?>" media="(min-width:992px)">
 <source srcset="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(710, 710); ?>" media="(min-width:768px)">
<source srcset="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(710, 710); ?>" media="(min-width:300px)">
 <img class="img-responsive"
 src="<?php echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(360, 365); ?>"
 alt="<?php echo $this->stripTags($this->getImageLabel($_product, 'small_image'), null, true) ?>"/>
</picture>

 

Képek méretének optimalizálása

 

A weboldalakra feltöltött képek túlnyomó többségénél megfigyelhető, hogy minőségromlás nélkül bizonyos programokkal lekicsinyíthető a képek mérete. Erre a Google is figyel, és jelzi a vizsgálatkor, hogy melyek azok a képek, ahol ezt meg kell tenni.

 

webshop-kep-optimalizalas

 

Erre mi nem készítettünk saját modult, mert a piacon fellelhető sok ingyenes Magento bővítménynek köszönhetően ez feladat könnyen megoldható. A választásunk az Image Optimizer for Magento-ra esett, ami egy ingyenes és teljesen jól használható megoldás erre a problémára.

A lényege, hogy a média, skin és frontend mappákban fellelhető képeket kigyűjti, és utána cron segítségével kötegelve optimalizálja a szerveren található képmanipuláló könyvtárak segítségével (jpegoptim, optipng).

 

Megjelenítést gátló elemek minimalizálása

 

Ez a gyakorlatban azt jelenti, hogy ha a JavaScript és CSS fájljaink száma nagy, akkor azoknak a betöltése sokkal több időt vesz igénybe, mert a fájlok betöltésével megvárja a másikra adott választ. Ennek a legmegfelelőbb mérése a Chrome-ban a developer tools, ahol összefűzés nélkül a következő eredményt kapjuk:

 

css-developer-tools-fajl-osszefuzes-nelkul

 

Látszik, hogy rengeteg idő, míg az összes fájl betöltődik. Ha a Magento adminisztrációs felületén bekapcsoljuk a fájlok összefűzését, akkor ugyanez az oldal a következő eredményt adja:

 

fajl-keptomorites-webshop

 

A felhasználó szemszögéből ugyanaz az eredmény, viszont jóval kevesebb fájlból dolgozik. Ez a lehetőség Magento alapfunkcionalitás, és ha jól írták meg a fejlesztők a JavaScript osztályokat, eljárásokat, akkor nem is lehet gond az összefűzésnél.

Bekapcsolni a System/Configuration/Developer menüpontok alatt lehet:

 

magento-developer-menu-fajl-osszefuzes

 

Szerveroldali tömörítés engedélyezése

 

 

A PageSpeed részletesen leírja, hogy egyes webszerverek esetében mi a teendő, milyen modulokat kell telepíteni ahhoz, hogy a tömörítés be legyen kapcsolva

Tesztelni könnyedén lehet, például Chrome esetében inspector módban (Ctrl+Shift+i) a network fülön a HTML oldal header (fejléc) részében megtalálható a következő:

 

szerver-oldali-tomorites-webshop

 

Végezetül a HTML, CSS, JavaScript lekicsinyítése

Távolítsuk el a felesleges karaktereket mindhárom oldalelemből, mert így csökkentjük a válasz méretét, így növeljük a válasz sebességét.

Magento-hoz ismételten az Aptrian termékét választottuk (Minify HTML CSS JS for Magento), ami a feltelepítés után egy egyszerű adminisztrációs beállítás után egy gomb megnyomásával már végre is hajtja azokat a módosításokat a fájlokon, amik növelhetik a méretét.

Fontos megemlítenem, hogy itt nem a javascript kicsinyítéséről/titkosításáról van szó, hanem a felesleges elemek eltávolításáról:

A Magento-s Validator osztály egy kiragadott része:

 

magento-validator-osztaly

 

Ezt a modul átalakítja:

 

magento-validator-osztaly-modul-atalakitas

 

Rövidebb tartalom, kevesebb felesleges karakter, gyorsabb betöltődés.

 

 

Összegzés

Az oldalbetöltési sebesség növelése egyre fontosabb a weboldalak, különösen a webshopok, számára, hiszen a látogatók is egyre többet várnak el, egyre jobb felhasználói élményt szeretnének.

Ebben a cikkben leírtam, hogyan lehet a Magento 1.x-nél javítani az oldalbetöltési sebességet, amely során különböző megoldásokat javasoltam.

Ami a Magento 2 rendszert illeti, úgy tervezem, az ezen a platformon működő webshopok frontend gyorsításával kapcsolatban is megjelentetek egy blogcikket, hogy teljes legyen a kép.

Külső adatbázisok elérése és egyedi raktárkészletek kezelése Magento-ban

Miről is lesz szó a cikkben?

  • Mi is az az FMCG?
  • Általánosságban pár szó az adatbázisokról
  • Adatbázisok és a Magento
  • Adatbázis típusok és felhasználásuk az FMCG-hez
  • Készlet változások kezelése a Magentoban, kérdések és javaslatok
  • Middleware: Köztes rétegek, MOM rendszerek

Mi is az az FMCG?

Rövid defíníció:

Fast-moving consumer goods vagy consumer packaged goods (CPG), azaz gyorsan forgó fogyasztási cikkek.

Azokat az árucikkeket értjük ez alatt, amelyek viszonylag gyakran, napi, heti vagy havi rendszerességgel újra megvásárlásra kerülnek és viszonylag alacsony árúak.

Ide tartozik például a borotva, papír zsebkendő vagy kisbabások esetén a nedves törlőkendő és a pelenka, de lehet szó a kötszerekről vagy a ragtapaszról is.

 

 Adatbázisok

Rövid defíníció:

Az adatbázisok azonos minőségű, strukturált információk összessége, amelyet tárolásra, szerkesztésre és lekérdezésre alkalmas adatbázis-kezelő alkalmazás kezel. Az adatbázisok célja az adatok megbízható, hosszú távú tárolása és viszonylag gyors visszakeresés biztosítása.

Az adatbázisokat két nagy csoportba érdemes bontani, a logikai és a fizikai adatbázisokra. A logikai adatbázisokat felépítésük, működésük és sajátosságaik alapján szokás megkülönböztetni a fizikai adatbázisoktól. Adatmodellekkel reprezentáljuk őket és a korszerű adatbázisoknál a fizikai adatbázist több logikai adatbázison keresztül is elérhetjük, mintha egyfajta burkoló rétegeket képeznének a tárolt adatok elé.

A Magento adatmodelljei (model) és gyűjteményei (collection) pontosan egy ilyen logikai adatbázist képeznek le a fizikai adatbázis elé, hogy megkönnyítsék és érthetőbbé tegyék az adatok feldolgozását. Az adatmodellekről, gyűjteményekről részletesebben olvashatsz ebben a cikkünkben: Magento 2 modul fejlesztés lépésről lépésre – 1. rész

 

magento külső adatbázis, modellek közti összefüggés

Fogalmi, logikai és fizikai modell összefüggése

 

Adatbázisok és Magento

A webáruházak és manapság minden alkalmazás egyik legfontosabb része az adatbázis, melyek üzemeltetése, karbantartása és fejlesztése hatalmas összegekbe kerül. Az adatbázisok lehetnek elosztottak is, mivel a Magento webshop logikai adatbázisa beburkolja a kapcsolatot, így csökkenthetjük a költségeinket és a megfelelő adatokat a megfelelő helyeken kezelhetjük.

A Magento emellett képes egyszerre több különböző adatbázist is kezelni, melyekhez a PDO-t használja, így Cubrid, FreeTDS / Microsoft SQL Server / Sybase, Firebird, IBM DB2, IBM Informix Dynamic Server, MySQL 3.x/4.x/5.x, Oracle Call Interface, ODBC v3 (IBM DB2, unixODBC és win32 ODBC), PostgreSQL, SQLite 3 és SQLite 2, Microsoft SQL Server / SQL Azure, 4D alapú kapcsolatokat könnyedén kiépíthetünk benne.

 

Többszörös adatbázis-kezelés

Ahhoz, hogy egyszerre több adatbázist is kezelni tudjon a Magento webáruházunk, csupán elegendő a modulunk config.xml konfigurációs állományba felvenni az új adatbázis elérhetőségének paramétereit (host, username, password, dbname), valamint a connection > use-ban meghatározni a kapcsolat azonosítóját.

Ezzel a kapcsolatnak már nincs szoftveres akadálya, ha a hálózaton keresztül a host elérhető, akkor a kapcsolat létrejön. A fejlesztőknek ezután már csak a logikai adatbázist (model, collection) kell létrehoznia, hogy az adatok áramlása zökkenőmentes legyen.

 

Adatbázisok: Állomány alapú források

A tapasztalatok azt mutatják, hogy a legtöbb esetben egyszerű (csv) vagy összetett (xml, json) forrás állományok állnak a felhasználók birtokában. Ezek az állományok tartalmazzák a teljes termékkínálatot, a felhasználói adatokat vagy akár a rendeléseket is. A Magento is lehetőséget biztosít ezen adatok exportálására, egészen könnyedén az adminisztrációs felületről.

 

magento külső adatbázis, skálázhatóság

 

Előnyei

  • Könnyen kezelhetőek
  • Könnyen módosíthatóak
  • Az ember számára viszonylag könnyen olvasható formátum
  • Exportálási lehetőség elérhető, nem indokol fejlesztést

 

Hátrányai

  • Szerkesztéskor nagy a hibalehetőség, amivel a teljes állomány szerkezete felbomolhat
  • Rekordok szerkesztése nehézkes
  • Az állományok kódlapjának beállítása adattorzulást okozhat
  • Importálásnál a teljes adatmennyiséget feldolgozzuk
  • Nem frissül automatikusan

 

Adatbázis-kezelő rendszerek

Az állomány alapú forrásokhoz képest itt annyi a különbség, hogy egy adatbázis-kezelő rendszeren keresztül érjük el adatainkat. Az adatbázis-kezelő áthidalja az állományok kezelése okozta hátrányokat, hiszen jól értelmezhető logikai adatmodelleket kínál erre. A fizikai adatfüggetlenség biztosítására az adatbázis-kezelő motortól független állományszervezési rendszereket dolgoztak ki, hogy a háttértár szervezése illetve eszköz függetlensége biztosítva legyen.

Az adatmodellek alapján megkülönböztethetünk relációs, objektumorientált, hálós, deduktív, objektumrelációs, deduktív relációs, deduktív objektumorientált adatbázis-kezelőket.

 

Háttértár szervezések

  • Optikai
  • Lyukszalagos
  • Mágnesszalagos
  • Merevlemezes
  • Memória-adatbázis

 

Előnyei

  • Felhasználói felület az adatokhoz
  • SQL általános nyelvből alakultak ki a lekérdező nyelvek
  • Funkcionalitás bővíthető
  • Elosztott rendszerek megvalósíthatóak

 

Hátrányai

  • Bonyolultak: Logikai, halmazkezelési ismeretek szükségesek
  • Lekérdező nyelvet ismerni kell
  • Nő az adattároláshoz és az adatbázis kezelőhöz szükséges tárterület szükséglet.

 

Adatbázisok: Szolgáltatás alapú források

A szolgáltatás alapú források alá tartoznak azok az adatbázis elérések, melyeket egy interfészen keresztül érhetünk el egy másik szerveren, mely akár a világ másik felén is lehet. Még a mai napig is leginkább SOAP protokollon keresztül vagy a fejlesztéseknek hála, valamilyen REST szolgáltatáson keresztül tudjuk az adatokat elérni és manipulálni.

A SOAP interfészen keresztül történő elérés legnagyobb hátránya, hogy az interfész bonyolult és részletes, szemben a REST interfésszel, mely sokkal egyszerűbb és kényelmesebb. A biztonság szempontjából a SOAP kliens volt korábban a megbízhatóbb, azonban az SSL kapcsolatokkal és egyéb titkosítási algoritmusokkal most már azonos megbízhatósági szintre került a két interfész.

A mobil alkalmazások fejlődési iránya azt mutatja, hogy szolgáltatás alapon érik el a távoli adatbázisokat, leginkább REST kliensként, mivel az adatbázisok méretei miatt ezek készüléken elhelyezése és feldolgozása hardver- és szoftverteljesítmény szempontjából sem lenne ideális.

 

Előnyei

  • Teljesítmény: Kisebb teljesítmény is elegendő az alkalmazás futtatásához
  • A REST alapú szolgáltatások interfésze egyszerű (HTTP kérések), jól érthető és kicsi erőforrásigényű a JSON alapú formátum könnyen kezelhető, akár már frontend szinten is.
  • A SOAP protokoll dokumentáltsága és hibajelzése kiforrottabb
  • Az általános biztonság SSL tanúsítványokkal megvásárolható

 

Hátrányai

  • A SOAP alapú szolgáltatások interfésze összetett, bonyolult, a fejlesztések drágák és az XML formátum miatt nehézkes a feldolgozása
  • A hálózati kommunikáció bizonytalanságai miatt lassú, elérhetetlen lehet
  • A hálózati kommunikáció miatt a biztonság nem 100%-os, további titkosítási algoritmusokra lehet szükség

 

 

magento külső adatbázis rest, soap

 

Adatbázisok: Külső alkalmazás források

A vállalatirányítási rendszerek adatbázisai nem különülnek el a külső adatbázisoktól, azonban mégis összetettebbek, nagyobbak (méret) lehetnek, mint más célirányosan összerakott adatbázisok. Mivel ezek az adatbázisok vállalatirányítási feladatokat látnak el, így folyamatosan frissülnek, változnak és bővülnek. Éppen ezért összetett interfészekkel rendelkeznek a külső rendszerek számára, melyek integrációja a közepestől a nagy bonyolultságú feladatig terjedhet.

Szerencsére a legtöbb ERP, CRM és PIM rendszer rendelkezik olyan modullal mely telepítése és minimális konfigurációja révén biztosítja a webáruházunkkal történő összekötést. Nagyon fontos, hogy ezen rendszerek között ajánlott az azonnali, kétirányú kommunikáció kialakítása, hogy a lehető legkevesebb emberi erőforrást kelljen az adminisztrációs munkára fordítani.

 

Előnyei

  • A kommunikáció lehet teljesen automatizált, így az adminisztrációs feladatok jelentősen csökkennek
  • Egy rendszert elegendő megtanulni kezelni és figyelni
  • A legismertebb rendszerekhez történő integráció gyors és zökkenőmentes
  • Fejlett felhasználói interfésszel rendelkeznek
  • Több protokollon vagy interfészen keresztül is képesek kommunikálni

 

Hátrányai

  • A rendszerek közötti kommunikáció keresztmetszete
  • A rendszerek közötti kommunikáció hiánya esetén adatvesztés
  • Kétirányú kapcsolat és/vagy aszinkronitás nélkül túl nagy emberi erőforrásra van szükség

 

Termék- és készletváltozások

Az FMCG esetén kritikus tényező a termék- és készletváltozások azonnali, legalább naprakész frissítése. Hiszen, ha egy új termék érkezik az áruházba, annak nem biztos, hogy fontos azonnal eladhatónak lennie a webáruházban, de ha elfogy egy termék készlete, akkor azt azonnal jelezni kell a vásárló felé vagy leadni a rendelést a beszállító, raktár vagy gyártó felé.

Ez a szinkronizáció ideális esetben kétirányú, azaz mindkét oldal képes jelezni a másik oldalnak, hogy az adatok megváltoztak és automatikusan az üzleti logikának megfelelően frissíteni az adatbázisokat. Ez még két rendszer esetén is bonyolult fejlesztést igényel mind a webáruház, mind az adatbáziskezelő alkalmazás részén, de vannak olyan esetek is, amikor egy ERP, egy PIM és több webáruház összekötése a feladat.

 

Mit lehet ilyenkor tenni?

 

Első és talán legfontosabb kérdés, hogy mekkora adatmennyiségeket szeretnénk mozgatni? A teljes termékkészletet, termékeket, megrendeléseket és vevői információkat frissíteni akarjuk? Elegendő időszakosan, várólistás (queue) megoldással az adott időszakban éppen aktuális változásokat frissíteni? Azonnal frissíteni kell minden változást a rendszerek adatbázisai között?

A fenti kérdések mind-mind kulcsfontosságúak, hogy meghatározzuk, milyen szintű integrációra van szükség. Egy sekély integrációnál lehet, hogy elegendő egy napi csv/xml állomány alapú importálás a külső rendszerből a webáruházba, akár ezt automatizálva futtatni. Közepes szintű bonyolultság a várakozó listás megoldás, ahol egyik vagy másik oldal is egy sor-szervert használ a frissítésre. A mély integrációnál pedig már akár köztes rétegben történik az adatok szinkronizációja.

Az alább felsoroljuk a különbségeket az egyes módszerek között, röviden ismertetve, hogy melyik mivel járhat és mennyire komplex a fejlesztési listában.

 

1.1. Teljes adatok cseréje

Az adat mennyiségek mozgatása és frissítése szempontjából a teljes adatok cseréje az úgynevezett fapados megoldás. A termékek, megrendelések mennyisége fontos szempont ebben az esetben, mivel több tízezer termék esetén az ilyen frissítés már akár percekig is eltarthat, ami kiesést vagy termék elérhetetlenséget jelenthet a webáruházban. Éppen emiatt csak abban az esetben javasoljuk ezt a megoldást, ha a termékek vagy készlet információk frissítése viszonylag rövid ideig tart vagy jól időzíthetően az áruház forgalmához az esetlegesen elhúzódó frissítés.

 

1.2. Részleges adatok csere

A részlegesadat-kommunikáció akkor jöhet szóba, ha többször az áruház működése alatt is frissíteni kell a termék-, készlet- vagy rendelési információkat. Az időzített megoldások mellett, melyek pontatlansága okozhat problémát az azonnali szinkronizáció is szóba jöhet, mivel a kisebb mennyiségű adatkommunikáció gyorsan végrehajtódik a rendszerben.

A készletkezelés és az FMCG típusú áruházak integrációs megoldásai pontosan ide tartoznak, mivel nem a teljes termék, csupán a darabszámok változnak.

 

2.1. Adatok áttöltésének iránya: egyirányú, kétirányú

Viszonylag egyszerű kérdés, azonban ha jobban átgondoljunk, további kérdéseket vet fel, ráadásul az integrációs költségek növekedése mellett az adatkommunikáció mennyiségét is jelentősen növelheti.

Egyirányú adatkommunikációról akkor beszélünk, ha van egy kiválasztott (master) rendszer – mondjuk egy ERP –, amelybe minden másik külső rendszer, azaz például a webáruházunk is beküldi az adatokat. A fő rendszer (ERP) pedig feldolgozza és tárolja őket, az ERP-t használó adminisztrátorok pedig a kapott adatok alapján irányítják a vállalati folyamatokat.

Kétirányú kommunikáció esetén mindkét rendszer kommunikál a másikkal és egymástól függően vagy függetlenül megadott interfészeken keresztül küldik el az adatokat. Itt már nincs alá- és fölérendelt szerep, csupán a prioritásokat kell megfelelően meghatározni vagy sorszerverekkel vezényelni a változások kezelését.

Az ERP integráció megtervezéséről ebben a cikkünkben olvashatsz: Magento ERP integráció: hogyan készítsük elő hibák nélkül

 

3.1. Adatok közvetett áttöltése

Az adatok áttöltését lehet közvetetten (manuális vagy ütemezett módon) vagy közvetlen (API interfészeken keresztül) frissítéssel megoldani. Az időszakos áttöltésnél szóba jöhet az emberi beavatkozás, aki az egyik rendszerből átemeli az adatokat a másik rendszerbe.

Ez történhet egyszerű export-import folyamatként, ahol az adatok egy állományba kerülnek mentésre (export), majd ezt az állományt a másik rendszer erre kialakított interfészén keresztül betölti az adatbázisba (import). Ez a folyamat természetesen automatizálható, ha az adott alkalmazás által kimentett adatokat a másik rendszer meghatározott időközönként (pl. cronjob) automatikusan betölti az adatbázisába.

Láthatjuk, hogy ez a módszer még az emberi tényező kivonása mellett is lassú, pontatlan és emiatt nem eredményes az FMCG szempontjából, azonban más esetekben, ahogy tapasztaltuk, elegendő lehet.

3.2. Közvetlen információcsere

Az adatok közvetett áttöltése nem éppen a legjobb megoldás a raktárkészletek kezelésére, hiszen a termékek darabszámának változását érdemes minél pontosabban szinkronizálni, így a közvetlen információcsere lehet a kézenfekvő megoldás. Ahhoz, hogy ez megvalósuljon, sokféle technológia áll a rendelkezésünkre, a Magento beépített XmlConnect, API (SOAP vagy REST) megoldásai mellett a legtöbb külső alkalmazáshoz már kész modulokat vásárolhatunk a Magento Connect-ből.

Kétségkívül az egyik legjobb megoldás, hiszen az adatok szinkronizálása azonnal, a változások bekövetkezésekor megindul, azonban, ha speciális külső alkalmazásunk van, melyhez még nincs konnektor (Magento modul), akkor az integrációs költségek jelentősen megugranak. Ne feledjük el, hogy az automatikus, azonnali megoldásokhoz az esetek nagyobb hányadában mélyintegrációra van szükség, mely a korábban leírtak szerint mind időben, mind fejlesztési költségekben nagy.

 

3.3. Automatikus vagy kézi szinkronizáció

Az előzőekben már szóba került, hogy emberi erőforrásokkal is megoldható az adatok szinkronizálása az alkalmazásaink között és ennek automatizálása is megoldható, azonban ezek az időszakos adatkommunikációk meglehetősen megnehezítik a készletek szinkronizációját. Automatikus szinkronizáció alatt itt azt az időzített feladatot értjük (pl.: cronjob), amikor a folyamatot a rendszer indítja, de helyette akár egy ember is meg tudja oldani. Ezek a jelentősen olcsóbb megoldások.

 

3.4. Aszinkron, azonnali megoldások

Az aszinkron megoldásokkal jelentősen gördülékenyebbé tehetjük a készlet- és adatszinkronizációt az alkalmazásaink között. A végtelenségig azonban még így sem lehet egyszerűsíteni a folyamatokat, hiszen az üzleti igények kötött függőségei miatt az aszinkronitás csak bizonyos feladatok vagy részfolyamatok esetén vezethet hasznos eredményre. Az azonnali adatkommunikáció pedig pontosan ugyanezen függőségek miatt nem valósítható meg 100%-osan.

A legjobb, legtisztább és egyben a legbonyolultabb megoldások közé tartozik, jelentős fejlesztési idővel és költségekkel, így ezt csak akkor érdemes választanunk, ha valóban indokolt a webáruházaink esetén.

 

Köztes réteg: Middleware, MOM

A köztes réteg (middleware), mint megoldás a készlet- és adatkommunikáció szinkronizációja az egyik leginkább fejlődő és jelenleg a legmodernebb technológiai megoldás, mind hardver, mind szoftver téren. Egy olyan megoldásról (szoftver és hardver) beszélünk, mely az alkalmazásaink közé ékelődve külső beavatkozás nélkül, az előre meghatározott üzleti logika alapján megvalósítja az adatkommunikációt.

 

magento külső adatbázis middleware

 

Tulajdonképpen egy félig intelligens rendszer, melyen keresztül az adatok áramlanak és eljutnak egyik alkalmazásunkból a másikba, attól függően, hogy éppen mely üzleti folyamat, mely részén tartanak.

Tekinthetünk úgy rá, mint egy hatalmas labirintusra, melynek egyes ki- és bejáratainál az alkalmazásaink találhatóak és az adatok a labirintuson keresztül jutnak el a másik alkalmazás kapujához, hogy közben a falakon lévő szabályokat követik. Az áthaladás közben az adatok átalakulnak a kívánt formátumba és a fogadó félnek megfelelő adatstruktúrát veszik fel, így nincs szükség alkalmazásainkban az adatok transzformálására.

Ezek a köztes szoftverek külön szerverekből állnak, olyan kiegészítő technológiákkal, mint az Üzenetorientált köztesréteg (Message Oriented Middleware), Redis memória alapú gyorsítótár és egyéb szoftveres és hardveres megoldások a köztes réteg támogatására. A köztes rétegek ma már a felhőben helyezkednek el, memória-alapú szervereken, melyek API interfészei a legtöbb webáruházhoz illeszkednek. A piacon már elérhetőek kész megoldások, melyekkel könnyedén integrálhatjuk rendszereinket és összehangolhatjuk a folyamatainkat az egyes rendszerekben.

Ezek a megoldások az általános üzleti folyamatokra épülnek, és többé-kevésbé személyre szabhatóak, azaz jól illeszkednek az általános, nem speciális üzleti igényeket kiszolgáló webáruházakhoz. Vegyük azonban figyelembe, hogy ha az üzleti folyamataink speciálisak és eltérnek az adott alkalmazás általános üzleti folyamataitól, akkor az integráció is egyedileg, személyre szabottan fog ideálisan működni.

 

magento external databases connection fmcg infographics

Konklúzió

Az FMCG kezelésére rengeteg megoldás létezik és ezekből a számunkra megfelelő megoldásokat kiválasztva egy olyan optimális rendszert építhetünk fel, mely kiszolgálja Magento webáruházunkat. A döntés szempontjából fontos kritériumokat a fentiek alapján meg tudjuk határozni, így ki tudjuk választani a kézenfekvő megoldást.

Ne feledjük el azonban, hogy a hosszú távú célok és az adott piaci szegmens ismerete nélkül, ha a legegyszerűbb és (nem biztos, hogy) a legolcsóbb megoldás választjuk, könnyen megeshet, hogy az integrációs költségeket többször is meg kell majd fizetnünk.

Ha bizonytalan a döntésben, írjon nekünk vagy hagyjon kommentet, és segítünk kiválasztani a megfelelő technológiát és megoldást, ezzel jelentős költségeket megtakarítva cégének.

 

Magento javítócsomagok, patch fájlok – miért fontosak?

Miről lesz szó a cikkben?

  • Mik azok a patch-ek? Milyen fajtáik vannak?
  • Miért fontosak a javítócsomagok?
  • Magento javítócsomagok és fontosságuk
  • Foltok vagy verzió frissítés?
  • Hogyan kell telepíteni Magento 1 és Magento 2 alatt a javítócsomagokat?
  • Javítócsomagok ellenőrzése
  • Telepítsük vagy ne telepítsük?
  • Konklúzió

 

Mik azok a patch-ek (foltok)?

Javítócsomagok: Egy-egy szoftver fejlesztése során gyakran előfordul, hogy a fejlesztőknek soron kívül kell módosításokat eszközölniük. Ilyenkor a szoftvefejlesztők különféle szoftver frissítések segítségével javítják a program kiadása utáni hibákat, hiányzó adatokat, biztonsági réseket, azaz a bug-okat.

 

A javítócsomagok (service packs) tartalmazzák a javított állományok teljes egészét, míg a nyílt forráskódú szoftverek esetén a foltokban (patch) csak az eltéréseket leíró állományokat teszik közzé. A Magento hivatalosan foltokat ad ki a hibák javítására.

 

 

Magento patches emblema

 

A foltok (patch-ek) előnye, hogy valóban csak a változtatásra szoruló kód sorokat módosítják, és egyszerre több, régebbi szoftver verzióval is kompatibilisek lehetnek, hátrányuk viszont, hogy némi plusz szakértelem és gyakorlat szükséges az alkalmazásukhoz.

Éppen emiatt a különbség miatt a javítócsomagok mérete nagyobb lehet, mint az eredeti alkalmazás állományaié, szemben a folttal, ami csak a különbségeket tartalmazza, melyek esetében olyan futtatható állományokról van szó, amelyek automatikusan módosítják az alkalmazás állományait.

Elengedhetetlen feltétel még, hogy a folt és a javítócsomag is csak a megadott verziójú alkalmazáshoz használható, ezt általában feltüntetik a csomag nevében és leírásában is.

 

Miért fontosak a foltok (patch-ek)?

A foltokkal és a  javítócsomagokkal elsősorban az elkészült alkalmazások hibáit, adat hiányait vagy biztonsági réseit javítjuk. Éppen ezért kiemelten fontos, hogy figyelemmel kísérjük az egyes alkalmazások újabb javítócsomagjainak megjelenését, hírlevél, RSS hírcsatorna, közösségi média vagy az alkalmazásba épített értesítő felületen (pl.: adminisztrációs oldal) keresztül. A szoftverfejlesztésben a foltok és  javítócsomagok lehetnek nem hivatalos (unofficial) forrásúak, biztonsági típusúak (security) és kiemelten fontos (hot) javítások.

magento patch folt illusztráció

tips FONTOS: Mindenképpen kötelezően ajánlott telepíteni a biztonsági javításokat, mivel ezek az alkalmazás sebezhetőségének hibáit hivatottak javítani. Ha egy biztonsági javítás megjelenik az alkalmazásunkhoz, akkor azt a lehető leggyorsabban telepíteni kell. Fontos megjegyezni, hogy ezeket a biztonsági javításokat csak megbízható (official) forrásból telepítsük, mivel csökkentenénk az alkalmazás biztonságát más forrásokból származó kártékony foltozással.

A hot (dinamikus szoftver fejlesztés) típusú javításokat az alkalmazás futása közben is telepíthetjük, mivel nem okoznak rendszer hibákat, újraindulást vagy rendszerleállást.

A nem hivatalos forrásból származó javítások, ahogy a nevük is mutatja, nem kereskedelmi javításai egy kereskedelmi alkalmazásnak, amit egy harmadik félen keresztül az eredeti fejlesztő adott ki.

 

magento patches security center biztonság

 

Milyen javítócsomagok jöttek ki és miért fontosak?

A Magento – és általában a legtöbb nagy közösséggel és felhasználói táborral rendelkező e-kereskedelmi szoftvergyártó – értesíti a felhasználóit, ha újabb frissítés vagy verzió került kiadásra. A Magento esetén hírlevél formájában a regisztrált fiókunkon keresztül, valamint az adminisztrációs felületre belépve egy figyelmeztető üzenet formájában is értesülünk ezen megjelenésekről.

 

magento patches message box magento1 üzenet

Figyelmeztető üzenetek Magento 1 adminisztrációs felületen

 

magento patches rendszer üzenet, magento2

Magento 2 adminisztrációs felületen a figyelmeztető üzenetek megjelenése

 

A Community Edition javítócsomagokat a Magento hivatalos oldaláról tölthetjük le a következő lépéseket végrehajtva:

  1. Jelentkezzünk be fiókunkkal a magentocommerce.com/download linken.
  2. Az oldal jobb felső részében kattintsunk a My Account Ha nincs még fiókunk, hozzunk egyet létre a regisztrációval – ez a lépés teljesen ingyenes.
  3. A Magento Community Edition Patches részben válasszuk ki az általunk telepíteni kívánt patch-et.
  4. A listában a patch mellett válasszuk ki a saját CE verzió
  5. Kattintsuk a Download-ra.
  6. Ha készen vagyunk a letöltéssel, következhet a telepítés.

 

Az Enterprise Edition javítócsomagokat szintén a Magento hivatalos oldaláról tölthetjük le a következő lépéseket végrehajtva:

  1. Jelentkezzünk be fiókunkkal a magentocommerce.com/download linken. Az oldal jobb felső részében kattintsunk a My Account linkre.
  2. A bal oldali panelen válasszuk a Downloads
  3. Kattintsunk a Magento Enterprise Edition szövegre a jobb oldali részben.
  4. Kattintsunk a Support Patches-re.
  5. Keressük meg a megfelelő patch-et.
  6. Kattintsunk az általunk használt megfelelő verzió számú letöltésre.
  7. Ha készen vagyunk a letöltéssel, következhet a telepítés.

 

magento patches letöltés panel, Enterprise Edition

Magento EE javítócsomagok gyűjtője

 

Folt vagy verzió frissítés?

A Magento letöltési oldalán feltünteti, hogy egy-egy szoftver verzió milyen foltot tartalmaz, így adott esetben kétféle választásunk is nyílhat a javítások alkalmazására:

  • Folt integrálása
  • A teljes verzió frissítése

 

A legfontosabb tudni, hogy az új verziók a javításokon túl egyéb új és módosított funkciókat is tartalmazhatnak, melyek – különösen nagyobb verzió ugrás esetén – „eltörhetik” a működő webáruházunkat. A biztonsági javításoknál a Magento fejlesztői arra törekednek, hogy a kódot a célnak megfelelően csak a szükséges mértékben módosítsák, így néhány kivételtől eltekintve foltozás után a webáruházunk jó eséllyel ugyanúgy fog működni, mint előtte. Ha a folt mégis visszafelé inkompatibilis hibát tartalmaz, azt a szoftverfejlesztő jelzi az adott foltnál vagy a verzió frissítésnél.

 

Hogyan kell telepíteni a javítócsomagokat Magento 1 alatt?

Mindegyik Magento verziónál adott a lehetőség, hogy a legfrissebb verziót – amely már tartalmazza a korábbi javítócsomagokat is – egyetlen állományként letöltsük a weboldalról és felülírjuk vele a már meglévő Magento verziónkat. Mivel feltételezzük, hogy a fejlesztők a szabályos moduláris kiterjesztéseket használták és a Core állományokat kiterjesztve érintetlenül hagyták, ezért ezzel nem okozhatunk problémát.

Azonban nézzük csak meg a Magento 1.9.2.4 (2016-02-23) telepítőjét: 109.4 MB, 14310 file, a 33.5MB-os ZIP állomány kitömörítése közel 1 percet vesz igénybe! Ha ezeket az állományokat fel szeretnénk másolni a szerverünkre, akkor a kapcsolat sebességétől függően akár fél óráig is eltarthat, ha közben még összehasonlítást is végzünk, akár órákra is emelkedhet ez az idő. Ez pedig közel sem ideális.

A foltok a maguk méretében kicsik (néhány kB-tól a pár száz kB-osig) és csupán a szükséges állományok megfelelő sorait cserélik ki a javított kódra. Ezek a szekvenciális állományok lépésről lépésre hajtják végre a feladatokat és végzik el a foltozást.

Ha ezt a megoldást használjuk, akkor mindenképpen figyeljünk arra, hogy a jelenlegi Magento-nk milyen verzióját használjuk és a hozzá tartozó patch fájlt futtassuk le.

 

# 9. Track patch applying result
echo "Patch was applied/reverted successfully."
ADDITIONAL_INFO=`$SED_BIN -n ""$ADDITIONAL_INFO_LINE"" "$CURRENT_DIR""$BASE_NAME"`
APPLIED_REVERTED_ON_DATE=`date -u +"%F %T UTC"`
APPLIED_REVERTED_PATCH_INFO=`echo -n "$APPLIED_REVERTED_ON_DATE"" | ""$ADDITIONAL_INFO""$REVERTED_PATCH_MARK"`
echo -e "$APPLIED_REVERTED_PATCH_INFO\n$PATCH_APPLY_REVERT_RESULT\n\n" >> "$APPLIED_PATCHES_LIST_FILE"

exit 0


SUPEE-6482 | CE_1.9.2.0 | v1 | | Tue Jul 14 14:17:04 2015 +0300 |

__PATCHFILE_FOLLOWS__
diff --git app/code/core/Mage/Api/Model/Server/Adapter/Soap.php app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
index 0f9a3fa..1ac0d57 100644
--- app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
+++ app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
@@ -233,9 +233,9 @@ class Mage_Api_Model_Server_Adapter_Soap
 : $urlModel->getUrl('*/*/*');
 
 if ( $withAuth ) {
- $phpAuthUser = $this->getController()->getRequest()->getServer('PHP_AUTH_USER', false);
- $phpAuthPw = $this->getController()->getRequest()->getServer('PHP_AUTH_PW', false);
- $scheme = $this->getController()->getRequest()->getScheme();
+ $phpAuthUser = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_USER', false));
+ $phpAuthPw = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_PW', false));
+ $scheme = rawurlencode($this->getController()->getRequest()->getScheme());
 
 if ($phpAuthUser && $phpAuthPw) {
 $wsdlUrl = sprintf("%s://%s:%[email protected]%s", $scheme, $phpAuthUser, $phpAuthPw,
diff --git app/code/core/Mage/Catalog/Model/Product/Api/V2.php app/code/core/Mage/Catalog/Model/Product/Api/V2.php
index ff71ec5..46fc492 100644
--- app/code/core/Mage/Catalog/Model/Product/Api/V2.php
+++ app/code/core/Mage/Catalog/Model/Product/Api/V2.php

 

Példa: SUPEE-6482_CE_1.9.2.0_v1 sh állományból

 

Patch telepítése .sh állományból lépésről lépésre

A következő lépéseket követve tudja telepíteni az.sh kiterjesztésű foltot a Magento-jához – ha a kiterjesztése .patch lenne, akkor először látogasson el a Magento Support-hoz.

 

1) Másolja fel az .sh állományt a Magento telepítés gyökerébe.

sh patch-file-name.sh

 

2) Adja ki a következő parancsot egy olyan felhasználóval, aki képes írni a Magento állományokat.

Ha a folt sikeresen telepítésre került a következőhöz hasonló üzenetet fog kapni:

Patch was applied/reverted successfully.

 

3) A telepítés után vissza kell szereznie a jogosultságait a módosított állományok felett:

A) Keressük meg a webszerver felhasználóját:

ps -o “user group command” -C httpd, apache2

A USER oszlopban szereplő érték lesz a webszerver felhasználója.

B) root felhasználóként adjuk ki a következő parancsot a Magento telepítési gyökér könyvtárban:

chown -R web-server-user-name .

 

Hajtsunk végre minden további instrukciót, amit a Magento Support írt.

 

Patch visszavonása

Ha a foltozás során hiba lépett fel, akkor a következő lépéseket hajtsuk végre és vegyük fel a kapcsolatot a Magento Support-tal:

  1. Lépjen be a Magento telepítés gyökér könyvtárába.
  2. Adja ki a következő parancsot egy olyan felhasználóval, aki képes írni a Magento állományokat:
sh patch-file-name.sh -R

 

Hogyan kell telepíteni a javítócsomagokat Magento 2 alatt?

A Magento 2.0.4 (2016-03-31) telepítője: 224 MB, 41458 file, a 69.4MB-os ZIP állomány kitömörítése kb. 2-3 percet vesz igénybe! Ha ezeket az állományokat fel szeretnénk másolni a szerverünkre, akkor a kapcsolat sebességétől függően akár egy óráig is eltarthat, ha közben még összehasonlítást is végzünk, több órára is megnövekedhet ez az idő. Ez, ahogy az 1.9.2.4-es verziónál is megállapítottuk, nem ideális.

A Magento 2-es verziónál a frissítéseket Composer segítségével vagy a GIT repository-ból tölthetjük le és telepíthetjük parancssorból. Telepítéskor pedig lehetőségünk van rá, hogy egy varázsló segítségével lépésről lépésre haladva frissítsük rendszerünket.

 

Hogyan ellenőrizhető, hogy telepítésre kerültek a javítócsomagok?

Miután a foltok és javítócsomagok telepítése megtörtént, fontos lehet ellenőrizni annak helyességét, erre két módszert is tudunk javasolni:

  1. A http://magereport.com oldalon adjuk meg a Magento webáruházunk URL-jét és részletes elemzést kapunk arról, hogy milyen javítócsomagok vannak telepítve és milyen javításokra van még szükségünk.
  2. Az .sh állományokban szereplő kód részleteket azonosítva ellenőrizhetjük, hogy a kódbázis frissítése megtörtént-e.

 

Miért nem jó, ha nem telepítjük a javítócsomagokat?

A Magento közösség gőzerővel dolgozik azon, hogy Magento webáruházunk megfeleljen minden igénynek és az esetlegesen felmerülő biztonsági hibákat orvosolják. Hiszen, mint minden szoftver esetén, hiába a sok tesztelés, a használat folyamán derülnek ki olyan hibák, amelyek problémákhoz vezetnek.

A javítócsomagok ezeknek a hibáknak a javításaira adnak gyors megoldást, ráadásul a később érkező verziókba ezek már belekerülnek és így egy javított, biztonságosabb verziót telepíthetnek a felhasználók. Ez a folyamat hosszú, hiszen ahogy egyre többen használják a szoftvert, egyre több igény merül fel és egyre jobban kiderülnek azok az apróságok és megvalósítási problémák, melyek az elején még nem jelentkeztek.

 

Nézzünk rá egy egyszerű példát

Magento CE SUPEE-5344 SHOPLIFT BUG PATCH

 

A patch 2015. február 19-én jött ki, Netanel Rubin jelentette, részletes leírása megtalálható a fenti linken. Javításra kerül a CE 1.9.1.1 verzióban és minden korábbi webáruházat érint, valamint az EE verziót is az 1.14.2.0-ás verziószámig.

Ez egy biztonsági folt, amely megakadályozza, hogy az adminisztrációs oldal átirányítási rendszerében szereplő extra paramétert kihasználva valaki adminisztrációs felhasználókat hozzon létre vagy malware-t telepítsen a rendszerbe. A patch hasznosságának értéke 9.1 (kritikus), ami azt jelenti, hogy veszélyben van a webáruházunk, hiszen aki ismeri a sebezhetőséget akár a teljes uralmat átveheti felette!

Ha belegondolunk, hogy mennyi információt lehet az adminisztrációs felületen megszerezni, akkor láthatjuk, hogy ennek a foltnak a telepítése valóban kritikus webáruházunkban.

 

Konklúzió

A webáruházunk egy szoftver, így rendelkezik egy életciklussal, egy fejlődési úttal és sokszor tartalmazhat hibákat, bugokat vagy biztonsági réseket. Ezeket a Magento mögött álló hatalmas közösség gyorsan, pontosan próbálja orvosolni, így azonnal foltokat (patch) vagy javítócsomagokat adnak ki, melyeket mindenképpen érdemes telepíteni. Az újabb verzióban beépítik ezeket a javításokat, így egy megbízhatóbb és stabilabb rendszert kapunk, ha a legújabb verziót használjuk fel.

Fontos azonban, hogy figyelemmel kövessük a megjelenő patch-eket és újabb verziókat – telepítsük is őket azonnal –, mert a biztonsági réseken keresztül rosszindulatú hackerek férhetnek hozzá áruházunk adataihoz vagy vehetik át felette az uralmat. Legyünk naprakészek és ne sajnáljuk az időt, pénzt és energiát, hogy befoltozzuk ezeket a réseket.

 

Vásárlók kezelése Magento adminban (gyakorlati útmutató)

Tartalom

Vásárlók menedzselése

 

Vásárlói lista

Az adminban menjünk a Customers –> Manage Customers menüre.

 

menu kezelés

 

Itt láthatjuk a vásárlók listáját.

A lista elemei (alap esetben, angol nyelven):

  • ID: vásárlói azonosító
  • Name: a vevő teljes neve
  • Email: a vásárló email címe, amivel be tud lépni az áruházba
  • Group: vásárlói csoport
  • Telephone: telefonszám
  • ZIP: irányítószám
  • Country: vevő országa (ha üres, akkor az azért van, mert még nem tartozik hozzá cím)
  • State/Provice: megye
  • Customer Since: mióta vásárló, vagyis a regisztráció időpontja
  • Website: melyik website-hoz tartozik (ez akkor jelenik meg, ha több website-unk van a shopban)
  • Action: műveletek (módosítási gomb)

 

A listában való keresést (szűrést) a következőképp kell elvégezni:

 

grid keresés

 

Be kell írni a keresett szót (számot) a lista tetején levő beviteli mezőkbe, majd a jobb oldalon lévő Search gombra kell kattintani. Sorrendezni a listában szereplő oszlopnevekre kell kattintani (ha van olyan, amire nem lehet kattintani, akkor az nem szűrhető). Ha szeretnénk újból a teljes szűretlen listát látni, akkor a Reset Filter gombot kell megnyomni. A lista felett látjuk a lapozót. Mellette ki tudjuk választani, hogy egy oldalon mennyi vásárlót jelenítsen meg.

Grid lapozó

 

A vásárlói listát ki is tudjuk exportálni csv-ben vagy Excel xml formátumban. Ez a lista tetején, középen található. Ki kell választani az Export to-nál a formátumot, majd az Export gombot kell megnyomni. Itt mindig az aktuális szűrt listát exportálja ki (ha szűretlen a lista, akkor az összes felhasználót). Tömeges műveletekre is van lehetőség, ezeket a jobb oldalon levő Actions lenyílóból tudjuk kiválasztani.

Grid Massactions

 

Ki kell választani a vásárlókat (akikre leszeretnénk futtatni az eseményt) az első oszlopban lévő jelölőnégyzet bekapcsolásával, majd ezután válasszuk ki a műveletet, majd nyomjuk meg a Submit gombot.

 

Vásárló létrehozása

Vásárlók létrehozását a jobb oldalon lévő Add New Customer gombbal kell kezdeni.

A létrehozás első lépésekor csak kettő fület látunk, az Account Information-t és az Addresses-t.

Account Information fülön a következőket kell kitölteni:

Account Information

  • Associate to Website: itt adjuk meg, hogy melyik website-hoz rendeljük a felhasználónkat.
  • Group: itt kell beállítani, hogy melyik vásárlói csoportba tartozzon a felhasználó
  • Prefix: Vásárló név előtag (nem kötelező)
  • First Name: Keresztnév (magyar webáruházakban vezetéknévnek szokták általában használni, ehhez előfeltétel, hogy a fordítási csomagban át legyen írva)
  • Middle Name/Initial: Középső név (nem kötelező)
  • Last Name: Vezetéknév (ugyanúgy, mint a first name-nél, ezt pedig keresztnévnek használják magyar áruházakban)
  • Suffix: név utótag (nem kötelező)
  • Email: email cím, ezzel jelentkezik be a vásárló
  • Date of Birth: születési dátum (nem kötelező)
  • Tax//Vat Number: Adószám (nem kötelező)
  • Gender: a vásárló neme (nem kötelező)
  • Send Welcome Email: ha bekapcsoljuk, akkor üdvözlő emailt küld a vásárló email címére
  • Send From: melyik bolt nézetből küldje ki az emailt (többnyelvű oldalnál használatos)

 

Password Management

  • Password: ide írjuk a jelszót
  • Send Auto-Generated Password bekapcsolásával generálni fog random jelszót, amit el is küld az email címre, ilyenkor a Password mezőt figyelmen kívül hagyja.

új AcInTab

 

Addresses fülön:

Új címet az Add New Address gomra kattintva lehet létrehozni.

Az kitöltendő mezőket ugyanúgy kell kitölteni, mint az account information fülön, e mellet vannak új mezők:

  • Company: cégnév (nem kötelező)
  • Street Address: utca, házszám
  • City: város
  • Country: ország
  • State/Province: megye (nem kötelező)
  • Zip/Postal Code: irányítószám
  • Telephone: ez a címhez tarozó telefonszám
  • Fax: fax (nem kötelező)
  • VAT number: adószám (nem kötelező)

Az űrlap mellett további címet (címeket) tudunk hozzáadni.

A címek listában található kettő jelölőnégyzet, amivel be tudjuk állítani, hogy melyik legyen az alapértelmezett számlázási (Billing) ill. szállítási (Shipping) címünk.

 

Edit CustomerviewTab

 

Ezután mentsük el a felhasználót a Save gombok egyikével.

 

Vásárló adatok áttekintése és módosítása

Vásárló módosításához kattintsunk az Edit gombra. Ekkor a bal oldalon látni fogunk jó pár fület. Mindegyiket leírom, hogy mi található rajtuk, ill. mit tudunk ott módosítani. Az Account Information és Addresses füleken vannak módosítható adatok, a többi valójában információk kijelzése.

 

Customer View

Itt egy általános áttekintő található a felhasználóról.

Personal information:

  • Last logged in: utolsó bejelentkezési dátum (ha Never, akkor még soha nem jelentkezett be)
  • Confirmed email: jóváhagyva az email vagy sem (ez csak akkor érdekes, ha be van állítva, hogy regisztráció után küldjön megerősítései emailt)
  • Account Created on: regisztráció dátuma
  • Account Created in: hol lett létrehozva a vásárló (admin vagy valamelyik bolt nézet lesz itt kiírva)
  • Customer Group: melyik vásárlói csoporthoz tartozik
  • Default Billing Address: ki lesznek írva az alapértelmezett számlázási cím adatai (feltéve, hogy van ilyen)

Sales Statistics: Itt lesz kiírva, hogy mennyi összegben vásárolt a webshopon.

Recent Orders: az 5 legfrissebb rendelést mutatja.

Shopping Cart: itt az aktuális bevásárlókosár tartalmát írja ki.

Wishlist: a vásárló kívánságlistájának a tartalmát mutatja.

 

Edit Customer rendeles Tab

 

Account Information:

Ezt a vásárló létrehozásánál részleteztem.

Addresses:

Ezt a vásárló létrehozásánál részleteztem.

Orders:

Itt találhatók a vásárló által leadott rendelések

Edit Customer WishlistTab

Billing Agreements:

Itt a számlázási megállapodások listája szerepel (ez a funkció lehetővé teszi, hogy bizonyos fizetési módoknál be tudjon állítani adatokat, így megkönnyítve a vásárlást, mivel nem kell mindig újra és újra megadni a fizetési adatokat, ehhez a fizető rendszerrel kell megállapodni (ezt most itt nem részletezném jobban).

Recurring Profiles (Beta):

Ez az előfizetéses vásárlások listája, részletesebben a Magento terméktípusok és termékek beállítása – Minden, amit tudnod kell c. cikkben tárgyaljuk.

Shopping Cart:

A vásárló aktuális kosár tartalma. Itt az admin felhasználó törölni tud a kosárból, a lista jobb oldalán lévő Delete gombbal.

Wishlist:

Itt a felhasználó kívánság listájában szereplő termékek vannak.

 

Edit Customer hirlevel Tab

 

Newsletter:

Itt a kiküldött hírlevelek jelennek meg (feltéve, hogy fel van iratkozva)

 

Edit Customer termék vélemény ProducreviewsTab

 

Product Reviews:

Itt a felhasználó által írt termék vélemények szerepnek (az elfogadott, függő és elutasított is).

Edit Customer termék vélemény-ProducreviewsTab

Product Tags:

Itt jelennek meg a vásárló által írt termék címkék.

Edit Customer ProducttagsTab

Vásárló törlése

Vásárlót törölni lehet a listában a tömeges műveletnél (fentebb van részletezve), vagy a vásárló módosításánál a Delete Customer gombra kattintva. Ebben az esetben a rendeléseknél természetesen minden adat megmarad a vásárlóról (tehát a vásárlásai nem vesznek el).

 

 

Vásárlói csoportok kezelése

Vásárlói csoport lista

Vásárlói csoport listát az adminban a Customers -> Customer Groups menüre kattintva hozhatunk létre.

vásárlók kezelés csoport Group Menu

Itt láthatjuk a vásárlói listát, alapból 4 csoport létezik:

  • General – ez van a legtöbbször használva
  • NOT LOGGED IN – ez akkor van használva és kijelezve, ha engedélyezve van a vendég vásárlás az oldalunkon, és ilyenkor a vendég vásárló ebbe a csoportba kerül.
  • Retailer – kiskereskedő
  • Wholesale – nagykereskedő

 

vásárlók kezelés csoport Group List

Miért vannak vásárlói csoportok, és miért használjuk ezeket?

Azért, mert megtörténik, hogy egy adott vásárlói csoportnak más árazást szeretnénk beállítani, vagy adott csoport kapjon kedvezményeket adott termékekre stb.

 

Vásárlói csoport létrehozása és módosítása

A lista jobb oldalán lévő Add New Customer Group gombra kell kattintani.

Ha módosítani akarunk, akkor kattinstunk a listában lévők valamelyikére.

Az űrlapon megkell adni:

Group Name: a csoport neve (pl. AionHill vásárlók)

Tax class: adóosztály

 

Add Group

 

Vásárlói csoport törlése

Válasszunk ki egy törölni kívánt csoportot a listából, majd nyissuk meg úgy, mint amikor módosítani akarjuk, ezután a jobb oldalon lévő Delete Customer Group gombra kattintva tudjuk törölni a csoportot. Azok a vásárlók, akik ehhez a csoporthoz tartoztak, átkerülnek az alapértelmezett csoportba, ami alap esetben a General.

 

 

Vásárlókhoz tartozó rendszer beállítások kezelése

Menjünk az System –> Configuration menüre.

Ott menjünk a Customers tabon belül a Customer Configuration linkre.

 

kezelés beállítás Settings CustomerConfTab

 

A bal felső sarokban tudjuk állítani, hogy melyik website-hoz, bolthoz vagy bolt nézethez akarjuk a beállításokat elvégezni.

Ott a következőket lehet beállítani:

Online Customers Options

  • Online Minutes Interval: ha üresen hagyjuk, akkor alap 15 percenként frissül a Customers –> Online Customers menüben található lista.

Settings CustomerConfTab Online

Account Sharing Options

  • Share Customer Accounts: itt kell beállítani, hogy a vásárlóink tudjanak-e vásárolni a website-ok között (pl. van 3 website-unk és ha website-ra van állítva ez az érték, akkor mind a 3 website-ra külön-külön kell regisztrálnia, hogy tudjon vásárolni, viszont ha global-ra van állítva, akkor mind a 3 website-on 1 felhasználói fiókjával tud vásárolni).

Settings CustomerConfTab Account

Create New Account Options

  • Enable Automatic Assignment to Customer Group: Engedélyezzük-e, hogy automatikusan a vásárlót egy csoporthoz hozzárendelje. Ha igen-t állítunk, akkor újabb mezők jelennek meg, ahol be kell állítani, hogy az adószám ellenőrzése után milyen vásárlói csoportba kerüljön a felhasználó.
  • Default Group: itt adjuk meg, hogy melyik az alapértelmezett csoport, ide kerül be a felhasználó regisztráció után, illetve ha törli az admin az egyik csoportot, az abban lévő vásárlókat ide teszi át.
  • Default Value for Disable Automatic Group Changes Based on VAT ID: úgy, mint az első beállítás, ez is kapcsolódik az adószám ellenőrzéséhez
  • Show VAT Number on Frontend: Megjelenítsük-e az adószámot a frontenden, ez is kapcsolódik az adószám ellenőrzéséhez
  • Default Email Domain: alapértelmezett küldő email domainje, ez csak akkor van használva, ha az adminisztrátor adminfelületen ad le rendelést és nem tölti ki az email címet.
  • Default Welcome Email: alapértelmezett üdvözlő email sablon
  • Email Sender: email feladó
  • Require Emails Confirmation: Ha igenre állítjuk, akkor regisztráció után emailben kap egy megerősítő linket, amire kattintva lesz aktív a felhasználói fiókja
  • Confirmation Link Email: Megerősítő email sablonja
  • Welcome Email: üdvözlő email sablon
  • Generate Human-Friendly Customer ID: ha igenre van állítva, akkor szebb azonosítót generál a felhasználóhoz. Ezt általában egyedi fejlesztésekhez érdemes használni.

CustomerConfTab CreateNew

Password Options

  • Forgot Email Template: elfelejtett jelszó email sablonja
  • Remind Email Template: ez az admin felhasználó által módosított jelszó emlékeztető, amit kiküld a vásárlónak
  • Forgot and Reminder Email sender: a kettő fenti pont küldője
  • Recovery Link Expirateion Period: elfelejtett jelszóban kiküldött jelszó változtató link érvényességi ideje napokban kifejezve.
  • Require admin user to change user password: ha igenre van állítva, akkor ha módosítani szeretnénk adminban a vásárló jelszavát, akkor meg kell adni a mi (admin) jelszavunkat.

Settings CustomerConfTab Password

Name and Address Options

  • Number of Lines in a Street Address: hány sort mutasson a cím bevitelekor
  • Show Prefix: kijelezze-e (és regisztrációkor bekérje-e) a név előtagot (optional = nem kötelező, required = kötelező megadni)
  • Prefix Dropdown Options: pontos vesszővel elválasztva fel kell sorolni az név előtag választási opciókat (pl. dr;mr),ha üresen hagyjuk, akkor a felhasználó fogja beírni.
  • Show Middle Name (initial): kijelezze-e a középső nevet, igen-re állítva megadhatja, de nem kötelező
  • Show Suffix: kijelezze-e a név utótagot
  • Suffix Dropdown Options: ugyanaz, mint a Prefix Dropdown Options-nál csak az útótagra vonatkozik
  • Show Date of Birth: kijelezze-e a születési dátumot
  • Show Tax/VAT Number: kijelezze-e az adószámot
  • Show Gender: kijelezze-e a vásárló nemét

név és cím

Login Options

  • Redirect Customer to Account Dashboard after Logging in: bejelentkezés után átirányítsa-e a felhasználót a vásárlói irányítópulthoz

Settings CustomerConfTab Login

Address Templates

  • Text: cím sablon szöveg, ami az emailekben, nyomtatott nézetekben jelenik meg.
  • Text One Line: ez a sablonszöveg a rendelési folyamatban jelenik meg
  • HTML: ez több helyen is megjelenik (adminban a rendeleseknél, adminban a vásárló módosításánál, frontenden a vásárló címjegyzékében)
  • PDF: ez a számlázási, szállítási és jóváírási pdf-ben jelenik meg
  • Javascript Template: js templatekben (adminban, amikor új címet adunk hozzá a vásárlóhoz)

Settings CustomerConfTab Address

CAPTCHA

  1. Enable CAPTCHA on Frontend: engedélyezzük-e a biztonsági kódot, ha igen akkor a következő mezők jelennek meg:
    • Font: betűtípus
    • Forms: válasszuk ki, hogy melyik űrlapokban jelenjen meg
      • Create User: regisztrációkor
      • Login: bejelentkezéskor
      • Forgot password: elfelejtett jelszónál
      • Checkout as Guest: vásárlás vendégként résznél
      • Register during Checkout: vásárlás közbeni regisztrációnál
    • Displaying Mode: kijelzés típusa, vagyis hogy mikor jelenjen meg a CAPTCHA
      • Always: állandóan
      • After number of attempts to login: több sikertelen bejelentkezés után, ha ezt az opciót választjuk, akkor a következő mező jelenik meg:
        • Number of Unsuccesfill Attempts: hány próbálkozás után jelenjen meg, ha 0-t írunk be, akkor állandóan megjelenik

 

  • CAPTCHA Timeout (minutes): kód lejáratának ideje, percben kifejezve
  • Number of Symbols: hány karakterből álljon a kód (pl. 4-5 = ilyenkor 4 vagy 5 karakter lesz)
  • Symbols Used in CAPTCHA: milyen szimbólumok legyenek használva (Ide soroljuk fel a karaktereket, amikből szeretnék, hogy generálja a kódot a rendszer. Használhatjuk az a-tól z-ig (nagy betűket is) és 0-9 számokat (pl. ABCDEFGHJKMnpqrstuvwxyz23456789)
  • Case Sensitive: kis-nagybetű érzékeny, ha igen, akkor pontosan ugyanazt a kódot kell beírnunk, mint amit generál (pl. AaY1, ha nem-re van állítva, akkor ebben a példában elfogadja az aay1 kódot).

Settings CustomerConfTab Captcha

 

Vásárlói adó osztályok kezelése

Első lépésként menjünk az adminban a Sales –> Tax -> Customer Tax Classes menüre.

CustomerTax Menu

Itt láthatjuk a meglévő vásárlói adóosztályokat, alap esetben egy darab van benne, méghozzá a Retail Customer.

Új vásárlói adóosztály létrehozásához menjünk a jobb oldalon lévő Add New gombra.

Az űrlap nagyon egyszerű, csak meg kell adni az osztály nevét, és utána elmenteni.

CustomerTax CreateTaxClass

Felmerül a kérdés, hogy ezt hol használjuk?

A vásárlói csoportoknál megadhatjuk, hogy az adott csoport melyik vásárlói adóosztályhoz tartozzon. Miért hasznos?

Azért, mert ahány ország annyi adószabály (sőt pl. Amerikában államonként is eltér).

Az adószabályoknál pedig beállítjuk, hogy az adott szabály melyik vásárlói csoportra érvényes.

Ehhez a Sales –> Tax -> Manage Tax Rules menüre kell kattintani.

Ahol létrehozunk, vagy módosítunk egy adott szabályt, majd ott beállítjuk, hogy melyik vásárlói csoportra vagy csoportokra érvényes.

CustomerTax TaxRulesEdit

Megj.: Ebben a részben nem részletezem tovább az adó kezelést, mert túl hosszú lenne. Ebben a témában külön cikket publikálunk majd.

 

Vásárlói vélemények és címkék kezelése

 

Vásárlói vélemények

A vásárlói véleményeket három helyen lehet megtalálni:

  1. Catalog -> Review and Ratings -> Customer Reviews -> All Reviews

Itt megtalálható az összes vélemény

  1. Catalog -> Review and Ratings -> Customer Reviews -> Pending Reviews

Itt megtalálható az összes el nem fogadott vélemény

  1. Customers -> Manage Customers -> Edit

Valamelyik felhasználót módosítva a Product Reviews fülön, az adott felhasználó által írt véleményeket találjuk.

Hogyan fogadjuk el a véleményeket?

A fentebb említett menük egyikén (ha nem tudjuk, melyik felhasználó írta, akkor ajánlott a második pontban található menüre menni).

Itt láthatjuk a nem elfogadott (Pending) véleményeket.

Ha többet szeretnénk egyszerre elfogadni, akkor a bal oldalon ki kell választani a jelölőnégyzet segítségével a véleményeket, majd a jobb oldali Actions lenyílóból válasszuk az Update Status-t, és állítsuk Approved-ra (illetve amilyen állapotra szeretnénk, Approved – elfogadott, Pending – várakozik, Not Approved – letiltott).

CustomerReview PedingReviews MassUpdate

Ha egyesével szeretnénk módosítani (Elfogadni stb.), akkor az Edit linkre kell menni, majd a Statust a megfelelőre kell állítani, és elmenteni. Itt át is írhatjuk a hozzászóló nevét, véleményét.

CustomerReview PedingReviews Edit

Vásárló által címkézett termékek

Ezt is ugyanúgy, mint a véleményeket, több helyen lehet megtalálni

  1. Catalog -> Tags -> All Tags

Itt megtalálható az összes címke

  1. Catalog -> Tags -> Pending Tags

Itt megtalálható az összes el nem fogadott címke

  1. Customers -> Manage Customers -> Edit

Valamelyik felhasználót módosítva a Product Tags fülön, az adott felhasználó által írt címkéket találjuk.

Hogyan fogadjuk el a címkéket?

Ugyanúgy kell, mint a véleményeket (fentebb kifejtve).

Ha egyesével szeretnénk módosítani (Elfogadni stb.), akkor kattintsunk a címke sorára, majd a Statust a megfelelőre kell állítani és elmenteni. Itt át is írhatjuk a címkét, megnézhetjük, hogy melyik termékre lett rátéve (admin és vásárló által), mely felhasználók tették rá.

33-vasarlok_kezeles-CustomerTags_Edit_Tag

Ezt a címke módosító űrlapot a felhasználó módosításánál a Product Tags részből is el lehet érni.

 

Vásárlókhoz tartozó jelentések kezelése

A vásárlói jelentések a következő helyen találhatók meg:

Reports –> Customers menüben almenüként:

  1. New Accounts: új vásárlók száma az adott időszakra
  2. Customers by orders total: vásárlók az adott időszakra vonatkozó összesített rendelési összege
  3. Customers by number of orders: vásárlók az adott időszakra vonatkozó összesített rendelési darabszáma (vagyis, hogy hányszor vásárolt, ez nagyon hasonló, mint a 2-es pont)

CustomerReport Menu

Mind a 3-nál ugyanúgy kell frissíteni az adatokat.

Hogyan kell lekérni (frissíteni) a jelentéseket?

Első lépésként válasszuk ki az egyik menüpontot.

Az adott oldalon ki kell választani (vagy beírni):

  • From: mettől kezdve (dátum)
  • To: meddig
  • Show By:
    • Day – napokra szétbontva
    • Months –havonta szétbontva
    • Year – évente szétbontva
tips Itt egy példa:

Kiválasztottam a New Accounts menüpontot. Majd ott beírtam, hogy 01/1/2016-tól, 03/31/2016-ig, és havi bontásban mutassa. Ezután a Refresh gombot kell megnyomni. Eredmény:

35CustomerReport NewAccountReport

Láthatjuk, hogy januári és februári hónapra nem volt új vásárló, viszont a márciusira már 5 felhasználó van.

 

Ezzel be is fejeztem a vásárlói funkciók adminban való bemutatását. Remélem, tudsz belőle meríteni saját webáruházad fejlesztéséhez, hatékonyabb működéséhez. Kérdéseidet, észrevételeidet kommentben megadhatod, illetve egyéb magento-val kapcsolatos információért is felkereshetsz bennünket.

 

Magento terméktípusok és termékek beállítása – Minden, amit tudnod kell

Milyen terméktípusok vannak a Magento-ban?

 

A Magento-ban 6-féle terméktípus van:

  • Egyszerű termék (Simple product)
  • Konfigurálható termék (Configurable product)
  • Csoportos termék (Grouped product)
  • Kötegelt termék (Bundle product)
  • Virtuális termék (Virtual product)
  • Letölthető termék (Downloadable product)

 

 

Mire jók a különböző termék típusok?

 

Egyszerű termék:
Ez a legegyszerűbb terméktípus, általában ez van legtöbbször használva. Ezek a termékek azért egyszerű termékek, mert olyan tulajdonságokkal rendelkeznek, amelyek egyedivé teszik őket, pl. társasjáték, tévé, festmény.

Ezek a termékek eladhatók önmagukban vagy csoportos, konfigurálható, kötegelt termék részeként.

 

Példa:

Az alábbi képen egy fekete sapka látható, ahol a vásároló nem tudja kiválasztani, hogy milyen színben szeretné.

Abban az esetben, ha a termék több színben is elérhető, és szeretnénk, hogy a termék adatlapján ki tudja választani a vásárló a színt, akkor konfigurálható termékként kell létrehozni.

Magento egyszerű termék

 

Konfigurálható termék:
Ezek a termékek (pl. cipő, póló) változtatható jellemzővel rendelkeznek (pl. szín, méret).

 

Példa:

A képen látható cipőt a vásárló többféle színben (pl. kék, fekete) és méretben (pl. 39, 40, 41) megvásárolhatja.

 

Konfigurálható termék

 

A konfigurálható termékek több egyszerű termékből állnak.

Tegyük fel, hogy van egy konfigurálható termékünk, ami 2 színben és 3 méretben választható, akkor valójában 6 egyszerű terméket hoztunk létre (ezeket az egyszerű termékeket általában nem jelenítjük meg az áruházban, vagyis önmagukban nem láthatók), és 1 darab konfigurálhatót, ami ezt a 6 termékek öleli fel.

 

Csoportos termék:
A csoportos termék hasonló, mint a konfigurálható. E típusnál a felhasználó kiválaszthatja, hogy a csoportos termék tételeiből (termékekből) mit vesz meg és mit nem, illetve, hogy az egyes tételekből hány darabot vesz meg, pl. kés szett, ágynemű stb.

 

Példa:

A képen látható hálószoba-garnitúrát, amiben több egyszerű termék van, külön termékenként is meg lehet vásárolni, de így a vásárlónak felkínáljuk, hogy több hasonló vagy egymáshoz tartozó termékeket meg tud könnyebben, keresgélés nélkül venni.

 

Magento Csoportos termék

 

Kötegelt termék:
A kötegelt termékeknél a vásárló testre szabhatja, hogy ténylegesen milyen résztermékekből álljon a vásárolni kívánt termék.

Alább egy fényképezőgép látható, amihez résztermékeket vásárolhatunk, mint pl. objektív vagy nyakpánt.

A kötegelt termékek résztermékei lehetnek egyszerű és virtuális termékek is.

 

Magento Kötegelt termék

Virtuális termék:
Ezeknek a termékeknek nincs fizikai vagy letölthető formája, nem szállíthatók (mivel nincs mit szállítani). Általában ezek különféle szolgáltatások, pl. előfizetés licenc stb.

A virtuális termék adatlapja ugyanolyan, mit az egyszerű terméké, csak a vásárlási folyamatban nem kell megadnunk szállítási címet.

Példánkban egy VIP-tagságot mint virtuális terméket láthatunk.

 

 

 

 

Magento virtuális termék

 

Letölthető termék:
Ezeknek a termékeknek nincs fizikai, csakis letölthető formája, pl. szoftver, e-könyv letöltése.

A képen egy BMW autónak a használati útmutatóját lehet megvásárolni, ami egy letölthető PDF dokumentum.

 

Magento letölthető termék

 

 

Miután a felhasználó megvásárolta és kifizette, kap egy e-mail-t, amely tartalmazza a letöltési linket, de ha belép a webáruházba a „My downloadable products” vagyis a „Letölthető termékeim” menüben ugyanúgy megtalálja a terméket, és onnan is le tudja tölteni.

 

Hogyan hozható létre egy adott terméktípus?

 

Egyszerű termék (Simple product)

Egyszerű terméket egyszerű létrehozni!

  1. Lépjünk be az adminba, majd ott a Catalog –> Manage Products menüre menjünk.
  2. Ott menjünk a jobb oldalon lévő Add Product menüre.
  3. Termék létrehozás első részénél
    1. Válasszuk ki az Attribute Set-et (Jellemzőcsoportot)
    2. Válasszuk ki a Product Type-nál a Simple Product-ot, majd nyomjuk meg a Continue gombot

Magento egyszerű termék beallitás

 

  1. Ezután egy új űrlapot kapunk, ahol már a termék konkrét adatait kell megadni.

Lényeges, hogy ha több webáruházunk, boltunk, boltnézetünk van, azok saját beállításait úgy tudjuk elérni, ill. módosítani, hogy a bal oldalon fent lévő Choose Store View lenyíló menüben átváltunk a kívánt boltnézetre.

Megjegyzés: az egyszerű terméknél írom le az összes szükséges beállítást, a többi típusnál csak a változásokat.

 

A General tabot töltsük ki a következőképp:

Name: Írjuk be a termék nevét, ezen a néven fog mindenhol szerepelni

Description: a termék hosszú leírása. Ez a termékadatlapon fog megjelenni.

Short Description: a rövid leírás, ez a listákban fog megjelenni.

SKU: cikkszám, ide egyedi azonosítót írjunk be.

Weight: a termék súlya, ez a szállítási számításokhoz kell (feltéve, ha van olyan a szállítónk, aki figyelembe veszi a súlyt).

Set Product as New from Date: ez az újszerű termék kezdő időpontja (nem kötelező).

Set Product as New to Date: ez az újszerű termék végső időpontja (nem kötelező).

Status: ha szeretnénk engedélyezni, akkor állítsuk „Enabled”-re.

URL Key: URL kulcs, ha üresen hagyjuk, akkor a termék nevéből automatikusan legenerálódik.

Visibility: Ha szeretnénk, hogy a termékünk mindenhol megjelenjen, akkor állítsuk „Catalog, Search”-re. A „Not visible individually” azt jelenti, hogy önmagában nem látható az oldalon, ez a kötegelt, illetve a konfigurálható termékeknél lényeges.

Country of Manufacture: gyártó ország (nem kötelező, ritkán használjuk).

Size: méret (nem kötelező).

Color: szín (nem kötelező).

 

Magento egyszerű termék beállítás general

 

Prices fül

Price: ide írjuk be a termék árát.

Group Price: ide tudjuk felvinni a vásárlói csoportos árakat (nem kötelező).

Special Price: akciós ár (nem kötelező).

Special Price From Date: akciós ár kezdete (nem kötelező).

Special Price To Date: akciós ár vége (nem kötelező).

Tier Price: Itt beállíthatjuk, hogy bizonyos mennyiség kosárba rakása után mennyi legyen a termék ára, külön állítható be vásárlói csoportokra és website-okra, Pl. 1 termék ára 1000 Ft, de ha 10 darabot vagy többet vesz, a darabonkénti ár csak 800 Ft, vagyis ha 10 darabot vesz, összesen nem 10 000 Ft-ba, hanem csak 8000 Ft-ba kerül.

Apply MAP: minimális hirdetett ár érvényesítése erre a termékre.

Display Actual Price: hol jelenítse meg az aktuális árat.

Manufacturers Suggested Retail Price: gyártó által ajánlott kiskereskedelmi ár.

Tax Class: válasszuk ki az adóosztályt.

 

Magento egyszerű termék beállítás prices

 

Meta Information

Ezek a részek keresőoptimalizálási szempontból fontosak.

  1. Meta Title: ez lesz a böngészőben a Title elem. Ha üresen hagyjuk, a böngésző Title a termék neve lesz.
  2. Meta Kerywords: ezek lesznek a meta kulcsszavak, ha üresen hagyjuk, a termék neve fog bekerülni.
  3. Meta Description: ez lesz a meta leírás, ha üresen hagyjuk, szintén a termék neve fog ide kerülni.

 

Magento egyszerű termék beállítás meta information

 

Images

Itt kell feltölteni a termékhez tartozó képeket. Ki kell választani a Browse Files gombbal a képeket, majd az Upload Files gombbal pedig feltölteni. Miután feltöltöttük, ki kell választani, hogy

  • melyik kép legyen az alap kép, ami a termék adatlapon jelenik meg (Base Image),
  • melyik legyen a kis kép, ami a termék listákban jelenik meg (Small Image),
  • melyik legyen a bélyegkép ami a termék adatlapon a galériában a kiválasztásnál jelenik meg (Thumbnail).

 

Be lehet még állítani a képeknek a Label-t is, ami a termék kép Title-je lesz. Az exclude jelölőnégyzettel meg tudjuk adni, hogy melyik képet nem szeretnénk megjeleníteni (ez akkor jó, ha nem akarjuk törölni a képet, csak pl. ideiglenesen kikapcsolni). A remove értelemszerűen kitörli a kiválasztott képet mentés után.

 

Magento egyszerű termék beállítás images

 

Recurring Profile

Ismétlődő profilok ‒ leggyakrabban előfizetésekre vagy termék részletre való vásárlására használják. Amikor a vásárló ilyen terméket vesz, azt csak PayPal-lel tudja kifizetni (be kell állítani és engedélyezni a PayPal-os fizetést).

 

Példa:

Van egy újság, amire előfizettünk, és havonta történik a fizetés, vagyis havonta 1-szer fizetünk.

 

Beállítások:

Enable Recurring Profile: állítsuk IGEN-re, ha engedélyezni akarjuk.

 

Schedule

Customer Can Define Start Date: engedélyezzük-e, hogy a vásárló megadja a kezdeti dátumot.

Scedule Description: rövid leírás, ez a fizetés utáni „sikeres vásárlás” oldalon jelenik meg.

Maximum Payment Failures: hány sikertelen fizetés után legyen felfüggesztve.

Auto Bill on Next Cycle: Állítsuk IGEN-re, ha szeretnénk, hogy automatikusan kezdeményezze az elmaradt (sikertelen) fizetést a következő számlázási ciklusra.

Példa: a fizetés napján nem volt elég pénz a számlánkon (PayPal), tehát fel lett függesztve a fizetés, de később tettünk elég pénzt a számlánkra és így a következő fizetéskor az elmaradt pénzt is kifizeti, ha IGEN-re van állítva.

 

Billing

Billing Period Unit: Állítsuk be a számlázási időszakot (hetente, havonta stb.)

Billing Frequency: Számlázási sűrűség egy ciklusra vetítve.

Maximum Billing Cycles: Maximum hány kör, vagyis hányszor legyen számlázva (ha üresen hagyjuk, akkor végtelen számú kör /ciklus/ történik).

Példa: Legyen egy újság, aminek az ára legyen 1000, a Billing Period Unit legyen hetente, Billing Frequency legyen 3, Maximum Billing Cycles legyen 5.

Ez azt jelenti, hogy 3 hetente történik a fizetés, és összesen 5 alkalommal, vagyis 3 hetente fizetünk ki 1000-et, összesen 5000-et költünk el.

 

Trial Period

A Trial period beállításait ugyanúgy kell elvégezni, mint a Billing résznél, azonban itt van egy Trial Billing Amount, ami a próbaidőszak alatti ár.

Példa: Tegyük fel, hogy kiadunk egy új magazint, ami a vásárlók számára még teljesen ismeretlen. Valószínű, hogy nem lesz sok érdeklődő, ezért érdemes „Bevezető” időszakot indítani, kedvezményes, bevezető áron árulni az adott terméket, majd miután lejár ez az időszak, az eredeti áron lehet kínálni.

 

Initial Fees

Initial Fee: Első alkalommal kell ezt a „kezdeti díjat” kifizetni ‒ feltéve, ha beállítjuk.

Allow Initial Fee Failure: IGEN-re állítva megszakítja az előfizetést, ha nem sikerül kifizetni a kezdeti egyszeri összeget. Ha NEM-re van állítva, és nem sikerül a kezdeti összeg kifizetése, akkor a következő alkalommal, mikor már van elég pénz, kerül kifizetésre ez az összeg.

 

Magento egyszerű termék recurring profile beállítás

 

Design

Itt lehet beállítani, hogy az adott termék milyen egyedi témával / sablonnal jelenjen meg.

Custom Design: itt választhatjuk ki a design csomagot.

Active From: Az egyedi kinézet mikortól legyen aktív (ha üresen hagyjuk, akkor a beállítás napjától, vagyis figyelmen kívül hagyja ez az opciót).

Active To: Az egyedi kinézet vége (ha üres, végtelen ideig marad, ha bizonyos dátumot állítunk be, akkor annak lejárta után visszaáll az eredetire).

Custom Layout Update: Egyedi Layout xml módosítás (Programozói tudás szükséges hozzá!)

Page Layout: Oldal elrendezés módosítás (pl. a jelenlegi 1 oszlopos, de szeretnénk 2 oszloposra módosítani).

Display Product Options In: Termék kiválasztható opcióit hol jelenítse meg (olyan terméknél érdekes, amelyiknek vannak választható opciói, pl. konfigurálható, kötegelt). A Product Info column a termék ára alatt szokott megjelenni a kép mellett, jobb oldalt, a Block after info column pedig az egész infó blokk alatt, vagyis a kép alatt általában.

 

Magento egyszerű termék design beállítás

 

Gift Options

Itt engedélyezni tudjuk, hogy vásárláskor a felhasználó meg tudjon adni ajándék üzenetet. Ha IGEN-re van állítva, a vásárlás közben bekéri a felhasználótól az ajándék üzenetet (kitől, kinek, üzenet). A rendszer beállításoknál be lehet állítani, hogy termékenként is lehessen egyedi üzenetet megadni, és az egész rendelésre.

 

Magento egyszerű termék gift options beállítás

 

Inventory

Itt lehet beállítani a készletkezelést. Ahol be van kapcsolva a User Config Settings, ott a rendszerbeállításokból veszi az értéket.

Manage Stock: Legyen-e engedélyezve a készletkezelés erre a termékre

Qty: Mennyi darab van raktáron.

Qty for Item’s Status to Become Out of Stock: Ennyi darab után lesz a termék „Nincs raktáron” állapotban.

Minimum Qty Allowed in Shopping Cart: Minimum vásárolható mennyiség.

Maximum Qty Allowed in Shopping Cart: Maximum vásárolható mennyiség.

Qty Uses Decimals: Mennyiség megadásnál használható-e tizedesjegy, pl. 1,5 liter.

Can be Divided into Multiple Boxes for Shipping: Ez az opció a Qty Uses Decimals IGEN-re állításával jön, itt be lehet állítani, hogy a terméket lehet-e külön dobozban szállítani.

Backorders: Előrendelés. A „No backorders”-nél ha a termék nincs raktáron, nem lehet megvásárolni, az „Allow Qty Below 0”-nál meg lehet vásárolni (előrendelni) a terméket, ha nincs raktáron, „Allow Qty Below 0, and Notify Customer”: ez ugyanaz, mint az Allow Qty Below 0”-nál, csak itt még értesítjük is a vásárlót.

Notify for Quantity Below: Milyen mennyiség alatt készítsen jelentést a termék raktárkészletéről (Ezt az adminban a Reports -> Products -> Low Stock menüben lehet megtekinteni).

Enable Qty Increments: Ha ezt beállítjuk, a felhasználó csak akkor tudja a kosárba rakni a terméket, ha a Qty Increments opcióban beírt mennyiséget teszi bele.

Stock Availability: Van-e raktáron a termék vagy sem. Ha Out of Stock-ra van állítva, akkor nem lehet megvásárolni, még akkor sem, ha engedélyezve van az előrendelés. A Qty és a Stock Availability nem értelmezhető ugyanannak. Sokaknak megtévesztő az, hogy van belőle pl. 3 darab (Qty), de ha a Stock Availability Out of Stockra van állítva, nem lehet megvásárolni.

 

Magento egyszerű termék inventory beállítás

 

Websites

Itt tudjuk beállítani, hogy a termékünk mely webáruházakban jelenjen meg.

 

Magento egyszerű termék websites beállítás

Categories

Itt kell kiválasztani, hogy a termék mely kategóriákban szerepeljen.

 

Magento egyszerű termék categories beállítás

Related Products

Itt tudjuk kiválasztani a megadott termékhez hasonló termékeket. Ha a teljes listát szeretnénk látni, nyomjuk meg a jobb oldalon lévő Reset Filter gombot. Ezután válogassuk ki (a jelölőnégyzetet pipáljuk be), hogy mely termékek hasonlóak. Ezek a termékek az aktuális termék adatlapján általában a bal, ill. jobb oldali oldalsávban szerepelnek (de persze ez a dizájntól függhet).

 

Magento egyszerű termék related products beállítás

Up-sells

Ugyanúgy kell beállítani, mint a Related Products részt. Ezek olyan termékek, amelyeket a vevőnek ajánl a webáruház. A termék adatlapján lent jelennek meg.

 

Cross-sells

Ugyanúgy kell beállítani, mint a Related Products részt. Ezek a termékek a kosár oldalon jelennek meg, a célja ennek a funkciónak, hogy a vevőt még vásárlás előtt még több termék vásárlására biztassuk.

 

Product Reviews

Ezen a fülön a termékre érkezett vélemények vannak megjelenítve. A véleményeket az Edit gombra kattintva tudjuk módosítani (pl. elfogadni, vagy esetleg a szövegét kicsit módosítani, törölni).

 

Magento egyszerű termék product reviews beállítás

 

Product Tags

Itt jelennek meg a termékre „akasztott” címkék. A termékre címkéket a bejelentkezett vásárló tud tenni a termék adatlapján, és ezt követően ott is jelennek meg az elfogadott címkék.

Az újonnan érkezett (tehát nem elfogadott) címkéket elfogadni, módosítani az adminban a Catalog -> Tags -> Pending tags menüben lehet.

 

Magento egyszerű termék beállítás product tags

 

Customer Tagged Product

Itt azon vásárlók listája jelenik meg, akik erre a termékre akasztottak címkét.

 

Magento egyszerű termék beállítás customer tagged product

 

Custom Options

Ezek a termék egyedi opciói, valamelyes hasonlítanak a konfigurálható termék opcióihoz.

Ez az egyedi opciós beállítás lehetőségét nyújtja számunkra ‒ egyedi választható opciókat hozhatunk létre, kikerülve a jellemzők létrehozását, ill. használatát.

 

Példa:

Vegyük a korábban mutatott fekete sapka példáját! Azt szeretnénk, hogy a sapkára lehessen nyomtatni valamilyen matricát, logót stb., ekkor a következőképp kell a beállításokat elvégezni:

Add New Option gombra kel kattintani, majd ott a Title mezőbe be kell írni az opció nevét, pl. Matrica nyomtatás, majd az Input Type-nál ki kell választani, milyen típusú legyen az opció. Az Is Required azt jeleni, hogy kötelező legyen-e kitölteni ezt a részt, a Sort Order segítségével a sorrendezést végezhetjük el.

 

Text – Field: egyszerű szöveges mező, amit a vásárló tölt ki, pl. „BMW emblémát szeretnék”, a Price mezőbe írjuk be, hogy a termék eredeti árához képest mennyivel lesz drágább, a Price Type arra vonatkozik, hogy fix árral vagy százalékkal lesz több, az SKU-hoz az esetleges egyedi cikkszámot beírhatjuk, a Max Charachers-hez pedig, hogy maximum mennyi karaktert írhat be a vásárló.

 

Text – Area: szöveges mező, ide hosszabb szöveget is beírhat a vásárló. A további beállításai ugyanazok, mint a Text – Field-nél.

 

File – File: valamilyen fájlt feltölthet, pl. feltölti a BMW emblémát.

A további beállításoknál az Allowed File Extensions-be vesszővel vagy üres hellyel elválasztva írjuk be az engedélyezett kiterjesztéseket, pl. jpg, gif, png.

A Maximum Image Size-hoz írjuk be, hogy maximum mekkora képeket tölthet fel. Ha a fájl nem kép, hagyjuk a mezőt üresen.

 

Select – Drop-down: lenyíló menü, ilyenkor az adminisztrátor fogja kitölteni a felkínált lehetőségeket (a csatolt képen ilyen példa van).

Új opciók hozzáadásakor az Add New Row gombot kell megnyomni. A további beállításoknál a mezőket ugyanúgy kell kitölteni, mint a Text – Field-nél, annyi különbséggel, hogy itt a Title-be be kell írni az opció nevét, amit a vásárló ki fog választani. Egy tétel választható a vásárló számára.

 

Select – Radio Buttons: Ugyanúgy kell beállítani, mint a Select – Drop-down-nál, csak ezek rádió gombok lesznek. Egy tétel választható a vásárló számára.

 

Select – Checkbox: Ugyanúgy kell beállítani, mint a Select – Drop-down-nál, csak ezek pipálható jelölőnégyzetek lesznek. Több tételt is választhat a vásárló.

 

Select – Multiple Select: Ugyanaz, mint a Select – Drop-down, annyi különbséggel, hogy több tételt is választhat a vásárló.

 

Date – Date: Dátum választó, ahol a vásárló ki tudja választani a dátumot.

Date – Date & Time: Dátum és idő választó.

Date – Time: Csak idő választó.

 

Magento egyszerű termék beállítás custom options

 

Magento egyszerű termék beállítás custom options

 

Ezzel az egyszerű termék beállítása kész, mentsük el a terméket a Save gombra kattintva!

 

Konfigurálható termék (Configurable product)

A konfigurálható termék létrehozása előtt kell, hogy már meglegyenek olyan jellemzők, amelyeket használhatunk konfigurálásra (ezt a jellemzők részben írom le részletesen).

  1. Első lépésként válasszuk ki a termék létrehozásakor a Configurable típust.
  2. Ezután ki kell választanunk, hogy mely jellemzőket szeretnénk használni a konfigurálásra, vagyis, hogy a vásárló mikből választhat majd.

 

Magento konfigurálható termék beállítás

3) Utána ugyanúgy töltsünk ki mindent, mint az egyszerű terméknél kivéve az Inventory-t, mivel ott a hozzá tartozó egyszerű termékektől függ, hogy lesz-e raktáron.

4) A hozzá tartozó egyszerű termékeket az Associated Products fülön lehet megtalálni.

A hozzá tartozó termékeket többféleképpen lehet létrehozni: vagy létrehozzuk külön, ahogy az egyszerű terméket, vagy az itt található Quick simple porduct creation rész segítségével. Én az utóbbit javaslom, mert gyorsabb.

Az utóbbit választva töltsük ki a mezőket, majd a Quick Create gombra kattintva létrejön a hozzá tartozó termék. Itt meg fogjuk találni az előzőleg kiválasztott jellemzőket, melyeket majd a vásárló ki tud választani (pl. Size, Color).

Ha szeretnénk a Quick Create után a terméket gyorsan módosítani, a lenti listában az Edit gombra kattintsunk, ahol előjön egy ablak, és ott módosítsuk, amit kell.

 

Magento konfigurálható termék gyors beállítás

 

A lenti ábrán látunk pár opciót, melyek valamennyi összeggel drágább beállítást tesznek lehetővé (pl. a 39-es méretet szeretnénk 500-zal drágábbra állítani, mint a többit). Lehet fix vagy százalékos árat állítani. Ez a beállítás a fenti űrlap kitöltésekor is előjöhet, ha pl. abban a méretben vagy színben még nincs termékünk, vagyis a Super product attribute configuration részben nincs benne az az opció.

Az Attribute Name-hez tudjuk beírni azt a szöveget, ami megjelenik a vásárlónak, ha a Use default be van pipálva, az eredeti szöveg fog megjelenni.

 

Magento konfigurálható termék super beállítás

 

Csoportos termék (Grouped product)

A csoportos termék beállításai hasonlítanak a konfigurálhatóhoz.

  1. Első lépésként a termék létrehozásakor a Grouped Product-ot kell kiválasztani.
  2. Associated Products fülön be kell pipálni a hozzá tartozó terméket, a listában a Default Qty-t beállíthatjuk, hogy mennyi legyen az alapértelmezett mennyiség, ami alapból be lesz a termék adatlapon állítva (persze ezt a vásárló módosíthatja). A Reset Filter-rel tudjuk a teljes listát megkapni, ha szeretnénk bővíteni a hozzá tartozó termékeket.

Magento csoportos termék beállítás

 

Kötegelt termék (Bundle product)

  1. Első lépésként ki kell választani a Bundle Product-ot a létrehozáskor.
  2. A General fülön, az egyszerű termék beállításától eltérő, hogy itt a cikkszámot (SKU) és a súlyt beállíthatjuk úgy, hogy dinamikus legyen (ez a rendelésben látszódik, dinamikusnál a cikkszámokat összevonja, pl. test-1, test-2, ebből lesz test-1-test-2).
  3. A Prices tabon a price mezőnél dinamikus szóval nem lehet beleírni az árat, mivel az altermékből számolódik ki az ár).

A Price View mező pedig, az, hogy hogyan jelenjen meg a termékadatlapon és listákban az ár. Az As Low As megadja, hogy mi a kezdőára, vagyis a minimum ára a kötegelt terméknek. A Price Range, pedig tól-ig érték lesz, vagyis a minimum és maximum árat írja ki (a minimumot itt úgy kell érteni, hogy az egész kötegelt csomagból a legkevesebb, általában 1 darabot vesz meg a vásárló, a maximum pedig, ha az egész csomagot megveszi, tehát mindent belőle).

  1. Bundle Items fülön látjuk a kötegelt termék részeket.

Itt kell hozzáadni azokat a termékeket, amelyek szeretnénk, hogy a kötegelt termék részét képezzék.

 

Ezt a következőképp kell beállítani:

A Ship Bundle Items-nél be kell állítani, hogy a résztermékeket külön (Separately) vagy egybe (Together) lehet szállítani.

Ez alatt van a Bundle Items rész, ahol jobb oldalon az Add New Option-nel tudunk új opciót hozzáadni. Új opció hozzáadásánál a Default Title-höz a kiválasztás címét kell beírni, pl. Fényképezőgép Objektív.

 

Input Type: itt ki kell választani a kiválasztás típusát, hogy lenyíló legyen-e (Drop-down), Rádió gombok, jelölőnégyzet (Checkbox) vagy Többes kiválasztó (Multiple select).

Is Required: a vásárlónak kötelező-e ebből a részből választania.

Position: hányadik helyen legyen, ha több választás is van.

Az Add Selection gomb segítségével tudunk termékeket hozzáadni ehhez a választáshoz.

A teljes listát a Reset Filter-rel tudjuk előhozni, majd itt ki kell választani a termékeket, a Qty to Add pedig abban segít, hogy milyen mennyiség legyen alapból kiválasztva.

 

Ezután meg kell nyomni a fentebb lévő Add Selection Product(s) to Option gombot.

Ha ez megvan, látni fogjuk a hozzáadott termékeket. Abban az esetben, ha Drop-down vagy Radio Buttons típusú, beállíthatjuk, hogy a Default Qty mellett a vásárló tudja-e módosítani a hozzáadott termék mennyiséget (User Defined Qty). A többi típusnál erre nincs lehetőség, és mindig a Default Qty mezőben beállított mennyiség fog bekerülni a kosárba.

A Default bekapcsólóval be tudjuk állítani, hogy alapból a termékadatlapon be legyen-e ez az opció kapcsolva.

 

Magento kötegelt bundle termék beállítás

 

Virtuális termék (Virtual product)

Virtuális terméket ugyanúgy kell beállítani, mint az egyszerű terméket.

  1. Első lépésként válasszuk ki a terméktípusnál a Virtual Product-ot.
  2. A General fülön annyi eltérés van, hogy itt nem kell megadni a súlyt, mivel egy virtuális terméknek nincs súlya. A többi ugyanaz, mint az egyszerű terméknél.
  3. Általában e típusnál nem szokták a készletkezelést használni, mivel nem valószínű, hogy az ilyen termékek kifogynak a raktárból, szóval ilyenkor az Inventory tab-nál a Manage Stock-ot állítsuk NEM-re.

Virtuális termék vásárlásakor nem kell a vásárlónak megadni szállítási címet, mivel ezt a típust nem lehet kiszállítani.

 

Letölthető termék (Downloadable product)

A letölthető terméket is szinte ugyanúgy kell beállítani, mint az egyszerű terméket, csak itt pluszban van a Downloadable Information fül.

  1. Első lépésként válasszuk ki a terméktípusnál a Downloadable Product-ot.
  2. Ugyanúgy, mint a virtuálisnál, itt se kell a General fülön megadni a termék súlyát, mert nincs, és ugyanúgy a készletkezelést sem szokták e típusnál használni (persze attól meg lehet, ha szeretnénk).
  3. A Downloadable Information fülön a következőket kell beállítani:

A Links részen:

Title: adjuk meg a letölthető termékek címét (pl. Dokumentumok).

Links can be purchased separately: a letölthető dolgok megvásárolhatóak-e külön.

Ezután lent az Add New Row gomb megnyomásával tudunk új tételt hozzáadni.

Itt be kell állítani a Title-t, ami a tétel címe lesz (pl. BMW e46 Manual).

A Price-t csak abban az esetben lehet beírni, ha engedélyezzük, hogy külön megvásárolhatók a letölthető tételek, mivel ilyenkor meg kell adni a tételek árát. Ha egyben vásárolható meg, akkor az eredeti ár lesz érvényes, ami a Price fülön van.

Max. Downloads: itt állítjuk be, hogy a felhasználó hányszor tudja letölteni a megvásárolt terméket. Ha nem akarjuk korlátozni, akkor pipáljuk be az Unlimited jelölőnégyzetet.

Sharable: ha szeretnénk, hogy a letöltött terméket a vevő meg tudja másokkal osztani, akkor állítsuk IGEN-re, ilyenkor linket elküldve bárki meg tudja azt nézni. NEM-re állítva csak az a bejelentkezett vásárló tudja megnézni, aki megvásárolta.

Sample: lehet fájl vagy link, egyfajta betekintő / minta / ízelítő, amely megjelenik a termékadatlapon (pl. ha egy könyvről beszélünk, akkor a hátlapján szereplő összefoglalót szokták feltenni valamilyen formában, ami lehet kép, PDF stb.)

File: ide kerül fel a letölthető tétel teljes változata, ami lehet fájl vagy link (a link pl. mutathat egy letölthető dokumentumra).

Sort Order: ha több letölthető tételünk van, akkor a megjelenési sorrendet állítja.

 

A Link rész felett van egy Samples (ritkán van használva szerintem), ha ide feltöltünk ugyanúgy tételeket, azt a termék adatlapon ugyanúgy meg lehet tekinteni, mint a Links részen a Sample-t. Igazából ez az egész letölthető termékre vonatkozó minta (Sample), míg a Links részen mindegyik letölthető tételhez lehet külön mintát feltölteni.

 

Magento letölthető termék beállítás

 

Ezzel a résszel be is fejeztem a termékek létrehozását és beállítását.

 

Mi a termékjellemző, illetve jellemzőcsoport?

 

Mi is valójában a termékjellemző?

A termékjellemzők: azok az elemek, amelyek a termékek tulajdonságait definiálják, pl. termék színe, súlya, mérete, leírása stb. Véleményem szerint ez nagyon jól ki lett találva a Magento-ban és jól használható úgy a fejlesztőknek, mint a webáruház adminisztrátorainak!

Rendkívül jól lehet szűrni a keresőkben a termékek jellemzőire, pl. valakit csak a fekete színű, M-es méretű pólók érdeklik. A vásárlói élmény szempontjából fontos, hogy egy webáruházban könnyen és sikeresen tudjanak a vásárlók keresni, ezért nagyon jól meg kell tervezni az áruház jellemzőit és jellemzőcsoportjait.

 

Mi a jellemzőcsoport?

A jellemző csoport, ahogy a neve is mondja, jellemzők csoportosítása.

 

Példa:

Tegyük fel, hogy a webáruházunkban árulunk pólókat és laptopokat. Ilyenkor létrehozunk kettő jellemzőcsoportot a megfelelő jellemzőkkel. Miért? Azért, mert pl. a pólónak nincs memória mérete, processzor órajele, merevlemez mérete, ugyanúgy a számítógépnek pedig nincs színe (bár ez több esetben még lehetséges is lenne), tehát létrehozunk a Pólóknak egy jellemzőcsoportot, legyen pl. Ruházat a neve, a számítógépnek pedig Műszaki cikkek.

Nem ajánlott minden egyes termékfajtára létrehozni külön jellemzőcsoportokat. Ahol csak tudunk, egyszerűsítsünk, de azért figyeljünk oda, hogy nagy értelmetlenségek ne legyenek (mint ahogy a fenti póló és laptop példa is mutatja).

 

Hogyan kell létrehozni termék jellemzőt, jellemző csoportot?

 

Jellemző létrehozása

Menjünk az adminban a Catalog –> Attributes -> Manage Attributes menüre.

Itt a jobb oldalon fent lévő Add New Attribute-ra kell kattintani.

Az űrlapot a következőképp kell kitölteni:

 

  1. A Properties fülön:

 

Attribute Properties

Attribute Code:

A jellemző egyedi azonosítója (nem lehet üres hely benne, ékezetek sem, és kevesebb mint 30 karakter hosszú lehet csak) pl. color, size, memory_size.

 

Scope:

Itt az tudjuk beállítani, hogy milyen szinten lehessen változtatni a termékek értékét.

Global: mindenhol egyforma, ugyanaz az érték.

Webiste: webshoponként eltérhet az értéke (tehát pl. van 2 webshopunk, az egyiknél február 1-től lesz akciós a termék, a másiknál március 1-től).

Store View: boltnézetenként eltérhet (tehát pl. van 2 store view vagyis boltnézetünk, az egyik a magyar nyelvű, aminél az URL kulcs pl. nagyon-jo-termek, a másik az angol nyelvű, ott pedig very-good-product)

 

Catalog Input Type for Store Owner:

Itt kell kiválasztani, a jellemző beviteli típusát.

Text Field: sima szöveges mező

Text Area: szöveges blokk mező

Date: dátum formátumú

Yes/No: igen/nem típusú

Multiple Select: Többszöri kiválasztós

Dropdown: Lenyíló típusú

Price: ár típusú

Media Image: kép típusú, ezt választva sok beállítás eltűnik

Fixed Product Tax: fix adó típusú, ezt választva sok beállítás eltűnik

 

Default Value:

Itt beállíthatjuk, hogy minden termék létrehozásakor mivel töltse ki alapból ezt az értéket (ez akkor jó, ha sűrűn ismétlődik a termékeknél ez az érték, tehát kevesebbet kell gépelni).

 

Unique Value:

Itt megtudjuk adni, hogy egy adott érték egyedi legyen-e, pl. az áruházban van olyan termék, aminek pl. 8 GB a memóriamérete, de egy másik terméknek is ezt az értéket szeretnénk beállítani. Ha „unique” IGEN-re van állítva, akkor szól, hogy ez az érték már használva van. Vagyis ilyenkor két terméknek nem lehet ugyanaz az értéke.

 

Values Required:

Kötelező-e a mezőt kitölteni

 

Input Validation for Store Owner:

Bevitelkor ellenőrizz-e, hogy az adott adat megfelelő-e.

Decimal Number: tizedesjegy-e

Integer Number: egész szám-e

Email: E-mail típusú-e

URL: URL típusú-e

Letters: Betűk-e

Letters (a-z, A-Z) or Numbers (0-9): Betűk vagy számok

 

 

Apply To:

Melyik terméktípusokra legyen a jellemző érvényes, ha mindre, akkor All Product Types.

 

Frontend Properties

Use in Quick Search:

Lehessen-e a gyorskeresőben a termékjellemző értékére keresni, ha igen, akkor pl. a red szóra keresve meg fogja találni azokat a termékeket, amelyeknél ez az érték be van állítva.

 

Use in Advanced Search:

A részletes keresőben megjelenjen-e ez a jellemző

 

Comparable on Front-end:

Lehessen-e a termékeket összehasonlítani ezen jellemző alapján.

 

Use In Layered Navigation:

A szűrő, szűkítő navigációban használjuk-e. Ha igen, akkor meg fog jelenni ez a jellemző, amire a vásárló tud szűrni. Csak lenyíló, többszörös kiválasztó és ár típusúakat lehet ilyenre használni.

 

Use In Search Results Layered Navigation:

Ez majdnem ugyanaz, mint a felette lévő, csak ez a keresés utáni szűrő navigációra érvényes, hogy megjelenjen-e.

 

Use for Promo Rule Conditions:

Ha szeretnénk, hogy a promóciós szabályok feltételei között használjuk, akkor állítsuk IGEN-re. Pl. van egy szabályunk, ami ad 10% kedvezményt a piros színű pólókra, akkor a szín jellemzőnél ezt IGEN-re kell állítani, hogy a szabályt alkalmazni tudjuk.

 

Position:

A szűrő navigációban adjuk meg, hogy hányadik pozícióban jelenjen meg.

 

Allow HTML Tags on Frontend:

Ezt csak a Text Field, Text Area-ra lehet állítani ‒ lehessen-e html tag-eket használni a jellemzőérték felvételekor.

 

Visible on Product View Page on Front-end:

Egyszerű és Virtuális termékeknél lehet csak ‒ a termék adatlapján általában az Additional Information-nél megjelenjen-e.

 

Used in Product Listing:

A terméklista oldalakon megjelenjen-e az összegzés részen. Vagyis a listában ki legyen-e jelezve ez az érték. Témától is függ.

 

Used for Sorting in Product Listing:

Listaoldalon sorrendezésre lehessen-e használni. Itt is függ a témától.

 

Magento termék jellemző létrehozás beállítás

 

2) Manage Label / Options fülön:

 

Manage Titles

Ez lesz boltnézetenként (feltéve, ha van több) a jellemző neve, vagyis ahogy meg fog jelenni az oldalon.

Admin: ahogy az adminon megjelenik

Default Store View (nem biztos, hogy ilyen néven van elnevezve, lehet, hogy át lett nevezve egy adminisztrátor által) : így fog megjelenni az alapnézetben, amit a vásárló lát.

És ha van több, akkor itt fel lesz sorolva az összes. Ha nem töltjük ki a mezőket, akkor mindig az admin mezőből veszi az értéket.

 

Manage Options (values of your attribute):

Ahogy a zárójelben lévő szöveg is írja, ezek a jellemzőértékek.

Csak lenyíló illetve többszörös kiválasztónál kell megadni.

Add Option gombbal tudunk újat hozzáadni.

Ugyanúgy kell kitölteni, mint a Manage Titles-nél, de szerepel nála még pluszban a jellemző értékek pozíciója. Ha be van pipálva az Is Default, alapból a termék létrehozásakor ez lesz kiválasztva.

 

Magento termék jellemző beállítás

 

Jellemzőcsoport létrehozása

 

Az adminban a Catalog -> Attributes -> Manage Attribute Sets menüre, majd az  Add New Set gombra kell kattintani.

A jellemzőcsoport létrehozása elég egyszerű

  1. Első lépésként meg kell adni a nevét, a Based On-ban pedig, hogy mi alapján hozza létre, ajánlott a Default-ot használni (ha van).
  2. Ezután a Save Attribute Set gombra kattintva kapunk egy új oldalt, ahol be lehet tenni a kívánt jellemzőket.

A bal oszlopban tudjuk módosítani a csoport nevét.

 

A középső oszlopba kell betenni a jobb oldalon található jellemzőket. Itt több alcsoportra vannak osztva, ez az áttekinthetőség szempontjából jó, és például a memory_size jellemzőnk ne a Prices fülön legyen, mivel nem oda való. Természetesen lehet új alcsoportot is létrehozni, az Add New gomb segítségével.

A jobb oldalon csak azok a jellemzők vannak felsorolva, amelyek még nem szerepelnek ebben a jellemzőcsoportban.

Ki is lehet venni jellemzőket, ha nem akarjuk, hogy a jellemzőcsoportba tartozzon.

 

Magento termék jellemző csoport létrehozás beállítás

 

 

Magento kedvezmények, Magento kuponok használata

Az árszabályok használata egy hatékony vásárlás ösztönző eszköz az eladó kezében, amit érdemes mindig használni, mivel a vásárlók szeretik magukat megkülönböztetve érezni. Ha egy termék akciós, a vásárlók nagyobb kedvvel vásárolják meg, mintha nem lenne az.

A kedvezmények szerkesztését az admin felületen, a Promotions (magyarul: Promóciók) főmenüpontban lehet elvégezni.

Alapvető különbség a katalógus és bevásárlókosár ár szabályok között az, hogy a katalógus ár szabálynál már az áruházba belépve látják a vásárlók a kedvezményt, míg a kosár árszabálynál csak a kosárban és a checkout folyamatban látják.

 

Magento katalógus árszabály

A szabály információk fülön (tab) az alapvető beállításait tudjuk megtenni a szabálynak. Itt állíthatjuk be, hogy milyen időintervallumban, milyen vevőcsoportokra legyen érvényes a szabály.

Magento kedvezmény catalog price rule

A feltételek fülön lehet összekattintani azt a szűkítést, amire szeretnénk adni a kedvezményt. Megadhatjuk feltételnek a jellemző csoportot, jellemzőt és a kategóriát. Lehetőség van tagadni is a feltétel összeállításában, ez azt jelenti, hogy a kiválasztott jellemző csoportra vagy kategóriára ne legyen érvényes az adott szabály.

 

A műveletek fülön a kedvezmény értékét tudjuk beállítani százalékosan vagy fix összeggel. Alapból egy áruházban akár több kedvezmény is érvényesíthető. Ennek a meggátolására a műveletek fülön a további szabályok feldolgozásának leállítása opciót igenre kell állítani.

FONTOS
A katalógus árszabályokat érvényesíteni kell. Ezt meg lehet tenni a „Mentés és alkalmazás” gombbal, de ha be van állítva a cronjob, akkor minden éjfélkor elvégzi ezt automatikusan a Magento.

 

Magento kosár árszabály

FONTOS
Beállítási lehetőségek hasonlóak, mint a katalógus árszabály beállításai. Különbség az, hogy ebben az esetben nem a termék ára fog változni, hanem a kosár végösszege vagy a szállítási költség. Feltételnek a katalógus árszabály feltételein kívül be lehet állítani szállítási, számlázási információkat, kosár teljes súlyát.

 

Magento kupon kódok

Lehetőség van a kosár árszabályoknál kuponok felvitelére is. Ha generálni szeretnénk, akkor végtelen számú random kupont tudunk generálni, viszont ha egyesével szeretnénk felvinni, akkor mindegyikre külön-külön árszabályt kell felvinni.

Magento kedvezmény shoppig cart price rule

 

Valós életből vett példák

 

1) Most a Magyarországra szállított termékek 10%-kal olcsóbban vásárolhatók meg

Ebben a példában láthatjuk, hogyan lehet kedvezményt adni szállítási cím alapján.

Feltétel beállítása:

Kattintsunk a „Conditions” fülre, majd a „+” ikonra. A legördülőből válasszuk ki a Shipping Country-t, majd a „…” linkre kattintva válasszuk a listából a „Hungary” opciót.

Magento kedvezmény szállitási hely

 

Az „Actions” fülön az Apply címkénél legyen a „Percent of product price discount” opció választva és a Discount Amountot pedig állítsuk be 10-re.

 

Magento kedvezmény kosár árszabály

 

2) 10 000 Ft feletti vásárlás esetén most 50%-ot elengedünk ha a PayPal Express fizetési módot választja

Ebben a példában egy olyan kosár árszabályt szeretnénk beállítani, amely a 10 000 Ft-os végösszeget meghaladó kosarakra vonatkozik és a vásárló a PayPal Express fizetési módot választotta.

Feltétel beállítása:

Kattinsunk a „Conditions” fülre, majd a „+” ikonra. A legördülőből válasszuk ki a „Subtotal” opciót. Kattintsunk az „is” linkre és válasszuk helyette az „equals or greater than” opciót, majd a “…” linkre kattintva adjuk meg értéknek a 10000-et.

Miután sikerült beállítani a kosár végösszeget, adjuk meg egy újabb “+” jel megnyomásával a “Payment method”- ot, majd a “…” linkre kattintva a “Paypal Express Checkoutot”.

Legvégül az “Actions” fülre az Apply címkénél legyen a „Percent of product price discount” opció választva és a Discount Amountot pedig állítsuk be 50-re.

 

Magento kedvezmény mérték

 

3) 10% kedvezmény egy 5 000 Ft-nál drágább termékre

Ebben a példában kuponkód segítségével fogjuk beállítani a 10%-os kedvezményt egy 5 000 Ft-nál drágább termékre.

Feltétel beállítása:

Kattintsunk a „General Information” fülre és a „Coupon” opciónál válasszuk a Specific Coupon opciót, majd az alatta megjelenő “Coupon Code” beviteli mezőben adjuk meg a 10OFFF értéket. Ezáltal ha a vásárló a kosár oldalon megadja a 10OFF kuponkódot, akkor egy termékre 10%-os kedvezményt kap.

A következő lépésben nem a “Conditions” fülön fogjuk beállítani az 5 000 Ft-ot, hanem az Actions fül “Apply the rule only to cart items matching the following conditions (leave blank for all items)” szekciójában. Kattintsunk a „+” ikonra majd a „Product attribute” opciócsoporton belül a „Price” opciót válasszuk. Az „is” linkre kattintva adjuk meg a „greater than” opciót és összegnek írjuk be az 5000-t. Ugyanezen a fülön az Apply opciónál a „Percent of product price discount” legyen kiválasztva, a “Discount Amount” beviteli mezőbe pedig írjunk 10-t, illetve a “Maximum Qty Discount is Applied To” mezőbe 1-et.

Magento kedvezmény mérték 5000 ft felett

 

4) 5% kedvezmény a vásárlás végösszegéből, ha UPS (Next Day Air) szállítási módot választ.

 

Ebben a példában kuponkód segítségével fogjuk beállítani az 5%-os kedvezményt.

Feltétel beállítása:

Kattintsunk a „General Information” fülre és a „Coupon” opciónál válasszuk a Specific Coupon opciót, majd az alatta megjelenő “Coupon Code” beviteli mezőben adjuk meg a 5OFFF értéket. Ezáltal ha a vásárló a kosár oldalon megadja a 5OFF kuponkódot, akkor a végösszegre 5%-os kedvezményt kap.

Kattinsunk a „Conditions” fülre, majd a „+” ikonra és válasszuk a „Shipping Method” opciót, majd a “…” linkre kattintva a “ [ups] Next Day Air”-t.

Legvégül az “Actions” fülön az Apply címkénél legyen a „Percent of product price discount” opció választva és a Discount Amountot pedig állítsuk be 5-re.

Magento kedvezmény kosár árszabály kupon

 

Komplexebb esetek

Előfordulhat olyan is, amikor az üzleti igényeknek a Magento alaptudása nem felel meg. Ilyen esetben fejlesztéssel kiegészíthető ez az alapfunkcionalitás. Nézzünk néhány példát ilyen fejlesztésre.

 

1)   Csak nőknek/férfiaknak, életkor szerinti kedvezmény

Ebben a példában szeretnénk kedvezményt adni az 50 év feletti férfiaknak a vásárlás végösszegéből.

Hiába lehet megadni a születési dátumot és a nemet Magentóban, ezeket sajnos nem lehet felhasználni feltételként a katalógus és kosár árszabályokban. Fejlesztéssel ki lehet egészíteni, hogy ezeket a felhasználói jellemzőket is figyelembe vegyék az árszabályok.

 

2)   XY felhasználónak szeretnék egy kedvezményre jogosító kuponkódot adni

Ebben a példában egy bizonyos, előre meghatározott felhasználónak akarunk egy kuponkódot adni, hogy olcsóbban vásároljon az oldalon.

Azt be lehet állítani, hogy egy kuponkód csak egyszer legyen felhasználható, viszont azt csak fejlesztéssel lehet megadni, hogy pontosan melyik felhasználó használja fel a kuponkódot. Egy kis csalással azért meg lehet oldani ezt, de nem a legelegánsabb: annak a felhasználónak, akinek szeretnénk a kupont adni, létrehozunk egy felhasználói csoportot és az árszabályt úgy állítjuk be, hogy csak ennek az egy felhasználói csoportnak legyen érvényes.

 

3)   Visszatérő vásárlóknak kedvezmény

Ebben a példában a gyakran vásárló felhasználókat szeretnénk jutalmazni.

Sajnos nem lehet alapból az árszabályoknál azt figyelni, hogy ki hányszor és milyen összegben vásárolt a webáruházban. Fejlesztéssel természetesen megoldható, hogy a vásárolt termékek árát összeadja és bizonyos összeg felett érvényesítsen valamilyen összegű kedvezményt.

 

tips +1 Megoldás:
Készítettünk olyan fejlesztést is, amely egy teljes űrlappal egészítette ki a checkout folyamatot. Az űrlap elemei pedig a kosár árszabálynak megfelelően jelentek meg. Például lehetett olyat is beállítani, hogyha számítógép konfiguráció volt a kosárban, akkor megjelent egy checkbox a rendelési folyamatban, hogy kéri-e a vásárló, hogy a számítógép konfigurációt a boltban összeállítsák neki.

 

A fent említett példák csupán egy töredéke, amit meg tudunk valósítani fejlesztéssel

Bármilyen kérdésed merül fel a cikkel vagy a fent említett keretrendszerekkel kapcsolatban, írd meg kommentben és válaszolunk!

 

 

Magento termék importálás: 4 bizonyítottan működő megoldás

A Magento rendszer egyik legnagyobb előnye, hogy a vásárlók szinte korlátlan számú paraméterre rákeresve válogathatnak a feltöltött árucikkek között. Ez megkönnyíti a vásárlást, megnöveli a konverzió esélyét, hiszen az érdeklődők nagyobb eséllyel találják meg az oldalon a számukra legjobb terméket, akár több ezer között is. Ahhoz azonban, hogy ez megvalósulhasson, a webáruházat fel kell töltenünk termékekkel – egy üres kirakatnál senki sem fog megállni. Szerencsére erre több praktikus megoldás is létezik.

Az alapok: adminisztrációs felületen keresztül

A legalapvetőbb, legegyszerűbb módszer természetesen az, ha kézzel visszük fel a termékeket a katalógusba. A Katalógust könnyen megtaláljuk az adminisztrációs felületen, ezen belül a Termékek kezelése oldalon találjuk meg az Új termék gombot. A Magento által használt CMS, vagyis Content Management System lehetőséget ad arra, hogy a termékadatbázist könnyen és gyorsan módosíthassuk, termékenként adjuk meg a paramétereket, amelyek alapján a felhasználók nem csak kereshetnek, de intelligens szűrőket is beállíthatnak. Sőt, mi is beállíthatunk olyan felhasználói csoportokat, akik csak bizonyos ajánlatokat látnak majd ez alapján. Mindez igen megkönnyíti a dolgunkat a mindennapi webboltmenedzsment során, az adatbázis létrehozásánál azonban ennél hatékonyabb módszerre lesz szükségünk.

1. Egyszerű importálás

A Magento alapvetően lehetőséget ad arra, hogy minden nehézség nélkül, gyakorlatilag néhány kattintással importáljuk termékeinket egy .csv fájlból. E módszer viszonylag egyszerű, ha már megtanultuk, mit hol kell keresnünk és milyen sorrendben végezzük a műveleteket. Erősen limitált lehetőségeket kínál azonban. Default Magento Product Importer Ha ugyanis olyan paraméterek is szerepelnek a fájlban, amelyek a rendszerben még nem szerepelnek (mert a megfelelő attribútumokat még nem hoztuk létre), akkor a feltöltés sikertelen marad, majd az adatellenőrzésnél félbe fog szakadni a folyamat. Olyan módszert kell tehát találnunk, ahol a feltöltött .csv fájlban szereplő attribútumok pontosan megegyeznek a rendszerben lévőkkel. Ezt a Rendszer -> Import/Export -> Import oldalon tehetjük meg. Mivel itt felhasználói adatokat is feltölthetünk, meg kell adnunk, ezt kívánjuk-e tenni, vagy termékadatokat töltenénk fel. Meg kell határoznunk azt is, hogy pontosan mit akarunk tenni:

  • hozzáadni az új .csv fájlban szereplő adatokat a létező adatbázishoz,
  • cserélni a létező adatbázist az importálandóra,
  • illetve törölni az adatbázisból az importfájlban szereplő tételeket.

 

2. Kötegelt importálás néhány extra lépéssel

Persze az adminfelületen sem csak arra van lehetőség, hogy egyesével vigyük fel a termékeket – ha így volna, a Magento eleve hibás rendszer lenne, márpedig nem az. Magento kötegelt importálás   Lássuk, hogyan importálhatunk tehát kötegelve termékeket előre meghatározott jellemzőkkel (attribútumokkal). A kiindulópont hasonló: mindenekelőtt egy kategóriát kell létrehoznunk az adminisztrációs felületen. Ezt a Katalógusban, a Kategóriák kezelése menün belül tehetjük meg. Hozd létre az összes olyan kategóriát, amelyre éppen szükséged van, majd ha kitöltötted a szükséges információkat, mentsd el őket. Érdemes ezen a ponton lejegyezned az újonnan létrehozott kategóriák azonosítóit (ID), legjobb, ha elmented őket egy szövegfájlba. Az azonosítót a rendszer akkor írja ki, amikor az újonnan létrehozott kategóriát elmented. Ezen a ponton érdemes azokat az attribútumokat is megadni, illetve létrehozni, amelyeket a későbbiekben használni akarunk majd. A Magento rendszere értelemszerűen nem tartalmazhat mindent, amire szükségünk van, lehetőséget biztosít azonban ezek hozzáadására. Ezt a Katalógus menün belül az Attribútumok -> Attribútumok kezelése oldalon belül tehetjük meg. Ha ezzel megvagyunk, készen is áll a mintatermékünk, amelyet template-ként használunk majd a továbbiak kötelet importálásához. Mentsük el, és meg fog jelenni a terméklistában. A következő lépésben látszólag bonyolódik a helyzet, valójában azonban egyszerűen elvégezhető a folyamat. Azt szeretnénk, hogy a mintatermék paramétereihez hozzáférjünk saját számítógépünkön, egyszerűen módosítható formában, majd ezt töltsük vissza a boltba. Ide pedig így juthatunk el: A Rendszer -> Import/Export -> Dataflow Profilok oldalon a Minden termék exportálása opciót kell megkeresnünk. A Profilinformációkban meg kell adnunk azt a webboltot, ahová a termékeket importáljuk majd – értelemszerűen ennek ugyanannak a webboltnak kell lennie, melyben korábban a mintaterméket létrehoztuk. Az Adatátvitel lenyíló menü alatt a Helyi/Távoli Szerver opciót válasszuk ki, és bizonyosodjunk meg arról, hogy a formátumnál CSV van megadva. Ezután mentsük el a profilt, majd exportáljuk ismét az összes terméket és kattintsunk a Profil Futtatása Popupként gombra. Így alapbeállításként egy “export_all_products.csv” nevű fájlt kapunk (melynek neve természetesen szabadon állítható), amelyet a Magento telepítőkönyvtárába ment el a rendszer. Ezt a fájlt egy FTP kliens segítségével letölthetjük a számítógépünkre, benne pedig a korábban megadott attribútumoknak megfelelő oszlopokat találjuk majd. Ha megnyitjuk egy táblázatkezelő programmal (Microsoft Excellel például), könnyedén kitölthetjük a mezőket, és így hozzáadhatjuk az importálni kívánt termékeket. Itt kell megadnunk a kategóriák azonosítóját (ID) is, figyeljünk, hogy melyik terméket melyik kategóriába helyezzük. Az előbbi útvonalon az adminisztrációs felületen ezúttal a Minden termék importálása opciót kell megkeresnünk, ha készen vagyunk, kiválasztani a Fájl feltöltése lehetőséget, és megkeresnünk a módosított .csv fájlt. Ha ez megvan, ismét lépjünk a Minden termék importálásához, válasszuk ki a Profil futtatását és a lenyíló menüből válasszuk ki az imént feltöltött fájlt. Ezután nincs más dolgunk, mint hogy a terméklistában ellenőrizzük, sikerült-e a művelet.

3. A Magento Mass Importer, vagyis Magmi használata

Ha egy átláthatóbb módszert akarunk több opcióval, ajánlott az ingyenes Magmi applikáció használata. Ez lényegében egy külső felhasználói felület, mely segítségével egy sor olyan import/export opcióhoz férhetsz hozzá, amelyek alapból nem találhatóak meg a Magento rendszerében. Magmi Magento importálás   A tapasztalatok szerint a Magmi használatával jóval egyszerűbb a termékeket importálni a rendszerbe, bár természetesen az ehhez használt .csv fájlokat továbbra is nekünk kell majd létrehoznunk. Sajnos az adatbázist valamilyen módon mindenképpen nekünk kell kialakítani – a Magmi segítségével azonban könnyebbé tehetjük az adatbázis feltöltését. Hátránya talán annyi, hogy még egy adminisztrációs felület használatát meg kell tanulnunk, a tapasztalatok szerint azonban ez egyáltalán nem teljesíthetetlen feladat. Főleg, azért, mert az applikáció bőséges dokumentációja lépésről lépésre végigvezet mindenen, és még saját Wikit is létrehoztak a felhasználók megsegítésére. Erőssége, hogy olyan dolgokat is megtehetünk a segítségével, mint például a képek tömeges importálása, vagy éppen a kategóriák automatikus létrehozása importáláskor.

4. Fizetős kiegészítők

A Magento képességeit azzal is felturbózhatjuk, ha speciális kiegészítőket vásárolunk hozzá. A legtöbben természetesen inkább a Magmi applikációt használják, hiszen ingyenesen letölthető és rengeteg funkcióval rendelkezik, ha azonban mégis valamilyen speciális funkcióra volna szükségünk, találhatunk az igényeinkre megfelelő kiegészítést. Magento store manager importálás   Arra kell csak felkészülnünk, hogy ezekért 50-100 dollárt kérnek el átlagosan, tehát azért, hogy egy-egy funkcióbővítéshez hozzájussunk, a zsebünkbe kell majd nyúlnunk, és talán nem is egyszer, hiszen lehet, hogy egyszerre több applikációra is szükségünk lesz a hatékony munkához.

tips Fontos Tippek:

 

Megfelelő szoftverválasztás

Mint az a fentiekből látható, a Magento esetében az egyik legnagyobb nehézséget az alap sablonok legyártása okozhatja, amelyeket aztán a későbbiekben a termékek feltöltéséhez használni akarunk – ha nem figyelünk oda nagyon pontosan a folyamatra, kompatibilitási problémák adódhatnak már egy-egy kihagyott attribútum miatt is. A sablont tehát úgy kell elkészítenünk, hogy azt először magában a webáruházban hozzuk létre, így elkészítve azt a mintát, amelyet egészen biztosan a későbbiekben is értelmezni tud majd a rendszer. Ezt a fájlt kell exportálnunk saját gépünkre, ott pedig megszerkeszteni úgy, hogy minden kívánt termék részletes adatait tartalmazza. A Magento esetében ugyanakkor nem mindegy, hogy milyen programmal kezeljük a .csv fájlokat. Az Excel a tapasztalatok szerint nem képes ezeket megfelelően kezelni, így érdemes egy másik program segítségéhez folyamodnunk. A Libre Office irodai szoftvercsomagjában megtalálhatjuk a Calc programot – ez ingyenesen letölthető, bármely Excel-felhasználó számára könnyen kezelhető és megfelelően képes bánni a számunkra szükséges fájlokkal is.

Speciális karakterek

A CSV fájl lementésekor használjunk UFT-8 formattálást, a tapasztalatok szerint így nem lesznek komoly gondjaink a későbbiekben – persze minden hibalehetőséget ez sem szűr ki. A speciális karakterekkel például vigyáznunk kell. Ha olyan speciális karaktereket használunk a termék valamely attribútumánál, amellyel az adott formátum nem bír el, ez az importálásnál gondot okozhat. A hibajelenség általában úgy jelentkezik, hogy a rendszer egyszerűen üresen hagyja az adott terméket. Ha mindenképpen akarsz speciális karaktereket alkalmazni, például sortörést vagy vesszőt, a mező tartalmát (a példákat keresd az attribútumokról szóló pontnál) tedd idézőjelbe, így már jó eséllyel megfelelően jelenik majd meg. Ez persze elsősorban a termékleírásra érvényes, a többi attribútum esetében a legjobb, ha tartózkodsz az ilyesmitől.

Az importálandó képeket helyezd a /media/import könyvtárba

Az importálás során minden egyes képet fel kell dolgoznia a rendszernek. A nyers képeket tehát a fent leírt könyvtárba töltsük fel még a termékadatbázis importálását megelőzően, innen dolgozik majd a rendszer. Fontos az is, hogy nagyon figyeljünk a képfájlok elnevezésére – ellenőrizzük, hogy a táblázatban is ugyanazokat az elnevezéseket, kiterjesztéseket adtuk-e meg, így nem találkozunk majd kellemetlen meglepetésekkel.

Ne változtass a táblázat oszlopain

Az egész fent leírt folyamat lényege, hogy pontosan azokat az attribútumokat használjuk, melyeket a webáruház motorja is képes felismerni, kezelni. Ha a fájl szerkesztésekor ezeken önhatalmúlag változtatunk, akár csak egy kicsit átírjuk azokat, az előre nem látható hibákat generálhat – bár az eredmény valószínűleg az lesz, hogy az importálás sikertelen marad.

Az oszlopok (/attribútumok), amiket muszáj megadnod

Alaposan körüljártuk már, milyen kompatibilitási problémáid akadhatnak, ha nem a megfelelő formában töltöd fel termékeidet – lássuk, melyek azok az oszlopok, vagyis attribútumok, amelyeket mindenképpen bele kell foglalnod a forrásként használt .csv fájlba.

  • websites – a termékhez tartozó entitás, mely alapesetben „base” értékkel bír.
  • store – a termékhez tartozó webbolt, alapesetben „admin” értékkel bír.
  • type – a termék típusa.
  • attribute_set – default, vagy egy másik attribútum-csoport – ezeket az adminfelületen a Catalog -> Attributes -> Manage Attributes oldalon ellenőrizheted.
  • tax_class_id – a termékhez tartozó adótípus, az adminfelületen a Sales -> Tax alatt találod a lehetőségeket.
  • status – a termék állapota, “Enabled” (aktív) vagy “Disabled” (inaktív) értéket vehet fel.
  • weight – a termék súlya. ha nincs erre szükséged, egyszerűen írj 1-et.
  • sku – a termék egyedi azonosítója.
  • name – a termék neve.
  • price – a termék ára.
  • description – a termék részletes leírása, amely a termékoldalon jelenik majd meg.
  • short_description – a termék rövid leírása, a beállításoktól függően megjelenhet például a találati oldalakon.
  • visibility – a termék láthatóságát adja meg, „Not Visible Individually”, „Catalog, Search”, „Catalog” és „Search” értékeket vehet fel (nem látható, katalógusban és keresésben látható, katalógusban látható, keresésben látható).
  • category_ids – a kategóriaazonosító (ID), erről beszéltünk már korábban.
  • qty – a termékből rendelkezésre álló mennyiség.
  • is_in_stock – a termékhez rendelt leltári érték, az 1 azt jelenti, a termék raktáron van, a 0, hogy nincsen. A raktáron nem lévő termékeket nem mutatja a webáruház a főoldalon és megvásárolni sem lehet őket.
  • image, small_image, thumbnail – itt adhatjuk meg a termékhez rendelt kép(ek) elérési útvonalát, fájlnevét. Nagyon kell itt figyelnünk arra is, hogy a rendszer a kis és nagy betűk közötti eltérésekre is érzékeny, a szóközök használatát pedig hanyagoljuk. A háromféle képmegjelenítéshez (image, small_image, thumbnail) ugyanazt a nagy képfájlt is használhatjuk, a rendszer automatikusan átméretezi majd.

 

Lehetséges hibák

 Magento import hibák

„Image does not exist”

Ezt a hibaüzenetet akkor látjuk majd, ha rosszul adtuk meg a képfájlok nevét a .csv fájlban. Ilyenkor érdemes újra ellenőrizni a pontos neveket és azt is, nem használtunk-e problémás karaktereket.  

Meg nem jelenő termékek

Az importált termékek akkor nem jelennek meg a főoldalon, ha bizonyos attribútumokat nem megfelelően adtunk meg. A megjelenéshez szükséges értékek:

  • websites = base
  • store = admin
  • status = Enabled
  • visibility = Catalog, Search
  • category_ids = # (létező kategóriaazonosítónak kell lennie!)
  • qty > 1
  • is_in_stock = 1

 

Összegzés

A Magento rendszerének alapvető funkciói lehetőséget adnak arra, hogy termékeket, jellemzőket, termékcsoportokat és más olyan entitásokat hozzunk létre, amelyek elképesztően hasznosnak bizonyulnak. Előre felépített adatbázisokból azonban az importálás már kifoghat rajtunk, ha csak a beépített opciókra támaszkodunk. A fent leírt módszerek használatával ugyanakkor – köszönhetően a Magento rugalmas rendszerének – .csv fájlok használatával könnyedén tölthetünk fel akár több tízezer termékből álló adatbázisokat olyan formában, hogy azokat a szoftver képes legyen probléma nélkül értelmezni. Ezzel pedig rengeteg időt spórolunk, hiszen nem kell minden terméket egyesével feltöltenünk, minden paramétert kézzel megadnunk – ez munkaórákban számolva egy nagyobb adatbázisnál elképesztően sok pénzbe kerülne. Továbbá lehetőséget ad arra is, hogy más rendszerekből származó adatbázisainkat egyszerűbb módon migrálhassuk Magento-ba.   Amennyiben még mindig úgy érzed, segítségre szorulsz, ajánljuk szíves figyelmedbe Magento projektválság-kezelés szolgáltatásunkat, amellyel szinte bármilyen, Magento webáruházával kapcsolatos problémát segítünk megoldani.