---
title: "Magento 2 / Mage-OS / Adobe Commerce"
description: "Enterprise e-commerce dla złożonych katalogów, B2B i multi-store, na Mage-OS i Adobe Commerce."
language: "pl"
canonical: "https://zapolu.com/pl/services/magento/"
---

# Magento 2 / Mage-OS / Adobe Commerce

Magento napędza jedne z największych operacji e-commerce w sieci
i zasłużenie zyskało opinię platformy wymagającej w utrzymaniu.
Dobrze prowadzone, wciąż jest najmocniejszą otwartą platformą dla
złożonych katalogów i B2B. Źle prowadzone oznacza kartę produktu
ładującą się 12 sekund i koszty hostingu, których nikt nie potrafi
uzasadnić. Większość naszych projektów przy Magento zaczyna się od
sklepu w tym drugim stanie.

Pracujemy z obiema żywymi gałęziami platformy:

- **[Mage-OS](https://mage-os.org)**: fork prowadzony przez
  społeczność, który uniezależnia przyszłość platformy od roadmapy
  Adobe i wydaje szybciej. Nowe otwarte wdrożenia trafiają dziś tam,
  a nie na stockowe Magento Open Source; to do forka przeniosła się
  wydawnicza energia społeczności.
- **[Adobe Commerce](https://business.adobe.com/products/magento/magento-commerce.html)**:
  licencjonowana edycja chmurowa z pakietem B2B, page builderem
  i enterprise'owymi SLA.

Pracę prowadzi architekt z certyfikatem **Adobe Certified Master –
Adobe Commerce Architect**, najwyższym, jaki Adobe przyznaje dla
Commerce, oraz z certyfikatem Hyvä po stronie frontendu. Oba
sprawdzisz na
[LinkedInie](https://www.linkedin.com/in/lubos-zapotocny-48bba0124/).

## Kiedy Magento jest właściwym wyborem

- Złożone katalogi z wieloma typami produktów, opcjami
  konfigurowalnymi i regułami cenowymi
- Wymagania B2B: konta firmowe, workflow ofertowy, ceny progowe,
  akceptacja zamówień
- Konfiguracje multi-store i multi-brand pod jedną administracją
- Istniejąca inwestycja w rozszerzenia i integracje Adobe Commerce

Jeśli żaden z tych punktów Cię nie dotyczy, tańszym rozwiązaniem
jest zwykle [Shopify](/pl/services/shopify/) i usłyszysz to od nas
już na pierwszej rozmowie.

## Problemy, z którymi zgłaszają się do nas klienci

- Karty produktów ładujące się trzy sekundy mimo skonfigurowanego
  Varnisha i Redisa
- Checkout, który nie wytrzymuje kampanii, podczas gdy serwery
  pracują na 10% obciążenia; wąskie gardło prawie zawsze leży
  w kodzie albo w konfiguracji cache'a, a nie w sprzęcie
- Czterdzieści zainstalowanych rozszerzeń, połowa porzucona przez
  dostawców, a dwa z nich w konflikcie o ten sam observer
- Indeksery i crony w stanie, w którym sklep pokazuje stany
  magazynowe, których magazyn nie ma
- Aktualizacja odkładana tak długo, że każda łatka bezpieczeństwa
  stała się osobnym projektem

## Przykłady awarii, które naprawiliśmy

Ze sklepów, przy których pracowaliśmy przez lata, bez nazw:

- Rejestracje klientów przestały działać w weekend, bo tabela
  jednego z rozszerzeń wyczerpała wszystkie 4,29 miliarda
  identyfikatorów auto-increment, zawierając zaledwie pół miliona
  wierszy.
  Hotfix na BIGINT przywrócił rejestracje w ciągu godziny,
  a nadpisanie schematu sprawiło, że poprawka przeżywa aktualizacje.
- Zamówienia za pobraniem zaczęły po aktualizacji żądać płatności
  kartą: migracja schematu przebudowała tabelę i przesunęła ID
  wierszy, których stary moduł używał jako zaszytych na sztywno
  stałych. Znalezione przez porównanie surowych tabel między
  środowiskami.
- Stan dostępny do sprzedaży przez miesiące spadał poniżej
  rzeczywistego. Konektor marketplace'u zmieniał numery zamówień
  już po założeniu rezerwacji magazynowych, więc MSI nie mogło ich
  zwolnić. Dowiedliśmy tego anti-joinami na metadanych rezerwacji,
  naprawiliśmy łatką u dostawcy i cronem czyszczącym dane.
- Adresy przestały się zgadzać w ERP, bo zabezpieczenie Magento
  przed CSV injection bez ostrzeżenia dodaje spację przed każdą
  wartością zaczynającą się od „+”, czyli także przed numerami
  telefonów. Zdiagnozowane w kodzie źródłowym frameworka, naprawione
  composer patchem.
- Upload mediów działał na stagingu, a na produkcji nie. Eliminacja
  hipotez doprowadziła do jednego nieaktualnego wiersza
  konfiguracji, a samonaprawiający się data patch zagwarantował,
  że problem nie wróci.

## Co robimy

- **Audyty wydajności i przebudowy storefrontu.** Domyślnie
  rekomendujemy [Hyvä](https://hyva.io): wymienia cały zastany stack
  frontendowy i zwykle wprowadza wyniki Lighthouse w okolice 90. PWA Studio albo pełny headless tam, gdzie
  przypadek naprawdę tego wymaga.
- **Moduły na zamówienie i [integracje](/pl/services/integrations/)**
  z ERP, PIM, fulfillmentem, płatnościami i marketplace'ami, pisane
  idempotentnie i obserwowalnie, bo to w warstwie integracji Magento
  najczęściej dochodzi do awarii.
- **Aktualizacje wersji**, w tym ratowanie sklepów na Magento 1,
  migracje do Mage-OS i ograniczanie ryzyka aktualizacji między
  wersjami głównymi, z pełnym audytem rozszerzeń przed wprowadzeniem
  jakichkolwiek zmian.
- **Długoterminowe wsparcie operacyjne:** łatki bezpieczeństwa,
  monitoring, strojenie cache'a i inżynier on-call na ten dzień,
  w którym zapełni się tabela blokad w bazie. Wszystko w formie
  miesięcznego retainera,
  z [DevOps i infrastrukturą](/pl/services/devops/) pod spodem.

## Jak zwykle zaczyna się współpraca

Dla działającego sklepu naturalnym wejściem jest
[audyt wydajności](/pl/services/performance-audit/): stała, z góry
znana cena, realne pomiary i lista poprawek ułożona według priorytetów,
którą wykona dowolny zespół. Dla sklepu wciąż na Magento 1 albo kilka
wersji głównych do tyłu zaczynamy od analizy migracyjnej: co
przechodzi dalej, co piszemy od nowa i jak wygląda plan przełączenia.
W obu przypadkach zakres i cenę znasz na piśmie, zanim cokolwiek
trafi na fakturę.