Error sa Koneksyon ng Database sa WordPress: Paano Ayusin

Binubuksan mo ang site mo at bawat page — pati front end at wp-admin — ay napapalitan ng iisang kulay-abong pangungusap: May error sa pagkonekta sa database. Walang lumalabas, dahil talagang hindi kaya. Hindi pa nga nakarating ang WordPress sa pagbuo ng isang page.

Ito ang mental model na magpapabilis sa pag-aayos. Iniimbak ng WordPress ang lahat ng content mo — mga post, page, setting, user — sa isang MySQL database, hindi sa mga file. Sa bawat request, binabasa nito ang apat na detalye ng login mula sa wp-config.php, kumokonekta sa database na iyon, at kinukuha ang kailangan. Ang ibig sabihin ng error na ito, sinubukan ang koneksyon na iyon at tinanggihan. Ang solusyon ay alamin kung bakit tinanggihan, at tatlo lang ang posibilidad.

Ang tatlong sanhi, ayon sa pagkakasunod ng posibilidad

1. Maling kredensyal sa wp-config.php — kadalasang bunga ng paglipat ng host.
2. Patay o overloaded ang database server — kadalasang bunga ng walang nagbago sa panig mo.
3. Sira ang database — mas bihira, at iba ang paraan ng pagpapakita nito.

Sundan ang mga ito sa ganoong pagkakasunod.

Hakbang 1: suriin ang apat na kredensyal

Buksan ang wp-config.php sa root ng site mo sa pamamagitan ng SFTP o ng file manager ng host mo. Apat na linya ang nagtatakda ng koneksyon:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Bawat isa sa mga ito ay dapat tugmang-tugma sa itinalaga ng host mo. Buksan ang seksiyong database sa hosting control panel mo (sa cPanel, ito ang “MySQL Databases”) at ihambing nang karakter por karakter:

• DB_NAME — madalas na inuunahan ng mga host ang pangalan ng iyong account, tulad ng cpaneluser_wpdb. Bahagi ng pangalan ang prefix na iyon.
• DB_USER — pareho ang tuntunin sa prefix, at ang user ay dapat nakatalaga sa database na iyon, hindi lang basta umiiral.
• DB_PASSWORD — ang pinakakaraniwang salarin. Kung hindi ka sigurado, i-reset ito sa control panel at idikit ang bagong halaga. Mag-ingat sa naiwang espasyo sa dulo o sa smart quote.
• DB_HOST — huwag ipagpalagay na localhost. Maraming host ang gumagamit ng dedikadong database server na may address tulad ng mysql.yourhost.com, minsan may :port. Ipinapakita ng control panel ang tamang halaga.

Dahil nasa file na ito mismo naninirahan ang apat na halagang ito, ang pinakaligtas na paraan para makabuo ulit ng malinis at tamang-tamang naka-quote na wp-config.php ay ang wp-config.php generator — punan ang apat na field ng database at idikit ang resulta sa ibabaw ng lumang block.

Ang hakbang na ito lang ay nakakaayos na ng error pagkatapos ng halos bawat paglipat, dahil ang mga kredensyal na tama sa lumang host ay mali na sa bago.

Hakbang 2: tiyaking talagang gumagana ang database server

Kung tama ang mga kredensyal pero nananatili ang error — lalo na kung kusa itong lumitaw nang wala kang binago — ang database server mismo ang pinaghihinalaan.

Sa shared hosting, karaniwan ito at kadalasang pansamantala: nao-overwhelm ang MySQL service tuwing may biglaang dami ng trapiko o naaabot ang connection limit kada account nito at nagsisimula nang tumanggi sa mga bagong koneksyon. Karaniwang gumagaling ito sa loob ng ilang minuto. Mag-reload pagkatapos ng maikling paghihintay bago gumawa ng anumang drastiko.

Para subukan kung valid ba ang mga kredensyal kahit hiwalay sa WordPress, maglagay ng maliit na script sa tabi ng wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Gamitin ang totoong DB_HOST, DB_USER, at DB_PASSWORD mo. Kung nag-print ito ng Connected, gumagana ang detalye ng login mo at nasa ibang lugar ang problema (sirang database, Hakbang 3). Kung nag-print ito ng connection error, sinasabi ng mensahe kung alin: ang “Access denied” ay maling user o password; ang “Can’t connect to MySQL server” ay maling host o talagang patay na serbisyo — panahon nang makipag-ugnayan sa host mo. Burahin ang script sa oras na matapos ka.

Hakbang 3: ayusin ang sirang database

Isang palatandaan ang naghihiwalay sa pagkasira mula sa problema sa koneksyon: bumubukas ang front end pero nagpapakita ng error ang wp-admin, o kabaligtaran. Kung talagang tinanggihan ang koneksyon, patay dapat pareho. Ang ganoong pagkakahati ay tumuturo sa mga sirang table.

May built-in na kasangkapan sa pag-aayos ang WordPress. Magdagdag ng isang linya sa wp-config.php, sa itaas ng komentong “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Tapos bisitahin ang URL na ito nang direkta sa browser mo:

https://yoursite.com/wp-admin/maint/repair.php

Bumubukas ito nang walang login — iyon ang punto, dahil baka naka-lock out ka — at nag-aalok ng “Repair Database” at “Repair and Optimize Database.” Patakbuhin ito.

Tapos agad na burahin ang linyang iyon sa wp-config.php. Habang naroon ito, kahit sinong nasa internet ay puwedeng buksan ang URL na iyon at magpatakbo ng pag-aayos sa database mo. Hindi ito opsyonal na paglilinis; pagsasara ito ng butas na kakabukas mo lang.

Hakbang 4: kapag hindi man lang makakonekta ang pag-aayos

Kung ang mismong repair page ay nagpapakita ng connection error, wala nang aayusin — hindi talaga maabot ang database, kaya balik ka sa Hakbang 1 o Hakbang 2. Sa puntong iyon, ang maaasahang hakbang ay i-restore ang database mula sa pinakabagong backup ng host mo. Karamihan sa mga control panel ay nag-iimbak ng automatic na araw-araw na snapshot ng database; ang pag-restore mula kagabi ay halos palaging mas mabilis at mas ligtas kaysa habulin ang isang pagkasira na hindi mo man lang makonekta.

Payo na puwede mong balewalain

“Mag-reinstall ka na lang ng WordPress.” Ang error na ito ay tungkol sa koneksyon ng database, hindi sa mga core file. Ang pag-reinstall ay pinapalitan mismo ang mga file na maayos naman at hindi hinihipo ang anumang sira.

“Taasan mo ang PHP memory limit mo.” Ang pagkaubos ng memory ay ibang error na may ibang mensahe. Ang pagtaas ng limitasyon ay walang ginagawa sa isang tinanggihang koneksyon ng database at itinatago lang na hindi mo pa nasusuri ang mga kredensyal.

“I-clear mo ang cache mo.” Nangyayari ang pagkabigo sa PHP bago pa makapaghain ng page ang anumang cache. Ang pag-clear ng cache ay walang binabago habang tinatanggihan ang koneksyon; katumbas lang itong gawin pagkatapos bumalik ang site.

“I-edit mo nang direkta ang database para ayusin.” Ang pagmamadaling gumamit ng phpMyAdmin para i-edit nang manu-mano ang mga table bago mo makumpirma na gumagana nga ang koneksyon ay kung paano nagiging permanenteng pagkawala ng data ang isang pansamantalang pagkakaputol. Kumpirmahin muna ang koneksyon; hipuin ang data sa huli, at mula lang sa backup.

Hindi pa rin gumagana?

Kung na-verify ang mga kredensyal gamit ang test script, gumagana ang server, at nakakonekta ang pag-aayos at walang naiulat na error, pero ipinapakita pa rin ng site ang mensahe, ang natitirang pinaghihinalaan ay isang plugin na nakikipag-usap sa database sa sarili nitong koneksyon — isang caching o database plugin na nag-imbak ng lumang host. Palitan ang pangalan ng wp-content/plugins ng plugins-off sa pamamagitan ng SFTP para maalis ito sa listahan. Kung nawala ang error, ibalik ang mga plugin nang isa-isa hanggang bumalik ito.