在版模中，常會看見一些函式，卻不知道其如何使用。
（將 Discuz X版模內某段 //For Developer 的註解取掉，就可以看到這些Hook點）
這些點即是一個函式，由插件來操控（訂製這個點該發生的動作）

而核心也協助處理了一部分，所謂的「版模之前」的處理。
（開發手冊上對同一個 Hook 有兩種設置，就是另一部份藏在核心上……）

就這種構造看來，也許「運行」上的負擔會加重。
不過從另一方面來看，卻對往後擴充增加了很多幫助。
（如版模之前的處理，甚至能夠將某些變數再次處理呢！）

就某弦來看，這對開發者其實是很方便的東西。
畢竟，開發上的「時間」減少，而使用者安裝時也不需要「東改西改」
一方面減少使用者安裝失敗，又能夠加速生產。
就結果來看，確實是好的！
（不過說真的，就DiscuzX那多餘的新工能來看，很多人真的都用不上。）

大家可以試試看 Discuz 的嵌入點，還可以在檔案中找找看運作構造喔～
（打算考上大學之後，也來做做看這種 Core 呢！）

不過我是不在意這點啦！
因為我這個是雛型，根本就還沒深入製作呢！
能變多強大我自己不知道，但是我知道我肯定會做到「非常多功能」的程度。
雖然現在只能設定一台Server, 一個Package和開通/停用/刪除帳號而已。

不過我的目標可遠大呢！
我要做到什麼程度呢？
1. 用論壇幣收費，而且自動扣除
2. 可以設定多台 Server
3. 可以即時管理Package
4. 用戶可以自己選Server和Package
5. 使用特殊主題達成
6. 可以找回密碼
7. 可以批次管理
等等……

總之，我也不想屈就在這種程度的插件呢！
希望下次我發佈時，那位版主不會在說話了！

雖然下次發怖可能要等好一陣子了！
（畢竟我要強化更多功能～）

總之，想參觀的請到 Fate of Eternity 站上喔！
（只有前五位可以享受到所謂的「被開通」）

<?php

if(!defined('IN_DISCUZ')) {
 exit('Access Denied');
}

class plugin_amufqs {

}

class plugin_amufqs_forum extends plugin_amufqs {
 function viewthread_amufqs_output(){
 global $_G,$postlist;
 $wxfid = unserialize($_G['cache']['plugin']['amufqs']['wxfid']);
 if(!$_G['uid']){
 if($_G['cache']['plugin']['amufqs']['rd']==1 &&(!in_array($_G['fid'],$wxfid)||!$_G['uid'])){
 foreach($postlist as $id => $postvalue){
 $message=$postvalue['message'];
 if($postvalue['first']==1){$ah=$_G['cache']['plugin']['amufqs']['zlgd'];}else{$ah=$_G['cache']['plugin']['amufqs']['otgd'];}
 if($postvalue['first']<>1 && $_G['cache']['plugin']['amufqs']['otgd']==-1){$messageot=$message;}
 $message='<div style="height:'.$ah.'px; overflow:hidden;">'.$message.'</div><br><div><em>訪客無法觀看完整內容,請：<a
onclick="showWindow(\'login\', this.href);hideWindow(\'register\');" href="member.php?mod=logging&action=login">登錄</a> 沒有帳號？<a onclick="showWindow(\'register\', this.href);hideWindow(\'login\');" href="member.php?mod=register">'.$_G['setting']["reglinkname"].'</a></em></div>';
 $postlist[$id]['message']=$message;
 if($postvalue['first']<>1 && $_G['cache']['plugin']['amufqs']['otgd']==-1){$postlist[$id]['message']=$messageot;}
 }
 }
 }
 }

}

結尾不加上 ?> 似乎是某種新習慣，我不太瞭解就是了……
除了一貫的檢查是否在Discuz中運行外，緊接著的就是「物件」的概念。
不過充其量，也就只是建立物件，然後給Discuz調用。

因為是針對討論區的部份，所以物件建立完畢後，就放著（望
緊接著建立繼承父物件的子物件（加上_forum對論壇）

因為插件是限制「訪客無法觀看完整文章」所以就出現所謂的 viewthread_amufqs_output 函式。
函式影響Discuz的相關資訊可以參考開發手冊，上面有內定義的列表。
加上 _output 是在輸出前處理，這點算是程式開發的好習慣運用吧！
*一般寫網站用程式，為了版面和運算分離，會有運算區和輸出區。這點在Discuz就是很明顯的例子 *include temple(‘xxx’) 這類語法

中間的運算過程就不用討論了……
其實這樣看來，原本需要去修改 viewthread.php 才能做到的事情，現在只需要一個PHP檔案就完成。
在開發者的角度來看，可以說是「方便」至少不用做教學說明和修改多個檔案了！
而在使用者的角度來看，可以說是「簡單」畢竟除開發者造成的Bug之外，安裝上不會出錯。

雖然 Discuz 7.2 / X 還有一部分插件需要手動修改，原因我也不清處。
不過可以確定自從 7.2 的 NC 開始被運用後，開發插件容易很多。

尤其是許多「修改版模」的零碎處理。
在這方面，原本看到眼花的程式碼，用程式就能解決，是非常「使人愉悅」
畢竟很多麻煩都沒了！而且NC在許多功能也有輔助到開發者，可以說是「輕鬆愉快」
而之前在Discuz 的 APP 網站上看到 Discuz X 還能直接新增後台選單。
看到這點，讓我感受到Discuz對開發者的友善。
（在7.2的時候我還得自己去修改後台選單呢！）

不過多用戶Discuz是否會因為DiscuzX而隱沒呢？
這點我就不得而知了！
畢竟類CMS論壇提供多用戶版本，消耗的資源挺可觀的，開發的難度也相對升高。
也許有時間我會去研究個「DiscuzX多用戶論壇獨立版」指針對論壇部份開發呢！
（當然，那是我考上大學之後的事情了……）

NC的改變對我影響很大，因為讓我更加的自由開發。
（比起phpBB我倒是很喜歡Discuz這點）

於是，計畫馬上改變，全力投入 Discuz! X 行列。
可惜，官方一直不肯公佈下載點。

有人推測 6 點，有人說今天不發布了！
不過，我是相信官方的誠信，畢竟人家是間「公司」
不過，和我推測的 5 點左右，已經開始有落差了！

不過我現在認為，大約7點後就會發布。
不過，到底Discuz! X 有多肥呢？
這就讓我很好奇，畢竟上傳個Discuz得花很多時間阿！

不過，比起這些還是「有可以下載」最重要了！

希望 NC 會有對 X 的文件，不然我想開發更多可就頭痛了！
（說真的，這次Discuz! X 的預設風格很好看呢！）

首先是特殊主題，這部份有點「妙」
首先，在 class 檔的格式似乎有要求，前面幾次因為我沒依照格式而發生錯誤。

接著，當我成功撰寫後，卻遲遲無法使用。
光是這點就讓我殘念到死了……

不過後來還是成功的在「版塊」設定打開了，但是仍然沒有反應。
最後，竟然是「用戶組」沒有設定，這點可是一個大大的盲點。

不過，最後還是成功的使用了特殊主題！

接著，今天我又繼續研究頁面插入。
除了預定的點之外，其他的插入方法其實非常妙。

其他想在不存在的點插入，竟然是「把變數加東西進去」
這部份真的很妙，許多的變更都是這樣改出來的！

不過也有缺點，因為要配合預設的方式去更動。

不過到最後我卻發現，原來一個插件最多兩個 class 檔案。
一個是一般的插件，另一個是特殊主題。

原因，簡單到讓人會忽略。
因為「插件唯一識別」只有一個！

不過整體而言，新核真的超棒、超好用。
（尤其是避免使用者改錯，還有開發完畢後上傳不需要重改等等。）

大家也試試看吧！
雖然一開始可能會抓不到，不過挺好上手的！

不過也不能完全這樣否定，因為有些地方真的很細膩。
不過要說罪魁禍首，大概就是目錄的關係。

此時，我就想起 XOmultibbs 的設計上，為什麼要使用絕對路徑了！
因為「路徑有差異，所以無法正常顯示」

當了解到這一點的時候，我倒是做了許多修正，才能夠正常使用。
不過也不只這些，累積到目前為止，有5個錯誤被我認定有效。

大多是我預估之外的錯誤，所以還是很感謝大家能幫忙。
而在運作方面，跑在虛擬主機上，平均運行時間少了 0.02 秒。
和我這台電腦跑出的 0.04 秒比起來，有更快的效果，讓我為運行速度過慢這個問題鬆了口氣。

不過在準備動作時，卻花了我挺多時間。
我想，大概是「WildCard」的關係，與之前設定法有差異。

不過還好最後是有成功，不然我可要頭痛了！
因為 WildCard 效果有出來，不過只有一次，之後又會回到 cPanel 錯誤頁。
不過最後還是靠 Google 的力量，處理完畢。

現在就等 Bug 回報，直到「錯誤極少，運作正常」的狀態了！

但是，在「論壇資料」這方面，倒是讓人「退三部」。
各位也知道，我開發的是緩存與資料庫分離的版本，因此每次新增論壇都要運行一次資料庫處理。

而我的這種方法，和直接複製的作法有一個差異。
那就是，我需要詳細設置資料庫的變化，否則會有很多問題隨之出現。
(另一方面是因為我支援多個資料庫，而非單資料庫。)

如果是複製的版本，只需要用官方的處理法處理資料。
而因為我要對各資料庫統計、整理以免過度混亂。

因此我需要新增資料表、更新資料、加入新資料。
比起複製，我的動作又更加複雜。

而我的處理是以插件方式，還必須捨棄掉 Discuz 自動清空資料庫帳密的設定。
雖然我不認為安全性影響會太大，不過仍是有風險在裏面。

當然，我更不想將資料庫帳密存在插件設置中。
因為這個會讓風險更大，因此我放棄了這種作法，而選用風險較低的處理方式。

以目前情況，插件的雛型已經完成。
今晚會正式上傳至虛擬主機，並且開始「正式測試」

希望之後的測試別出現太多問題，不然我真的會「昏倒」
而且，這次開發成功後，之後可以說是「麻煩減少」

原因在於每次更新，許多語法會沿用。
所以原本套用的很多東西都可以繼續使用，而不需要重新開始。

那麼，祝我好運！

差異在哪裡呢？
1. 輸入網址之後，系統會判斷是否存在資料庫中，如果真則修正路徑、資料庫資訊。
2. 網址獨立，不受影響。

不過說真的，目前仍有「未知錯誤」存在於系統。

就像是 Archiver 就是一個例子，
其獨立在Discuz控制範圍，自己形成一個小型的系統。

因此在修改上，需要對其做支援，否則就無法使用。

另一個錯誤是api資料夾中的 uc.php , dbbak.php 等等。
原本使用GET時，還可以手動切換。

現在改為使用資料庫時，就需要特殊的處理，否則就不會正常。

之後還有意將部份資料改為 Cache 方式儲存，減少系統資源消耗。

目前的完成度看來，其實Discuz多用戶化並不難，只是很麻煩。
也許過去一直把麻煩和困難重疊，所以才會覺得很難成功。

實作之後，卻發現其實還好。
不過有一部份也是 XOmultibbs 的功勞，因為它啟發了我一些新的思考方式。

不過，還有一個大問題 – 快取
這要怎麼說呢？

其實 Discuz 幾乎是建構在快取之上的，因此運行品質良好。
從用戶組、文章等等，都有被快取的痕跡。

大家必定會對此有疑惑，為什麼是最大的問題呢？
原因在此，假設我選取A資料庫的時候，就會在forumdata建立快取檔案。
此時，我想選取B資料庫時，打開來卻是A的資料。

為什麼呢？
因為A資料庫的快取沒有被去除，因此顯示的是A的資料。

此時我們該怎麼辦？
很簡單，幫每一個資料庫建立專屬的快取資料夾。

聽起來很簡單，不過實際上有許多難題呢！

1. 檔案數量多，需要大量修改
2. 檔案中為forumdata的字串並非純路徑字串(還有資料庫查詢)
3. 部份檔案沒有引用include/common.inc.php檔案(有控制外的情況會發生)
4. UCenter以及其他API整合問題

以上4點，都是快取衍生出來的難題。
今天，我將會嘗試處理，也希望能夠處理成功。

雖然使用全部取代來減少工作量，不過仍有錯誤。
(變數生命周期，某些地方變數無法引用，需要使用全域變數等等……)

今年寒假，的確挺充實的！
(不過我似乎充實錯地方了呢！明明剩一下一年不到要學測了……)

仔細一看，其實並非特別困難的原始碼。
如果好好的「修改」其實很快就能使用。

不過仔細想想，事情會這麼容易嗎？
其實也不盡然，因為其中還有許多奧妙之處呢！

1. 我未曾接觸過的多個資料庫聯接。
> 在技術實現中，有多次是中途開啟資料庫的！
2. 許多曖昧不明的處理痕跡
> 如附件，真的就讓我不知道該如何是好。
3. 新舊版本的眾多差異
> 如果6.0還好，現在可是有7.x呢！
4. 暗藏的各種秘密
> 沒也不知道作者偷偷藏了什麼，得慢慢找出來。

看似簡單，實際上又是困難。
不過我想，最基本的複合論壇技術，我倒是可以製作出來。

而申請、問題的處理等等，就是一個難題了！
例如：插見的安裝、廣告的強制設定等等……

不過，一切都是「好的開始」
真期待我自己製作出來的 多用戶 Discuz 呢！