Magento

Magento er navnet, mange stadig bruger om den open source-baserede webshopplatform, der i dag findes som Magento Open Source og som teknisk fundament for Adobe Commerce. Magento Open Source er den kodebase, Adobe bidrager til og vedligeholder kompatibilitet omkring, mens Adobe Commerce tilføjer flere enterprise-funktioner og kommercielle driftsmodeller oven på samme grundlag.

Platformen er bygget til e-handel og adskiller sig derfor fra et generelt CMS. Produkter, priser, lager, kunder, ordrer, websites, stores og store views er centrale objekter fra starten. En enkelt installation kan understøtte flere websites og butikker med forskellige domæner, kataloger, sprog eller konfigurationer.

Magento forbindes ofte med større eller mere komplekse webshops. Det skyldes ikke kun antallet af produkter, men også platformens fleksible katalogmodel, mulighed for flere stores, extensions, integrationer og omfattende konfiguration. Den fleksibilitet har en pris: installation, opdateringer, servermiljø, deployment og specialudvikling kræver typisk mere teknisk arbejde end en enkel hosted webshop.

Sammenlignet med WooCommerce er Magento en selvstændig commerce-platform, mens WooCommerce udvider WordPress. Begge kan tilpasses og integreres, men deres arkitektur, økosystem og driftsmodel er forskellige. Derfor er det sjældent meningsfuldt kun at sammenligne på en funktionsliste.

Magento Open Source bruger blandt andet Composer til at styre PHP-pakker og afhængigheder. En moderne installation består således af mange versionerede komponenter, og en opgradering er mere end at trykke på en opdateringsknap. Kompatibilitet mellem core, extensions, PHP, database, søgetjenester og specialkode skal håndteres systematisk.

Hvis virksomheden allerede har Magento, bør første skridt være en teknisk kortlægning. Kører den Magento Open Source eller Adobe Commerce? Hvilken version? Hvilke extensions er installeret? Hvor meget custom code findes der? Hvilke eksterne systemer er koblet på? Og hvordan ser deployment-processen ud fra udvikling til produktion?

Store-strukturen er et vigtigt særkende. En installation kan have flere websites, hvert website kan have flere stores, og stores kan have flere store views. Det bruges eksempelvis til forskellige lande, brands, sortimenter eller sprog. Fleksibiliteten er stærk, men en dårlig struktur kan gøre priser, katalog, SEO og administration sværere at forstå.

Produktkataloget bør modelleres ud fra de faktiske data. Et produkt kan have mange attributter, varianter og relationer. Hvis webshoppen integreres med et PIM eller ERP, skal det aftales, hvilket system der ejer produktnavn, billeder, lager, priser og kategorier. Integrationer kan bygges gennem et API, events, køer eller webhooks afhængigt af arkitekturen.

Extensions udvider Magento med funktioner og integrationer. De kan være udviklet af Adobe, fællesskabet eller tredjepartsleverandører. Som med plugins i andre systemer bør de behandles som afhængigheder. En extension kan påvirke database, checkout, frontend eller API'er, og kompatibiliteten skal kontrolleres ved opgradering.

Hosting er en væsentlig del af Magento-arkitekturen. Magento Open Source skal driftes i et miljø, der passer til den valgte version og dens afhængigheder. Det kan kræve cache, søgetjenester, cronjobs, køer og korrekt dimensionerede serverressourcer. Et almindeligt billigt webhotel-setup er derfor ikke nødvendigvis tilstrækkeligt.

Databasen er central, fordi katalog, kunder, konfiguration og ordredata hænger sammen gennem mange tabeller og services. Det betyder, at direkte manuelle ændringer i databasen bør undgås som en hurtig løsning. Brug platformens modeller, API'er eller kontrollerede migrationsværktøjer, så dataintegriteten bevares.

Ved større opgraderinger bør virksomheden have staging og en testplan. Centrale flows som produktvisning, søgning, kurv, checkout, betaling, fragt, ordremail og ERP-synkronisering skal testes. En teknisk opgradering er først færdig, når forretningens kritiske flows virker.

Hvis Magento skal erstattes med en anden platform, er migreringen typisk et data- og integrationsprojekt lige så meget som et designprojekt. Produkter, kunder, ordrer, URL'er, redirects, attributter og eksterne integrationer skal mappes til den nye løsning.

En grossist driver tre webshops fra samme Magento-installation. Hvert brand har eget domæne og design, men en stor del af produktkataloget og lageret deles. Priserne kommer fra ERP-systemet, og nogle kunder har individuelle aftaler.

Den eksisterende løsning fungerer, men opgraderinger tager lang tid, fordi 35 extensions og flere specialmoduler er afhængige af den gamle version. Ingen har et samlet overblik over, hvilke extensions der stadig bruges.

Virksomheden laver derfor en afhængighedsliste. Hver extension klassificeres som kritisk, erstattelig eller overflødig. Samtidig dokumenteres alle integrationer til ERP, betalingsgateway, fragt og marketing. Tre extensions viser sig at løse funktioner, som nyere platformversioner allerede håndterer.

På staging bygges en opgraderet version med færre extensions. ERP-integrationens masterdata dokumenteres: ERP ejer priser og lager, Magento ejer kurv og ordreflow, og ordren sendes retur efter checkout. Det gør fejlsøgning langt mere konkret.

Virksomheden overvejer også at flytte til en mindre kompleks webshopløsning. Efter analysen vælger den at beholde Magento, fordi multi-store, kundespecifikke priser og integrationer faktisk udnytter platformens styrker. Hvis behovet kun havde været én butik med et almindeligt katalog, kunne konklusionen være en anden.

Eksemplet viser pointen: Magento bør ikke beholdes af vane, men heller ikke erstattes alene fordi platformen er teknisk tung. Det relevante spørgsmål er, om kompleksiteten skaber forretningsværdi.

Den første faldgrube er at undervurdere opgraderinger. Magento Open Source består af mange pakker og afhængigheder. Hvis core opdateres uden at teste extensions og custom code, kan checkout, integrationsjobs eller frontend fejle. Planlæg opgraderinger som releases med backup, staging og rollback.

En anden fejl er at installere extensions ukritisk. Hver extension øger mængden af kode og kan påvirke sikkerhed, performance eller kompatibilitet. Hvis en funktion kan løses enkelt i eksisterende kode eller ikke længere bruges, bør den ikke nødvendigvis blive hængende.

Pas også på med at bruge Magento til en lille standardshop alene fordi virksomheden forventer at “vokse ind i det”. En platform bør løse dagens og den realistiske fremtids behov. Ellers betaler virksomheden for kompleksitet i udvikling, hosting og support uden at få værdi igen.

Den modsatte fejl er at tro, at enhver Magento-shop let kan flyttes. En webshop med ti års ordredata, specialattributter, flere stores og ERP-integration er ikke et almindeligt indholdssite. Migreringen kræver mapping, test og ofte nyudvikling.

Performance bør heller ikke løses med én cache-indstilling. Katalogstørrelse, søgning, tema, extensions, indeksering, database og servermiljø påvirker hinanden. Mål først, hvor flaskehalsen ligger.

Endelig skal man skelne mellem Magento Open Source og Adobe Commerce. De deler kodebase, men har ikke samme produktpakke, licensmodel eller enterprise-funktioner. Når en leverandør blot skriver “Magento”, bør det præciseres, hvilken løsning der faktisk er tale om.

Adobe beskriver Magento Open Source som den kodebase, virksomheden bidrager til og sikrer kompatibilitet for i forhold til Adobe Commerce. Det betyder, at navnet Magento fortsat er teknisk relevant, selv om Adobe Commerce er det kommercielle produktnavn.

Magento Open Source 2.4.9 er dokumenteret som en Composer-baseret PHP-applikation med en lang række pakkeafhængigheder. Det understreger, hvorfor versionsstyring og deployment er centrale driftsdiscipliner på platformen.

En installation kan understøtte flere websites, stores og store views. Det er nyttigt til internationale setups og flere brands, men strukturen bør planlægges tidligt, fordi scope påvirker konfiguration, katalog og indhold.

Adobe Commerce arbejder i stigende grad med API-first og moderne storefront-arkitekturer, men det betyder ikke, at enhver Magento-løsning skal være headless. Et traditionelt storefront kan stadig være det mest robuste valg, hvis kravene ikke kræver en separat frontend.

Magento Open Source er open source, men en Magento-løsning er ikke gratis at eje. Hosting, udvikling, sikkerhedsopdateringer, overvågning, integrationsdrift og support er reelle omkostninger. Det er derfor mere relevant at sammenligne totalomkostningen end licensprisen alene.

For en virksomhed, der vurderer Magento mod WooCommerce, Shopify eller andre platforme, bør beslutningen tage udgangspunkt i katalog, markeder, integrationer, redaktørbehov, checkout, ejerskab og driftskompetencer. Platformen er kun et middel til at få webshoppen til at fungere.