Wstęp: część zaawansowana
Ta część słownika jest dla Ciebie, jeśli utrzymujesz stronę z developerem, czytasz logi błędów albo rozmawiasz o API, cache i headless – zakłada podstawy z części pierwszej i idzie krok głębiej.
Jeśli czegoś tu nie ma, zacznij od Słowniczka pojęć WordPress – część 1 (podstawowy). Konwencja hasła jak wcześniej: definicja, praktyka, typowe nieporozumienie.
Tip: Traktuj tę część jak leksykon do briefu – nie musisz „umieć wszystkiego”, ale rozumiesz słowa, którymi operuje zespół techniczny.
Infrastruktura i środowiska
Produkcyjna witryna to tylko jedna z warstw: obok niej bywa staging, dostęp SSH, katalogi WordPressa i harmonogram zadań – bez tego słownika trudno czytać procedury migracji czy audytu.
Staging vs produkcja (*staging*, *production*)
Definicja: Produkcja – środowisko widoczne dla użytkowników; staging – kopia do testów aktualizacji, motywu lub treści przed wdrożeniem „na żywca”.
W praktyce: Większe zmiany przechodzą staging → QA → merge na produkcję; patrz też przewodnik po migracji WordPressa przy przenosinach między serwerami.
Nieporozumienie: „Kopia zapasowa na dysku” to nie staging – staging musi działać jako serwis WWW z własną konfiguracją URL-i.
SSH (*Secure Shell*)
Definicja: Szyfrowany terminalowy dostęp do serwera – komendy powłoki, często potrzebny do WP-CLI, diagnostyki lub rsync.
W praktyce: Na shared hostingu SSH bywa opcjonalny; na VPS prawie zawsze obecny.
Nieporozumienie: SSH to nie panel graficzny hostingu – to osobny kanał umiejętności (i odpowiedzialności).
wp-content i uploads
Definicja: wp-content – katalog na motywy, wtyczki, języki i (domyślnie) media; wp-content/uploads – zwykle roczne podfoldery z plikami mediów z biblioteki.
W praktyce: Przy przenosinach serwera uploads bywa najcięższy objętościowo obok bazy.
Nieporozumienie: „Wyczyszczenie uploads” nie usuwa wpisów z bazy – zostawisz wtedy „martwe” odnośniki do plików.
WP-Cron vs cron systemowy (*WP-Cron*, *system cron*)
Definicja: WP-Cron – mechanizm WordPressa uruchamiany przy wejściu na stronę, który odpala zaplanowane zadania (publikacja zaplanowana, kolejka wtyczek). Cron systemowy – harmonogram po stronie serwera (crontab), niezależny od ruchu na stronie.
W praktyce: Na stronach z małym ruchem często ustawia się prawdziwy cron wywołujący wp-cron.php, by zadania odpalały się punktualnie.
Nieporozumienie: „Cron nie działa” ≠ „WordPress się zepsuł” – często brak ruchu albo zablokowany outbound na serwerze.
Multisite (*WordPress Multisite*)
Definicja: Jedna instalacja WordPressa obsługująca wiele witryn (subdomeny lub ścieżki) ze wspólnym rdzeniem i często wspólnymi użytkownikami.
W praktyce: Sieci agencji lub wydawnictw; wyższy próg złożoności niż pojedyncza instancja.
Nieporozumienie: Multisite to nie „kilka osobnych WordPressów w jednym FTP” – to jedna baza z prefiksami blogów i osobną konfiguracją uprawnień super admina.
Ważne: Zmiana URL-i między stagingiem a produkcją bez planu to klasyczny źródłowy błąd przy migracji – trzymaj się checklisty z poradnika migracji.
Rdzeń, konfiguracja, diagnostyka
Tu pojawiają się pliki i stałe, których nie dotykasz codziennie z kokpitu, ale które definiują zachowanie WordPressa w środowisku produkcyjnym i developerskim.
wp-config.php
Definicja: Główny plik konfiguracyjny instalacji: dane do bazy, prefiks tabel, klucze soli, często stałe środowiskowe.
W praktyce: Edytujesz go przez FTP/SSH lub edytor w panelu hostingu; przed zmianą zawsze kopia.
Nieporozumienie: „Wklejam snippet z internetu do wp-config” bez testu na kopii – łatwy sposób na białą stronę składniową.
WP_DEBUG, DISALLOW_FILE_EDIT i pokrewne stałe
Definicja: WP_DEBUG – włącza szczegółowe komunikaty błędów PHP dla developerów (na produkcji zwykle wyłączone lub z kierowaniem do logu). DISALLOW_FILE_EDIT – wyłącza edytor plików motywu/wtyczki z kokpitu.
W praktyce: Diagnostyka: debugowanie WordPressa i logi błędów; przy białym ekranie zob. naprawa białego ekranu śmierci.
Nieporozumienie: WP_DEBUG „na produkcji bez logów” może wyświetlać ostrzeżenia gościom – to zła praktyka bezpieczeństwa i UX.
Rewizje (*revisions*)
Definicja: Historia zapisanych wersji wpisu/strony w bazie, umożliwiająca podgląd i przywrócenie.
W praktyce: Rozsądna historia ratuje przed utratą treści; nadmierna liczba rewizji potrafi puchnąć bazą na bardzo aktywnych witrynach.
Nieporozumienie: „Usuń wszystkie rewizje wtyczką optymalizacyjną na produkcji bez backupu” – ryzykowne, jeśli nie wiesz, co dokładnie robi skrypt.
Transients (*transients*)
Definicja: Tymczasowe dane w bazie (z opcjonalnym czasem wygaśnięcia), które wtyczki i motywy wykorzystują jako cache lub bufor wyników.
W praktyce: Czasem czyścisz transients przy „dziwnych” cache’ach wtyczek – robią to też dedykowane narzędzia serwisowe.
Nieporozumienie: Transients to nie „to samo co object cache” – to warstwa danych w bazie, nie pamięć RAM serwera.
Logi błędów (*error logs*)
Definicja: Pliki tekstowe lub strumienie zapisujące ostrzeżenia PHP, fatal errors i czasem błędy serwera WWW.
W praktyce: Czytasz log w panelu hostingu albo w wp-content/debug.log, jeśli skonfigurowano zapis debugowania do pliku.
Nieporozumienie: Brak wpisu w logu nie dowodzi, że „nic się nie dzieje” – część błędów trafia tylko do logu serwera WWW poza WordPressem.
Key Takeaways:
wp-config.phpto przełącznik środowiska – edycja na żywym serwisie wymaga dyscypliny i kopii.- WP_DEBUG na produkcji zawsze pod kontrolą (log, nie echo).
Model treści i danych (zaawansowane)
Poza postami i stronami WordPress pracuje na typach treści, taksonomiach i metadanych – to fundament pod sklepy, katalogi i „kafelki” z polami niestandardowymi.
Taksonomia i archiwum taksonomii (*taxonomy*, *taxonomy archive*)
Definicja: Taksonomia – sposób grupowania treści (kategorie, tagi, lub własne typy); archiwum – widok listy wpisów przypisanych do danego termu taksonomii.
W praktyce: Decydujesz, czy archiwum ma być indeksowane w Google (wtyczki SEO pozwalają sterować noindex).
Nieporozumienie: „Tag SEO” na 300 pustych stronach archiwum to techniczny dług, nie „bonus pod pozycjonowanie”.
Załącznik i strony załączników (*attachment*, *attachment pages*)
Definicja: Każdy plik w bibliotece ma rekord typu attachment; motywy potrafiły tworzyć osobne, cienkie strony pod URL samego obrazka.
W praktyce: Wiele serwisów wyłącza lub przekierowuje strony załączników, by nie konkurowały z treścią główną.
Nieporozumienie: „Usunięcie obrazka z FTP” bez posprzątania bazy i treści zostawia 404 w treści artykułów.
Custom Post Type – CPT (*custom post type*)
Definicja: Dodatkowy typ treści (np. Realizacja, Produkt w sensie katalogowym poza Woo), z własnym menu w kokpicie i często własnymi szablonami.
W praktyce: CPT definiuje developer w kodzie lub przez wtyczkę typu CPT UI – potem łączysz go z taksonomią.
Nieporozumienie: CPT to nie „lepsza strona” – to narzędzie modelowania danych; źle zaprojektowany CPT utrudnia migrację.
Pola meta i ACF (*post meta*, *custom fields*)
Definicja: Meta – pary klucz/wartość przypisane do wpisu/strony/CPT; ACF to popularna wtyczka budująca na meta warstwę pól w UI.
W praktyce: Szablony motywów czytają meta przez API WordPressa i budują z nich layout.
Nieporozumienie: „Wpiszę wszystko w meta JSON 50 MB” – wydajność i backupy cierpią; projektuj pola z głową.
Tip: Gdy słyszysz „musimy dodać CPT”, dopytaj o listę pól, taksonomie i URL-e archiwum – to trzy rzeczy, które definiują 80% pracy.
Motywy i Full Site Editing (FSE)
Motywy blokowe i Site Editor przenoszą część decyzji z Customizera do szablonów JSON i edytora witryny – inny model pracy niż klasyczny motyw PHP.
Motyw potomny (*child theme*)
Definicja: Motyw dziedziczący funkcjonalność rodzica, pozwalający nadpisywać style i pliki bez edycji motywu nadrzędnego.
W praktyce: Zob. motyw potomny – personalizacja i zalety.
Nieporozumienie: Child theme nie „aktualizuje rodzica” – tylko chroni Twoje nadpisania przy update rodzica.
Site Editor i FSE (*Site Editor*, *Full Site Editing*)
Definicja: Edycja szablonów całej witryny (nagłówek, stopka, archiwa) w interfejsie blokowym; FSE to paradygmat, w którym motyw dostarcza bloki i style globalne.
W praktyce: W motywach blokowych część rzeczy z Wygląd → Edytor zastępuje stary podział „Customizer vs pliki PHP”.
Nieporozumienie: FSE nie usuwa potrzeby testów wydajnościowych – tylko zmienia, gdzie siedzą decyzje layoutu.
Szablon (template) i część szablonu (template part)
Definicja: Szablon – układ dla typu widoku (np. pojedynczy wpis); template part – wielokrotnie używany fragment (np. nagłówek HTML w blokach).
W praktyce: Deweloper motywu układa je w plikach HTML w repozytorium motywu blokowego.
Nieporozumienie: „Szablon strony” w edytorze treści to nie zawsze „template” w sensie FSE – WordPress rozróżnia szablon strony i szablon witryny.
Motyw blokowy (*block theme*) vs motyw klasyczny
Definicja: Motyw blokowy – oparty o theme.json i szablony blokowe; klasyczny – cięższy w PHP, functions.php, hierarchia szablonów .php.
W praktyce: Migracja między modelami bywa projektem, nie „przyciskiem przełącznika”.
Nieporozumienie: „Zainstalujemy blokowy motyw i będzie jak dawniej” – często wymaga przebudowy widgetów i menu pod nowe sloty.
Ważne: Stan funkcji Gutenberga / Site Editora zmienia się z wersją WordPressa – przy audycie zapisuj numer rdzenia i motywu (stan na 2026 w dokumentacji projektu).
Rozszerzalność kodu (słownik developera)
WordPress rozszerza się przez hooki, pliki motywu i wtyczki – zrozumienie tego słownika pomaga czytać snippet’y z GitHuba bez zgadywania.
Hooki: action i filter
Definicja: Action – punkt, w którym możesz „podpiąć” własny kod wykonywany w konkretnym momencie cyklu życia żądania. Filter – punkt, w którym przekazuje się dane przez funkcję modyfikującą i zwraca zmienioną wartość.
W praktyce: Wtyczki robią add_action / add_filter w swoim bootstrapie.
Nieporozumienie: „Wklejam ten sam kod do header.php i do functions.php” – duplikacja i nieprzewidywalna kolejność wykonania.
functions.php
Definicja: Plik motywu ładowany przy starcie, w którym rejestruje się style, hooki i wsparcie motywu.
W praktyce: Logika „biznesowa” wtyczek nie powinna żyć w motywie – motyw się zmienia, wtyczki zostają.
Nieporozumienie: Gigantyczny functions.php bez modularności to dług techniczny, nie „oszczędność na wtyczce”.
MU-plugin i drop-in (*must-use plugin*, *drop-in*)
Definicja: MU-plugin – wtyczka w wp-content/mu-plugins, zawsze aktywna, nie z kokpitu. Drop-in – plik o szczególnej nazwie (np. object-cache.php) podmieniający zachowanie rdzenia w konkretnym obszarze.
W praktyce: Hostingi enterprise wrzucają tam integracje cache lub logowania.
Nieporozumienie: MU-plugin to nie „szybsza wtyczka” – to narzędzie polityki wdrożeniowej (nie da się wyłączyć z UI).
Shortcode (*shortcode*)
Definicja: Makro w treści posta, np. 
W praktyce: Starsze wtyczki budowały na shortcode’ach całe layouty – dziś częściej bloki.
Nieporozumienie: Shortcode w treści Gutenberga bywa w klasycznym bloku – mieszanie modeli utrudnia migrację do czystych bloków.
REST API jako kanał danych (*REST API*)
Definicja: HTTP JSON-owe endpointy wbudowane w WordPressa (i rozszerzane przez wtyczki), służące do odczytu i zapisu treści z zewnętrznych aplikacji.
W praktyce: Podstawa pod headless, aplikacje mobilne i automatyzacje.
Nieporozumienie: REST API „włączone” nie znaczy automatycznie „publicznie udostępnione wszystko” – nadal obowiązują uprawnienia i nonces przy mutacjach.
Tip: Jeśli developer mówi „podpinamy się pod
init”, chodzi o wczesny action hook – nie o inicjalizację bazy w sensie DBA.
Wydajność i pomiary
Wydajność to warstwa: PHP, baza, motyw, wtyczki, cache, CDN i front – słownik poniżej pomaga rozdzielić pojęcia przy rozmowie z hostingiem.
Cache strony vs object cache (*page cache*, *object cache*)
Definicja: Page cache – gotowy HTML (lub odpowiedź z cache edge) serwowany bez pełnego przebiegu PHP. Object cache – trwałe lub ulotne cache’owanie obiektów PHP (np. wyników zapytań) zwykle na Redis/Memcached.
W praktyce: Zob. kompletny przewodnik po optymalizacji szybkości oraz podstawy prędkości strony.
Nieporozumienie: „Włączyłem cache wtyczką” nie rozwiązuje złego zapytania N+1 w szablonie – tylko maskuje objawy.
TTFB (*Time to First Byte*)
Definicja: Czas od żądania do pierwszego bajtu odpowiedzi serwera – mierzy m.in. PHP, bazę i ścieżkę sieciową do pierwszego hopu.
W praktyce: Wysoki TTFB często wymaga profilu po stronie hostingu i zapytań, nie tylko „optymalizacji obrazków”.
Nieporozumienie: TTFB to nie to samo co LCP – LCP dotyczy renderu największego elementu treści w przeglądarce.
Core Web Vitals: LCP, INP, CLS (*Core Web Vitals*)
Definicja: Zestaw metryk jakości UX w Chrome: LCP (largest contentful paint), INP (interaction to next paint), CLS (cumulative layout shift).
W praktyce: Mierzysz w PageSpeed Insights / CrUX; problemy bywają po stronie motywu, czcionek, reklam i JS.
Nieporozumienie: „Zielony PSI na komórce w laboratorium” nie gwarantuje dobrego doświadczenia w polu – patrz też dane rzeczywych użytkowników.
Lazy load i minifikacja (*lazy loading*, *minification*)
Definicja: Lazy load – odkładanie ładowania obrazów poza viewportem; minifikacja – usuwanie zbędnych znaków z CSS/JS bez zmiany działania.
W praktyce: Używasz rozsądnie – zbyt agresywny lazy load psuje LCP.
Nieporozumienie: Minifikacja nie zastępuje redukcji liczby żądań HTTP do trackerów zewnętrznych.
CDN w kontekście cache edge
Definicja: Sieć brzegowa może cachować statyczne odpowiedzi lub (przy odpowiedniej konfiguracji) pełne strony HTML.
W praktyce: Inwalidacja cache CDN musi być zsynchronizowana z publikacją treści – inaczej redaktor „nie widzi zmian”.
Nieporozumienie: CDN nie naprawia wolnego zapytania SQL w panelu admina – dotyczy głównie ruchu publicznego.
Key Takeaways:
- Rozdziel TTFB (serwer) od LCP (treść w przeglądarce).
- Object cache pomaga przy ciężkich zapytaniach – nie zastępuje architektury treści.
Bezpieczeństwo (terminologia)
Poniżej same nazwy zagrożeń i kontrolek – procedury masz w dłuższych artykułach z kategorii WordPress security / Bezpieczeństwo WordPress.
Brute force (*brute-force attack*)
Definicja: Automatyczne zgadywanie haseł logowania masą prób.
W praktyce: Ograniczenie prób, 2FA, WAF – warstwy opisane m.in. w wtyczkach firewall dla WordPressa i 2FA.
Nieporozumienie: „Ukryte wp-admin” jako jedyna obrona to obfuscation, nie bezpieczeństwo w sensie kryptograficznym.
XSS, SQLi, CSRF (*cross-site scripting*, *SQL injection*, *cross-site request forgery*)
Definicja: XSS – wstrzyknięcie skryptu w treść wyświetlaną innym; SQLi – manipulacja zapytaniem SQL; CSRF – podsunięcie żądania wykonanego w kontekście zalogowanego użytkownika.
W praktyce: Nonce i sanityzacja danych to standard w formularzach i REST.
Nieporozumienie: „Mamy SSL więc jesteśmy bezpieczni przed XSS” – SSL nie chroni przed złym escapowaniem HTML.
Nonce (*nonce*)
Definicja: Jednorazowy token WordPressa chroniący formularze i żądania admina przed CSRF.
W praktyce: Wtyczki dodają nonce do AJAX; błąd „nonce invalid” często oznacza wygasłą sesję lub cache strony admina.
Nieporozumienie: Nonce to nie „szyfrowanie hasła użytkownika” – to osobny mechanizm.
CVE i hardening (*CVE*, *hardening*)
Definicja: CVE – publiczny identyfikator podatności; hardening – zestaw działań redukujących powierzchnię ataku (np. wyłączenie edycji plików z kokpitu).
W praktyce: Monitoring CVE wtyczek, które realnie używasz, jest tańszy niż gaszenie po włamaniu.
Nieporozumienie: „Zero CVE w skanerze” nie gwarantuje bezpieczeństwa – skanery nie widzą logiki biznesowej.
WAF i malware (*web application firewall*, *malware*)
Definicja: WAF – filtr żądań HTTP pod znane sygnatury ataków; malware – złośliwy kod na hostingu (często w PHP w uploads lub w zmodyfikowanych wtyczkach).
W praktyce: Czyszczenie: usuwanie malware z WordPressa.
Nieporozumienie: WAF na poziomie CDN nie zastępuje aktualizacji podatnej wtyczki – tylko daje czas na patch.
Backup vs restore (*backup*, *restore*)
Definicja: Backup – kopia; restore – przywrócenie stanu z kopii.
W praktyce: Tworzenie i przywracanie kopii zapasowych WordPressa.
Nieporozumienie: „Mamy snapshot sprzed tygodnia” nie pomaga, jeśli malware siedzi od trzech tygodni – głębokość retencji ma znaczenie.
Ważne: 2FA na koncie administratora to jedna z najtańszych kontroli pod kątem ryzyka – wdrożenie opisujemy w przewodniku po dwuetapowej weryfikacji.
Headless i nowoczesny frontend
Oddzielenie CMS od frontendu zmienia słownik: API, tokeny, strategie renderu – poniżej minimum pojęć przy briefie headless.
Headless i decoupled (*headless*, *decoupled*)
Definicja: Headless – WordPress serwuje treść przez API, a prezentację robi osobna aplikacja. Decoupled – szersze rozdzielenie warstw, czasem z częściowym SSR klasycznym.
W praktyce: Decyzja architektoniczna, nie „przycisk w kokpicie”.
Nieporozumienie: „Headless = szybciej zawsze” – bez cache i dobrego hostingu frontendu bywa wolniej niż dobrze zestrojony klasyczny stack.
REST a GraphQL (*REST API*, *GraphQL*)
Definicja: REST – zasoby pod URL-ami HTTP z JSON; GraphQL – jeden endpoint, klient wybiera pola w zapytaniu (często przez WPGraphQL).
W praktyce: GraphQL bywa wygodny przy złożonych widokach mobilnych, REST przy prostych integracjach.
Nieporozumienie: GraphQL nie jest „bezpieczniejszy domyślnie” – wymaga świadomej konfiguracji uprawnień i limitów.
Endpoint, token, OAuth (*endpoint*, *token*, *OAuth*)
Definicja: Endpoint – konkretny URL API; token – dowód tożsamości aplikacji/użytkownika w żądaniu; OAuth – protokół autoryzacji delegowanej (często przy logowaniu zewnętrznym).
W praktyce: Application Passwords w WP to osobny mechanizm od „hasła do kokpitu”.
Nieporozumienie: Wklejanie tokenów do repozytorium Git to incydent czekający na minutę.
SSR, SSG, ISR (*server-side rendering*, *static site generation*, *incremental static regeneration*)
Definicja: SSR – HTML generowany przy żądaniu; SSG – HTML budowany wcześniej (deploy); ISR – hybryda odnawiania statycznych stron wg reguł (pojęcie z ekosystemu np. Next.js).
W praktyce: Wybór strategii wpływa na to, jak szybko widać zmiany z CMS i jak obciążony jest origin.
Nieporozumienie: „Static” nie znaczy „bez bazy” po stronie WP – znaczy statyczny frontend konsumujący API.
Tip: Przy headless zawsze dopisz w briefie: źródło prawdy dla URL-i (WP vs frontend) oraz model preview treści dla redakcji.
E-commerce (terminologia)
WooCommerce nakłada na WordPressa model zamówień i produktów – poniżej słowa, które padają w integracjach płatności i fulfillmentu.
WooCommerce (*WooCommerce*)
Definicja: Najpopularniejsza wtyczka e-commerce na WordPressie – CPT produktów, koszyk, checkout, integracje płatności.
W praktyce: Wymaga dbałości o wydajność (np. tabela koszyka, sesje) i compliance (RODO, faktury – poza tym słownikiem).
Nieporozumienie: „Woo = gotowy sklep” – nadal potrzebujesz konfiguracji podatku, wysyłki, bramki i szablonów maili.
Produkt i wariant (*product*, *variation*)
Definicja: Produkt prosty – jeden SKU; wariant – produkt zmienny (rozmiar/kolor) z własnym SKU i ceną.
W praktyce: Warianty generują więcej rekordów w bazie i więcej URL-i do opieki SEO.
Nieporozumienie: Atrybut produktu ≠ taksonomia blogowa – to osobny model danych Woo.
Koszyk, checkout, bramka płatności (*cart*, *checkout*, *payment gateway*)
Definicja: Koszyk – tymczasowy zbiór pozycji; checkout – proces składania zamówienia; bramka – integracja z operatorem płatności (Stripe, Przelewy24 itd.).
W praktyce: Testuj checkout w trybie sandbox przed kampanią.
Nieporozumienie: „SSL mamy, więc PCI nas nie dotyczy” – uproszczenie; rozliczenia PCI zależą od modelu (hosted fields vs formularz na stronie).
Zamówienie i webhook (*order*, *webhook*)
Definicja: Zamówienie – rekord zakupu ze statusem (np. processing, completed). Webhook – wywołanie HTTP z powiadomieniem do zewnętrznego systemu (ERP, fulfillment) przy zdarzeniu.
W praktyce: Webhooki muszą być idempotentne i zabezpieczone przed powtórkami.
Nieporozumienie: Webhook to nie „cron” – to push zdarzenia, choć czasem retry wygląda podobnie.
Ważne: Motywy pod sklep to osobny temat wyboru layoutu – zob. Top 10 motywów WordPress do sklepów online jako punkt startu researchu, nie jako jedyną prawdę.
Proces i DevOps (hasła z briefu agencji)
Gdy pojawia się Git, Composer i pipeline CI/CD, projekt WordPressa przestaje być tylko „panelem w przeglądarce” i staje się repozytorium artefaktów.
CI/CD (*continuous integration*, *continuous delivery*)
Definicja: Automatyczne budowanie, testowanie i wdrażanie zmian po pushu do repozytorium.
W praktyce: Zmniejsza ryzyko „działa u mnie na laptopie” na stagingu i produkcji.
Nieporozumienie: CI/CD bez testów regresji UI nadal pozwala wywieźć regresję wizualną.
Repozytorium Git (*Git repository*)
Definicja: Historia commitów z kodem motywu, wtyczek własnych lub całego monorepo projektu.
W praktyce: Pliki generowane przez WordPressa (uploads, cache) zwykle nie commitujesz.
Nieporozumienie: „Wrzucę cały wp-content do Git” – szybki sposób na gigantyczne repo i sekrety w historii.
Composer i npm (*Composer*, *npm*)
Definicja: Composer – menedżer zależności PHP; npm – menedżer paczek JavaScript (build motywów, bundlery).
W praktyce: Motywy nowoczesne budują assety przez npm run build, a PHP biblioteki ładuje Composer.
Nieporozumienie: node_modules na produkcji serwera współdzielonego bez izolacji bywa problemem bezpieczeństwa i miejsca.
Key Takeaways:
- Git chroni kod, nie zastępuje backupu bazy i uploadów.
- CI/CD bez dokumentacji rollbacku to wdrożenie tylko w połowie.
Podsumowanie
Druga część słownika domyka infrastrukturę, diagnostykę, model danych, motywy blokowe, hooki, wydajność, bezpieczeństwo, headless, Woo oraz DevOps – czyli słowa, które padają przy utrzymaniu i rozwoju serwisu, nie przy pierwszym logowaniu redaktora.
Jeśli któreś pojęcie wydaje się zbyt techniczne, wróć do części 1 albo napisz do nas – pomożemy przełożyć brief na konkretny plan prac.
Ważne: Wersja produkcyjna i staging to dwa światy – trzymaj w dokumentacji projektu adresy obu oraz to, która baza jest „źródłem prawdy” przed migracją.
