Konfiguracja Wordpress w multisite

Wordpress od wersji 3.x domyślnie posiada już multisite. Nazwane to zostało obecnie "sieciowością". Trzeba tylko dograć jeden moduł i będzie dobrze

Instalacja wordpress

Za pomocą własnego repozytorium pakietów instalujemy pakiet w systemie:

pkg install -Uy www/wordpress

Aby działał moduł domain mapping, konieczne jest zainstalowanie WP jako subdomena, a nie poprzez URL do głównej domeny.

Dogranie modułu domain mapping

Zgodnie z artykułem Multisite domain mapping trzeba zrobić następujące kroki:

mkdir -p /usr/local/www/wordpress/wp-content/blogs.dir
chown www:www /usr/local/www/wordpress/wp-content/blogs.dir

# pobranie pluginu multisite i rozpakowanie do roboczego katalogu
cp <tmp_dir>/domain_mapping.php /usr/local/www/wordpress/wp-content/plugins/
cp <tmp_dir>/sunrise.php /usr/local/www/wordpress/wp-content/

Modyfikacja konfiguracji wp-config.php

Wszystkie "dopiski" do wp-config.php wykonujemy przed komentarzem

define('WP_ALLOW_MULTISITE', true);

/* That's all, stop editing! Happy blogging. */

W kolejnym kroku można dopisać następujące linijki

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'wp.bsdserwis.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
define( 'SUNRISE', 'on' );
define( 'VHOST', true );

A potem to już przeglądarka

Pozostałe rzeczy to już przeglądarka. Tam już się klika, robi nowe blogi, itd.

Polonizacja Wordpress

Ponieważ Wordpress zainstalowany z ports, zatem chcemy tylko dokonać polonizacji, a nie instalacji całości źródeł. Tak więc trzeba pobrać odpowiednie pliki ze źródeł:

cd /tmp/
wget -nv -nH -r -X '..' -l 2 -A .po -A .mo  http://svn.automattic.com/wordpress-i18n/pl_PL/tags/3.2.1/messages/
cp wordpress-i18n/pl_PL/tags/3.2.1/messages/pl_PL.* /usr/local/www/wordpress/wp-content/languages/
cp wordpress-i18n/pl_PL/tags/3.2.1/messages/twentyten/pl_PL.* /usr/local/www/wordpress/wp-content/themes/twentyten/languages/
cp wordpress-i18n/pl_PL/tags/3.2.1/messages/twentyeleven/pl_PL.* /usr/local/www/wordpress/wp-content/themes/twentyeleven/languages/

No i oczywiście w pliku wp-config.php zmieniamy wartość odpowiedniej zmiennej:

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress. A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de_DE.mo to wp-content/languages and set WPLANG to 'de_DE' to enable German
 * language support.
 */
define('WPLANG', 'pl_PL');

I już mamy polskiego wordpressa.

Dodanie administratora do WordPressa

Poniższy przepis dotyczy wykonania tego za pomocą bazy danych:

-- utworzenie administratora
INSERT INTO wp_users (user_login, user_pass, user_registered) VALUES ('admin1',md5('admin1'), now() );

-- zapami/etanie ID
SELECT LAST_INSERT_ID();

INSERT INTO wp_usermeta( user_id, meta_key, meta_value) VALUES ( LAST_INSERT_ID(), 'wp_capabilities', 'a:1:{s:13:"administrator";s:1:"1";}' );

Obsługa REDIS

WordPress pozwala na przyspieszenie działania poprzez wykorzystanie serwera cache o nazwie Redis. TBA

Konfiguracja po stronie nginx

Korzystając z możliwości nginx możliwe jest dobre zabezpieczenie samego WordPress-a jak również jego przyspieszenie.

Zabezpieczenie WordPress

Konfiguracja nginx pozwala na bardzo dokładne oraz rozbudowanie sterowanie dostępem do wybranych plików, katalogów samego Wordpress-a, jak również zablokowanie niepożądanych żądań do serwera. Całość została umieszczona w repozytroium konfiguracji w plikach

    # Ograniczenie metod /z/ada/n HTTP jedynie do GET oraz POST. W przeciwym
    # przypadku zwracany jest kod "Zamkni/ecie sesji bez odpowiedzi"
    #
    if ($request_method !~ ^(GET|POST)$ ) {
        return 444;
    }

    # Blokowanie dost/epu do ukrytych plik/ow (jakichkolwiek)
    # Logowanie takich zdarze/n w celu dalszej analizy, np. fail2ban
    location ~ /\.(?!well-known) {
        deny all;
    }

    # Blokowanie dost/epu do plik/ow .php w katalogach uploads, wp-contetns,
    # itd.
    #
    # Dzia/la r//ownie/z w podkatalogach jak r/ownie/z w konfiguracji multisite
    # Logowanie takich zdarze/n w celu dalszej analizy, np. fail2ban
    location ~* /(?:uploads|files|(?:wp-content?!themes)|wp-includes|akismet)/.*\.php$ {
        deny all;
    }

    # Blokowanie innych skrypt/ow CGI, ale za wyj/atkiem csp-report.cgi
    # Zwracany jest kod "Zamkni/ecie sesji bez odpowiedzi"
    #
    location ~* \.((?:cgi<!csp-report)|pl|py|sh|lua)$ {
        return 444;
    }

    # blokowanie plik/ow potencjalnie niebezpiecznych
    #
    location ~* ^/(wp-config.php|wp-comments-post.php|readme.html|license.txt) {
        deny all;
    }

    # blokowanie dost/epu do xmlrpc
    #
    location ~ ^/xmlrpc.php$ {
        allow 127.0.0.0/8;
        allow ::1;
        # allow __ipv4__;
        # allow __ipv6__;
        deny all;
    }

    location ~ \.php$ {
        # przekierowanie dla nieistniej/acych plik/ow
        #
        if (!-f $document_root$fastcgi_script_name) {
            return 301 $scheme://$server_name;
        }
        include 022-wordpress-php-fastcgi.conf;

        # blokowanie dost/epu do wp-login
        #
        # limit_req_zone tylko w sekcji http{}, czyli nginx.conf
        ## limit_req_zone $binary_remote_addr zone=WPRATELIMIT:10m rate=5r/s;
        #
        location ~* /wp-login.php$ {
            limit_req zone=WPRATELIMIT;
            include 022-wordpress-php-fastcgi.conf;
        }

    }

Natomiast w sekcji http{} należy dodać ustawienie odpowiedzialne za ograczanie dostępu do wp-login.php:

    # ograniczenie dost/epu do logowania do WP - ochrona przez pr/obami
    # z/l/amania logowania do WP
    #
    limit_req_zone $binary_remote_addr zone=WPRATELIMIT:10m rate=3r/s;

Ustawienie cache dla stron dynamicznych

Konfiguracja nginx pozwala uruchomienie pamięci podręcznej dla stron dynamicznych (generowanych przez PHP, WSGI, itd). Z pamięci podręcznej serwowane są pliki statyczne, tak więc wyświetlanie danej strony jest znacznie szybsze.

sekcja http

W sekcji http należy wskazać konfigurację dla takiej pamięci podręcznej. Należy podać miejsce na dysku (katalog) z odpowiednimi prawami dostępu. W ramach konfiguracji określany jest maksymalny rozmiar pamięci "cache":

    # cache'owanie dynamicznych stron php
    #
    fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=phpcache:100m max_size=1g inactive=60m use_temp_path=off;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";

WordPress