WordPress, W3 Total Cache, Piwik i home.pl -> problem

Postanowiłem w końcu przenieść bloga na wykupiony hosting. Początkowo szło dość gładko, ale jedna zasada zawsze się sprawdza – jeśli coś idzie bardzo łatwo, oznacza to, ze za chwilę będą spore problemy. :)

Minify w W3 Total Cache

Zaraz po przeniesieniu bloga z własnego hostingu do home.pl wszystko wyglądało ok. Problem pojawił się w momencie wyczyszczenia cache-u we wtyczce W3 Total Cache. Przestały działać style – plik ze stylami nie ładował się. Po włączeniu debugowania dla Minify zobaczyłem komunikat:

W3TC Minify Error</h1><p>Path "/wp-content/w3tc/min/wp-content/themes/twentyten/style.css" failed realpath().

Oczywiście jest to nieprawidłowa ścieżka.

Początkowo myślałem, że z powodu jakiegoś bug-a $_SERVER['DOCUMENT_ROOT'] zawiera ścieżkę z RewriteBase (m.in. który kieruje request do index.php w /wp-content/w3tc/min/). Taką ścieżkę właśnie zawierał, ale z innego powodu – w kodzie minify jest linijka ustawiająca $_SERVER['DOCUMENT_ROOT'], a problem pojawił się w metodzie generującej ścieżkę – define.php -> w3_get_document_root():

function w3_get_document_root() {
    static $document_root = null;

    if ($document_root === null) {
        if (!empty($_SERVER['SCRIPT_FILENAME'])) {
            $document_root = substr(w3_path($_SERVER['SCRIPT_FILENAME']), 0, -strlen(w3_path($_SERVER['PHP_SELF'])));
        } elseif (!empty($_SERVER['PATH_TRANSLATED'])) {
            $document_root = substr(w3_path($_SERVER['PATH_TRANSLATED']), 0, -strlen(w3_path($_SERVER['PHP_SELF'])));
        } elseif (!empty($_SERVER['DOCUMENT_ROOT'])) {
            $document_root = w3_path($_SERVER['DOCUMENT_ROOT']);
        } else {
            $document_root = w3_get_site_root();
        }

        $document_root = realpath($document_root);
        $document_root = w3_path($document_root);
    }
    return $document_root;
}

Szczególnie ważny jest ten warunek:

if (!empty($_SERVER['SCRIPT_FILENAME'])) {
    $document_root = substr(w3_path($_SERVER['SCRIPT_FILENAME']), 0, -strlen(w3_path($_SERVER['PHP_SELF'])));

Jest on spełniony, a na home.pl $_SERVER['SCRIPT_FILENAME'] i $_SERVER['PHP_SELF'] są równe, więc substr() generuje pusty ciąg.

Poniżej znajduje się realpath(), które jeśli jako parametr dostanie ciąg pusty (lub NULL) zwraca obecny folder, co spowodowało zwrócenie “/wp-content/w3tc/min/” (w którym znajduje się wykonywany index.php od Minify) zamiast “/” który jest właściwym tu DOCUMENT_ROOT.

Poprawienie tego:

if(strlen($document_root))
    $document_root = realpath($document_root);

spowodowało, że Minify zaczęło działać, ale to nie był jeszcze koniec problemów. Okazało się, że jest więcej miejsc, w których realpath() dostaje pusty ciąg jako parametr i zwraca złą ścieżkę. Powodowało to generowanie uszkodzonych ścieżek w url() w CSS-ach: “/wp-content/w3tc/min/wentyten/wenyten/images/logo_small.png” (tam jest “wentyten”, nie “twentyten”).

Dwie kolejne poprawki i wszystko zaczęło działać jak należy:

ImportProcessor.php -> _urlCB($m):

if(strlen($_SERVER['DOCUMENT_ROOT']))
    $path = substr($path, strlen(realpath($_SERVER['DOCUMENT_ROOT'])));

UriRewriter.php -> _realpath($path):

$realPath = strlen($path) ? realpath($path) : "";

To jednak prawdopodobnie nie wszystkie miejsca i w innych konfiguracjach problem może nadal występować. Zgłosiłem go na forum WordPressa. Problem nie leży po stronie home.pl, jedynie prawdopodobnie konfiguracja jest na tyle unikalna, że nikt nie wziął jej pod uwagę.

Piwik

Z Piwikiem był w zasadzie tylko jeden problem – po przeniesieniu na home.pl, pomimo ustawienia baz także na UTF-8, dane z bazy miały nieprawidłowe (uszkodzone) polskie znaki (choć PHPMyAdmin pokazywał wszystkie rekordy prawidłowo).

Rozwiązaniem było dodanie:

charset = “UTF-8″

w config/config.init.php w sekcji database – powoduje to zmianę kilku parametrów na UTF-8 podczas połączenia i polskie znaki nie są już tracone.

Migracja

Przeniesienie chciałem zrealizować tak, aby uptime był jak największy. Najprościej wykonać kopię danych i bazy na nowy serwer i w tym samym czasie przekonfigurować domenę tak, aby jej rekord A wskazywał na nowy serwer.

W tym przypadku część użytkowników trafi jeszcze na stary serwer, a część na nowy, zanim na wszystkich DNS-ach wyekspiruje cache rekordu domeny i zostanie pobrany nowy z właściwym już adresem IP.

Aby uniknąć takiej sytuacji, na starym serwerze zestawiłem reverse proxy kierując wszystkie requesty na nowy serwer (czyli przez ten czas requesty trafiające na stary serwer są przekierowywane na nowy).

Piwik bez problemu działa na reverse proxy, WordPress już nie i tutaj przydał się patch, który robiłem wcześniej, gdy korzystałem z loadbalancera do serwowania contentu swojego bloga (ale o tym będzie osobny wpis).

 

Źródło obrazka: [1]

Ten wpis został opublikowany w kategorii Oprogramowanie, PHP, Programowanie, Serwery, WWW i oznaczony tagami , , , , , , . Dodaj zakładkę do bezpośredniego odnośnika.

Dodaj komentarz

Musisz się zalogować (także Facebook, Google+, Twitter), aby móc dodać komentarz.