Jeffgeerling.com का Hugo पर माइग्रेशन

 (jeffgeerling.com)
2 पॉइंट द्वारा GN⁺ 2026-01-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2009 से Drupal-आधारित रूप में चल रहा JeffGeerling.com, व्यक्तिगत ब्लॉग की दक्षता बढ़ाने के लिए Hugo static site generator (SSG) पर स्थानांतरित किया गया
  • Drupal 6 से 10 तक जारी कई upgrade और maintenance के बोझ इस बदलाव की मुख्य वजह बने
  • Hugo, Markdown-आधारित लेखन को सपोर्ट करता है, जिससे पहले की जटिल publishing प्रक्रिया सरल हो गई और publish/deploy का काम एक ही command line से संभव हो गया
  • माइग्रेशन के दौरान image link errors, URL loss जैसी कुछ समस्याएँ हो सकती हैं, और comments व search features बाद के चरण में बहाल किए जाने की योजना है
  • यह व्यक्तिगत डेवलपर्स के लिए सरल workflow और maintenance efficiency देने वाला एक उदाहरण है, जो static site migration के वास्तविक फायदों को दिखाता है

Drupal से Hugo पर जाने की पृष्ठभूमि

  • साइट 2009 में Drupal 6 से शुरू हुई थी और बाद में 7, 8, 9, 10 तक चरणबद्ध upgrade हुए
    • 10 साल से अधिक समय तक पेशेवर रूप से इस्तेमाल किए गए CMS को व्यक्तिगत ब्लॉग पर भी लागू किया गया था
  • Drupal 7 से 8 के जटिल upgrade process के बाद, व्यक्तिगत ब्लॉग पर enterprise-grade Digital Experience Platform(DXP) बनाए रखने की थकान बढ़ती गई
  • ब्लॉग का उपयोग personal projects और YouTube content के सहायक स्थान के रूप में किया जाता है, और CMS maintenance के बजाय लेखन पर ध्यान देने के लिए यह बदलाव चुना गया

Hugo चुनने की वजह

  • पहले hobby sites को static hosting पर ले जाने का अनुभव रहा है, जिनमें कुछ को Jekyll या Hugo में बदला गया
  • Jekyll, GitHub Pages के लिए उपयुक्त है, लेकिन Ruby विशेषज्ञ न होने के कारण Hugo की आसान configuration और तेज़ speed को प्राथमिकता दी गई
  • Hugo, Markdown को default support देता है, इसलिए यह मौजूदा लेखन शैली के साथ स्वाभाविक रूप से जुड़ जाता है

माइग्रेशन प्रक्रिया और समस्याएँ

  • माइग्रेशन का काम GitHub issue #158 में जारी है
  • लगभग 3,500 से अधिक posts और 20 साल के data के कारण कुछ image damage, link errors, redirect omissions होने की संभावना है
  • जहाँ तक संभव हो, मौजूदा URL structure को बनाए रखने या redirects जोड़ने की कोशिश की जा रही है

Markdown-आधारित workflow में सुधार

  • 2020 से सभी posts Markdown में लिखी जा रही हैं
    • पहले Sublime Text में Markdown लिखकर उसे HTML में बदलने के बाद Drupal पर manually upload किया जाता था
  • Drupal में post publish करने के लिए multi-step प्रक्रिया की आवश्यकता होती थी
    • body paste करना, images अलग-अलग upload और insert करना, publish date बदलना, cache clear करना आदि
    • DDoS response के लिए Cloudflare cache management भी शामिल था, जिससे प्रक्रिया और जटिल हो जाती थी
  • Hugo में Markdown file लिखने के बाद hugo && git commit && git push command से तुरंत publish किया जा सकता है
  • Composer, Drush, PHP, MariaDB, Nginx जैसे server management burden के हटने से maintenance efficiency बेहतर हुई

आगे की योजना (TODOs)

  • Comments feature को दूसरे चरण में self-hosted static comments system के रूप में बहाल किया जाएगा
    • इससे जुड़ा काम GitHub issue #167 में चल रहा है
  • Site search feature पहले Apache Solr-आधारित था, लेकिन फिलहाल बंद है
    • Hugo में search implementation के तरीके की समीक्षा issue #168 में की जा रही है
  • माइग्रेशन के शुरुआती चरण में comments disabled हैं, और migration-related work में समय लगने की उम्मीद है

बदलाव का महत्व

  • Drupal की जटिल content creation और management structure से निकलकर, अधिक सरल और कुशल static site operations model की ओर बढ़ना
  • व्यक्तिगत डेवलपर्स के लिए maintenance burden में कमी और creation पर focus देने वाला एक व्यावहारिक उदाहरण
  • Hugo-आधारित बदलाव को personal blog operations की sustainability बढ़ाने वाली दिशा के रूप में देखा जा रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-06
Hacker News की राय

  • कुछ साल पहले, मैंने अपनी निजी वेबसाइट को अपने हाथ से बनाए Common Lisp आधारित static site generator पर माइग्रेट किया था
    शुरुआत में यह करीब 850 लाइनों का था, अब बढ़कर लगभग 1500 लाइनों का हो गया है, और ब्लॉग पोस्ट, गेस्टबुक, कमेंट पेज, टैग-वार RSS feed आदि लगभग सब कुछ static रूप में render करता है
    सारा code, HTML और CSS मैं खुद हाथ से लिखता हूँ, इसलिए aesthetic control बना रहता है और नए फीचर जोड़ना भी तेज़ है
    उदाहरण के लिए, ‘backlink’ पेज जोड़ने के लिए करीब 40 लाइन CL code और 15 मिनट ही काफी थे
    अब यह बहुत stable है, इसलिए लगभग छेड़ने की ज़रूरत नहीं पड़ती और मैं सिर्फ़ लिखने पर ध्यान दे सकता हूँ

    • मेरे जैसे स्वभाव के लिए self-hosted blog ही समस्या था
      मैं ब्लॉग engine को ही कुरेदने में सारा समय लगा देता था और अंत में लिखता ही नहीं था
      इसलिए जानबूझकर कम control वाले hosting solution पर वापस चला गया। अब मैं सिर्फ़ लिखने पर ध्यान दे सकता हूँ
    • मुझे भी single-purpose static site generator की आज़ादी और स्थिरता पसंद है
      पहले मैं Tclssg नाम का एक public project चलाता था, और user feedback की वजह से documentation भी किया और कई फीचर भी जोड़े
      लेकिन public project होने की वजह से structure को मनमुताबिक बदलना मुश्किल था
      अब मैं अपनी साइट के लिए Python(900 लाइन) + Pandoc Lua(700 लाइन) से बना generator इस्तेमाल कर रहा हूँ
      तकनीकी बदलावों का इतिहास मेरी साइट पर दर्ज है
    • मैं भी सहमत हूँ। मैंने अपनी साइट taoofmac.com को Hy में port किया था, फिर दोबारा Python में rewrite किया
      अब मैं इसे TypeScript/Bun में फिर से बना रहा हूँ, और इसमें अभी भी LISP-जैसे तत्व बचे हुए हैं
      मैं एक हल्की LISP/Scheme dialect ढूँढ रहा हूँ जिसमें SQLite और HTML parsing built-in हो और जो native compile भी हो सके
      संबंधित जानकारी यहाँ संकलित है
    • मैंने भी यही किया, लेकिन Go में site generator बनाया
      कई साल बाद भी पूरे साइट का build 1 सेकंड के अंदर हो जाता है
      RSS feed और code highlighting भी खुद जोड़ी, और Chroma तथा Blackfriday का इस्तेमाल किया
      Hugo इस्तेमाल किया था, लेकिन वह बहुत जटिल लगा, इसलिए खुद बना लिया
    • static blog में comments कैसे संभालते हैं, यह जानने की उत्सुकता है

  • पहले svbtle से Hugo पर आया था, लेकिन सच कहूँ तो पछतावा है
    मैंने theme fork किया था, लेकिन Hugo अक्सर टूट जाता है, इसलिए maintenance में बहुत समय लगता है
    अभी तो साइट build ही नहीं हो रही
    मेरी सलाह है कि साइट build करने वाले binary version को source control में साथ रखना अच्छा रहता है

    • मुझे समझ आया कि कुछ software को ज़रूरी नहीं कि update ही किया जाए
      static site generator में security issue लगभग नहीं होते, इसलिए अगर ज़रूरी फीचर की कमी नहीं है तो पुराना version जैसा है वैसा इस्तेमाल किया जा सकता है
      जब तक operating system या CPU में बड़ा बदलाव न हो, आमतौर पर दिक्कत नहीं होती
    • CI config में version specify कर दीजिए
      मैंने भी इस config को देखकर version pin किया था
      काम करने वाला version ढूँढते समय binary search सबसे कारगर रहता है
    • मैंने इसे custom Docker image से हल किया
      local और CI दोनों में Hugo का वही version इस्तेमाल होता है, इसलिए समस्या की गुंजाइश नहीं रहती
    • off-the-shelf binary इस्तेमाल करते समय उसे ${project}/bin/ में रखें, .gitignore में डालें, और checksum को SHA256SUMS फ़ाइल में दर्ज कर दें
      यह Git LFS के साधारण version जैसा तरीका है
    • मुझे Jekyll में भी यही समस्या हुई थी
      नए computer पर जाते समय version मिलाना डरावना लगता है, और आखिरकार मैं PHP में port कर रहा हूँ, लेकिन अभी अधूरा है

  • जो लोग Markdown में लिखते हैं, उनके लिए Hugo पर जाना तर्कसंगत है
    मैंने भी 500 से ज़्यादा Jekyll post को Hugo में माइग्रेट किया, और template syntax सबसे कठिन हिस्सा था
    फिर भी कुल मिलाकर फ़ायदा ही हुआ
    migration process और auto-conversion script को इस ब्लॉग पोस्ट में लिखा है

    • यह जानने की जिज्ञासा है कि Jekyll से Hugo पर क्यों गए। मैं अभी भी Jekyll से पूरी तरह संतुष्ट हूँ

  • SSG static site के लिए अच्छा है, लेकिन जहाँ interaction चाहिए वहाँ server चाहिए
    अगर वैसे भी server चलाना है, तो Markdown को dynamically render करना ज़्यादा सरल है
    आखिरकार SSG dependency और टूटने वाले हिस्से ही बढ़ाता है
    लगता है Jeff बाद में comments जैसी सुविधा जोड़ना चाहेंगे तो पछताएँगे
    व्यक्तिगत रूप से मुझे SSR आधारित सरल server ज़्यादा व्यावहारिक समाधान लगता है

    • लेकिन अगर visitor या bot बहुत बढ़ जाएँ तो server जवाब दे सकता है
      static page में यह जोखिम नहीं होता, और ज़्यादातर traffic read-only होता है
      Jeff भी comments फीचर को issue में खुद implement करने की सोचते दिखते हैं
    • मैं भी self-hosted analytics tool और comment system खुद चला रहा हूँ
      Drupal के दिनों की तुलना में codebase कहीं छोटा और सरल है
    • static site generator तो उल्टा dependency घटाने की दिशा है
    • मैं static page के लिए SSG, और comments के लिए Common Lisp + Hunchentoot server इस्तेमाल करता हूँ
    • मैंने भी साइट को SSG में बदला और ज़रा भी पछतावा नहीं है। उल्टा, जितना सरल उतना बेहतर

  • SSG चुनते समय decision-making process क्या होती है, यह जानना चाहता हूँ
    Hugo, Eleventy, Jekyll जैसे कई बड़े tools हैं, और Hugo में खासकर compatibility breakage बार-बार दिखती है
    मेरा मानना है कि पुराने project के लिए अब stability की गारंटी होनी चाहिए

    • वास्तव में Hugo ने v0.146 में template system को पूरी तरह बदल दिया
      उसकी वजह से मेरे blog का build टूट गया, और documentation भी अभी तक पूरी तरह update नहीं हुई है
      बदलाव अपने आप में ठीक है, लेकिन समस्या यह है कि documentation साथ नहीं चलती

  • आजकल Pelican कैसा है, यह जानने की उत्सुकता है। Python ecosystem में Hugo और Pelican दो बड़े नाम लगते हैं
    RSS की तुलना में ActivityPub integration भी आकर्षक लगती है

    • मैं Pelican इस्तेमाल करता हूँ और संतुष्ट हूँ
      पहले Nikola इस्तेमाल करता था, लेकिन dependency बहुत थीं और incremental build mismatch की समस्या भी थी
      Pelican की सादगी मुझे पसंद है
    • मैं भी कई सालों से Pelican इस्तेमाल कर रहा हूँ
      documentation लगभग 90% पूरी लगी, इसलिए बारीक हिस्सों में कमी है, लेकिन अगर केवल मूल फीचर इस्तेमाल करें तो यह शानदार है
    • मैं Pelican में कई खुद के बनाए plugin जोड़कर इस्तेमाल करता हूँ
      हर महीने commit आते हैं, इसलिए project जीवित है
    • अगर आप Python जानते हैं, तो Pelican सबसे स्वाभाविक विकल्प है

  • मैं अभी Hugo से Zola पर जाने की प्रक्रिया में हूँ
    Zola की settings और templates मुझे कहीं अधिक intuitive लगते हैं

    • मैं भी Jekyll से Zola पर गया था, और ज़रा भी पछतावा नहीं है
      GitHub Actions से build और deploy automate कर रखा है
    • अगर requirements ज़्यादा नहीं हैं, तो Zola + gist का संयोजन सरल और उपयुक्त है

  • मैं 3 साल से Hugo इस्तेमाल कर रहा हूँ
    जो सीखा है, वह यह कि theme को fork करके खुद manage करना चाहिए
    submodule से बचना बेहतर है, और update धीरे-धीरे करना चाहिए
    comment feature अब भी मुश्किल लगती है

    • सही बात। theme आखिरकार हर साइट के लिए अलग होती है
      मैंने भी Drupal theme migrate करने की कोशिश की थी, फिर छोड़ दिया
      submodule की जगह सीधे include करके ज़रूरत वाले हिस्से ही override करना बेहतर लगता है

  • पिछले साल Hugo से ब्लॉग शुरू किया था, लेकिन 18 post में से 3/4 के दौरान build error ने परेशान किया
    इतनी instability से निराशा हुई

    • मैं भी Hugo से खुद बनाए Python SSG पर चला गया
      Hugo के तरीके का अभ्यस्त बनने से बेहतर था कि जिस भाषा को मैं जानता हूँ, उसी में जल्दी implement कर लूँ

  • मैंने पहले एक साधारण SSG खुद बनाया था, और हाल में कुछ ज़्यादा व्यवस्थित चीज़ खोजते हुए 11ty आज़माया
    लेकिन Liquid template बहुत असुविधाजनक लगी
    मैं JSX आधारित template इस्तेमाल करना चाहता था, लेकिन 11ty उसे कठिन बना देता है
    NextJS SSG में फीचर बहुत हैं, लेकिन वह इतना जटिल है कि ज़रूरत से ज़्यादा लगता है
    Tempest जैसे framework के ऊपर custom SSG बनाना भी विचार में है

    • Eleventy, Mustache जैसी पुरानी template language भी support करता है
      मैंने भी Punch आधारित साइट को Eleventy में माइग्रेट किया, और अगर build speed ठीक हो तो यह Hugo से बेहतर लगा
      अब मैंने इसे Astro में नया बनाया है
    • हमने अपने startup की marketing site को NextJS से Astro में माइग्रेट किया, और हम बहुत संतुष्ट हैं
      यह static-first है, लेकिन ज़रूरत पड़ने पर backend logic भी इस्तेमाल कर सकते हैं
      साधारण साइट के लिए NextJS बहुत ज़्यादा जटिल था