Jeffgeerling.com Hugo'ya taşındı

 (jeffgeerling.com)
2 puan yazan GN⁺ 2026-01-06 | 1 yorum | WhatsApp'ta paylaş
  • 2009'dan beri Drupal tabanlı olarak işletilen JeffGeerling.com, kişisel blog verimliliği için Hugo statik site oluşturucuya (SSG) geçirildi
  • Drupal 6'dan 10'a uzanan çok sayıdaki yükseltme ve bakım yükü, geçişin başlıca nedeni oldu
  • Hugo, Markdown tabanlı yazımı destekleyerek mevcut karmaşık yayınlama sürecini sadeleştiriyor ve yayınlama/dağıtım sürecini tek satırlık bir komutla yönetmeyi mümkün kılıyor
  • Taşıma sürecinde görsel bağlantı hataları, URL kayıpları gibi bazı sorunlar yaşanabilir; yorumlar ve arama işlevi ise sonraki aşamada geri getirilecek
  • Kişisel geliştiriciler için yalın iş akışı ve bakım verimliliği sunan bir örnek olarak, statik siteye geçişin pratik avantajlarını gösteriyor

Drupal'dan Hugo'ya geçişin arka planı

  • Site 2009'dan itibaren Drupal 6 ile başladı ve ardından 7, 8, 9, 10 sürümlerine kademeli olarak yükseltildi
    • 10 yıldan uzun süredir profesyonel olarak kullandığı CMS'yi kişisel blogunda da uyguluyordu
  • Drupal 7'den 8'e olan karmaşık yükseltme sürecinin ardından, kişisel blogda kurumsal düzeyde bir Digital Experience Platform (DXP) sürdürmenin yorgunluğu birikti
  • Blog, kişisel projeler ve YouTube içerikleri için yardımcı bir alan olarak kullanılıyor; CMS bakımından çok yazmaya odaklanmak için geçiş kararı alındı

Neden Hugo seçildi?

  • Geçmişte hobi amaçlı sitelerini statik barındırmaya taşıma deneyimi vardı; bunların bir kısmı Jekyll veya Hugo'ya dönüştürüldü
  • Jekyll, GitHub Pages için uygun olsa da Ruby uzmanı olmayan biri olarak Hugo'nun basit yapılandırmasını ve yüksek hızını tercih etti
  • Hugo, Markdown'ı varsayılan olarak destekliyor ve mevcut yazım biçimiyle doğal şekilde uyum sağlıyor

Taşıma süreci ve sorunlar

  • Taşıma çalışması GitHub issue #158 üzerinden sürdürülüyor
  • Yaklaşık 3.500'den fazla gönderi ve 20 yıllık veri nedeniyle bazı bozuk görseller, bağlantı hataları, eksik yönlendirmeler yaşanma ihtimali var
  • Mümkün olduğunca mevcut URL yapısını korumaya veya yönlendirmeler eklemeye çalışıyor

Markdown tabanlı iş akışındaki iyileşme

  • 2020'den beri tüm gönderiler Markdown ile yazılıyor
    • Önceden Sublime Text'te Markdown olarak yazıp HTML'ye dönüştürdükten sonra Drupal'a elle yüklüyordu
  • Drupal'da gönderi yayımlarken çok adımlı bir süreç gerekiyordu
    • Metni yapıştırma, görselleri tek tek yükleyip ekleme, yayın tarihini düzenleme, önbelleği temizleme vb.
    • DDoS önlemleri için Cloudflare önbellek yönetimi de buna dahildi ve süreç karmaşıktı
  • Hugo'da Markdown dosyasını yazdıktan sonra hugo && git commit && git push komutuyla anında yayımlamak mümkün
  • Composer, Drush, PHP, MariaDB, Nginx gibi sunucu yönetimi yükü ortadan kalktığı için bakım verimliliği arttı

Gelecek planları (TODOs)

  • Yorum özelliği, ikinci aşamada kendi kendine barındırılan statik bir yorum sistemiyle geri getirilecek
  • Site içi arama özelliği geçmişte Apache Solr tabanlıydı, ancak şu anda devre dışı durumda
    • Hugo içinde aramanın nasıl uygulanacağı issue #168 kapsamında inceleniyor
  • Taşımanın ilk aşamasında yorumlar devre dışı bırakılmış durumda ve aktarım çalışmalarının zaman alması bekleniyor

Geçişin anlamı

  • Drupal'ın karmaşık içerik üretim ve yönetim yapısından çıkarak, daha basit ve verimli bir statik site işletim modeline geçiş
  • Kişisel geliştiriciler için azalan bakım yükü ve üretime odaklanma ortamı sunan somut bir örnek
  • Hugo tabanlı geçiş, kişisel blog işletiminin sürdürülebilirliğini artıran bir adım olarak değerlendiriliyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-01-06
Hacker News yorumları

  • Birkaç yıl önce kişisel web sitemi kendi yaptığım Common Lisp tabanlı statik site üretecine taşıdım
    Başta yaklaşık 850 satırdı, şimdi 1500 satıra kadar büyüdü; blog yazıları, ziyaretçi defteri, yorum sayfaları, etikete göre RSS akışları gibi neredeyse her şeyi statik olarak render ediyor
    Tüm kodu, HTML’i ve CSS’i elle yazarak estetik kontrolü koruyabiliyorum ve yeni özellik eklemek de hızlı oluyor
    Örneğin bir “geri bağlantılar” sayfası eklemek için yaklaşık 40 satır CL kodu ve 15 dakika yeterliydi
    Şimdi çok kararlı, neredeyse hiç dokunmam gerekmiyor ve sadece yazmaya odaklanabiliyorum

    • Benim gibi biri için sorun self-hosted blog idi
      Blog motorunu kurcalamaya tüm vaktimi harcıyor, sonunda da hiç yazı yazmıyordum
      Bu yüzden bilerek daha az kontrol sunan bir hosting çözümüne geri döndüm. Artık sadece yazmaya odaklanabiliyorum
    • Ben de tek amaçlı bir statik site üretecinin sunduğu özgürlük ve kararlılığı seviyorum
      Eskiden Tclssg adlı açık bir proje yürütüyordum; kullanıcı geri bildirimleri sayesinde dokümantasyon yaptım ve birçok özellik ekledim
      Ama açık bir proje olduğu için yapıyı istediğim gibi değiştirmek zordu
      Şimdi siteme özel Python(900 satır) + Pandoc Lua(700 satır) bileşiminden oluşan bir üreteç kullanıyorum
      Teknik evrimi sitemde özetledim
    • Ben de katılıyorum. Sitem taoofmac.com’u Hy’ye port edip sonra yeniden Python ile yazdım
      Şimdi onu TypeScript/Bun ile tekrar yapıyorum ama hâlâ LISP benzeri unsurlar taşıyor
      SQLite ve HTML ayrıştırmayı içinde barındıran, native derlenen hafif bir LISP/Scheme lehçesi arıyorum
      İlgili bilgileri burada derledim
    • Ben de aynısını yaptım; Go ile bir site üreteci geliştirdim
      Yıllar sonra bile tüm siteyi 1 saniyenin altında build edebiliyorum
      RSS akışı ve kod vurgulama özelliklerini de kendim ekledim; Chroma ve Blackfriday kullanıyorum
      Hugo’yu denedim ama fazla karmaşık geldiği için kendim yazdım
    • Statik bir blogda yorumları nasıl yönettiklerini merak ediyorum

  • Eskiden svbtle’dan Hugo’ya taşınmıştım ama açıkçası pişmanım
    Temayı fork ettim ama Hugo sık sık bozulduğu için bakımına fazla zaman gidiyor
    Şu anda site hiç build olmuyor
    Tavsiyem, siteyi build eden binary sürümü de source control içinde tutmanız olur

    • Bazı yazılımların aslında güncellenmesine gerek olmadığını fark ettim
      Statik site üreteçlerinde güvenlik sorunu neredeyse yok; ihtiyacınız olan özellik eksik değilse eski sürümle aynen devam edebilirsiniz
      İşletim sistemi ya da CPU büyük ölçüde değişmediği sürece sorun çıkmaz
    • CI ayarında sürümü açıkça belirtmek yeterli
      Ben de bu ayarı referans alarak sürümü sabitledim
      Çalışan sürümü bulurken ikili arama ile gitmek verimli oluyor
    • Ben bunu özel bir Docker imajı ile çözdüm
      Hem lokalde hem CI’da aynı Hugo sürümünü kullandığım için sorun çıkmıyor
    • Hazır binary kullanıyorsanız ${project}/bin/ içine koyup .gitignore ile hariç tutabilir, checksum’u da SHA256SUMS dosyasına yazabilirsiniz
      Git LFS’nin basit bir sürümü gibi
    • Ben de Jekyll’de aynı sorunu yaşadım
      Yeni bir bilgisayara geçerken sürümleri eşleştirmek göz korkutuyor; sonunda PHP’ye port etmeye başladım ama henüz bitmedi

  • Yazılarını Markdown ile yazan biri için Hugo’ya geçmek mantıklı
    Ben de 500’den fazla Jekyll yazısını Hugo’ya taşıdım; template sözdizimi en zor kısmıydı
    Ama genel olarak kazançlıydı
    Geçiş sürecini ve otomatik dönüştürme script’lerini blog yazımda anlattım

    • Neden Jekyll’den Hugo’ya geçtiğini merak ettim. Ben Jekyll’den gayet memnunum

  • SSG’ler statik siteler için iyi ama etkileşim gereken yerde sunucu gerekir
    Zaten sunucu çalıştıracaksanız Markdown’ı dinamik render etmek daha basittir
    Sonuçta SSG sadece bağımlılıkları ve bozulabilecek şeyleri artırıyor
    Jeff’in ileride yorum gibi özellikler eklemeye çalışırken pişman olacağını düşünüyorum
    Bana göre daha gerçekçi çözüm SSR tabanlı basit bir sunucu

    • Ama ziyaretçi ya da bot sayısı artarsa sunucu çökebilir
      Statik sayfalarda böyle bir risk yok ve trafiğin çoğu sadece okumaya yönelik
      Jeff de yorum özelliğini issue içinde kendisi geliştirmeyi planlıyor gibi görünüyor
    • Ben de self-hosted analiz aracı ve yorum sistemini kendim işletiyorum
      Drupal dönemine göre kod tabanı çok daha küçük ve basit
    • Statik site üreteçleri aslında bağımlılıkları azaltan bir yaklaşım
    • Ben statik sayfaları SSG ile, yorumları ise Common Lisp + Hunchentoot sunucusuyla yönetiyorum
    • Ben de sitemi SSG’ye çevirdim ve hiç pişman değilim. Hatta ne kadar basitse o kadar iyi

  • Bir SSG seçerkenki karar sürecini merak ediyorum
    Hugo, Eleventy, Jekyll gibi büyük araçlar var ve Hugo özellikle geriye dönük uyumluluğu bozan değişiklikleri sık yapıyor
    Eski bir projeyse artık kararlılık garanti edilmeli diye düşünüyorum

    • Gerçekten de Hugo, v0.146 ile template sistemini baştan aşağı yeniledi
      Bu yüzden blog build’im bozuldu ve dokümantasyon da hâlâ tam güncellenmiş değil
      Değişikliğin kendisi sorun değil ama dokümantasyonun geriden gelmesi sorun

  • Bu aralar Pelican nasıl diye merak ediyorum. Python ekosisteminde Hugo ve Pelican sanki iki büyük seçenek gibi
    RSS’ten çok ActivityPub entegrasyonu daha cazip görünmeye başladı

    • Pelican kullanıyorum ve memnunum
      Eskiden Nikola kullanıyordum ama bağımlılıkları çok fazlaydı ve artımlı build tutarsızlığı sorunları vardı
      Pelican’ın sadeliğini koruması hoşuma gidiyor
    • Ben de yıllardır Pelican kullanıyorum
      Dokümantasyon sanki %90 tamamlanmış gibi, ince ayrıntılarda eksikler var ama temel işlevleri kullanıyorsanız harika
    • Pelican’a kendim yazdığım eklentilerden birkaç tane ekleyerek kullanıyorum
      Her ay commit geldiği için proje canlı görünüyor
    • Python biliyorsanız Pelican en doğal seçim

  • Şu anda Hugo’dan Zola’ya geçmeye çalışıyorum
    Zola’nın yapılandırması ve template’leri bana çok daha sezgisel geliyor

    • Ben de Jekyll’den Zola’ya geçtim ve hiç pişman değilim
      Build ve dağıtımı GitHub Actions ile otomatikleştiriyorum
    • İhtiyaçlarınız çok fazla değilse Zola + gist kombinasyonu basit ve uyumlu bir çözüm

  • Üç yıldır Hugo kullanıyorum
    Öğrendiğim şey, temayı fork edip kendin yönetmen gerektiği
    Submodule’den kaçınmak ve güncellemeleri yavaş yapmak en iyisi
    Yorum özelliği ise hâlâ zor görünüyor

    • Aynen. Temalar sonuçta her site için farklı
      Ben de Drupal temasını taşımaya çalışırken vazgeçtim
      Submodule yerine doğrudan projeye dahil edip sadece gereken kısımları override etmek daha mantıklı geliyor

  • Geçen yıl Hugo ile blog açtım ama 18 yazının 3/4’ünde build hataları ile uğraştım
    Bu kadar kararsız olması hayal kırıklığıydı

    • Ben de Hugo’dan kendim yaptığım Python SSG’ye geçtim
      Hugo’nun yaklaşımına alışmaya çalışmak yerine bildiğim dille hızlıca yapmak çok daha rahattı

  • Eskiden basit bir SSG’yi kendim yazmıştım; son zamanlarda daha düzenli bir şey ararken 11ty denedim
    Ama Liquid template’leri çok rahatsız ediciydi
    JSX tabanlı template kullanmak istiyordum ama 11ty bunu zorlaştırıyor
    NextJS SSG özellik olarak zengin ama fazla karmaşık, gereğinden büyük hissettiriyor
    Tempest gibi bir framework üzerinde özel bir SSG kurmayı da düşünüyorum

    • Eleventy, Mustache gibi klasik template dillerini de destekliyor
      Ben de Punch tabanlı sitemi Eleventy’ye taşıdım ve build hızı kabul edilebilir olduğu sürece Hugo’dan daha iyi olduğunu düşünüyorum
      Şimdi ise Astro ile baştan kurdum
    • Startup’ımızın pazarlama sitesini NextJS’ten Astro’ya taşıdık ve çok memnunuz
      Statik odaklı ama gerektiğinde backend mantığı da yazabiliyorsunuz
      NextJS basit bir site için fazla karmaşıktı