WordPress Real Physical Media 插件意外導致圖片路徑錯亂救援日誌

起因

出於好奇我下載了 WordPress Real Physical Media 插件以及它要求安裝的 WordPress Media File Renamer 插件. 這個插件聲稱自己可以通過將文件 (主要是圖片) 的物理路徑和文件在 Real Media Library 中的路徑對應, 優化網站的 SEO 表現.

# 比方說, 運行插件後, 文件會被這樣移動

Old Path: /wp-content/uploads/2022/06/pic-name.png
New Path: /wp-content/uploads/2022/blog-post-name/pic-name.png

雖然知道這個對 SEO 排名沒有多大幫助, 出於好奇我還是下載並執行了該插件.

結果是災難性的, 圖片被丟的亂七八糟, 而且插件和 W3 Total Cache 的壓縮為 WEBP 功能完全不兼容, 所有 WEBP 文件都沒有被移動. 改插件更改了所有媒體庫中文件對應的文件路徑, 卻沒有更改文章中圖片的 Link, 僅僅是做了重定向, 從而大大拖慢了頁面載入速度, 大部分圖片根本不會載入, 或者顯示 404 Not Found.

經過慌亂的尋找之後, 我意識到不管是 WordPress Real Physical Media 還是 WordPress Media File Renamer 都沒有 Undo 按鈕. 又是一番尋找之後我絕望的發現我的 WordPress 沒有任何最近的備份.

閱讀全文 WordPress Real Physical Media 插件意外導致圖片路徑錯亂救援日誌

為 WordPress 添加 Onion 域名

前言

我的博客本身擁有一個正常可訪問的域名, 為其額外添加一個 Onion 域名對我的安全係數不會有任何顯著的提升. 事實上, 對系統的穩定性可能有害無益因為我的博客本身是跑在 Cloudflare 防火牆後面的, 而啟用 Tor 之後, Tor 用戶就可以通過 Onion 域名直接訪問 WordPress 服務, 從而使 DDoS 以及其他攻擊變得反而更加輕鬆. 我之所以這麼做完全是好奇心使然, 如果你不清楚你在幹什麼, 請不要輕易模仿!

閱讀全文 為 WordPress 添加 Onion 域名

WordPress Docker 優化: 添加 PhpRedis、Memcached 支持

環境:
Docker + WordPress, 用官方默認的 Apache 驅動, 不是 fpm.

因為 PhpRedis 不屬於 PHP 內置的模塊, 而 PHP 內置了一個 Predis 又太慢太蛋疼, 所以要重新構建 Docker Image 為 PHP 添加 Redis 模塊支持.

為了添加這個 Redis 模塊, 我特別做了一些搜索, 發現網上清一色的全部是 本教程只適合 fpm 版本云云. 我個人認為這是一種迷思啊, 因為不論是用 php-fpm 還是 apache + php-mod 應該都和 php 的插件沒有太多關係吧. 所以雖然上面環境說的是 wordpress-apache , 用 wordpress-fpm 的朋友照著這個教程做也沒差.

構建 Docker Image

mkdir /tmp/build
cd /tmp/build
# 添加 Memcached 支持
cat > /tmp/build/Dockerfile << EOF
FROM wordpress:latest
RUN apt-get update
RUN apt-get install -y libz-dev libmemcached-dev && \
    pecl install memcached && \ 
    docker-php-ext-enable memcached && \
RUN rm -rf /tmp/pear && \
    apt-get clean
EOF
# 添加 Redis 支持
cat > /tmp/build/Dockerfile << EOF
FROM wordpress:latest
RUN pecl install -o -f redis && \
    docker-php-ext-enable redis
RUN rm -rf /tmp/pear
EOF

關於 Memcached vs Redis… 這個網上都可以搜到吧. 我的意見是, 兩者都能給一個 WordPress 小博客提供相當不錯的 Object Cache. 效能的話, Redis 略勝一籌, 但是要求專門開一個 Redis 容器. 而 Memcached 安裝好之後直接用就可以了. 所以還是根據服務器的配置來選吧.

docker build -t wordpress_extended .
閱讀全文 WordPress Docker 優化: 添加 PhpRedis、Memcached 支持

例行安全檢測 — 加固WordPress

因為我正在使用 cloudflare 提供的內網穿透服務, 相當於整個服務器只對外開放了 Web 服務, 所以我基本是圍繞 Web 服務在加固. 如果讀者的 wordpress 跑在租用的 VPS 上, 極有可能同時開放了數據庫、SSH、FTP 服務, 對這些的防護不在本文討論範圍內.

本文主要是參考了這篇官方教程. 如果你英文好的話, 不妨自己讀一讀這篇教程, 寫的很詳細, 基本每一個改動都有解釋.

檢測手段

https://github.com/wpscanteam/wpscan

下載 wpscan, 然後在終端敲入

wpscan --url https://example.com

可能需要關閉 CF 防火牆.

刪除無關文件

cd /www/wordpress

# 刪除根目錄下無關文件
rm readme.html
rm license.txt

# 遞歸刪除插件、主題 Readme
find . -name readme.txt -type f -print -exec rm -rf {} \;
閱讀全文 例行安全檢測 — 加固WordPress

WordPress + Cloudflared + V2ray 異地組網並隱藏流量

目標

  • 異地組網, 遠程訪問家中環境
  • 結合海外 VPS 翻牆 ( 不在此篇討論 )
  • 使用 V2Ray TLS 加密流量
  • 將 TLS 流量隱藏在正常的 HTTPS 流量中達到混淆目的
  • 使用 Cloudflare 的內網穿透服務, 達到防探測目的 ( 服務器直接和 CF 溝通, 沒有端口暴露 )
  • 使用 Cloudflare 的 CDN 服務, 達到防牆、加速作用

如果你並不是想要做異地組網, 而是想要在 VPS 上跑 (Nginx/Caddy/Apache) + WP + V2Ray, 那麼你其實用不著這麼複雜. 你只需要看這篇文章就可以了.

(這篇博文主要是討論一個沒多少人做過的方案的可行性, 所以你會看到後面還有一大通廢話; 作為教程本文是不合格的, 如果想要尋找教程請出門右轉谷歌搜索. )

網絡拓墣示意圖
閱讀全文 WordPress + Cloudflared + V2ray 異地組網並隱藏流量

定期批量刪除图片 EXIF

EXIF 元信息是一種圖片的附加信息, 一般在拍攝的時候就已經寫進圖片, 而圖片被上傳到 WordPress 之後也會留在裡面.我剛剛看完幾篇關於網絡安全的文章, 於是去查詢了一下維基百科看一看 EXIF 到底有沒有這麽恐怖. 很不幸, 確實有.

圖片可以暴露拍攝的時間和地點, 精確到 GPS 坐標

雖然我的網站並不是非常 Secure, 而我使用密碼的習慣也並不是非常 Solid, 但是修復已經注意到的漏洞, 減少攻擊面總是一件好事. 所以我就設置了一個 Cron, 定時刪除 WordPress 中儲存的所有圖片元信息.

怎麼做到

首先安裝 ExifTool, 一個以 Perl 寫成的開源圖片 EXIF 信息處理工具. 樹莓派是基於 Debian, 所以直接 apt 就可以了

apt update && apt install exiftool

然後定位到 /mnt/data/wordpress/ , 這裡是 WordPress 的根目錄. 我先執行一次清除試一下:

( 方法來自 這個討論串 )

$ find -type f -iname '*.jpg' -exec exiftool -all= {} \;

1 image files updated
1 image files updated
...

然而, 除了修改文件以外, 這個工具還產生了 *.jpg_original 格式的備份, 這些備份我並不需要.

find . -name "*.jpg_original" | xargs rm -rf   

寫進 Cron

明確了作法之後, 就可以將任務寫進 Cron 了.

touch /etc/cron.daily/rm_exif
cat > /etc/cron.daily/rm_exif <<EOF
#!/bin/sh
find /mnt/data/wordpress -type f -iname '*.jpg' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.jpg_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.jpeg' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.jpeg_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.png' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.png_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.gif' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.gif_original" | xargs rm -rf
EOF
chmod +x /etc/cron.daily/rm_exif

完成了!

Cloudflare Tunnel Self WebHosting

由於不習慣用 Hugo 管理內容, 且文章漸漸多了起來, 我在家中的樹莓派上跑起了一個 WordPress. 一切都進行的很順利, 直到我發現發佈這個網站並不是我想像中的那麼容易.

這篇文章是一篇踩坑文, 就是說我會把我在設置中遇到的一切困難完整的紀錄在文章中, 因此你不應當將其當作教程來看. 如果需要教程的話, 我推薦 官方文檔 , 或者 土豆不好吃 的教程.

前言

失敗的嘗試

首先, 我的樹莓派跑在內網, 我需要在路由器上配置一個端口轉發. 借助 Openwrt 的圖像介面, 我輕鬆的完成了轉發.

其次, 我還需要一個公網 IP. 撥打了電信的電話, 我成功的要到了公網 IP.

因為 “維穩” 需求, 電信是封殺 80, 443, 等常見的端口的. 因此我將 443 端口轉發到了 2053 端口上. ( HTTPS 證書是 Cloudflare 的原站證書 ) 2053 端口確定可以訪問.

在然後, 每次撥號的時候 IP 都會改變, 我需要配置一個 DDNS. 為了解決這個問題, 我找到了一個 Cloudflare DDNS 腳本跑在 Openwrt 裡來動態更新我的 IP.

一個類似 ip.justin.education:2053 的地址為免有些太過不友好, 於是我使用 CF-Workers 反向代理網站到 proxy.justin-zhang.workers , 再將其 CNAME 到 justin.education.

如果是靜態頁面這個時候已經可以訪問了, 但是 WordPress 並不支持多個域名, 一直在執著的 301 重定向. 我不能配置其地址為 justin.education, 因為那樣我就沒辦法登錄後台: CF 反代不支持保存 Cookies.

我於是在 Openwrt 上用 Docker 跑了一個 Nginx 來反代網站, 放棄了簡單的端口轉發的方案. 這次成功了, 不過我遇到了一些圖片和CSS不能加載的問題. 安裝插件之後我配置了替換 Header 的規則, 總算是可以看了.

但是由於 CF Workers 的緣故, 評論還是不工作. 而且攻擊者只要知道了我的端口是 2053, 他可以全網搜索 ip.justin.education:2053 的證書來找到我的真是 ip; 這顯然太冒險.

這個方案失敗之後, 還剩下的就是使用 frp 內網穿透的方案. 然而我並不想用我的翻牆服務器來代理網站, 我經常換 ip, 而且不安全, 而且效率太低.

看起來我已經被逼到絕路了.

閱讀全文 Cloudflare Tunnel Self WebHosting

WordPress Enligher 插件適配主題

感覺博客缺少一個代碼高亮插件, 所以我就挑了一個免費的, 功能比較多的插件 Enligher 安裝到博客.

好用但是挺好用, 但是好像和當前的主題不太兼容, 具體症狀請見下圖:

可以看見, 不管是編輯器還是實際文章, 這個插件都有兼容性問題.

所以我馬上要做的事情, 就是找出問題並自己解決掉.

我沒有學過任何關於 CSS 或者 JS 的知識, 以下所有紀錄都來源於常識… 如果我有哪邊做錯, 歡迎在評論區指正😄

(下文所有的修改都會寫在文末的 patch 文件中)

編輯器部分

錯位修正

margin 的左右都是 0

這個比較簡單, 修改 enlighter/resources/gutenberg/enlighterjs.gutenberg.min.css , 如下所示:

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	/* max-width: 100%; */
	padding: 15px
}

刪除/移動 干擾信息

右下角的提示 “EnligherJS Syntax Highlighter” 一直都在那裡, 非常佔空間而且還會產生打擾的效果, 所以我們不能讓它達到目的, 可以直接把它刪掉. 另外, 左上角的粗體字提示 Highlighting 種類未免有些太過喧賓奪主, 要是可以把它移到右下角的話豈不完美.

所以我就將 enlighter-footer 的部分刪掉, 然後將 enlighter-title 的部分移到 原來的 footer 的部分. 目前一切進行的都比較順利.

wp.element.createElement("div", {
                    className: "enlighter-header"
                },
                    /*wp.element.createElement("div", {
                        className: "enlighter-title"
                    }, (e = t.language, s()[e] || "Unknown language"))), wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }),*/
                    /*wp.element.createElement("div", {
                        className: "enlighter-footer"
                    },
                        wp.element.createElement("div", {
                            className: "enlighter-footer-label"
                        },
                            wp.element.createElement("strong", null, "EnlighterJS"), " Syntax Highlighter"))*/
                    wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }), wp.element.createElement("div", {
                        className: "enlighter-footer"
                    }, wp.element.createElement("div", {
                        className: "enlighter-footer-label",
                    }, (e = t.language, s()[e] || "Unknown language")))),

美化

到這一步, 編輯器 Enlighter 區塊的效果是這個樣子的:

不夠完美啊!

從使用的角度來說, 它已經夠用了.
但是右下角的那一行字總覺得有點不和諧.

所以我就把它往下移動了一點點, 並且加粗.

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	padding: 15px;
	padding-block-end: 1px /* New */
}
div[data-type="enlighter/codeblock"] .enlighter-footer-label {
	text-align: right;
	font-size: 10px;
	font-family: Menlo,Consolas,monaco,monospace;
	color: #23282d;
	cursor: pointer;
	padding-top: 3px; /* New */
	font-weight: 800 /* New */
}

( 以上所有代碼全部由我目測得到, 且並不理解其含義, 均未考慮兼容性. 使用前請再三考慮 )

最終效果

現在感覺好多了 👌

網頁展示部分

EnlighterJS 官網按鈕倒不難去掉, 插件提供了開關可以直接把它關掉.

將 EnlighterJS website button 設為 Disable 就可以了

那麼接下來要做到就是適配暗黑模式.

適配暗黑模式的話… (撓頭) 要改的變量好像有點太多了, 暫時就不寫了吧.
本身 MDX 的暗黑模式就不太好看, 我的解決方法就是 徹 . 底 . 不 . 開 ! 這下不會有問題了吧?

Patch via Gist