WordPress telepítése (Jessie)

Innen: AdminWiki
A lap korábbi változatát látod, amilyen KZoli (vitalap | szerkesztései) 2019. június 19., 16:01-kor történt szerkesztése után volt. (WordPress közös kódkészlet (core) frissítése)
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)

A WordPress egy meglehetősen elterjedt blogmotor (pardon: semantic personal publishing platform :-). Ebben a leírásban több WordPress blog párhuzamosan, egymástól lényegében függetlenül (más-más virtualhostokban, de nem teljesen izoláltan) futtatására alkalmas környezetet építünk fel ("WordPress farm" ismerősöknek).

Figyelem: kínban született - de tapasztalat szerint működő - megoldás, átgondolni!

Work in progress - még ne vedd komolyan!

Házirend

A WordPress filozófiája szerint "a WordPress arra való, hogy publikálj, és nem arra, hogy harcolj vele" (ld. itt), így készítői úgy igyekszenek kialakítani a szerveralkalmazást, hogy annak üzemeltetéséhez minimális közreműködés kelljen a szervergép illetve az alapszintű szolgáltatások (webszerver, adatbázis-szerver) üzemeltetőjétől. Sajnos ennek hátulütője, hogy a kódkarbantartás ugyanazon eszközzel és rendszerszintű hozzáféréssel - a publikus webfelületen keresztül - történik, mint a mindennapi webszolgáltatás. Ily módon a publikus webszervert futtató rendszerfelhasználó (www-data) jogosult kódállományok írására, ami nézetem szerint nagyon előnytelen kompromisszum a biztonság rovására. A jelen leírásban igyekszünk a kódkarbantartást szeparálni, és a wsm2-ben szokásos módon azt kizárólag a webadmin rendszerfelhasználó nevében futó WebDAV szolgáltatás számára fenntartani, korlátozva ezzel a WordPressen belüli adminisztrátor és az esetleges automatikus frissítőprogramok jogait és lehetőségeit.

Megjegyzés: lehetséges lenne az adminisztrációs részt más Linux felhasználó (wsm2 policy esetén webadmin) nevében futtatni - az apache2-mpm-itk és a rewrite modul erre lehetőséget ad - TODO!.

Hasonlóan más LAMP webalkalmazásokhoz, a WordPresst is úgy kívánjuk üzemeltetni, hogy:

  • ne igényeljen dedikált gépet, egy szervergépen - más-más Apache virtualhostok alatt - több példány (instance) is működjön;
  • a példányok egy közös, frissíthető kódkészletet használjanak, amely csak olvasható tárterületen (/usr/local/share) helyezkedjen el;
  • minden példány adatterülete a hozzá kapcsolódó virtualhost területén (/var/www/[virtualhost]) belül egyetlen írható könyvtár legyen;
  • minden példány önálló, dedikált MySQL adatbázist használjon.

Ennek érdekében a következő fájlterületeket alakítjuk ki:

A példány saját tárterülete                   Közös (rendszergazda által frissített) tárterület
===========================                   =================================================
/var/www/[virtualhost]/                       /usr/local/share/
                                                        wordpress/ -> wordpress-versions/wordpress-X.Y.Z-hu
              wp-admin/ -------------------------------> wp-admin/         # Közös kódkészlet, adminisztrációs felület
            wp-content/                                                    # Saját adatterület (languages, plugins, themes, upload)
           wp-includes/ ----------------------------> wp-includes/         # Közös kódkészlet
          wp-config.php                                                    # Saját beállítások
            [any other] -----------------------------> [any other]         # Közös kódkészlet

A példány saját tárterülete a wsm2-nek megfelelően a webadmin:www-data tulajdonában van a szokásos 2750/640 jogokkal (kivéve a látogató által is írható /wp-content/uploads, amely 2770/660 jogokkal). A közös tárterület a root:www-data tulajdonában van 750/640 jogokkal, R/O csatolt partíción.

A telepítés során az alábbi névkonvenciókat alkalmazzuk:

  • a WordPress instance-nak van egy egyedi (technikai) neve (a továbbiakban BLOGNAME)
    • a használt adatbázis neve wp_BLOGNAME;
    • az adatbázis-felhasználó neve wp_BLOGNAME;
  • minden fenti account jelszava generált;
  • a WordPress instance egyedi (technikai) nevének nem muszáj közvetlen összefüggésben lennie a virtualhost névvel (bár ez célszerű);

TODO!

Előfeltételek

  • Házirend szerint telepített LAMP szerver: Apache2 és wsm2, MySQL, PHP;
  • A PHP globális beállításai között az include és mail függvények engedélyezése (wsm2-ben ez alapértelmezett);
  • TODO!

Telepítés

Noha a Debian disztribúció a WordPresst tartalmazza, utóbbi gyorsabban fejlődik, mint azt a Debian kiadások követik, így érdemes a mindenkori legfrissebb változatot telepíteni.

A telepítéshez a /usr partíciót írhatóan kell csatolnunk, ezután ellenőrizzük a legfrissebb stabil kiadás verziószámát (érdemes a magyar nyelvűt használni), és a /usr írhatóan újracsatolása után csomagoljuk ki a /usr/local/share/wordpress-versions/wordpress-X.Y.Z-hu könyvtárba a házirend szerinti jogosultságok beállításával, pl. az alábbi parancsokkal:

mount -o remount,rw /usr  # Írni kell ide
WP_VERSION="X.Y.Z-hu"     # Töltsük ki az aktuális verzióval!

# Közös kódkészlet könyvtárának elkészítése
mkdir /usr/local/share/wordpress-versions; chown root:staff /usr/local/share/wordpress-versions
mkdir /usr/local/share/wordpress-versions/wordpress-$WP_VERSION

# Letöltés, kicsomagolás
cd /root/tmp
wget http://hu.wordpress.org/wordpress-$WP_VERSION-hu_HU.tar.gz # linket ellenőrizni, változhat!
tar xzvf wordpress-$WP_VERSION-hu_HU.tar.gz -C /usr/local/share/wordpress-versions/wordpress-$WP_VERSION --strip-components=1

# Jogosultságok beállítása
chown -R root:www-data /usr/local/share/wordpress-versions/
find /usr/local/share/wordpress-versions/ -type d -exec chmod 750 {} \;
find /usr/local/share/wordpress-versions/ -type f -exec chmod 640 {} \;

# Symlink az aktuális verzióra
ln -s wordpress-versions/wordpress-$WP_VERSION /usr/local/share/wordpress
chown -h root:www-data /usr/local/share/wordpress

Sajnos a WordPress fejlesztői a blogmotor bootstrap loader részében a kódállományok könyvtárának meghatározására a PHP __FILE__ változóját használják, amely a symlinkelt útvonalakat abszolút útvonallal helyettesíti, így lehetetlenné teszi, hogy a document root-ba kódállományt linkeljünk. Ezért egyetlen helyen kénytelenek vagyunk a kódkészletet megváltoztatni. Szerkesszük meg a wp-load.php állományt az alábbiak szerint:

-rw-r----- root www-data /usr/local/share/wordpress/wp-load.php

[...]

/** Define ABSPATH as this files directory */
//define( 'ABSPATH', dirname(__FILE__) . '/' );
define( 'ABSPATH', $_SERVER['DOCUMENT_ROOT'] . '/' );

[...]

Ezt a patchelést sajnos minden kódfrissítéskor újra el kell végeznünk.

A telepítés befejezéseként csatoljuk újra csak olvashatóan a /usr partíciót:

mount -o remount /usr

Ezzel a WordPress core-t telepítettük, a továbbiakban a közös és virtualhostonként külön-külön alkalmazható beállításokat tekintjük át.

Megjegyzés: a telepített WordPresst itt még nem tudjuk kipróbálni, csak ha a lentiek szerint legalább egy konkrét WordPress website-ot is telepítünk.

WordPress példány készítése

MySQL adatbázis készítése

A MySQL adatbázisnak egyetlen, az adatbázisra nézve teljes jogú felhasználója van, akinek neve célszerűen megegyezik az adatbázis nevével. Az adatbázist és a felhasználót a MySQL root hozzáféréssel hozzuk létre.

mysql --defaults-file=/etc/mysql/root.cnf

mysql> CREATE DATABASE wp_BLOGNAME DEFAULT CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON wp_BLOGNAME.* TO 'wp_BLOGNAME'@'localhost' IDENTIFIED BY 'PASSWORD';
mysql> FLUSH PRIVILEGES;

ahol a PASSWORD egy megfelelő jelszó. Relatív megjegyezhető, mégis erős jelszó a pwgen segédprogrammal is generálható, pl. a következőképpen:

/usr/bin/pwgen -s -n -c 12 1

Ellenőrizzük, hogy a felhasználó megfelelően létrejött-e:

mysql> SELECT host, user, password FROM mysql.user ORDER BY user;
+-----------+------------------+---------------------------------------------+
| host      | user             | password                                    |
+-----------+------------------+---------------------------------------------+
| localhost | wp_BLOGNAME      | *73CDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
[...]
+-----------+------------------+---------------------------------------------+

mysql> quit

Ezután próbáljunk a létrehozott felhasználó nevében és jelszavával belépni. Az alábbi parancsokkal ellenőrizhetjük, hogy a felhasználó jogosultságai valóban csak erre a WordPress adatbázisra terjednek ki:

mysql -u wp_BLOGNAME -p
Enter password:

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| wp_BLOGNAME        |
+--------------------+

A felhasználó felvételét és kipróbálását követően töröljük le a .mysql_history állományt, mert ebben a jelszó szabad szöveges formában benne van:

rm ~/.mysql_history

Az adatbázis iniciális feltöltését a telepítő PHP script végzi.

Apache virtualhost készítése

Leírásunkban a http://fully.qualified.hostname weboldal közvetlenül a WordPress példány nyitólapjára mutat. A virtualhostot a szokott módon, a wsm2 segítségével készítjük el; ennek 2.6 vagy későbbi verzióinál, ha van a /etc/ssl/certs-ben elhelyezett, hitelesített webszerver SSL tanúsítványunk, annak fájlnevét (kiterjesztés nélkül) megadhatjuk harmadik paraméterként (ellenkező esetben önaláírt tanúsítvány készül):

wsm2 -cw FULLY.QUALIFIED.HOSTNAME sysadmin@MYDOMAIN certificate_name

A beállítások idejére érdemes a virtualhostot letiltani (így nem kapunk feleslegesen cron, stb. hibaüzeneteket):

a2dissite FULLY.QUALIFIED.HOSTNAME
systemctl reload apache2

Filerendszer beállítások

  • A wsm által létrehozott config, download könyvtárakat és az index.html állományt töröljük.
  • A virtualhost tárterületén az egyedi tartalom részére a tárterületet (a wp-content könyvtárat) fizikailag is el kell készíteni. Ebben a könyvtárban találhatóak a webhelyre nézve egyedi kiegészítők (languages, plugins, themes, stb.) illetve a szerkesztők és felhasználók által feltöltött tartalom (uploads) - ez utóbbira a www-data-nak írásjogot is kell adjunk.
  • A /usr/local/share/wordpress alatti összes többi tartalmat egyszerűen belinkeljük.
cd /var/www/FULLY.QUALIFIED.HOSTNAME
pwd # Biztos, ami biztos..

rmdir config download
rm index.html

export WORDPRESS="/usr/local/share/wordpress"
echo $WORDPRESS; ls $WORDPRESS # Biztos, ami biztos... :-)

# Tárterület
mkdir -m 2750 wp-content; chown webadmin:www-data wp-content
mkdir -m 2750 wp-content/languages wp-content/plugins wp-content/themes
chown webadmin:www-data wp-content/languages wp-content/plugins wp-content/themes
mv upload wp-content/uploads

# Symlinkek
ln -s $WORDPRESS/wp-content/languages/* wp-content/languages/
ln -s $WORDPRESS/wp-content/plugins/* wp-content/plugins/
ln -s $WORDPRESS/wp-content/themes/* wp-content/themes/
ln -s $WORDPRESS/wp-content/* wp-content/
ln -s $WORDPRESS/* .
# Tulajdonjog átruházása (csak szépség)
find . -type l -exec chown -h webadmin:www-data {} \;

# A .txt-k és .html-ek nem kellenek, kivéve robots.txt
rm `ls -1 *.html *.txt | grep -iv robots.txt`
  • A WordPress rewrite API-t támogató .htaccess már nem fájlként szerepel a telepítőkészletben, hanem azt a felhasználóbarát URL-ek adminisztrátori bekapcsolásakor a WordPress megpróbálja elkészíteni a gyökérkönyvtárban az aktuális környezetnek (a webszerver típusa, a WordPress alapkönyvtára a document root-on belül, stb.) megfelelő tartalommal. Házirendünk szerint, írásjog hiányában ez nem sikerülhet, így ezt az állományt kénytelenek vagyunk előre, manuálisan elkészíteni:
touch .htaccess; chown webadmin:www-data .htaccess; chmod 640 .htaccess
-rw-r----- webadmin www-data .htaccess

# Rewrite API support for permalinks.
# See also http://codex.wordpress.org/Using_Permalinks

# BEGIN WordPress
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>
# END Wordpress

Ez a rewrite a felhasználóbarát URL-ek kikapcsolása esetén sem ártalmas (csak felesleges); nem gátolja (csak kissé lassítja) a működést.

A WordPress konfigurációs állomány előkészítése

A symlinkelések (pontosabban a symlinkeket abszolút útvonallá konvertáló PHP __FILE__ használata miatt) miatt a WordPress telepítő konfigurációs állomány nélkül nem tud elindulni, ezért azt manuálisan kell elkészítenünk.

Másoljuk a példa konfigurációs állományt a virtualhost gyökérkönyvtárába:

cp $WORDPRESS/wp-config-sample.php wp-config.php
chown webadmin:www-data wp-config.php; chmod 640 wp-config.php

Szerkesszük meg az állományt:

  • töltsük ki az adatbázis-hozzáférések adatait;
  • az állományban is szereplő linken generáljunk új secret key-ket és cseréljük ki ezekkel az állomány azonos nevű (alapértelmezett) sorait;
  • rögzítsük a WordPress könyvtár abszolút elérési útját (elkerülendő a symlinkek feloldásából származó bonyodalmakat) az alábbiak szerint:
-rw-r----- webadmin www-data /var/www/FULLY.QUALIFIED.HOSTNAME/wp-config.php

[...]

/** A WordPress könyvtár abszolút elérési útja. */
define('ABSPATH', '/var/www/FULLY.QUALIFIED.HOSTNAME/');
if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');
[...]

Webszerver beállítások

Módosítsuk a virtualhost (a wsm2 által létrehozott) Apache konfigurációját:

  • a teljes virtualhostra vonatkozóan:
    • felvesszük az esetleges ServerAlias-okat;
    • engedélyezzük a PHP futtatását, engedélyezünk 32 MB RAM használatot;
    • módosítjuk az open_basedir és include_path bejegyzéseket, hozzátesszük a WordPress kódkönyvtárát;
    • engedélyezzük a PHP file feltöltést, ha az APC telepítve van, a progress bar-t, megadunk méretkorlátot és egy ideiglenes könyvtárat;
    • tiltjuk a ModSecurity-t (mindenféle gonoszság várható, amire értelmesen nem tudok szűrni - TODO!);
  • speciálisan a wp-admin könyvtárra:
    • TODO!
  • speciálisan a wp-content/uploads (írható) könyvtárra:
    • engedjük a közvetlen fájlkiszolgálást;
    • engedjük a symlinkek követését;
  • a nem használt (törölt) könyvtárakra vonatkozó bejegyzéseket törölhetjük;
  • a virtualhost ssl konfigurációját az esetleges ServerAlias-ok felvételét kivéve nem kell módosítani.
-rw-r--r-- root root /etc/apache2/sites-available/FULLY.QUALIFIED.HOSTNAME.conf

<VirtualHost *:80>
[...]
    <IfModule mod_php5.c>
        php_admin_flag engine on
        php_admin_value open_basedir /var/www/FULLY.QUALIFIED.HOSTNAME/:/usr/local/share/wordpress/
        php_admin_value include_path .:/usr/local/share/wordpress/
        #php_admin_value safe_mode_exec_dir bin/
        php_admin_value memory_limit 32M
        [...]
        php_admin_value file_uploads on
#       php_admin_flag apc.rfc1867 on
        php_admin_value upload_max_filesize 10M
        php_admin_value post_max_size 10M
        php_admin_value upload_tmp_dir /var/www/FULLY.QUALIFIED.HOSTNAME/wp-content/uploads/
        [...]
    </IfModule>
[...]
    # ModSecurity settings (entire virtualhost).
    <IfModule security2_module>
        # Engine On/Off/DetectionOnly.
        SecRuleEngine Off
        [...]
    </IfModule>
[...]
    # Official upload directory (writable by www-data).
    <Directory /var/www/FULLY.QUALIFIED.HOSTNAME/wp-content/uploads>
        Require all granted
        [...]
        Options +FollowSymLinks
#       Options -SymLinksIfOwnerMatch
        [...]
    </Directory>
[...]

Ezzel a WordPress virtualhost alapbeállítása megtörtént, az a virtualhost engedélyezése és a webszerver konfiguráció újraolvasása után használatba vehető:

a2ensite FULLY.QUALIFIED.HOSTNAME
systemctl reload apache2

Használatba vétel

Tekintettel arra, hogy a frissen telepített WordPress az első, arra tévedő felhasználónak lehetőséget ad adminisztrátori hozzáférésre, a használatba vételt a webszerver konfiguráció újraolvasása után azonnal el kell végezni!

Egy, a telepítés alatti szervert elérő munkaállomás grafikus böngészőjében hívjuk be a http://FULLY.QUALIFIED.HOSTNAME/ weboldalt, ami a WordPress "híres, 5 perces telepítőjére" visz. Itt csak az adminisztrátori email címet kell megadni, a jelszót érdemes a WordPress-sel generáltatni. A telepítő:

  • inicializálja a MySQL táblákat;
  • minimális, alapértelmezett tartalommal tölti fel a blogot;
  • beállítja az alapértelmezett témát (ettől kezdve a http://FULLY.QUALIFIED.HOSTNAME alatt a blog publikus felhasználói felülete megjelenik);
  • véletlen belépési jelszót generál a blog adminisztrátor számára, ezt kiírja, illetve e-mail-ben is elküldi.

A létrehozott blog ezután rendeltetésszerű használatba vehető.

Célszerű beállítások

Mielőtt a WordPress blogot átadjuk leendő adminisztrátorának, érdemes néhány technikai beállítást elvégezni (és megkérni a leendő adminisztrátort, hogy ezeken a későbbiekben ne változtasson). Az ebben a szakaszban leírtakhoz konzolos bejelentkezés nem feltétlenül szükséges, a telepítések a wsm2-ben szokásos módon, DAV feltöltéssel történhetnek, a beállításokat a WordPress adminisztrátori webfelületén lehet elvégezni.

Még rendezés alatt, ne vedd komolyan!

A webhely általános beállításai

Webcron beállítása

A WordPress rendelkezik beépített poor man's cron funkcióval, azaz minden látogatáskor ellenőrzi, hogy szükséges-e cron jobot futtatnia. A wsm2 urlcheck funkciója gondoskodik a látogatói felület fél óránkénti meghívásáról, ami általában elegendő a karbantartási feladatok számára. Ennél gyakrabb futtatás célszerűen a .htacrontab állományban írható elő.

TODO!

Pluginok telepítése és bekapcsolása

A WordPress funkcionalitásának jelentős része a WordPress plugin gyűjteményéből beszerezhető beépülő modulokban van megvalósítva (Plugins can extend WordPress to do almost anything you can imagine). Amennyiben a WordPresst futtató webszervernek írásjoga volna a virtualhost teljes tárterületére, a pluginok telepítése az adminisztrátori webfelületen "egy gombnyomással" is megoldható lenne (TODO!), de a szigorúbb házirend miatt a pluginokat csak külső eszközökkel lehet telepíteni:

  • felhasználói munkaállomáson letöltve és kicsomagolva, DAV hozzáférésen (wsm2 webmaster) keresztül a /wp-content/plugins könyvtárba feltöltéssel - ez esetben a szervergépen a fájlrendszerbeli jogosultságok automatikusan megfelelőek lesznek;
  • a szervergépre (webadmin vagy root felhasználóként) konzolos belépés után egy ideiglenes könyvtárba letöltve és onnan a /wp-content/plugins könyvtárba kicsomagolva. A kicsomagolást követően be kell állítanunk a megfelelő fájlrendszerbeli jogosultságokat:
cd /var/www/FULLY.QUALIFIED.HOSTNAME
find wp-content/plugins/PLUGIN_KONYVTARA -type d -exec chown webadmin:www-data {} \; -exec chmod 2750 {} \;
find wp-content/plugins/PLUGIN_KONYVTARA -type f -exec chown webadmin:www-data {} \; -exec chmod 640 {} \;

Ezt követően a plugin megjelenik az adminisztrátori webfelület Bővítmények listájában, ahol bekapcsolható és konfigurálható.

Frissítések követése

A frissítések követése alapvető biztonsági követelmény, de a WordPress automata frissítése környezetünkben nem működik (a core frissítése rendszergazda beavatkozást, minden egyéb - theme, plugin, stb. - frissítés webadmin belépést vagy DAV feltöltést igényel). Ezért a Stops Core Theme and Plugin Updates (aka Disable Updates Manager) plugin segítségével ezt a funkciót letiltjuk, de a WP Updates Notifier plugin segítségével naponkénti ellenőrzést végeztetünk és email értesítést kérünk a szükséges frissítésekről:

  • WP Updates Notifier - bekapcsolás után állítsuk be: Frequency to check - Daily, Notify email to - célszerűen két, vesszővel elválasztott email cím; egy a szervergép rendszergazdája számára a core frissítése miatt, egy a blog DAV-hozzáféréssel rendelkező technikai adminisztrátora számára a pluginok és témák frissítése miatt; Notify email from létezzen, Notify about plugin/theme updates? - Yes but only active, Save settings with test email. Ellenőrizzük a tesztlevél megérkezését, hiba esetén vegyük figyelembe, hogy az envelope-from headerben a www-data@serverhostname.serverdomainname.tld feladó van (sender-verify probléma lehet!).
Kommentek és közösségi tartalom kezelése

A közösségi aktivitás emeli egy webhely értékét, viszont szükségessé válik az anonym spam kommentek, botreklámok, stb. kivédése. Az előmoderálásnál hatékonyabb, gazdaságosabb lehet az automata beküldések megakadályozása pl. valamilyen captcha alkalmazásával, vagy azok tartalomszűrése, pl. a WordPress alapértelmezésben telepített Akismet pluginjának használatával. Lehetőségünk van arra is, hogy a közösségi aktivitást inline Facebook felületen valósítsuk meg.

  • A Captcha plugin egyszerű számtani művelet elvégzését követeli meg a beküldőtől. Telepítés után kapcsoljuk be, majd állítsuk be - Captcha settings: CAPTCHA regisztrált felhasználóknak ki. A többi beállítás egyelőre megfelelőnek tűnik.
  • Az Akismet filter alapértelmezésben telepítve van, használatba vételéhez be kell szerezni egy API key-t - ehhez a WordPress.com-on felhasználóként regisztrálni kell. A regisztráció megerősítése után kapott levél tartalmazza a kulcsot, amivel az Akismet bekapcsolható. TODO!
  • Facebook - TODO!

Témák telepítése és beállítása

Karbantartás

WordPress közös kódkészlet (core) frissítése

A core frissítésekor rendszergazdaként belépve az új verziót a /usr/local/share/wordpress-versions/wordpress-3.X-hu könyvtárba telepítjük, majd a /usr/local/share/wordpress symlinket ide irányítjuk, ezzel az összes instance-ban egyszerre(!) lecseréljük a core kódkészletet. A frissítéshez az egyes blog adminisztrátorok közreműködése nem szükséges, de érdemes őket a műveletről utólag értesíteni.

A frissítéshez a /usr partíciót írhatóan kell csatolnunk, ezután szerezzük be a legfrissebb stabil (magyar) WordPress verziót, és a /usr írhatóan újracsatolása után csomagoljuk ki a /usr/local/share/wordpress-versions/wordpress-X.Y.Z-hu könyvtárba a házirend szerinti jogosultságok beállításával:

mount -o remount,rw /usr  # Írni kell ide
WP_VERSION="X.Y.Z-hu"     # Töltsük ki az aktuális verzióval!

# Közös kódkészlet könyvtárának elkészítése
mkdir /usr/local/share/wordpress-versions/wordpress-$WP_VERSION

# Letöltés, kicsomagolás
cd /root/tmp
wget http://hu.wordpress.org/wordpress-$WP_VERSION\_HU.tar.gz # linket ellenőrizni, változhat!
tar xzvf wordpress-$WP_VERSION\_HU.tar.gz -C /usr/local/share/wordpress-versions/wordpress-$WP_VERSION --strip-components=1

# Jogosultságok beállítása
chown -R root:www-data /usr/local/share/wordpress-versions/wordpress-$WP_VERSION 
find /usr/local/share/wordpress-versions/wordpress-$WP_VERSION -type d -exec chmod 750 {} \;
find /usr/local/share/wordpress-versions/wordpress-$WP_VERSION -type f -exec chmod 640 {} \;

Sajnos a WordPress fejlesztői a blogmotor bootstrap loader részében a kódállományok könyvtárának meghatározására a PHP __FILE__ változóját használják, amely a symlinkelt útvonalakat abszolút útvonallal helyettesíti, így lehetetlenné teszi, hogy a document root-ba kódállományt linkeljünk. Ezért egyetlen helyen kénytelenek vagyunk a kódkészletet megváltoztatni. Szerkesszük meg a wp-load.php állományt az alábbiak szerint:

-rw-r----- root www-data /usr/local/share/wordpress-versions/wordpress-$WP_VERSION/wp-load.php

[...]

/** Define ABSPATH as this files directory */
//define( 'ABSPATH', dirname(__FILE__) . '/' );
define( 'ABSPATH', $_SERVER['DOCUMENT_ROOT'] . '/' );

[...]

Ezt a patchelést sajnos minden kódfrissítéskor újra el kell végeznünk.

A frissítés érvényesítéseként módosítsuk a /usr/local/share/wordpress symlinket úgy, hogy az imént létrehozott kódkönyvtárra mutasson, majd csatoljuk újra csak olvashatóan a /usr partíciót:

# Webszerver stop (PHP cache-elés miatt - elkerülése TODO!)
systemctl stop apache2
# Symlink az aktuális verzióra
if [ -L /usr/local/share/wordpress ]; then rm /usr/local/share/wordpress; fi
ln -s wordpress-versions/wordpress-$WP_VERSION /usr/local/share/wordpress
chown -h root:www-data /usr/local/share/wordpress
# Webszerver start
systemctl start apache2

# Már nem kell írni ide
mount -o remount /usr

A frissítés befejezéseként minden telepített WordPress instance-ban (böngészőből, adminisztrátori belépés nélkül) meg kell hívni az esetleges adatbázis-változtatásokat (MySQL ALTER) végrehajtó http://FULLY.QUALIFIED.HOSTNAME/wp-admin/upgrade.php weblinket!

WordPress pluginok frissítése

A frissítéshez egyszerűen ki kell cserélnünk a /wp-content/plugins/PLUGIN_FOLDER tartalmát a plugin frissített változatának tartalmára. A friss változat tömörítvényére mutató linket a frissítés szükségességéről küldött levél általában tartalmazza. Lehetőség szerint forgalommentes időben:

  • a frissítést egy felhasználói munkaállomásra letöltve és kicsomagolva, DAV hozzáférésen (wsm2 webmaster) keresztül végezzük el a cserét - ez esetben a szervergépen a fájlrendszerbeli jogosultságok automatikusan megfelelőek lesznek;
  • a szervergépre (webadmin vagy root felhasználóként) konzolos belépés után a frissítést egy ideiglenes könyvtárba letöltve cseréljünk. A kicsomagolást követően be kell állítanunk a megfelelő fájlrendszerbeli jogosultságokat:
cd /var/www/FULLY.QUALIFIED.HOSTNAME
find wp-content/plugins/PLUGIN_KONYVTARA -type d -exec chown webadmin:www-data {} \; -exec chmod 2750 {} \;
find wp-content/plugins/PLUGIN_KONYVTARA -type f -exec chown webadmin:www-data {} \; -exec chmod 640 {} \;

A frissítést követően érdemes meghívni a http://FULLY.QUALIFIED.HOSTNAME/wp-admin/upgrade.php scriptet, hogy az esetleges adatbázis-változások (MySQL ALTER) megtörténjenek.

Bárhogy is végezzük a frissítést, hasznos lehet a leváltott verziót (pl. a /wp-content/plugins.bak könyvtárba) archiválni, mert tapasztalat szerint a frissített változatban sajnos előfordulhat blokkoló hiba - ez esetben a visszaállítás a legegyszerűbb (ideiglenes) megoldás.

Migráció korábbi WordPress változatról

TODO!

Irodalom

  • A Wordpress hivatalos honlapja
  • A WordPress magyar honlapja
  • WordPress Codex - the online manual for WordPress and a living repository for WordPress information and documentation.