關於 Drupal 8 JavaScript (&CSS) 開發的一些事 [ES6]

這可能是比官方更官方的指引 (簡單版) :p 歡迎傳閱 🙂

Drupal 8.4 版本以後,JavaScript 將有兩大項改變:

  1. 採用 Airbnb JavaScript Style Guide 作為 Drupal JavaScript 程式碼規範。在 DRUPAL 中稍有修改,個人建議緊記 Airbnb JavaScript Style Guide 就可以,不必強行花時間記憶,有需要時,通過 ESLint 查看錯誤。
    而 ESLint 的自動修復功能,大致上能解決大部份問題。[詳看]
  2. Drupal 8.4 正式開始使用 ES6 作為開發語言。[詳看]
    (如果你很熟悉 NODE 開發,直接看 /core/package.json 就可以,否則請留意以下)
    以後的開發步驟:

    1. 所有動作必需在 /core 目錄進行
    2. 安裝必要的 NODE PACKAGES
      如果你沒有使用 YARN:
      npm i -g yarn

      安裝必要 PACKAGES:
      yarn install
    3. 開發途中,可以透過以下指令監視檔案改變:
      yarn run watch:js
    4. 修改完成後,可以透過以下指令建立最後檔案:
      yarn run build:js

      亦可以指定其中一個檔案:
      yarn run build:js — –file misc/drupal.es6.js

      (更好的方法: https://www.drupal.org/node/2879072)

聰明的你應該會發現,DRUPAL 使用 BABEL 編譯檔案,同時使用了 babel-preset-env,也就是說,如果你的網站不支持很舊的瀏覽器,或以手機為主,你可以更新設定,編譯出更完美的 JavaScript:
https://github.com/drupal/drupal/blob/8.4.x/core/package.json#L37

另一方面,Stylelint 亦替代 csslint 作為 DRUPAL CORE 的 CSS Lint 工具。[詳看]

個人推測,這一步將大大改變現行模組及版型開發流程,還沒有使用過 NODEJS FRONTEND 工具的朋友,要花點時間學習囉。

搖擺不定的 Drupal

[這篇文章在 2014 年 3 月寫下的,一直想公不公開… 最近 (2017 三月) DRUPAL 社區發生很多事情,一些重要的開發者紛紛離開… 現在才發現,在近來事件前,亦有人被迫離開。亦有不少不再想留在 DRUPAL 而離開。]

DRUPAL 社區很多政策都搖擺不定,很多時候給予我的感覺是:  集中於某數位核心貢獻者喜愛,便可以,如果 DIRES 喜歡,必定可以。

舉些例子: https://drupal.org/node/1993334

因為早前 DRUPAL 8 移除了 IE8 支援,所以 HTML5shiv 並不再需要了。移除他是很合理的。

有趣的事來了,社區要先問 DRIES 意見,以下是他回答:

As far as I can tell, this library doesn’t get in the way of work being done, and does make things a bit better for IE8 users. If so, let’s leave it in for the time being and revisit it before the Drupal 8 release. I’ve added the appropriate tag.

(略譯: 如果這對 IE8 使用者好,暫時留下吧,待 D8 發佈前再看)

本來,這是很英名的決定。但是,你再回想…. 是誰決定殺掉 IE8 的?? 又是 DRIES。

從現況看,DRUPAL 8 己經不是純粹能不能顯示 “HTML5” 這麼簡單了,而是由上到下,很多 JAVASCRIPT 及 CSS 已經不支援 IE8。

我寫以上一段話時是 2014 年 3 月。待至 2014 年10 月,以下是 DRIES 最新回應:

Given that it is conditionally loaded, it really doesn’t really hurt anyone. I’d wait to remove this as too many people are still using IE8. Let’s revisit this when we’re working on 8.1.

結果,還是保留。我只能說 DRUPAL 8 己經傷了很多 IE 8 開發者的心,你根本沒有可能將一個如此的產品送上客戶手上去。這種令 IE8 看上去沒問題的做法 (在各種評論比較文章時,會多一個優點罷了),像是仁慈,但並沒有多大作用。這是一種誤導。

第二個例子: https://drupal.org/comment/6859824

在這主題,要選擇一個編輯器放進 Drupal 8。開始時選了 Aloha Editor,並花費了一段開發時間於此,後來才選上 CKeditor。

[註: 筆者參與上面主題討論,@droplet 是筆者。我是很個人地分享我的看法。]

在此選編輯器的事情上,我個人認為是 100% 由 Acquia (DRIES 的個人公司) 主導了,並選擇上 Aloha Editor ( Acquia 的人還寫了一份報告分析各編輯器 )

直到 @droplet (#69) 重提 CKEditor 新版本的時候,CKEditor 老大加入討論,計劃開始轉變。

這事實帶出一件很重要的事情,包括我個人在內,以及 CKEditor 的人,並不知道 DRUPAL 8 己經完全決定使用 Aloha Editor! ( ISSUE 沒有 CLOSE)

何時決定? 在那裏做的決定? 由誰決定?

Drupal 很多時候看上去像公開,但事實還是有很多並沒有公開交待的討論。大家都知道 DRUPAL 有 ISSUE TACKER 專門做針對 DRUPAL 的事,但奇怪的是,有些事情會在 DRUPAL GROUP / IRC / DrupalCon / 不公開的場合進行。這些政策會失去很多寶貴的意見。

[以上在 2014 年 3 月 – 10 月份寫下,而在 2017 年今天,Aloha Editor 早已宣佈停止更新。]

數月前,留意到 DRUPAL ISSUE TRACKER 有大量 ISSUES 加上了 JS 相關標籤,而且是來自同一實驗模組。程式碼鬆散混亂,仔細看看,都是來自 Acquia 公司的人員。

還有一些例子,想想,刪掉了。

 

 

後話,仔細想想,DRUPAL 在不斷複製 WORDPRESS 中功能,比如:

  • WordPress 使用 REACT 在 WordPress.org 及開源 WordPress 相關的 REACT 工具數月後,DRIES 開動引擎發表了數篇文章,談要不要在 DRUPAL CORE 使用 REACT 等等..
  • WordPress 4.x 強化版面設定工具並推出不久後,Drupal 亦有了一個 Setting Tray 實驗模組

不懂是巧合,還是直追趕上。只能肯定: 這不是創新。

 

中文自動完成在 DRUPAL 8 中得到改善

不知大家有沒有察覺,在新的 DRUPAL 8.2.4 版本以後中,在標籤 (TAG) 輸入中文,不再返回奇怪的結果。 不必要的 HTTP REQUEST 也減少了。

DRUPAL 7 / DRUPAL 8.2.4 以前:
返回一堆不相幹的結果

(感謝 @jungle 提供 GIF)

D8.2.4 以後:

(再次感謝 @jungle 提供 GIF)

這受益於瀏覽器的 CompositionEvent API,監察 IME 輸入與輸出。
(可以參考 VUE 開發者的文章:
http://blog.evanyou.me/2014/01/03/composition-event/)

再沒有理由不用上新版 DRUPAL 8。至於 DRUPAL 7,要 BACKPORT PATCH 很容易,新年有空的朋友,可以展示一下你的功力: https://www.drupal.org/node/2823589

(特別感謝 @jungle 的 REVIEW,JS PATCH 在 DRUPAL CORE 要一天內完成及順利進到 CORE,不常出現)

[必看] Drupal 自動化測試與 WebDriver

Drupal 8 引入了 PhantomJS 加強 JavaScript 與瀏覽器方面測試,亦大家曾嚐試編寫自動化測試,必定遇過頭痛的時刻。不單是你,比如 DRUPAL CORE 也花費大量時間去尋找與修復一些不是 BUG 的 BUG:

https://www.drupal.org/node/2773791
https://www.drupal.org/node/2789381

大家不會對 Selenium 冒生,Selenium2 配合 WebDriver,你將可以在各個瀏覽器進來自動化測試。你可以直接透過真實的瀏覽器觀察結果,這絕對提高解決問題效率,及取得更真實的結果。而 Drupal Core 將 PhantomJS 寫死了為唯一的測試引擎,這為你帶來前所未有的惡劣 DEBUG 體驗!

若然,大家想要 WebDriver 進入 Drupal Core,請進去以下 ISSUE 說點廢話,不愛說廢話,可以直接 FOLLOW! 緊記積穀防飢,即使現刻沒有使用,假若覺得提議不錯,請進去說點廢話:

JavascriptTests with WebDriver
https://www.drupal.org/node/2775653

廢話有時候是有用的!! 自已感覺良好的舉例,CKEditor 就是因為我的一句廢話帶回到 Drupal 8 (為求目的,不擇手段自讚 XD),否則就要使用已經消失的 Aloha
https://www.drupal.org/node/1260052#comment-6414400

我相信群眾的力量,SHOW YOUR LOVE!!

(請任意大量轉載)

 

找到第二個 Drupal 安全漏洞

想不到繼上一個安全漏洞後,半年內再發現第二個與 JavaScript 相關的漏洞。這是一個很輕微的安全漏洞,在 Drupal Security Issues 待了數月後,安全團隊決定可以公開討論。

漏洞:
@see https://www.drupal.org/node/2725255

這漏洞出現在 “Allowed HTML tags” 中,在 JS 中蠻普遍的 XSS 攻擊。當我們允許 HTML TAG 時,後台會執行驗證及與 CKEDITOR 設定。

document.createElement(‘div’)

Drupal 使用了以上 FUNCTION 處理 TAGS,不小心往裏面狂塞進食物,就會即時嘔吐的。這問題在早期的 jQuery 版本經常出現 (現在還是有點,只是難度較高):

jQuery(“<bad-js-code>”)

 

影響:
預設情況下,只有管理員能修改 “Allowed HTML tags” 設定。(但不排除任何模組在 FRONTEND 調用了關於此漏洞的 FUNCTION)

預防修正:
– 任何時候都不要給不信任的人大量管理權限
– 直接快速打上 https://www.drupal.org/node/2725255 內的 Patch A. (雖然… D8 硬硬地不要面地說半支援 IE 8….我相信不會有人使用 Drupal 8 還在用 IE8 吧? )
– 靜候官方安全發佈

 

消除 Drupal 8 Toolbar 垂直模式閃爍

我們是對客戶負責的開發者,讓客戶用得爽是我們的目標。我們絕不會是只生活在程式碼中追求不必要的 0.1 ms 後端效能 的不實際人士。對客戶的前端體驗是我們第一必須關註的。適當的時候進行正確的決定,做正確的事,比一切看不見的完美更完美!

繼 修復 Drupal 8 Toolbar 亂跳現象 發佈後,在 CORE ISSUE 又進行了三個月原地踏步。無止境等待,不會令我們停步,繼往開來,現在發佈了 2.0 版本,進一步修復我們所面臨的一切問題:

https://www.drupal.org/project/toolbar_anti_flicker

** 中文讀者若遇上問題,可以在此或官方 ISSUE 透過你熟悉的語言與我溝通。

修復 Drupal 8 Toolbar 亂跳現象

使用過 Drupal 8 都能感受到,當頁面載入後,會由上至下跳一小跳。

Drupal Issue:
https://www.drupal.org/node/2542050
(問題: https://www.youtube.com/watch?v=urZ02CLzrAU)

做了一個小模組修復這問題:
https://www.drupal.org/project/toolbar_anti_flicker

大家放心使用吧! 以個人經驗,Druapl Core 幾乎不會在半年至一年內修復.. (我還算保守估計了)

還有這裏:
https://notabluescreen.com/drupal-problem/

 

修復了一個 Drupal 安全漏洞

個人第一個 Drupal 安全報告,同時是第一個有份參與 PATCH 的安全問題。

發現過程:

成為 Drupal JS maintainer 後,對一些 PATCH 關心程度大了。在 REVIEW 一個已 COMMIT 的 AJAX Patch 時發現了此漏洞 (以往一定不會太關心),於是向 Drupal Team 報告了。修復過程並不簡單,由於需要兼容 IE6+,做了很多瀏覽器測試 (多逹 32 個 TEST CASES)。 Backend 也需要解決 CACHES 及安全等等問題,討論了很多不同方案。

經過一番戰鬥,終於解決及公諸於世。(由於是安全問題,不多說了 ^_^)

( 最近的更新還包括挺嚴重的安全問題,建議大家更新。Ctools 也需要哦 )

了解 Drupal 8:為什麼我怎麼修改版型都沒反應?

從 Drupal 8 開始,沿用了多年的版型系統要改變了,改了使用 Twig。Symfony 的長期使用者對它不會產生冒生。作為程式員,遇到新事物,我慣常是直接打開檔案來修一修改,看看效果。對了,就看看 Bartik 版型。

於是打開 bartik/tempaltes/page.html.twig 改一改。怎麼沒有反應?嗯,是 CACHES 吧!清一清,有反應了。可是改一改,清一清,多複雜!怎麼關掉?還要看看文檔。到目前為此,文檔中除了一堆廢話還是一堆廢話,最終找到了 PATCH,原來收藏在 settings.php 中。(提示 Patch)


$settings['twig_debug'] = TRUE;

打開後,你可以使用 Twig 的 dump FUNCTION。(這其實就是 PHP 的 var_dump)

例子:


{{ dump() }}

印出所有目前 twig 檔案的所有可用的變數


{{ dump(user) }}

只印出 $user 內容

** 在 Devel 模組還未能完全在 Twig 下發揮作用前,大家先用用此 FUNCTION 吧。

啟用這個 DEBUG 設定更強大及有用的是將大量 DRUPAL 版型套用資訊以註釋方式印在源始碼中,讓開發者更順手! (將會有一篇文章詳說)


$settings['twig_auto_reload'] = TRUE;

當設定為 TRUE 時,會依據檔案修改時間決定是否重新載入修改的內容。


$settings['twig_cache'] = FALSE;

完全關閉 CACHE 功能。 在 DRUPAL 註釋中只建議打開上面的 twig_auto_reload 選項就足夠。但既然 TWIG 設計有這一選項,大家也應知道在一些未知情況下,AUTO RELOAD 是會出錯的。在開發過程中,如果兩者都打開不足以對你的進度構成影響,不妨兩者都用上。

在 DRUPAL 8 文檔中,還提及一些 TWIG 的全局變量。除非 PATCH 成功進入核心,否則是不可使用的。

 

開發版型,建議大家緊記三原則:

  • 直接試,不要猜想;未嘗試前不要發問這這這方法是否可行
  • 沒反應,試清除 CACHE
  • 上線前,請關閉上面的 DEBUG 設定

 

在此,特別想請醒新手們!關於 DRUPAL 中的 TWIG 就是你們在各大不同平台所見的 TWIG,DRUPAL 會增加少量獨有的 FUNCTION,但其他語法及功能幾乎是一致的。你們可以從非 DRUPAL 資源中學習 TWIG。比如說官方網站:http://twig.sensiolabs.org/