一年一度的閒著沒事幹系列。
配色
「風記星辰」別的先不說,站長的配色功力真是一絕。差距實在太大,成功讓我死心,不再試圖運用我蹩腳的審美來為網誌配色。
話說,也看了不少設計師的網誌,個人大致分為兩類:一類是不愧是設計師,功能、配色面面俱到;另一類,也同樣不愧是設計師,色彩之繽紛、特效之華麗,不說找不到按鈕,連文字都看不太清。
移除WordPress留言功能
大致上……同意要開放討論才能激盪思考火花啦,但對我這種0IP/1IP部落格,會留言的訪客基本上是善者不來,來者不善,不知道要對留言表單做什麼。十個有九個是機器人,剩下一個是不知從哪學到點駭客技術,於是「身懷利器,殺心自起」。
會說大致上,是因為除非特地找碴,一般情況有誰會到別人地盤去反駁別人?很難說最後到底是為難誰。多是「引起共鳴」,所以要說思考火花……其實也……還好?
WordPress資料庫大掃除
雖然看建議說沒必要,但閒著沒事幹,來清理資料庫。
_wp_old_slug
WordPress會記錄下「所有」登記過的Slug。像我這種文章標題猶豫不決症患者,改五次就出現五個_wp_old_slug
。
DELETE FROM `wp_postmeta` WHERE `meta_key` = '_wp_old_slug';
oEmbed
費解。明明已經關閉相關功能了,卻還是有資料寫進資料庫中,查找相關聯的文章裡面也沒有嵌入的引用。而且還到處存,wp_posts有,wp_postmeta也有。
DELETE FROM `wp_posts` WHERE `post_type` LIKE '%oembed_cache%';
DELETE FROM `wp_postmeta` WHERE `meta_key` LIKE '_oembed_%';
Algolia
wp_postmeta裡面還有八百年前反安裝的WP Search with Algolia留下的痕跡。
DELETE FROM `wp_postmeta` WHERE `meta_key` LIKE 'algolia_%'
LikeCoin
一樣是早八百年前刪除的外掛。
DELETE FROM `wp_postmeta` WHERE `meta_key` LIKE 'lc_%'
Blocksy
Blocksy佈景主題的Blocksy Child Page Settings很好用。但由於之前頻繁摸索的緣故,導致在wp_postmeta產生一堆殘留物。
太過雜亂懶得仔細看,直接全部刪除,再對需要的Content Blocks重新設定,重新寫入資料庫。
DELETE FROM `wp_postmeta` WHERE `meta_key` = 'blocksy_post_meta_options';
fs_api_cache
隸屬於Freemius,位於wp_option。清空option_value後自動重建。
重建前足足有7MB,重建後只有60KB。之前就在納悶,我有那麼著作等身?
其他
日常其他的清理項目就靠WP-Sweep跟phpMyAdmin的Cron Job。
另,發現古騰堡的Footnote功能是把腳註寫到wp_postmeta,它這樣與內文拆分感覺以後匯出或是古騰堡改版/被取代時會很痛苦。
將WordPress搜尋頁的?s=改為/search/
實在不喜歡要301轉址的方式,使用JavaScript解決,感謝AI。
修改searchform.php
- 設定<form>的id,例如:
id="searchForm"
。 - 設定<input>的id,例如:
id="searchContent"
。
*設定id配合search-rewrite.js的getElementById
。
建立search-rewrite.js
document.addEventListener('DOMContentLoaded', function () {
var form = document.getElementById('searchForm');
var searchField = document.getElementById('searchContent');
if (form && searchField) {
form.addEventListener('submit', function (event) {
if (!searchField.checkValidity()) return;
event.preventDefault();
var searchValue = searchField.value.trim();
if (searchValue) {
location.href = `https://example.com/search/${encodeURIComponent(searchValue)}`;
}
});
}
});
form = document.getElementById('');
填入searchform.php中<form>
標籤裡的id。searchField = document.getElementById('');
填入searchform.php中<input>
標籤裡的id。- 修改https://example.com
*將輸入限制交給搜尋表單的pattern
,通過後才會繼續執行。
在functions.php加入重寫規則
function search_rewrite_rule() {
add_rewrite_rule('^search/([^/]+)/?$', 'index.php?s=$matches[1]', 'top');
add_rewrite_rule('^search/([^/]+)/page/([0-9]+)/?$', 'index.php?s=$matches[1]&paged=$matches[2]', 'top');
}
add_action('init', 'search_rewrite_rule');
*讓/search/keyword與/search/keyword/page/都能對應上。
*到WordPress控制台的Settings > Permalinks點擊儲存,以便存入新設定的重寫規則。
在functios.php載入js檔
add_action('wp_enqueue_scripts', function () {
wp_enqueue_script( 'searchrewrite', get_stylesheet_directory_uri() . '/search-rewrite.js', array(), null, true );
});
urldecode
由於其他設定,另外還處理了urldecode
的問題,中文的劣勢就在這裡體現,英文隨便編碼解碼都沒事,中文直接轉到認不出,害我跟AI吵起來。
總結
考慮半天還是拆掉,還原到傳統的查詢參數?s=,總覺得為了/search/格式好看而多加一個JavaScript有些划不來。拆了之後又覺得可惜,記錄下來,說不定哪天裝回去。
話說回來,搜尋跟留言一樣,都是來者不善的重災區,或許該像專業人士所說的乾脆封鎖?