RIKEN24
← Wszystkie teksty
IT7 min czytania

.htaccess. Mały plik za kulisami strony

Co naprawdę robi .htaccess, co znalazłem w starej instalacji WordPressa i dlaczego statyczna wersja bloga nie potrzebuje tej warstwy.

Pliki, które najbardziej wpływają na działanie strony, często są tymi, których odwiedzający nigdy nie widzi. .htaccess jest dobrym przykładem. Nie pojawia się w menu, nie ma własnej podstrony i zwykle nie interesujemy się nim, dopóki coś nie przestanie działać.

A jednak to właśnie tam serwer Apache może dostać instrukcje dotyczące przekierowań, adresów URL, dostępu do katalogów, pamięci podręcznej albo wymuszania HTTPS.

Co to właściwie jest

.htaccess to konfiguracyjny plik serwera Apache działający w konkretnym katalogu i jego podkatalogach. Kropka na początku nazwy oznacza, że plik jest ukryty w wielu systemach. Nie oznacza jednak, że jest tajny. Jeśli serwer zostanie źle skonfigurowany, jego zawartość może nawet zostać omyłkowo udostępniona jako zwykły tekst.

Ważna jest lokalność tego pliku. Reguła zapisana w katalogu strony może obowiązywać tylko tę stronę, podczas gdy konfiguracja główna serwera działa szerzej. To wygodne na hostingu współdzielonym, gdzie właściciel witryny nie ma dostępu do głównego pliku konfiguracyjnego Apache.

Co znalazłem w starej wersji RIKEN24

Przed zastąpieniem WordPressa statyczną wersją zrobiłem kopię jego katalogu. W zachowanym .htaccess znalazły się wyłącznie komentarze:

# BEGIN WordPress
# Dyrektywy zawarte między „BEGIN WordPress” oraz „END WordPress” są generowane dynamicznie i powinny być modyfikowane tylko za pomocą filtrów WordPressa.

# END WordPress

To może wyglądać jak błąd, ale sam pusty blok nie jest dowodem awarii. WordPress często zapisuje swoje reguły właśnie pomiędzy znacznikami BEGIN WordPress i END WordPress. Jeżeli instalacja nie potrzebowała dodatkowych reguł albo konfiguracja serwera obsługiwała adresy inaczej, plik mógł pozostać praktycznie pusty.

Najważniejszy wniosek brzmi: nie należy dopisywać przypadkowych reguł tylko dlatego, że plik istnieje.

Najczęstsze zadania .htaccess

1. Przekierowanie na HTTPS

Klasyczny przykład wymuszenia szyfrowanego adresu wygląda tak:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Taka reguła może być przydatna, ale tylko wtedy, gdy certyfikat TLS działa poprawnie. W przeciwnym razie przekierowanie nie naprawi problemu — jedynie sprawi, że użytkownik szybciej zobaczy błąd HTTPS.

2. Przyjazne adresy WordPressa

W typowej instalacji WordPressa reguły przekazują żądania do index.php, jeśli nie wskazują one na istniejący plik lub katalog:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

To właśnie dzięki takim regułom adres wpisu może wyglądać jak /moj-wpis/, zamiast wskazywać bezpośrednio na fizyczny plik PHP.

3. Ochrona plików

.htaccess bywa także używany do ograniczania dostępu do plików konfiguracyjnych. Trzeba jednak uważać: zbyt szeroka blokada może zepsuć obrazy, arkusze stylów albo działanie panelu administracyjnego.

Nie należy kopiować reguł z przypadkowego poradnika bez sprawdzenia wersji Apache, modułów i układu katalogów. To, co działa na jednym hostingu, na innym może zakończyć się błędem 500.

Dlaczego nowy RIKEN24 go nie potrzebuje

Nowa wersja bloga jest statyczna. Artykuł jest gotowym plikiem HTML, arkusz stylów jest zwykłym CSS-em, a wyszukiwanie i motyw działają po stronie przeglądarki. Nie ma PHP, WordPressa ani żądania, które trzeba przepisywać do index.php.

To upraszcza kilka rzeczy naraz:

  • mniej procesów po stronie serwera,
  • mniej miejsc, w których może powstać błąd,
  • brak bazy danych potrzebnej do wyświetlenia wpisu,
  • prostszy rollback — wystarczy przywrócić poprzedni katalog plików,
  • łatwiejsze sprawdzenie, co dokładnie zostało opublikowane.

Statyczność nie oznacza jednak braku odpowiedzialności. Nadal trzeba pilnować HTTPS, nagłówków bezpieczeństwa, praw dostępu, kopii zapasowych i poprawnych przekierowań po zmianie adresów.

Najważniejsza lekcja

.htaccess nie jest magicznym plikiem naprawiającym stronę. Jest warstwą instrukcji dla serwera. Dobrze napisany rozwiązuje konkretny problem. Źle napisany może ukryć prawdziwą przyczynę awarii albo zamienić działającą stronę w błąd 500.

W przypadku RIKEN24 najrozsądniejszą decyzją było nie przepisywać starej konfiguracji do nowej witryny na siłę. Zachowałem oryginalny WordPress wraz z jego plikami jako kopię, a nowy blog opublikowałem jako zestaw jawnych, gotowych zasobów.

Czasem najlepszą konfiguracją jest ta, której nie trzeba dodawać.

Czytaj dalej

Jeszcze dwa teksty