Konfigurationstips för WordPress
Många WordPress-användare känner till wp-config.php
-filen som nyckeln till WordPress-databasen. Det är där du ställer in databasens namn, användarnamn, lösenord och plats (bland annat säkerhetsnycklar, databasprefix och lokaliserat språk).
Här är en skärmdump av wp-config.php
(även kallad WordPress-konfigurationsfilen) för dem som kanske ännu inte är bekanta:
Men vad många användare inte vet är att wp-config.php
-filen kan användas för att ange en mängd olika konfigurationsinställningar, så att du kan förbättra funktionaliteten, prestandan och säkerheten för din WordPress-drivna webbplats. I den här artikeln delar jag med mig av så många av dessa konfigurationsknep som jag har kunnat samla in genom åren. Den här guiden täcker allt som finns i WordPress Codex, samt några ytterligare knep som du förmodligen inte har sett tidigare. Om du känner till några andra WordPress-konfigurationsknep, dela dem i kommentarerna så lägger jag till dem i inlägget.
Databasens autentiseringsuppgifter *
Den här uppsättningen av fyra konfigurationsdefinitioner krävs för att WordPress ska kunna ansluta till databasen:
define('DB_NAME', 'database-name');define('DB_USER', 'database-username');define('DB_PASSWORD', 'database-password');define('DB_HOST', 'localhost');
Databasens namn, användarnamn och lösenord bör vara lättillgängliga för dig under skapandet av databasen, men DB_HOST
-värdet kan vara svårare att få tag på. Vanligtvis är det här värdet helt enkelt ”localhost
”, men om det inte fungerar finns här några andra värden att prova:
- 1and1 Hosting –
db12345678
- DreamHost –
mysql.example.com
- GoDaddy –
h41mysql52.secureserver.net
- ICDSoft –
localhost:/tmp/mysql5.sock
- MediaTemple (GS) –
internal-db.s44441.gridserver.com
- Pair Networks –
dbnnnx.pair.com
- Yahoo –
mysql
Du kan även ange en alternativ port för din databasserver. Här är två exempel:
define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');
Ett annat coolt knep är att upptäcka värdet på databasservern automatiskt:
define('DB_HOST', $_ENV{DATABASE_SERVER});
Om alla dessa åtgärder misslyckas, eller om du fortfarande har problem, kan du kontakta din webbhotellleverantör för hjälp.
Databasens teckenuppsättning och kollation *
Från och med WordPress version 2.2 kan du ange en teckenuppsättning för dina MySQL-databastabeller. I allmänhet finns det ingen anledning att ändra standardvärdet för teckenuppsättningen UTF-8, som vanligtvis är perfekt eftersom det stöder alla språk. Här är standardinställningen (och den rekommenderade inställningen):
define('DB_CHARSET', 'utf8');
Med WordPress version 2.2 kan du också ange kollation, vilket är sorteringsordningen för teckenuppsättningen i din databas. Inställningen av collation hanteras i allmänhet automatiskt av MySQL i enlighet med teckenuppsättningen, vilket aktiveras genom att lämna collation-värdet tomt, vilket görs i standardinställningen för den här definitionen. Här är standardinställningen (och den rekommenderade inställningen):
define('DB_COLLATE', '');
wp-config.php
-fil.Säkerhetsnycklar *
Sedan WordPress 2.7 finns det fyra säkerhetsnycklar tillgängliga som är utformade för att säkerställa en bättre kryptering av cookies. Dessa nycklar arbetar tyst i bakgrunden och bör vara så slumpmässiga och komplicerade som möjligt (nej, du kommer aldrig att behöva komma ihåg dem). Det enklaste sättet att generera dessa nycklar är att göra det automatiskt på tjänsten för hemliga nycklar på WordPress.org. Besök helt enkelt den länken och kopiera/klistra in resultaten i din wp-config.php
-fil. Observera att dessa nycklar kan ändras när som helst, och om du gör det kommer alla dina användares befintliga cookies att ogiltigförklaras så att de måste logga in på nytt på din webbplats.
define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,<h\`39');define('SECURE_AUTH_KEY', '@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\`39m_(');define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al.'/path/to/wordpress');define('WP_SITEURL', 'http://'.$_SERVER.'/path/to/wordpress');
Det är förmodligen bäst att undvika dessa värden om du använder dem på en offentlig webbplats.
Mallsökväg och stilbladsökväg
Som med de fördefinierade konstanterna för bloggadress och webbplatsadress (se föregående avsnitt) kan du också öka prestandan genom att eliminera databasförfrågningar för mallsökväg och stilbladsökväg för din webbplats. Här är standardvärdena för dessa två definitioner:
define('TEMPLATEPATH', get_template_directory());define('STYLESHEETPATH', get_stylesheet_directory());
Som det är nu frågar dessa två definitioner fortfarande databasen, men vi kan eliminera dessa onödiga frågor genom att hårdkoda värdena på plats:
define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/active-theme');define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/active-theme');
Disable Cache and Cache Expiration
De här två alternativen gäller för äldre versioner av WordPress som fortfarande använder standardmekanismen för objektsbaserad caching. Med den första definitionen kan du aktivera eller inaktivera cacheminnet, medan du med den andra definitionen kan ange cacheminnets utgångstid.
Aktivera cacheminnet
define('WP_CACHE', true); // enable the cachedefine('ENABLE_CACHE', true); // enable the cachedefine('CACHE_EXPIRATION_TIME', 3600); // in seconds
Inaktivera cacheminnet
define('WP_CACHE', false); // disable the cachedefine('DISABLE_CACHE', true); // disable the cache
Specificera cookie-domän
Det finns flera anledningar till varför du vill ange en cookie-domän för din webbplats. Ett vanligt exempel handlar om att förhindra att kakor skickas med förfrågningar om statiskt innehåll på underdomäner. I det här fallet skulle du använda den här definitionen för att tala om för WordPress att skicka cookies endast till din icke-statiska domän. Detta kan vara en betydande prestandaförbättring. Här är några exempel på inställning av olika information om cookiesökväg och cookie-domän:
define('COOKIE_DOMAIN', '.digwp.com'); // don't omit the leading '.'define('COOKIEPATH', preg_replace('|https?://+|i', '', get_option('home').'/'));define('SITECOOKIEPATH', preg_replace('|https?://+|i', '', get_option('siteurl').'/'));define('PLUGINS_COOKIE_PATH', preg_replace('|https?://+|i', '', WP_PLUGIN_URL));define('ADMIN_COOKIE_PATH', SITECOOKIEPATH.'wp-admin');
Override File Permissions
Om din webbhotells standardfilbehörigheter är för restriktiva kan det hjälpa till att lösa problemet om du lägger till de här definitionerna i din WordPress-konfigurationsfil. Observera att du inte behöver citattecken runt behörighetsvärdena. Till exempel:
define('FS_CHMOD_FILE', 0755);define('FS_CHMOD_DIR', 0755);
Visa alla definierade konstanter
Behövs du visa alla fördefinierade konstanter? Goda nyheter, den här PHP-funktionen returnerar en array med alla för närvarande definierade konstanter:
print_r(@get_defined_constants());
Anpassade användar- och usermetatabeller
Hur är det med anpassade användar- och usermetatabeller? Ja, det kan du också göra med följande definitioner:
define('CUSTOM_USER_TABLE', $table_prefix.'my_users');define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');
FTP/SSH-konstanter
Den här uppsättningen konfigurationsdefinitioner är utformad för att hjälpa användare att hitta och använda FTP/SSH-anslutningar. Här är en exempeluppsättning av fördefinierade konstanter för FTP/SSH-uppdateringar:
define('FS_METHOD', 'ftpext'); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"define('FTP_BASE', '/path/to/wordpress/'); // absolute path to root installation directorydefine('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/'); // absolute path to "wp-content" directorydefine('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/'); // absolute path to "wp-plugins" directorydefine('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub'); // absolute path to your SSH public keydefine('FTP_PRIVKEY', '/home/username/.ssh/id_rsa'); // absolute path to your SSH private keydefine('FTP_USER', 'username'); // either your FTP or SSH usernamedefine('FTP_PASS', 'password'); // password for FTP_USER usernamedefine('FTP_HOST', 'ftp.domain.tld:21'); // hostname:port combo for your SSH/FTP server
Förflyttning av din wp-content-katalog
Sedan WordPress version 2.6 kan du ändra standardplaceringen av wp-content
-katalogen. Det finns flera goda skäl att göra detta, bland annat för att öka säkerheten på webbplatsen och underlätta FTP-uppdateringar. Några exempel:
// full local path of current directory (no trailing slash)define('WP_CONTENT_DIR', $_SERVER.'/path/wp-content'); // full URI of current directory (no trailing slash)define('WP_CONTENT_URL', 'http://domain.tld/path/wp-content');
Du kan också ange en egen sökväg för din plugins
-katalog. Detta kan hjälpa till med kompatibilitetsproblem med vissa plugins:
// full local path of current directory (no trailing slash)define('WP_PLUGIN_DIR', $_SERVER.'/path/wp-content/plugins'); // full URI of current directory (no trailing slash)define('WP_PLUGIN_URL', 'http://domain.tld/path/wp-content/plugins');
Hantering av inläggsrevisioner
Nyare versioner av WordPress tillhandahåller ett system för inläggsrevisioner som gör det möjligt för användare att spara olika versioner av sina blogginlägg och till och med återgå till tidigare sparade versioner om det behövs. Oavsett hur mycket du föraktar eller inte föraktar denna otroligt häftiga funktion finns här ett par konfigurationsdefinitioner som kan vara användbara för dig 😉
Begränsar antalet sparade revideringar
define('WP_POST_REVISIONS', 3); // any integer, but don't get too crazy
Deaktivera post-revisioning-funktionen
define('WP_POST_REVISIONS', false);
Specificera Autosave-intervallet
På samma sätt som post-revisioning-funktionen finns WordPress faktiskt användbara funktionalitet för autosparande. Som standard sparar WordPress ditt arbete var 60:e sekund, men du kan helt ändra denna inställning till vad du vill. Bli inte för galen om du inte vill stressa din server 😉
define('AUTOSAVE_INTERVAL', 160); // in seconds
Buggning av WordPress
Sedan WordPress version 2.3.1 har användarna kunnat visa vissa fel och varningar för att hjälpa till med felsökningen av sin webbplats. Från och med WordPress version 2.5 höjer aktivering av felrapportering rapporteringsnivån till E_ALL
och aktiverar varningar för föråldrade funktioner. Som standard (dvs. om ingen definition anges i wp-config.php
-filen) är felrapportering inaktiverad.
define('WP_DEBUG', true); // enable debugging modedefine('WP_DEBUG', false); // disable debugging mode (default)
Konfiguration av felloggning
Här finns ett enkelt sätt att aktivera grundläggande felloggning för din WordPress-drivna webbplats. Skapa en fil som heter ”php_error.log
”, gör den serverskrivbar och placera den i en valfri katalog. Redigera sedan sökvägen i den tredje raden i följande kod och placera den i din wp-config.php
-fil:
@ini_set('log_errors','On');@ini_set('display_errors','Off');@ini_set('error_log','/home/path/domain/logs/php_error.log');
Öka PHP-minne
Om du får felmeddelanden som talar om att din ”Tillåten minnesstorlek på xxx bytes är uttömd” kan den här inställningen hjälpa dig att lösa problemet. Från och med WordPress version 2.5 kan du med WP_MEMORY_LIMIT
-definitionen ange den maximala mängden minne som får användas av PHP. Som standard försöker WordPress automatiskt öka PHP-minnet upp till 32 MB, så den här inställningen behövs bara för värden som är högre än 32 MB. Observera att vissa webbhotell inaktiverar din möjlighet att öka PHP-minnet, så du kan behöva tigga för att de ska göra det. Här är några exempel:
define('WP_MEMORY_LIMIT', '64M');define('WP_MEMORY_LIMIT', '96M');define('WP_MEMORY_LIMIT', '128M');
Spara och visa databasfrågor för analys
Denna teknik är perfekt för att spara databasfrågor och visa informationen för senare analys. Processen sparar varje fråga, dess tillhörande funktion och dess totala exekveringstid. Informationen sparas som en array och kan visas på vilken sida som helst med temamall som helst. För att göra detta lägger du först till följande direktiv i din wp-config.php
-fil:
define('SAVEQUERIES', true);
Därefter placerar du följande kod i sidfoten av ditt aktiva tema:
// display the query array for admin onlyif (current_user_can('level_10')) {global $wpdb;echo "<pre>";print_r($wpdb->queries);echo "</pre>";}
Här är en enradig version av den här funktionen:
<?php if (current_user_can('level_10')) { global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; } ?>
Kontrollera proxyåtkomst
Sedan WordPress 2.8 kan konfigurationsfilen användas för att definiera konstanter som är involverade i att blockera, tillåta och filtrera åtkomst till specifika värdar bakom en proxyserver. Om du till exempel är värd för din WordPress-webbplats på ett intranät kan du förhindra åtkomst till alla externa värdar och endast tillåta förfrågningar från localhost och din blogg med hjälp av den första definitionen nedan. Du kan också tillåta åtkomst till specifika värdar med en kommaseparerad lista över tillåtna värdnamn, vilket visas i den tredje definitionen nedan.
define('WP_HTTP_BLOCK_EXTERNAL', true); // block external requestsdefine('WP_HTTP_BLOCK_EXTERNAL', false); // allow external requestsdefine('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org'); // whitelist hosts
api.wordpress.org
för att säkerställa korrekt funktionalitet för kärnfiler och plugins.Whew! Jag är helt slut. Dags för en liten paus 🙂
Anteckningar
- * Anger att koden ingår i standardfilen
wp-config.php
- Översättning till brasiliansk portugisiska (av Tárcio Zemel)