WeiPHP4.0使用调试心得
第一部分 说明
WeiPHP是一个基于ThinkPHP实现的微信公众号和小程序后台管理框架
第二部分 获取程序
官网和git上都有下载
git下载链接为：https://coding.net/u/weiphpdev/p/weiphp4.0/git
第三部分 程序安装
安装部分比较简单，将源码解压之后，搭建web服务器，运行 http://你的网址/index.php。按照提示一步步完成，安装过程中会检测PHP版本，官网说明PHP版本号需要在5.5以上。
其中最后一步是创建数据库和创建管理员账号
如图所示，数据库部分填写数据库的root账号以及密码。创始人信息可以随便填，但是这个账号是管理系统管理人的账号密码，请务必记住。
这一步中数据库账号信息如果填写准确一般是不会有问题的。数据库安装完成之后则安装结束，下一步就可以访问首页了。
第四部分 配置公号
进入首页之后，首先需要做的是配置公众号，我使用两个公号进行测试，一个是个人的订阅号，另一个是微信的测试号。配置后的页面信息如下：
表单中公众号17是个人订阅号，16是测试号。
点右上角的“新增公众号”可以进入新增公众号界面。
如上图所示
1、“公众号类型”一栏有四个选项，我的个人号是“普通订阅号”，测试号则选择的是“微信认证服务号”。
2、“公众号名称”一栏其实是可以随便填写的，但是我填写时是和微信公众平台中的配置保持一致的。
3、“原始ID”一栏的信息比较重要，我在调试时曾经就在这里坑过。首先如上面的图示可以看出，原始ID一栏填写的应该是以“gh_”开头的微信号。我在调试时首先填写的是“wx_”开头的AppID，这就造成我在后面调试自动消息回复时，服务器始终返回 “404 Page Not Found”。这就很坑爹了。作为一个web开发的菜鸟，我开始抓包，看日志，跟代码，发现程序使用数据库中的token查找微信接口权限时整失败了。而这个用于查表的token是从接受消息的“ToUserName”解析出来的，数据库中的token就是这个原始ID，所以，我重新用这个解析出来的“ToUserName”配置原始ID，发现消息自动回复功能成功了。然后继续查下去，发现，这个原始ID在公众号平台的公众号设置页面中的最西面有显示，而测试号管理页面的最右上角也有显示微信号。
填写完成后进入下一步，会显示如图所示的URL和Token信息，用于填写在公众号配置中的服务器配置中
再下一步就是填写AppID、AppSecret、AESKey。这三个值在配置中心的开发->基本配置中找对应的字串就可以了。
然后点击保存，至此，公众号配置就完成了。点击“进入管理”就可以配置公众号功能了。
第五部分 接口检测
按照WeiPHP官方的教程所述，公号创建成功之后需要先检测接口。
我的检测结果如下：
第一节 个人订阅号
这两个检测失败项比较令人尴尬，原因待查。
查看wiki的错误信息(https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140183)有如下描述：
所以，重新设置AppSecret吧，设置时微信官方提示是一定要配置白名单的，所以，还是白名单的问题，我使用 http://ip.qq.com/ 查找IP地址，将IP地址填入即可。
完成以上修改后，接口测试全部成功。PS：虽然这里都测试成功了，但是手机端还是会显示js授权错误，猜测是由于个人订阅号权限的原因造成的。
第二节 测试号
后面两项检测一直卡住，检测不过去，此时手机端提示“js授权出错，请检查域名授权设置和参数是否正确”，点确定后又提示“redirect_uri域名与后台配置不一致，错误码:10003”，这两个问题待查。
后面，我做了如下设置之后，所有的测试项通过：
1、JS接口安全域名直接改为natapp映射的域名：tywkuu.natappfree.cc
2、体验接口权限表中的“网页账号”->“网页授权获取用户基本信息”中的回调域名natapp映像域名“tywkuu.natappfree.cc”
3、natapp的端口改为80端口，即将IIS中的网站绑定端口改为80
以上第1条修正js授权出错，第2、3条修正redirect_uri错误的问题
第六部分 功能调试
第一节 公众号功能
公众号功能部分有如下图所示中的选项的功能
上文已经提及，在调试的过程中，因为原始ID一项填写错误，导致出现404错误。这个是一个重点。
1、自定义菜单
自定义菜单只有在测试号中才能测试其功能，个人订阅号是无接口权限的。
我在调试时设置的自定义菜单如下：
目前有以下几个问题没解决：
1、获取图文->图文素材 这里可以获取到图文素材，但是点击文章却无法在浏览器中显示，会提示“redirect_uri 参数错误”。
关于“redirect_uri 参数错误”，网上搜索了一下，说是URL或者IP地址白名单设置等问题。因为我搭建的环境是使用natapp做外网映射实现的。所以这里估计有问题，需要进一步调试。针对该问题，我将“网页账号”->“网页授权获取用户基本信息”中的回调域名直接改为我natapp映像域名“tywkuu.natappfree.cc”，发现图文可以在浏览器中打开，查看了其链接地址为“http://tywkuu.natappfree.cc/index.php?s=/w16/Home/Wap/news_detail/id/188.html”。此时可以正常访问了，以前无法正常访问时的链接地址是
“https://open.weixin.qq.com/connect/oauth2/authorize?appid=wx0e5120106c01e7ed&redirect_uri=http%3A%2F%2Ftywkuu.natappfree.cc%3A8254%2Findex.php%3Fs%3D%2Fw16%2FHome%2FWap%2Fnews_detail%2Fid%2F187.html%26&response_type=code&scope=snsapi_base&state=weiphp#wechat_redirect”。
可是，我把回调域名设置改回去之后，发现依然是这个可以正常访问的链接地址，很奇怪，我怀疑是否是因为测试号的相关修改有限制或者是有延迟啥的。后来，发现必须将natapp的端口修正为80端口。
2、发送事件->图片素材 这里无法获取到图片，没有任何提示信息。
这个问题在调试时，通过查看 Runtime\Logs\Home\xxxxx_SQL.log发现有如下打印：
返回错误码40007，无效ID
追根溯源，从添加素材开始重新操作一遍，在我添加图片素材时，从日志中看出有如下打印
“缺少多媒体文件数据”？WTF？
上网查了一下这个错误，有些大神说是通过该curl的配置解决了，具体的参考链接为
https://segmentfault.com/q/1010000007365200
于是跟踪代码，找到具体代码位置为：\Application\Common\Common\function.php 中 2729 行，修改如下
// modify by kapoo for add_material fail(wechat error code: 41005)
// 这段代码原本是注释起来的，但是注释起来之后添加图片素材会出错，上网查到一些PHP大神说是这个配置的问题
// 我用的PHP版本是5.6.30, CURLOPT_SAFE_UPLOAD 需要设置为false
if (class_exists ( '/CURLFile' )) { // php5.5跟php5.6中的CURLOPT_SAFE_UPLOAD的默认值不同
curl_setopt ( $ch, CURLOPT_SAFE_UPLOAD, true );
} else {
if (defined ( 'CURLOPT_SAFE_UPLOAD' )) {
curl_setopt ( $ch, CURLOPT_SAFE_UPLOAD, false );
}
}
// add end至于具体的curl的使用差异，可以参考如下链接 https://segmentfault.com/a/1190000000725185，后面再研究。
除此之外，日志中还有如下错误
The usage of the @filename API for file uploading is deprecated. Please use the CURLFile class instead就是说PHP5.6以上已经舍弃了@filename的方式来存储文件名，需要修改
\Application\Home\Controller\MaterialController.class.php 中 550 行，修改如下：
if (true) // this branch is added by kapoo
{
if (class_exists('\CURLFile')) {
//php5.6中的 不使用@
$param ['media'] = new \CURLFile(realpath( SITE_PATH . $path));
} else {
$param ['media'] = '@' . realpath ( SITE_PATH . $path );
}
}
else // this branch is origin code in WeiPHP4.0
{
$param ['media'] = '@' . realpath ( SITE_PATH . $path );
}到此，添加图片素材功能已经调通了，但是图片返回消息依然返回错误码 40007，继续调。跟踪代码之后发现很有可能是Cache造成的。后面再未修改代码的情况下，功能居然通了。
至此，自定义菜单的相关功能都已经调通。