一般来说我们使用server酱或qmsg酱等第三方api来做评论提醒，最近在技术松鼠的文章中了解到可以通过企业微信的应用来关联微信评论提醒，这里主要提下几个踩过的坑。首先是wp原生的 get_option 函数并不能在没有加载 wp_load.php 核心文件的 php 文件中调用，需要先 include 加载 wp_load.php 之后方可调用该函数（此问题主要出现在调用后台设置数据时，因为把这个提醒服务做成可选功能了）其次是需要注意如果首次写入access_token返回值未NULL时，正确输入id/token后需要手动清除access_token.php中的变量才能正常返回值，解决方案是判断过期重新写入token的同时判断token是否为NULL（已反馈技术松鼠

Ps.

微信关联企业微信应用需要使用微信在企业微信（网页版）中的“微信插件”中扫描其二维码关注后即可看到微信应用，并同时接收该应用推送服务。

修复了valine评论通知几率错误问题，新增 pushplus 微信公众号通知接口（推荐，目前每日免费200条），修复lbms部分功能，完善wp后台设置体验，正在新增wp原生评论企业微信通知功能。

Ps.

目前大概这样，lbms还有标签连续删除问题没有修复。

目前已同步所有数据到一个leancloud应用内（防止cross-app跨应用重复调用/初始化导致的各种数据混乱及调用出错问题。注意nginx已配置跨域仍出现cors问题时多半是appid/key写错了）实现全站数据统一调用/及wp混用，完善了数据判断逻辑，修复lbms登录页存在的部分问题。

Ps.

此条信息发布自cms跨应用数据后台。

太头疼了这个问题，重复初始化导致不同的server_url加载应用数据混乱，可以考虑一下把数据都放一个应用里了。

Ps.

从控制台can not redefine就可以看出leacnloud并不推荐跨应用（cross-app）数据调用，始终有几率造成数据调用错误/混乱问题

场景：页面为page类型（后台已新建页面）时调用wp文章后出现$post变量被重写（page本身属于post，所以该问题会导致执行wp查询后的$post变量被更新为相关文章变量），此时只需要在执行wp查询语句enwhile循环标签结束后加上 wp_reset_query() 即可，此方法暂无测试翻页功能。

Ps.

不管页面以何种形式调用了文章数据后记得重置查询。

上次提到了该问题，目前解决方案：两套数据分别动态加载（dynamicLoad）avos依赖文件(av-min.js)，通过js将依赖加载到页面头部，并保持依赖文件不重名（包括参数）避免重复初始化。

Ps.

Ps.

若直接调用script标签会造成阻塞，无法完全加载评论组件。 问题解决了，原来只需要将av-min依赖在head头部加载并完成初始化一次即可！ 不再需要内嵌初始化或动态加载了..（前面一直纠结为什么来回切换加载顺序都不行动态加载到head头部就可以，这简直了）

继上次自动创建/删除分类页面同步后，完善了创建同步后的双向编辑数据同步，即创建分类后，编辑category分类时同步更新name/slug数据到page页面，反之亦然。

Ps.

目前存在提交更新后一直转圈（编辑分类/页面提交时），即数据已成功提交但不提示，问题暂时不清楚原因，后续再做修复。 0413更新：完善了双向数据同步中的页面删除同步分类。在使用了相关hook同步数据后admin-ajax.php始终返回500错误，页面数据提交成功之后无响应（偶尔跳转返回错误页面），但数据都正常提交生效，打算先搁置下（中途删了数据表一个term，幸好设置了自动备份数据库）相关hook查询站：https://wp-kama.com/ 官方文档：https://developer.wordpress.org/reference/hooks/

评论和页面数据分别储存在国内版 leancloud 不同的应用内，导致需要重复初始化 app，导致数据无法正常输出，控制台报错：Initializing LeanCloud Storage SDK which has already been initialized. Reinitializing the SDK might cause problems like unexpected cross-app data writing and invalid relations.

Ps.

想了下最好还是把数据放到一个应用内统一初始化

如题，首先这个问题基本无解，wp官方并没有为category类型提供评论选项，comment_template仅适用于post及page页面。目前的解决方案一：为category类型提供第三方评论（可使用 include_once(TEMPLATEPATH . ‘/comments.php’); 调用评论）。方案二：新建别名为该category别名的页面，此方案可使用 comment_template 调用评论，但当前页面已经由category变为page类型，无法再循环调用wp数据（此时可选备用方案，使用第三方数据库，也是本主题提供的另一选项），目前解决方案综合了以上两点：当调用category数据无法调用wp评论时，可手动调用第三方评论，亦可新建对应slug页面使用第三方数据库。注意：调用page页面内容时，无法调用对应slug的category数据

Ps.

一般主题不存在这些问题，分类文章页面都是分离的，不过我这边开发的时候因为使用了第三方leancloud的数据及第三方valine评论，所以需要考虑两套数据之间的切换问题。主要是当页面需要调用wp数据时，其页面类型必须为category，但矛盾的是category不能调用评论。同时，页面为category时又无法调用page中的内容（post_content），这导致了后台如果需要改页面说明还需要到源代码里去修改很不方便，所以目前的解决方案是：首先页面默认category状态（循环调用wp文章数据，一般为文章列表）关闭wp评论，但后台提供了第三方评论选项，开启后即调用第三方评论数据。其次页面为page状态（调用page页面页面内容，一般为页面说明内容，同时可调用当前slug别名相同分类别名的文章数据（不适用其slug存在相同模板的子分类））开启wp评论，亦可切换第三方评论，同时提供第三方数据库覆盖选项。所有需要调用wp文章数据的category分类均不能调用comment_template评论且无法对接其页面自定义内容；

一级以下分类均可随意变更页面类型调用数据（如页面为分类类型时可正常调用当前分类的template_comment评论），且不会误判页面类型

Ps.

这个问题有点坑，目前是做了类型切换提示的判断，不过不太方便，想下怎么搞这问题..

不知道是什么原因，同样是子域名访问（已加入leancloud api白名单）资源返回cors跨域问题，意味着所有数据都不能正常调用，目前正在处理该问题。

Ps.

这就有点坑爹了

开发到这步拖了很久，出现了个比较坑的问题：页面导航均由post类型的category输出（每个category分别使用不同模板），而每个分类页面中的内容都在php模板文件内导致更改很不方便，所以需要提供一个接口在后台像post文章一样随意更改，然后想到了PAGE页面，利用page的slug来查询wp数据库对应的category内容，即page别名（slug）和category别名（slug）同步，之后再在模板内添加查询代码即可完成数据更新同步。 问题来了，这时候想给page页面加一个评论（使用comments_template调用）却调用出了文章内的评论。所以当页面别名和分类别名重复的时候，wp默认会使用category模板（这一步调用其实没问题，因为前台基本看不出来，但相关数据调用会有很多问题，category和page的调用不一样），这时候我们再调用评论的时候就出错了。不过这些都还好，致命的是这种情况只出现在部分分类页面，也就是说还有些category和page别名冲突的也一样调用了page页面，将页面作为单独的评论页面正常调用评论，这就百思不得其解了啊.. 搞了很久才发现有些不冲突是因为category分类层级的原因，那些访问冲突slug页面正常调用评论的都不是一级分类！没错，因为博客有很多层分类，所以在调用的时候出现了偏差，属实有些蛋疼。

Ps.

现在的解决方案有把一级分类移到二级，以此类推，重新输出导航。还有个比较简单的办法，因为之前去掉了category分类目录，现在只需要把对应代码删了，然后在后台固定链接的分类前缀处填写“.”即可让wp自动区分category与page之间的关系（此方法在网上最常见，但仔细观察导航链接会发现那个.号依然存在于链接当中，即使能正常访问。所以另一个间接导致这个问题的原因就是WPML去category插件的原因，从根本上重写的category就导致了page之间的slug冲突。注意：当使用page页面时$cat变量将无法使用，届时分类模板中的部分post变量将无法使用，主要是在category中即使用了分类模板又对接了页面数据）... 暂行方案：删除wpml重写category规则 -> 设置分类固定链接为“.” -> 删掉不需要应用page类型的页面（删掉后默认使用category模板），至于导航链接中显示的“.”层级暂时无解（如果使用.后再启用wpml重写会导致page页面应用失效，需要删除wpml并取消前缀后重新启用“.”前缀）

上次那个问题没找到原因突然自动就好了，现在又出了一样的问题，一直以为是没匹配到文章模板（single-***）甚至去自定义了文章模板，但还是想到和跳转有关，毕竟把设置里固定链接改为?参数形式就可以正常访问每篇文章模板，再简单记录下这次问题记录。

Ps.

首先查看插件 WPML（去 category 插件）是否启用（需要提前清空functions内跳转category规则），再去配置 nginx 的配置文件（如果是宝塔就直接去伪静态栏目清空wordpress跳转配置文件并保存）清空跳转文件，之后再去插件启用 WPML，重新访问即可正常范围每个文章模板。

之前用的是 No Category Base (WPML) 插件实现去除 url 中的 category 目录，后面把插件内的代码搬到 functions 里之后进行了精简处理（仅保留了少部分），结果今天偶然一访问文章发现跳到首页去了，以为是 single 页出了问题，但什么都没改过，其他也都正常，折腾了一早上大半天才发现就是这个重写规则出的问题，之前试过把固定链接改为参数查询访问就没问题，一自定义就出问题了，而且换成.也没用，最后把之前所有重写规则重新放入 function 内后恢复了正常。

Ps.

这东西的确坑，原因也没找到，因为之前用的精简版完全没问题，突然出这个问题应该是最近更新了 wordpress 5.9 的原因。

修改了不同分类友链展示内容，更新了部分没有1：1的比例头像。

Ps.

变相减少了无效友链信息，简化信息展示。