從WordPress REST API到WordPress Compatible

去年底WordPress 4.7熱鬧登場,在諸多熱辣辣的新功能中,要算將WP REST API納入核心使得人人有REST API用,影響最為深遠了。這代表往後任何人只要實作了與此API溝通的app,自動就有像天上星星那麼多的WordPress網站是你的潛在用戶;討厭php嗎?理論上你可以用任何你喜歡的toolchain實作這個API,那些透過此API與WordPress網站溝通的app,自然而然就能用在你的網站上。(不過後者恐怕還要等使用者認證、授權等API穩定後才較實際)

其實這不是什麼新概念,所謂interface as contract的概念早在web前就有了,令人想哼起經典老歌:Everything Old is New Again:

之所以放在WordPress上好像鑲金了,主要還是『像星星這麼多』這件事,造成它不容忽視的影響力。看看那個知名的content injection漏洞吧!甫一露出就十幾萬網站爆炸呢 ^.<

像星星一樣,到底有多少?

在寫這篇的時候,w3techs的content management system使用分佈報告顯示,使用WordPress作為CMS的網站高達27.5%:

螢幕快照 2017-02-22 下午6.12.11.png

而且第二名與其差距不是幾趴而已,而是24.2%之多。那今日有多少網站呢?根據internet live stats,目前能追蹤的數量超過10^9,因此27.5%就有超過2.7億個網站。雖然說w3tech和internet live stats追蹤的網站集合極有可能不同,但在這樣的數量級下,個人覺得忽視無妨。

從WordPress API到WordPress Compatible

前面提到,這其實就是一個interface as contract的概念。這裡的contract就是一紙input -> output的合約,約定好後,我後端不必管你前端是JS還是mobile app,我前端也不必管你後端是PHP還是一隻猴子。有參與過提供local server讓front-end可以離線開發的專案嗎?差不多就是這個意思。

WordPress雖然勢力龐大,十多年來累積不少成就,但也有不少歷史包袱,例如你要用舊有的the loop來打造一個single page app theme幾乎是不可能的任務;要重新用更新的技術打造WordPress core也很艱困,畢竟面對的可是超過2億個網站。這就好像JS一堆很爛很莫名的feature,制定ES6仍然必須把『don’t break the web』放在第一位考量,與其刪去,不如鼓勵大家使用新的替代方案,期待十年二十年後deprecated features自然消失。

想像看看,如果WordPress core API發展成熟,替代了任何現有路徑,成為了最主要的與WordPress site溝通的橋樑,會發生什麼事?Theme developers、front-end developers、app developers等用戶端的開發者可以用任何喜歡的工具開發,而且產品立刻就有超過兩億的潛在用戶。Backend developers可以用任何喜歡的工具開發,而且自然而然就會有各式各樣的theme、各式各樣的app可以使用。

我個人認為這就是把WordPress REST API整入核心的真正意義:逐步發展這層『contract』,待其完備之日,WordPress就會從一個CMS進一步抽象成為一個CMS API spec。屆時『WordPress compatible』與否,對使用者的影響力可能會像以前的顯示卡有貼『OpenGL compatible』與否一樣強。而我們今日熟悉的WordPress,則會成為『以PHP + MySQL的經典WordPress實作例』;人們不再需要受限於此種實作,也就間接為過去的歷史包袱解了套。

這一天快到了嗎?

聽起來好棒棒,但個人覺得這一天還不會太快來到。首先,目前進入核心的只有content API,也就是存取posts / pages、comments、media libraries等等內容的API,目前REST API仍然只能用cookie authentication;沒有authentication / authorization API,應用的範圍就十分受限,以上WordPress compatible之類大夢是無法實現的。再來,就我所知範圍,擴充REST API並非下一個版本核心開發的首要任務,補上這塊缺片的日期便更加遙遙無期。

總之,從API-based theme開始吧!

api-all-the-things

要推動API完備乃至實現WordPress compatible,首先就是要有愈來愈多的WordPress API應用。考量cookie-based authentication的限制,個人覺得首選、也是最有價值的,就是API-based theme。在content API還是WP REST API plugin的時代,已經有一些不錯的實作例,例如Wallacewp reset theme。我還有看過把twenty-seventeen theme用core API重寫的實驗,可惜好像沒繼續做了,只剩下一個tweet中的一張截圖供人瞻仰。

改用content API開發theme,代表你可以大方使用React、Angular、Elm等時下最潮到出水的碗糕來開發;與REST API溝通較為自然的async data flow,也通常代表你的theme互動性更佳、有更好的使用體驗。而且你的程式碼架構不再會受限於the loop,可以自由使用你喜歡的方式來組織。

『呃?這是要我去寫JS嗎?』很遺憾,以現在的環境,JS儼然就是今日的web machine code,就算你用elm之類的語言,由於最終還是會compile成JS,懂些JS終究是好的。Matt Mullenweg也曾在2015年WCUS keynote說:『Learn JavaScript, deeply.』,明確呼籲WordPress社群是時候跟上這個擋不住的潮流了。我碰過蠻多theme developer是幾乎不碰JS的,所以我了解,這件事對很多人來說一點都不有趣。但我相信這一定是WordPress theme未來的發展趨勢,不趁現在一切尚未蓬勃發展前強忍嘔吐上手,更待何時?

廣告

2 thoughts on “從WordPress REST API到WordPress Compatible

    1. 今年WordCamp EU還特設了JavaScript workshop呢 https://2017.europe.wordcamp.org/2017/03/10/welcome-to-the-wceu-2017-contributors-day/

      Post Status最近也有一個podcast的主題是"JavaScript frameworks in a WordPress context": https://poststatus.com/javascript-frameworks-wordpress-context-draft-podcast/
      內容涵蓋了幾項在WordPress上套用JS frameworks常見的挑戰,例如routing和嚴重缺乏來自WP本身的支援等,值得一聽。

      Liked by 1 person

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s