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，本文所述方案不一定對你有用，但可提供一個思考的方向。