Category: WordPress

WordPress在中国为何不温不火？

这篇文章主要是梳理下我自己的想法，如果你有不同的看法欢迎留言交流~

我个人觉得有下面几个核心问题。

一、中国的大环境并没有为GPL的开源模式做好准备

这一问题是国情和大环境所致的，短期内没有改善的可能。

其具体产生的影响主要是以下两点：

1、本土生态资源匮乏

wordpress.org的应用市场强制只能上架GPL应用，这导致中国的开发者不得不构建自己的私域流量，对于没有流量积累的小开发则将举步维艰。

开发者的匮乏直接引发了恶性循环：没开发者->没生态资源->用户因此而排斥->没开发者。

幸好WordPress有丰富的全球生态为我们补血，这才能在生态这一环多少进行一些弥补，这也才没让WordPress在中国很快凋零。

2、中文翻译匮乏

极少有公司愿意付出成本让自己的雇员带薪翻译WordPress生态资源。

这些生态资源几乎都是靠某些插件的用户因为自己用到了所以才会去顺手翻译，而对于文档这种自己用不到的东西则完全没动力翻译。同时我们统计，目前wordpress.org上的插件和主题的汉化率仅为7.8%，仍有高达400余万条原文等待翻译。

二、WordPress错过了中国以微信互联网为代表的公众号、小程序体系

这一问题比应用市场更加无解。

因为wordpress.org是不可能为了中国这1%的用户专门为此提供支持的。这不是坏不坏的问题，而是投入和产出比严重失衡。

未来PC端网页整体市场占有量会越来越低已经是不可逆的趋势，传统APP在中国因为小程序的异军突起而干扰了其在中小企业中的应用，而WordPress的用户群恰好也是中小企业。于是对于WordPress来说，通过APP来拥抱移动互联网，在中国几乎是死路。只有小程序和公众号才是唯一通往移动化的可能。

WordPress的市场很小，为什么值得投入精力

我想起来几个月前找开发人员的时候，听见最多的观点（或是叫嘲讽）就是：不要把WordPress说的很牛逼，这是很落后的东西了，大公司没人用的。随后就是类似大并发、微服务、SpringBoot等等的概念和名词。

他们说的其实是对的，WordPress的架构还是十多年前的，不谈什么分布式之类的，就单说单体架构中流行的MVC设计模式WordPress都不支持。模板引擎也没有，都要自己手工在HTML里面嵌入PHP代码。当然这里提到的MVC和模板引擎甚至于分布式架构在WordPress中都有相应的解决方案，只不过是第三方的。

WordPress的应用领域也确实是中小公司，大公司没有用它来做核心业务的。

这些说的都没错，都是WordPress的弱势，但却忽略了WordPress的优势——近乎于垄断的全球CMS市场占有量、完善的生态体系，以及中国市场下的萎靡不振。

以上三点合起来就是机遇。

为什么WordPress在国外可以近乎垄断，但是在国内却萎靡不振？如果解决了这个问题，那么依托WordPress近乎变态的生态储备也许就可以在中国复制其在全球市场的成功。

同时WordPress是GPL 2.0协议授权的，法律上的障碍也近乎于没有。

但即便复制了成功，在web 2.0的末班车上，留下的市场增量空间还有多少呢？

这个问题我觉得得分成三点来看 ：

  1. 一个人很难一步登天，仅靠一个idea或一个项目就实现自己的理想，更多情况下要靠一个又一个跳板去往上跳，而每个跳板则可能都是完全不相干的项目。这其实并非是不想，而是存在一个叫“资源边界”的东西在限制着每一个人。就好像井底之蛙一样，如果他不先跳出井口，他怎么会知道大千世界都有哪些机遇？于是现在，有一根绳子从井口伸了下来，我想顺着绳子爬上去，想去看看外面的世界，然后一群其他的青蛙在嘲笑：你就这点儿志向？我们是想直接吃到一只天鹅，而不是和你一样爬到井口舔苍蝇。
  2. 这将为我打造一个根据地。所谓人穷志短，我很难相信一个人在持续的贫穷中可以坚持远大理想。当然，或许有神人做到了，但那肯定不是我。况且一个企业需要很成功吗？不需要呀，哪怕能服务好100个优质客户，就可以活的很滋润了，并不是都要像滴滴一样垄断全国的网约车市场才能好好活着。于是，如果这次成功了，我打下了自己的根据地，那就可以以此为根基别做良图，就像前一条说的，人生是踏着一个个跳板上去的，而不是一步登天。
  3. 一个一无所有的普通人，究竟是类似17年的共享单车这种巨头重重且重资产的行业的机会大，还是类似WordPress这样市场需求存在，且有天赐之机遇，但巨头看不上的市场的机会大？或者不谈机会，就只说：一个普通人在哪个战场上能最基本的生存下来？

以上三点总结一下：对于一无所有的普通人，得先有自己的根据地，然后以根据地为基础一步步向上跳，每次起跳都是一次资源边界的突破，换来的是更广阔的眼界和格局。而WordPress提供了这第一跳的可能。

理想可以远大，但是具体执行方案还是要务实为主。

bbpress批量删除垃圾帖子

当垃圾帖子上万之后，在WordPress后台删除显然就不现实了，于是直接执行SQL删除之：

DELETE FROM wp_posts WHERE post_status='pending'; # 删除所有待审核文章，因为bbpress是在post表里保存的帖子内容，所以此操作会删掉待审核的帖子
DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL; # 删掉孤立的帖子元信息
DELETE tr FROM wp_term_relationships tr LEFT JOIN wp_posts wp ON wp.ID = tr.object_id WHERE wp.ID IS NULL; # 删掉孤立的term绑定信息

WordPress文章数量10万以上时文章编辑器卡死的解决方案

这个问题来自对post_meta表的一个慢查询：

SELECT DISTINCT meta_key 
FROM wp_postmeta 
WHERE meta_key NOT BETWEEN '_'
AND '_z' 
HAVING meta_key NOT LIKE '\\_%' 
ORDER BY meta_key 
LIMIT 30

该查询由WordPress文章编辑器的Meta Box功能发起。

该问题的原因是MySql中普通索引的长度最长为767字节，如果使用的是utf8mb4编码的话，那么总的字符长度就是767/4，约为191，而WordPress的post_meta表的meta_key列的字符长度则是255。

所以此时因为meta_key的长度超范围，索引并未生效。解决方案可以选择把数据库编码更改为utf8或是将meta_key的长度更改为191，再或者是禁用掉Meta Box功能。

当然，提醒一句，这些更改都可能会破坏兼容性，所以更改前请务必做好测试工作。

最后，导致性能问题的原因千奇百怪，具体情况要具体分析再针对性解决。so，本文所述方案不一定对你有用，但可提供一个思考的方向。