Migol’s Blog

Podczas poprawiania jakości zabezpieczeń w moim blogu wg. porad jakich udzieliła mi wtyczka WP Security Scan okazało się że WordPress ma pewien błąd w projekcie (głupia sprawa, wszystko działa, ale nie w sposób w jaki powinno) i zmiana prefix’u tabel nie jest taka łatwa.
Przede wszystkim nie udało mi się tego dokonać z poziomu wtyczki. Nie jestem pewien, ale chyba jest to błąd w samej wtyczce, a nie w ustawieniach użytkownika bazy danych (ale 100% pewien nie jestem). Tak więc postanowiłem to zrobić ręcznie wg opisu znajdującego się na stronie wtyczki (sama mi podała odpowiedni adres). Opis wydał mi się w miarę prosty i wykonalny. Kombinacja phpMyAdmin + Vim poradziła sobie ze zmianami nazw tabel, a SSH + Vim ze zmianą pliku konfiguracyjnego. Po skończeniu wchodzę na bloga i wszystko świetnie, gdyby nie fakt, że nie mam dostępu do panelu administratora.
Po otrząśnięciu się z WTF poszukałem informacji na Google i znalazłem wpis opisujący ten problem. NIestety programiści WordPress’a zapędzili się z prefix-ami i nie są one używane tylko przy nazwach tablic, ale i w paru wpisach w nich (to jest właśnie ten bug w projekcie). Na szczęście te poprawki pozwoliły mi dostać się do panelu admina.
Oczywiście wysłałem wiadomość twórcom wtyczki, że opis na ich stronie nie działa do końca i odesłałem ich do wpisu z którego skorzystałem. Druga sprawa, że ich wtyczka posiada błąd: w zakładce Database (nie przetłumaczyłem jeszcze tej wtyczki) pole na prefix tablicy ma ograniczoną długość, co przeczy zasadom zabezpieczania (im dłuższy tym lepszy). Tak czy siak narazie mam wszystkie kryteria oceny zielone, więc chyba jestem bezpieczny.

Przed chwilą zrobiłem upgrade WordPress’a do najnowszej wersji – 2.5.1. Przebiegło całkiem sprawnie, chociaż wolałem nie ryzykować i zrobiłem kopię zapasową (na szczęście się nie przydała).
Zmieniłem także sposób w jaki WordPress jest zainstalowany. Standardowo instaluje się go z pliku ZIP. Da się tą metodą instalować zawsze, nawet jeżeli nie posiada się dostępu przez SSH. Jednak szukając opisu jak wykonać aktualizację natknąłem się na opis jak wykorzystać do tego SVN. Jako że jestem zwolennikiem tego systemu od razu postanowiłem go wykorzystać. Autor nie omieszkał także opisać w jaki sposób przejść na ten typ instalacji z wersji tradycyjnej. Dalsze aktualizacje tak przygotowanego WordPress’a są sprowadzone do zmiany gałęzi repozytorium SVN (komenda switch). Jakoś nie mam na tyle odwagi i zaufania do programistów WordPress’a żeby korzystać z najnowszej wersji developerskiej (tzw. trunk).
Niestety przeniesienia moiich przeróbek musiałem dokonać sam, co jest pierwszym minusem całego procesu. Drugi to fakt, że musiałem ręcznie otworzyć adres /wp-admin/upgrade.php żeby baza danych się zaktualizowała. To wszystko dałoby się wykonać automatycznie (tak jak jest to zrobione przy wtyczkach), i to nawet z wykryciem przeróbek użytkownika.
Całemu procesowi postawiłbym 2,5/5 i to głównie za to, że nic się nie uwaliło, ale że można korzystać z SVNa do robienia tego dam 4/5.