Ghidul avansat al dezvoltatorului pentru fișierul wp-config.php

Publicat: 2022-09-28

Cât de bine știi cu adevărat wp-config ? Există o cantitate surprinzătoare de putere în acele câteva linii de PHP! Acest articol este un tur al unor fragmente de wp-config despre care poate nu știai, dar ar trebui cu adevărat.

Știți tot ce trebuie să știți despre fișierul wp-config.php ? Ați citit întreaga pagină de documentație WordPress despre asta? Până la capăt?

Dacă sunteți deja familiarizat cu elementele de bază ale wp-config , atunci citirea documentației oficiale WordPress va fi probabil un festival de amânare adecvat.

Dacă vreți adevăratele răsfățări ale dezvoltatorului, grupate frumos pe subiecte și livrate cu ceea ce ar putea fi numit doar „entuziasm total inutil pentru câteva constante PHP”, atunci rămâneți pe aici: sunt pe cale să fac din nou wp-config.php cool.

Milhouse din Simpsons, cu „wp-config” pe față și legenda „Mama mea spune că sunt cool”.

Cuprins

  1. Cine ar trebui să citească asta?
  2. De ce ar trebui să citești asta?
  3. Cele elementare
  4. Vizualizarea constantelor wp-config
  5. Defalcarea procesului de încărcare wp-config.php
    1. wp-config poate fi mutat în sus
    2. Ecranul de configurare se încarcă dacă nu există un fișier wp-config.php
    3. wp-config.php se încarcă foarte devreme
    4. Nu vă încurcați cu wp-config.php!
  6. Verificarea/Linting fișierul dvs. wp-config.php
  7. Securizarea WordPress cu wp-config.php
    1. Protejarea wp-config.php de vizitatorii site-ului
    2. Chei rotative/Săruri
    3. Mutarea și ascunderea lucrurilor
    4. Dezactivarea editorilor de fișiere
    5. Dezactivarea actualizărilor automate
    6. Prevenirea solicitărilor HTTP externe
  8. Mutarea lucrurilor
    1. Mutarea tabelelor User și Usermeta
    2. Mutați directoarele de conținut, încărcări și pluginuri
  9. Setări legate de conținut
    1. Schimbați adresele URL ale site-ului și tabloului de bord
    2. Setări de postare
    3. Postați revizuiri
    4. Modificarea intervalului de salvare automată
  10. Încheierea

Cine ar trebui să citească asta?

Acest articol se adresează dezvoltatorilor și utilizatorilor avansați care știu deja să editeze fișierul wp-config.php și sunt la curent cu unele dintre setările de configurare pe care le puteți pune în el.

Nu vă voi spune cum să editați fișierul folosind FTP sau cPanel sau de ce nu ar trebui să utilizați MS Word pentru a-l edita.

Nu vă voi spune cum să vă configurați baza de date sau să treceți peste setările vechi pe care le utilizați în 2013, dar chiar nu ar trebui să mai fie nevoie. Și majoritatea gazdelor se vor ocupa oricum de elementele de bază pentru tine.

Dacă sunteți nou la wp-config.php , nu lipsesc ghidurile care vă vor oferi elementele de bază sau puteți oricând să căutați în documentația oficială.

De ce ar trebui să citești asta?

Da, da, te aud. Dacă detaliile de bază despre ceea ce puteți pune în acest articol sunt toate acoperite în altă parte și dacă gazda se ocupă oricum de majoritatea elementelor de bază, de ce ar trebui să citiți asta? Și, într-adevăr, de ce îmi petrec timpul scriind-o?

Ei bine, dacă sunteți mulțumit de editarea wp-config.php și cunoașteți elementele de bază despre ceea ce face, atunci probabil că sunteți cel puțin un dezvoltator WordPress de nivel intermediar.

Probabil că sunteți cel puțin parțial responsabil pentru găzduirea site-urilor mari, probabil pentru clienți. Deci trebuie să știți cum puteți utiliza acest fișier în caz de urgență. Și pentru a înțelege suficient acest fișier, astfel încât, dacă îl editați, nu veți face ceva greșit.

În plus, aproape sigur veți dori să blocați anumite caracteristici ale WordPress dincolo de ceea ce gazda vă va permite să configurați automat.

Este probabil că există lucruri pe care nici măcar nu știi că le poți face cu wp-config.php ! Unele „Aha!” momente de avut.

Acest articol este un punct de referință util pentru configurarea unora dintre elementele interne ale WordPress. Așa că, citiți mai departe, marcați și distribuiți prietenilor și colegilor dvs.

Cele elementare

Am spus că acesta nu este un articol pentru începători, dar ar trebui să stabilim faptele de bază pentru a ne asigura că suntem la același punct de plecare.

Fișierul wp-config.php se află în rădăcina instalării WordPress (poate locui în alte locuri, dar vom ajunge la asta), se încarcă ca parte a inițializării WordPress și vă permite să configurați nucleul WordPress.

Este esențial pentru funcționarea WordPress. Stochează un set de constante care vă permit să specificați:

  • Conexiunea la baza de date și prefixul de tabel pe care le folosește WordPress.
  • Informații de securitate precum săruri și chei de autentificare.
  • Setări pentru alte caracteristici ale nucleului WordPress, cum ar fi WP_CACHE și WP_DEBUG .
  • Setări pentru pluginuri care își pot adăuga propriile opțiuni la fișier.
  • Opțiunile dvs. de configurare proprii.

În mod esențial, wp-config.php este un fișier specific mediului. Conținutul său poate (și ar trebui!) să fie diferit pentru diferite site-uri. Chiar și copiile locale, provizorii și live ale aceluiași site vor avea valori diferite în fișier.

WordPress vine cu un fișier wp-config-sample.php care conține minimum de detalii de care WordPress trebuie să funcționeze. Ați putea copia acest lucru în propriul vostru wp-config.php ca parte a instalării, dar în prezent acest lucru este de obicei făcut pentru dvs.

În cele din urmă, rețineți că este posibil ca atunci când deschideți un fișier wp-config.php de pe un site existent, să vedeți niște constante PHP vechi pentru caracteristici vechi, cum ar fi permisiunile implicite pentru fișiere și acreditările FTP pentru rularea actualizărilor. Nu le vom acoperi aici, deoarece este puțin probabil să fie nevoie să le folosiți.

Vizualizarea constantelor wp-config

Există câteva modalități de a verifica rapid valorile constantelor WordPress fără a accesa SSH la un server la distanță și a deschide fișierul.

Caracteristica Site Health a WordPress core vă permite să vizualizați câteva valori de bază navigând la Instrumente -> Sănătate site -> Informații -> Constante WordPress. Constantele bazei de date pot fi văzute și în secțiunea „Bază de date” a aceleiași pagini.

Constantele bazei de date, afișate aici în secțiunea Bază de date a paginii WordPress Site Health.

Pluginul Query Monitor are un panou „Mediu” unde puteți vedea câteva constante wp-config utilizate în mod obișnuit.

Panoul „Mediu” al pluginului Query Monitor, care arată câteva constante wp-config utilizate în mod obișnuit.

WP-CLI, interfața de linie de comandă WordPress, are o comandă wp config care poate fi folosită pentru a obține și a seta constante în wp-config.php . În mod normal, acest lucru ar necesita să faceți mai întâi SSH, dar dacă configurați aliasuri în configurația WP-CLI, atunci puteți crea o comandă rapidă pentru a vizualiza și modifica constantele din fișierele wp-config la distanță.

Defalcarea procesului de încărcare wp-config.php

Este util să știți când se încarcă fișierul wp-config.php , deoarece aceasta determină unele dintre lucrurile pe care le puteți și nu le puteți face cu el. Este un exercițiu bun pentru a urmări procesul de încărcare:

  • WordPress începe să se încarce cu fișierul index.php . Acest lucru necesită fișierul wp-blog-header.php .

  • Aproape primul lucru pe care wp-blog-header.php îl face este să încarce wp-load.php .

  • Apoi, wp-load.php setează constanta ABSPATH (directorul de bază WordPress) și inițializează error_reporting() înainte de a încărca wp-config.php .

Acest proces de încărcare, și în special codul din wp-load.php , ne pot învăța câteva lucruri interesante. Iată acel cod:

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

Ce vedem aici?

wp-config.php poate fi mutat în sus

În primul rând, comentariul ne spune că putem pune wp-config.php în „Rădăcina WordPress”. Ceea ce nu reușește să menționeze este că „rădăcina” poate fi de fapt un director deasupra ABSPATH în care locuiește wp-load.php .

Putem vedea această verificare suplimentară în elseif unde caută dirname( ABSPATH ) . '/wp-config.php' dirname( ABSPATH ) . '/wp-config.php' . Condiția suplimentară din elseif este explicată în comentariu.

Ecranul de configurare se încarcă dacă nu există un fișier wp-config.php

În al doilea rând, putem vedea că, dacă un fișier de configurare nu există, acesta va încărca ecranul de configurare.

Este foarte posibil să nu fi văzut niciodată acest ecran. Vă permite să introduceți informațiile de configurare inițială, cum ar fi acreditările bazei de date, într-o interfață de utilizator bazată pe web:

Ecranul de configurare WordPress rar văzut. WordPress încarcă acest lucru dacă nu găsește un fișier de configurare, permițându-vă să setați opțiunile de configurare manual.

Aceasta este o caracteristică a WordPress despre care merită să știți. Dacă ați pus vreodată fișierele de bază WordPress pe un server web disponibil public, dar nu creați un fișier wp-config.php , atunci altcineva (sau, mai probabil, un bot) poate veni și configura WordPress în modul lor . și, eventual, să vă compromiteți găzduirea.

wp-config.php se încarcă foarte devreme

Al treilea lucru de remarcat este că wp-config.php este încărcat foarte devreme în secvența de pornire a WordPress. Aceasta înseamnă că:

  1. Sunt multe pe care nu le putem face în wp-config.php . De exemplu, nu putem adăuga cârlige (acțiuni sau filtre) aici, deoarece funcțiile și structurile de date pentru a face asta nu sunt încă încărcate. Și nu avem acces la niciuna dintre funcțiile, obiectele și API-urile interne ale WordPress.

  2. Avem mult control asupra a ceea ce urmează. Deoarece fișierul este încărcat atât de devreme, are o mare influență asupra WordPress. Acest lucru este și bine și rău. Putem face cu ușurință WordPress să moară complet. Dar putem accesa, de asemenea, orice este definit în wp-config.php din aproape oriunde altundeva în WordPress.

Nu vă încurcați cu wp-config.php!

Ultimul lucru pe care îl învățăm din acest proces este că cu această mare putere vine o mare responsabilitate.

În partea de jos a fișierului wp-config.php sunt următoarele rânduri:

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

Există câteva instrucțiuni aici, dar linia „opriți editarea” este importantă. După această linie este continuarea secvenței de inițializare a WordPress. Adăugarea unui cod nou în locul greșit va avea ca rezultat probabil că noul cod nu va avea niciun efect. Dar pentru a fi în siguranță, vă recomand să urmați aceste instrucțiuni. Sunt acolo pentru un motiv bun.

Verificarea/Linting fișierul dvs. wp-config.php

Dacă lucrați în producție, chiar nu doriți să puneți erori în fișierul wp-config.php . Erorile de aici vă pot distruge site-ul și este posibil să nu primiți un mesaj de eroare util afișat atunci când apare.

Puteți rula php pe linia de comandă cu opțiunea -l ("lint") pentru a verifica fișierul wp-config.php pentru erori fatale de sintaxă PHP.

$ php -l wp-config.php

Eroare de analiză: eroare de sintaxă, indicativ neașteptat „require_once” în wp-config.php pe linia 9

Erori la analizarea wp-config.php

Ai putea chiar să scrii un script shell pentru...

  1. Copiați wp-config.php într-un fișier temporar,
  2. Editați fișierul temporar,
  3. Lint fișierul temporar și
  4. Copiați-l înapoi numai dacă nu are erori de sintaxă.

Dacă sunteți mulțumit de linia de comandă, atunci este mai sigur să utilizați comenzile WP-CLI, cum ar fi wp config set <name> <value> pentru a seta valori în siguranță, decât să o faceți manual.

Puteți enumera valorile de configurare și cu WP-CLI (acesta este un exemplu cu unele intrări eliminate - ați înțeles ideea!):

lista de configurare $ wp
+---------------------+--------------------------- --------------------+----------+
| nume | valoare | tip |
+---------------------+--------------------------- --------------------+----------+
| director_rădăcină | /Utilizatori/smithers/site-uri/snpp | variabilă |
| webroot_dir | /Utilizatori/smithers/sites/snpp/public | variabilă |
| prefix_tabel | wp_ | variabilă |
| WP_HOME | https://snpp.test | constantă |
| WP_SITEURL | https://snpp.test/ | constantă |
| DB_NAME | snpp | constantă |
| DB_USER | rădăcină | constantă |
| DB_PASSWORD | Montgomery | constantă |
| DB_HOST | 127.0.0.1 | constantă |
| DB_CHARSET | utf8mb4 | constantă |
| DB_COLLATE | | constantă |
| DB_PREFIX | wp_ | constantă |
| WP_DEBUG | 1 | constantă |
| WP_DEBUG_LOG | 1 | constantă |
| WP_DEBUG_DISPLAY | | constantă |
| WP_ENVIRONMENT_TYPE | dezvoltare | constantă |
| DISABLE_WP_CRON | | constantă |
| DISALLOW_FILE_EDIT | 1 | constantă |
+---------------------+--------------------------- --------------------+----------+

Aceste două tehnici ar putea să vă scutească de bătăi de cap și să vă împiedice să vă speriați de a pune accidental un punct și virgulă în locul greșit într-un fișier atât de critic.

Securizarea WordPress cu wp-config.php

Securitatea este un subiect mereu fierbinte în WordPress. Unele setări pe care le putem modifica în fișierul wp-config pun mai multe instrumente în cutia noastră de instrumente de securitate.

Aceste părți ale fișierului wp-config nu sunt cu siguranță singurele lucruri pe care ar trebui să le utilizați pentru a obține o bună securitate WordPress. Asigurați-vă că înțelegeți temeinic securitatea site-ului web, pe lângă informațiile din secțiunea următoare.

Protejarea wp-config.php de vizitatorii site-ului

Fișierul dvs. wp-config se află în directorul rădăcină al site-ului dvs. în mod implicit și se întâmplă să conțină informații esențiale, cum ar fi detaliile de conectare la baza de date și sărurile parolei. Nu doriți ca aceste informații să fie disponibile public, așa că ar trebui să vă asigurați că fișierul dvs. wp-config este protejat de vizitatorii site-ului.

Compania ta de găzduire va face adesea acest lucru pentru tine. Puteți verifica încercând să accesați fișierul din browser adăugând /wp-config.php imediat după domeniul dvs. Această adresă URL poate fi diferită dacă ați mutat fișierul.

Dacă ați plasat fișierul wp-config în directorul de deasupra directorului rădăcină al site-ului dvs., atunci nu ar trebui să îl puteți vedea. În cele mai multe alte cazuri, veți primi un mesaj de eroare PHP oricum când încercați să vizitați fișierul, așa că de obicei nu este nimic de făcut aici. Dar dacă doriți să îl securizați în mod corespunzător, puteți face acest lucru modificând configurația serverului dvs. web (Apache sau nginx) pentru a bloca accesul la acesta.

În cele din urmă, dacă stocați fișierul site-ului dvs. în Git, este important să nu stocați fișierul wp-config în depozitul dvs. Git. Procedând astfel, s-ar putea scurge informații critice despre site-ul dvs., dar, în plus, probabil doriți oricum o versiune diferită a acestui fișier în fiecare mediu. Deci este mai bine să-l adăugați la .gitignore și să gestionați manual fișierele din fiecare mediu.

Chei rotative/Săruri

Ce sunt cheile/sărurile?

Secțiunea chei și săruri este una dintre părțile mai misterioase ale wp-config . Acest set de constante cu aspect ciudat ajută la criptarea lucrurilor precum cookie-urile și non-urile. Fără a intra în detalii, așa cum a făcut WP Engine, ele adaugă un strat suplimentar de aleatoriu care face lucrurile mai greu de decriptat dacă nu cunoașteți sărurile și cheile.

De ce să „rotiți” cheile/sărurile?

În primul rând, „rotirea” este doar un cuvânt elegant pentru „schimbare”. Nu știu de ce folosim „rotire”. Nu e ca și cum am reveni vreodată la același set de chei!

Probabil că ar trebui să vă schimbați cheile și sărurile dacă site-ul a fost piratat, deoarece nu puteți garanta că cheile și sărurile sunt încă secrete. Dar poate doriți să le rotiți în mod regulat oricum, ca în cazul parolelor, doar pentru a vă asigura că nimeni nu știe ce sunt.

Problema cu cheile/sărurile rotative

Schimbarea cheilor și a sărurilor nu este fără durere. Oricine are un set de cookie-uri îl va pierde. Deci, oricine s-a conectat va fi pornit și oricine are un coș WooCommerce îl va goli.

Cum să rotiți cheile/sărurile

Adică, ați putea edita fișierul wp-config și doar să tastați câteva caractere aleatorii noi peste cele vechi. Dar asta ar fi plictisitor și oamenii nu sunt foarte buni la întâmplare.

Așa că permiteți-mi să vă spun despre câteva modalități de a seta chei/săruri noi în wp-config .

  1. Adăugați manual chei dintr-un generator: puteți utiliza generatorul wordpress.org pentru a obține codul de care aveți nevoie. Doar copiați și lipiți-l în fișierul wp-config în locul vechilor valori.
  2. Utilizați un plugin: multe plugin-uri de securitate precum Sucuri Security, iThemes Security și Malcare au toate această funcție. Și Salt Shaker este un plugin dedicat care va automatiza acest proces într-un program pentru dvs.
  3. Utilizați WP-CLI. Am spus încă cât de minunat este WP-CLI? Noi am facut? O.K. Ei bine, o spunem din nou! Și puteți folosi comanda wp config shuffle-salts pentru a face acest lucru în câteva secunde.

Mutarea și ascunderea lucrurilor

Oamenii de securitate vă vor spune că „securitatea prin obscuritate” nu este deloc securitate, dar unora le place totuși să-și ascundă lucrurile WordPress pentru a pune bariere suplimentare pentru hackeri.

Fișierul wp-config vă oferă o serie de opțiuni pentru a face acest lucru și le vom acoperi în secțiunile ulterioare despre mutarea lucrurilor și dezactivarea editării fișierelor.

Dezactivarea editorilor de fișiere

WordPress are o caracteristică la îndemână care vă permite să editați fișiere în teme și pluginuri din interiorul tabloului de bord administrativ. Editarea wp-config.php vă permite să dezactivați aceste editori de fișiere! Unora le place să le dezactiveze pentru liniște sufletească.

Acum știu că există un argument de securitate conform căruia, dacă cineva are acces de administrator la site-ul tău, care este necesar pentru a utiliza aceste editori, atunci poate încărca un plugin și poate face oricum ce vrea. A avea acești editori activați nu le oferă hackerilor mai multă putere decât au deja.

Cu toate acestea, deși securitatea ar putea să nu fie îmbunătățită prin dezactivarea acestora, adevăratul motiv pentru a face acest lucru este acela de a opri oamenii care sunt de fapt autorizați ca administratori să le folosească. Dacă ești o agenție, probabil că nu vrei ca clienții tăi să descopere că își pot edita toate fișierele tematice, nu?

Multe gazde vor dezactiva această caracteristică în mod implicit. Dar dacă vrei să le faci să dispară, este la fel de simplu ca să adaugi:

 define( 'DISALLOW_FILE_EDIT', true );

Sau dacă doriți cu adevărat să vă blocați sistemul de fișiere, există DISALLOW_FILE_MODS , pe care îl vom trata în secțiunea următoare.

Dezactivarea actualizărilor automate

Indiferent dacă le iubești sau le urăști, actualizările automate ale WordPress au avut un impact net pozitiv asupra ecosistemului WordPress și sunt greu de ignorat. Dar nu toată lumea vrea ca software-ul lor să aibă grijă de el însuși!

Deci wp-config vă oferă control asupra procesului de actualizări automate cu un set simplu de constante auto-explicative pe care le puteți seta:

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Dacă doriți ceva mai extrem, puteți DISALLOW_FILE_MODS :

 define( 'DISALLOW_FILE_MODS', true );

Dar acest lucru oprește WordPress să scrie orice pe disc legat de nucleu, teme, pluginuri sau traduceri și dezactivează notificările prin e-mail despre actualizări minore. A fost descrisă de un colaborator principal drept „prost nebun de folosit dacă nu știi exact ce faci”.

Puțin mai puțin extrem este AUTOMATIC_UPDATER_DISABLED . Acest lucru vă permite să instalați pluginuri și teme, dar nu le veți actualiza sau software-ul de bază. De asemenea, dezactivează actualizările de traducere.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Există un ghid detaliat despre toate acestea pe wordpress.org, inclusiv alte opțiuni, cum ar fi utilizarea filtrelor pentru un control mai fin.

În cele din urmă, observ că, dacă site-ul tău este controlat de versiune, atunci este probabil ca WordPress să fi dezactivat actualizările pentru tine oricum. De exemplu, prezența unui director .git în rădăcina site-ului (sau a diferitelor alte fișiere în diferite locuri) va dezactiva actualizările automate fără a fi nevoie să adăugați nimic la wp-config .

Configurarea HTTPS

Configurarea HTTPS era adesea dificilă. Odată cu apariția certificatelor de securitate gratuite și de încredere din locuri precum LetsEncrypt și Cloudflare, multe gazde vă vor configura acest lucru cu câteva clicuri. Probabil că această setare ar trebui considerată moștenire, dar poate că mai aveți nevoie de ea pentru ceva.

Constanta FORCE_SSL_ADMIN îi spune WordPress să folosească întotdeauna SSL pentru paginile de conectare și tabloul de bord WordPress. Acest lucru asigură că acreditările și modulele cookie securizate nu pot fi trimise necriptate.

Dar, așa cum am spus, o companie de găzduire bună va simplifica oricum configurarea HTTPS pe site-ul dvs., așa că faceți-o.

Prevenirea solicitărilor HTTP externe

În cele din urmă, în securitate, puteți bloca solicitările HTTP externe. Aceasta înseamnă că WordPress nu poate contacta alte locuri de pe internet pentru a face lucruri precum efectuarea de apeluri API sau descărcarea de actualizări.

Permiterea lui WordPress să contacteze servicii externe prin HTTP este, în general, o idee bună, deoarece vă permite să obțineți actualizări, să instalați pluginuri și teme, iar multe plugin-uri se vor întrerupe dacă dezactivați solicitările HTTP.

Dar nucleul WordPress și multe plugin-uri și teme trimit „telemetrie” sau „date de utilizare” înapoi la serverele centrale. Acest lucru poate fi bun - îi ajută pe dezvoltatorii de pluginuri și teme să știe cine își folosește software-ul și cum. Dar dacă aveți un site care conține date deosebit de sensibile, poate doriți să dezactivați acest lucru. Și poți face asta cu:

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Dacă doriți să aveți o listă permisă de gazde care pot fi contactate, puteți face și asta:

 define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

Rețineți că lista de gazde accesibile este o listă separată prin virgulă și sunt permise subdomenii cu caractere joker. Și puteți monitoriza ce gazde sunt contactate folosind pluginul Log HTTP Requests.

Mutarea lucrurilor

Nu toate instalările WordPress sunt la fel. Unor gazde sau cadre le place să mute directoare din motive de securitate sau să păstreze codul și activele specifice site-ului separat de nucleul WordPress. Articolul meu despre utilizarea Git și Composer pentru a gestiona WordPress acoperă câteva beneficii ale acestei abordări.

Deci, ce opțiuni vă oferă WordPress pentru – în lipsa unui termen mai bun – „lucruri în mișcare”?

Schimbarea prefixului bazei de date

WordPress folosește prefixul numelui tabelului bazei de date wp_ în mod implicit. Acest prefix este adăugat la toate numele tabelelor bazei de date și este folosit și în alte locuri, de exemplu opțiunea <prefix>user_roles din tabelul de opțiuni și meta intrările utilizatorului <prefix>capabilities .

Hackerii sau atacatorii pot folosi prefixul implicit într-un atac, încercând să descopere sau să modifice tabelele bazei de date. Așa că unii oameni recomandă schimbarea lui din valoarea implicită.

Opțiunea wp_config $table_prefix vă permite să faceți acest lucru și probabil ar trebui să o setați la un șir scurt, dar aleator, sufixat cu o liniuță de subliniere:

 $table_prefix = 'b4F8az_';

Acest lucru va spune WordPress să folosească nume de tabel precum b4F8az_posts în loc de wp_posts .

Nu ar trebui să actualizați niciun cod pentru a face față acestei modificări (cu excepția cazului în care acel cod este scris foarte prost), dar dacă îl schimbați pe un site existent, va trebui să faceți unele actualizări în baza de date - și nu doar să redenumești mesele!

Unele plugin-uri de securitate vor face acest lucru pentru tine și există un plugin care poate face și asta. Vă recomandăm cu căldură să faceți o copie de rezervă a bazei de date înainte de a face acest lucru și să rețineți că selectarea unui prefix de tabel care nu este implicit este cel mai bine făcută atunci când instalați WordPress, nu atunci când îl schimbați în timp ce site-ul dvs. este în zbor.

O notă curioasă în acest sens este că $table_prefix este o variabilă, nu o constantă. Este singura variabilă definită în fișierul de configurare exemplu pe care ți-l oferă WordPress! Și dacă tot ești curios: da, comenzile wp config ale WP-CLI se ocupă de asta pentru tine fără ca tu să știi!

Mutarea tabelelor User și Usermeta

Nu am văzut niciodată acest lucru făcut și am învățat doar că se poate face atunci când scriu acest articol, dar puteți schimba complet numele tabelelor user și usermeta.

Bănuiesc că acest lucru ajută la prevenirea unui atac de injecție SQL care încearcă să „SELECTEAZĂ * FROM wp_usermeta;”, dar mă bucur să aud și alte motive pentru a face acest lucru.

În orice caz, constantele CUSTOM_USER_TABLE și CUSTOM_USER_META_TABLE sunt ceea ce aveți nevoie:

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

Există câteva avertismente care merită cunoscute înainte de a utiliza aceste constante. Verificați documentele oficiale înainte de a utiliza această funcție. Și la fel ca utilizarea unui prefix de tabel personalizat, acest lucru este cu siguranță cel mai bine făcut atunci când instalați un site nou, mai degrabă decât să îl modificați mai târziu.

Mutați directoarele de conținut, încărcări și pluginuri

De asemenea, este posibil să mutați întregul director wp-content , directorul de uploads și directoarele de themes și plugins . Lucruri de reținut:

  • În unele dintre aceste cazuri, trebuie să setați adresa URL, precum și directorul.
  • Trebuie să aveți grijă să utilizați căi complete sau căi relative, după caz.
  • Niciuna dintre aceste setări nu ar trebui să aibă o bară oblică.

Consultați documentația oficială pentru detalii – nu voi repeta toate acestea aici.

În cele din urmă, rețineți că un plugin sau o temă prost codificată poate da greșit dacă le schimbați. Acest lucru nu ar trebui să se întâmple niciodată, dar merită să știți.

Dacă sunteți un dezvoltator de pluginuri sau de teme, este important să rețineți că aceste căi se pot schimba. Deci, asigurați-vă că nu codificați căile către directoare sau URL-uri. Funcțiile utile pentru dvs. aici sunt:

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – rețineți că pentru o temă copil, aceasta returnează locația temei părinte
get_template_directory_uri

Există o listă mai exhaustivă de funcții ca acestea în manualul dezvoltatorului WordPress.

În cele din urmă, pe lângă mutarea fișierelor în interiorul instalării WordPress, este posibil să doriți să mutați locația wp-admin sau să schimbați locația site-ului dvs. Și wp-config.php poate ajuta și cu asta.

Setări legate de conținut

WordPress este, până la urmă, un sistem de gestionare a conținutului. Așa că v-ați aștepta la unele dintre constantele pe care le puteți utiliza în wp-config.php pentru a controla opțiunile de conținut. Să aruncăm o privire și să vedem ce putem face.

Schimbați adresele URL ale site-ului și tabloului de bord

Acestea m-au încurcat întotdeauna.

Pentru a seta adresa URL a site-ului dvs. trebuie să utilizați constanta WP_HOME , nu constanta WP_SITEURL .

Constanta WP_SITEURL nu modifică adresa URL a site-ului dvs.

Confuz?

Descrierea oficială a ceea ce face WP_SITEURL este „adresa unde se află fișierele de bază WordPress”. Acest lucru este, de asemenea, confuz, deoarece este o adresă URL, nu un director.

Nu mă învinovăți pentru asta, sunt doar ghidul tău turistic pentru ziua respectivă!

Setarea WP_HOME și WP_SITEURL înlocuiește intrările home și siteurl din tabelul bazei de date wp_options . Deci, cel puțin, are sens.

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

Puteți utiliza aceste constante după ce mutați un site la o nouă adresă URL, pentru a pune site-ul în funcțiune în timp ce reparați corect baza de date. Puteți chiar să alegeți să le lăsați pe loc după aceea.

Setarea WP_SITEURL poate fi folosită și atunci când ați mutat fișierele principale WordPress într-un director diferit.

Utilizarea acestora previne, de asemenea, rularea unei interogări de bază de date sau două pentru a obține valorile din tabelul de opțiuni, deci poate avea un câștig marginal de performanță. Deși, dacă faceți memorarea în cache a obiectelor, acest câștig este probabil neglijabil.

Există mai multe detalii în documentele oficiale și chiar un articol de asistență completă despre schimbarea adresei URL a site-ului. În plus, acel articol include constanta obscură RELOCATE pentru wp-config.php despre care nu am auzit niciodată înainte de a cerceta acest articol.

În cele din urmă, atunci când mutați site-uri, rețineți că acesta nu este singurul lucru pe care trebuie să îl schimbați. Se recomandă o căutare și înlocuire completă în baza de date pentru șirurile URL.

Setări de postare

Există câteva setări diferite pe care le puteți modifica când vine vorba de postări. Cele mai multe dintre acestea sunt preocupate fie de revizuiri postate, fie de caracteristica de salvare automată.

Postați revizuiri

Comportamentul implicit al WordPress este de a salva toate revizuirile făcute postărilor și paginilor. Avantajul acestui lucru este că este ușor să reveniți la versiunile anterioare. Dezavantajele sunt că toate acele revizuiri ocupă spațiu în baza de date și pot afecta performanța site-ului prin încetinirea interogărilor bazei de date.

Este posibil să dezactivați complet revizuirile postate prin modificarea valorii WP_POST_REVISIONS din fișierul wp-config.php . Este implicit la adevărat. Pentru a dezactiva revizuirile, îl puteți seta la false:

 define( 'WP_POST_REVISIONS', false );:

Unele gazde, inclusiv WP Engine, dezactivează în mod implicit revizuirile postate. Vă recomand să verificați cu furnizorul dvs. de găzduire înainte de a face orice modificare. Acest lucru variază de la gazdă la gazdă, dar dacă sunteți cu WP Engine, nu puteți activa revizuirile prin wp-config , deoarece va fi suprascris la nivel de server.

Dacă gazda controlează acest lucru și încerci să-l schimbi, nu vei sparge neapărat ceva, dar s-ar putea să-ți pierzi timpul.

Dacă sunteți îngrijorat de revizuirile postate care încetinesc interogările bazei de date, o opțiune mai bună ar putea fi limitarea numărului de revizuiri pe care WordPress le stochează. Aceasta este controlată de constanta WP_POST_REVISIONS , pe care o puteți seta la numărul maxim de revizuiri pe care doriți să le păstrați:

 define( 'WP_POST_REVISIONS', 5 );

Modificarea intervalului de salvare automată

De asemenea, puteți reduce frecvența cu care se declanșează salvarea automată. Acesta este implicit la fiecare 60 de secunde, dar îl puteți schimba în orice doriți. Dacă sunteți paranoic, poate doriți să setați acest lucru la 20 sau 30 de secunde.

Este important să țineți cont de cât durează o salvare automată. Nu doriți ca acestea să se suprapună făcându-le să se întâmple prea des, așa că nu setați această valoare la, de exemplu, o secundă. Nu este foarte probabil ca salvarea automată să dureze mai mult decât valoarea implicită de 60 de secunde, dar puteți crește intervalul dacă doriți să salvați solicitările:

 define( 'AUTOSAVE_INTERVAL', 120 ); // Seconds

Încheierea

Există o mulțime de potențial în wp-config care așteaptă să fie deblocat. Sper că acest tur a ajutat la evidențierea doar câteva dintre ceea ce este posibil. Într-un articol viitor, voi analiza mai multe dintre capabilitățile avansate inerente wp-config , inclusiv instalările pe mai multe site-uri și depanarea. De asemenea, voi analiza performanța, inclusiv modul de ajustare a limitelor de memorie, problemele CRON și tipurile de mediu.

Fără îndoială, în documentația oficială pândesc și alte comori, care așteaptă să fie descoperite. Ce sfaturi ați găsit pentru utilizarea wp-config ? Anunță-mă în comentarii.