建站/框架

我需要做什麼？

閱讀本文，選擇符合您需求的框架，並按照提供的安裝指南進行最終操作。

• 例如：Mediawiki、Typecho

　

前言

從技術流程上講，我們需要先部署web環境再安裝框架，但從策略邏輯上講，我們需要先敲定框架，再部署需要的環境。

選框架要謹慎：

• 體量上：像wp，功能多、插件多，但適合做論壇或者商業化的東西，做個人博客有些太折騰及臃腫；
• 創作上：長期文本創作，我更喜歡可視化編輯——所見即所得，就如同主流社交平台編輯文章的界面一樣，我想看到實時的渲染效果；
• 體驗上：一開始我用的wp，大部分時間都花在了處理框架問題上^{（比如優化、設置、格式轉換等）}，後來試圖換成Typecho，但仍舊對編輯功能不滿意，並且默認主題不好看，使用別人的主題花了很多時間在調整細節上，但仍舊有諸如頁面上的編輯按鈕被其他元素蓋住無法觸擊等問題^{（非框架純主題問題）}，最後換成了mediawiki，啟用可視化編輯後，才安下心來寫東西，也是wiki.scio.icu使用的框架。

目前已寫指南：

• MediaWiki 初始化安裝移步：建站/MediaWiki、拓展等功能的使用移步：建站WIKI功能
• Typecho 安裝指南移步：建站/Typecho

但在這之前，建議您先閱讀本文的以下章節，了解我對它們的純主觀意見^{（限於默認設置或極其簡單就能實現的功能）}，以便助您更好的選擇。

　

MediaWiki

　　Mediawiki是基於WikiText語法的內容管理平台，與markdown語法的絕大部分功能兼容。也是WIKI及本站所使用的框架，我用過的博客框架不多，也只有mediawiki留住了我創作的積極性，作為平均每天都要編輯好幾次、使用兩年半^{（2022-05至編輯時的2024-11）}、累積碼了百萬字單位的mediawiki使用者，我鍾愛於它，但它也並不完美，也有很多弊端，且聽我細細道來。

本質

　　Mediawiki是由頁面構成的，所有內容都是頁面，普通的页面是頁面、分类是頁面、文件是頁面、用户是頁面、模板是頁面、xx讨论是頁面、就連設定框架css/js樣式的亦是頁面。區別它們的是「命名空間」，除了主命名空間外都具有前綴^{(或者說主空間的前綴為空)}，如分类:xxx，您可以在 特殊:所有頁面 中檢閱它們。

　　底層設定讓這些命名空間有不同的展現形式與功能，比如文件頁面會顯示圖片信息，分类頁面會統計所有轄內頁面，但他們本質仍舊是頁面，除了設定css/js樣式的特殊功能頁面外，它們具有相同的風格，可執行相同的操作。

　　如此設計有優點：一切由自己支配，自由度高。您可以查閱：Wiki:SCIO系列站點WIKI章程 ，後半部分羅列了WIKI的所有分類與頁面；前半部分是統計的一些大類別的索引，而一些具有較多文章的類別我又為其創建了單獨的索引頁，這使得管理跨類別/主題較多的文章時十分便利——類別越多其優勢越明顯，因為類別或文章太少反而顯得臃腫。這在普通的博客框架中是很難做到或維護繁瑣的，因為它們會混為一談或毫無章法^{(粗暴的按照發佈時間排序，或標籤/分類內按照拼音或字母順序排列)}，而給他們建立索引頁的繁瑣度又遠超mediawiki——況且這樣一來這些傳統博客框架依據標籤與分類自動建立的索引的機制又失去了其價值。

　　當然也有其缺點：如你所見，一切都需要你自己構建，相對較為繁瑣，如果你無法藉助腳本自動化一些繁瑣流程，那就只能手動維護這一切。所有的索引頁/匯總頁都是手動編輯與維護的，而不是常規博客框架發佈自動建立索引/歸檔。

優勢

編輯的易用性：

• 真·可視化編輯，在頁面內直接編輯而不需要跳轉到專門的工作區，所見即所得，適合長期/頻繁編輯的場景，尤其是記錄生活類博客；
  • 可視化編輯器支持的功能類似於typora的升級版，除了實驗性與特殊用途外，所有文本創作都可以用可視化編輯器單獨完成。
  • 原始碼編輯器配合官方提供的體驗增強擴展使其用起來也不難，1.41.1版本已經引入了在編輯器窗口「顯示預覽」的功能，雖然有幾秒刷新延遲或需要手動刷新，但比近似於提交的那個預覽更方便(那個預覽會刷新一下頁面，也就使編輯痕跡無法通過ctrl+z找回)。
• 插入內鏈十分方便，不必輸入url，輸入頁面標題即可，這使得對站內文章相互索引有強烈需求的用戶省去很多麻煩。
  • 需要順序輸入標題部分，如輸入「你」，它只會以此為起點索引「你xxxx」的文章。
• 支持嵌入HTML代碼，其弊端見劣勢章節。

UI的乾淨簡潔：

• 空間利用率大、看着舒服、適合長篇幅文章。
  • 推薦vector舊版(2010)皮膚，維基百科目前用的就是新版(2022)皮膚，多了一些無意義空區，且文本區域最寬948px，舊版是自適應；typecho默認的行間距都可以通行航母了，短篇文章還好說，像wiki:生與死這種長篇文章就體現出臃腫程度了。

組織內容的強勢：

• mediawiki是由頁面組成的，可以給頁面設置類別（不限數量），而類別也是頁面，可以正常填充內容^{(不支持可視化編輯器但支持wikitext語法)}，因此可以嵌套類別，實現層級的分別；
  • 簡單來說就是一個可以嵌套的分類機制，我是採用一個大一統但無意義的根類別，下面接幾個二級類別，然後慢慢細分；
  • 在創建頁面時，點擊「≡」，選擇「分類」，設定為什麼，就歸類於什麼名下；「分類」本身也算頁面，所以也可以讓分類掛靠到其他分類下^{（但分類命名空間只能原始碼模式下編輯，格式為「[[分类:要归类到哪个分类名下]]」）}。
• 但默認的分類頁面對所有旗下分類及文章的匯總方式同其他主流框架的類別機制一樣，排序按照拼音順序不能自定義，所以我是使用新建一個總的頁面去索引一切文章，其他主流框架也可以這麼做，但是mediawiki插入內部頁面十分方便，修改起來也順手，可以提高編輯效率。
• 因此對於 涉及多话题 但 每个文章间又紧密联系 的創作需求非常好用；當體量變大時，大索引頁 索引 小索引頁，小索引頁 索引 轄內文章，不用擔心跨類別較多時難於管理。
  • 需要手動寫索引頁，但由於是頁面，怎麼寫索引、說點什麼，自然是看心情隨便安排。而常規博客框架只適用於每篇文章僅題材相同但互相獨立的情況，除非是常用內容，否則很難想起舊文章，其框架特色默認的歸檔內容也就只是歸檔作用，除非手動建立索引頁。
• mediawiki是為多人協作與維護內容類項目而生的，在編輯內容上所支持的自然比其他框架更多，比如比如站內文章/一些固定詞彙發生了變動，要修改其他頁面對其的索引，自有「特殊:替換文本」的功能去幫助簡單的實現。
• 簡單即自由。

劣勢

編輯的缺陷：

• 在原始碼模式下編輯內容，兩行回車才是換行；可視化編輯器下一行回車即可，生成的代碼其實就是兩行回車^{（Markdown就是如此）}，因此若要將原始碼移植到非wikitext、markdown語法場景，需要額外做些工作^{（比如批量替換換行符）}；
• 多個連續的回車/空格在提交編輯後會被視為只有一個、標題上一行的回車會被無視；
  • 所以我大量使用全形空格「　」^(u+3000)佔位）。
• 引用中的文本、代碼框文本等樣式前後容易出現換行失效的情況；
  • 解決方案：在原始碼模式下，以：<blockquote>Q：我需要做什么？……、</syntaxhighlight>'''添加了拓展文件后，无法访问页面'''……：為例，在標記標籤和正文文本間用回車換行即可，但是否失效只能保存(渲染後)才知道。

• 原始碼模式下原生可以調用html的style元素，設置後可插入html代碼，以便實現特殊需求，但很多情況都無法在可視化編輯器下快捷編輯；
  • 一般來說，於可視化編輯器下能預覽的內容都可以進行直接編輯（修改、複製、粘貼）；
  • 但諸如直接插入html代碼和一些拓展實現的功能，在可視化編輯器下都是以按鈕或元素卡片的形式出現，其編輯跟原始碼模式下無甚區別甚至無法編輯，顯現不出可視化編輯器的優勢。
• 解析器與編輯習慣可能衝突，比如「#」「*」在wikitext中是列表元素標識，在可視化編輯器內輸入此類符號再接空格，是一個很普通不過的編輯習慣，但在wiki中會識別為wikitext元素並解析/渲染為列表樣式；
  • 可視化編輯中可以ctrl+z取消樣式，正常來說保存後不會被再度解析，但有抽風的風險；原始碼模式下編輯需要添加「<nowiki>内容</nowiki>」來阻止渲染。
• 對於非可視化編輯器主用功能，在調用或渲染時或有抽風：如代碼框視角置右、中文(全形)引號導致定位不准；插入外鏈圖像的渲染規則不一致(中文名的圖片在頁面中不會渲染，在可視化編輯器中會渲染)等。

性質上的劣勢：

• 因為它為了多人協作、公共項目而生，主流應用場景還是維基百科等項目，而它們都是用原始碼編輯器，開發團隊的重心也不在個人用途上，就延伸出一系列個人用很難受的功能，比如不支持^(視頻)或最低限度的支持^(圖像)插入外部資源、上傳文件的多步驗證。
• 個人博客用途中，可視化編輯器是最主要的核心，而對於高級功能——以模板或嵌入html代碼為例的任何非可視化編輯器所能提供或不能完全提供的功能——都需要在原始碼編輯模式下完成，這就要你審視自己的實際應用場景、需求、對wikitext語法編輯的接受度等。
• 由於用於個人博客和用於維基項目的用戶群體數量差異，無法妄想其官方團隊為個人博客用途做優化。

對於功能/題材單一的場景：

• 如果您的博客涉及內容單一或跨題材很少，尤其是每篇文章間是獨立的^{（或許題材相同，但絕對沒理由相互索引）}，那麼建議您使用其他主流博客框架。無他，上手更簡單、發佈更省心就是完全足夠的理由，不是所有人都有維護索引頁的需求和精力，而用wiki又大量創作文章可不建立索引頁，那同樣是放棄了wiki的強勢之處。
• 除了常規博客，對於單一系列類內容，尤其是指南類，或許wiki.js這種才是更好的選擇。

對於插入媒體資源需求強烈的場景 / 圖片管理：

• 圖片上傳和管理機制對於個人博客用途來說十分不友好：
  • 前者是上傳需要多步確認^{（如可視化編輯器中需要勾選版權確定的複選框、填寫文件描述、設定略縮圖和圍繞文字的樣式）}
    • 在特殊:上傳文件中可以只拖動文件，自動按照文件名填寫頁面名並直接提交即可；
    • 也有MsUpload這類(基於原始碼編輯器的)批量上傳工具。
  • 後者是會自動壓縮圖片為各種解像度造成大量冗餘、有着「壓縮後的大小遠超原圖」的現象、圖片存儲路徑混亂不便統一管理；且不支持avif等非上古格式，我都是上傳圖片到伺服器後插入直鏈；在我更改圖像上傳策略前，我在WIKI實際上傳了50MB的圖像，但是在WIKI的文件夾中，加上各種解像度的版本，佔用空間達到了400MB；
    • 這看起來也不是多，但是我非常在意，尤其是圖像是瑣碎的分佈到各種文件夾中，如果後續我要備份WIKI，只能備份/恢復數據庫+這些臃腫的文件，所以我採取上傳外鏈的形式插入圖片；
    • 如果只是上傳圖像，按照指南設置好模板，選好託管圖片的網站（或者自建圖床）也不麻煩，但我的目的是上傳小體積的圖片，因此需要做些額外的操作，比如壓縮圖像、上傳到自己的另一個伺服器中^{（通過sftp）}避免佔用scio.icu域的站點性能，就顯得麻煩了點——這可不是「麻煩一點」的問題，因為頻繁編輯的情況下，會麻煩很大，就會像typecho等框架一樣影響編輯的動力，因此我在尋找一個更方便的策略/擴展讓可視化編輯器體驗增強的功能。
    • 短期內的方案是減少對媒體文件的引用。
• 可視化編輯器雖然支持複製粘貼上傳圖片，但需要多步驗證；雖然可以通過插入html來插入圖片，並複製粘貼現有元素、修改參數，可以應對絕大多數單純插入圖片的需求，但其不屬於mediawiki內資源，便無法實現如cargo等特殊功能的匯總並展示海報的需求^{（或許可以，但要自己造輪子）}；
• 其嵌入外部圖片、youtube等平台視頻都是要通過模板、html代碼等方式實現，而這是可視化編輯器的劣勢，自然也是受其吸引的mediawiki的劣勢。

UI：

• 對手機等小屏設備訪問不友好。

性能的缺陷：

• mediaiwki的舊版本有些兼容性問題，一開始我踩的坑真不少，新版本兼容性好多了，不用考慮php^(支持7.4+)、mysql^(支持5.7+)版本什麼的了；
• 但是新版本的mysql^(8.0+)比較吃性能，本來mediawiki就不以性能著名，對於租低配置vps的個人玩家並不算友好，在我還是1c2g1M時，更新環境版本後，由於清理了數據庫，訪問速度是提升了^{（總體還是要1-3s）}，但是提交編輯有時會很慢^{（進入編輯狀態慢或保存很慢，久的能達到20s+，跟編輯量無關，可能是數據庫上的問題，如果是用的寶塔，低於2核是會提示不讓安裝mysql8的）}；
  • 在伺服器未變化的情況下，將框架從1.40升級至1.41，似乎提交慢的問題消失了。
• 不過SCIO系列站點現在取消任何計數功能了，之前有的時候也就是博客日IP 50-100，主站10-，WIKI未知但不會很多，所以抗迸發效果如何未知。

中性

編輯記錄：

• 保存所有歷史編輯記錄，前端也不是真正的刪除；
• 所有數據還都在數據庫，只是被刪除內容只能由有權限的用戶^{（管理員）}訪問和恢復，一旦產生大量垃圾數據，還是得通過一些插件/擴展清理；
• 清理所有記錄很簡單，但是針對性的清理就麻煩許多，且日誌目前仍舊不能刪除^{（創建和刪除頁面的日誌）}。

擴展/模板等功能：

• 默認支持的功能不算太強大，mediawiki需要調教才能用起來順手，否則只能使用一些基礎的文字編輯；
  • 這個看個人需求，但是就我來說，個人博客不只是文章創作，或者簡單的加個腳註貼個連結，還是需要很多高級樣式與功能插入外部資源的。
• 如果要進行調教，那麼wiki確實強大，除了豐富的官方社區及文檔外，市場佔有率導致的人口基數也是一大利處^{（如維基百科、萌娘百科等都基於mediawiki框架）}，抄作業方便；
  • 不過調用模板等高級功能都需要在原始碼編輯器下操作，雖然可以便捷的切換兩種編輯器。

個人想法

自定義：雖然這不是為個人博客而創建的，但是我總覺得非常適合用來寫博客，不過除了「分類」外，是不會自動建立索引的，比如Wired世界開發進度中貼出來的文章，都是我寫完之後再手動加進去的，只是一切都在web端操作，並不麻煩。除此之外，它就是單純的一個由頁面組成的框架，想怎麼用，完全隨你。

歷史內容：在我看來，諸如typecho等博客框架，有一種感覺就是，舊的文章很難找到，一經發表就像離開了一樣，而建立索引的維護成本又非常高，在wiki中，得益於插入內鏈的便捷程度，非常適合做這種工作；以及常規的博客只適合單調場景，比如blog.scio.icu只能容納下unraid及相關的文章，像我在WIKI中寫的大量不同類別的文章，在普通的個人博客下很難分類與組織，會很臃腫與難以找到，並且需要變動時，編輯起來十分不便，而如果為其創建索引頁，那就是捨棄mediawiki所長用個人博客之短。

優缺點：我說了它很多缺點，是因為我在真正大量的、頻繁的使用它，而typecho，已經被我遺忘了。

mediawiki確實有一些複雜的功能，對於專業的wiki人來說似乎也是很適用的，比如用變量定義字符串，正文中需要使用該字符串時使用此變量，在編輯時或許並不比直接用字符串更簡單，但維護時卻更加的便捷與精確，但總的來說編輯時確實麻煩，一般的wiki人也不用，普通用戶更不用。更不要提模板、模塊、微件、擴展等等功能，它複雜的是上限和特殊功能，對於基礎的文字編輯不需要考慮甚多，可視化編輯器工具欄提供的功能夠我所有非折騰類文本創作使用，其他高級功能無非是圖個新鮮與玩個花樣。

總的來說，mediawiki適合文本創作、自己組織頁面，在文章篇幅較大、不同文章跨類別較多、文章數量可觀的情況下，mediawiki是非常適合的。而如果只是偶爾發一篇文章、很少後續維護、話題比較隨機、喜歡其他框架美觀的主題、對我認為的優點並不感冒、經常插入外部視頻或圖片，那麼mediawiki就不適合您。

但我不建議讓「我沒有那麼多好寫的」成為使您決策因素。你看我寫了如此多的字，但我在建設wiki前知道自己能有如此多東西可寫嗎？我不知道，我也難以置信，因為這是我累積的產物。我將那些本來或許要被拋棄的想法拾了起來， 它們有些確實被遺忘了，但有些自成一體了，wiki:小知識、Favorites:興趣博物館莫不是如此，整個Wired世界系列更是如此，就連OSINT項目不也是沉澱的結晶嗎？捕捉想法， 並給它一個機會。

我並不寫博客文章， 而是按照主題維護系列內容，所以傳統博客於我而言沒有任何優點，反而他們的優點是我認為的缺點。

　

Typecho

基本功能：基於markdown語法的個人博客平台。

優點：輕量化

缺點：編輯功能（半可視化編輯，非所見即所得。）

建議：適用於對組織內容沒有太大要求的用戶，按照簡單的標籤和類別制度進行分類，文章一經發佈很少去變動的情況下；或使用的場景(話題)比較單調，只是發表想法，不太需要組織內容的場景。

參考：https://blog.scio.icu/

　

其他推薦：

• wordpress：對於我的需求來說，wp插件很多，可以實現很多功能，很強大， 但有些臃腫，適合做論壇或商業化的站點，生活化的博客我個人不看好 。
• 您也可以通過中意的網站頁面底部的版權標識來得知其使用的架構/框架與主題，或者發給我，我幫忙參考一下。