v1.8.0 — search pagination is back
Bug fix release. Update if visitors use your site's search.
Search results collapsed to a single page. With search hardening on — the default — the plugin unconditionally set no_found_rows on the search query, so found_posts and max_num_pages stayed at 0 and themes drew no pagination links. A search matching a hundred pages of posts looked like it matched one. Nothing in the markup hints at the cause; the first page of results is entirely correct, there is simply no way to reach the second.
Skipping that count is now its own setting, off by default:
| Constant | Default | Behaviour |
|---|---|---|
PH_SEARCH_NO_FOUND_ROWS |
false |
Drops SQL_CALC_FOUND_ROWS on the search query. Saves the full scan, at the cost of every pagination link on the results page |
This is the same treatment v1.6.0 gave to widget and page-builder queries, and for the same reason: an optimisation that silently removes something from the page does not belong in a default. Search pagination recovers from the upgrade alone — no setting to change, no wp-config.php edit.
Unlike tag and taxonomy archives, search has no cheap stored count to rebuild the page total from, so the trade-off is genuine rather than an oversight: keeping the count means paying for the scan. Everything else in search hardening — junk-probe filtering, the narrowed post_type / post_status, title-and-excerpt matching — is unchanged and still on.
One thing to check after upgrading: PH_SEARCH_MAX_PAGES (default 3) is a separate cap and still applies. Now that pagination links are visible again, visitors can see links to pages that intentionally return nothing. Raise it, or set it to 0 to lift the cap, if searches on your site should page deeper than three.
Verified on WordPress 7.0.2: default and hardened modes, both the admin setting and the constant, the save round-trip, and pagination output on a multi-page search. Plugin Check clean.
修正版本，站上有站內搜尋功能者請更新。
搜尋結果會塌成只有一頁。搜尋防護開啟時（預設即開啟），外掛會無條件對搜尋查詢套用 no_found_rows，found_posts 與 max_num_pages 因此固定為 0，佈景主題隨之不輸出任何分頁連結——原本符合上百頁的搜尋，看起來就像只有一頁。畫面上沒有任何線索指出原因：第一頁的結果完全正確，只是沒有任何途徑能走到第二頁。
略過該計算改為獨立設定，且預設關閉：
| 常數 | 預設 | 行為 |
|---|---|---|
PH_SEARCH_NO_FOUND_ROWS |
false |
搜尋查詢關閉 SQL_CALC_FOUND_ROWS。省下全表掃描，代價是結果頁的所有分頁連結 |
處理方式與 v1.6.0 對次要查詢的修正相同，理由也相同：會讓畫面上某個東西無聲消失的優化，不該是預設值。搜尋分頁光是升級就會恢復，不需調整任何設定，也不需修改 wp-config.php。
與標籤／分類法封存頁不同，搜尋沒有如 term count 那樣的便宜既存計數可用來還原總頁數，因此這是真正的取捨而非疏漏：要保留計數就得付掃描成本。搜尋防護的其餘部分——垃圾關鍵字過濾、限縮 post_type / post_status、只比對標題與摘要——皆未變動且維持開啟。
升級後請一併確認：PH_SEARCH_MAX_PAGES（預設 3）是另一個獨立的上限，仍然有效。分頁連結恢復顯示後，訪客會看得到那些刻意回傳空結果的頁面連結。若站上的搜尋需要翻超過三頁，請將其調高，或設為 0 解除上限。
已於 WordPress 7.0.2 驗證：預設與收斂兩種模式、後台設定與常數兩種寫法、後台儲存往返，以及多頁搜尋的分頁輸出。Plugin Check 通過。
安裝：後台「外掛 → 安裝外掛 → 上傳外掛」上傳附件 ZIP。
完整變更紀錄見 CHANGELOG.md