消除 Drupal 8 Toolbar 垂直模式閃爍

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

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

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

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

[徵求意見] 寫 Drupal 教學,有可能達到收支平衡,或不錯盈利嗎?

在 Drupal Planet 看見關於 Drupal 視頻教學瀏覽量達到 25 萬的文章,略看 YOUTUBE PLAYLIST,瀏覽量主要集中在初此數個視頻。

OSTraining 早前在 KickStarter 籌募此計劃:https://www.kickstarter.com/projects/stevebure/drupal-8-training-videos-help-us-make-drupal-magic/description

筆者有點驚訝,只有 41 人/公司支持,實在太少。總額只有 USD $12,280 (平均每人貢獻 USD $300,這價格在英文世界,相當合理。)
OSTraining 本身是一家培訓公司,開發教學未必動用到更多資源,額外的 USD $12,280 對他們來說算是收入。(根據文章裏說,Acquia 有可能額外作了金錢支持)。

記得很多年前,一位台灣 Drupaler @artt 創辦視頻教學,當中有包括 Drupal。(https://drupaltaiwan.org/forum/20110303/4940) 後來好像是個人關係關閉並轉手了。筆者沒有機會與 @artt 私下接觸,了解不了他當時經營情況。只能大敢推測盈利並沒有比他之前本職好,導致關閉其中一個原因。轉手後,也沒有再更新,推斷也是沒有達到收支平衡,所以不能再投入更多資源。

線上教學,在中文世界似乎很難生存。

剛好,又在 Drupal 台灣 Facebook 看見一則線下收費課程:
https://www.facebook.com/groups/drupaltaiwan/permalink/1044772058898401/

這課程,筆者有點驚訝,$3000TWD 一課,好像也有 8 – 10 位參與。

$3000 TWD * 8 ~ 10 = 24 000 ~ 30 000 TWD

以單一課堂計算,是極好收入。

以香港而言,$3000 TWD 一人算是很高的收費。不太清楚是否在台灣工程師界中算平凡定是高。雖然講者是有名氣的開發者,但以入門 CSS 設計模式教學來看,筆者還是有點驚訝 (不知是否因為英文教學,所以更貴? 還是因為英文教學,降低了收費? 不過,講者夫婦似乎在這方面有經驗,他們敢於定下這收費,應該作出了不少考量)

筆者沒有線上或線下教學經驗,但大敢推測,對於一個極度經驗講者,且又是開發者來說,開啟基礎線下教程,並不太花時間作準備。甚至可以零準備就能作高水平講課。(敢於這樣推測,原因是你沒有達到一定水平,你很難以在 Drupal Core 社區走上這麼高的地位,這些問題,每天都面對,甚至要作解釋。)。作為兼職運作,肯定不錯。

線下教學,看像有點希望,可是全職投入工作,第二課堂及以後,有多少參與?

推斷一下,即使之後也有 10 人參與,一個月可能要至少八課程才能達到講者基本薪金。而你沒有講者的名氣,可能收入減半或只有三分之一,甚至更少。

寫書又如何?
筆者覺得寫書是最難的,前期準備,中期寫作,後期審核,都不是容易的事。收入如何? 推算不了,但有時聽說其他非技術書籍作者都不能只純靠寫書養活。

辦學的人都太偉大 !!!

 

修復 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/

了解 Drupal 8:安裝模組、版型在這裏就對了!

DRUPAL 8 基於 Symfony2 架構上開發,相比前面的版本是極大的改變。然而連目錄架構也變了。

以前,經常看到新手直接把模組與版型放在根目錄的 MODULES / THEMES 資料夾中,這是錯誤的。但到了 DRUPAL 8,它是建議這樣做。

Drupal 8 目錄解說:

  • CORE
    這資料夾存放了 DRUPAL 核心檔案,不建議隨便修改。
  • MODULES
    在 DRUPAL 8 中,請將模組直接安裝到這裏。在多網站架構中,所有網站都會看到這些模組。
  • THEMES
    在 DRUPAL 8 中,請將版型直接安裝到這裏。在多網站架構中,所有網站都會看到這些版型。
  • PROFILES
    這裏保存 DRUPAL 8 安裝檔,與 DRUPAL 8 之前版本相同。
  • SITES
    這裏保存 DRUPAL 8 設定檔,與 DRUPAL 8 之前版本相同。(當然也能將模組及版型放到這裏)
    如在多網站架構中,你能限制模組/版型於某一網站,如:sites/notabluescreen.com/modules/foo_module/..

放在根目錄的 MODULES / THEMES 還是 SITES 中好?

從 DRUPAL 8 架構來說,放在那都是沒有差別的,是個人喜好
但需要注意,某些模組寫得糟糕,有機會被影響。(Drupal 7 中,很少會出現這情況,但我遇上一次;Drupal 8 中,相信更是極低可能性)。
即使如此,試想像你有十個不同網站放到一起,有一堆不同的版型及模組,當你打開 admin/modules 管理時,是極慢及很亂的。所有建議大家使用較複雜架構的式時好好規劃一番。

如果你是有潔癖的人,可以更仔細的整頓資料夾,可參考:整頓你的模組資料夾

“Taiwan, Province of China"

不知為什麼大家將 DRUPAL 翻譯成 "水滴",並在出版刊物中應用,真的很難聽。對於一個品牌的稱呼,個人有點執著。比如我只會講 "Google",絕不會講 "谷歌",即使這是官方公佈的名稱。

我不理政治正不正確,我會選擇使用 "繁體中文",不愛 "正體中文"。原因很簡單,在我的生活環境中,除了 FOSS 社區以及政治話題中以外,絕不會有人這麼稱呼它們。

DRUPAL 剛剛 COMMIT 了一個 ISSUE: 將 "Taiwan" 修改為 "Taiwan, Province of China"

這改變肯定有人不喜歡。此外也帶出另一糟糕問題: 若你想改變這一名稱,除了預裝程式並通過介面翻譯改正外,你必須 HACK CORE。

"Taiwan, Province of China" 該如何翻譯 ?

我偏愛 "台灣"。原因同上。

 

UPDATE 29-06-2013: 現已使用 CLDR 數據,台灣是 TAIWAN ( https://drupal.org/node/1938892 )

Drupal CKEDITOR 模組 linebreaks 問題

我們的一個網站由於開發時並沒有使用 Ckeditor 模組,最後導致啟動編輯器後引起 LINEBREAK 的錯誤 (右面是期待的正確結果)。從網上及官網資料大概了解到這是一個已知問題, 也沒有解決方法。

想一想,最後決定直接更新文章內容,替代 LINEBREAK 為 HTML <br />。本來較好的方法是透過 Drupal API 更新,可是我們的網站很簡單,寫 API 太浪費時間,所以選用直接 MYSQL REPLACE:

  1. 為安全起見,隨機找了一段文章字詞進行全資料庫搜尋,結果符合預期: 只有一個欄位儲存這些資料 (CACHE TABLES 可以乏略)
  2. MYSQL REPLACE

    
    UPDATE field_data_body SET body_value = REPLACE(body_value, "n", "<br />");
    UPDATE field_revision_body SET body_value = REPLACE(body_value, "n", "<br />");
    
  3. Enjoy It !

如果你是使用 Wysiwyg 模組可以試試: Wysiwyg Linebreaks