Hugo

最近，我在 Netlify 上創建了一個新的網站，希望將其中一部分公開在 GitHub 上，以便任何人都可以提交錯別字等問題的拉取請求。 我在 Hugo 倉庫中有一個名為 content 的文件夾，我想公開的部分是一個名為 handbook 的文件夾。 因此，我為此創建了一個新的倉庫，名為 handbook。 我刪除了父倉庫中的 content/handbook 文件夾（如果您從頭開始創建，則不需要此步驟，但我希望移動現有內容）： rm -rf content/handbook 然後我提交了更改，然後添加了子模組： git submodule add https://github.com/flaviocopes/handbook 我在 Netlify 上部署了網站，它自動捕獲了子模組。 但在本地上遇到了一個問題，因為並不是像子模組存儲庫文件夾上有著符號鏈接這樣。 我刪除了 content/handbook 文件夾，並從子模組的本地存儲庫添加了一個符號鏈接： ln -s ../../../dev/handbook/ 然後，我告訴 Git 停止跟踪 content/handbook 文件夾，使用以下命令： git update-index --skip-worktree content/handbook （要恢復跟踪，請使用 --no-skip-worktree） 這樣，我既有子模組，也在本地上有指向子模組的符號鏈接，兩者兼得。

在最長的一段時間後，我從 Blackfriday 切換到默認的 Hugo Markdown 渲染器 Goldmark。我延遲了這個切換的時間，但在版本 0.100 中，他們移除了被棄用的舊版 Markdown 渲染器。 不幸的是，這意味著我在 Markdown 中嵌入的所有 HTML 都停止運作。 我通過在我的 config.yaml 文件中啟用這個選項來解決這個問題： markup: goldmark: renderer: unsafe: true 或者，在 config.toml 文件中： [markup.goldmark.renderer] unsafe = true

發現Netlify，一個非常適合靜態網站的優秀托管服務，它還有一個很好的免費計劃、免費CDN並且運行非常快速。 我把我的博客托管在Netlify上。 我一段時間前轉移，我的前一個托管服務遇到了一些問題，導致我的網站在幾個小時內無法訪問，所以在等待它恢復上線期間，我尋找了一個快速的方式將其還原，並在Netlify上創建了一個複本。 由於這個博客使用的是Hugo，它是一個靜態網站生成器，所以我不需要太多工作將博客遷移到新的托管服務上。我只需要一個可以提供HTML文件的地方，而這幾乎是地球上的任何一個托管服務都能做到的。 我開始尋找最適合靜態網站的平台，有一些平台在我眼中脫穎而出，但最終我選擇了Netlify，並且很高興我這麼做了。 介紹Netlify 在我嘗試之前，有一些讓我留下了極好印象的事情。 首先，免費計劃非常豐富，無論是免費還是商業項目都可以享有100GB的每月免費帶寬，對於一個只有一些圖片的靜態網站來說，這是一個非常寬敞的空間。 它們提供全球CDN，以確保速度不成問題，即使在遠離中央位置服務器的大陸上也是如此。 你可以將你的DNS nameserver 指向Netlify，他們會為你處理一切，並且提供一個非常漂亮的界面來設置高級需求。 它們當然支援自訂域名和HTTPS。 從Firebase過來，我期望能夠以一種對程序員友好的方式來管理部署，但我發現Netlify在處理每個靜態網站生成器方面甚至更好。 Netlify和Hugo 我使用的是Hugo，在本地我使用它內建的工具hugo server運行服務器，該工具會在每次更改時重新構建所有HTML文件，並且默認運行一個HTTP服務器，端口為1313。 為了生成靜態網站，我需要運行hugo，這會在public/文件夾中創建一系列的文件。 在Firebase的情況下，我採用了這個方法：我運行hugo來創建文件，然後運行firebase deploy，配置它將public/文件夾的內容推送到Google服務器。 然而，在Netlify的情況下，我將它連接到了我私有的GitHub存儲庫，並且每次我推送到我告訴Netlify同步的主分支時，Netlify都會啟動新的部署，變更將在幾秒鐘內生效。 提示：如果你在Netlify上使用Hugo，請確保在netlify.toml中設置HUGO_VERSION為最新的Hugo穩定版本，因為默認版本可能比較舊（截至目前為止）並且不支援最新的功能，例如後綴束。這是我的netlify.toml配置文件。 如果你覺得這不是什麼新鮮事，你是正確的，因為這在自己的服務器上並不難實現（我在其他沒有托管在Netlify上的網站上也這麼做），但這裡有一些新鮮事情：你可以預覽GitHub（或GitLab、或BitBucket）的任何分支/PR，同時你的主站點仍然運行並顯示“穩定”的內容。 另一個很酷的功能是可以在2個不同的Git分支上進行A/B測試。 Netlify為靜態網站提供的高級功能 靜態網站的顯而易見的限制是不能執行任何服務器端操作，這和你從傳統CMS（如WordPress）中期望的功能不一樣。 這既是一個優勢（因為安全問題較少），也是一個你可以實現的功能的限制。 一個博客並不復雜，你可以使用像Disqus或其他類似服務來添加評論功能。 或者，你可以通過嵌入第三方應用程序（如Wufoo或Google Forms）生成的表單來添加表單。 Netlify提供了一套工具來處理表單，驗證用戶，甚至部署和管理Lambda函數。 需要在發布之前對網站進行密碼保護？✅ 需要處理CORS？✅ 需要進行301重定向？✅ 需要為你的SPA進行預渲染？✅ 我只是觸及了Netlify提供的功能的表面，而沒有借助第三方服務，希望我給你提供了一個嘗試Netlify的理由。 預覽分支 GitHub的集成和拉取請求一起工作得很好。 每次你推送一個拉取請求，Netlify就會在一個特定的URL上部署該分支，你可以與你的團隊共享這個URL，或者與任何你想共享的人共享。 這裡，我提出了一個拉取請求，以預覽博客文章，但只在我的公共博客上不可用： Netlify立即捕捉到它，並自動部署它🎉 點擊鏈接會將您指向一個特殊的URL，讓您可以預覽該分支的網站版本。

我有一份定期發布在我的博客上的文章清單。以下是我如何透過IFTTT每天早上自動觸發我的Hugo靜態網站部署在Netlify上的方法。 注意：這個方法不僅適用於Netlify，也適用於其他提供手動部署Webhooks的服務供應商。 我有一份定期發布在我的博客上的文章清單，而我試著提前撰寫幾天的內容，為我無法寫作的時候或是需要休息的時候留出空間。 我認為保持一致性對於保持工作的動力很重要。過去兩個月，我每週一至週六都有發布文章，且我未來也想繼續這樣做，因為我真的很喜歡寫作。 我使用的是 Hugo 靜態網站生成器，並且托管在 Netlify 上。 這組工具組合非常棒，對於博客的設置我非常滿意。 今天我在山上遠足時，突然意識到已經超過我通常發布文章的時間，而我之前已經安排好的博客文章也沒有發布。 使用 Hugo，我可以設定一個未來的發布日期，當使用 hugo CLI 命令重新構建網站時，這篇文章不會包含在生成的 HTML 中，因為它是未來的文章。 Netlify 有這個很不錯的概念，在他們的伺服器上構建 Hugo 網站，所以我只需要觸發一個新的部署。通常情況下，當我將任何內容推送到 GitHub 時，Netlify 會自動警報並在一分鐘內進行部署。 但在這種情況下，我需要手動觸發Netlify上的部署，所以我使用iPhone登錄並點擊“觸發部署”。 這個動作在服務器端使用Hugo重建靜態網站，我只需將手機放回口袋。 博客文章上線了🎉，我只需在Twitter上發一條推文。 在步行時，我意識到我可以自動化所有這些工作。 我只需要每天早上9點自動觸發一個部署。於是我在Netlify界面上尋找他們是否有任何定時循環部署的自動化功能。雖然沒有這樣的功能，但他們有一個WebHook端點。 因此，我尋找了一些可以每天對WebHook進行POST設置的工具。 我使用了Zapier（也可以），但之後轉用了 IFTTT，因為它可以免費提供相同的功能。 在Netlify上，我建立了一個WebHook URL 這給了我一個自定義的URL來呼叫： 我在IFTTT上創建了一個每天早上8點提醒的"applet"： 並且在其中設定一個Web請求來觸發Netlify上的部署鉤子。 現在，我只需要創建內容，按計劃日期將其推送到GitHub，就不用再擔心手動部署了！🎉 👨🏼‍💻

一个从零开始到部署的使用 Hugo 开始技术博客的详细教程 Hugo 是一个非常好的工具，可以用来开始一个博客。 我自己在这个博客中使用了 Hugo 已经超过 2 年了。我喜欢使用 Hugo 的原因有几个。 它是简单，无聊，灵活，快速。 最重要的原因是它是简单的。你不需要学太多东西就可以开始使用。 你可以使用 Markdown 编写内容，这个格式允许我使用我最喜欢的编辑器（Bear）来写文章。 Hugo 是无聊的。不要误会，这是一件非常好的事情。作为一个开发者，我总是有冲动的想要不停地调整各种东西。Hugo 没有使用任何花哨的技术。它是用 Go 语言构建的，而 Go 是我最喜欢的语言之一，但这并不意味着我想要深入了解 Hugo 的内部工作方式，并改变它的工作方式。 Hugo 也没有展示任何炫酷或者下一代的东西，就像许多 JavaScript 框架经常会做的那样。 因此它非常无聊，这给了我很多的时间来做真正有用的事情，比如写内容。我专注于内容，而不是内容的展示方式。 话虽如此，Hugo 是非常灵活的。我用一个开源的主题开始了我的博客，然后随着时间的推移，完全改变了它。有时，我想在我的网站上做一些超出了普通博客范围的事情，而 Hugo 可以让我实现这些功能。 最后，我喜欢 Hugo 的另一个原因是它快速。为什么呢？首先，它的核心是 Go 语言，而 Go 语言以其非常快的速度而闻名。在 Go 的生态系统中，没有 100MB 依赖的概念。所有的东西都被设计得尽可能快速。此外，Hugo 不需要进行一些使用花哨技术时需要的繁琐操作。这是非常无聊的一个副产品。 好了，废话不多说。 Hugo 真的很棒，尤其是对于开发者来说，而且你愿意使用 Markdown 来写作的话。非技术人员可能会拒绝使用 Markdown，这是可以理解的。 此外，你还需要为使某些事情真正奏效而准备一个基于 Git 的工作流程。 在何处托管 Hugo 网站 Hugo 博客是完全静态的。这意味着你不需要自己托管服务器，也不需要使用特殊的服务。 Netlify、Now 和 GitHub Pages 是 3 个非常好的免费托管 Hugo 博客的地方。...

我的網站是基於Hugo的，它是一個靜態網站生成器。 雖然有像Forestry等工具可以在其之上使用視覺化的內容管理系統，但我並不是很喜歡它們，而且我組織內容的方式並不適合這些工具。一個簡單的例子就是圖像。它們通常希望您將所有圖像存儲在一個文件夾中，而我則為每篇文章創建一個文件夾，並將文件放在其中。 總之，我在我的Mac上使用VS Code編輯Markdown，然後將更改推送到GitHub。 在iPad上，我使用GitHub的一個很棒的功能，直接在瀏覽器中編輯文件，本質上是在雲端運行的VS Code。 這非常酷，也許有一天我會完全使用這個功能，而不再使用Mac上的VS Code。 下面是它的工作原理。 如果你有一個名為https://github.com/userName/repositoryName的存儲庫，將瀏覽器指向https://github.dev/userName/repositoryName 換句話說，只需將.com改為.dev，你就可以在Safari的VS Code視圖中看到你的存儲庫。 從這裡，你基本上可以像在VS Code中一樣工作，但在瀏覽器中。唯一仍然不完全正常工作的是搜索，它需要在本地存儲中索引文件，但在Safari中效果並不完美。 我還需要注意不要嘗試使用cmd-w來關閉VS Code標籤，因為那樣會關閉Safari標籤。 此外，我在處理圖像時遇到了一個問題，例如如果我在iPad上進行截圖，它們的大小相當大，並且解析度很高（超過1MB？），而我通常將圖像轉換為JPG格式，因為這更高效。但這是我之後可以在Mac上處理的問題。我可以有一種處理圖像的系統在雲端執行，但我到目前為止還沒有需要它。 除此之外，完成更改後，我將它們推送到GitHub。

在 Hugo 中，如何傳遞多個參數給 partial？這並不像看起來那麼簡單，你需要使用一個技巧。讓我們看一下。 我使用 Hugo 來管理這個網站，它非常方便。 今天遇到的一個問題是如何將 2 個參數傳遞給 partial。 由於在 partial 中無法訪問 .Site.Pages 以獲取網站頁面列表（由於作用域問題），我不得不創建一個字典並填充其中 2 個項目： {{ partial "my-partial.html" (dict "context" . "pages" $.Site.Pages) }} 這裡的關鍵是將 (dict "context" . "pages" $.Site.Pages) 作為參數傳遞，而不是像通常在 partial 中使用的 .。 現在，在 partial 中，我們需要使用 .context 來訪問當前上下文變量，而不是使用 .。 如果要訪問 pages 的值，可以使用 .pages。 當然，您也可以傳遞多個項目。只需將更多項目添加到字典中即可。

最近，我試圖將我的基於 Hugo 的部落格移植到 Next.js（結果並不理想），而在這個過程中遇到了一個問題。 Hugo 允許我在圖片名稱中使用空格，這對於使用截圖並且預設檔名為 Screen Shot 2022-... 是很方便的。 但是 Next.js 的 Markdown 則不允許使用空格。因此，我撰寫了一個腳本來將所有的圖片檔名中的空格改為連字符（hyphen）。 "Screen Shot 2022-..." => "Screen-Shot-2022-..." 然後，我將文章的 Markdown 內容替換為改好的名稱。 同時，由於 Hugo 允許將文章放在與 Markdown 檔案相同的資料夾中，而 Next.js 則不允許這樣做。 因此，我使用了 /public/images/<SLUG>/ 的資料夾形式，將每個文章的圖片設為公共可見。 以下是我實現這個功能的程式碼： import matter from 'gray-matter' ... let { data: frontmatter, content } = matter(fileName) const regex = /\!\[(.*?)\]\((.*?)\)/gm let matches while ((matches = regex.exec(content)) !== null) { content = content.replace( '](' + matches[2], `](/images/${slug}/${matches[2].replace(/ /g, '-').replace(/\//g, '')}` ) }

當我在我的電子書網站The Valley of Code上推出新的主頁時，我並沒有考慮到我的託管費用以及為客戶加載大量圖片的影響。 由於每個頁面非常長（沒有導航，這就是它們作為書籍而不是文章的目的），一個頁面的大小甚至可能達到10MB。 因此，我決定通過使用懶加載來解決這個問題，也就是說，當用戶滾動到該圖片時，瀏覽器只加載該圖片。 這是一個權衡，但我相信99%的人打開一個頁面後甚至根本不會立即滾動到該圖片。 問題是…我無法控制標記！所有的內容都在Markdown中。 但是我發現Hugo允許我們覆蓋圖片的呈現方式。 在您的主題中創建文件layouts/_default/_markup/render-image.html，內容如下： <img src="{{ .Destination | safeURL }}" alt="{{ .Text }}" loading="lazy" /> 這將使生成的HTML具有loading="lazy"屬性，從而實現圖片的懶加載。

在Hugo中，要獲取當前的URL可以使用以下代碼： {{ trim .Page.RelPermalink "/"}} 下面是代碼執行的結果： yoursite.com/ebooks -> "ebooks" yoursite.com/ebooks/php -> "ebooks/php"