某社区打算升级 discuzX3.2，不过据说原来的录像解析插件升级了之后不能用了
于是我自发的去帮了一下他们，顺便看看他们的解析是什么样子
本来以为他们的录像解析是以插件的形式嵌入论坛的
直到我开始分析他们的源码．．．．．．
我去，居然直接改 discuz 的源码！
而且没有任何的修改说明，代码东一块西一块零零散散的，光是找相关代码都要找半天，真是无语了 = =
于是我打算把原来在 X2 中的修改源码的形式改成在 X3.2 中的插件形式
上手照着 google 那些入门教程写了写，然后了解了一下里面插件的嵌入方式
弄着弄着，渐渐地开始体会到了 discuz 这整个架构的庞大与沉重．．．
这时我仿佛看到了当年的 ENIAC（世界上第一台计算机）．．．
TMD 论重量级，跟 Typecho 简直一个天上一个地下啊！！！
Typecho 数据库的所有表加起来才 8 张
而 discuzX2 的数据库表加起来却超过 200 张，升级到 X3.2 后更是超过了 300 张！我的天．．．
再说说弄这个录像解析插件的曲折之路吧．
刚开始，根据 discuz 的资料库，看到了 viewthread_attach_extra 这个注入点
这个函数应该返回一个 array，在 discuzcode.htm
但问题来了，这个返回的 array 中应该是什么格式？包含什么样的内容？
文档里面完全没有相关资料，在网上搜更是有人直接 return array(1, 2, 3) 的 = =
于是我打开 discuzcode.htm，到里面去找答案，原来是要返回一个 aid 附件表
可是我完全不知道怎么获得这个 aid 表．．．于是纳闷了，搞半天，最后只好放弃了这个方案，换种思路
接着试了 discuzcode，然而还是附件信息不足，无法解析成功
既然找来找去，没有好的 hook 点，也就只好被逼着改点源码．造一个 hook 点了
可是 DZ 这么大的架构，要怎么驾驭？？？试过 echo，var_dump，啥效果都没有．．．
这可怎么调试．．．于是去网上搜各种办法，才知道每次修改 php 之后都要清缓存才行
而且发现了两个很重要的函数1
2showmessage("要输出的消息");
debug($ 变量);
这样终于可以调试了，于是修改了 function_attachment.php，在里面遍历附件并显示的地方嵌入代码
这下一改，一下子就解决了附件信息不足的问题．而且可以做到尽可能少的改 DZ 源代码
最终决定．整个插件的思路是这样的
先写一个插件包，把原来 X2 中旧的录像解析，里面跟 DZ 黏在一起的部分的代码分离出来
然后写一个 replay_tool.class.php，作为一个嵌入的标志，全局性的把录像解析的 css 样式放到 viewthread 页面的顶部
在 DZ 的 admin 后台引用这个 replay_tool.class.php
然后在 function_attachment.php 的显示附件部分，嵌入自己的代码
通过全局变量 $_G 判断插件是否已经启用1
in_array('replay_tool', $_G['setting']['plugins']['available'])
如果已经启用的话，就开始引入 source/plugin/replay_tool/core.func.php，并执行里面的 resolve_replay() 函数
这样就实现了论坛附件录像解析的功能，
最后感叹一下，大的架构真的是不一样啊．虽然 discuzX3.2 不是什么新东西了．但里面的架构思想还真是让人印象深刻．
源码已上传至 Github