Wielu użytkowników WordPressa zna plik wp-config.php jako klucz do bazy danych WordPressa. To właśnie tam ustawiasz nazwę bazy danych, nazwę użytkownika, hasło i lokalizację (wśród innych rzeczy, takich jak klucze bezpieczeństwa, prefiks bazy danych i zlokalizowany język).

Tutaj jest zrzut ekranu wp-config.php (aka plik konfiguracyjny WordPress) dla tych, którzy mogą jeszcze nie być zaznajomieni:

Ale co wielu użytkowników nie wie, że plik wp-config.php może być używany do określenia szerokiej gamy ustawień konfiguracyjnych, umożliwiając poprawę funkcjonalności, wydajności i bezpieczeństwa witryny zasilanej WordPress. W tym artykule dzielę się tyloma sztuczkami konfiguracyjnymi, ile udało mi się zebrać przez lata. Ten przewodnik obejmuje wszystko w WordPress Codex, jak również kilka dodatkowych sztuczek, które prawdopodobnie nie widział wcześniej. Jeśli znasz jakieś inne sztuczki konfiguracyjne WordPressa, podziel się nimi w komentarzach, a ja dodam je do tego posta.

Poświadczenia bazy danych *

Ten zestaw czterech definicji konfiguracyjnych jest wymagany, aby WordPress mógł połączyć się z bazą danych:

define('DB_NAME', 'database-name');define('DB_USER', 'database-username');define('DB_PASSWORD', 'database-password');define('DB_HOST', 'localhost');

Nazwa bazy danych, nazwa użytkownika i hasło powinny być łatwo dostępne podczas tworzenia bazy danych, ale wartość DB_HOST może być trudniejsza do zdobycia. Najczęściej wartość ta to po prostu „localhost„, ale jeśli to nie zadziała, oto kilka innych wartości do wypróbowania:

• 1and1 Hosting – db12345678
• DreamHost – mysql.example.com
• GoDaddy – h41mysql52.secureserver.net
• ICDSoft – localhost:/tmp/mysql5.sock
• MediaTemple (GS) (GS) – internal-db.s44441.gridserver.com
• Pair Networks – dbnnnx.pair.com
• Yahoo – mysql

Możesz nawet określić alternatywny port dla swojego serwera bazy danych. Oto dwa przykłady:

define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');

Inną fajną sztuczką jest automatyczne wykrywanie wartości serwera bazy danych:

define('DB_HOST', $_ENV{DATABASE_SERVER});

Jeśli wszystko to zawiedzie, lub jeśli nadal masz problemy, skonsultuj się z dostawcą usług hostingowych w celu uzyskania pomocy.

Zestaw znaków bazy danych i kolacja *

Od wersji 2.2 WordPressa możesz określić zestaw znaków dla swoich tabel bazy danych MySQL. Ogólnie rzecz biorąc, nie ma powodu, aby zmieniać domyślną wartość zestawu znaków UTF-8, która jest zazwyczaj idealna, ponieważ obsługuje wszystkie języki. Oto domyślne (i zalecane) ustawienie:

define('DB_CHARSET', 'utf8');

WordPress w wersji 2.2 umożliwia również określenie kolacji, która jest porządkiem sortowania zestawu znaków Twojej bazy danych. Ustawienie kolacji jest zazwyczaj obsługiwane automatycznie przez MySQL zgodnie z zestawem znaków, który jest włączony przez pozostawienie wartości kolacji pustej, jak to ma miejsce w domyślnym ustawieniu dla tej definicji. Oto domyślne (i zalecane) ustawienie:

define('DB_COLLATE', '');

Klucze bezpieczeństwa *

Od WordPress 2.7 dostępne są cztery klucze bezpieczeństwa, które zostały zaprojektowane w celu zapewnienia lepszego szyfrowania plików cookie. Klucze te działają cicho w tle i powinny być tak losowe i skomplikowane, jak to tylko możliwe (nie, nigdy nie będziesz musiał ich pamiętać). Najprostszym sposobem na wygenerowanie tych kluczy jest zrobienie tego automatycznie w serwisie WordPress.org secret-key. Po prostu odwiedź ten link i skopiuj/wklej wyniki do swojego pliku wp-config.php. Zauważ, że te klucze mogą być zmienione w dowolnym momencie, a zrobienie tego unieważni wszystkie istniejące pliki cookie użytkowników, tak że będą musieli ponownie zalogować się do witryny.

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');

Prawdopodobnie najlepiej uciec od tych wartości, jeśli używasz w witrynie publicznej.

Ścieżka szablonu i ścieżka arkusza stylów

Tak jak w przypadku predefiniowanych stałych dla adresu bloga i adresu witryny (zobacz poprzednią sekcję), możesz również zwiększyć wydajność poprzez wyeliminowanie zapytań do bazy danych dla ścieżki szablonu i ścieżki arkusza stylów dla twojej witryny. Oto wartości domyślne dla tych dwóch definicji:

define('TEMPLATEPATH', get_template_directory());define('STYLESHEETPATH', get_stylesheet_directory());

Jak jest, te dwie definicje nadal odpytywać bazę danych, ale możemy wyeliminować te zbędne zapytania poprzez hardcoding wartości w miejsce:

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

Te dwie opcje mają zastosowanie do starszych wersji WordPressa, które nadal używają domyślnego mechanizmu buforowania opartego na obiektach. Pierwsza definicja umożliwia włączenie lub wyłączenie pamięci podręcznej, podczas gdy druga definicja umożliwia określenie czasu wygaśnięcia pamięci podręcznej.

Włącz pamięć podręczną

define('WP_CACHE', true); // enable the cachedefine('ENABLE_CACHE', true); // enable the cachedefine('CACHE_EXPIRATION_TIME', 3600); // in seconds

Wyłącz pamięć podręczną

define('WP_CACHE', false); // disable the cachedefine('DISABLE_CACHE', true); // disable the cache

Specify Cookie Domain

Istnieje kilka powodów, dla których chcesz określić domenę plików cookie dla swojej witryny. Powszechnym przykładem jest zapobieganie wysyłaniu ciasteczek z żądaniami zawartości statycznej na subdomenach. W tym przypadku użyłbyś tej definicji, aby powiedzieć WordPressowi, aby wysyłał pliki cookie tylko do domeny niestatycznej. Może to być znaczący wzrost wydajności. Oto kilka przykładów ustawienia różnych ścieżek plików cookie i informacji o domenie plików cookie:

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

Jeśli domyślne uprawnienia do plików twojego hosta są zbyt restrykcyjne, dodanie tych definicji do pliku konfiguracyjnego WordPressa może pomóc w rozwiązaniu problemu. Zauważ, że nie potrzebujesz cudzysłowów wokół wartości uprawnień. Na przykład:

define('FS_CHMOD_FILE', 0755);define('FS_CHMOD_DIR', 0755);

Wyświetl wszystkie zdefiniowane stałe

Potrzebujesz wyświetlić wszystkie predefiniowane stałe? Dobra wiadomość, ta funkcja PHP zwróci tablicę wszystkich aktualnie zdefiniowanych stałych:

print_r(@get_defined_constants());

Własne tabele użytkowników i usermeta

A co z własnymi tabelami użytkowników i usermeta? Tak, to też możesz zrobić, z następującymi definicjami:

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

Stałe FTP/SSH

Ten zestaw definicji konfiguracyjnych jest zaprojektowany, aby pomóc użytkownikom zlokalizować i wykorzystać połączenia FTP/SSH. Oto przykładowy zestaw predefiniowanych stałych dla aktualizacji FTP/SSH:

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

Moving Your wp-content directory

As of WordPress version 2.6, you may change the default location of the wp-content directory. Istnieje kilka dobrych powodów, aby to zrobić, w tym zwiększenie bezpieczeństwa witryny i ułatwienie aktualizacji FTP. Kilka przykładów:

// 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');

Możesz także dodatkowo określić niestandardową ścieżkę dla katalogu plugins. Może to pomóc w problemach z kompatybilnością z niektórymi wtyczkami:

// 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');

Dealing with Post Revisions

Późniejsze wersje WordPressa zapewniają system post-revisioning, który umożliwia użytkownikom zapisywanie różnych wersji ich postów na blogu, a nawet powrót do wcześniej zapisanych wersji w razie potrzeby. Niezależnie od tego, jak bardzo gardzisz lub nie gardzisz tą niesamowicie niesamowitą funkcją, oto kilka definicji konfiguracyjnych, które mogą okazać się dla Ciebie przydatne 😉

Limit the number of saved revisions

define('WP_POST_REVISIONS', 3); // any integer, but don't get too crazy

Disable the post-revisioning feature

define('WP_POST_REVISIONS', false);

Specify the Autosave Interval

W podobnym duchu jak funkcja post-revisioning jest WordPress’s actually useful Autosave functionality. Domyślnie, WordPress zapisuje twoją pracę co 60 sekund, ale możesz całkowicie zmodyfikować to ustawienie do czegokolwiek chcesz. Nie szalej jednak za bardzo, chyba że chcesz zestresować swój serwer 😉

define('AUTOSAVE_INTERVAL', 160); // in seconds

Usuwanie błędów WordPressa

Od wersji 2.3.1 WordPressa użytkownicy mogą wyświetlać pewne błędy i ostrzeżenia, aby pomóc w usuwaniu błędów w ich witrynie. Od wersji 2.5 WordPressa włączenie raportowania błędów podnosi poziom raportowania do E_ALL i aktywuje ostrzeżenia dla przestarzałych funkcji. Domyślnie (tzn. jeśli nie określono definicji w pliku wp-config.php), raportowanie błędów jest wyłączone.

define('WP_DEBUG', true); // enable debugging modedefine('WP_DEBUG', false); // disable debugging mode (default)

Konfiguracja dziennika błędów

Oto prosty sposób na włączenie podstawowego rejestrowania błędów w witrynie zasilanej WordPressem. Utwórz plik o nazwie „php_error.log„, uczyń go zapisywalnym dla serwera i umieść w wybranym przez siebie katalogu. Następnie edytuj ścieżkę w trzeciej linii następującego kodu i umieść w swoim pliku wp-config.php:

@ini_set('log_errors','On');@ini_set('display_errors','Off');@ini_set('error_log','/home/path/domain/logs/php_error.log');

Zwiększ pamięć PHP

Jeśli otrzymujesz komunikaty o błędach mówiące, że „Dozwolony rozmiar pamięci xxx bajtów wyczerpany”, to ustawienie może pomóc rozwiązać problem. Od wersji 2.5 WordPressa, definicja WP_MEMORY_LIMIT umożliwia określenie maksymalnej ilości pamięci, która może być używana przez PHP. Domyślnie WordPress będzie automatycznie próbował zwiększyć pamięć PHP do 32MB, więc to ustawienie jest potrzebne tylko dla wartości większych niż 32MB. Zauważ, że niektóre hostingi wyłączają możliwość zwiększania pamięci PHP, więc może być konieczne błaganie, aby to zrobili. Oto kilka przykładów:

define('WP_MEMORY_LIMIT', '64M');define('WP_MEMORY_LIMIT', '96M');define('WP_MEMORY_LIMIT', '128M');

Zapisywanie i wyświetlanie zapytań do bazy danych do analizy

Ta technika jest idealna do zapisywania zapytań do bazy danych i wyświetlania informacji do późniejszej analizy. Proces zapisuje każde zapytanie, jego powiązaną funkcję oraz całkowity czas wykonania. Informacje te są zapisywane jako tablica i mogą być wyświetlane na dowolnej stronie szablonu tematycznego. Aby to zrobić, najpierw dodaj następującą dyrektywę do swojego pliku wp-config.php:

define('SAVEQUERIES', true);

Następnie w stopce aktywnego motywu umieść następujący kod:

// display the query array for admin onlyif (current_user_can('level_10')) {global $wpdb;echo "<pre>";print_r($wpdb->queries);echo "</pre>";}

Tutaj znajduje się jednowierszowa wersja tej funkcji:

<?php if (current_user_can('level_10')) { global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; } ?>

Control Proxy Access

Od czasu WordPress 2.8, plik konfiguracyjny może być używany do definiowania stałych związanych z blokowaniem, zezwalaniem i filtrowaniem dostępu do określonych hostów zza serwera proxy. Na przykład, jeśli hostujesz swoją witrynę WordPress w sieci intranetowej, możesz uniemożliwić dostęp do wszystkich zewnętrznych hostów i zezwolić na żądania tylko od localhost i swojego bloga, używając pierwszej definicji poniżej. Możesz również zezwolić na dostęp do określonych hostów za pomocą oddzielonej przecinkami listy dozwolonych nazw hostów, jak pokazano w trzeciej definicji poniżej.

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

Whew! Jestem wykończony. Czas na małą przerwę 🙂

Przypisy

• * Oznacza, że kod jest zawarty w domyślnym pliku wp-config.php
• Tłumaczenie na brazylijski portugalski (autorstwa Tárcio Zemela)

.