Default .htaccess File ng WordPress: Code at Paano Ibalik

Ang default na .htaccess file ng WordPress ay ang maikling RewriteEngine block na isinusulat ng software sa .htaccess sa root ng site mo, para gumana ang mga permalink tulad ng /2026/10/pangalan-ng-post/ sa halip na mag-404. Ganito ito:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Galing ang mga rule na ito sa code na ginagamit ng WordPress para buuin ang block, at tugma ang mga ito sa sariling .htaccess guide ng WordPress. Nagsusulat din ang WordPress ng tatlong comment line kasunod ng # BEGIN WordPress, na nagbababala na mao-overwrite ang mga edit sa pagitan ng mga marker. Hindi nito binabago ang gawa ng mga rule.

Sa subfolder install, inilalagay ng WordPress ang path ng subfolder sa RewriteBase at sa huling rule, halimbawa RewriteBase /blog/ at RewriteRule . /blog/index.php [L]. Gumagamit ang mga multisite network ng ibang block, at hindi awtomatikong isinusulat ng WordPress ang file na ito para sa kanila.

Mga pangunahing punto

• Ginagawa ng WordPress ang block na ito sa Apache at LiteSpeed kapag may write access ito at naka-on ang pretty permalinks. Sapat na ang pagbukas ng Settings > Permalinks.
• Kung nawawala o sira ang file, 404 ang mga permalink habang naglo-load pa rin ang homepage, dahil hindi kailangan ng homepage ang rewrite rules.
• Ilagay ang anumang idinagdag mo o ng plugin sa itaas ng # BEGIN WordPress, hindi kailanman sa loob ng mga marker. Pinapalitan ng WordPress ang lahat sa pagitan ng mga ito kapag ina-update ang file.

Ano ang gawa ng bawat linya

Ina-activate ng RewriteEngine On ang mod_rewrite module ng Apache para sa directory na ito; kung wala ito, walang nagagawa ang mga rule sa ibaba.

Hindi binabago ng RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] ang URL (iyon ang ibig sabihin ng -) at kinokopya nito ang Authorization header ng request sa isang server variable. Binabasa ng WordPress ang variable na iyon para makuha ang username at password na ipinadala sa header, tulad ng Application Password.

Itinatakda ng RewriteBase / ang path prefix na ginagamit ng Apache para sa mga rewritten URL. Itinatakda ito ng WordPress ayon sa kinalalagyan ng site, kaya RewriteBase /blog/ ang natatanggap ng subfolder install.

Ang RewriteRule ^index\.php$ - [L] ay isang guard: kung index.php na ang request, hihinto ang rewrite at dadaan ang request nang walang pagbabago.

Ang dalawang linyang RewriteCond ang tunay na lohika. Tinatanong ng %{REQUEST_FILENAME} !-f at !-d kung “ang request ba na ito ay HINDI tumutugma sa tunay na file, at HINDI tumutugma sa tunay na directory?”. Dapat totoo ang dalawa para gumana ang huling rule, kaya direktang isinisilbi ang tunay na larawan, CSS file, o na-upload na PDF at hindi ito dumadaan sa routing ng WordPress.

Ang RewriteRule . /index.php [L] ang nagpapagana sa mga permalink. Ipinapadala sa index.php ang anumang nakapasa sa dalawang kondisyong iyon, at ang WordPress ang nagpapasya kung aling post, pahina, o archive ang ibig sabihin ng URL.

Kailan ginagawa ulit ng WordPress ang file na ito, at kailan hindi

Ina-flush ng WordPress ang rewrite rules nito tuwing naglo-load ang screen na Settings > Permalinks, kaya sapat nang buksan ito at hindi mo kailangang i-click ang Save Changes. Kung nawawala ang .htaccess, gagawin ito ng WordPress basta writable ang folder at naka-on ang pretty permalinks. Kung umiiral at writable ang file, papalitan ng WordPress ang block sa pagitan ng mga marker.

Hindi nito naaayos ang problema sa mga kasong ito:

• Hindi writable ang file o ang folder nito para sa user na pinagpapatakbo ng PHP. Magpapakita ang screen ng error na nagsasabing hindi writable ang .htaccess file, kasama ang mga rule na ipe-paste. Sa ilang host, tumatakbo ang PHP bilang ibang system user kaysa sa may-ari ng mga FTP upload mo, kaya ang mga permission na mukhang tama sa FTP client ay puwede pa ring humarang sa WordPress.
• Nasa nginx ka. Sinasabi ng nginx guide ng WordPress na walang configuration file sa antas ng directory ang nginx na tulad ng .htaccess, at hindi kayang baguhin ng WordPress ang server configuration. Ang katumbas na routing ay isang try_files directive sa server configuration, na kailangang i-edit ng administrator.
• Nakatakda sa None ang AllowOverride para sa directory ng site mo sa pangunahing Apache config. Sinasabi ng dokumentasyon ng Apache (orihinal na sipi): “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Ibig sabihin, ganap na binabalewala ang mga .htaccess file maliban kung hayagan mong i-enable ang mga ito para sa isang directory. Puwedeng magsulat ang WordPress ng perpektong file at wala pa rin itong epekto. Kailangan ng rewrite rules ang AllowOverride FileInfo (o All), na maaaring kailangang baguhin ng host mo.
• Nakatakda sa Plain ang permalinks mo. Hindi kailangan ng rewrite rules ang mga Plain URL, kaya hindi ginagawa ng WordPress ang file para sa mga ito.

Paano ito ibalik nang manual

Kung 404 ang mga post at pahina habang gumagana pa rin ang homepage, ang nawawala o sirang .htaccess ang unang dapat tingnan. Ayusin ito sa dalawang hakbang.

1. Subukan muna ang one-click fix. Buksan ang Settings > Permalinks sa wp-admin, tapos i-click ang Save Changes nang walang binabago. Kung kayang isulat ng WordPress ang file, gagawin itong muli nito. Kung hindi, ipapakita ng screen ang error at ang mga rule na kailangan mo.

2. Kung hindi ito nag-ayos, gawin ang file nang manual. Kumonekta via FTP/SFTP o sa file manager ng host mo at pumunta sa root folder ng site, na karaniwang ang may wp-admin. Tingnan kung umiiral ang .htaccess. Nagsisimula sa tuldok ang pangalan nito, kaya itinatago ito ng ilang file manager bilang default; i-on ang “show hidden files.”

• Kung nawawala, gumawa ng bagong file na eksaktong .htaccess ang pangalan (walang .txt, walang anuman bago ang tuldok).
• I-paste ang mga rule na ipinakita ng WordPress, o ang default block mula sa itaas ng gabay na ito. Sa subfolder install, baguhin ang RewriteBase at ang huling rule para tumugma.
• I-save, tapos i-reload ang permalink ng isang post para kumpirmahing gumagana ito.

Kung 404 pa rin, baka binabalewala ang .htaccess. Tanungin ang host mo tungkol sa AllowOverride, dahil binabalewala ng Apache ang tamang file kapag naka-off ito.

Sariling mga rule mo laban sa block ng WordPress

Puwedeng magdagdag ang plugin o manual na pag-edit ng sariling mga rule, tulad ng redirects, hotlink protection, o caching headers. Ilagay ang mga ito sa labas ng block ng WordPress at sa itaas nito, para tumakbo ang mga ito bago ang huling rule nito na sumasalo sa lahat ng natitirang request:

# Mga rule na idinagdag mo o ng plugin: SA ITAAS ng mga marker ng WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # halimbawa: hotlink protection, cache rules, atbp.
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Mawawala ang anumang nailagay sa pagitan ng # BEGIN WordPress at # END WordPress sa susunod na pag-update ng WordPress sa file, at sapat na ang pag-load ng Permalinks screen para mangyari iyon. Nananatili ang mga linya bago at pagkatapos ng mga marker. Para sa mga redirect, tingnan ang tamang paggawa ng WordPress .htaccess redirect rules para malaman kung saan dapat ilagay ang mga ito at paano iwasan ang mga loop.

Ang 500 Internal Server Error kaagad pagkatapos i-edit ang file ay tumuturo sa kababago mo lang. Sinasabi ng dokumentasyon ng Apache na malamang na papangalanan ng error log ang directive na hindi pinapayagan o ang syntax error. Puwedeng magdulot nito ang mga rule na kinopya mula sa lumang tutorial: ang Order ay invalid command sa Apache 2.4 maliban kung naka-load ang mod_access_compat. I-undo ang edit para maibalik ang site, tapos basahin ang error log.

Lagpas sa default block

Ang permalink routing at ang Authorization header lang ang hinahawakan ng default block. Para higpitan ang access sa mga sensitibong file, tulad ng pagharang sa PHP execution sa /uploads o pagtanggi sa direktang request sa wp-config.php, tingnan ang WordPress .htaccess security rules na talagang nakakatulong. Kung nag-404 ang permalinks sa ibang dahilan, tulad ng maling permalink structure, caching layer na nagsisilbi ng lumang mga rule, o multisite subdirectory conflict, tinatalakay ng WordPress permalinks na hindi gumagana ang ibang mga sanhi.

Mga madalas itanong

Ano ang default .htaccess file ng WordPress? Ito ang RewriteEngine block na isinusulat ng WordPress sa pagitan ng # BEGIN WordPress at # END WordPress sa .htaccess file sa root ng site mo. Ipinapasa nito ang Authorization header sa PHP at ipinapadala sa index.php ang anumang request na hindi tunay na file o folder.

Ano ang eksaktong default .htaccess code ng WordPress? RewriteEngine On, isang rule na nagpapasa ng Authorization header sa PHP, RewriteBase /, isang pass-through rule para sa index.php, dalawang kondisyon na nagsusuri na hindi tunay na file o folder ang request, at isang huling rule na nagpapadala ng lahat ng natitira sa index.php. Nasa itaas ng gabay na ito ang buong block.

Bakit 404 ang lahat ng post ko maliban sa homepage? Ang nawawala o sirang .htaccess file sa Apache ang gumagawa ng pattern na ito. Nahahanap ng server ang homepage kahit walang rewrite rules. Kailangan ng bawat ibang permalink ang mga rule na iyon para makarating sa index.php, kaya kung wala ang mga ito, naghahanap ang Apache ng file na hindi umiiral at nagbabalik ng 404.

Ginagawa ba uli ng WordPress ang .htaccess nang awtomatiko? Oo, sa Apache o LiteSpeed na may mod_rewrite, kung naka-on ang pretty permalinks at kayang magsulat ng WordPress doon. Sapat na ang pagbukas ng Settings > Permalinks. Kailangan ng nawawalang file ang folder na writable, at dapat writable ang umiiral na file. Kung hindi, magpapakita ang screen ng error, kasama ang mga rule na ipe-paste nang manual.

Bakit walang .htaccess file ng WordPress ang nginx? Walang configuration file sa antas ng directory ang nginx na tulad ng .htaccess ng Apache. Ang parehong routing ay isinusulat bilang try_files rule sa server configuration ng nginx, na kailangang i-edit ng administrator dahil hindi ito kayang baguhin ng WordPress.

Bakit nasira ang .htaccess ko matapos ko i-save ang permalinks? Tingnan kung may custom rule na nailagay sa loob ng mga marker na # BEGIN WordPress at # END WordPress. Pinapalitan ng WordPress ang lahat sa pagitan ng mga ito kapag ina-update ang file, kaya nawawala ang rule na iyon. Ilagay ang custom rules sa itaas ng mga marker.

Mga pinagmulan

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Source code ng WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Buuin ang malinis at tamang .htaccess, kasama ang default permalink block at ang anumang security o redirect rules na talagang kailangan mo, gamit ang libreng WordPress .htaccess generator.