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

Docker 默認網段巨坑

簡單的紀錄一下我瞎搞Docker的時候碰到的一個坑:
我現在要配置一個Nginx, 跑在路由器上, 地址是 192.168.10.1 ;
我要用 Nginx 反向代理一個網站, 跑在這個局域網裡面, 地址是 192.168.10.10
這其實根本就超簡單, 正常情況下沒有 Docker, 我們就直接編輯 /etc/nginx/conf.d/default.conf, 然後在裡面扔以下配置, 就直接 Ok (緩存啥的都有照顧到, 我就拿這個作為模板)

server {
    listen 80;
    listen 443 ssl http2;
    server_name 127.0.0.1;

    ssl_certificate /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/private.key;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    add_header Strict-Transport-Security "max-age=31536000";
    error_page 497 https://$host$request_uri;


    location / {
        proxy_pass https://justin.education;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header REMOTE-HOST $remote_addr;

        add_header X-Cache $upstream_cache_status;

        #Set Nginx Cache

        proxy_set_header Accept-Encoding "";
        sub_filter "http://192.168.10.10" "https://192.168.10.1";
        sub_filter "https://192.168.10.10" "https://192.168.10.1";
        sub_filter_once off;


        proxy_ignore_headers Set-Cookie Cache-Control expires;
        proxy_cache_key $host$uri$is_args$args;
        proxy_cache_valid 200 304 301 302 10m;
    }
}

然後就一直提示我 502 Bad Gateway, 我就 …

光看截圖你就知道我該有多 Mad

愣是浪費我整整一個小時時間來檢查哪裡有問題, 所以說思維定勢真的不可取, 你說他每次用都好好的, 怎麼一到 Docker 上面就出問題?

不過萬幸的是我想起來起看了一眼日誌 (日誌一定得看啊) , 然後發現一直提示訪問 172.17.0.1 報錯…

於是我去谷歌上面搜了一下 鏈接 , 發現 172.17.0.1/16 是 Docker 自己的一個網段, 是通過 NAT 橋接到 Host 網絡的.

這就… 怪不得. 都不在一個網段裡面, 訪問得到才有鬼

知道就好辦, 直接在 Portainer 裡面從 Bridge 改為 Host 就解決了問題.

Docker 日誌塞滿服務器修復

早晨我例行的摸了一下鏈接到樹莓派的硬盤,結果發現它不轉了。Nani?
於是我立即嘗試登錄寶塔面板,結果發現卡在登錄頁面。
使用SSH重啓之後根本重連不上,網關提示根本沒給它分配IP,就是說它現在不能聯網。
我把樹莓派強制斷電後插電,可以連上了,但是提示的消息卻讓我比較震驚…

空間佔用 100% ?

於是我決心把他弄懂。

問題初步排查

首先肯定是要確定磁盤佔用是這樣…

$ df -h

Filesystem                                     Size  Used Avail Use% Mounted on
tmpfs                                          782M   60M  723M   8% /run
/dev/mmcblk0p2                                 117G  117G     0 100% /
tmpfs                                          3.9G     0  3.9G   0% /dev/shm
tmpfs                                          5.0M     0  5.0M   0% /run/lock
tmpfs                                          4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/mmcblk0p1                                 253M  152M  101M  60% /boot/firmware
/dev/sda1                                      916G   95G  776G  11% /media/backup
tmpfs                                          782M  4.0K  782M   1% /run/user/0

是這樣沒錯,然後要定位到主目錄,看看到底那個文件夾出了問題。

$ cd /
$ du -h -x --max-depth=1 

74M    ./home
2.9G    ./usr
8.0K    ./.disk
24K    ./snap
4.0K    ./mnt
4.0K    ./srv
114M    ./root
72K    ./tmp
117M    ./boot
16K    ./opt
8.0K    ./patch
6.1M    ./etc
4.0K    ./media
4.1G    ./www
110G    ./var       <- 問題根源
16K    ./lost+found
117G    .

經過一番定位之後,現在可以發現問題的根源在這個文件夾裏:

/var/lib/docker/containers/6c8a****13f4/

進一步定位那個文件出了問題:

$ ll


total 112907424
drwx------ 4 root root         4096 Jan  7 04:41 ./
drwx------ 4 root root         4096 Feb  3 21:06 ../
-rw-r----- 1 root root 115617058816 Feb 18 13:05 6c8a****13f4-json.log
drwx------ 2 root root         4096 Feb  3 16:33 checkpoints/
-rw------- 1 root root         3958 Jan  7 04:41 config.v2.json
-rw-r--r-- 1 root root         1513 Jan  7 04:41 hostconfig.json
-rw-r--r-- 1 root root           13 Feb  5 13:29 hostname
-rw-r--r-- 1 root root          174 Feb  5 13:29 hosts
drwx------ 3 root root         4096 Feb  3 16:33 mounts/
-rw-r--r-- 1 root root          612 Feb  5 13:29 resolv.conf
-rw-r--r-- 1 root root           71 Feb  5 13:29 resolv.conf.hash

恐怖的發現…這個日誌文件竟然佔了這麼多的大小…

修復問題

看了一下日誌,整個日誌基本全是 P2P文件交換的記錄。
離譜的是這個日誌居然是以毫秒記錄的,有的地方甚至一毫秒幾十行…這個樹莓派是怎麼支撐過來的?
因爲沒有值得注意的東西,我就直接 rm 掉了。瞬間執行,滿足感還是很高的, WinServer不知道刪到猴年馬月去。
(Ext4文件系統刪除文件時並沒有對數據進行操作,我的理解中是將記錄文件信息的索引釋放掉了,在系統的想法裏這片空間又變回可寫的了)

$ df -h

Filesystem                                     Size  Used Avail Use% Mounted on
tmpfs                                          782M   79M  703M  11% /run
/dev/mmcblk0p2                                 117G  9.3G  103G   9% /
tmpfs                                          3.9G     0  3.9G   0% /dev/shm
tmpfs                                          5.0M     0  5.0M   0% /run/lock
tmpfs                                          4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/mmcblk0p1                                 253M  152M  101M  60% /boot/firmware
/dev/sda1                                      916G   95G  776G  11% /media/backup
tmpfs                                          782M  4.0K  782M   1% /run/user/0

很好,空間佔用回到正常了。

防止問題重複

既然知道了是日誌文件的問題,現在就要搞清楚到底那個容器出了問題。

$ docker ps -a

CONTAINER ID        IMAGE
84e1a7934eb6        linuxserver/syncthing:latest
6c8a506e5aca        linuxserver/resilio-sync:latest

現在就知道哪裡出現問題了。可以看到,resilio-sync 的id對應了那個日誌文件的開頭。

我更改了resilio sync中的設置,分別更改爲

log_size = 0
log_ttl = 0
disk_low_priority = true

希望這樣可以有效果,我會在幾天後再來查看。

实测这样子并没有效果,看起來是Docker鏡像製作時留下來的問題, 直接在容器裡更改配置不起作用.

那這不簡單.

docker pause ResilioSync
rm 6c8a****13f4-json.log
ln -s /dev/null 6c8a****13f4-json.log
$ ll

總計 36K
drwx------ 2 root root 4.0K  1月  1  2038 checkpoints
-rw------- 1 root root 4.9K  5月  5 10:25 config.v2.json
lrwxrwxrwx 1 root root    9  5月  5 10:26 6c8a****13f4-json.log -> /dev/null
-rw-r--r-- 1 root root 2.2K  5月  5 10:25 hostconfig.json
-rw-r--r-- 1 root root   13  5月  4 22:14 hostname
-rw-r--r-- 1 root root  174  5月  4 22:14 hosts
drwx-----x 2 root root 4.0K  1月  1  2038 mounts
-rw-r--r-- 1 root root   61  5月  4 22:14 resolv.conf
-rw-r--r-- 1 root root   71  5月  4 22:14 resolv.conf.hash
docker unpause ResilioSync

问题到此解决

沒解決.

這樣做之後確實一時爽, 但是過了一天我回來看, 發現容器停止運行, 原因是

/mnt/data/docker/containers/6c8a****13f4-json.log/dev/null no file or directory

所以問題到底怎麼解決呢?

經過一番搜索(現在才想起來有谷歌這回事)之後, 我得到了結果, 問題完美解決.

原來是可以通過配置 docker-compose 來限制logsize的, 比如說我要限制 nginx 的 logsize 為5g, 我可以

nginx: 
  image: 
  restart: always 
  logging: 
    driver: “json-file” 
    options: 
      max-size: “5g” 

那麼我是用portainer管理docker的, 我可以

問題到此真正完美解決.