Určitě víte, že WordPress obsahuje soubor s nastavením wp-config.php. Jsou v něm základní informace pro „oživení“ WordPressu a pro úpravu některých parametrů. Několik z nich si dnes projdeme, ale tento článek bude hlavně o dalších důležitých souborech vašeho WordPressu. Možná jste o nich ani moc neslyšeli.
Obsah článku
Soubor wp-config.php, hlavní motor
Tak ten hlavní konfigurák je wp-config.php, najdete ho v kořenové složce, na stejné úrovni pak jsou složky wp-admin, wp-content a wp-includes. Ve wp-config.php je nastavení pro připojení do databáze, podle potřeby několik konstant a spousta komentářů. Na jeho konci se postupně natahuje (bootstrapuje) v konkrétních krocích celá aplikace.
Které konstanty jsou pro nás jako správce důležité a proč? Tak hlavně bychom měli vědět, kam sáhnout, když je něco rozbité nebo nefunguje. Z tohoto pohledu vybírám následující:
- ujistěte se, že používáte aktivní solení pro vytváření dostatečně jedinečných hesel a hashů (ty se používají např. pro nonce ověřování dat formulářů); použijte generátor solí,
- ujistěte se, že znáte správný prefix pro tabulky v databázi (
$table_prefix), stalo se mi, že v databázi byly tři sady tabulek a nevěděl jsem, která z nich se používá, - konstanta
WP_DEBUGje určena především vývojářům a slouží k usnadnění vývoje pluginů a šablon vzhledu. Správce by ji ale měl používat na pracovní kopii webu a sledovat výstupy, zda mu web negeneruje chyby, resp. je ukládat do souboru pomocíWP_DEBUG_LOG, AUTOSAVE_INTERVALurčuje frekvenci pro uložení revize editovaného článku v sekundách, standard je každých 60 sekund, můžete změnit:define('AUTOSAVE_INTERVAL', 160 );WP_POST_REVISIONS– revize samozřejmě zabírají místo v databázi a touto konstantou je můžete zakázat (nastavte hodnotufalse). Tím se ale připravíte o historii článku. Můžete také snížit počet revizí, pak zadejte číselnou hodnotu:define('WP_POST_REVISIONS', 3 );DISALLOW_FILE_EDITzakáže v administraci editor pro pluginy a šablony, což je dobrý nápad a zvyšuje to zabezpečení celé instalace,DISALLOW_FILE_MODSzase zakáže možnost aktualizovat WordPress, pluginy a šablony a také zakáže editory v předchozím bodě. Aktualizace se pak provádějí ručně nebo pomocí externí aplikace.WP_AUTO_UPDATE_COREzakáže nebo omezí automatické aktualizace jádra, které probíhají jen pro případ „třetiřadých“ minoritních verzí jako 6.8.2 na 6.8.3.WP_MEMORY_LIMITslouží ke změně paměťového limitu pro WordPress, pokud to povoluje samotné prostředí, tedy PHP. Pokud PHP nastavuje limit na 128 MB, pak zde více než 128 nevymáčknete.define('WP_MEMORY_LIMIT', '128M' );WP_CACHEaktivují cachovací pluginy a vede k tomu, že se místo spouštění celého WordPressu budou načítat soubory připravené v adresářiwp-content/cache. Pro vás jako správce je to hlavně informace o tom, že cache je aktivní (nebo aktivní být má).FS_METHOD: Jde o způsob, jakým WordPress přistupuje k souborům při instalaci a aktualizaci. Základní hodnotou jedirect, kdy se používá nejjednodušší přímý přístup přes PHP. Měl by fungovat všude, ale v praxi tomu tak není. Pokud se snažíte aktualizovat web a vyskakuje na vás přihlašovací okno pro FTP, pak zkuste nastavitdefine('FS_METHOD', 'direct' );
Tady máte všechny direktivy pro wp-config.php.
debug.log, drby a pomluvy
Hned další v pořadí, který chci zmínit, je soubor debug.log v adresáři /wp-content/, který obsahuje chybová hlášení WordPressu, pokud si je aktivujete direktivami uvedenými výše. Na některých hostinzích si můžete v jejich administraci zapnout chybový soubor pro PHP, který se pak objevuje v kořenovém adresáři jako error_php.log nebo podobně. Může být i v samostatném adresáři mimo WordPress a nemusí být vůbec dostupný přes http.
Servisní režim, zlobidlo
Soubor .maintenance je takový enfant terrible. Objeví se vždy v nejblbější chvíli a zablokuje vám web. Slouží totiž k odstavení webu během aktualizací jádra nebo pluginů a jeho existence se má měřit na maximálně desítky sekund. Jenže někdy aktualizační proces neproběhne správně a soubor tam zůstane. Svou existencí blokuje všechny požadavky na web, což znamená, že web není použitelný, zobrazuje se pouze stručná hláška. Bohužel se ani nelze přihlásit do administrace.
Soubor lze odstranit pouze smazáním z SFTP/serveru. Je to nemilá vlastnost, která způsobuje hodně mrzení.
WAF, ochranka
Některé budovy mají ochranku. Většinou chlapy v uniformách nebo maníky v saku s ježkama v podpaží; podle toho, kam se snažíte jít. Na webu můžete mít taky ochranku, firewall, který kontroluje každý příchozí požadavek. To lze zařídit nastavením PHP, konkrétně direktivou auto_prepend_file, které jako hodnotu přidělíte cestu ke skriptu-ochrance (třeba wordfence-waf.php). Tento zápis se pro individuální weby (na sdíleném hostingu) ukládá do souboru .user.ini (viz nápověda PHP).
; Wordfence WAF
;auto_prepend_file = '/home/master/applications/nregephqn/public_html/wordfence-waf.php'
; END Wordfence WAFJe to spíše výjimka, protože pokud nemáte sdílený hosting, pak se vše dá nastavit přímo u webového serveru. Taktéž jde nastavení pro PHP měnit prostřednictvím .htaccess.
.htaccess, šedá eminence
To je vůbec zajímavý soubor, ten .htaccess. Používá ho webový server Apache jako individuální konfiguraci webu, která má přednost před globálním nastavením (webového serveru). Opět se používá na sdíleném hostingu, kde tyto individuální požadavky vznikají.
Zapisuje se sem přesměrování, nastavení tvaru odkazů nebo omezení přístupu k souborům a adresářům. Dejte pozor – pravidla mohou platit pro všechny podřízené adresáře, pokud v nich není další .htaccess, jde tedy o pravidlo padajacího…pada.. vodopádu.
Můžete využít generátor pravidel pro .htaccess nebo validátor, ale žádný vám nedoporučím, protože je nepoužívám (a chtějí zadat konkrétní url).
Pokud vám web jede na webovém serveru NGinx, pak se nepoužívá soubor .htaccess, nýbrž nginx.conf. V zásadě má stejnou funkci a využití, ale jinou syntaxi a jiné příkazy. Obecně ale platí, že prostředí pro web by mělo být nastaveno už na serveru, použijte doporučené nastavení pro WordPress.
Specialisté na výkon
Další soubory plní speciální funkce a nejsou konfigurační. Říká se jim dropiny. Vytvářejí je podle funkce různé pluginy v adresáři /wp-content/ a dropin daného jména může být logicky jen jeden. Další plugin ho tedy už nemůže vytvořit, což znamená, že jde o koncepční rozhodnutí, kterému pluginu to dovolíte. Typicky jde o cachovací dropiny.
- advanced-cache.php, object-cache.php – ovlivňují chování cache, např. napojení externí objektové cache Redis, memcached,
- maintenance.php – vlastní obsluha pro servisní režim,
- sunrise.php – přesměrování požadavků na správný web v síti webů (multisite),
- db.php – úprava komunikace s databází, např. sledování výkonu databáze, příklad použití v Query Monitoru,
- db-error.php – vlastní šablona pro zobrazení chyb databáze, příklad použití,
- fatal-error-handler.php – vlastní obsluha fatálních chyb, např. odeslání e-mailu, další informace
Ještě připomenu, že velmi podobnou funkcí mají must-use pluginy v adresáři /wp-content/mu-plugins/, které se spouštějí při každém načtení jádra WordPressu (což nemusí být ani celá aplikace WordPressu). Tyto pluginy musí být pouze jeden samostatný skript. Hostingy tak třeba realizují vlastní ochranu webu nebo nastavují cache, aniž by měnily hodnoty ve wp-config.php.
Von je tady zas
Řeč je o index.php. Musí být v každém podadresáři wp-admin/ a wp-includes/, měli byste ho mít i v pluginech a šablonách. Jeho obsah by měl být PHP komentář <?php // Silence is golden. Tento soubor je totiž na webovém serveru nastavený jako ten, který se všude hledá a spouští jako první. Tak bacha na útočníky a podvrhy.
