Serfex 0.1.46

• Yeni SnappyMail web postası: E-posta → E-posta ayarları → Web posta artık Roundcube, SnappyMail ya da Kapalı seçeneklerini sunuyor (Yazılım Yönetimi → Diğer'deki SnappyMail satırından da açılıyor). Roundcube varsayılan olarak kalıyor. Aynı anda tek web posta çalışıyor ve adres değişmiyor (https://<posta sunucusu>/); panelden Webmail düğmesi seçili uygulamada posta kutusunu tek tıkla, parolasız açıyor.
• SnappyMail'in Ubuntu paketi olmadığı için Serfex, denediği sürümü (2.38.2) GitHub'dan indiriyor ve SHA-256 sağlama toplamını denetliyor. Sürüm /opt/serfex/snappymail altında, veriler (ayarlar, kişiler) /var/lib/serfex/webmail/snappymail altında duruyor. SnappyMail'in yönetici paneli kapalı; ayarlarını Serfex yazıyor. Kişi defteri açık, dil tarayıcıdan seçiliyor.
• Uygulama değişince kişiler ve ayarlar taşınmıyor; her uygulamanınki sunucuda kalıyor ve geri dönülünce yerinde oluyor.
• İleride bir Serfex güncellemesi daha yeni bir SnappyMail getirirse Yazılım Yönetimi'nde SnappyMail satırında Güncelle görünüyor; önceki sürüm geri dönüş için saklanıyor.

Serfex 0.1.45

• PostgreSQL'de pgvector. Müşterilerin PostgreSQL sunucusu artık pgvector eklentisinin paketiyle (postgresql-<sürüm>-pgvector) birlikte kuruluyor. Vektör kolonları, HNSW/IVFFlat indeksleri ve benzerlik araması (yapay zekâ gömmeleri, anlamsal arama, Laravel'in vector kolonları) kullanılabiliyor.
• Yeni Eklentiler kartı: Veritabanları → PostgreSQL veritabanı. Eklentiyi aç pgvector'ü o veritabanında açıyor. pgvector "güvenilir" bir eklenti değil, yani yalnızca süper kullanıcı CREATE EXTENSION vector çalıştırabiliyor. Bu adımı Serfex yapıyor, sonra veritabanının kullanıcıları vector kolonlarını kendi yetkileriyle kullanıyor. Laravel'in Schema::ensureVectorExtensionExists() çağrısı eklenti açıkken sorunsuz geçiyor. Müşteriler kendi veritabanlarında açıp kapatabiliyor. Açmak ve kapatmak Geri al ile geri alınabiliyor.
• Kapat eklentiyi yalnızca onu kullanan kolon ya da indeks yoksa kaldırıyor. Hiçbir şey onunla birlikte silinmiyor (CASCADE yok).
• Kurulu sunucular paketi PostgreSQL'in bir sonraki Güncelle/onarım işleminde ya da eklenti ilk açıldığında alıyor. Paket kurulamazsa sunucu yine çalışıyor ve eklentiyi açınca yeniden deneniyor. Güncellemeler pgvector'ün yeni sürümlerini de getiriyor. Sürüm yükseltmede (ör. 16 → 18) yeni sürümün pgvector paketi önceden kuruluyor, böylece eklentiyi kullanan veritabanları yükseltmeyi engellemiyor.

Serfex 0.1.44

• Uygulama şablonları. Kendi Laravel uygulamanızı Araçlar ve Ayarlar → Uygulama şablonları'nda bir kez tanımlayın, sonra herhangi bir siteye tek adımda kurun. Şablonlar yalnızca bu sunucuda, panelin veritabanında durur; açık kaynak koda hiçbir şey girmez. Her kurulum ayrıdır: kendi kodu, veritabanı ve .env dosyası.
• İki kaynak türü var. Git deposu: bağlı Git hesabınızdan seçilen ya da herkese açık bir depo, bir etiket veya dal; Serfex kurar ve günceller, özel depoya her siteye ayrı salt okunur dağıtım anahtarı ekler. Sürüm paketi: GitHub'daki en son sürüme eklenmiş zip ya da sabit bir https adresi; sitenin app/ klasörüne açılır, site kökü app/public olur ve sonraki güncellemeleri uygulama kendi panelinden yapar.
• Şablonun sayfasında veritabanı (her siteye yeni MySQL/PostgreSQL veritabanı, SQLite ya da yok), PHP sürümü, kuyruk işçisi ve zamanlayıcı, .env satırları, kurulumda sorulan sorular (metin, gizli metin, lisans gibi dosya), ilk kurulum komutları ve ilk yönetici hesabı ayarlanır. Yer tutucular: {site.url}, {customer.name}, {db.password}, {ask.ANAHTAR}, {file.ANAHTAR}, {random:32} ve diğerleri.
• Kurulum: Siteler → Site ekle → Uygulama (site oluşturulur, sertifika alınır, ardından uygulama kurulur) ya da Laravel → Laravel uygulaması kur → Şablondan. Kurulum Laravel sayfasında canlı izlenir. İlk yönetici şifresini Serfex üretir ve bir kez gösterir; şifreler ve gizli yanıtlar günlükte gizlenir.
• Güncelleme (Git şablonları): şablonun etiketini değiştirin, Siteler sekmesinden tek siteyi ya da Tümünü güncelle ile hepsini sırayla güncelleyin. Her sitede veritabanı yedeği, bakım sayfası, yeni sürüm ve migrate; site açılmazsa önceki sürüme dönülür. İsterseniz ilk hatada kalan siteler güncellenmez.
• Müşteriler şablonları varsayılan olarak göremez; şablon başına "Müşteriler de kendi sitelerine kurabilir" açılırsa yalnızca adını ve açıklamasını görürler. Şablonlar JSON olarak dışa ve içe aktarılabilir (Git hesabı ve bağlı siteler hariç).

Serfex 0.1.43

• Bir ad artık başka bir müşterinin sitesine düşmüyor. Müşteri sitelerini sunan Nginx'te şimdiye kadar bir varsayılan sunucu yoktu. Henüz sertifikası olmayan bir siteye HTTPS ile gelen istek (ör. Cloudflare "Full" modunda), bu sunucuda tanımlı olmayan bir ad ya da çıplak IP adresi, Nginx'in okuduğu ilk siteye gidiyordu. Bir sitenin ziyaretçisi başka bir müşterinin sitesini (ya da onun hata sayfasını) görüyordu. Serfex artık kendi varsayılan sunucusunu yazıyor (/etc/nginx/sites-available/serfex-default.conf). 80 ve 443 portlarında eşleşmeyen her istek 404 ile "Bu adreste bir site yok" sayfasını alıyor. HTTPS'te kendinden imzalı bir sertifika kullanılıyor, istenen ad sayfada gösteriliyor. Sayfa varsayılan olarak İngilizce, #tr ile Türkçe.
• Ubuntu'nun kendi varsayılan sitesi (sites-enabled/default, "Welcome to nginx!") etkin siteler listesinden çıkarılıyor. Dosyası sites-available içinde duruyor. Yönetici bu bağlantıyı başka bir dosyaya yöneltmişse dokunulmuyor.
• Varsayılan sunucu güncellemeyle kendiliğinden yazılıyor. Bunun için bir site değişikliği beklemek gerekmiyor. Yazılamazsa güncelleme yine tamamlanıyor ve sorun bir sonraki site değişikliğinde gösteriliyor.
• Cloudflare arkasındaki alan adları için de sertifika alınıyor. Panel, sertifika istemeden önce adın bu sunucuyu gösterip göstermediğine bakıyor. Cloudflare'in vekil adreslerini görünce "DNS henüz işaret etmiyor" deyip sertifika almıyordu. Artık yalnızca Cloudflare adreslerine çözülen bir ad bu sunucuyu gösteriyor sayılıyor. Let's Encrypt doğrulaması Cloudflare üzerinden geliyor ve varsayılan sunucu HTTPS'te de cevaplıyor. Sertifika gelince Cloudflare'in en güvenli modu olan "Full (strict)" de çalışıyor. Ad başka bir sunucuya gidiyorsa doğrulama başarısız oluyor ve diğer hatalar gibi saatte bir yeniden deneniyor.

Serfex 0.1.42

• Yeni Siteyi kopyala: Site → Dosya ve veri → Siteyi kopyala. Site, aynı sistem kullanıcısı, PHP sürümü ve web sunucusuyla ayrı bir adrese (varsayılan staging.<alan adı>) kopyalanıyor. Dosyaların tamamı (günlükler hariç) kopyalanıyor; wp-config.php, .env ve PHP ayar dosyalarındaki adres ve veritabanı adları kopyaya göre düzeltiliyor, siteye işaret eden sembolik bağlantılar kopyaya yönleniyor, Laravel'in önbelleğe alınmış ayarları siliniyor.
• İstenirse her veritabanı <ad>_copy adlı yeni bir veritabanına kopyalanıyor; aynı veritabanı kullanıcıları aynı yetkiyle erişiyor. WordPress'in veritabanındaki adresler de (serileştirilmiş veriler dahil) yeni adrese çevriliyor ve kopyadaki WordPress de yönetiliyor.
• Arama motorlarından gizle varsayılan olarak açık: her yanıta X-Robots-Tag: noindex ekleniyor, WordPress'te "Arama motorlarını engelle" açılıyor.
• Kaynaktan yenile canlı sitenin dosyalarını ve/veya veritabanlarını kopyaya yeniden yazıyor. Canlı siteye aktar kopyayı canlı siteye yazıyor: önce canlı sitenin yedeği alınıyor, aktarma başarısız olursa canlı site hemen geri yükleniyor, sonradan vazgeçilirse 7 gün içinde Geri al ile dönülüyor. Laravel uygulaması olan sitelerde aktarma sunulmuyor (Git dağıtımı ve önizleme ortamları kullanılıyor).
• E-posta, zamanlanmış görevler, FTP hesapları ve kuyruk işçileri kopyalanmıyor. Alan adının DNS'i sunucudaysa kopyanın kaydı ekleniyor; kopya paketteki site ve veritabanı sınırına sayılıyor. Müşteriler kendi sitelerini kopyalayabiliyor.
• Yeni Önbellek ve hız: Site → Geliştirme → Önbellek ve hız. Sayfa önbelleği (Nginx, PHP'nin ürettiği sayfayı 1 dakika ile 1 gün arasında saklıyor; varsayılan 10 dakika), tarayıcı önbelleği (resim, CSS, JavaScript, yazı tipi ve video için 1–365 gün; varsayılan 30) ve gzip sıkıştırma. Hepsi kapalı başlıyor. Oturum açmış ziyaretçiler, çerez kuran ya da "private" yanıtlar, giriş, yönetim, sepet, ödeme ve API sayfaları hiç saklanmıyor; ek yollar hariç tutulabiliyor. Önbelleği temizle düğmesi ve X-Serfex-Cache (HIT/MISS/BYPASS) yanıt başlığı var. Değişiklikler geri alınabiliyor.
• Yeni Composer ve Node.js: Site → Geliştirme. Laravel olmayan sitelerde de Composer ve npm/pnpm/Yarn/Bun komutları sitenin kullanıcısıyla, seçilen klasörde, canlı çıktıyla çalışıyor. composer.json ve package.json bulunan klasörler listeleniyor; sık komutlar ve package.json betikleri tek tıkla. Site, komutlarının (ve Laravel derlemelerinin) kullanacağı Node.js sürümünü seçebiliyor. Müşteriler için paketin "Komut ve Tinker erişimi" özelliği gerekiyor.

Serfex 0.1.41

• Depoyu listeden seçme (GitHub, GitLab, Bitbucket): Git dağıtımında, Laravel kurulumunda ve Laravel → Dağıtımlar'da depo artık bağlı hesabınızın listesinden aranıp seçiliyor, dal da listeden geliyor. Serfex depoya salt okunur dağıtım anahtarını ve dağıtım webhook'unu kendisi ekliyor (Laravel'de push ve pull request olayları); depo bağlantısı kaldırılınca ya da Laravel uygulaması silinince ikisini depodan yine kendisi siliyor. Kod her zaman sitenin dağıtım anahtarıyla çekiliyor, hesabın erişim izniyle değil. Sağlayıcı anahtarı reddederse (depoda yönetici değilseniz) anahtar eskisi gibi elle eklemek için gösteriliyor. Adresi elle yazmak hâlâ mümkün.
• Araçlar ve Ayarlar → Git sağlayıcıları: her sağlayıcı için bir OAuth uygulaması tanımlanıyor (GitHub OAuth App, GitLab uygulaması — GitLab.com ya da kendi sunucunuz — ve Bitbucket OAuth consumer). Sayfa, sağlayıcıya girilecek geri dönüş adresini ve adımları gösteriyor; gizli anahtar şifreli saklanıyor. Hiçbiri açık değilse her şey eskisi gibi çalışıyor.
• Hesap → Git hesapları: her kullanıcı (yönetici, müşteri, Laravel ekibi) kendi GitHub, GitLab veya Bitbucket hesabını bağlıyor ya da bağlantısını kaldırıyor. Erişim izinleri şifreli saklanıyor; GitLab ve Bitbucket izinleri süresi dolmadan yenileniyor.

Serfex 0.1.40

• Site araçlarındaki Bağlantı bilgileri artık çalışıyor: sunucunun adresi ve IP'si, SFTP portu ve sitenin FTP hesapları (bağlanınca açılan klasörle), sitenin veritabanları (sunucu, port, kullanıcılar, phpMyAdmin/Adminer bağlantısı) ve SSH açıksa sftp/ssh komutları tek sayfada, kopyalanmaya hazır. Parolalar gösterilmiyor (Serfex saklamıyor); her bölümün yanında yenisinin belirlendiği sayfaya bağlantı var. Müşteriler de kendi sitelerinde kullanabiliyor.
• Laravel → Zamanlayıcı'da her görevin kendi anahtarı var: kapatılan görev zamanı gelince atlanıyor, uygulamanın kodu değişmiyor. Geri al ile hemen açılabiliyor; kapalı görev "Şimdi çalıştır" ile elle yine çalıştırılabiliyor. Kapalı görev olduğunda Serfex schedule:run'ı küçük bir başlatıcıyla (/opt/serfex/laravel/schedule-run.php) çalıştırıyor; hiç kapalı görev yoksa eskisi gibi doğrudan php artisan schedule:run.
• README'deki Genel Bakış ekran görüntüleri yeni tasarımla yeniden çekildi.
• composer.lock composer.json ile eşitlendi (composer artık uyarı vermiyor). Livewire 4.4.8'e yükseltildi (4.4.7 için yayımlanan orta düzey güvenlik uyarısı; Serfex etkilenen #[Authorize] özelliğini kullanmıyordu).
• 0.1.20'den önceki sürümlerden kalan eski Türkçe güncelleme adresi (/ayarlar/guncellemeler/ilerleme) kaldırıldı. 0.1.20'den eski bir sürümden doğrudan bu sürüme güncellerken güncelleme sayfası sonda bir hata gösterebilir; güncelleme yine de tamamlanır, sayfayı yenilemek yeterli.
• Ajan testlerindeki sabit tarihler (9 yer) bugüne göre hesaplanıyor, testler ileride kendiliğinden bozulmuyor.

Serfex 0.1.39

• Plesk'ten taşıma: Siteler → Başka sunucudan taşı → Plesk sunucusu. Yedek almadan eski Plesk sunucusuna SSH ile (root ya da parolasız sudo kullanıcısı) bağlanılıyor; giriş Serfex'in SSH anahtarıyla ya da parolayla yapılıyor. Parola yalnızca aktarım bitene kadar şifreli saklanıyor; sunucunun SSH parmak izi gösteriliyor ve sonraki bağlantılarda aynı anahtar isteniyor.
• Sunucudaki abonelikler listeleniyor; seçilen abonelik önce bu sunucuya kopyalanıyor (dosyalar, Maildir posta kutuları, MySQL dökümleri, Plesk veritabanından alan adları, takma adlar, posta hesapları, yönlendirmeler, DNS kayıtları ve sertifikalar). Eski sunucuda hiçbir şey değişmiyor.
• Sonra cPanel taşımasıyla aynı önizleme, seçim, taşıma ve rapor geliyor. Ana alan adı ve her ek alan adı ayrı site oluyor, takma adlar DNS bölgeleriyle ek ad olarak geliyor, alt alan adları klasörleriyle taşınıyor.
• Posta kutuları eski parolalarıyla geliyor (Plesk'in mail_auth_view aracıyla okunup burada yalnızca SHA512-CRYPT olarak saklanıyor). Veritabanı kullanıcıları eski parola hash'leriyle geliyor; bu sunucunun kullanamadığı biçimde yeni parola veriliyor ve wp-config.php/.env dosyasına yazılıyor.
• Web barındırması olmayan alan adları, takma adların postası, başka veritabanı sunucusundaki ve PostgreSQL veritabanları, zamanlanmış görevler ve ek FTP hesapları raporda listeleniyor ama taşınmıyor. Ayar dosyasında eski /var/www/vhosts/ yolu geçen dosyalar da belirtiliyor.

Serfex 0.1.38

• Yeni WordPress araç seti: Site → Uygulamalar → WordPress. Her sitede bir WordPress yönetiliyor; işler WP-CLI ile sitenin kendi kullanıcısı olarak yapılıyor.
• WordPress'i kur: sitenin web kökü boşsa (yalnızca "site hazır" sayfası varsa) tek tıkla kurulum. Yeni MySQL/MariaDB veritabanı (<önek>wp), site adı, yönetici hesabı ve dil (Türkçe ya da İngilizce) birlikte hazırlanıyor. Yönetici parolası bir kez gösteriliyor, saklanmıyor; admin ve administrator kullanıcı adı olarak kabul edilmiyor. Kurulum başarısız olursa dosyalar ve veritabanı geri alınıyor. WordPress'in adresi sitenin tercih ettiği ad oluyor (www'li ya da www'siz). Laravel uygulaması olan sitede sunulmuyor.
• Sitede zaten bir WordPress varsa (web kökünde ya da iki seviyeye kadar alt klasörde) bulunuyor; Yönet ile dosyalarına dokunmadan yönetime alınıyor.
• Güncellemeler: WordPress'in kendisi, tek bir eklenti/tema ya da Tümünü güncelle. Önce veritabanı ve güncellenecek dosyalardan geri dönüş noktası alınıyor; güncellemeden sonra site hata verirse güncelleme kendiliğinden geri alınıyor. Son güncelleme Geçmiş'ten 7 gün içinde Geri al ile güncelleme öncesine döndürülebiliyor. Panel her gün yönetilen WordPress'leri güncelleme için denetliyor (otomatik güncelleme yapmıyor).
• WordPress'e giriş yap: yönetim paneli ilk yönetici olarak, iki dakika geçerli ve tek kullanımlık bir bağlantıyla parolasız açılıyor; işlem günlüğüne yazılıyor.
• Bakım modu, eklenti etkinleştirme/devre dışı bırakma, tema değiştirme ve WordPress'in otomatik güncelleme ayarı (varsayılan: yalnızca güvenlik ve bakım sürümleri) anında değişiyor ve geri alınabiliyor.
• Güvenlik sekmesi: dosya düzenleyiciyi kapat, wp-config.php'yi koru, yüklemeler klasöründe PHP çalıştırma, hassas dosyaları gizle (dördü önerilen; kurulumda uygulanıyor) ve XML-RPC'yi kapat. Kurallar sitenin kendi Nginx eklerinde duruyor.
• Yönetimden çıkar WordPress'i, dosyalarını ve veritabanını yerinde bırakıyor; yalnızca Serfex'in giriş eklentisini, web sunucusu kurallarını ve geri dönüş noktalarını kaldırıyor.
• Müşteriler kendi sitelerindeki WordPress'i aynı şekilde yönetebiliyor.

Serfex 0.1.35

• Yeni Tercih edilen adres ayarı (Plesk'teki "Preferred domain" gibi): ziyaretçiler ornek.com ya da www.ornek.com adresinden hangisine gitsin? Diğer ad kalıcı (301) yönlendirmeyle tercih edilen ada gidiyor; yol ve sorgu korunuyor, istek uygulamaya hiç ulaşmıyor. "Yönlendirme yok" seçilirse iki ad da siteyi ayrı ayrı açıyor (eski davranış).
• Site ekle penceresinde "www. ile de açılsın" kutusunun yerine bu seçim geldi: ornek.com (varsayılan), www.ornek.com, ikisi de açılsın ya da yalnızca ornek.com (www. eklenmez).
• Var olan sitelerde ayar Yönlendirme yok olarak geliyor, yani hiçbir şey kendiliğinden değişmiyor. Site → Alan adları → Ek alan adları sekmesinden değiştirilebiliyor; değişiklik Geri al ile geri alınabiliyor. Site araçlarında da "Tercih edilen adres" satırı var.
• Yönlendirme yalnızca tercih edilen ad sertifikadaysa başlıyor, böylece ziyaretçi hiçbir zaman sertifika hatası veren bir adrese gönderilmiyor. Sertifikası olmayan sitede yalnızca alan adının kendisi tercih edilebiliyor; www. adı sertifikaya girince yönlendirme kendiliğinden başlıyor.
• Laravel uygulaması kurulurken APP_URL artık tercih edilen adresle yazılıyor. APP_URL www'lu olup trustHosts() açık olan bir uygulamada çıplak alan adının "400 Bad Request" vermesi, tercih edilen adres www seçilince çözülüyor.
• API: POST /api/v1/sites preferred_host (bare, www, none) alıyor ve site yanıtında gösteriyor. Komut satırı: serfex sites create ornek.com --prefer www.
• Site yedekleri tercih edilen adresi de saklıyor ve geri yüklüyor.