感覺目前的插件機制更像是適配composer包，是不是做成像discuz! X那樣的插件會更方便一些
目前已有的插件都是適配composer包，更像是一個組件，不包含業(yè)務代碼
如果包含業(yè)務代碼，使用現(xiàn)有的插件機制開發(fā)會比較麻煩，做成像discuz!X那樣會不會更方便一些?
比如做成這樣子，安裝的時候直接把插件復制到plugins目錄下，卸載的時候刪除了事,類似于多應用
看到一個不錯的項目，可惜看起來停止更新了
laravel-plugin
4個回答
的確！～
目前webman插件面向的是開發(fā)者；這個本社區(qū)做比較合適！～
你說的discuz的應用插件面向的是站長或運營者；這個開發(fā)者根據(jù)具體項目來做更合適！～
個人理解！～ ^_^
-
江月閑談 2022-05-29如果把插件分成組件級插件和應用級插件，組件級的更像是現(xiàn)有的機制，應用級的更多的是包含業(yè)務邏輯，這樣開發(fā)起來會更容易上手?，F(xiàn)在邏輯把兩者混在一起了，不論是開發(fā)還是更新卸載都比較麻煩 ??
-
-
耦合太嚴重，不做成組件 雀氏，隨便調(diào)用，就好像thinkphp3 ，在框架內(nèi)用是ok。然而移植性呢，太過于依賴thinkphp。為什么 thinkphp6把所有功能都拆了，做成composer，你這不是在倒開車嗎。
舉個例子 以前有一個叫 thinkphpApiDoc的 目的是讀取注解 然后生成在線web調(diào)試接口，原來就是放到application里，后來改成composer 替換度更高了，耦合解除了，開發(fā)者不必要關注組件內(nèi)部了，只需要根據(jù)規(guī)范使用，或二次使用。
-
-
admin 2023-02-04
就算是大量代碼，你去看看discuz還是Flarum輕論壇.
https://bbs.kodcloud.com/
https://forum.aapanel.com/
阿里小站 用的也是這個論壇，這個論壇的亮點，所有內(nèi)容都是組件化,composer，評論組件，用戶組件，發(fā)布組件，附件組件，所以你想二開，只能去改composer包，或者自己新建composer，然后composer require
打賞
插件分為2種，一種是基礎插件，一種是應用插件。
基礎插件提供一些組件類的基礎功能，開發(fā)者只要簡單配置就可以使用，沒有更改插件源碼的需求。例如數(shù)據(jù)庫插件、隊列插件等。這種插件使用composer安裝是非常合理的。
應用插件則更貼近于完整的項目，例如cms插件、問答插件等，開發(fā)者根據(jù)需要可能會修改源碼，所以插件源碼應該放到項目里。目前的插件機制也可以實現(xiàn)應用插件的安裝，原理是利用插件自帶的install腳本將代碼拷貝到項目的某個需要的位置，比如cms應用插件拷貝到 app/cms下。目前應用插件還沒有正式推廣，有些方案還沒確定，例如應用插件目錄放在app下是否合理，還是同一放plugins目錄？還有各個應用插件應該需要一個統(tǒng)一的管理后臺，這個還沒開始做。
-
-
-
-
-
小杰 2022-05-30應用插件若放在app/下，所有應用即為插件，都需要遵循插件的規(guī)范，可能會跟現(xiàn)有的應用有沖突，但以現(xiàn)有的webman應用方式應該會比較簡單。如果放一個統(tǒng)一的plugins下，需要驅(qū)動插件的控制器，模型，路由，中間件，視圖這些在插件中完全實現(xiàn)，這樣可以做到應用和插件的分離，但會增加復雜度，TP是通過addons鉤子函數(shù)實現(xiàn)的。
我認為，插件規(guī)范很重要，可以參考現(xiàn)有的系統(tǒng)方式，但也不用完全一樣，可以使webman實現(xiàn)的后臺管理系統(tǒng)的插件方式使用簡單高效，不用考慮現(xiàn)有項目的兼容改造包袱。應該使新開發(fā)的項目去遵循插件的開發(fā)方式，以后開發(fā)應用即插件。
插件安裝和卸載時管理菜單生成，數(shù)據(jù)庫的導入和卸載，代碼的迭代，數(shù)據(jù)庫版本的更新，希望都能周全。
