使用筆記/雜項篇
這篇介紹一些沒有具體主題的小點。
郵件傳送
如果你沒有一個正經的付過費的域名和企業電子信箱，那麼事情會變得異常麻煩。你要自己搭建郵件伺服器，如果是免費域名和其他特定域名還得遭受被拒收的痛苦。自己搭建的郵件伺服器也會出現被他人不當利用的問題，實在是很難辦。
因此，還是建議你去搞一個企業電子信箱和一個正經域名，然後按照手冊填寫參數。
如果你沒有企業電子信箱，那麼其實解決方案也很簡單（但不靠譜）⸺用你的個人電子信箱。像你登入你自己電子信箱的時候要填寫的參數一樣，把這些參數填上，然後郵件就會神奇地透過你的電子信箱傳送出去⸺前提是你在帳戶設定裡面「允許本次異地登入」。除了你的個人電子信箱會被不當利用的風險以外，好像也沒啥。比如我站被100多位垃圾使用者註冊
個人電子信箱在近期已經越來越無法透過該方式使用，因為大部分商業電子信箱為了「安全性」開始放棄基本驗證，轉而要求使用OAuth。Outlook.com即便使用應用密碼也將無法由MediaWiki透過基本驗證登入。
SVG
總之SVG縮圖會出問題，不知道為什麼。有的時候這和PHP停用函數有關，有的時候和shell locale有關，有的時候和你上傳的SVG有問題有關。這類問題需要具體問題具體分析去解決，主要取決於看具體的報錯資訊。
PHP停用函數請自行查閱相關的文件，比如面板的話可能會提供相關選項，而最終停用函數設定都會在php.ini裡面。
Shell的語言與各大發行版有關，也請自行查閱如何組態Locale和生成Locale。
有的svg檔案可能不符合規範，導致計算出來的縮圖與原圖不符。這種情況只能怪svg自己。
好用的Gadget
從各大wiki上搬。維基百科有很多。我站的Special:Gadgets也可以看著搬。
Gadget有時會依賴其他Gadget。有的Gadget的dependencies裡面會指定類似於ext.gadget.<小工具名>的，這個時候要注意搬運完全。
好懶我不想搬運模板怎麼辦
首先wiki不能懶，不然不會有長進。
然後呢，這裡有一個$wgEnableScaryTranscluding。這是幹什麼的呢？沒錯，只要你的Interwiki設定的iw_trans有設定，那麼就可以透過跨wiki連結的方式呼叫頁面了！
聽上去好棒哦。但是首先並不是能呼叫模板這麼簡單，其次你的伺服器會爆炸（高開銷）。所以別想著偷懶啦。
其次，善用Special:Export和Special:Import。
LuaSandbox
LuaSandbox是一個PHP擴充程式。簡單來說，模組引擎切換到它會變快。
如果你使用的是寶塔面板，那麼很遺憾寶塔面板的PHP不支援自動安裝這個擴充程式。你需要查閱官網的資料手動編譯然後安裝到寶塔安裝的PHP的對應目錄裡面去，然後再啟用。如果不是面板的話按照文件來即可。
修改擴充程式生成的HTML結構
如果你有基礎的英文能力，那麼把代碼當作英文去讀，就能找到生成HTML的地方。
比如擴充管理員連結，內建的頁面Special:AdminLinks實在是太醜了，我就想著寫一個CSS和JS對其做一個徹底改造！
但是原本生成的頁面一個class都沒有寫什麼CSS啊……（直接按次序選擇元素是不好的。）
所以我就想著，我讓這個擴充生成的元素帶上class，不就好做了！於是我就去幾個php檔案裡面找了找，發現生成HTML的地方還算良心，有好幾處是簡單的字串拼接。我就直接拼上去了class。
但是有一個class有點難啃，用了一個MediaWiki內建的LinkRenderer。生成連結的第三個參數是標籤的HTML attribute，我就這麼改了。以下代碼是舊版的，新版只需要按照類似的方法把makeKnownLink等方法的第三個參數塞上一個代表HTML attribute的array就行。
/**
* Helper function for backward compatibility.
*
* @param LinkTarget|Title $title
* @param string|null $msg Must be HTML escaped already
* @param array $attrs
* @param array $params Query parameters
* @return string
*/
public static function makeLink( $title, $msg = null, $attrs = array(), $params = array() ) {
$linkRenderer = MediaWikiServices::getInstance()->getLinkRenderer();
if ( $msg !== null ) {
$html = new HtmlArmor( $msg );
} else {
// null
$html = $msg;
}
$attrs['class'] = 'adminlinks adminlinks-' . $title;
return $linkRenderer->makeKnownLink( $title, $html, $attrs, $params );
}
事情瞬間好了起來，我寫了一些CSS和JS之後，這個特殊頁面就能和Fandom的管理員控制面板相媲美了，真棒！
我修改的也包括SimpleBlogPage的一些結構。
有些計畫頁面比如隱私政策這種怎麼辦
抄。反正你自己大概是不會寫了。或者建議找律師。不在意的話也許可以找GPT。
抄也要注意wiki實際，不要抄的和實際wiki情況不符。
前端有什麼參考手冊嗎
有，MDN Web Docs（簡稱MDN，全稱為Mozilla開發者網路）。點擊這裡檢視MDN學習區。
統計資料不更新怎麼辦
編寫定時任務，讓合適的系統使用者執行php /path/to/mediawiki/maintenance/updateSpecialPages.php（新版本注意使用run.php實現）。/path/to/mediawiki/請換成實際的路徑。
此方法一般只用於大型wiki農場，因為這類網站的快取週期與系統預設不同。但是如果遇到了這種bug，這麼做也沒問題。
格式指導怎麼寫
相當一部分可以抄。
具體來說，標點符號用法、書面漢語指導，以及一些基礎的模板排布都可以借鑑著寫。
格式指導要與你wiki的實際內容相適應。如果不太清楚怎麼寫的話，也許你應該先擴充內容。
如何開發外觀
開發MediaWiki外觀在1.36版本後不再必須掌握PHP。只需要會CSS和一些Mustache語法就行。
有兩種方式入手，一是下載範例外觀（GitHub），一是使用外觀實驗室工具。後者更具有互動性，也更能幫助你了解外觀的製作流程。
當然啦，你也可以參考我的外觀Lakeus，它就是用後者生成並修改的。
外觀製作的常見問題反正也就那些，基本上你會遇到這些問題：
LESS與MediaWiki預處理
你可能不是很熟悉LESS。我也不熟悉。但是，使用預處理器可以節省時間增加效率，也還是推薦了解一下LESS的語法以及常見命名規則，不然就會像Lakeus一樣，命名十分混亂。
在自己的wiki上嘗試外觀，如果你的樣式代碼有問題，可能會出現一點外觀樣式都不載入的情況。打開開發者工具，找到對應的樣式檔案請求，就可以看到報錯。或者，你也可以使用Node安裝LESS工具，本地編譯一下看看有什麼問題。
MediaWiki還會幫你自動在介面使用RTL語言（從右向左書寫的語言，比如阿拉伯語）的情況下，把你樣式中的左右都顛倒一下。如果你的樣式表的一些部分是單獨對RTL（從右向左書寫）處理的，可以這樣繞過這個特性：
.rtl .toggle-list__list {
/* @noflip */
left: initial;
/* @noflip */
right: 0;
top: 0;
bottom: 0;
/* @noflip */
transform: translateX( 100% );
}
如果你打算使用CSS變數，那麼我建議在單獨的檔案裡面寫好CSS變數在:root裡面的聲明，然後把對應的LESS變數賦值為var()函數去呼叫CSS變數，在外觀編寫的時候使用LESS變數，透過import去載入對應的變數聲明。這裡也可以參考Lakeus。
自己想要的資料沒有提供/想變更Mustache傳入的資料
你需要掌握一定的PHP以實現該效果。具體可以參考我的外觀。
我的外觀使用PHP的地方主要是三點：解析包含參數的介面文字（比如根據傳入的數字改變顯示單詞的單複數），在Mustache模板中動態插入HTML，和讀取本地設定。
你也可以使用SkinJson外觀檢視預設傳入Mustache的資料。可以根據這些來自行讀取處理和覆寫相關資料。以「is-」開頭的都是布林型，「array-」開頭的都是陣列型，「data-」開頭的都是對象型，「html-」開頭的是你準備插入的HTML，「msg-」開頭的是系統訊息（介面文字）。
開啟外觀的回應式設計
如果你的外觀打算支援回應式設計，請在你的skin.json中找到並變更成類似下面的片段：
{
"ValidSkinNames": {
"my-responsive-skin": {
"class": "SkinMustache",
"args": [
{
"name": "my-responsive-skin",
"responsive": true
}
]
}
}
}
外觀特性
在你外觀的ResourceLoader模組中，可以設定features欄位，但是它可以設定的內容比外觀模板給出的要多。具體支援哪些請見Wikimedia的文件，或者參考Lakeus。不開啟這些特性可能會使你的外觀缺失一些大部分外觀應當有的功能。
當然，這些外觀特性實際上都是對應原版MediaWiki的resources目錄下的一些預製CSS/LESS/JS。如果你不滿意內建的東西，你當然可以另起爐灶，做完後關閉對應的外觀特性。
你會發現MediaWiki真的內建了很多的CSS/LESS/JS。要學會利用它們。
擴充程式相容性
官網說「應當是擴充程式去支援外觀而非反過來」，但是作為你的外觀，你當然可以獲得主動權。透過skinStyles就可以為其他擴充自己做適配了。此處也參考Lakeus和Citizen，一個是目錄，一個是ResourceModuleSkinStyles。
也有的擴充程式真的需要他人適配，比如SocialProfile的頭像部分。
z-index
範例外觀的z-index其實沒有按照MediaWiki的z-index規範。按照規範修改有助於擴充程式的相容性。
同樣，你自己設計的外觀元素之間也有可能打架。要時刻注意。
你可能會遇到的z-index問題包括Echo的通知，WikiEditor的編輯列，以及頁面內一些有語法突顯的代碼塊。
z-index自己的規則我就不贅述了，建議多讀讀文件。
開啟了變體轉換，但是搜尋引擎收錄的和變體選單內的連結都很長
如果你希望自己的站台在點擊變體選單時的格式和維基百科的一樣簡潔，請參考下面的步驟。
首先，你應該已經設定過了$wgArticlePath（文章路徑）。變體連結和此變數的設定差不多，只是變數名是$wgVariantArticlePath，並且多了一個參數用於區分變體。
設定$wgVariantArticlePath = "/$2/$1";，意味著變體連結的格式為/<变体代码>/<页面名>。和你設定文章路徑時一樣，你需要變更網頁伺服器的偽靜態設定。以Nginx為例，在Nginx設定檔中加入以下代碼到合適的位置：
location ~ ^/(zh|zh-hans|zh-hant|zh-cn|zh-tw|zh-hk|zh-mo|zh-my|zh-sg) {
rewrite ^/(zh|zh-hans|zh-hant|zh-cn|zh-tw|zh-hk|zh-mo|zh-my|zh-sg)/([^?]*)(?:\?(.*))? /index.php?variant=$1&title=$2&$3 last;
}
設定得當，一切就緒。
如何繁簡轉換<code>等HTML標籤內的文字
預設情況下，由於原始碼一般要保留其原始文字，MediaWiki不會轉換相關的內容（比如<code>與<pre>內的文字）。如果需要轉換，可以在標籤內部的開頭加入-{}-。
比如，原始碼內有以下內容：
{{cd|#''<命名空间>'':''<名字>''}}函数的文件名对应<code>data/''<命名空间>''/''<名字>''.mcfunction</code>。
則覆寫成：
{{cd|-{}-#''<命名空间>'':''<名字>''}}函数的文件名对应<code>-{}-data/''<命名空间>''/''<名字>''.mcfunction</code>。
比較特別的是，以空格（以下用 表示）開始的段落，MediaWiki會自動將這個段落包裹上<pre>。比如，原始碼內有以下內容：
'''[[命令/scoreboard|scoreboard]] objectives''' add <记分项> <准则> [<显示名称>]
則覆寫成：
-{}-'''[[命令/scoreboard|scoreboard]] objectives''' add <记分项> <准则> [<显示名称>]
請注意，有的長得像的標籤（比如<syntaxhighlight>）並不是HTML標籤，而是解析器擴充標籤。這些標籤並不適用以上方法，反而會在最終頁面中展示-{}-。目前沒有很好的方法讓其中的內容跟隨頁面變體（如果實在需要轉換，可以參考wzh:Template:lan，讓一部分內容跟隨介面語言顯示）。
想讓過濾器變更推播至近期變更
請向LocalSettings.php加入unset($wgLogRestrictions['abusefilter']);。
我能向這裡補充內容嗎
當然可以。不過如果自己不太確定的話，可以在討論頁說明。
| 主要頁面 | |
|---|---|
| 正文 | |
| 外部連結 | |