Wdrażanie WordPressa w 2026: FTP kontra SSH i Git | WPPoland

Mariusz Szatkowski

Porzuć FTP: nowoczesne wdrażanie WordPressa przez SSH, Git i klucze

Ostatnio zweryfikowano: 12 października 2026

16 min czytania

Przewodnik

Jeśli nadal przeciągasz pliki PHP do FileZilli i modlisz się, żeby łącze wytrzymało, wdrażasz tak, jak robiło się to w 2008 roku. W wppoland.com przenieśliśmy dziesiątki stron klientów z pracy opartej na FTP i różnica w niezawodności, bezpieczeństwie i spokoju programistów jest jak dzień i noc. Ten przewodnik prowadzi przez każdą warstwę nowoczesnego procesu wdrażania WordPressa, od logowania kluczem SSH po w pełni zautomatyzowane CI/CD, z prawdziwymi poleceniami, które możesz uruchomić jeszcze dziś.

#Dlaczego FTP nie nadaje się do wdrażania WordPressa

FTP (File Transfer Protocol) przesyła dane logowania i zawartość plików otwartym tekstem. Każdy w tej samej sieci (kawiarnia, panel współdzielonego hostingu, przejęty router) może przechwycić twój login, hasło i każdy wysyłany plik. Poza koszmarem bezpieczeństwa FTP nie zna historii wersji, nie ma mechanizmu powrotu do poprzedniego stanu i nie daje żadnej możliwości koordynowania pracy kilku programistów.

SFTP i FTPS załatały lukę w szyfrowaniu, ale nie rozwiązały podstawowych problemów z procesem pracy. Nadal ręcznie wybierasz pliki, liczysz, że pamiętasz, które się zmieniły, i nadpisujesz kod produkcyjny bez żadnej siatki asekuracyjnej. Jedno przerwane wysyłanie functions.php i strona pokazuje biały ekran.

Nowoczesny zamiennik to trzy warstwy: SSH do bezpiecznego dostępu do serwera, Git do kontroli wersji i współpracy oraz potoki CI/CD do automatycznych testów i wdrożeń. Razem dają szyfrowane połączenia, pełną historię zmian, natychmiastowy rollback i wydania bez przestojów. Każda profesjonalna agencja WordPress w 2026 roku, w tym wppoland.com, traktuje ten zestaw jako podstawową infrastrukturę, a nie luksus.

#Konfiguracja logowania kluczem SSH

Logowanie do SSH hasłem jest podatne na ataki brute force. Logowanie kluczem całkowicie usuwa to ryzyko. Serwer wpuszcza tylko klientów, którzy mają pasujący klucz prywatny, a żadne hasło nie przechodzi przez sieć.

#Wygeneruj parę kluczy ED25519

Klucze ED25519 są krótsze, szybsze i bezpieczniejsze niż starsze klucze RSA. Wygeneruj klucz z opisowym komentarzem:

ssh-keygen -t ed25519 -C "[email protected]"

Powstają dwa pliki: ~/.ssh/id_ed25519 (klucz prywatny, nigdy go nie udostępniaj) i ~/.ssh/id_ed25519.pub (klucz publiczny, można go swobodnie rozsyłać).

#Skopiuj klucz publiczny na serwer

Najszybciej zrobisz to przez ssh-copy-id, które dopisuje klucz publiczny do pliku ~/.ssh/authorized_keys na serwerze:

ssh-copy-id [email protected]

Od tej chwili połączenia SSH z tym serwerem uwierzytelniają się automatycznie, bez pytania o hasło.

#Skonfiguruj ssh-agent i plik config

Uruchom ssh-agent, żeby nie wpisywać hasła do klucza za każdym razem:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Następnie utwórz lub zmień plik ~/.ssh/config, dodając wygodne aliasy:

Host wppoland-prod
    HostName 198.51.100.42
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host wppoland-staging
    HostName 198.51.100.43
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Teraz ssh wppoland-prod łączy cię od razu. Żadnych adresów IP do zapamiętania, żadnych haseł do wpisywania. Każdy programista w zespole powinien mieć własną parę kluczy, a kluczy prywatnych nigdy nie dzieli się między osobami.

#Jak założyć repozytorium Git dla WordPressa

Git zamienia pracę z WordPressem z “edytuj pliki na serwerze i miej nadzieję, że się uda” w uporządkowany proces z pełną historią zmian, który da się prześledzić.

#Struktura repozytorium Git dla WordPressa

Nie wszystko z instalacji WordPressa powinno trafić do Gita. Śledź własny kod, ignoruj wszystko, co da się zainstalować ponownie:

wordpress-project/
├── .gitignore
├── composer.json
├── wp-content/
│   ├── themes/
│   │   └── wppoland-theme/    # tracked
│   ├── plugins/
│   │   └── wppoland-custom/   # tracked
│   └── mu-plugins/            # tracked
└── wp-config.php              # NOT tracked

Plik .gitignore powinien wykluczać pliki rdzenia WordPressa, katalog uploads i wrażliwą konfigurację:

/wp-admin/
/wp-includes/
/wp-content/uploads/
/wp-content/upgrade/
wp-config.php
.env
*.log
node_modules/
vendor/

#Strategia gałęzi Git dla WordPressa

Zachowaj prostotę. Gałąź main odpowiada produkcji. Gałęzie funkcji (feature/new-header, fix/contact-form) odchodzą od main i wracają do niej przez pull requesty. W projektach klienckich wppoland.com dodajemy gałąź staging, która automatycznie wdraża się na serwer testowy, żeby klient mógł wszystko obejrzeć przed scaleniem z main.

#Composer do zarządzania zależnościami WordPressa

Używaj Composera do zarządzania wtyczkami WordPressa, a nawet samym rdzeniem, jako zależnościami. Instalacje stają się powtarzalne i nie trzeba commitować cudzego kodu:

{
  "require": {
    "wpackagist-plugin/advanced-custom-fields": "^6.0",
    "wpackagist-plugin/wordpress-seo": "^22.0",
    "wpackagist-plugin/wp-super-cache": "^1.9"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ]
}

Uruchom composer install na serwerze (albo w CI), a każde środowisko dostanie identyczne wersje wtyczek.

#Jak wdrażać WordPressa przez rsync po SSH

Git zajmuje się kontrolą wersji, a rsync wykonuje ciężką pracę przy przenoszeniu zbudowanych plików na produkcję. Wysyła tylko różnice między źródłem a celem, więc jest znacznie szybszy niż wrzucanie wszystkiego przez FTP czy SCP.

#rsync, SCP i FTP w porównaniu

SCP za każdym razem kopiuje całe pliki. FTP nie ma transferu różnicowego. rsync liczy sumy kontrolne i przesyła tylko zmienione bloki. Obsługuje też operacje atomowe: jeśli transfer się przerwie, możesz wznowić go dokładnie w miejscu, w którym stanął.

#Polecenie wdrożenia rsync z próbnym przebiegiem

Zawsze zaczynaj od próbnego przebiegu (dry run), żeby zobaczyć, co się zmieni:

rsync -avz --dry-run --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@server:/var/www/html/

Przejrzyj wynik. Jeśli wszystko się zgadza, usuń --dry-run i uruchom właściwe wdrożenie:

rsync -avz --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@server:/var/www/html/

Flaga --delete usuwa z serwera pliki, których nie ma już w lokalnym buildzie, więc wdrożenie zostaje czyste. Wzorce wykluczeń chronią uploads, konfigurację środowiska i metadane kontroli wersji przed nadpisaniem lub usunięciem.

#Potoki CI/CD dla WordPressa

Ciągła integracja i ciągłe wdrażanie automatyzują cały łańcuch: lintowanie kodu, testy, budowanie zasobów i wdrożenie, a wszystko uruchamia jeden git push.

#Workflow GitHub Actions do wdrażania WordPressa

Utwórz w repozytorium plik .github/workflows/deploy.yml:

name: Deploy WordPress

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          tools: composer

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run PHP linting
        run: vendor/bin/phpcs --standard=WordPress wp-content/themes/wppoland-theme/

      - name: Build frontend assets
        run: |
          npm ci
          npm run build

      - name: Deploy via rsync
        uses: burnett01/[email protected]
        with:
          switches: -avz --delete --exclude='.git' --exclude='wp-config.php' --exclude='wp-content/uploads'
          path: ./
          remote_path: /var/www/html/
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Clear cache
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: wp cache flush --path=/var/www/html

Dane dostępowe SSH trzymaj w sekretach repozytorium na GitHubie, nigdy nie wpisuj ich na sztywno w kod. Każdy push do main uruchamia teraz pełny cykl: lint, build i wdrożenie. Jeśli lintowanie się nie powiedzie, wdrożenie w ogóle nie rusza. Jeśli zawiedzie rsync, na serwerze nadal zostaje poprzednia działająca wersja.

#Polecenia WP-CLI do zarządzania WordPressem przez SSH

WP-CLI pozwala zarządzać każdym aspektem WordPressa z terminala. W połączeniu z SSH możesz administrować zdalnymi stronami bez otwierania przeglądarki.

#Najważniejsze polecenia WP-CLI

# Update WordPress core
wp core update
wp core update-db

# Plugin management
wp plugin install wordpress-seo --activate
wp plugin update --all
wp plugin deactivate wordfence

# User management
wp user create editor [email protected] --role=editor
wp user update 1 --user_pass=new_secure_password

# Database operations
wp db optimize
wp db repair

# Search and replace (critical for migrations)
wp search-replace 'https://staging.wppoland.com' 'https://wppoland.com' --all-tables --precise

# Generate a salts refresh
wp config shuffle-salts

# Maintenance mode
wp maintenance-mode activate

#Zdalne WP-CLI przez SSH

Uruchamiaj polecenia WP-CLI na serwerze produkcyjnym bez wcześniejszego logowania:

ssh wppoland-prod "cd /var/www/html && wp plugin status"
ssh wppoland-prod "cd /var/www/html && wp cron event run --due-now"

Możesz też skonfigurować aliasy WP-CLI w ~/.wp-cli/config.yml:

@prod:
  ssh: [email protected]/var/www/html
@staging:
  ssh: [email protected]/var/www/html

Potem wystarczy uruchomić wp @prod plugin list na lokalnym komputerze.

#Migracja i synchronizacja bazy danych

Baza danych to najtrudniejsza część wdrażania WordPressa, bo zawiera zserializowane dane z zapisanymi na sztywno adresami URL. Zwykłe znajdź i zamień w SQL psuje zserializowane ciągi. WP-CLI radzi sobie z tym poprawnie.

#Jak wyeksportować i zaimportować bazę WordPressa przez WP-CLI

# Export from staging
wp @staging db export staging-backup.sql

# Download it
scp wppoland-staging:/var/www/html/staging-backup.sql ./

# Import to production (after backup)
wp @prod db export production-backup-$(date +%Y%m%d).sql
wp @prod db import staging-backup.sql

# Fix URLs with serialization-safe replacement
wp @prod search-replace 'https://staging.wppoland.com' 'https://wppoland.com' --all-tables --precise

#Jak przenieść bazę danych ze stagingu na produkcję

W wppoland.com migracja bazy danych przebiega w ścisłej kolejności: eksport bazy produkcyjnej jako kopii zapasowej, import bazy ze stagingu, search-replace dla adresów URL, wyczyszczenie wszystkich cache i sprawdzenie kluczowych stron. Cały proces mamy w skrypcie, więc trwa poniżej dwóch minut i uruchamia się jednym poleceniem. Przy większych stronach warto rozważyć wtyczkę WP Migrate, która obsługuje zserializowane dane, pliki multimediów i wybór tabel z poziomu interfejsu. Przydaje się, gdy klienci chcą sami uruchamiać migracje.

#Jak skonfigurować WordPressa dla stagingu i produkcji

Profesjonalna praca z WordPressem wymaga co najmniej trzech środowisk: lokalnego, stagingu do akceptacji przez klienta i produkcji. Każde środowisko potrzebuje własnej bazy danych, własnego adresu URL i własnej konfiguracji, ale korzysta z tego samego kodu.

#wp-config.php dla każdego środowiska

Użyj wykrywania środowiska w wp-config.php, żeby wczytać właściwe ustawienia:

<?php
$environment = getenv('WP_ENVIRONMENT_TYPE') ?: 'production';

switch ($environment) {
    case 'local':
        define('DB_NAME', 'wppoland_local');
        define('DB_HOST', 'localhost');
        define('WP_DEBUG', true);
        define('WP_DEBUG_LOG', true);
        break;
    case 'staging':
        define('DB_NAME', 'wppoland_staging');
        define('DB_HOST', 'db.internal');
        define('WP_DEBUG', true);
        define('WP_DEBUG_LOG', true);
        break;
    default: // production
        define('DB_NAME', 'wppoland_prod');
        define('DB_HOST', 'db.internal');
        define('WP_DEBUG', false);
        break;
}

#Pliki .env z phpdotenv

Czystsze rozwiązanie całkowicie wyprowadza sekrety z wp-config.php. Zainstaluj vlucas/phpdotenv przez Composera i wczytuj zmienne środowiskowe z pliku .env:

DB_NAME=wppoland_prod
DB_USER=wp_user
DB_PASSWORD=strong_random_password
DB_HOST=localhost
WP_HOME=https://wppoland.com
WP_SITEURL=https://wppoland.com

Każde środowisko ma własny plik .env (nigdy nie trafia do Gita), a wp-config.php czyta z $_ENV i jest identyczny na wszystkich serwerach. Ten wzorzec, spopularyzowany przez Bedrock od Roots.io, jest dziś standardem w agencjach WordPress, które obsługują kilka środowisk na projekt.

#Jak zabezpieczyć serwer WordPressa po wdrożeniu

Nowoczesny proces wdrożeń jest tak bezpieczny, jak jego najsłabsze ogniwo. Gdy masz już klucze SSH i automatyczne wdrożenia, zablokuj całą resztę.

#Wyłącz XML-RPC

XML-RPC to przestarzałe API, które umożliwia wzmacnianie ataków brute force. Jeśli go wprost nie potrzebujesz (Jetpack, niektóre aplikacje mobilne), wyłącz je:

add_filter('xmlrpc_enabled', '__return_false');

#Ustaw poprawne uprawnienia plików

Pliki WordPressa nigdy nie powinny być zapisywalne dla wszystkich:

# Files: 644 (owner read/write, group and others read)
find /var/www/html -type f -exec chmod 644 {} \;

# Directories: 755 (owner full, group and others read/execute)
find /var/www/html -type d -exec chmod 755 {} \;

# wp-config.php: extra restrictive
chmod 600 /var/www/html/wp-config.php

#Przenieś wp-config.php poza katalog główny strony

WordPress automatycznie szuka wp-config.php katalog wyżej niż katalog główny strony. Przeniesienie pliku tam blokuje bezpośredni dostęp przez URL:

mv /var/www/html/wp-config.php /var/www/wp-config.php

#Chroń SSH przez fail2ban

Zainstaluj fail2ban, żeby automatycznie blokować adresy IP, które wielokrotnie nie przechodzą uwierzytelniania SSH:

sudo apt install fail2ban
sudo systemctl enable fail2ban

Domyślna konfiguracja blokuje adres IP na 10 minut po 5 nieudanych próbach. Na serwerach produkcyjnych w wppoland.com wydłużamy blokadę do 1 godziny i obniżamy próg do 3 prób.

#Dlaczego nie należy uruchamiać git pull bezpośrednio na produkcji

Typowym nawykiem programistów porzucających FTP jest logowanie się na serwer przez SSH i wykonywanie polecenia `git pull origin main` bezpośrednio w katalogu głównym serwera WWW (`/var/www/html`). Mimo że rozwiązanie to wprowadza historię rewizji, rodzi poważne zagrożenia w środowisku produkcyjnym o dużym natężeniu ruchu.

#Niespójny stan plików w trakcie pobierania z sieci

Git aktualizuje pliki na dysku sekwencyjnie. Jeśli wdrożenie modyfikuje jednocześnie szablon motywu oraz wtyczkę biznesową o współzależnych funkcjach, procesy PHP-FPM będą obsługiwać zapytania HTTP w ułamkach sekund, w których zaktualizowano zaledwie część kodu. Odwiedzający i roboty indeksujące trafiają wówczas na błędy krytyczne PHP (`Fatal error: Uncaught Error: Call to undefined function`) oraz puste białe ekrany.

#Konflikty merge wywołane modyfikacją plików na serwerze

Jeśli administrator wdroży szybką poprawkę na serwerze, automatyczny mechanizm tłumaczeń zmodyfikuje plik językowy lub błędna wtyczka zapisze dane w śledzonym katalogu, kolejne wywołanie `git pull` zostanie przerwane konfliktem scalania (`error: Your local changes to the following files would be overwritten by merge`). Wdrożenie zostaje zablokowane w połowie, a strona pozostaje w niekontrolowanym stanie do czasu ręcznej interwencji programisty przez SSH.

#Ryzyko ujawnienia metadanych repozytorium git

Uruchamianie Gita bezpośrednio w publicznym katalogu webroot tworzy ukryty katalog `.git/`. Jeśli konfiguracja Nginx lub Apache nie blokuje explicite dostępu do ukrytych plików, osoby z zewnątrz mogą pobrać plik `.git/index` i odtworzyć pełną strukturę kodu źródłowego, uzyskując dostęp do wewnętrznych komentarzy, logiki biznesowej i danych konfiguracyjnych.

#Architektura wdrożeń atomowych z dowiązaniami symbolicznymi

Aby wyeliminować przestoje oraz ryzyko niespójnego stanu plików, profesjonalne zespoły WordPress stosują architekturę wdrożeń atomowych, spopularyzowaną przez narzędzia takie jak Capistrano oraz Deployer.

#Struktura katalogów dla bezprzerwowych wydań

Wdrożenia atomowe oddzielają poszczególne wydania, zasoby współdzielone oraz publiczny punkt wejścia serwera WWW:

/var/www/mojastrona/
├── current -> /var/www/mojastrona/releases/20261012120000/
├── releases/
│   ├── 20261012100000/
│   ├── 20261012110000/
│   └── 20261012120000/
└── shared/
    ├── .env
    └── wp-content/
        └── uploads/

Serwer WWW (Nginx lub Apache) wskazuje w swojej konfiguracji wyłącznie na dowiązanie `/var/www/mojastrona/current`.

#Mechanizm atomowego przełączania symlinka

Każde wdrożenie tworzy nowy katalog w `releases/` oznaczony znacznikiem czasu ISO.
Tworzone są dowiązania symboliczne do trwałych zasobów z katalogu `shared/`, takich jak `.env` oraz `wp-content/uploads/`.
W wyizolowanym katalogu wydania wykonywane są zadania budowania: `composer install`, kompilacja stylów i skryptów, migracje bazy (`wp core update-db`) oraz testy integralności.
Po pomyślnym zakończeniu wszystkich kroków dowiązanie `current` jest przełączane w jednej atomowej operacji na poziomie systemu plików:

ln -sfn /var/www/mojastrona/releases/20261012120000 /var/www/mojastrona/current_temp && mv -Tf /var/www/mojastrona/current_temp /var/www/mojastrona/current

Wywołanie systemowe `rename()` w Linuksie jest atomowe. Dla serwera WWW przełączenie wersji zajmuje mikrosekundy. Jeśli instalacja zależności lub kompilacja zakończą się błędem, symlink pozostaje nienaruszony, a działająca witryna obsługuje ruch bez ani jednej milisekundy przestoju.

#Natychmiastowy rollback w sytuacjach awaryjnych

Jeśli po wdrożeniu ujawni się nieprzewidziany błąd produkcyjny, powrót do poprzedniej wersji nie wymaga pobierania kopii zapasowych ani czasochłonnego przebudowywania kodu. Wystarczy przestawić symlink na poprzedni katalog wydania i wyczyścić pamięć podręczną:

ln -sfn /var/www/mojastrona/releases/20261012110000 /var/www/mojastrona/current
wp cache flush
sudo systemctl reload php8.3-fpm

#Automatyzacja z repozytoriami bare i hookami post-receive

W infrastrukturze bez zewnętrznych systemów CI/CD w chmurze można zorganizować prosty i niezawodny proces push-to-deploy bezpośrednio na serwerze Linux, wykorzystując repozytorium bare i skrypt `post-receive`.

#Inicjalizacja repozytorium bare na serwerze

Na serwerze docelowym tworzymy repozytorium pozbawione katalogu roboczego:

mkdir -p /var/repo/mojastrona.git
cd /var/repo/mojastrona.git
git init --bare

#Konfiguracja skryptu post-receive

W pliku `/var/repo/mojastrona.git/hooks/post-receive` umieszczamy skrypt wdrożeniowy:

#!/bin/bash
TARGET_DIR="/var/www/mojastrona/releases/$(date +%Y%m%d%H%M%S)"
SHARED_DIR="/var/www/mojastrona/shared"
CURRENT_LINK="/var/www/mojastrona/current"

echo "===> Rozpoczynam atomowe wdrażanie WordPressa..."
mkdir -p "$TARGET_DIR"

# Pobranie kodu ze śledzonej gałęzi main
git --work-tree="$TARGET_DIR" --git-dir=/var/repo/mojastrona.git checkout -f main

# Podlinkowanie trwałych zasobów współdzielonych
ln -s "$SHARED_DIR/.env" "$TARGET_DIR/.env"
rm -rf "$TARGET_DIR/wp-content/uploads"
ln -s "$SHARED_DIR/wp-content/uploads" "$TARGET_DIR/wp-content/uploads"

# Instalacja zależności produkcyjnych Composera
if [ -f "$TARGET_DIR/composer.json" ]; then
    cd "$TARGET_DIR" && composer install --no-dev --optimize-autoloader --quiet
fi

# Aktualizacja schematu bazy danych WordPressa
wp core update-db --path="$TARGET_DIR" --quiet

# Atomowe przełączenie aktywnego wydania
ln -sfn "$TARGET_DIR" "${CURRENT_LINK}_temp" && mv -Tf "${CURRENT_LINK}_temp" "$CURRENT_LINK"

# Czyszczenie pamięci podręcznej i przeładowanie PHP-FPM
wp cache flush --path="$CURRENT_LINK" --quiet
sudo systemctl reload php8.3-fpm

echo "===> Wdrożenie zakończone pomyślnie bez przestoju."

Nadajemy uprawnienia do wykonywania pliku:

chmod +x /var/repo/mojastrona.git/hooks/post-receive

#Konfiguracja lokalnego repozytorium i publikacja

Na lokalnej maszynie programisty dodajemy zdalny cel:

git remote add production deploy@serwer:/var/repo/mojastrona.git
git push production main

Git przesyła skompresowane różnice po SSH, hook na serwerze przygotowuje katalog nowego wydania, instaluje zależności i atomowo przełącza symlink.

#Weryfikacja i testy dymne po wdrożeniu produkcyjnym

Nowoczesny proces wdrożeniowy nie kończy się w momencie wysłania plików. Zautomatyzowana kontrola po publikacji pozwala natychmiast upewnić się, że kluczowe funkcjonalności działają prawidłowo.

#Automatyczne sprawdzanie kodów odpowiedzi HTTP

Zaraz po wyczyszczeniu pamięci podręcznej warto uruchomić skrypt weryfikujący odpowiedzi HTTP dla kluczowych adresów:

# Weryfikacja poprawności kodu HTTP 200
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/pl/wordpress-developer/
curl -s -o /dev/null -w "%{http_code}" https://wppoland.com/wp-json/

W razie wykrycia błędu 500 proces może automatycznie wywołać komendę wycofania symlinka, minimalizując wpływ na ruch organiczny.

#Monitorowanie logów błędów środowiska uruchomieniowego

Przez pierwsze minuty po wdrożeniu należy obserwować dzienniki błędów PHP-FPM oraz `debug.log` WordPressa:

tail -n 100 /var/log/php8.3-fpm.log
tail -n 100 /var/www/mojastrona/shared/wp-content/debug.log

Pozwala to wychwycić ukryte ostrzeżenia i błędy niekompatybilności zanim wpłyną na użytkowników końcowych.

#Bezpieczne zarządzanie danymi uwierzytelniającymi w procesie Git

Przejście z FTP na Git wymaga wprowadzenia przejrzystych reguł dotyczących poufności haseł i kluczy:

Prywatne klucze SSH nie opuszczają lokalnego komputera: Zabezpieczone silnym hasłem klucze prywatne pozostają u programisty, a na serwer trafia jedynie klucz publiczny w pliku `authorized_keys`.
Systemy CI/CD korzystają z dedykowanych kluczy wdrożeniowych (Deploy Keys): Automatyzacje takie jak GitHub Actions powinny używać osobnych kluczy o ograniczonych uprawnieniach, a nie prywatnych kluczy indywidualnych programistów.
Zmienne środowiskowe w odizolowanych plikach konfiguracyjnych: Hasła do bazy danych i klucze API przechowujemy w pliku `/var/www/mojastrona/shared/.env` z uprawnieniami `600`. Jeśli sekret przypadkowo trafi do commita w repozytorium, usunięcie go w kolejnym commicie nie rozwiązuje problemu, ponieważ Git pamięta całą historię. W takiej sytuacji hasło musi zostać bezzwłocznie unieważnione i zmienione na serwerze.

#Lista kontrolna przejścia z FTP na Git dla WordPressa

Przejście z FTP na profesjonalny proces wdrożeń nie dzieje się z dnia na dzień. Skorzystaj z tej listy, żeby migrować stopniowo, krok po kroku.

Etap 1: fundamenty (dzień 1)

Wygeneruj klucze SSH ED25519 dla każdego programisty
Wyłącz logowanie hasłem na serwerze (PasswordAuthentication no w sshd_config)
Zainstaluj WP-CLI na serwerze
Skonfiguruj ~/.ssh/config dla wszystkich środowisk

Etap 2: kontrola wersji (tydzień 1)

Zainicjuj repozytorium Git dla projektu
Przygotuj porządny .gitignore (bez rdzenia, uploads i konfiguracji)
Tam, gdzie się da, przenieś zarządzanie wtyczkami i motywami do Composera
Ustal strategię gałęzi (main plus gałęzie funkcji)

Etap 3: automatyczne wdrożenia (tydzień 2)

Postaw staging, który odwzorowuje produkcję
Napisz skrypt wdrożeniowy rsync z właściwymi wykluczeniami
Utwórz workflow GitHub Actions do automatycznych wdrożeń
Dodaj do potoku lintowanie PHP i sprawdzanie standardów kodowania

Etap 4: utwardzanie (tydzień 3)

Skonfiguruj wp-config.php lub pliki .env dla każdego środowiska
Ustaw uprawnienia plików (644 dla plików, 755 dla katalogów)
Zainstaluj i skonfiguruj fail2ban
Wyłącz XML-RPC i nieużywane endpointy REST API
Udokumentuj cały proces dla zespołu

Każda strona, którą prowadzimy w wppoland.com, przechodzi przez te etapy. Klienci, którzy zaczynali od FileZilli, mają dziś wdrożenia uruchamiane pushem z automatycznym rollbackiem. Początkowa inwestycja to kilka godzin, a zwrot to lata szybszych, bezpieczniejszych i spokojniejszych wdrożeń.

Więcej o naszych usługach programisty WordPress w WPPoland.