年度改版·貳零貳伍年

一年一度的閒著沒事幹系列。

配色

風記星辰」別的先不說,站長的配色功力真是一絕。差距實在太大,成功讓我死心,不再試圖運用我蹩腳的審美來為網誌配色。

話說,也看了不少設計師的網誌,個人大致分為兩類:一類是不愧是設計師,功能、配色面面俱到;另一類,也同樣不愧是設計師,色彩之繽紛、特效之華麗,不說找不到按鈕,連文字都看不太清。

移除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有些划不來。拆了之後又覺得可惜,記錄下來,說不定哪天裝回去。

話說回來,搜尋跟留言一樣,都是來者不善的重災區,或許該像專業人士所說的乾脆封鎖?

— 完 —