感觉目前的插件机制更像是适配composer包，是不是做成像discuz! X那样的插件会更方便一些
目前已有的插件都是适配composer包，更像是一个组件，不包含业务代码
如果包含业务代码，使用现有的插件机制开发会比较麻烦，做成像discuz!X那样会不会更方便一些?
比如做成这样子，安装的时候直接把插件复制到plugins目录下，卸载的时候删除了事,类似于多应用
看到一个不错的项目，可惜看起来停止更新了
laravel-plugin
1616 4 2
4个回答
相似问题
年代过于久远，无法发表回答
的确！～
目前webman插件面向的是开发者；这个本社区做比较合适！～
你说的discuz的应用插件面向的是站长或运营者；这个开发者根据具体项目来做更合适！～
个人理解！～ ^_^
如果把插件分成组件级插件和应用级插件，组件级的更像是现有的机制，应用级的更多的是包含业务逻辑，这样开发起来会更容易上手。现在逻辑把两者混在一起了，不论是开发还是更新卸载都比较麻烦 😞
稍候等官方后台出来了，就有了通用的
载体了。https://www.workerman.net/q/8414
我猜到时会有了各种通用的应用插件了。呵呵
不知道什么时候才能出来。。。出来之前只能先自己折腾了 :(
耦合太严重，不做成组件 雀氏，随便调用，就好像thinkphp3 ，在框架内用是ok。然而移植性呢，太过于依赖thinkphp。为什么 thinkphp6把所有功能都拆了，做成composer，你这不是在倒开车吗。
举个例子 以前有一个叫 thinkphpApiDoc的 目的是读取注解 然后生成在线web调试接口，原来就是放到application里，后来改成composer 替换度更高了，耦合解除了，开发者不必要关注组件内部了，只需要根据规范使用，或二次使用。
你说的是composer组件层面的，把框架拆分成各个组件当然没问题。我说的是应用层面的，含有大量业务代码的情况
就算是大量代码，你去看看discuz还是Flarum轻论坛.
https://bbs.kodcloud.com/
https://forum.aapanel.com/
阿里小站 用的也是这个论坛，这个论坛的亮点，所有内容都是组件化,composer，评论组件，用户组件，发布组件，附件组件，所以你想二开，只能去改composer包，或者自己新建composer，然后composer require
插件分为2种，一种是基础插件，一种是应用插件。
基础插件提供一些组件类的基础功能，开发者只要简单配置就可以使用，没有更改插件源码的需求。例如数据库插件、队列插件等。这种插件使用composer安装是非常合理的。
应用插件则更贴近于完整的项目，例如cms插件、问答插件等，开发者根据需要可能会修改源码，所以插件源码应该放到项目里。目前的插件机制也可以实现应用插件的安装，原理是利用插件自带的install脚本将代码拷贝到项目的某个需要的位置，比如cms应用插件拷贝到
app/cms下。目前应用插件还没有正式推广，有些方案还没确定，例如应用插件目录放在app下是否合理，还是同一放plugins目录？还有各个应用插件应该需要一个统一的管理后台，这个还没开始做。对！
应用插件应该需要一个统一的管理后台这个有必要，要不然不好统一开发标准！～ 我觉得！～那最终岂不是还要提出插件代码
个人倾向 plugins目录 不需要删除就可用
是的 这个统一管理后台很重要 希望早点搞出来 :)
应用插件若放在app/下，所有应用即为插件，都需要遵循插件的规范，可能会跟现有的应用有冲突，但以现有的webman应用方式应该会比较简单。如果放一个统一的plugins下，需要驱动插件的控制器，模型，路由，中间件，视图这些在插件中完全实现，这样可以做到应用和插件的分离，但会增加复杂度，TP是通过addons钩子函数实现的。
我认为，插件规范很重要，可以参考现有的系统方式，但也不用完全一样，可以使webman实现的后台管理系统的插件方式使用简单高效，不用考虑现有项目的兼容改造包袱。应该使新开发的项目去遵循插件的开发方式，以后开发应用即插件。
插件安装和卸载时管理菜单生成，数据库的导入和卸载，代码的迭代，数据库版本的更新，希望都能周全。
你说的是不是类似daoadmin这种做成saas容器（应用商城）的形式？
然后使用点坏心思 搞死一堆项目。哈哈 安全性 = 0