年度改版·貳零貳伍年

日期：
分類： 站務
標籤： 人工智慧消遣

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

配色

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

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

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

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

— 完 —