zod.kr geliştirme 7 ay, yayında 5 ay: CMS seçimi ve geliştirme bölümü

https://tr.news.hada.io/topic?id=19746 yazısının devamıdır.

Yerli bir topluluk sitesini kurmak için Rhymix'i seçme nedenlerini ve Rhymix ile sitenin geliştirilme sürecini ele alıyor.

Aşağıda ChatGPT özeti yer alıyor.

---

zod.kr CMS seçimi ve geliştirme deneyimi özeti (kısa özet)

• Arka plan: Kore'deki CMS ekosisteminin fazla eski olduğuna karar verildi, ancak pratik nedenlerle sıfırdan yapmak yerine mevcut bir CMS kullanma kararı alındı.
• CMS karşılaştırması:
  • Gnuboard5: Kod kalitesi, güvenlik ve yapı sorunları nedeniyle elendi.
  • Rhymix: XE tabanlı olduğu için tanıdık, yapısı iyileştirilmiş, modern sözdizimini destekliyor ve genişletilebilirliği iyi → nihai seçim.
• Rhymix'in avantajları:
  • Composer, modüler yapı, önbellek desteği, asenkron kuyruk gibi birçok modern özellik.
• Dezavantajları:
  • Eski yönetici arayüzü, eksik üçüncü taraf bileşenler, yetersiz dokümantasyon vb.
• Tasarım: Duyarlı tema kullanımı + sayısız hata düzeltmesi ve CSS/JS iyileştirmeleri.
• Özellik eklemeleri:
  • Web push, etkinlik yönetimi, R2 bağlantılı yükleme, kullanıcı özellikleri gibi birçok şey kurum içinde geliştirildi.
• Modül geliştirme: Kılavuz eksikliği → kod analizi ve yapıyı bizzat çözerek uygulama.

👉 Özet: Eski CMS ortamında gerçekçi bir tercih olarak Rhymix seçildi ve çok sayıda deneme-yanılma ile özelleştirme sonucunda zod.kr kararlı biçimde kuruldu.

[jujumilk3]

Gerçek site geliştirme ve işletmeye kadar uzanan süreç için çok değerli bir kaynak, teşekkürler; büyük bir ilgiyle takip ediyorum.

[nemorize]

XE1’in ilk dönemlerinden Rhymix’e kadar onu on yılı aşkın süredir kullanan bir kullanıcı olarak, oldukça katıldığım bir içerik olmuş.

Bence en büyük sorun, Rhymix’in hedeflediği pazarın büyük bölümünün doğrudan geliştirme yapabilecek yeterliliğe sahip olmaması.

Doğrudan geliştirme yapabilen kişiler ise, XE ya da Rhymix’in yetersiz dokümantasyonunu, belirsiz yapısını ve legacy yükünü göze almak yerine çoğu zaman Laravel vb. çözümleri tercih ediyor.

Asıl yazının yazarı gibi ben de

1. Pek çok kişinin aşina hissedeceği bir yönetici paneli
2. Eksikleri olsa da yetersiz kalmayan bir CMS olarak sunduğu işlevler
3. Yeni önerileri aktif biçimde yansıtan çekirdek geliştirme ekibi
4. Uzun yıllardır kullanmaktan gelen bağlılık
   gibi nedenlerle bazı yeni projelerde Rhymix’i tercih ediyorum; ancak her seferinde bunun doğru bir seçim olup olmadığını ciddi ciddi düşünmeden edemiyorum.

Rhymix’i framework yerine kullanırken eksik bulduğum noktaları tamamlamak için kişisel olarak çeşitli denemeler yapıyorum.
https://github.com/nemorize/rx-make (develop branch / PoC projesi, production planı yok)

Rhymix’i tümüyle bir framework/kütüphane haline getirmek, legacy API’ye erişimi en aza indirmek ve daha modern bir API’yi (legacy ile aşağı yukarı uyumlu olacak şekilde) yeniden kurmak gibi çeşitli denemeler yapıyorum ama... gerçekten çok fazla düşündürüyor haha..

Bu konuyu daha önce hiç net biçimde toparlamamıştım; hazır fırsatını bulmuşken bir kez açık seçik düzenleyip yazıya dökmem gerekecek gibi görünüyor.