Większość zleceń dotyczących Shopify zaczyna się od pytania "czy możesz po prostu zmienić motyw?". Czasem odpowiedź to dziesięć minut w edytorze motywów. Czasem zmiana dotyczy kasy albo logiki cen, czyli miejsc, do których kod motywu w ogóle nie sięga. Wtedy prawdziwy wybór jest między aplikacją z App Store, aplikacją własną z Shopify Functions, zmianą planu albo pogodzeniem się z tym, że Shopify na to nie pozwala. Wybór złej warstwy kończy się tak, że sklep płaci za obejście w motywie, które psuje się przy następnej aktualizacji, albo za aplikację własną, która działa tylko na planie, którego sklep nie ma.
Ten poradnik porządkuje zlecenia według warstwy, która naprawdę może je zrealizować. Każdy limit planu, data i liczba poniżej pochodzą z shopify.dev albo z Centrum pomocy Shopify i zostały sprawdzone 23 października 2026.
Co można zmienić w motywie Shopify bez programowania
Motywy Online Store 2.0 są zbudowane z szablonów JSON. Dokumentacja szablonów JSON opisuje je jako pliki danych, które przechowują listę sekcji i ich ustawienia, i podaje, że sprzedawcy “mogą dodawać, usuwać i zmieniać kolejność tych sekcji w edytorze motywów” (tłumaczenie własne). Szablon może wyświetlić do 25 sekcji, a każda sekcja może mieć do 50 bloków.
Spora część “dostosowania” to więc konfiguracja: przeniesienie bloku z opiniami wyżej, dodanie sekcji z tabelą rozmiarów do jednego szablonu produktu, złożenie strony docelowej z istniejących sekcji, zmiana kolorów i fontów w ustawieniach motywu. Jeśli twój motyw ma potrzebną sekcję, nikt nie musi pisać kodu. Wątek na r/shopify, w którym 23 października 2026 padło dokładnie to pytanie, ujął to w jednym zdaniu:
Sporo zleceń na “customowe” rzeczy okazuje się metapolem plus sekcją.
(u/Born_Programmer_1089, r/shopify, 23 października 2026, tłumaczenie własne)
Kolejny poziom to edycja Liquid, CSS i JavaScriptu w samym motywie. Tak powstaje nowy typ sekcji, własny szablon produktu, metapole wyświetlane na karcie produktu czy inny układ filtrów kolekcji. Strona pomocy o edycji kodu motywu mówi bez ogródek, ile to kosztuje: kod warto edytować tylko wtedy, “gdy nie da się wprowadzić potrzebnych zmian” w edytorze, a jeśli zmiany nie są zgodne z aktualizacją motywu, “wszystkie zmiany w kodzie zostaną usunięte w zaktualizowanej kopii” (tłumaczenie własne). Najpierw zduplikuj motyw i prowadź listę zmienionych plików, żeby następna aktualizacja była zwykłym scaleniem zmian, a nie wykopaliskami.
Równie ważne jest to, czego kod motywu nie zrobi. Odpowiada za wygląd sklepu. Nie działa podczas finalizacji zamówienia, nie zmienia sposobu naliczania rabatów i nie zablokuje złożenia zamówienia.
Aplikacja Shopify czy rozszerzenie motywu: kiedy są potrzebne
Opinie, zestawy produktów, doradcy rozmiaru, widżety programów lojalnościowych i podglądy 3D zwykle pochodzą z aplikacji. Nowoczesne aplikacje umieszczają to, co wyświetlają w sklepie, w rozszerzeniu motywu (theme app extension): to bloki Liquid, które sprzedawca wstawia w edytorze motywów. Shopify wprost wymienia korzyść: sprzedawcy “nie będą musieli ręcznie edytować kodu motywu”, a aplikacje “nie edytują kodu motywu, co zmniejsza ryzyko wprowadzenia zmian psujących motyw” (tłumaczenie własne). Rozszerzenia motywu współpracują z motywami Online Store 2.0, więc sklep na starszym motywie (vintage) traci tę czystą ścieżkę.
Dla właściciela sklepu wynikają z tego dwie zasady:
- Jeśli aplikacja z App Store robi to, czego potrzebujesz, i instaluje się przez bloki aplikacji, zwykle wychodzi taniej i bezpieczniej niż własny kod w motywie, bo utrzymuje ją dostawca aplikacji i przetrwa aktualizacje motywu.
- Jeśli programista proponuje ręczne wklejenie fragmentu kodu aplikacji do
theme.liquid, zapytaj, dlaczego aplikacja nie ma bloku. Ręcznie wklejone fragmenty zostają zwykle w motywie także po odinstalowaniu aplikacji.
Aplikacja własna ma sens, gdy logika jest specyficzna dla twojej firmy (synchronizacja z ERP, reguła cenowa, której nikt nie sprzedaje, etap akceptacji zamówień B2B) albo gdy każda z aplikacji w App Store pokrywa połowę wymagań i gryzie się z pozostałymi.
Shopify Functions: co robią i jaki plan jest potrzebny
Shopify Functions pozwalają programistom “dostosować logikę zaplecza Shopify, uruchamiając własny kod podczas finalizacji zamówienia” (tłumaczenie własne). To warstwa dla wszystkiego, co zmienia kwoty, dostawę albo decyduje, czy zamówienie może przejść dalej. Obecne API Functions:
- Discount: jedna funkcja może naliczać rabaty na produkty, zamówienie i wysyłkę
- Payment Customization: zmiana nazwy, kolejności albo ukrywanie metod płatności, ustawianie terminów płatności
- Delivery Customization: zmiana nazwy, sortowanie albo ukrywanie opcji dostawy
- Cart and Checkout Validation: blokowanie zamówienia z własnym komunikatem błędu
- Cart Transform: rozwijanie, łączenie albo aktualizowanie pozycji koszyka, na potrzeby zestawów
- Fulfillment Constraints i Order Routing
- Pickup Point i Local Pickup Delivery Option Generators
Funkcje kompilują się do WebAssembly, działają na serwerach Shopify i podlegają ścisłym limitom liczby instrukcji oraz rozmiaru danych wejściowych i wyjściowych. Właściciele sklepów najczęściej przeoczają regułę dotyczącą planu. Dokumentacja Shopify mówi, że “sklepy na każdym planie mogą korzystać z publicznych aplikacji dystrybuowanych przez Shopify App Store, które zawierają funkcje”, ale “tylko sklepy na planie Shopify Plus mogą korzystać z aplikacji własnych zawierających API Shopify Functions” (tłumaczenie własne).
W praktyce: reguła ukrywająca metodę płatności z aplikacji z App Store działa na planie Basic. Ta sama reguła napisana jako aplikacja własna tylko dla twojego sklepu wymaga planu Plus. Zanim zamówisz własną funkcję, sprawdź swój plan albo to, czy jakaś publiczna aplikacja już tego nie oferuje.
Są też limity na sklep. Shopify pozwala na maksymalnie 25 aktywnych funkcji w każdej z grup: rabaty, dostosowania płatności, dostosowania dostawy i walidacje. Sklepy z wieloma aplikacjami robiącymi podobne rzeczy mogą dobić do tego sufitu.
Shopify Scripts, starsze narzędzie Script Editor do logiki rabatów i wysyłki, to zamknięty rozdział. Strona pomocy Script Editor podaje, że od 30 czerwca 2026 Shopify Scripts “zostało wycofane”, opublikowane skrypty “zostały dezaktywowane i już nie działają” (tłumaczenie własne), a następcą jest Shopify Functions. Jeśli twoje progi cenowe po cichu przestały działać tego lata, to właśnie z tego powodu.
Ceny hurtowe w Shopify bez aplikacji
Sprzedaż hurtowa najlepiej pokazuje, dlaczego przed pisaniem czegokolwiek warto sprawdzić wbudowane funkcje Shopify. 22 października 2026 właściciel sklepu zapytał na r/shopify właśnie o to:
próbuję się zorientować, jakie rozwiązania stosowaliście tutaj, żeby dać hurtownikom niższą cenę niż klientom detalicznym. myślałem, że mógłbym stworzyć kod rabatowy, którego klient użyłby, żeby dostać stały rabat procentowy.
(u/GreenGloober, r/shopify, 22 października 2026, tłumaczenie własne)
Odpowiedzi objęły dwie z opisanych wyżej warstw. Jeden programista opisał drogę przez motyw: kod rabatowy ograniczony do segmentu klientów na etapie kasy plus sprawdzenie w Liquid na karcie produktu.
Otaguj klientów hurtowych (np. “wholesale”), zbuduj z tego tagu segment klientów i utwórz procentowy kod rabatowy ograniczony do tego segmentu, żeby nie wyciekł do klientów detalicznych. […] To naprawiasz w motywie: małe sprawdzenie w Liquid na customer.tags, które zalogowanym klientom hurtowym pokazuje cenę hurtową obok albo zamiast detalicznej. To tylko wyświetlanie, więc prawdziwą robotę w kasie i tak robi rabat.
(u/vladeta, r/shopify, 23 października 2026, tłumaczenie własne)
To działa przy stałym procencie, a najważniejsze jest ostrzeżenie “tylko wyświetlanie” (tłumaczenie własne): motyw pokazuje liczbę, rabat decyduje o kwocie do zapłaty, i te dwie wartości mogą się rozjechać. Ten sam komentarz nazwał potem natywne cenniki B2B funkcją planu Plus. Inna odpowiedź wskazała drogę wbudowaną:
dodaj hurtowników jako firmy, zrób katalog z twoim hurtowym rabatem procentowym i jak się zalogują, widzą swoją cenę na każdym produkcie. bez plusa masz limit 3 katalogów, ale to aż nadto, jeśli masz tylko jeden poziom hurtowy
(u/HoneyedVices, r/shopify, 23 października 2026, tłumaczenie własne)
Dokumentacja Shopify przyznaje rację drugiej odpowiedzi. Shopify B2B “jest dostępne w planach Basic, Grow, Advanced i Shopify Plus” (tłumaczenie własne), nie tylko w Plus. Klientów hurtowych zakładasz jako firmy i przypisujesz im katalogi z ich własnymi cenami.
Porównanie planów B2B pokazuje, czym plany się różnią:
| Funkcja B2B | Basic, Grow, Advanced | Plus |
|---|---|---|
| Aktywne katalogi B2B | Do 3, przypisywane przez rynki B2B | Bez limitu |
| Katalog przypisany bezpośrednio do firmy lub lokalizacji | Nie | Tak |
| Reguły ilościowe (minimum, maksimum, krok) | Tak | Tak |
| Progi cenowe zależne od ilości | Tak | Tak |
| Odroczone terminy płatności | Tak | Tak |
| Wymagana przedpłata (depozyt) | Nie | Tak |
Hurtownik z jednym cennikiem dla odbiorców i progami ilościowymi może więc na planie Basic nie potrzebować ani aplikacji, ani własnego kodu. Firma z osobną umową cenową dla każdego klienta potrzebuje bezpośredniego przypisania katalogów, czyli planu Plus, aplikacji cenowej albo własnej funkcji rabatowej w publicznej aplikacji. Nadpisywanie cen w koszyku ma osobną barierę: API Cart Transform podaje, że z aplikacji z operacjami lineUpdate mogą korzystać tylko sklepy deweloperskie albo sklepy na planie Plus.
Właściciele sklepów na WooCommerce, którzy porównują platformy, znają ten kompromis z drugiej strony: tam ceny dla konkretnego klienta to wtyczka albo własny kod PHP na dowolnym hostingu, bez progów planów, ale utrzymujesz to sam. Całą tę decyzję omawia nasze porównanie Shopify Plus i headless WooCommerce.
Czym zastąpiono checkout.liquid w Shopify
Kiedyś kasa była miejscem, gdzie sklepy na planie Plus swobodnie edytowały Liquid. To się skończyło etapami, a Shopify podaje dokładne daty:
- 13 sierpnia 2024: zmiany w checkout.liquid przestały działać na stronach Information, Shipping i Payment. Changelog Shopify zapowiadał, że sklepy, które nie zdążą przed terminem, zostaną “automatycznie przełączone na niedostosowaną, standardową kasę Shopify” (tłumaczenie własne).
- 28 sierpnia 2025: według dokumentacji checkout.liquid wygaszono go na stronach Thank you i Order status, a sklepom Plus wyłączono tam tagi script. Tego samego dnia pole dodatkowych skryptów stało się tylko do odczytu.
- 26 sierpnia 2026: termin, do którego sklepy spoza planu Plus musiały zaktualizować strony Thank you i Order status. Strona pomocy Shopify podaje, że aktualizacja zastępuje te strony i wszystkie istniejące na nich dostosowania.
W ich miejsce weszły węższe narzędzia. Rozszerzenia UI kasy (checkout UI extensions) dodają bloki zbudowane z komponentów Shopify, działające w izolowanej piaskownicy bez dostępu do “samej strony kasy (HTML ani innych zasobów)” (tłumaczenie własne). Śledzeniem zajmują się piksele (web pixels). Za wygląd odpowiadają ustawienia brandingu i Checkout Branding API. Logikę obsługują Functions.
Granica planów przebiega przez środek kasy. Strona o dostosowaniu kasy podaje, że “zaawansowane funkcje dostosowania kasy są dostępne tylko w planie Shopify Plus” (tłumaczenie własne), i wymienia jako funkcje Plus aplikacje zmieniające strony Information, Shipping i Payment oraz Checkout Branding API. Standardowe dostosowania są dostępne od planu Basic wzwyż.
Które funkcje Shopify są tylko w planie Plus
Na podstawie cytowanych wyżej stron to elementy dostępne tylko w Plus, które najczęściej przesądzają o projekcie:
- Aplikacje własne zawierające Shopify Functions (publiczne aplikacje z App Store z funkcjami działają na każdym planie)
- Rozszerzenia UI kasy na krokach Information, Shipping i Payment
- Checkout Branding API
- Operacje
lineUpdatew Cart Transform, służące do nadpisania ceny, nazwy albo zdjęcia pozycji koszyka - Terminy płatności ustawiane przez funkcję dostosowania płatności oraz ukrywanie konkretnych miejsc wyświetlania płatności
- Katalogi B2B bez limitu, bezpośrednie przypisanie katalogu do firmy, wymagana przedpłata
To, czego nie ma na liście, i tak może mieć jakiś niuans zależny od planu. Shopify zmienia te strony, więc sprawdzaj samą stronę w dniu wyceny zakresu, a nie wpis na blogu sprzed roku, łącznie z tym.
Czy Shopify w ogóle pozwala na taką zmianę
Pierwsza odpowiedź w tym samym wątku dodała krok, który większość list decyzyjnych pomija:
Najpierw sprawdź, czy Shopify w ogóle pozwala na zmianę, którą chcesz wprowadzić. Na przykład zmiana wyglądu strony produktu to coś zupełnie innego niż wymuszenie reguły zakupowej w kasie. Do pierwszego może wystarczyć edycja motywu, a drugie może wymagać Shopify Functions albo zgodnej aplikacji.
(u/kunalkhatri12, r/shopify, 23 października 2026, tłumaczenie własne)
Niektóre zlecenia rozbijają się o zasady platformy, zanim w ogóle dojdzie do rozmowy o budżecie. Shopify dokumentuje kilka z nich:
- Żadnego dowolnego kodu w kasie. Rozszerzenia UI kasy “są ograniczone do konkretnych komponentów UI i API udostępnionych przez platformę” (tłumaczenie własne) i działają w Web Workerze bez dostępu do DOM. Projektu, który wymaga wstrzyknięcia własnego skryptu w krok płatności, nie da się zbudować.
- Sortowanie dostaw ma dolną granicę. API Delivery Customization podaje, że “najtańsza opcja wysyłki zawsze musi być pierwszą zaznaczoną opcją” (tłumaczenie własne).
- Ukrywanie dostawy na skrytki pocztowe działa tylko częściowo. Według tej samej dokumentacji funkcja może ukryć opcję wysyłki na skrytkę (PO Box) wyłącznie wtedy, gdy opcję dostarcza usługa przewoźnika albo zewnętrzna aplikacja wysyłkowa. Stawek wysyłki wpisanych ręcznie w ustawieniach sklepu ta reguła nie obejmie.
- Funkcja nie może zachowywać się losowo. Dokumentacja Shopify Functions mówi wprost, że Shopify nie dopuszcza w funkcjach niedeterminizmu, a do debugowania nie da się pisać na STDOUT ani STDERR. Losowanie typu “co dziesiąty klient dostaje rabat” odpada, a dane potrzebne regule, na przykład próg z metapola, trzeba podać funkcji na wejściu.
- Subskrypcje blokują część logiki. Cart Transform odrzuca operacje expand, merge i update, gdy w koszyku jest plan sprzedaży (selling plan), a dostosowanie płatności nie może ustawić terminów płatności, gdy koszyk zawiera produkty w subskrypcji.
- Połączenia sieciowe z funkcji są ograniczone. W funkcjach rabatowych zapytania fetch mogą wysyłać tylko aplikacje własne w sklepach Plus i Enterprise, a w funkcjach walidacji tylko aplikacje własne w sklepach Enterprise.
Dziesięć minut czytania odpowiedniej strony na shopify.dev przed wyceną chroni przed dobrze znanym scenariuszem: funkcja jest opisana, zaprojektowana i w połowie zbudowana, a potem trafia do kosza, bo platforma nigdy na nią nie pozwalała. Gdy Shopify mówi “nie”, uczciwe opcje to inny przebieg zakupu, zewnętrzny krok przed kasą albo platforma, na której kod kasy należy do ciebie. Posiadanie własnego kodu ma cenę, którą programiści zwykle zaniżają. W wątku z 18 października doświadczony programista pytał, czy budować sklepy klientów na Shopify, czy na własnym hostingu, bo na Shopify “czuje się, jakby pracował w pudełku” (tłumaczenie własne). Jedna z odpowiedzi przyszła od kogoś, kto prowadził wiele wdrożeń na zamówienie:
W swojej karierze nadzorowałem mnóstwo wdrożeń headless i na zamówienie. Bardzo niewiele z nich powinno było tak powstać, a w 2026 dotyczy to tym bardziej. To wyjątkowe wymagania uzasadniają złożoność.
(u/pjmg2020, r/shopify, 19 października 2026, tłumaczenie własne)
Jeśli twoje wymaganie naprawdę jest wyjątkowe, na przykład logika kasy, na którą Shopify nie pozwala, nasz przewodnik po migracji z Shopify do WooCommerce opisuje, z czym wiąże się przeprowadzka.
Motyw, aplikacja, Functions czy Plus: tabela decyzyjna
| Czego potrzebujesz | Warstwa, która to zapewnia | Wymagany plan |
|---|---|---|
| Przestawienie sekcji, nowa strona docelowa z istniejących sekcji | Edytor motywów | Dowolny |
| Nowy typ sekcji, wyświetlanie metapól, własny szablon produktu | Kod motywu (Liquid) | Dowolny |
| Opinie, widżet zestawów, wyświetlanie programu lojalnościowego | Aplikacja z rozszerzeniem motywu | Dowolny |
| Ukrycie albo zmiana nazwy metody płatności lub dostawy | Publiczna aplikacja z funkcją albo aplikacja własna | Dowolny dla aplikacji publicznej; Plus dla aplikacji własnej |
| Blokada zamówienia według reguły (minimalna ilość, ograniczenie adresu) | Funkcja walidacji | Dowolny dla aplikacji publicznej; Plus dla aplikacji własnej |
| Progi rabatowe albo rabaty dla konkretnych klientów | Funkcja rabatowa | Dowolny dla aplikacji publicznej; Plus dla aplikacji własnej |
| Jeden cennik hurtowy z progami ilościowymi | Shopify B2B, wbudowane | Basic lub wyższy |
| Osobne ceny dla każdego klienta hurtowego | B2B z bezpośrednim przypisaniem katalogu | Plus |
| Własny blok na kroku Information, Shipping lub Payment | Rozszerzenie UI kasy | Plus |
| Własny blok na stronie Thank you lub Order status | Rozszerzenie UI kasy | Sprawdź aktualną stronę dla swojego planu |
| Skrypt wstrzyknięty w HTML kasy | Niemożliwe na Shopify | Żaden |
Jak zlecić pracę programiście Shopify
Opisz zlecenie jako efekt: “klienci hurtowi z Niemiec widzą ceny netto i muszą zamawiać w kartonach po sześć sztuk” to brief, a “dodaj skrypt do koszyka” to zgadywanie rozwiązania. Podaj swój plan, zainstalowane aplikacje i informację, czy korzystasz z subskrypcji albo B2B. Jedna z odpowiedzi w wątku decyzyjnym dodała nawyk, który warto przejąć:
Zanim się zobowiążesz, zapisz dokładną regułę prostym językiem, z kilkoma przypadkami testowymi.
(u/Muted_Jellyfish_6784, r/shopify, 23 października 2026, tłumaczenie własne)
Poproś, żeby wycena oddzielała budowę od bieżącego utrzymania. Kod motywu, funkcje i rozszerzenia kasy wymagają kogoś, kto je zaktualizuje, gdy Shopify zmieni wersję API.
Jeśli wychodzi praca w motywie, programista Shopify zwykle oszacuje ją na podstawie listy szablonów. Jeśli praca dotyczy kasy, cen albo zakupów realizowanych przez agentów, zmienia też to, jak narzędzia zakupowe AI odczytują twój sklep i kupują w nim, a to sprawdza nasza usługa gotowości na handel z AI. Przewodnik po Universal Commerce Protocol wyjaśnia, jak agenci AI zmieniają sposób, w jaki ludzie kupują w internecie.
