Quantcast
Channel: WFU BLOG
Viewing all 571 articles
Browse latest View live

網站管理員提交文章時,出現 "網址不在 Google 服務中"訊息怎麼辦?

$
0
0
google-search-console-url-not-index.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?最近接獲線報,表示使用 Google 網站管理員(新版 Search Console),在上方搜尋框輸入網址查詢時,出現了訊息「網址不在 Google 服務中」。案主表示:

之前利用檢索都可以順利在Google建立索引,但從前幾天開始即使送出需求,網頁也一直無法建立索引,不曉得您的網站是否也有相同問題呢?

由於 Google 推出了 Search Console,很多操作方式、錯誤訊息會跟以前舊版網站管理員不一樣,那麼將來這個狀況也可能重複出現,因此本篇藉這機會來調查是怎麼回事。



一、新版 Search Console


雖然舊版依然可以使用,但只要操作沒幾下,八成就會被建議、指示前往新版 Search Console:



雖然很多功能要花點時間找一下,用詞也可能不太一樣,不過新的版面我必須讚美一下:

  • 網站看起來有質感多了,比較專業
  • 操作介面也比較精簡,少了很多複雜、看不懂的選項



二、案情描述


1. 手動提交流程

我們知道,Google 收錄網站文章有時間差,會根據網站規模大小而不同。如果想要強制 Google 早點進行索引,使用舊版時,可以利用「檢索」→「Google 模擬器」來提交文章網址。

但現在這個功能在舊版已經無法使用,一律告知前往新版使用「新的網址檢查工具」。方法也很簡單,在新版 Search Console 上方搜尋框輸入網址即可:

google-search-console-url-not-index-1.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?

一個還未被 Google 收錄的網址,可以按上圖右上方紅框處的按鈕「要求建立索引」,這就是手動提交的流程,非常簡單。

那麼這個案子到底問題在哪裡,以上流程有發現任何異狀嗎?


2. Google 遲遲未進行索引

再複習一下開頭的案情陳述:「從前幾天開始即使送出需求,網頁也一直無法建立索引,不曉得您的網站是否也有相同問題」。

意思就是說,其實已經手動提交網址好幾天了,但是幾天後在 Search Console 上方的收尋框輸入文章網址,依然出現 "網址不在 Google 服務中"的畫面,這就比較離奇了。

於是我用 Google 搜尋案主該篇文章,事實上搜尋得到,所以當下 Line 對話大概是這樣:

  • W:Google 這篇文章搜尋得到啊
    • E:可以搜尋到但是沒辦法建立索引~覺得怪怪的
  • W:沒有索引怎麼可能搜尋得到呢 哈哈~要先被索引,才有可能搜尋得到
    • E:照理來說應該是這樣 但系統一直顯示不在索引中 所以我在想是不是系統有問題
  • W:不然你回報給官方好了 我也不清楚~
    • E:如果是系統有問題我就暫時不理他了 所以你的不會啊~~
  • W:不是會不會耶 我不太注意這種事的 ^^

後面的對話與本文無關,當下我的直覺是,既然文章能搜尋得到就好了,並沒有很想理會 Google 網站管理員顯示的訊息。因為根據過去的經驗,當我被詢問到跟網站管理員相關的問題時,大部分的情形最終都在安撫使用者 "沒事~別理會那些訊息",例如「在網站管理員看到 Index Coverage 問題不用擔心」。

不過為了瞭解是否為個案,還是測了一下自己網站,結果出現一模一樣的畫面,那麼還是來調查一下案情,猜猜到底 Search Console 發生什麼事。



三、網站地圖 sitemap.xml


試著從我網站最新的 3 篇文章開始調查,第 3 篇有被索引,略過。最新的 2 篇都會出現 "網址不在 Google 服務中",其中第 2 篇就是前面那張圖,那麼再來仔細研究一下。

google-search-console-url-not-index-2.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?

搜尋當天的日期為 4/19,這篇文章在 Google 是可以搜尋到的,表示一定有被 Google 索引。


google-search-console-url-not-index-1.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?

但是為何在 Search Console 會出現上圖的錯誤呢,明明就有被索引啊?

檢查了一下 sitemap,上圖的意思是說,sitemap.xml 裡面沒有這篇文章,那麼我們來檢查一下 sitemap 報表資訊。


google-search-console-url-not-index-3.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?

似乎找到兇手了,原來 sitemap.xml 上一次檢查的日期是 4/11 這麼久以前啊,難怪網站地圖 sitemap.xml 裡面沒有那篇文章。

注意到 atom.xml 的日期了嗎?4/18 有進行索引過。


google-search-console-url-not-index-4.jpg-網站管理員提交文章時,出現 "網址不在 Google 服務中" 訊息怎麼辦?

如上圖,這篇文章的發佈日期是 4/14,所以在 4/19 的時間點,該篇文章不在 sitemap.xml 之中,但有被 atom.xml 收錄、已被 Google 索引。

這就能完美解釋,為何 Google 可以搜尋得到,但在 Search Console 卻出現 "網址不在 Google 服務中"的錯誤訊息。

所以我的推測是,Search Console 預設讀取 sitemap.xml 的資料來顯示報表,才會發生與現實脫節的狀況,只要改掉這一點,直接讀取日期最近的一個 sitemap 提交檔案,就可解決這個 bug。



四、提交網站地圖的正確作法


雖然目前看起來已經破案了,但還是有一些事需要提醒讀者:

1. 不是只有本篇的狀況會出現 "網址不在 Google 服務中"訊息,有些站長可能根本不知道要提交網站地圖,那麼依然會出現這個錯誤訊息

2. 還有一些機率比較低的情況會出現此錯誤訊息,例如內容有問題、被提報導致 Google 剔除索引,或是 Google 有專人介入處理某些網址。不過這些從報表上應該都會有明確的訊息,要如何處理直接看說明就好了。

3. 從本文的內容可發現,Google 處理 sitemap.xml 這個檔案的間隔非常久,以我的網站來計算,等於隔了 10 天才檢查,那麼只提交 sitemap.xml 可能會浪費 10 天的時間

因此強烈建議讀者,務必按照「Blogger 提供新的網站地圖(sitemap)格式﹍一勞永逸的提交方法」,同時另外提交 atom.xml,可以有效縮短索引間隔,那麼看到本篇的錯誤訊息也不必擔心,因為文章其實已經被收錄,Google 也搜尋得到文章囉~


更多 SEO 相關文章:

統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)

$
0
0
website-track-google-analytics-event-widget-free.jpg-統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)上一篇「GA 事件追蹤器」的免費版功能比較少,本篇的版本可以做到這些事:

  • 排除 Blogger 站長自己的點擊
  • 對小工具進行分類,例如區分為導覽列、側邊欄、頁尾等等
  • 監測動態 JS 產生的小工具連結
  • 指定要監測的小工具
  • 排除不要監測的小工具

關於這個工具的運作原理、使用方式,建議先參照上一篇的內容有個基本的瞭解,並請注意本篇為「會員加值文章」,需先儲值點數才能看到隱藏內容。

(圖片出處: pixabay.com)


一、特點及應用方式


因為此版本功能較多,說明一下特點及可以應用的方式:

1. 依照區塊分類

使用免費版時,撈 GA 數據時,所有小工具的數據會列在一起,比較不方便查找與歸納分析。

本版可以依照自訂的區塊分類,例如側邊欄區、標頭區、輪播區、頁尾區等等:

  • 從 GA 報表可直接看到各區塊的成效
  • 也可直接進入個別區塊來查看、分析小工具的成效
  • 操作上會比較節省時間


2. 去蕪存菁

使用免費版時,網頁上所有的連結都會監控,導致 GA 存放許多不需要的數據。

本版可以設定要監控的區塊、不要監控的區塊,例如網站留言區塊的連結沒什麼監控的必要。

如此 GA 報表只會看到必要的數據,節省篩選資料的時間。


3. 分析小工具的去留

從 GA 報表的數據,可以觀察哪些小工具的點擊數成效不彰:

  • 乾脆移除這些小工具,以加快網頁載入速度。
  • 或是改放其他小工具進行測試,看是否有更好的點擊成效


4. 分析值得擺放的文章連結

這是很需要科學導向重要的一項工作,例如挑選輪播、精選文章時,當然可以依照我們個人喜好來擺放。但更重要的是觀察這些文章的點擊數據,如果某些文章放了卻都沒有點擊,代表沒有打中訪客的口味,那麼就該將這些文章下架,改試不同的輪播文章、精選文章。

以上動作必須依照週期循環來檢查,因為讀者的口味在不同的時間點有可能改變。


5. 找出熱門的文章題材

通常網站都會有這兩個工具:

  • 側邊欄的標籤分類工具
  • 導覽列

這兩個工具的內容會有大量的標籤連結,若想找出讀者關注的主題,將是絕佳的觀察指標。

定期觀察讀者點擊哪些標籤的次數最多,除了可知道該時期的風向,也可列為網站寫作的題材方向。


6. 分析服務項目、擺放位置

如果網站提供了一些服務項目,可以注意這幾點:

  • 觀察哪些服務的連結點擊成效比較好,代表這是市場上需重點發展的項目。
  • 在網站不同位置擺放這些服務連結,測試哪裡的成效比較好,並進行調整。



二、安裝程式碼


在修改範本之前,如果第一次安裝本站工具的讀者,建議先閱讀「備份範本的訣竅」系列文章。

以 Blogger 平台為例,請到後台「主題」→「編輯 HTML」,游標點進範本區塊,按 Ctrl-F 搜尋 </body>這個字串,找到後在此字串的前一行,插入以下程式碼:


參照以上程式碼行號,請見以下參數修改說明:
  • A 行綠字可參考「引用 jQuery 的注意事項」,檢查範本是否已安裝過 jQuery,如果已經安裝過請刪除此行,以免重複安裝。
  • E 行參數:
  • F 行參數:
    • 藍色字串是想要監控點擊的區塊,可自行修改,區塊的字串規則為 "." + class 名稱、或是 "#" + id 名稱
    • 每個區塊的字串請放在雙引號 ""內,每組字串之間用小寫逗號 ","隔開,最後一組字串之後不要有小寫逗號。
    • 以 Blogger 官方範本而言,這些監控的區塊包含了 "標頭"、"導覽列"、"側邊欄"、"頁尾"
  • G 行參數:藍色字串是想要排除監控的區塊,可自行修改,規則同 F 行說明。
  • H 行參數:
    • 藍色字串是要追蹤的小工具 class 名稱,可自行修改
    • 也可加入多個小工具 class,彼此間請用小寫逗號隔開
    • 這是 Blogger 平台小工具都會有的 class 名稱,非 Blogger 平台請務必修改



三、使用說明


基本的操作請參考上一篇「GA 事件追蹤器」即可。

以下說明這個工具比較進階的使用方式:

1. 為點擊區域進行分類

免費版的功能會直接列出所有小工具的點擊,當網站監控的工具非常多時,一個報表可能會一次列出十幾、二十多個工具,比較不容易進行歸納分析。

程式碼 F 行參數具有「為所有點擊事件進行分類」的功效。例如預設的參數:

  • "header"→ 會統整標頭區塊的所有小工具,瞭解標頭的整體成效
  • ".sidebar"→ 會統整側邊欄的所有小工具,瞭解整個側邊欄的成效
  • "footer"→ 會統整標頭頁尾區塊的所有小工具,瞭解頁尾區塊的成效


2. 排除不需監測的區塊

這個工具主要用來評估小工具的點擊成效,那麼免費版會監控所有區塊的點擊,報表也會列出太多雜訊。

程式碼 G 行參數設定後,預設參數的意思是排除以下兩個地方的點擊數據:

  • 文章區塊
  • 留言區塊


3. 使用範例

website-track-google-analytics-event-widget-member-post-1.jpg-統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)

上圖可看到,現在看 GA 的事件報表時,紅框處已經將所有小工具的點擊,按照 sidebar(側邊欄)、header(標頭)、footer(頁尾) 分類好了,馬上就能看到各個大分類區塊的總體成效。


website-track-google-analytics-event-widget-member-post-2.png-統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)

假設想要看 sidebar(側邊欄) 個別工具的成效,先點擊 sidebar → 再點擊「事件動作」,可看到上圖的效果,點擊數據依照側邊欄每個工具的 ID 名稱列出來。

以本站的數據來看,看起來成效最好的是 Label1(樹狀標籤),再來是 ArchiveList(文章彙整)。


website-track-google-analytics-event-widget-member-post-3.png-統計歸納網站所有連結的點擊成效﹍GA 事件追蹤器(會員加值文章)

如果想知道訪客關注的主題有哪些,可點進 Label1,如上圖,就會列出熱門點擊的標籤名稱了。




四、聯絡表單


本篇的工具,參數修改需要具備前端的基本 HTML/CSS 知識,如果不熟悉的話,建議不要購買此工具,請直接發案給本站代為處理。

加值文章關閉留言板功能,使用上有任何問題請用下面的表單與我聯繫:




更多「提升網站效能」相關文章:

利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

$
0
0
google-analytics-event-tracking-optimize-web-widget-link.jpg-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例過去我們網站擺放的各種外掛、小工具,一開始是如何決定的呢?是因為個人喜好,還是因為別的網站有裝,還是猜測訪客應該需要?

如果不確定為何而裝,那麼想必站長們都知道,外掛裝越多,網頁載入速度越慢,那麼究竟哪些外掛該移除呢?

還有,我們會在網站各處擺放各種想推廣的文章連結,你知道哪些有人點、哪些沒人點,哪些該換別的連結以獲得更好的成效呢?

以上所有的事,其實可以不依靠第六感,直接收集實實在在的數據,從報表就能輕鬆分析出該如何取捨,本篇從實作範例來看看如何做到。



一、安裝 GA 事件追蹤器


只要網站有安裝 Google Analytics (GA),就可利用本站開發的「GA 事件追蹤器(會員加值文章)」,追蹤網站所有連結的點擊成效。

使用這個版本的優點有這些:

  • 排除 Blogger 站長自己的點擊
  • 對所有點擊事件進行分類,例如區分為導覽列、側邊欄、頁尾等等
  • 監測動態 JS 產生的小工具連結
  • 指定要監測的小工具
  • 排除不要監測的小工具


文章開頭圖片的 GA 數據報表,為本站在上個月進行實測的結果,以下將分析這些點擊記錄,試著進行各種網站優化的評估。



二、網頁各區塊的評估


進入「GA 官網」→ 左側選單 → 行為 → 事件 → 總覽 → 並且套用選定的日期範圍後,可看到類似以下的報表。

google-analytics-event-tracking-optimize-web-widget-link-1.jpg-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

從以上的數據,可看出對於本站而言:

  • 文末的「延伸閱讀」工具 (postSeries)是最重要的一個區塊,佔了訪客將近 3 成的點擊率,所以這是不可或缺、極重要的一個外掛。
  • 導覽列下拉選單區塊 (dropdown_menu) 也非常重要,同樣佔了訪客將近 3 成的點擊率
  • 側邊欄所有點擊加總,將近 1/4,次數也不少,但側邊欄佔據網頁的面積遠大於前兩者,所以側邊欄的外掛取捨,需要看進一步的數據來決定
  • 標頭 (header)、頁尾 (footer) 區塊,雖然點擊比例沒那麼多,但由於都只是超連結而已,不會對網頁效能有任何負面影響,相較之下其實是 CP 值超高的兩個區塊,可以看做是無本生意、卻能創造出這麼多的點擊。
  • 本站比較可惜的是紅框標出來的兩個區塊:首頁輪播(cross_slider)、首頁推薦文章(label_posts)
    • 輪播等於 1 天只有 2 次點擊而已,但是載入了 6 張大圖、執行一個輪播外掛(3 個額外的 CDN HTTP 請求),CP 值不算好 → 將來我可能會移除輪播區塊
    • 首頁推薦文章更慘,1 天不到 1 次點擊,但是載入了 8 張大圖、6 張小圖、3 個額外的 HTTP 請求→ 目前我已決定會移除這 3 個推薦文章區塊

接下來我們一一針對個別數據,來看看可以如何進行解讀。



三、延伸閱讀的重要性


1. 文字版相關文章

google-analytics-event-tracking-optimize-web-widget-link-2.jpg-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

點進「延伸閱讀」區塊的報表,上圖可看到所有被點擊的連結文字:

  • 一方面可瞭解讀者對哪方面的主題、內容最有興趣
  • 看是要多寫相關的文章,還是推廣這些容易受到關注的文章
  • 另一方面可看到「所有相關主題文章一覽」這個連結的點擊數最多

一般的「延伸閱讀」工具並沒有這個功能,「所有相關主題文章一覽」是我自行開發的功能,點擊後會進入該標籤的頁面,讓讀者參考該標籤的所有相關文章,可增加更多的點擊機會

當初設計這功能時,其實我不確定訪客是否會點擊「所有相關主題文章一覽」這個連結,現在有了數據支持,可以確定這是非常正確的決定。

所以從統計數據可以看出,文末區塊是讀者剛閱讀完文章,注意力最高的一個區塊,在這裡放「延伸閱讀」工具可以說是網站 CP 值最高的一件事。


2. 圖片版相關文章

從本站的數據來看,文字版的相關文章有這麼大的效用,那麼很多網站會擺放的「圖片版相關文章」效用又是如何呢?

一方面載入圖片會花費不少 HTTP 請求,如果沒有好的點擊效果,跟「文字版相關文章」比較之下,對於網站效能是很浪費的。

很可惜本站目前沒使用這樣的工具,所以缺乏資料評估效用,站長們需要自行安裝「GA 事件追蹤器」,讓數據來說話。



四、導覽列的連結配置


google-analytics-event-tracking-optimize-web-widget-link-3.png-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

來看看所有導覽列被點擊的數據細節:

  • 算是不意外,首頁永遠是點擊率最高的連結
  • 我看過有些站長導覽列沒放「首頁」連結,這是很吃虧的,盡量在各方面滿足訪客的操作需求,可以逐步累積訪客的好感,聚沙成塔
  • 其他的數據跟「延伸閱讀」的效果類似,可以了解讀者對哪些標籤、連結最有興趣


根據導覽列的點擊排行,我們可以做的事大致是這樣:

  • 把點擊率高的標籤或文章連結,排序的位置往上移動,減少讀者眼球的移動距離
  • 點擊率低的連結,一方面排序往下,一方面也可思考是否下架
  • 沒什麼點擊的連結,可更換其他連結再測試一個月
  • 從數據反覆評估找出導覽列所有連結的最佳解
  • 說不定有些連結的成效是季節性的,這需要不一樣的實驗時間區間才看得出來



五、側邊欄的工具取捨


前面兩個區塊很單純,都只有一個工具而已,而側邊欄的小工具數量就很多了,我們點進側邊欄區塊來看細節。

google-analytics-event-tracking-optimize-web-widget-link-4.jpg-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

  • 雖然「樹狀標籤」是本站最熱門的工具,但我一直不確定讀者到底有沒有在用本站的這個工具,直到現在看到 Label1 的數據,而且是遙遙領先,總算心裡比較踏實,這個工具沒有白裝了 → 樹狀標籤是側邊欄最重要的工具
  • ArchiveList 是 Blogger 官方工具「文章彙整」,長久以來一直不想安裝這工具,因為我自己不會去使用。前陣子覺得訪客或許會用這個工具吧,才加到側邊欄,沒想到數據顯示「文章彙整」是本站排行第 2 名的側邊欄工具,而且位置還很偏僻。這也讓我醒悟,安裝工具與否需要讓數據說話,而不是憑自己的感覺
  • sidebar_float 是側邊欄浮動區塊,由於固定在畫面上,有一定的點擊不意外
  • blog_collection 與 blogger_collection 都是精選文章的區塊,雖然點擊數沒很多,但這些都只是超連結而已,不需要 http 請求,也就是無本生意,只要有點擊都是賺。


剩下幾個幾乎沒有點擊數的工具,倒是可以討論一下:

  • 這幾個只有個位數點擊量的工具,剛好都是位於隱藏的分頁,沒有顯示出來
  • 所以側邊欄不適合使用分頁工具,數據證明,訪客的時間很寶貴,他們不會特地去打開隱藏的分頁
  • 最新文章 (newPosts) 與熱門文章 (popularPostArea) 都是部落格側邊欄的常見工具,但可惜本站都放在隱藏的分頁,所以此次無法測出這兩個工具的實際效用,這就留待其他站長的實測結果了



六、標頭、頁尾的連結


本站的標頭、頁尾區塊,沒有安裝任何工具,代表載入頁面不需要任何額外的 http 請求,完全不影響網頁載入速度,所以任何連結的點擊都算是淨賺。


google-analytics-event-tracking-optimize-web-widget-link-5.png-利用科學數據,決定網頁是否安裝特定外掛,優化網站配置﹍實作範例

特別來看一下標頭區塊的點擊細節,本站的標頭一共只有 5 個連結,但是這 5 個連結一共貢獻了數百次點擊,必須說「標頭」是本站 CP 值最高的一個區塊。

  • 首頁點擊率都是最高前面提過,此處省略
  • 剩下的幾個連結,有的是推廣本站的業務
  • 有的是本站工具懶人包整理,該篇有數十個更多的文章連結
  • 有的是增加分站曝光度

此次進行統計才知道「標頭」是非常能吸引訪客注意的區塊,那麼建議讀者好好規劃這個區塊的連結,成效可能會超出想像。

有的站長會在標頭放廣告,當然轉換成收益也是滿實在的,不過建議站長們評估一下,究竟這個區塊用來拿現金比較划算,還是獲得大量點擊會有更好的影響力。



七、小結


本篇分享的 GA 點擊數據,僅僅是本站 4 月份的績效,相信對本站的版面配置、小工具去留有很大的參考價值。然而是否所有網站都能依照本站的經驗來進行規劃呢?我相信某些可以,但不是所有數據都能依樣畫葫蘆。

舉例來說,數據顯示本站的輪播功能青睞度不高,這很有可能是輪播圖片不夠吸引人,或是輪播圖片不夠大張,又或者本站的性質本來就不適合放輪播。如果是美食、旅遊、美妝網站,或許首頁有高質感的輪播圖,點擊率就不一樣了。

所以不同性質的網站,版面配置、擺放的工具、連結的安排,可能訪客習性都不一樣,自然點擊習慣也不一樣,那麼一切還是回歸各自的網站數據才準確。

那麼本篇算是讓讀者瞭解,「面對數據時,可以進行什麼樣的思考與應對」。而真正規劃自己網站時,還是得請站長們好好收集 GA 點擊數據,才能為自己的網站配置做出最佳化


更多「提升網站效能」相關文章:

讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

$
0
0
web-table-sort-html-generator.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)之前寫過一篇「讓網頁表格能自動排序﹍TableSorter 安裝懶人包 」,只要安裝這個外掛就能達到排序的效果,看起來非常方便。

但最近接到的需求除了要讓表格排序,還得讓案主知道怎麼做出表格來,這下就麻煩了,因為很多站長其實不熟悉 HTML 碼,自然也不知道表格 Table 的正規 HTML 格式會是什麼樣子。

所以我之前也寫了一篇「網頁插入表格不再麻煩﹍線上產生器 + 可匯入 CSV 檔」,讓製作表格不再是困難的事,什麼都不需要懂,就可無腦產生表格語法。

不過困難的還在後頭,因為這個「表格自動排序」的外掛,只吃特定格式的表格 HTML 碼,所以得想辦法讓案主做出特定的 HTML 碼才行。

因此本篇會找出一個順暢的操作流程,來操作各種線上工具,產生表格的 HTML 碼,最後再套用排序外掛。

(圖片出處: photo-ac.com)


一、表格範例


web-table-sort-html-generator-1.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

本篇以上圖範例的表格內容來進行流程,示範如何做出這種形式的表格,並進行排序。

完成效果大致像這樣:

2019高雄生日餐廳優惠
No餐廳價格區域地址優惠
1墨吉日式$500↑左營富民路160號送小蛋糕
2巴蜀大將$300↑三民鼎山街225號送肉盤
319to1牛排$500↑左營民族1路948號2F2人同行1人免費






二、熟悉 HTML/CSS 的作法


如果熟悉 HTML/CSS 的話,流程比較簡單,可使用這個線上表格產生器:



這個工具所產生的表格 HTML 碼,是少數幾個能支援表格排序外掛的格式,操作流程說明如下:

web-table-sort-html-generator-2.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

  • A:輸入列、欄數量
  • B:如果熟悉 CSS,可自行設定這裡的參數
  • C:此處一一輸入表格內容
  • D:輸入完畢,按「Generate Table」
  • E:最後複製此處產生的 HTML 碼即可



三、不熟悉 HTML/CSS 的流程


如果沒辦法自訂 CSS 的話,建議改按照以下流程,一樣使用前面的線上表格產生器:

web-table-sort-html-generator-3.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

  • A:輸入列、欄數量
  • B:不勾選所有選項
  • C:輸入表格標題、欄位名稱、所有表格內容
  • D:輸入完畢,按「Generate Table」
  • E:最後複製此處產生的 HTML 碼即可



四、可能比較快的操作流程


如果「三、不熟悉 HTML/CSS 的流程」已經比較熟了,而表格內容很多時,可能會覺得這個線上產生器的輸入不方便,那麼可改用以下優化過的流程:

1. 使用試算表製作表格內容

web-table-sort-html-generator-4.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

使用「Google 試算表」的優點是,複製、匯入、輸入都很方便,比操作任何線上表格產生器都來得方便。

如上圖,使用「Google 試算表」輸入或匯入表格內容,不含欄位標題及表格標題,處理完後下載格式選擇存成 csv 檔。


2. 匯入 Tables Generator

接著使用線上工具:



web-table-sort-html-generator-5.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

  • 匯入 CSV 檔:File → Import CSV file → 選擇檔案
  • 剛剛製作的表格內容就會出現在上圖
  • 勾選「Do not generate CSS」,就可得到乾淨的 HTML 碼
  • 複製下方的 HTML 碼備用,這些是表格內容的 HTML 碼
  • 但請注意,需將開頭的 <table> 以及結尾的 </table> 字串刪除,只留中間的所有字串


3. 製作表格標題及欄位名稱

接著使用線上工具:


web-table-sort-html-generator-6.jpg-讓網頁表格自動排序﹍實作範例教學 (HTML 線上產生器)

  • A:列輸入 0,欄位輸入數量
  • B:不勾選所有選項
  • C:輸入表格標題,及欄位名稱
  • D:輸入完畢,按「Generate Table」
  • E:
    • 此處可產生乾淨的表格標題、表格欄位 HTML 碼,將這些 HTML 碼複製到他處備用
    • 在藍色箭頭處,也就是 <tbody> ~ </tbody> 之間,貼上前面複製的表格內容 HTML 碼
    • 這樣組合起來,就是全部完整的表格 HTML 碼



五、使用排序外掛


1. 修改 class 名稱

使用這個表格線上產生器製作的 HTML 碼,Table 元素的 class 名稱預設都是 "demo",如果網站所有表格都採用同樣的 CSS 樣式,那麼可維持 "demo"不必變動。

但如果表格會使用不同的 CSS 樣式,可以為不同表格取不一樣的 class 名稱。


2. 排序外掛

這部分的程式碼,需要詳細說明請參考「讓網頁表格能自動排序﹍TableSorter 安裝懶人包 」,以下直接看安裝程式碼,可放在文章中所有表格後面:


產生的表格排序效果可見「一、表格範例」。


更多「表格」製作技巧:

使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例

$
0
0
gmail-api-send-message-google-apps-script.jpg-使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例最近研究 Gmail API 才發現,處理郵件是一件非常麻煩的事,操作 Gmail API 可說是我目前為止,所有經手過的 API 之中最難搞的一個。

如果可接受比較簡化的功能、不一定要使用 Gmail API 的話,那麼 Google Apps Script(以下簡稱 GAS) 提供了一個 GmailApp 服務,可以用最無腦的方式寄送 Gmail 郵件,不過缺點是一天最多 100 封郵件。

而操作 Gmail API 的優點是,一天至少可寄 500 封郵件(可參考官方文件「Usage Limits」),所以本篇還是說明 Gmail API 的使用方法,提供最簡易的操作環境及範例程式碼。

(圖片出處: pixabay.com)


一、處理 OAuth 授權


1. 啟用 Gmail API

操作 Gmail API 第一步要解決的是 oAuth 身份驗證問題,這個流程很冗長、麻煩,網路上已有很多教學文章,例如可參考這篇「申請及啟用 Gmail API 的 OAuth 2.0 憑證」。

如果讀者方便使用 GAS 環境的話,恭喜你可以略過這些步驟,不需要處理身份驗證問題,參考官方文件「Advanced Gmail Service」,請見以下操作方式:

進入「Google 雲端硬碟」→「新增」→「更多」→「Google Apps Script」,可新增一個指令碼專案。


gmail-api-send-message-google-apps-script-1.jpg-使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例

按「資源」→「進階 Google 服務」


gmail-api-send-message-google-apps-script-2.jpg-使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例

往下捲到「Gmail API」,如上圖紅框,點擊右邊開關可開啟這個 API,再按下方「確定」即可。

很簡單的一個啟用步驟,以上完成後就可直接在 GAS 直接呼叫 Gmail API,完全不必進行身份驗證。

補充一下,以上流程適用於最近一兩個月內新增的 GAS 指令碼專案(2019.4.8 之後),如果你的指令碼專案在這個日期之前產生,請參考官方文件說明「Advanced Google services」,除了以上動作之外,還需要同時到 Google Cloud Platform 啟用 Gmail API,多做一個動作。不過其實 GAS 畫面上都會有說明以及附上連結,不必擔心。


2. 試用 Gmail API

同樣根據剛剛的官網文件,提供了幾個範例語法。在 GAS 中只要啟用 Gmail API 後就能直接執行全域物件 Gmail。

一方面可以參考 Gmail 官網「getProfile」的用法,調用以下語法就能取得自己的 profile 資料:

Logger.log(Gmail.Users.getProfile("me"))



二、Gmail API 寄信語法


解決了麻煩的驗證問題後,終於可以開始寫信了,這下比較簡單了吧?很可惜,現在才是災難的開始。

1. 寄信語法

根據官方操作教學文件「Users.messages: send」,我找到 JS 範例語法如下:

gmail.users.messages.send({
'userId': userId,
'resource': {
'raw': base64EncodedEmail
}
});

需要帶入兩個變數,簡單說明一下:
  • userId 比較好解決,不用身份驗證後,只要填入字串 "me"即可
  • base64EncodedEmail 看起來是需要將郵件內容作 base64 編碼處理

但是郵件內容要怎麼填寫呢,直接放字串 "Hello World!"這樣可以嗎?當然是不行的。


2. GmailApp

前面提到的字串 "Hello World!"是指郵件內容的字串,但一封郵件需要填入的欄位很多,例如收件人、主旨、內容等等,所以 base64EncodedEmail 的內容不會是單純的一組字串。

以 GAS 提供的 GmailApp 為例,可參考說明文件「GmailApp」,提供的語法很簡單:

GmailApp.sendEmail(收件人, 主旨, 內容);
這樣是不是很無腦就能操作?我相信 Gmail API 也可以這麼做,但可惜並沒有針對這部分做簡化。


3. 郵件格式規範

從 Gmail API 官方文件,對於郵件內容字串只說要符合郵件格式規範:

* @param {String} email RFC 5322 formatted String.

而整份 API 說明文件看不到半個郵件內容範例,代表我們需要自行找出郵件格式規範 RFC 5322 來閱讀,然後想辦法弄成 Gmail API 可以接收、還能正常顯示的格式。但就算知道了什麼是 RFC 5322,也無法知道要怎麼包字串才能讓 Gmail API 接受,所以官方文件這部分可說是相當簡易,或許只有具備網路底層知識背景的工程師有辦法使用。



三、處理郵件格式


1. RFC 郵件規範

找到這個討論串「How to send a message successfully using the new Gmail REST API?」,終於知道什麼是 RFC 郵件規範,例如以下範例

From: John Doe
To: Mary Smith
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>

This is a message just to say hello. So, "Hello".

不過實作上,真正需要的欄位主要是 To、Subject、以及郵件內容這三個。


2. base64 編碼

另外這個討論串「Google REST API - message in an RFC 2822 formatted and base64url encoded string」說明了如何針對郵件規範產生郵件,並進行 base64 編碼,作法重點如下:

  • 從前面的郵件規範範例,每一行字串結尾都要加上 Enter 以及換行符號
  • 將每行字串連結成一段完整字串
  • 將此完整字串進行 base64 編碼

如果你以上都看懂、知道如何進行了,官網文件「Users.messages: send」提供了 API 測試工具,可自行測試你的 base64 字串是否有效,能否成功寄出郵件。


3. GAS 轉換 base64 語法

GAS 官方提供了工具「Class Utilities」,其中 base64Encode() 就可直接進行 base64 編碼,但可惜有時測試成功,有時不行。

這篇「message in an RFC 2822 formatted and base64url encoded string」說明了 base64 編碼不一定能相容於網址字串,所以還需要對特定字元作轉換才行,例如 "+/"這些字元。

所以最好 Utilities 使用另一個 base64EncodeWebSafe() 才能確保沒問題。


4. 中文編碼轉換

事情還沒完,坑非常多,使用中文傳送郵件會變成一堆問號 "??????",所以必須再將中文編碼成 UTF-8,GAS 完整的 base64 轉換語法如下:

Utilities.base64EncodeWebSafe(符合郵件規範的字串, Utilities.Charset.UTF_8)


5. 標題中文編碼轉換

以為中文編碼完終於可以正常寄信了,沒想到信件標題卻總是變成亂碼。

看了這篇「Gmail API not respecting UTF encoding in subject」,才知道原來根據 RFC 規範,郵件標題一律使用 7 位元編碼,難怪中文及需要 8 位元編碼的文字全都變亂碼,全世界各種語言都看得到災情。

這篇「unable to encode special characters email in right format, gmail api」,提供了正確處理方式及範例,需要將郵件標題用以下形式處理:

Subject: =?utf-8?B?這裡放入經過base64編碼的中文字串?=



四、寄信範例程式碼


綜合以上心得及整理,以下附上 GAS 中執行 Gmail API 寄信的完整範例程式碼:

function sendMail() {
var recipient = "xxxxxxxx@gmail.com", // 收信者郵件地址
subject = "測試郵件主旨", // 郵件主旨
content = "這裡是郵件內容!!!", // 郵件內容
mailData = "",
rawData = {},
base64Data, response;

mailData += "To: " + recipient + "\r\n"; // 每行字串要加上 Enter 及換行符號
mailData += "Subject: =?utf-8?B?" + Utilities.base64Encode(subject, Utilities.Charset.UTF_8) + "?=\r\n\r\n"; // 主旨這一行一定要有兩個換行;主旨字串一定需要額外重新 base64 編碼過一次
mailData += content;

base64Data = Utilities.base64EncodeWebSafe(mailData, Utilities.Charset.UTF_8);

rawData = {
"raw": base64Data
};

response = Gmail.Users.Messages.send(rawData, "me");
Logger.log(response);
}

第一次執行時 GAS 會跳出要求授權的視窗,可參考「前端操作 Apps Script 上傳檔案」 →「三、撰寫 Apps Script 指令碼」的第 3 張圖開始看,開放權限給 API 即可執行。

接下來重點說明:

  • recipient、subject、content 三個重要字串請見註解說明填寫
  • 「收信者郵件地址」這一行後面一定要加上 Enter 及換行符號
  • 「郵件主旨」這一行後面一定要加上兩個 Enter 及換行符號,否則郵件會無法寄出
  • 所有的字串都需要經過 base64 編碼,而「郵件主旨」的字串需要額外再 base64 編碼一次,等於經過 2 次編碼,否則一定無法顯示中文
  • Gmail.Users.Messages.send 的參數與 Gmail API 有出入,原因不明。

所以 GAS 這裡在操作 Gmail API 時,會面臨需要的功能,在官方文件找不到的窘境,解決方法請見下圖:

gmail-api-send-message-google-apps-script-3.jpg-使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例

請依紅框處,手動輸入 Gmail API 的所有方法,GAS 系統都會出現提示文字以及該方法需要的變數,算是滿方便的。


gmail-api-send-message-google-apps-script-4.png-使用 Gmail API 寄信的簡易管道及障礙排除﹍Google Apps Script 實作範例

試著執行以上範例程式碼,果然成功收到郵件,且可完全正常顯示了!


更多 Google Apps Script 使用技巧:

CSS 撰寫技巧及規範﹍維護心得整理

$
0
0
前端開發 CSS 寫久了之後,發現幾個麻煩的地方:

  • 命名字串想破頭,要避免重複,又得能正確理解
  • 日後維護修改時,要找到正確的區塊位置得花不少時間
  • 壓縮過的 CSS 碼無法閱讀、不易維護,好閱讀的 CSS 碼太冗長

因此決定研究一套方便維護 CSS 碼的作法,本篇心得比較適合 Blogger 平台參考。

(圖片出處: pixabay.com)


一、CSS 命名


1. 有意義的英文單字

對於非開發人員而言,CSS 命名使用有意義的英文單字有很大的好處:

  • 完整的單字也許字元數比較多,但至少一眼就能看出是什麼意思
  • 為了減少字元數而使用自創的縮寫,例如相關文章 relatedPost 改用 rp,一段時間後也許認不出 rp 到底是相關文章還是隨機文章 (randomPost)
  • 這篇「製作網頁表單﹍Grid 網格系統」的 class 使用了大量簡寫,例如 f1、w1、l1,久了一定記不起來 "f"、"w"、"l"分別代表什麼意思

因為非開發人員不常維護 CSS 碼,所以最好在命名上要考慮到,怎麼樣可以讓自己在幾年後仍可一眼認出 CSS 命名。

而開發人員因為每天接觸這些 class 名稱,各種縮寫、簡寫都是吃飯工具,可以稍微放寬命名的要求。但如果需要協作的話,還是需建立一套有共識的命名方式。


2. 常用命名單字

有意義的英文單字遲早會用到詞窮,不小心就多處造成重複,可整理一份自己常用的字典檔,隨時查閱很方便。

也可參考這篇「前端人員必看CSS命名規範」:

  • 「三、命名規範」這裡整理許多泛用、常用的單字,有中英對照,分類成這幾部分:
    • 頁面結構:例如 container、header、content...
    • 導航:例如 nav、topnav、subnav、sidebar...
    • 功能:例如 banner、title、status...
  • 「一、文件規範」這裡有一些各區塊 css 檔命名的範例


3. 命名規範

class 名稱使用超過一個英文單字時,有多種方法將各個單字連結起來。這篇「CSS 書寫規範」整理了不少 CSS 書寫風格,例如:

  • 駝峰命名風格:首字母大寫、其餘小寫
  • 底線風格:用底線 "_"連接每個英文單字
  • 連字符風格:用 "-"連接每個英文單字

使用 "-"或 "_"有其特定意涵存在,這裡先不贅述,我個人的命名習慣是,盡量不使用 "-"符號,因為在維護時,用滑鼠操作比較花時間。

使用 "駝峰命名"或底線的單字,滑鼠點兩下就能選取,可以節省很多操作時間。



二、CSS 順序


CSS 排列順序能夠形成一套邏輯的話,日後維護、尋找可以節省很多時間。

1. 區塊架構順序

可參考「CSS 團隊開發的最佳實踐」,這篇提供的 CSS 架構及順序很值得參考:

/*---GLOBAL---*/
/*---HEADER---*/
/*---NAV---*/
/*---CONTENT---*/
/*---SIDEBAR---*/
/*---FOOTER---*/

這篇還有更細的分類方法,總之這樣的分類很直覺,就是我們眼睛閱覽一個網站的移動順序,日後維護、查找 CSS 內容時會比較快。

在 GLOBAL 通用區塊,可以擺放例如 reset、架構、字體等等版面以外的 CSS。

在 CONTENT 主要內容區塊,部落格架構會分不同的頁面,例如文章頁面、索引頁面,Blogger 可以利用判斷式來個別區分不同頁面的 CSS。


2. 屬性順序

CSS 屬性的順序每個人的習慣都不同,有的派別依照字母順序,例如:

.box{border: 1px lolid #333; float:right; font-family: Arial; margin: 20px auto; }
但這種方式我比較不習慣,這篇「CSS代码重构与优化之路」→「3、书写顺序」,依照重要性來排列,我比較喜歡這樣的邏輯:

(1)位置属性(position, top, right, z-index, display, float等)
(2)大小(width, height, padding, margin)
(3)文字系列(font, line-height, letter-spacing, color- text-align等)
(4)背景(background, border等)
(5)其他(animation, transition等)



三、CSS 註解


CSS 團隊開發的最佳實踐」這篇還提供了不少跟 CSS 註解相關的實用資訊

1. 便於搜尋

善用註解除了日後維護、閱讀文件說明方便,還有搜尋的妙用。例如想快速找到標頭區塊(header)的 CSS,我們若搜尋 "header"可能會找到頭暈,因為有數不清的 header。另一種構想是標示中文註解 "標頭",直接搜尋中文準沒錯,但切換中文輸入的速度遠比不上英文。

所以這篇的技巧很不錯,例如結合特殊符號 "=header"的註解,搜尋起來就很快,字串不會重複。

因為 Blogger 有行動版判斷式,可輕易區分網頁版、行動版 CSS,那麼可以這麼設定標頭區塊的註解:

wHeader → 代表網頁版標頭區塊
mHeader → 代表行動版標頭區塊

使用這樣的技巧,一秒鐘就能搜尋到要維護的 CSS 區塊。


2. 標示特殊資訊

這篇還提供一個很棒的觀念,把網頁所有用到的顏色,用註解保存起來,例如:

/*---顏色
綠色 #38761d
藍色 #0b5394
紅色 #990000
---*/

日後要重複使用時會節省很多查詢的時間。



四、CSS 壓縮


美化過的 CSS 碼好閱讀、但佔空間,壓縮過的 CSS 碼無法閱讀、維護,所以我習慣取折衷的方式,例如使用這個 CSS 線上工具:


壓縮選項選擇「High (moderate readbiligy, smaller size」,會將每則 CSS 描述內容個別壓縮為一行顯示,而非全部壓縮為一行。這樣既維持了可讀性,又大幅減少了網頁載入的字元數。



五、CSS 模組化


當網站的 CSS 數量越來越龐大時,為了有效開發及維護,產生了許多模組化的派別。這篇「CSS 的模組化方法」介紹了相當多種模組,例如:

  • 物件導向 OOCSS
  • 結構化命名 SMACSS
  • 區塊化命名 BEM

這篇「Functional CSS 經驗分享」提供一種另類的 Functional CSS,像是把 CSS 用積木組裝,類似 Bootstrap。

很難說哪一種會是最佳解,也許要每個都試試看才能找到讓自己最順手的模組。

以部落格平台來說,要管理的 CSS 數量沒那麼多,我會拿 SMACSS 的概念當基礎,但使用自己習慣的命名邏輯,來組合出順手的管理架構。



六、CSS 技巧


最後補充一些 CSS 使用技巧。

1. RESET


除了讓各個瀏覽器效果一致,使用 CSS Reset 還有很多好處。部落格常會使用各種不同版型,不同的模版會自帶奇奇怪怪的 CSS 預設參數,用 Reset 可清掉、或重設我們習慣的元素參數。


2. CSS 權重


使用 important 是最偷懶的 CSS 修改技巧,久了就會嚐到苦果。因此有必要瞭解 CSS 權重的概念,利用權重覆蓋 CSS 效果,將來才容易維護。


3. CSS 變數

較新版本的瀏覽器都能支援「CSS 變數」,那麼常用的 CSS 參數可以在開頭設定好,各處都能方便的套用,可節省不少時間~


更多 CSS 相關技巧:

協助自架站、WP 搬家到 Blogger 流程紀錄

$
0
0
前陣子接到幾個需求,部落格想要從自架站、WordPress 搬到 Blogger,找上本站尋求協助。嚴格來說這比較不尋常,因為我在「Blogger 是否搬家到 Wordpress 的比較」曾提到,部落格成長週期有三階段:免費部落格平台 → Blogger → 自架站。那麼從自架站搬到 Blogger,等於反轉了部落格的發展曲線。

那麼為何最近多個自架站紛紛逆向搬回 Blogger,我想主要原因大概是這樣:

  • 一開始錯估自己需求,或聽信了朋友、廠商的錯誤資訊,例如「10 個不建議使用 Blogspot 建立網站的錯誤觀念釐清」,部落格直接跳第三階段,每年花費龐大固定成本,而現在後悔了。
  • 部落格型態的網站,如果用不到金流、物流,其實沒必要自架站,除了省下主機、流量、圖床、維護費用,前端自架站、WP 能做到的功能或效果,Blogger 其實都做得到
  • 可能手頭變緊了,開始縮減不必要支出,因而看上 Blogger 架站的優點。

那麼本篇就紀錄一下,協助自架站搬到 Blogger 的過程,所有需要重點處理的項目。

(圖片出處: pixabay.com)


一、搬家重點事項


架設網站、修改版面的部分先不談,搬家主要處理的項目有這些:

  • 搬文章
  • 搬圖片
  • 更換新舊文章連結
  • 搬人氣
  • SEO 移轉

要能順利搬家,最重要的反而不是以上項目的處理,而是「原自架站的主機商、工程師維護人員能否配合」

這件事真的是最麻煩的,自架站可能會遇到這些情形:

  • 原本的工程師跑了,寫的 code 沒人懂、無法維護只好搬家
  • 但如果找不到接手的工程師,或原本的架構無法理解,搬家也會非常困難。
  • 如果原本網站是由主機商處理、代管,那麼搬家也是要花一番唇舌,因為沒有主機商想白白失去生意,那麼得看是否遇到有良心的主機商,至少要提供完整搬移網站檔案、資料庫的權限。

總之,自架站想搬家,得先確定有沒有後端主機的權限,有沒有處理後端各種事務的工程師,這樣子搬家的過程,Blogger 這一端才知道窗口要跟誰聯繫,來處理各種問題。



二、搬文章


1. 匯出 XML

  • WP 可匯出文章成為 XML 檔,但格式與 Blogger 不相容,需要進行轉換後再匯入 Blogger
  • XML 匯入 Blogger 是最方便的處理方式,可一次發佈所有文章
  • 自架站若無法匯出 XML 檔,那麼處理步驟就比較多一些。


2. 自架站

無法用 XML 處理方式時,自架站的工程師要進行許多工作:

  • 將所有文章內容一篇篇抽出來,交由 Blogger 這邊用官方 API 來發佈文章
  • 或者將文章內容自製成 XML 檔,匯入 Blogger
  • 或者以上都做不到的話,至少要有自架站的文章列表,再用爬蟲一篇篇爬,最後用 Blogger API 發佈文章



三、搬圖片


1. 搬到 Blogger

Blogger 的圖片儲存在 Picasa 圖床,由於 2019/3/15 開始,「Picasa 關閉上傳圖片 API」,所以要用程式將圖片搬到 Picasa 已經是不可能的事了。

那麼如果搬家後圖片想要放在 Blogger 的話,需用別的方法,請再與本站聯繫。


2. 搬到其他圖床

放在自架站的圖片,多半是存放在同網域的特定目錄,那麼如果可以找到目錄結構的免費空間,就能夠無痛搬移圖片。

有些空間可以免費存放圖片,例如 Google Drive、Dropbox,但檔案的路徑並非依照目錄結構,所以放這些空間沒有用。

提供幾個目錄結構的空間作為參考:Github、Google Site。

但這些空間不是為了圖床而設計,所以不一定方便處理,且會有流量限制,終究沒有 Picasa 方便、安全。



四、更換新舊文章連結


這部分比較簡單,文章搬完後,取得自架站、Blogger 兩邊的文章列表,用 Blogger API 就能將文章中所有原本自架站的連結,更換為新的 Blogger 文章連結。



五、搬人氣


首先自架站工程師要能撈出原本每篇文章的瀏覽數,讓 Blogger 這邊可以處理。

而 Blogger API 本身沒有提供瀏覽數功能,所以 Blogger 網站需要安裝 Google Analytics,接著再安裝本站開發的「Blogger 文章計數器」,將原本自架站的瀏覽數,合併 Blogger 瀏覽數,即完成搬人氣的功能。



六、SEO


能否將自架站 SEO 移轉到 Blogger,相信是站長們最關切的問題,一般常聽到移轉 SEO 可能會失敗,或是要花上幾個月,也不一定能全部移轉。

實際上從 WP、自架站搬到 Blogger,完全可以無痛移轉、也不需要花時間,因為自架站直接就能設定 301 轉址,以下說明流程:

  • 假設自架站是 xxx.com 這樣的網址,Blogger 是 xxx.blogspot.com 這樣的網址。
  • 搬完所有文章後,可得到兩個網站的文章列表資料
  • 自架站工程師根據兩邊的資料,比對後可為自架站的所有文章設定 301 轉址,直接跳轉到 Blogger 網址。
  • 搬完家後如果網址、或主機的約剩沒幾個月,可以先延長一年,讓文章 SEO 權重有足夠的時間過戶到新的 Blogger 網址
  • 搬到 Blogger 半年 ~ 一年的時間,可以確定 SEO 權重都已經移轉新的文章網址後,再為 Blogger 網站設定原本網址,也就是 xxx.com 的形式
  • 做到這個階段時,就可以跟原本的主機解約。



七、總結


做個結論,本篇內容需分兩部分來看:

1. 自架站

本篇的記錄主要針對自架站,因為自架站有可能用任何後端語言來寫,所以比較需要原工程師的協助,才可能完整地從後端將各種資料撈出來,例如「人氣」這樣的數據。

如果真的原工程師跑了,那麼只好寫爬蟲程式來爬前端的文章、資料,而某些存在後端的「人氣」數據,就不一定能搬了。


2. WordPress

如果是 WP 要搬到 Blogger,難度就比較低了,可以不需要原工程師的協助,只要請原主機商提供 FTP 權限,可以把網站檔案、資料庫複製出來,後續的處理原理都跟本篇自架站記錄相同。



八、聯絡表單


自架站、WP 可處理的搬家項目有這些:

  • 搬文章
  • 搬圖片
  • 處理新舊文章連結
  • 搬人氣
  • SEO 移轉


需要協助搬家請告知:

  • 網址
  • 文章篇數
  • 需要處理的搬家項目

並用以下表單與我聯繫:




更多部落格搬家相關文章:


更多 WordPress 相關文章:

Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

$
0
0
blogger-android-app-publish-post.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理Blogger 社團這則「討論串」詢問 "是否有什麼app可以編輯好圖文然後上傳",原本認為這是很困難的事,因為年初 Google 宣布「Picasa 關閉上傳圖片的 API」,導致現在 Blogger 發文軟體已經沒有用處了,例如知名的 Open Live Writer (簡稱 OLW),而我也寫了這篇「Blogger 無法使用 OLW 後,寫文章有什麼替代方案?」。

不過實際拿了幾個 Android APP 測試之後,卻又發現不是這麼回事,原來 OLW 不能用 Blogger 發文,不代表行動裝置 APP 不能發文,因此本篇整理一下我的測試心得。



一、Blogger 官方 APP


  • Google Play:安裝網址
  • 最後更新:2016年2月29日
  • 評價:差勁

官方的 APP 反而是最爛的一個,根本完全無法使用,非常懷疑真的是官方釋出的產品嗎。



二、Blogger (New)


  • Google Play:安裝網址
  • 最後更新:2019年3月1日
  • 評價:無

blogger-android-app-publish-post-1.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

這個 APP 我覺得很有趣,如上圖是進入 APP 後的畫面,這不就是 Blogger 網頁版的後台嗎?那麼自然跟官方 APP 相比,絕對可以發佈文章啦。

不過有瀏覽器還特地安裝這個 APP 要做什麼,直接打開瀏覽器進入後台不就好了~~然後滿幽默的是,這 APP 的更新日期還滿近的,不太清楚要更新什麼。



三、Blogger Pro


  • Google Play:安裝網址
  • 最後更新:2019年4月28日
  • 評價:不錯

這個 APP 可以成功上傳圖片,讓我覺得非常神奇,代表 APP 並非使用 Google 廢棄的 Picasa API,也許這個 APP 有跟 Blogger 官方合作,可能有付費得到授權。


blogger-android-app-publish-post-2.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

上圖的畫面也讓我感到驚艷,APP 介面算是做的相當好、很有質感。


blogger-android-app-publish-post-3.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理


上圖相當於 Blogger 網頁版的「撰寫模式」,工具列有「繼續閱讀」功能可插入。

上傳的圖片有超連結可連到原始尺寸,顯示的圖片最多 512px 寬

美中不足的是,這個 APP 沒有「HTML 模式」,所以只能進行簡單的圖文處理。



四、BlogIt


  • Google Play:安裝網址
  • 最後更新:2019年4月29日
  • 評價:最佳選擇

這個 APP 同樣能成功上傳圖片,也許同樣有跟 Blogger 官方合作,有付費得到授權。

而上傳的圖片沒有產生超連結,不過可顯示原圖尺寸


blogger-android-app-publish-post-4.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

文章列表介面比較陽春,但反而比較實用,選擇要編輯的文章比較省時間。


blogger-android-app-publish-post-5.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

編輯文章時首先會看到「撰寫模式」,但工具列看不到「繼續閱讀」按鈕。

但值得稱讚的是,這個 APP 允許編輯「HTML」,如上圖操作即可。



blogger-android-app-publish-post-6.jpg-Blogger 可以在行動裝置發佈文章+上傳圖片的 APP 整理

切換到「HTML 模式」後,右下角就可看到「繼續閱讀」按鈕了。

但是需要注意的是,每次編輯時,繼續閱讀語法會變成上圖紅框處的 HTML 語法,等儲存後,繼續閱讀的功能就會失效。

所以每次重新編輯,都要刪除這段語法,按右下角「繼續閱讀」按鈕,產生真正的繼續閱讀語法,再儲存才行,這是該 APP 需要解決的問題。

不過綜合比較下來,「BlogIt」我認為是 Android APP 中最好的選擇。



五、實用的作法 Chromebook


如果你是尋找 OLW 替代品的 Blogger 站長,那麼本篇的內容或許會有一點點的參考價值,雖然使用手機發佈 Blogger 文章操作很麻煩,這個選擇不太實際,但若有一個作業環境能夠執行 Android APP,那麼說不定可以成為 OLW 的替代品。

這樣的作業環境,最佳解會是 Chromebook,因為可以執行 Android APP。如果你有 Chromebook 筆電,就不用忍受手機的操作環境,可以試試看執行「BlogIt」來取代 OLW,發佈 Blogger 文章。





更多 Blogger 相關文章:

前端如何使用 JS 先壓縮圖片尺寸大小再進行上傳,有效節省儲存空間﹍實作範例

$
0
0
js-compress-resize-image-canvas.jpg-前端如何使用 JS 先壓縮圖片尺寸大小再進行上傳,有效節省儲存空間﹍實作範例以前處理過一個客製系統,有多處需要註冊會員上傳圖片:

  • 會員頭像
  • 證件留底
  • 設施環境介紹照片

由於使用者各種年齡層都有,不是每個人都網路世代,懂得先壓縮 JPG 檔再上傳,那麼上傳的圖片檔案可能會超出工程師想像。大部分中高齡使用者可能直接從手機選了圖片就上傳,也不會知道這張圖片到底多大。現在手機鏡頭越來越高級,照出來的圖片預設原始尺寸也越來越大,一張圖好幾 MB 是常態,超過 5MB 也是有可能的事。

以站長的角度,絕不願意儲存在後端的圖片,佔用這麼大的空間,除了要付更多費用,同時浪費頻寬、網頁存取速度也慢。

因此本篇介紹的 Javascript 技術非常實用,可以在上傳圖片之前,從前端就先改變圖片尺寸,並進行壓縮減少檔案大小,減少後端的作業及空間。

(圖片出處: pixabay.com)


一、上傳圖片的基本知識


1. 網路空間

上傳圖片功能最重要的是需先準備一個存放空間,如果是自架站就比較沒問題,使用自己的空間不會有任何限制。

如果沒有空間的話,那麼以本站作為舉例,「留言開放上傳圖片」功能,而圖片是則上傳到免費的 Google Drive,圖片的顯示使用 Google Drive 提供的分享連結(上傳後即可取得此連結),讓訪客另開視窗來看圖片。


2. 上傳按鈕

接下來在網頁上製作「上傳按鈕」,利用 HTML5 的 File API 取得圖片內容,再進行上傳。

這部分的範例程式碼,可參考這篇「前端操作 Apps Script 上傳檔案到 Google Drive 並取得連結」。



二、壓縮圖片原理


完整的原理說明,可參考這篇「圖片純前端JS壓縮的實現」,以下進行關鍵分解說明。


1. 調整圖片尺寸

取得圖片後,接下來需要利用 HTML5 Canvas 的「drawImage()」方法:

drawImage(圖片, 0, 0, 圖片寬度, 圖片高度)
使用這些參數後,可以更改圖片尺寸。


2. 壓縮圖片

上傳圖片之前,利用 Canvas 的「toBlob()」可設定壓縮比例:

canvas.toBlob(回傳函數, 檔案格式, 壓縮比例)

基本上要設定壓縮比例的話,通常要處理 jpg 檔,那麼可以用這樣的參數:

canvas.toBlob(callback, "image/jpeg", 0.8)
這樣代表 jpg 檔的壓縮比例為 80%。

如果檔案類型用 png、gif 檔是不能壓縮的,設定了壓縮比例會被無視。


3. 瀏覽器支援度

HTML5 Canvas 的 toBlob(),這個函數的使用說明及瀏覽器支援度請參考「HTMLCanvas​Element​.toBlob()」,看起來 IE、Edge 都是不支援的。



三、壓縮圖片範例程式碼


需先載入 jQuery、Bootstrap,如網頁已安裝過,請移除綠字部分的程式碼:

<label class="btn btn-info"><input id="upload_img" style="display:none;" type="file"><i class="fa fa-photo"></i> 上傳圖片</label>

<div id="oldImg"></div>

<div id="newImg"></div>

<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css" rel="stylesheet"></link>
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>

<script>
(function($) {
var compressRatio = 0.8, // 圖片壓縮比例
imgNewWidth = 400, // 圖片新寬度
img = new Image(),
canvas = document.createElement("canvas"),
context = canvas.getContext("2d"),
file, fileReader, dataUrl;

// 上傳檔案
$("#upload_img").change(function() {
file = this.files[0];
// 圖片才處理
if (file && file.type.indexOf("image") == 0) {
fileReader = new FileReader();
fileReader.onload = getFileInfo;
fileReader.readAsDataURL(file);
}
});

function getFileInfo(evt) {
dataUrl = evt.target.result,

// 取得圖片
img.src = dataUrl;
}

// 圖片載入後
img.onload = function() {
var width = this.width, // 圖片原始寬度
height = this.height, // 圖片原始高度
imgNewHeight = imgNewWidth * height / width, // 圖片新高度
html = "",
newImg;

// 顯示預覽圖片
html += "<img src='" + dataUrl + "'/>";
html += "<p>這裡是原始圖片尺寸 " + width + "x" + height + "</p>";
html += "<p>檔案大小約 " + Math.round(file.size / 1000) + "k</p>";
$("#oldImg").html(html);

// 使用 canvas 調整圖片寬高
canvas.width = imgNewWidth;
canvas.height = imgNewHeight;
context.clearRect(0, 0, imgNewWidth, imgNewHeight);

// 調整圖片尺寸
context.drawImage(img, 0, 0, imgNewWidth, imgNewHeight);

// 顯示新圖片
newImg = canvas.toDataURL("image/jpeg", compressRatio);
html = "";
html += "<img src='" + newImg + "'/>";
html += "<p>這裡是新圖片尺寸 " + imgNewWidth + "x" + imgNewHeight + "</p>";
html += "<p>檔案大小約 " + Math.round(0.75 * newImg.length / 1000) + "k</p>"; // 出處 https://stackoverflow.com/questions/18557497/how-to-get-html5-canvas-todataurl-file-size-in-javascript
$("#newImg").html(html);

// canvas 轉換為 blob 格式、上傳
canvas.toBlob(function(blob) {
// 輸入上傳程式碼
}, "image/jpeg", compressRatio);
};
})(jQuery);
</script>

  • compressRatio 參數 0.8 請改為自訂壓縮比
  • imgNewWidth 參數 400 請改為自訂寬度 px 值
  • 其餘說明請見程式註解,需要自訂功能請直接修改原始碼


js-compress-resize-image-canvas-1.jpg-前端如何使用 JS 先壓縮圖片尺寸大小再進行上傳,有效節省儲存空間﹍實作範例

此範例程式碼的效果大致如上圖,後面有展示用的「上傳按鈕」可自行玩玩看效果。



四、圖片壓縮效果展示


點擊下方的「上傳按鈕」,上傳 jpg 圖片後,會將圖片尺寸等比例縮小為 400px 寬,並壓縮為 80%,有效縮減檔案大小,又不降低圖片品質。








更多網頁開發工具:

使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例

$
0
0
gmail-api-insert-image-html-google-apps-script.jpg-使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例上一篇說明完「使用 Gmail API 寄信簡易管道」流程,接著要實作利用 Gmail API 在郵件中插入圖片。

其實處理純文字郵件就已經挺複雜麻煩了,然而跟本篇相比,還算是小巫見大巫。啃了大量的郵件通訊格式資訊後,結果發現就算是使用完全正確的格式,Gmail API 也不見得就能相容,測試過程相當痛苦。不過最終總算找出一個可行的作法,請見本篇心得整理。

(圖片出處: stocksnap.io)


一、MIME 郵件規範


要在郵件中插入圖片(非附件),可使用 IMG 標籤,也代表要使用 HTML 語法,那麼需要先理解郵件的格式規範如何加入 HTML 內容。

1. MIME 郵件架構

要在郵件中使用純文字以外的內容,必須使用 MIME 架構,首先請先看這篇「MIME中的Multipart/mixed」瞭解原理,根據不同的架構類型,可分成三種:

  • multipart/alternative:可使用純文字、HTML 語法
  • multipart/related:前一種再加上內嵌物件(例如圖片)
  • multipart/mixed:前一種再加上附件


這三種架構使用巢狀方式嵌套,必須符合嚴謹的嵌套邏輯,一層層包覆,這篇「Multi-Part MIME Messages」提供了圖解,借用下面這張圖可以一眼就非常清楚地理解:

gmail-api-insert-image-html-google-apps-script-1.png-使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例

這篇也提供了詳細的範例程式碼,搭配圖片可以快速理解如何製作 MIME 郵件內容。


2. Multipart/Alternative 架構

要在郵件中插入 HTML,至少需使用 Multipart/Alternative 架構,以下提供一個完整的郵件內容範例,同時包含純文字與 HTML 的部分:

To: waynefu.g@gmail.com
Subject: 測試郵件主旨
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="wfublog"

--wfublog
Content-Type: text/plain; charset="utf-8"

這裡是純文字內容!!!

--wfublog
Content-Type: text/html; charset="utf-8"

welcome to WFU BLOG
這裡是 HTML 內容
文字可以上色

--wfublog--



3. Multipart/Related 架構

要在郵件中插入行內(inline)圖片,至少需使用 Multipart/Related 架構,以下提供一個完整的郵件內容範例:

To: waynefu.g@gmail.com
Subject: 測試郵件主旨
Mime-Version: 1.0
Content-Type: multipart/related; boundary=wfublog1

--wfublog1
Content-Type: multipart/alternative; boundary=wfublog2

--wfublog2
Content-Type: text/html; charset=utf-8

<p>這封完全是 HTML 郵件</p>
<img src='cid:wfublog_img'/>
<p>在兩行文字間插入圖片</p>
--wfublog2--

--wfublog1
Content-Type: image/jpeg; name=flag.jpg
Content-Disposition: inline; filename=flag.jpg
Content-Transfer-Encoding: base64
Content-ID: <wfublog_img>

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAsICAoIBwsKCQoNDAsNERwSEQ8PESIZGhQcKSQrKigkJyctMkA3LTA9MCcnOEw5PUNFSElIKzZPVU5GVEBHSEX/2wBDAQwNDREPESESEiFFLicuRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUX/wAARCAAVACADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDm7qJL74g31rd3bwW73sgZt5GBuNR+M7C00bVFg0u/kniK5J8wnBqz4h0+2fxFqTtGSzXMhJ3H+8azTp1sxyUJPqWNdyzjDxkm+bRWtZf5nsx4fxU4qScdfN/5FxJ5fLX94/QfxGp7aaU3MX7x/vj+I+tVgMAAdBUtt/x9Rf74/nXy7d5XPtuRKFrdD0e++HSX1/cXR1JkM0jSbfJBxk5x1qv/AMKwj/6Cjf8Afgf/ABVFFer9XpvWx8BHN8bFKKnovJf5B/wrCP8A6Cjf9+B/8VTo/hnHHIr/ANpsdpBx5A/+KoopfV6XYf8AbGNentPwX+R//9k=

--wfublog1--




二、Gmail API 會遇到的問題


前面的郵件範例都是合法的格式,但餵給 Gmail API 後會有很多問題需要注意:

1. 雙引號問題

前面「Multipart/Alternative」的範例請注意這一行:

Content-Type: multipart/alternative; boundary="wfublog"
boundary 的參數使用雙引號 ""是標準作法,如果不小心使用了單引號 '',會導致整封 MIME 郵件無法被 Gmail 解析,全部變成純文字,這是很大的坑需注意。

為了避免麻煩,MIME 格式的郵件,需要使用參數時可全部省略雙引號,例如參考「Multipart/Related」的範例,全部移除了雙引號,郵件仍可被解析。


2. 換行次數的問題

這也是超級大的坑,換行符號使用的次數若不對,Gmail 就無法正確解讀郵件內容。

Content-Type: multipart/alternative; boundary="wfublog"
同樣是這一行,後面必須使用 2 次換行符號,如果只使用 1 次會導致郵件寄不出去。


Content-Type: text/plain; charset="utf-8"
在郵件開始文字內容的前一行,也就是上面這行內容,後面必須使用 2 次換行符號,如果只使用 1 次會看不到郵件內容。


3. Multipart/Alternative 問題

雖然 MIME 郵件允許純文字、HTML 格式並存,但似乎 Gmail 無法同時接收這兩種格式,來看實例,試著將前面「Multipart/Alternative」的範例內容寄出:

gmail-api-insert-image-html-google-apps-script-2.png-使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例


收到郵件後,只有第二個部分 HTML 內容可顯示。

gmail-api-insert-image-html-google-apps-script-3.png-使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例


然而檢視郵件原始內容後,會發現純文字內容是有被 Gmail 接收到的,但就是無法顯示。

經交叉測試可發現,若將兩個部分位置交換,則郵件會顯示純文字內容,而 HTML 內容無法顯示。

這也代表說,「Multipart/Alternative」郵件有多個部分時,只會顯示最後一個部分的內容。



三、GAS 範例程式碼


瞭解以上所有相關知識及資訊後,以下來看 Google Apps Script 的範例程式碼:


  • 以上範例碼,比較基本的原理請直接參照「使用 Gmail API 寄信簡易管道」,本篇省略說明。
  • 本篇比較重要、需要注意的地方,直接用註解提醒
  • 例如所有需要使用兩次換行的地方
  • 為了避免麻煩,MIME 郵件所有等於 "="後面的參數都可省略雙引號

下面是收到範例程式碼寄出的郵件畫面:

gmail-api-insert-image-html-google-apps-script-4.png-使用 Gmail API 讓郵件插入圖片及 HTML﹍Google Apps Script 障礙排除 + 實作範例

可成功顯示插入的文件及 HTML 語法!


更多 Gmail 相關文章:

jQuery 相簿畫廊外掛 nanogallery2﹍排版效果與功能都十分強大

$
0
0
jquery-gallery-grid-plugin-nanogallery.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2在網頁上展示相簿圖片可以有幾種作法,最常見的是使用輪播效果,過去介紹過幾個知名的 jQuery 外掛(使用 CDN):


輪播在畫面上的視覺效果,能同時展示的數量有限,如果希望一次展示 10 張圖或更多數量時,則需要網格(Grid)這類的外掛。而根據不同的排版方式,也需要尋找不一樣的外掛。

本篇找到一個免費的超強悍外掛「nanogallery」,功能、質感、特效完全不輸付費軟體,而且本身就能實現各種網格排列效果,等於一套工具可抵至少 3~4 個外掛。

而且更貼心的是這外掛提供了 CDN 外連,站長們不需再費心尋找網路空間存放檔案,本篇也會展示範例效果及提供範例程式碼。





一、官網介紹


jquery-gallery-grid-plugin-nanogallery-0.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2



基本上官網製作的很詳盡,而且若是你的相簿圖片符合以下條件,還可使用官方提供的懶人包產生器,非常方便:

  • 放在特定的網址路徑
  • 使用 Flickr 相簿

原本這個外掛有支援 Google Photo 相簿,但因為 Google 的 API 改版,所以現在已經無法用懶人包產生器抓 Google Photo 的圖片了,那麼選擇 Google Photo 時會提示錯誤訊息

另外很可惜的是,如果沒用官方的懶人包產生器,也就是必須自行抽出自己相簿中、一張張的所有圖片外連,來套用這個工具的話,雖然官方操作說明書做的很詳細,但我覺得只適合前端工程師閱讀,一般使用者應該覺得像在看天書,要成功的話難度非常之高。

本篇整理了簡單的範例程式碼,直接套用的話成功率會比較大。



二、各種排版效果


官網首頁提供了 4 種排版類型的範例效果,以下簡單介紹:

1. Mosaic 拼貼式

jquery-gallery-grid-plugin-nanogallery-1.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2

很有藝術感的版面配置,修改一下參數就能變化出各種不規則的拼貼效果。官方也有提供另一種版面比較整齊的拼貼效果(例如本文開頭的圖片)

滑鼠經過時會有放大的特效,若圖片沒全部展示完,右下角會顯示剩餘圖片數。


2. Grid 網格式

jquery-gallery-grid-plugin-nanogallery-2.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2

中規中矩、最常見的排版方式,本篇將以此效果來舉例說明。

滑鼠經過時會有放大標題文字的特效,若圖片沒全部展示完,下方會有剩餘圖片數的提示按鈕。


3. Justifed 對齊式

jquery-gallery-grid-plugin-nanogallery-3.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2

這種左右對齊的排版方式比較活潑、沒那麼呆板。

滑鼠經過時會出現標題文字,以及數個功能按鈕,效果意外的好。

下方則有分頁的導航按鈕。


4. Cascading 瀑布式

jquery-gallery-grid-plugin-nanogallery-4.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2

瀑布流的排版很生動,但也許不是那麼好駕馭,個人沒那麼喜好,因為最下方的版面參差不齊。



三、燈箱效果


除了相簿畫廊的排版展示效果之外,點擊圖片後的畫面也非常值得介紹:

jquery-gallery-grid-plugin-nanogallery-5.jpg-十分強大的 jQuery 相簿畫廊外掛﹍nanogallery2

觀看個別圖片時會立即進入燈箱效果,一一說明功能:

  • 左上顯示總圖片數、目前圖片
  • 點擊播放按鈕會進行自動播放
  • 右上分別有關閉、全螢幕、旋轉等等功能,非常專業
  • 除了有左右箭頭可切換圖片,實際上直接點擊圖片偏左、偏右處,也能切換圖片,設計非常貼心
  • 下方也有各種功能按鈕,可顯示圖片資訊、分享、另開視窗等等,非常齊全
  • 直接按 Esc 也可離開燈箱畫面,回到畫廊



四、範例程式碼


以下提供「Grid 網格式」的範例程式碼:


1. 載入外掛

首先需要載入 jQuery 以及官方提供的 CDN 外連:

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<link href="https://unpkg.com/nanogallery2/dist/css/nanogallery2.min.css" rel="stylesheet" type="text/css"></link>
<script type="text/javascript" src="https://unpkg.com/nanogallery2/dist/jquery.nanogallery2.min.js"></script>



2. 主程式

接著在展示相簿圖片的地方,插入以下程式碼:


請參照以下修改說明:

  • A 行 與 C 行綠色 ID 字串請一致
  • D、E 行可自訂縮圖寬度、高度
  • G 行可設定預設顯示的縮圖行數
  • H ~ AN 行放入所有圖片網址相關資訊,頭尾用括號 [] 包起來:
    • 每一組圖片的資訊,分別用 {} 包起來,彼此用小寫逗號 ","隔開,最後一組圖片的刮號後面不可有小寫逗號
    • 每組圖片需分別填入 3 組字串,也就是 I ~ K 行標示的綠色字串
    • src: 原始圖片網址
    • srct: 縮圖網址
    • title: 圖片描述字串
  • 請依照以上處理邏輯來新增、刪減圖片相關資訊


以上範例程式碼的展示效果,請見下面範例網頁,同時此範例網頁提供了兩種縮圖比例的效果:




五、補充說明


雖然這個「Grid 網格式」可設定縮圖尺寸,但實際執行上並非完全依照設定的尺寸呈現,而是依照縮圖比例自動根據寬度進行 RWD 調整,這是更好的設計

這個外掛可以設定的參數非常多,請詳閱官方說明書進行修改,來達到自己想要的效果。

本篇只提供了「Grid 網格式」的效果,將來視情況有可能介紹其他版面效果。

由於需要一張張圖片手動進行細部設定,所以一定程度上可說是相當瑣碎,這件事最好是能夠由程式代勞比較輕鬆。

如果之後研究成功的話,將來應該會提供支援 Google Photo 相簿的功能,可直接載入相簿中的圖片,省下逐筆填入圖片網址的時間。


更多圖片展示工具:

Google Cloud Platform 架設 WordPress 心得整理﹍HTTPS + FTP + 永遠免費方案

$
0
0
google-cloud-platform-wordpress-https-ftp.jpg-Google Cloud Platform 架設 WordPress 心得整理﹍HTTPS + FTP + 永遠免費方案最近處理客戶需求得使用 WP 作業一段時間,想到「Google Cloud Platform 雲端平台」(以下簡稱 GCP) 提供了一年免費測試的服務,剛好可以來研究看看。

而且如果測試網站流量不大,那麼 GCP 還有「一律免費」方案,符合條件時也是有可能架設的 WP 網站一直都不用收費。



一、各種架站方式比較


基本上 GCP 提供使用者第一年 USD 300 (平均一個月 USD 25)的測試額度,沒意外一定是用不完,但根據不同的架站方式,第二年開始可能就會產生費用了。

1. GCP + Bitnami

一般來說架設 WP 網站是非常麻煩的,需要搞懂後端環境、資料庫架構、運作原理等等。不過就像以前有「一鍵安裝 Windows 系統」這樣的封裝包,現在有個服務「BitNami」,專門整合各種開源軟件、開發框架等,也包含了 WP。

GCP 提供了 BitNami 的快速架設 WP 方案,滑鼠點幾下就能在幾分鐘內自動架好 WP,非常方便也不需瞭解背後運行的原理,可以說是前端使用者的福音。

這個方式架站的缺點是,GCP 不提供完整的 FTP 權限(不能直接存取 WP 目錄),也許是為了安全性考量(不能存取就比較不會被駭),但必須說真的不太方便。


2. 從 Bitnami 官網安裝

還好在 GCP 使用 Bitnami 的方案架設 WP,不一定要從 GCP 官網來進行,若是改從 Bitnami 官網安裝,Bitnami 會另外提供一些好用的工具,並且提供權限更高的金鑰,可以使用 FTP 直接存取 WP 目錄,從而解決第一種方式的不便。


3. 完全免費方案

前兩種方式都是使用 Bitnami 的快速架站服務,節省了大量時間,那麼第二年起自然就要付費,至少每個月 USD 5。

想要真的在 GCP 上完全免費,只好花自己的時間來換取,同時最好相關的知識都瞭解,然後安裝免費的 SSL、處理 FTP 金鑰等瑣事全部自己來,這是沒辦法的事。



二、Bitnami 官網 + HTTPS + FTP


首先說明麻煩最少的流程,從 Bitnami 官網安裝 WP 的優點:

  • 會定期自動幫 SSL 憑證續約,確保 HTTPS 不會開天窗
  • 提供 FTP 較高權限金鑰,能直接存取 WP 根目錄


詳細的操作流程,可直接參考這篇進行即可:



這個流程除了需要啟用 GCP,也要另外在 Bitnami 註冊一個帳號,再連結 GCP 帳號。整個流程步驟比較多,也可能比較複雜,若是新手可先嘗試「四、從 GCP 安裝 Bitnami」的流程,成功的話再回頭來挑戰這個方案。


google-cloud-platform-wordpress-https-ftp-1.jpg-Google Cloud Platform 架設 WordPress 心得整理﹍HTTPS + FTP + 永遠免費方案

需要注意的是,方便必需付出昂貴的代價。請見上圖,Bitnami 官網不允許選擇最便宜的 CPU「f1-micro」方案(每月 USD 4.6),最少要選擇「g1-small」(每月 USD15.33),價格差了 3 倍



三、完全免費架設 WP


如果有預算考量,連第二年後也不想花錢,那麼就無法使用任何 Bitnami 方案,得自己搞定:

  • 所有後端環境
  • 免費 SSL 憑證申請,自行處理憑證延期
  • FTP 環境設定,很可能無法擁有完整金鑰權限,操作 FTP 軟體時會很麻煩


以下提供幾種自行架設 WP 的方式:




四、從 GCP 安裝 Bitnami


如果 WP 網站不是長期使用,也許不一定常常需要 FTP,那麼可以考慮從 CGP 安裝 Bitnami 就好。

安裝流程可參考這篇「透過bitnami在Google cloud platform上架設自動更新憑證的wordpress」,這個方案會幫我們申請免費 SSL 以及自動延展憑證。

如果覺得這篇的說明比較簡略,同時可參考「使用 Google Cloud Platform 雲端主機免費版架設 WordPress 教學」補上某些較詳細的步驟。


google-cloud-platform-wordpress-https-ftp-2.jpg-Google Cloud Platform 架設 WordPress 心得整理﹍HTTPS + FTP + 永遠免費方案

可參考上圖,跟前面「二、Bitnami 官網 + HTTPS + FTP」選擇一模一樣的方案,但從 GCP 安裝可以選擇最便宜的 CPU,一個月只要 USD 5 左右,剩 1/3 的價格



五、其他問題


補充一些相關細節:

1. HTTPS

申請完 SSL 憑證後,不代表網頁會自動跳轉為 HTTPS 網址,所以需要參考「在 WordPress 設定 HTTPS,強制使用 SSL 安全加密協定教學」進行設定,若訪客進入 HTTP 頁面時可轉到 HTTPS 網址。


2. FTP 替代方案

實際上本篇的三種架站方式,只有「二、Bitnami 官網 + HTTPS + FTP」可以順暢的使用 FTP。

當使用另外兩種方案時,例如抓了某外掛的檔案,想要從 FTP 上傳到 WP 外掛的路徑,就會知道痛苦了,因為 GCP 不提供 FTP 存取 WP 所有目錄的權限。

我找到的解決方式為,在 WP 後台安裝「File Manager」這個外掛。

雖然可能沒有跟 FTP 一樣方便,但這個外掛的介面就跟檔案總管差不多,要刪除檔案、目錄,或是上傳檔案、目錄,都有很方便的介面,還不需要管 FTP 那些金鑰、權限等問題,也算是不錯的替代方案了。


更多 WordPress 相關文章:

讓 RWD 表格能自動排序

$
0
0
rwd-table-sort-scroll.jpg- RWD 表格能自動排序過去為網頁表格的處理寫了不少文章,例如「自適應 RWD 表格」、「讓網頁表格自動排序」。

後來發現,效果比較好的 RWD 表格,因為手機的表格形式跟網頁已經完全不一樣,那麼在行動版將無法做到自動排序。

有次無意間在手機看到 NBA 的統計數據表格,算是比較傳統的 RWD 表格形式,才想到這樣的 RWD 表格型態,就能夠進行排序了。

那麼本篇會提供範例程式碼,讓手機也能看到表格的排序效果。



一、能夠排序的表格型態


1. 各種方案

這部分的內容之前介紹過了,不過仍有必要再說明一次。自適應表格可以有幾種處理方式:

  1. 隱藏部分內容
  2. 讓表格出現水平捲軸
  3. 將橫向標題欄位改為直向,重新排版

這個網頁「Responsive Table」很詳細地整理了以上幾種解決方案,同時頁面上也可直接看到各種方案的即時展示效果,請切換頁簽即可。


2. 可以排序的表格型態

只有 1、2 這兩個形式可以藉由外掛來進行排序,也就是傳統的表格形式。而效果比較好的會是 2,使用水平捲軸,才不會遺失所有資訊。

但使用水平捲軸的版面效果沒那麼好,訪客很可能不知道畫面之外還有資訊,必須在畫面邊緣做處理,讓訪客知道還有沒看到的內容等待捲動。



二、範例效果


權限會員編號暱稱性別註冊時間EmailID聯絡電話聯絡地址購買項目會員點數
加值會員W00001Wayne男生2014/9/12wayne@gmail.com1111111110912345678台北市信義區信義路五段1號Blogger015000
一般會員W00002Chen女生2014/9/17chen@gmail.com2222222220923456789台北市信義區信義路五段2號Blogger0250
一般會員W00003Ken男生2014/9/17ken@gmail.com3333333330934567890台北市信義區信義路五段3號Blogger03500
一般會員W00004Sung男生2014/9/17sung@gmail.com4444444440945678901台北市信義區信義路五段4號Blogger04100
一般會員W00005Liu男生2014/9/17liu@gmail.com5555555550912345678台北市信義區信義路五段5號Blogger0550

上面這個範例表格在網頁版會出現捲軸,訪客可知道要往右捲

也請用手機看這個表格的效果。


rwd-table-sort-scroll-1.jpg- RWD 表格能自動排序

行動版不會自動出現捲軸,因此表格右邊使用漸層透明的效果,暗示使用者可以往右捲看更多內容,這是很好的 RWD 設計。



三、範例程式碼


以下的表格範例程式碼,就是上面的範例表格,使用的外掛及原理跟「讓網頁表格能自動排序﹍TableSorter 安裝懶人包」一模一樣,因此注意事項請直接參考該篇的解說,此處不再詳細說明:

<div class="table_outer"><div class="table_scroll">
<table id="myTable" class="tablesorter">
<thead>
<tr>
<th>權限</th>
<th>會員編號</th>
<th>暱稱</th>
<th>性別</th>
<th>註冊時間</th>
<th>Email</th>
<th>ID</th>
<th>聯絡電話</th>
<th>聯絡地址</th>
<th>購買項目</th>
<th>會員點數</th>
</tr>
</thead>
<tbody>
<tr><td>加值會員</td><td>W00001</td><td>Wayne</td><td>男生</td><td>2014/9/12</td><td>wayne@gmail.com</td><td>111111111</td><td>0912345678</td><td>台北市信義區信義路五段1號</td><td>Blogger01</td><td>5000</td></tr>
<tr><td>一般會員</td><td>W00002</td><td>Chen</td><td>女生</td><td>2014/9/17</td><td>chen@gmail.com</td><td>222222222</td><td>0923456789</td><td>台北市信義區信義路五段2號</td><td>Blogger02</td><td>50</td></tr>
<tr><td>一般會員</td><td>W00003</td><td>Ken</td><td>男生</td><td>2014/9/17</td><td>ken@gmail.com</td><td>333333333</td><td>0934567890</td><td>台北市信義區信義路五段3號</td><td>Blogger03</td><td>500</td></tr>
<tr><td>一般會員</td><td>W00004</td><td>Sung</td><td>男生</td><td>2014/9/17</td><td>sung@gmail.com</td><td>444444444</td><td>0945678901</td><td>台北市信義區信義路五段4號</td><td>Blogger04</td><td>100</td></tr>
<tr><td>一般會員</td><td>W00005</td><td>Liu</td><td>男生</td><td>2014/9/17</td><td>liu@gmail.com</td><td>555555555</td><td>0912345678</td><td>台北市信義區信義路五段5號</td><td>Blogger05</td><td>50</td></tr>
</tbody>
</table>
</div></div>
<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.30.5/css/theme.blue.min.css"></link>
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.30.5/js/jquery.tablesorter.min.js"></script>
<script>
$("#myTable").tablesorter({
theme: "blue",
widgets: ['zebra']
});
</script>
<style>
.table_outer {position: relative;}
.table_scroll{overflow-x: auto;}
.table_outer:after { content: ""; display: block; width: 100px; height: 100%; position: absolute; top: 0; right: 0; z-index: 1; background: -moz-linear-gradient(left, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 0.7) 40%, rgba(255, 255, 255, 1) 100%); background: -webkit-gradient(linear, left top, right top, color-stop(0%, rgba(255, 255, 255, 0)), color-stop(40%, rgba(255, 255, 255, 0.7)), color-stop(100%, rgba(255, 255, 255, 1))); background: -webkit-linear-gradient(left, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 0.7) 40%, rgba(255, 255, 255, 1) 100%); background: -o-linear-gradient(left, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 0.7) 40%, rgba(255, 255, 255, 1) 100%); background: -ms-linear-gradient(left, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 0.7) 40%, rgba(255, 255, 255, 1) 100%); background: linear-gradient(to right, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 0.7) 40%, rgba(255, 255, 255, 1) 100%); filter: progid: DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#ffffff', GradientType=1); }
#myTable{margin-bottom: 0;}
#myTable * { white-space: nowrap; }
#myTable th:last-child { padding-right: 100px; }
</style>

比較特別的地方大致說明一下:

  • 為了讓表格標題、內容不斷行,CSS 必須加入 white-space: nowrap
  • 為了讓表格出現捲軸,Table 外面需要包一個 DIV,設定 overflow-x: auto
  • 為了讓表格右邊有 100px 寬的區塊,顯示漸層透明效果,外面還要再包一層 DIV,利用 position: absolute 設定「漸層透明區塊」的絕對位置
  • 為了不影響表格最後一欄的排序功能,最後一欄要加上 padding-right: 100px


更多「表格」使用技巧:

Blogger 文章自動產生大綱索引錨點區塊

$
0
0
blogger-post-headline-anchor-area.jpg-Blogger 文章自動產生大綱索引錨點區塊今年的 Blogger 架站案例中,好幾個都要求在文章中製作一個區塊,裡面擺放多個錨點超連結,點擊後可跳到文章中對應的大標題。

雖然每個案例的客製執行效果都不同,有的將這個區塊放在側邊欄浮動,有的希望每個錨點分別出現在自訂位置,有的希望所有錨點集中在文章開頭,不過目的都是相同的,把文章大綱明顯的標示出來,讓讀者很輕鬆就能點擊前往對應的區塊,這是很友善的閱讀體驗設計

本篇會提供其中一種作法的範例程式碼,熟悉 JS 的話可自行修改,而如果需要更便利的客製功能請再發案給本站。



(圖片出處: pexels.com)


一、Blogger 錨點問題


1. 錨點語法

其實做這件事並不困難,只要瞭解基本的 HTML 就可完成。例如:

  • 手動在文章建立幾個 A 標籤的錨點語法
  • 將錨點指向各個大標題,例如 H2、H3 標籤
  • 為這些 H2、H3 標籤設定獨一無二的 ID 參數

舉例來說,使用下面的範例 HTML 碼:

<a href="#anchor1">點擊後跳到 anchor1</a>
<h2 id="anchor1">這裡是標題</h2>

點擊超連結後,畫面就會捲到 H2 標籤的位置。


2. 錨點問題

然而 Blogger 文章中使用錨點語法,長期以來有很嚴重的問題,可參考「超連結 A 標籤及錨點, 你不知道的操作技巧」→「二、Blogger 難搞的錨點」,只要 Blogger 文章編輯器有切換過模式,這些錨點語法就會失效了。

解決方法文章有說明,但是很麻煩,或許比較簡單的方法,還是使用本篇的程式碼。



二、範例效果


blogger-post-headline-anchor-area-1.png-Blogger 文章自動產生大綱索引錨點區塊




本篇提供的範例效果可參考範例網頁,這個工具的執行原理大致是這樣:

blogger-post-headline-anchor-area-2.jpg-Blogger 文章自動產生大綱索引錨點區塊

  • Blogger 文章編輯器在「撰寫」模式下,可設定「標題」、「子標題」、「小標題」
  • 設定完後,會分別對應到 HTML 碼中的 H2、H3、H4 標籤
  • 此工具會自動抓這些 H2 ~ H4 標籤的文字,出現在「大綱索引區塊」
  • 在「大綱索引區塊」會自動產生錨點,點擊後自動跳到對應的 H2~H4 標籤位置
  • 「大綱索引區塊」可自行設定要出現在文章中的指定位置



三、安裝程式碼


1. 準備動作

在修改範本之前,如果第一次安裝本站工具的讀者,建議先閱讀「備份範本的訣竅」系列文章。

請到後台「主題」→「編輯 HTML」,游標點進範本區塊,按 Ctrl-F 搜尋 </head>這個字串,找到後在此字串的前一行,插入以下程式碼:

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<style>
.post-body .headline {
margin: 30px 0;
padding: .5em;
background: #C1D6C5;
font-size: 1.3rem;
}
.headline a {
color: #4E5750;
}
.headline a:hover {
color: initial;
text-decoration: none;
}
</style>


第 1 行綠字可參考「引用 jQuery 的注意事項」,檢查範本是否已安裝過 jQuery,如果已經安裝過請刪除此行,以免重複安裝。

其餘的部分,如果對 CSS 熟悉可自行修改參數。


2. 安裝程式碼

接著在範本中搜尋以下程式碼,應該只有一個搜尋結果:

<b:include data='post' name='post'/>

找到後在其下一行插入以下程式碼:


儲存後還沒結束,請繼續設定文章中要出現「大綱索引區塊」的地方。



四、設定「大綱索引區塊」的位置


請按以下步驟進行:

  • 進入 Blogger 後台,隨意挑選一篇文章來編輯
  • 切換到 HTML 模式
  • 在文章中想出現「大綱索引區塊」的位置,插入以下 HTML 碼
  • <div class="headline"></div>

儲存後即可看到效果。

當然別忘了在文章內設定「標題」、「子標題」、「小標題」,否則是不會有效果的。



五、浮動導覽列問題


有些網站會使用「浮動導覽列」功能,由於導覽列長期佔用網頁上方固定高度,導致網頁上的任何錨點位置,都會被「浮動導覽列」遮住。

那麼使用本篇工具時,也會遇到這樣的問題,解決辦法請參考這篇「解決浮動導覽列遮住錨點位置的問題﹍CSS 技巧」,另外設定相關的 CSS 即可。


更多 Blogger 小工具:

使用 Google Apps Script 爬網頁資料,解析 HTML 及操作 DOM 的技巧

$
0
0
前陣子接到的需求,要使用爬蟲程式撈特定網站資料回來,那麼利用 Google 試算表是不錯的選擇,除了每個儲存格的容量最多有 50000 個字元,還可用 Google Apps Script(以下簡稱 GAS) 執行爬蟲程式、處理各種細節。

不過撈完網頁內仍後,如何解析 HTML 架構、操作頁面上的 HTML 元素都有不少難題要解決,因此本篇記錄一下 GAS 的操作心得與技巧。

(圖片出處: pixabay.com)


一、解析 HTML


1. 爬網頁原始碼

由於操作平台是 GAS,需要先瞭解爬網頁資料的語法:

var response = UrlFetchApp.fetch("https://www.wfublog.com/"),
content = response.getContentText();

以上語法可很簡單取得 WFU BLOG 的網頁 HTML 內容字串。


2. 操作 XmlService

GAS 用來解析 HTML 語法的官方文件如下:


官方也附了簡單的範例,使用 XmlService.parse() 就能解析網頁原始碼。

但先說結論,這是沒有用的,因為 XmlService 只能解析結構完整的 XML 文件,而 HTML 語法結構並沒有 XML 那麼嚴謹,所以不是每個網頁都能解析。

可參考這篇「XML文件的結構」,每個元素都要有開始及結束標記,例如:

<link></link>

但 HTML 文件以下標記方式(開始即結束)是允許的:

<link /> <input />

那麼一個正常的網頁內容,使用 XmlService.parse() 解析都會報錯,這就非常麻煩了。

硬要處理的話只能先用正規表示式,一一修改 link、input 等等各種不合 XML 規範的結束標記,才能使用 XmlService.parse()。


3. GAS 舊的 XML 工具

找到這篇比較好的解法「What is the best way to parse html in google apps script」,提到 GAS 舊版本的 XML 這個工具可以解析 HTML,參考語法如下:

var page = UrlFetchApp.fetch(contestURL);
var doc = Xml.parse(page, true);
var bodyHtml = doc.html.body.toXmlString();
doc = XmlService.parse(bodyHtml);
var root = doc.getRootElement();

先用 Xml 解析 HTML 後,再轉成 XML 字串,就能使用 XmlService 來解析內容了。

需要注意的是,XML 這個工具已被 Google 棄用(deprecated),隨時有可能失效。



二、操作 DOM


如果是前端的話,用 jQuery 操作取得的 HTML 內容非常簡單方便,但可惜的是 GAS 無法使用 jQuery,而且官方提供的工具還非常難用,比前端的 HTML API 還爛,所以國外有網友自行做了幾個方便的函數,可參考「Parsing HTML」。

這個頁面主要模擬 HTML API,做出了三個最常用的 DOM 操作工具:

  • getElementById
  • getElementsByClassName
  • getElementsByTagName


範例程式碼如下,複製到自己的 GAS 即可執行:

function getElementById(element, idToFind) {
var descendants = element.getDescendants();
for(i in descendants) {
var elt = descendants[i].asElement();
if( elt !=null) {
var id = elt.getAttribute('id');
if( id !=null && id.getValue()== idToFind) return elt;
}
}
}

function getElementsByClassName(element, classToFind) {
var data = [];
var descendants = element.getDescendants();
descendants.push(element);
for(i in descendants) {
var elt = descendants[i].asElement();
if(elt != null) {
var classes = elt.getAttribute('class');
if(classes != null) {
classes = classes.getValue();
if(classes == classToFind) data.push(elt);
else {
classes = classes.split('');
for(j in classes) {
if(classes[j] == classToFind) {
data.push(elt);
break;
}
}
}
}
}
}
return data;
}

function getElementsByTagName(element, tagName) {
var data = [];
var descendants = element.getDescendants();
for(i in descendants) {
var elt = descendants[i].asElement();
if( elt !=null && elt.getName()== tagName) data.push(elt);
}
return data;
}




三、常用功能


另外也提供一些 GAS 我常會用到的幾個 DOM 操作工具:

1. 刪除元素

function removeElement(element) {
element.getParentElement().removeContent(element);
}


2. 屬性值

取得圖片網址 IMG 的 src:

imgElement.getAttribute("src").getValue()

設定圖片網址 IMG 的 src:

imgElement.setAttribute("src", "圖片網址");


3. 字串

取得整個元素的 HTML 字串:

XmlService.getCompactFormat().format(element);

取得元素的文字:

element.getText();

設定元素的文字:

element.setText("字串內容");


更多 Google Apps Script 相關技巧:

從任意網站(痞客邦、WP)無痛搬家到 Blogger,不影響 SEO 搜尋排名

$
0
0
之前這篇讀者提問「Blogger 網址買了很後悔,可以再搬到新網址嗎?」,當時想到的解決辦法是把文章搬到新的 Blogger 網址,然後舊的 Blogger 做搬家畫面導向新網站,花幾個月的時間慢慢移轉 SEO。

後來熟悉「Google Cloud Platform 架設 WordPress」的技術後,這件事可以有比較簡單的作法,利用 WP 進行 301 轉址,那麼新舊網站的 SEO 移轉不必再等幾個月,可以馬上無痛搬家。

把這概念延伸出去,任何網站(例如痞客邦、WP)想要搬家到 Blogger、且不影響 SEO,只要有買網址都是沒問題的。使用相同的套路,利用 WP 當作跳板,都能無痛移轉 SEO。

(圖片出處: photo-ac.com)


一、從 Blogger 搬到 Blogger


以下大概記錄一下如何從 Blogger 舊的自訂網址搬到新的自訂網址,這個流程可當成其他平台搬到 Blogger 的參考作法。

1. 架設 WP 網站

首先要架出可 301 轉址的 WP 中繼站,請直接參考前面提到的參考文章,搞定 HTTPS 及 FTP 等問題。


2. 文章搬到 WP

完成之後就可將 Blogger 所有文章匯出,並匯入 WP,但這流程需要處理的問題非常多:

  • WP 有匯入 Blogger 文章的外掛,但一次能匯入的文章數量有限
  • 所以必須將 XML 檔切割成許多小檔,分別匯入直到成功為止
  • 例如我最近處理的網站有超過 2000 篇文章,至少切成 7 個檔才順利匯入


3. 調整文章網址格式

文章匯入後,WP 會自動產生自己的網址格式,必須改成跟原本 Blogger 的文章網址一模一樣,才有辦法進行 SEO 移轉,這是非常重要的一點:

  • WP 後台 →「設定」→「永久連結」,這裡可以設定文章網址的格式
  • 務必設成跟 Blogger 一樣「/年份/月份/xxxx.html」的格式
  • Blogger 文章有改過發佈月份的,要記得一篇篇改回去
  • 但以上這麼做後,WP 網址還是可能會不一樣,那麼必須參考「Guide to Moving a Blog From Blogger to WordPress」來調整錯誤的網址


4. 設定 301 轉址

文章都處理完後,可以為整個網站設定 301 轉址,導向新的網域,作法有 2 種:


直接說結論,熟悉 WP 的話,改 .htaccess 檔最快。

但不熟悉 WP 的話,.htaccess 這個檔案可能會有一大堆權限的問題、bug 要解決,研究起來是很痛苦的,那麼不如直接在後台裝個外掛,有圖形介面設定一下就解決了。


5. 設定 DNS

以上都完成後,就可以到網域代理商的後台設定 DNS 了:

  • 將原 Blogger 網站設定成新的網址
  • 將 WP 網站設定成原本的網址

之後所有原 Blogger 文章網址,就可以 301 跳轉到新網址了。


6. 新舊文章連結

如果文章內有引用內部連結(其他自己的文章連結),那麼也必須將所有連結改成新的網域才行。

一篇篇手動改太麻煩了,而且也不知道哪些文章有內部連結,所以可以使用 Blogger API 來全部檢查、全部更換。


7. 其他後續動作

網站搬家完之後,記得要趕快幫新網址到 Google Search Console 提交新的網站地圖,可參考「Blogger 提供新的網站地圖(sitemap)格式」。

同時 Adsense 廣告有可能因為換了網址而無法生效,那麼得趕快提出新網域的申請。



二、從痞客邦搬到 Blogger


從一般的痞客邦網站 (pixnet.net 網域) 搬到 Blogger,只能尋古法製作搬家畫面,想要無痛、不掉 SEO 是不可能的,因為做不到 301 轉址。

以下提供理論上可行的無痛搬家流程:

  • 痞客邦有提供自訂網址的服務,可以先買一年網址,將 SEO 權重移轉到自訂網域
  • 接著按照前面「一、從 Blogger 搬到 Blogger」的流程處理
  • 將痞客邦文章匯入 WP 時,網址或許不一定能完全對應痞客邦的網址
  • 那麼需要另外寫程式強制讓 WP 的文章網址完全跟痞客邦一樣
  • 接下來也要將痞客邦文章匯入 Blogger
  • 301 轉址要花一點功夫,需用 Blogger API 取得 Blogger 文章網址,以及用 pixnet API 取得痞客邦文章網址,讓所有痞客邦文章網址對應到新的 Blogger 文章網址
  • 處理新舊文章連結也不輕鬆,同樣需用兩邊的 API 來對應正確的連結



三、從任意網站搬到 Blogger


從自架站搬到 Blogger 的話,有可能很輕鬆也可能很麻煩。

1. WP

如果是 WP 的話,基本上本篇的流程就是靠 WP 來完成,那麼 WP 搬到 Blogger 算是最簡單的。


2. 自架站

如果是非 WP 的自架站,就有可能很麻煩了,因為自架站有可能用任何後端語言來寫:

  • 如果原網站的工程師能協助處理的話,就輕鬆很多了,可參考「協助自架站、WP 搬家到 Blogger 流程紀錄
  • 如果原網站工程師跑了,那就會是非常大的工程,需要先寫爬蟲程式進行砍站,一篇篇將所有文章複製到新建立的 WP 網站
  • 接下來再按照本篇的流程來進行



四、聯絡表單


本站可協助處理的搬家項目有這些:

  • 搬文章
  • 搬圖片
  • 處理新舊文章連結
  • 搬人氣
  • SEO 移轉


需要協助搬家請告知:

  • 網址
  • 文章篇數
  • 需要處理的搬家項目

並用以下表單與我聯繫:




更多「部落格搬家」相關文章:

Adsense 申請 + 廣告無法顯示的各種疑難雜症整理

$
0
0
最近一兩年詢問如何申請 Adsense 的案例越來越多,跟以往相較之下可說是門檻提升不少,這代表 Google 透露出這樣的訊息:

  • Adsense 申請資格已經不像 5~10 年前那麼容易
  • 投放(買)廣告的業主增加速度,遠不及想要擺放廣告的網站增加速度
  • 供給小於需求的情況下,Adsense 只好緊縮、嚴審申請資格
  • 若能夠篩掉越多品質不夠好的網站,代表廣告主越能投放更精準的廣告,代表品質好的網站越能維持收益

也許有些新進站長聽說網站可以賺廣告費就躍躍欲試,部落格文章還不多時就想申請 Adsense。如果能夠瞭解以上目前 Adsense 市場的現況,或許就不需要這麼急著申請。

僧多粥少急也沒有用,早點搶、晚點搶的意義差別不大,能夠吃得到才是最重要的。

本篇會整理各種申請 Adsense 可能遇到的問題,以及應對、解決方式,在正確的時機進場,才能分到比較大的餅。

(圖片出處: pxhere.com)


一、申請 Adsense 最基本的條件


先來看一系列官方提供的說明文件。

1. 準備動作

根據這篇「確保您網站的網頁已為 AdSense 做好準備」,以下部分內容非必要條件,但如果都能做到,至少在人工審核階段,可以讓自己網站較有優勢,比其他沒那麼用心的網站更容易脫穎而出:

  • 您的網頁有哪些特別之處:您應該思考自家網頁有何獨到之處,製作原創且相關的內容。
  • 版面配置看起來必須有吸引力:能讓訪客輕鬆找到所需資訊。
  • 建議您為訪客增闢留言專區:您必須負責管理留言專區,確保其符合 AdSense 計劃政策且不含不當內容。
  • 您的網頁是否提供清楚且易於使用的導覽方式:提供方便且易於使用的導覽列是一個關鍵。


2. 資格規定

根據這篇「AdSense 資格規定」,以下都是必要條件,請務必詳閱並遵守這些基本要件

  • 您是否自行從頭開始製作了內容:網站不要有抄襲、複製的文章
  • 提交給 AdSense 的網站,您必須擁有 HTML 原始程式碼的存取權:所以自架站、Blogger 等可以編輯範本的網站才有辦法申請,其他平台只能看該平台是否有提供代為申請的服務
  • 您的內容是否符合 AdSense 計劃政策規定:請詳讀「AdSense 計劃政策」這個頁面,不要違規
  • 您是否年滿 18 歲:如未滿 18 歲,可以請父母或監護人使用他們的 Google 帳戶代為註冊 AdSense。


3. Blogger 內容政策

如果是從 Blogger 平台申請 Adsense,還需要特別注意部落格內容,是否都遵守了「官方內容政策」,例如以下內容都是違反規定:

  • 申請 Adsense 不可有成人內容
  • 「剝削 / 利用兒童」的內容
  • 仇恨、暴力、恐怖主義、騷擾和威脅、非法活動
  • 侵害版權、洩漏個人及機密資訊
  • 管制類商品與服務 (包括酒類飲品、賭博、藥物、未核准補給品、菸草、煙火、武器或保健/醫療器材)
  • 垃圾內容、惡意軟體與病毒



二、申請無法通過的常見案例


簡單舉幾個案例,都是滿通用的狀況:

1. 一文多發,被判定非原創內容

這個 Blogger 論壇討論串「申請過 Google AdSense 被駁回」,遇到的狀況是:

  • 案主申請被駁回,理由是「版權內容」,但他自己不覺得有侵權
  • 經過網友幫忙抽絲剝繭,才發現是案主自己一篇文章發在多個平台,被誤判為非原創內容
  • 案主將一文多發的文章刪除後,後來重新申請有通過審查

因此為了避免被誤判,建議申請 Adsense 通過後,再一文多發,或是同意他人轉貼,或是修改部分文字,以免被判定為重複內容。


2. 流量要足夠

這篇「廣告待審核的時間點」,案主遇到的狀況是:

  • Adsense 遲遲無法進入下個階段的審核
  • 他找到的 Adsense 說明表示:「您必須將註冊 Adsense 時使用的網址中加入廣告程式碼,廣告累積足夠的曝光後,我們的專員會審核您的網站...」
  • 這代表 Adsense 審核期間,如果網站的流量不夠是不行的


3. 網站是否活躍

這個 Blogger 論壇討論串「adsense 認證, 試了多次都失敗」,遇到的狀況是:

  • 案主收到 Adsense 傳來審核不過的理由,但他認為那些要求都有做到
  • 經過網友抽絲剝繭後,才發現案主已經很久(一年)沒寫文章
  • 因為網站處於不活躍的狀態,也許 Adsense 無法判斷案主是否有心要經營網站
  • 這個狀態跟上一點「2. 流量要足夠」其實是一體兩面,網站不活躍、很久沒寫文章時,也可能沒有流量

所以申請 Adsense 的期間,是需要確保網站有一定流量的。


4. 請官方協助

如還是無法找出 Adsense 申請不過的原因,可填寫這個官方表格,加快處理速度:




三、申請通過但廣告無法顯示


廣告無法顯示、一片空白,是很常見的狀況,可能的原因有很多種。

1. 剛申請通過

如果才剛申請通過,新安裝的廣告碼沒那麼快能顯示,總要給 Adsense 一段時間整理數據、比對相關內容、建立資料庫等等。

一般來說根據經驗要等個十幾分鐘,而如果網站規模還很小,可能再等久一點吧。


2. 廣告數量不夠

全部的廣告數量再多也不可能餵飽全部網站,因此 Adsense 需要用演算法做些取捨,例如:

  • 先匹配相關主題的文章
  • 先匹配從訪客 cookie 收集來的數據資料
  • 先匹配規模較大的網站

想減少自己網站產生空白廣告的機率,最好的方法就是讓網站規模茁壯、成為權威網站,提高在 Adsense 心目中的地位


3. 設定 ads.txt

今年(2019) Adsense 新增了一項規定,網站必須設定 ads.txt 資訊,沒有正確設定的網站就無法獲得收益,算是同時保障廣告商與個別網站的一個措施

一般網站詳細的作法請參考官方文件「使用 ads.txt 宣告授權賣方」。

而 Blogger 網站的設定方式有所不同,請參考官網說明「設定 ads.txt 檔案」,在 Blogger 後台有相關選項可設定。


4. 被 Adsense 封鎖

當然,Adsense 無法出現廣告也可能是帳號違規、或網站被 Google 封鎖,那麼可參考這篇「GOOGLE ADSense廣告空白、沒出現、解決方式、沒收益」的記錄,想辦法跟官方查詢廣告無法顯示的原因。

或者是填寫 Adsense 官方提供的表格:




四、從 Blogger 後台申請 Adsense


如果使用 Blogger 平台,申請 Adsense 算是最簡單的,從後台就可完成申請流程,可參考官網說明:



要判斷是否 Blogger 網站已經符合申請資格非常簡單,如果在後台能看到「申請使用 AdSense」這顆按鈕,代表已經符合申請資格

如果找不到這顆按鈕,代表還不符合申請條件,請先閱讀前面的內容「一、申請 Adsense 最基本的條件」、「二、申請無法通過的常見案例」。



五、從 Adsense 官網申請


非 Blogger 以外的平台,那麼就依照標準流程作吧,參考官網說明:


如果覺得官網只有文字難以操作,也可參考這篇圖文教學「如何註冊 Google AdSense 帳戶(一般已註冊網域域名網站作法)」。



六、Blogger 買網址後無法顯示廣告


前陣子我多位客戶都遇到相同的狀況,例如原本是 .blogspot 網域,但買了網址、或是更換網址後,Adsense 廣告就無法顯示。

如果是多年前,例如本站剛買網址時,並不會出現這樣的情形,一個 Adsense 帳號可以同時在多個網域擺放廣告。但也許有人開始鑽漏洞,先申請 Blogger 獲取 Adsense 資格後,再放廣告到自己真正要經營的多個網站,來規避各種可能申請不過的網站。

現在 Adsense 把這漏洞補起來了,只要是不同的網域,一律得重新申請、審核 Adsense 資格。



七、Adsense 如何申請多個網域


如果 Adsense 帳號要增加多個網域的話,需要分以下不同的狀況處理:

1. 升級代管帳號

如果當初申請 Adsense 時並非使用自己的網址,而是透過第三方平台,例如痞客邦、Blogger、Youtube 等等,那麼這類帳號稱為「代管帳號」,要增加新的網址時,走的流程是不一樣的。

必須進入 Adsense 官網後,進行代管帳號升級才可以,詳細的圖文操作流程,可參考這些教學文章:



2. 加入新網站

如果當初是循正常管道申請的 Adsense 帳號,請依照官網說明文件進行設定,直接加入新網站:


新的網站需要重新審核、驗證,跟前面提到注意事項的一模一樣,也請注意這個頁面的所有步驟,包括「後續步驟」的內容。



八、總結


如果讀者有注意的話,本篇的任何說明都有出處來源,也沒提到任何申請 Adsense 需要具備的相關數字,例如其他網站可能會根據自身經驗提供以下數據,證明這樣才能符合資格:

  • 文章要寫幾篇
  • 網站建立時間要多久
  • 流量要多少

這些資訊 Adsense 官方都沒提過,所以任何網路上的數據都不足為信,為什麼呢?

Adsense 不可能明說申請通過的相關必要數據,也不可以說,因為只要數字一曝光,就代表存在作弊的可能性

那麼在沒有任何數據參考的情況下,站長們要如何知道何時可以提出 Adsense 申請呢?以下是我的建議:

  • 為了達到雙贏、市場能長久運作,Adsense 會希望廣告商出價高,也會希望網站都是優質的。
  • 網站的數量只會越來越多,為了讓廣告商有優質網站可投放廣告,Adsense 會努力提升網站素質、淘汰劣質網站
  • 所以評判網站是否優質的標準不可能固定,是相對性而非絕對性,會隨不同時間、時期而浮動,不可能維持固定的內部評判數據
  • 站長們要放在心上的,不是什麼條件下可以申請 Adsense,而是要如何勝過其他網站,獲得 Adsense 青睞
  • 站長們可以試著從廣告商的角度出發,如果自己是廣告商,願不願意把廣告投放在自己的網站?自己的網站能否為廣告商帶來利益?
  • 如果覺得自己網站設計得不夠友善、內容還不夠優質、無法吸引流量,尚還無法說服自己投放廣告到網站時,代表可以不急著申請
  • 如果對自己網站很有自信,可以幫廣告主賺到點擊、賺到收益,那麼就是適合提出申請的時刻


更多 Adsense 使用技巧:

讓 Google Photo 實現各種相簿畫廊或輪播效果

$
0
0
Google 相簿由於官方的用意並非設計來當作圖床,那麼想要自行製作各種 Google Photo 工具相當不容易,例如在網頁上展示各種畫廊圖片排版效果、或是利用 Google Photo 來輪播等等。

主要是官方不提供任何輕易取得圖片外連的方法,如同這篇「Google 關閉 Picasa API」提到關於 Goolge Photo API:

  • 每次以不同 access token 取得的相簿、照片資訊,包含id、baseurl(圖床)均不同
  • 由 Google 相簿上傳的資料,取得的資料具有時效性,時效一過,沒有登入google帳戶該張圖片是會產生破圖,無法讀取

因此本篇這個主題要用程式實現幾乎不可能,不過前陣子 FB 社團有成員推薦一個「可在網頁上輪播 Google Photo 的工具」,原來是國外網友的自製工具,當下覺得非常神奇,不知用什麼方法繞過了官方 Google Photo API 的限制,本篇就來研究看看。



一、手動取得 Google Photo 外連


如果不侷限用程式取得圖片連結,那麼使用手動取得 Google Photo 圖片外連,搭配各種畫廊、輪播外掛,雖然麻煩一點,還是能在網頁上做出各種特效。

1. 取得圖片外連

參考「取得 Google 相簿圖片外連更好的方法﹍轉換為 Picasa 連結」,從 Blogger 文章編輯器,就能直接取得 Google 相簿裡面的圖片連結。


2. 搭配輪播、畫廊外掛

接著拿這些圖片連結,參考「jQuery 相簿畫廊外掛 nanogallery2」,就能搭配以下外掛,在網頁做出各種特效:

  • 輪播
  • 燈箱
  • 畫廊



二、官方輪播效果


這篇「用來替代 Google 相本無法輪播的解決方法」是一種輪播的作法,也可視為 Goolge 官方提供的輪播效果。

「Google 雲端硬碟」裡面的「Google 簡報」(Google Slides)功能,可以輪播任何內容,並內嵌到網頁上。

從「Google 簡報」安裝這個外掛「Photos to Slides」可以取得 Google Photo 的圖片,全部設定好之後,發佈到網路,就可取得內嵌語法,效果大致像下面這樣:




三、國外輪播外掛


1. 外掛介紹

前面提到的國外網友自製工具,請見這個網頁「Embed photos as a slideshow with carousel widget」,操作方式也很簡單,在該頁面輸入 Google 相簿頁面的分享連結後,這個工具會自動產生程式安裝碼,放到自己網頁就有輪播效果,大致像下面這樣:




2. 原理拆解

仔細研究這個工具的安裝碼後,可發現:

  • 這工具可直接取得該項目的圖片連結,再另外搭配輪播外掛
  • 日後如果相簿圖片有更新(新增或刪除),此外掛不會更新圖片,依然輪播之前抓到的圖片
  • 此工具並非直接取得 Google Photo 的圖片外連,而是透過作者自己提供的後端程式處理,再返回圖片連結
  • 因此研究的結論為,前端仍然沒有直接取得 Google Photo 圖片外連的有效作法。



四、用程式取得 Google Photo 外連


綜觀本篇以上的所有作法,都只能算是「手動」操作的方案,無法全自動更新 Google 相簿的圖片連結。也就是說,當 Google 相簿的內容有變動時,想要在網頁上展示最新的 Google 相簿畫廊、或是輪播,必須全部的步驟重頭做一次,重新產生安裝程式碼。

不過瞭解國外網友的原理後,這件事也不算做不到了,只要跟國外網友一樣,搭配後端伺服器來取得 Google Photo 連結(例如使用 Google Apps Script),就能即時更新、或定期更新相簿的圖片連結了

好的,研究至此結論出來了,只是搭配 Apps Script 的製作流程很長、很麻煩,而且需求度不一定有想像中這麼高,就先不寫這部分的心得了。以下為建議:

  • 先從本篇以上三種方案擇一使用就好,相信可滿足多數的需求
  • 如果讀者製作的輪播或畫廊效果,真的有需要自動更新 Google Photo 的圖片連結,再另外發案給本站,來製作客製程式。


更多圖片展示工具:


更多「Google 相簿」相關文章:

常用程式碼片段的管理技巧及使用工具

$
0
0
協助前端架站久了之後,有許多常見的小工具會用到,代表需要安裝的程式碼中,有一部份是重複性高的,例如:

  • FB 讚、分享按鈕
  • 各種社群分享按鈕
  • FB 留言板等等

能重複使用的程式碼自然較有價值,即使是不能 100% 套用,但只要修改一部份就能用在新的情境,也是可節省大量時間,這些程式碼都值得用一套規則保存及管理。

只有 10 組程式碼要管理時當然很輕鬆,但有上百組、數百組時怎麼辦呢?有沒有好的管理工具或技巧,可以快速找到需要的程式碼呢?



一、原始作法的困境


一開始寫的 code 比較少時,我用 2 種方式記錄保存:

  • Evernote
  • 存成對應的 html/css/js 檔案,再使用 Windows 軟體「Everything」搜尋

當資料數量較少,搜尋起來雜訊沒那麼多,終歸可以找到需要的 code。但等到資料量一大時,缺點就浮現了。


1. Evernote

  • 由於先天上的限制,Evernote 的分類最多只有 2 層,很難對所有程式碼進行較有系統的分類及管理。
  • 很多客戶會用到類似的程式碼,那麼進行搜尋時,很容易就列出所有相似的程式碼,不容易有精確搜尋的方法
  • Evernote 會同時對標題及內文進行搜尋,因此不相關的搜尋結果太多
  • 如果為了這件事改用其他記事軟體,例如 oneNote,同時使用多個記事軟體在管理上不是好的作法


2. Everything

  • 直接用 Window 資料夾進行分類,管理上會比 Evernote 來得有效率,再搭配 Everything 搜尋更是完美
  • 可惜實際操作上還是會遇到跟 Evernote 一樣的情形,當多個客戶用到類似程式碼時,搜尋結果會出現大量雜訊。


總之,不管使用哪種方案,需要的都是如何縮短搜尋的時間,有效排除不精確的搜尋結果



二、程式碼管理工具


1. 管理工具

因此研究了一下,是否有什麼管理程式碼的好工具,大致找到這些:



2. 使用缺點

大致裝來玩一玩後,總覺得沒有 Evernote 或 Everything 來得方便,大概歸納一下:

  • Evernote 或 Everything 都是系統必備的常駐工具,有熱鍵可以隨時叫出來搜尋
  • 如果另外安裝程式碼管理工具,需要使用時才執行軟體,效率上有點慢
  • 如果要在多個裝置使用,得每個裝置都安裝、建立所有程式碼片段。
  • 這些軟體不會有雲端同步的功能,代表每個裝置要自己想辦法同步所有程式碼
  • 這些工具多半使用英文開發,對中文的支援度不一定夠

所以沒多久我就放棄使用這些工具了,轉而想辦法研究能否讓 Evernote 或 Everything 更好操作。



三、Everything 搜尋特定資料夾


為了能夠讓程式碼在所有裝置同步,必須在 Dropbox 內建立一個專門存放程式碼片段的資料夾。

為這個資料夾建立多個分類資料夾、多層子分類資料夾之後,如果可使用 Everything 單單搜尋這個資料夾之下的所有內容,排除其他不相關的內容,我想就是一個最簡便的方案了

搜尋到 Everything 這個討論串「Limiting search to within a folder」,提供了不少概念。


1. 使用命令列

官方提供了許多命令列的指令,可參考官網文件「Command Line Interface」。

例如使用以下的指令,就能搜尋特定資料夾,及所有子目錄:

C:\Everything\Everything.exe -path 完整路徑


2. 寫入登錄檔

原討論串有網友提供了密技,將一些指令寫入 Windows 登錄檔,將來按右鍵時就會出現選項,可以直接用 Everything 搜尋特定的資料夾。


3. 從檔案總管搜尋資料夾

詳細設定方法請參考這篇「Everything 重要技巧」,在設定中勾選右鍵選單的選項後,將來在檔案總管任何資料夾,只要按右鍵都能直接用 Everything 搜尋該目錄及所有子資料夾。


4. 搜尋捷徑

經過我的實測,如果將某些常用資料夾設成捷徑,放在 Windows 桌面上,按右鍵用 Everything 搜尋這個捷徑,一樣有搜尋該目錄及所有子資料夾的效果

那麼這個作法比進入檔案總管選取資料夾,再按右鍵搜尋,會來得快更多。


5. 製作熱鍵

如果能直接做個熱鍵,按了就執行搜尋特定資料夾,那麼又比以上所有方案快更多。

研究了一下,作法如下:

  • 用文書編輯軟體製作一個 .bat 檔,內容類似以下:
    • C:\Everything\Everything.exe -path E:\Dropbox\
    • 前一個路徑為 Everything 所在位置,後一個路徑為要搜尋的資料夾
  • 儲存後將 .bat 檔放在自己記得住的地方
  • 對這個 .bat 檔按右鍵,建立捷徑,將捷徑放在桌面
  • 對這個捷徑按右鍵 → 內容,可設定快速鍵

將來直接快速鍵,就能執行用 Everything 搜尋特定資料夾了。



四、小結


簡單做個總結,Evernote 由於會同時搜尋標題及內文,因此較難搜尋到精確的結果。而 Everything 將搜尋範圍縮小到特定資料夾後,只要用心為標題命名,就可以有精確的搜尋結果,能有效管理整理好的程式碼片段

不過提醒一下,本篇的方法比較適合業餘愛好者使用,如果是職業工程師,只要打開電腦就使用 Visio Studio 這類專業開發工具的話,其本身就有相關的 code snippet 套件可使用,會有不一樣的管理方式與技巧,就不一定需要另外存放程式碼片段了。


更多網頁開發工具:

部落格文章修改發佈日期對 SEO 的影響

$
0
0
最近一位客戶的 SEO 流量掉很多,在協助尋找原因的過程中,詢問是否曾經為了 SEO 而做過哪些動作。因為有不少站長可能從網路接觸一些 SEO 文章,除了內容不一定正確,也可能該手法已經過時,所以有必要釐清客戶是否不小心做了哪些動作導致被處罰。

客戶表示「如果是以前寫的舊文章,自己更改日期為較新的日期,是否會影響到文章的google排名呢」。

這件事的確可能會影響,但不盡然會是流量掉很多的主因,不過仍然是個值得探討的主題,因此本篇先討論文章修改發佈日期對 SEO 的影響。

(圖片出處: pxhere.com)


一、為何許多站長修改發佈日期


以訪客的角度來看,搜尋某些文章時,會希望找越近的日期越好,某些文章則沒有差別:

  • 屬於知識類的文章:例如疾病症狀、生活常識、居家修繕 DIY 技巧等等,比較不會因日期而影響搜尋結果
  • 屬與時效性的文章:例如網路相關資訊、新聞、娛樂影劇資訊、美食店家等等,日期越近的文章可能越有排名優勢。

雖然對某些領域的文章而言,日期是不重要的。實際上不諱言,Google 也的確喜歡新的文章,比較喜歡頻繁更新的網站。那麼有些站長為了讓文章排名較前面,可能會定期將特定文章的發文日期,改成是該年度發佈的狀態。



二、Google 官方聲明


根據這篇今年(2019)三月的官方聲明「Help Google Search know the best date for your web page」,有部分跟本文相關的內容。因為內容不短,且有不少實用知識,用中文整理一下所有重點:


1. Google 如何決定日期

我有遇過讀者反應搜尋結果的發佈日期,跟文章實際的發佈日期不一樣,後來有找到原因,原來是 Google 索引成某個小工具(例如熱門文章)的第一篇文章的日期。

這篇官方文章可說是解釋了這個狀況,Google 會從一個網頁的許多地方來推測出一篇文章的發佈日期,例如網頁上明顯的日期、結構化資料(JSON-LD)、Schema 標記、timestamp 相關標記。

一般來說部落格平台的文章,發佈日期多半能正確被索引,因為範本有一定的格式。非部落格平台的網站,SEO 相關的網站架構、日期格式如果沒做好,可能 Google 就無法正確索引發佈日期。

若有些部落格站長喜歡自行修改範本,就可能不小心動到日期的相關 code,導致發生類似前面的案例,文章總是被 Google 判定成錯誤的發佈日期。


2. 正確的日期格式

日期的表示方法有很多種格式,Google 建議符合「ISO 8601」規範。

這部分跟前面的說明一樣,部落格平台只要不亂動範本,日期格式這件事通常不用擔心。

除非發現搜尋結果的日期不太正常,那麼可參考這篇「部落格使用 "結構化資料"的最佳作法 JSON-LD」來進行設定日期相關資訊。


3. 會被視為違規的手法

If an article has been substantially changed, it can make sense to give it a fresh date and time. However, don't artificially freshen a story without adding significant information or some other compelling reason for the freshening. Also, do not create a very slightly updated story from one previously published, then delete the old story and redirect to the new one. That's against our article URLs guidelines.

這部分的內容是本篇重點,中文意思如下:

  • 如果文章內容實質修改過,那麼給與新的發佈日期是合理的。
  • 然而,不要去修改文章內容卻沒有增加重要的資訊,Google 不樂見人為刻意的更新
  • 也不要故意從舊文章只修改一點點的內容後,發佈成一篇新文章,然後刪除舊文章、將舊文章的網址轉址到新文章網址

前面 2 點說明了 Goolge 對修改發佈日期的態度,如果是正常的更新文章內容,那麼發佈日期變更是非常合理的事

如果文章內容變動不大,卻刻意更改發佈日期,就會被視為是作弊、操縱 SEO 排名的舉動,導致被 Google 處罰。

第 3 點看起來也是一種延伸的作弊手段,刻意將差不多的文章內容放到新網址,然後從舊網址轉址、移轉 SEO 權重到新網址,達成將同一篇文章變更成較新發佈日期的目的,現在被發現後同樣會被 Google 處罰。


4. 其他建議

官方還給了一些相關建議,由於部分內容跟前面重複,只列出不重複的事項:

  • 各處發佈日期要一致:如果一個頁面上多處使用了發佈日期,例如結構化資料、timestamp 標記,請確保各處的日期資訊一致,以免 Google 索引錯誤。
  • 不要使用未來日期



三、順其自然


找到這篇文章非常有趣、也很有參考價值:



作者很有實驗精神,不辭辛苦花了很多時間,做了各種修改日期的實驗。過程很長,可看看他的故事,簡短做個摘要:

  • 修改文章 "更新日期"對他的網站作用不大,修改 "發佈日期"作用比較明顯
  • 改日期後,大約第 2 週他有感覺出一點點流量上升
  • 大致 1 個月後,又回到原來的狀態


從這個故事可以看得出來,修改日期就像打類固醇,短期可以看到效果,但不會真正改善我們的體質。

所以凡事還是順其自然就好,不過份依賴 SEO 小技巧,發佈日期有需要再修改,沒需要就不要改,Google 一切都看在眼裡


更多 SEO 相關文章:
Viewing all 571 articles
Browse latest View live