Güncellemeler

WebBlocks CMS'de güncellemeler sürüm tabanlı ve paket tabanlıdır.

• Kurulu sürüm, kuruluma uygulanan son gerçek sürümü yansıtır.
• Olağan kaynak geliştirme çalışması kurulu sürümü değiştirmez.
• Uygulama içi güncelleyici, yerel çalışma ağacı değişikliklerini değil, yayımlanmış sürüm paketlerini uygular.
• Yeni Composer tüketicileri, normal sürüm tabanlı güncelleme akışını kullanmadan önce ilk kurulumu composer require fklavyenet/webblocks-cms ve php artisan webblocks:install ile yapmalıdır.
• Güncel paket-yerel kurulumlar, paket köklü sürüm ZIP'lerini doğrudan tüketir.
• Paket-yerel System Updates, paket yapıtını kanonik Composer paket kökü olan vendor/fklavyenet/webblocks-cms konumuna uygular; böylece Composer güncellemesi ile System Update aynı kurulu paket düzenini üretir.
• Tarihsel olarak, 1.31.53 gibi paket-yerel öncesi kurulumlar paket köklü sürüm ZIP'lerini doğrudan tüketemiyordu ve önce eski biçimli 1.32.33 kök yönetimli köprüyü gerektiriyordu. Normal kapılarda desteklenecek eski kök yönetimli kurulum kalmadığı için bu köprü yolu artık rutin sürüm doğrulamasından emekliye ayrılmıştır.

• Güncellemeleri yalnızca yayımlanmış sürümlerden çalıştırın.
• Kuruluma özgü dosyaları .env, storage/ ve project/ gibi korunan yollarda tutun.
• Geliştirme ve sürüm iş akışlarını ayrı ele alın.
• Kaynak üzerinden bakımı yapılan bakım çalışma kopyalarında, yerel kaynak düzenlemeleri zaten çalışma ağacında bulunur. System Updates bu yerel değişiklikleri uygulamak için kullanılmamalıdır ve çalışan CMS kod sürümü, güncelleme uygunluğu için en son yayımlanmış sürümle karşılaştırılır.
• Sürüm paketleri yalnızca yeniden kullanılabilir CMS çekirdek kodunu içerir ve kuruluma özgü project/ içeriğini barındırmamalıdır.
• Güncelleme sırasında korunan yollar sürüm paketi sınırını değiştirmez: project/ kuruluma yerel kalır ve yayımlanan yapıtın dışındadır.
• Kurulu CMS çalışma kopyaları güncelleme tüketicisidir, upstream yayıncısı değildir. Bir kurulumun git origin'i varsa, gerekiyorsa fetch erişimini koruyun ancak push'u git remote set-url --push origin DISABLED ile devre dışı bırakın.
• Bir System Update, yalnızca uygulanan paket çalışma zamanı hedef sürümü kanonik WebBlocks\Cms\Support\WebBlocks sürüm kaynağından raporladıktan sonra başarılı olarak kaydedilir. Uygulanan kod hâlâ daha eski veya beklenmedik bir sürüm raporluyorsa, çalıştırma başarısız olarak kaydedilir ve operatörler yeniden denemeden önce güncelleme öncesi yedeği geri yüklemeli veya dosya sistemi/önbellek durumunu incelemelidir.

CMS sürüm, güncelleme, yayınlama, Publisher, yapıt veya migration uyumluluk davranışını değiştirmeden önce WebBlocks Advisor'a danışın ve yanıtı rapora bir uygulama notu olarak ekleyin. Advisor doğru yanıta sahip değilse, tek seferlik bir iş akışı uydurmak yerine önce ilgili bilgi kaynağını veya parçayı (chunk) güncelleyin.

System Updates ekranı, bir yönetici güncellemeyi başlatmadan önce insan tarafından okunabilir sürüm ayrıntılarını gösterir. Ana akışta iki kart vardır: Install Update ve Update Details. Install Update; bir güncellemenin mevcut olup olmadığını, çalışan CMS kod sürümünün güncel olduğunu, yerel/kaynak sürümün en son yayımlanmış paketten daha yeni olduğunu, güncellemenin uyumsuz olduğunu veya güncelleme sunucusu yanıtına güvenilemeyeceğini açıklar. Görünen özet, çalışan CMS kod sürümünü en son yayımlanmış sürümle karşılaştırır. Kayıtlı kurulu sürüm bir kurulum geçmişi/güncelleme kalıcılığı değeri olarak kalır ve Update Readiness içinde incelenebilir, ancak Install Update eyleminin etkinleştirilmesinde kullanılmaz.

Update Details; sürüm notlarını, güncelleme hazırlığını ve son güncelleme çalıştırmasını WebBlocks UI akordeon satırlarının arkasında tutar. Update Readiness, hedef sürümün sürüm notları değil, kurulum ve güncelleme servisi hazırlık özetidir. Last Update Run, en son ilgili çalıştırma özetini gösterir ve gerektiğinde ayrıntıları bir modalda açar. Paylaşımlı barındırma destek vakaları için süper yönetici destek raporu indirmesi mevcuttur; güvenli sürüm/hazırlık/çalıştırma özetlerini içerir; token'ları, gizli anahtarları, mutlak yerel yolları ve ham yığın izlerini hariç tutar.

Güncelleme çalıştırma kayıtları, güncelleme denetimlerinden ve uygulama/iptal akışlarından sonra otomatik olarak budanır. Varsayılan saklama en son beş çalıştırmayı tutar; en son başarısız çalıştırma ise daha yeni bir başarılı çalıştırma oluşana kadar korunur. Ana yönetici ekranı eski çalıştırmaları listelemez. Terminal operatörleri saklanan çalıştırmaları php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last ve php artisan webblocks:updates:runs --failed ile inceleyebilir; kontrollü budama php artisan webblocks:updates:prune-runs --keep=5 ile yapılabilir.

Update Details içindeki kompakt Release Notes akordeonu; title, summary, highlights, fixes, compatibility_notes, migration_notes, asset_notes, operator_notes ve technical_notes gibi alanlardan gelen yapılandırılmış üstveriyi işler. CMS bu alanları kaçışlanmış düz metin olarak işler; hazırlık denetimlerini, kayıtlı kurulu sürümü ve düşük seviyeli yanıt ayrıntılarını Update Readiness içinde tutar.

Eski release_notes dizesi, daha eski sürüm yükleri için desteklenmeye devam eder. Sürüm notu yoksa ekranda No release notes were provided for this release. yazar. Güncelleyici, değişiklikleri sürüm numaralarından çıkarsamaz.

Sürüm üstverisi yerelde composer release:prepare ile hazırlanır ve composer release:publish-update ile doğrudan Publisher servisine yayımlanır. Yerleşik yayıncı, yapılandırılmış sürüm ayrıntı alanlarını üst düzey ve iç içe ayrıntı yük biçimlerinde eski release_notes değeriyle birlikte gönderir; böylece güncelleme servisi, uyumlu System Updates ekranlarına zengin notlar sunarken eski istemciler düz notlar almaya devam eder. Uyumlu istemciler yapılandırılmış ayrıntıları üst düzey alanlardan, details, release_details ve güncelleme sunucusunun meta.release_details veya meta.details yüklerinden okur.

GitHub Actions artık sürüm paketleri oluşturmaz veya güncelleme üstverisi yayımlamaz ve .github iş akışları CMS deposunda kasıtlı olarak bulunmaz. Bakımcılar kaynak geçmişi için git commit'leri ve etiketleri göndermeye devam edebilir, ancak System Updates yalnızca güncelleme sunucusu üstverisini ve paket yapıtlarını tüketir. publisher.webblocksui.com hem yayınlama hem de güncelleme tüketimi için kanonik servistir: bakımcılar https://publisher.webblocksui.com/api/updates/publish adresine yayımlar, kurulu CMS siteleri en son üstveriyi https://publisher.webblocksui.com/api/updates/latest adresinden okur ve üstveri yapıt URL'leri https://publisher.webblocksui.com/downloads/... paket indirmelerine işaret etmelidir. CMS ürün kodu; varsayılan sürüm sunucusuna, ürün anahtarına, stable kanalına, latest yoluna ve publish yoluna ReleaseDefaults aracılığıyla sahip olduğundan, kurulu CMS siteleri normal .env dosyalarında Publisher/güncelleme sunucusu, ürün veya kanal ortam anahtarlarını yapılandırmaz. Eski updates.webblocksui.com köprüsü yalnızca tarihseldir ve etkin bir yapılandırma yolu olarak kullanılmamalıdır.

Bakımcı komutları:

Bakımcı yayınlaması normalde yalnızca WEBBLOCKS_PUBLISHER_TOKEN gerektirir. Kurulu CMS güncelleme denetimleri; https://publisher.webblocksui.com, ürün webblocks-cms, kanal stable ve okuma yolu /api/updates/latest için ürün varsayılanlarını kullanır; bakımcı yayınlaması aynı ürün sahipliğindeki kimliği ve /api/updates/publish yayınlama yolunu kullanır. Önbelleğe alınmış yapılandırmayla yapılan yayınlama çalıştırmaları yalnızca yayıncı token'ını proje .env dosyasından tazeler; böylece yerelde yapılandırılmış bir token, kabuk dışa aktarımları gerekmeden algılanır. Dry-run, yükleme yapmadan girdileri doğrular. Token olmadan yapılan gerçek bir yayınlama, kontrollü bir yayımlanmadı durumu raporlar, başarısız kodla çıkar ve bir sürüm yayını olarak kabul edilmemelidir.

Uygulama içi bir System Update başarıyla uygulandığında, WebBlocks CMS kurulum sonrası akışı şu sırayla çalıştırır:

• geçerli kurulum stratejisi için migration işleme
• önbellek temizleme adımları
• güncelleme çalıştırması kaydı
• kurulu sürümün kalıcı hâle getirilmesi

Normal System Updates yayımlanmış sürüm paketlerini uygular. Çekirdek katalog tohumlamayı, block-types:sync-core komutunu, simge eşitlemeyi, slot türü onarımını, sayfa yerleşimi slot onarımını veya geniş kapsamlı katalog onarımını otomatik olarak çalıştırmaz. Bir sürüm bir şema veya veri dönüşümü gerektiriyorsa, bu o sürüm için açık bir güncelleme migration'ı olarak ele alınmalıdır.

Önbellek temizleme adımları; dosya değişiminden sonra güncellenen paket sahipliğindeki Blade yerleşimlerinin ve yardımcıların yeniden derlenmesi için Laravel config, view, uygulama önbelleği ve route temizlemelerini içerir. OPcache'in zaman damgalarını doğrulamayacak şekilde yapılandırıldığı canlı PHP-FPM kurulumlarında, PHP'nin güncelleme öncesi paket sınıflarını bellekten sunmaya devam edememesi için başarılı bir güncellemeden sonra ilgili PHP-FPM servisini yeniden yükleyin.

Kaynak üzerinden bakımı yapılan bakım çalışma kopyalarında migration işleme, tarihsel kök database/migrations yetkisini korur ve artisan migrate --force çalıştırır. Bu yol yalnızca kök Composer manifesti, WebBlocks\\Cms\\ => packages/webblocks-cms/src/ dahil olmak üzere bakım deposu WebBlocks CMS autoload yetkisine sahip olduğunda seçilir.

webblocks:install ile kurulan paket-yerel yeni Composer tüketicilerinde System Update, ana Laravel uygulamasının kök database/migrations dizinini çalıştırmaz. Paket dizininin varlığı tek başına bir kaynak çalışma kopyası işareti değildir. Bu, 0001_01_01_000000_create_users_table.php gibi bekleyen Laravel başlangıç migration'larının, paketin yeni kurulum şemasıyla oluşturulan CMS tablolarıyla çakışmasını önler. Paket tüketici güncellemeleri sürüm yapıtını vendor/fklavyenet/webblocks-cms konumuna uygular ve yalnızca vendor/fklavyenet/webblocks-cms/database/migrations/updates dizini PHP migration dosyaları içerdiğinde bu dizindeki özel paket sahipliğindeki güncelleme migration'larını çalıştırır; aksi hâlde güncelleyici ana uygulama migration'larının atlandığını kaydeder ve önbellek temizlemeleri ile kurulu sürüm kalıcılığıyla devam eder. Paket güncelleme migration'ları, tam veritabanı yedekleme/geri yükleme taşınabilirliği için gereken eksik üst anahtarların eklenmesi gibi güvenli mevcut kurulum şema onarımları için de doğru yerdir.

Çalışma zamanı kodunun gerektirdiği her WebBlocks CMS şema değişikliği her iki kurulum yolunu da desteklemelidir:

1. Yeni/paket tüketici kurulumları: normal veya yeni kurulum şema migration yolunu güncelleyin.
2. System Updates üzerinden güncellenen mevcut paket-yerel kurulumlar: paket database/migrations/updates altına bir paket güncelleme migration'ı ekleyin; kurulu tüketiciler bunu vendor/fklavyenet/webblocks-cms/database/migrations/updates konumundan çalıştırır.

Yalnızca yeni kurulum şeması yeterli değildir. Yeni çalışma zamanı kodu bir tablo veya sütun bekliyorsa, sürüm mevcut kurulumlar için bir güncelleme migration'ı içermeli ya da güncelleme, yeni kod yolu ham 500 hatası verebilmeden önce güvenli biçimde başarısız olmalıdır. Paket-yerel System Updates, başarılı bir güncellemeden sonra sıradan kullanıcıların bir siteye SSH ile bağlanıp elle migration çalıştırmasını gerektirmemelidir.

Başarılı bir paket-yerel System Update; uygulanan kodun, gerekli şemanın, önbellek temizlemelerinin ve uygulama sonrası sürüm/şema hazırlığının hizalı olduğu anlamına gelir. Yeni eklenen şemaya bağımlı yönetici, API ve çalışma zamanı sayfaları, eksik şema için ham framework/veritabanı hataları göstermek yerine kontrollü kurulum/güncelleme yönlendirmesi göstermelidir. 1.32.146'dan 1.32.147'ye API token olayı referans hata modudur: cms_api_tokens yalnızca normal migration yolunda vardı, paket-yerel QuizTem kodu güncelledi ve 1.32.147 bir paket güncelleme migration'ı ile zarif hazırlık işleme ekleyene kadar System -> API Tokens ham 500 hatası verdi.

Şema değişikliği içeren sürüm raporları şunları açıkça yanıtlamalıdır:

• yeni kurulum şema yolu güncellendi: evet/hayır
• paket güncelleme migration'ı eklendi: evet/hayır
• güncelleme migration'ı regresyon testi eklendi: evet/hayır
• eksik şema için zarif davranış gerekli/eklendi: evet/hayır

Paket geçişi sırasında bazı kurulumlarda hâlâ bayat bir kurulum kökü packages/webblocks-cms kopyası veya eski bir iç içe vendor geçiş kopyası bulunabilir. Bu yollar eski geçiş yapıtlarıdır, etkin paket-yerel doğruluk kaynağı değildir. Paket-yerel System Update artık vendor/fklavyenet/webblocks-cms konumundaki kanonik Composer paket kökünü değiştirir ve hedef sürümü bu paket kökünden doğrular. packages/webblocks-cms dizinini ikinci bir güncellenmiş çalışma zamanı kopyası olarak tutmaz.

Daha eski kurulumlarda vendor/fklavyenet/webblocks-cms konumunda artisan, app/, bootstrap/, packages/webblocks-cms/, plugins/ veya tests/ gibi kök dosyalar içeren depo biçimli bir Composer vendor dizini bulunabilir. System Update, bu vendor dizinini düz paket köklü yapıtla değiştirerek normalleştirir. Ortaya çıkan paket kökü; composer.json, src/, docs/, routes/, resources/, database/, public/, config/ ve stubs/ gibi paket dosyalarını doğrudan vendor/fklavyenet/webblocks-cms altında içerir. Paket-yerel güncellemeler, optimize edilmiş autoload dosyalarını yeniden üretmeden önce Composer'ın kurulu paket üstverisini normalleştirir; ardından üretilen Composer autoload üstverisinin WebBlocks\Cms\ ad alanını eski iç içe vendor/fklavyenet/webblocks-cms/packages/webblocks-cms/src yerine vendor/fklavyenet/webblocks-cms/src konumundan çözdüğünü doğrular. Bayat iç içe yollar kalırsa, güncelleme çalıştırması bozuk bir yönetici çalışma zamanıyla başarı raporlamak yerine başarısız olur.

Modern güncellemeler, v1.32.56 geçişiyle getirilen /webadmin yönetici ve /cms varlık ayrımını korur. /cms yalnızca statik bir varlık ad alanıdır, bir yönetici öneki değildir; çünkü Nginx try_files, Laravel bir rota görmeden önce /cms/ yolunu fiziksel public/cms/ dizini olarak çözebilir. Güncellemeler; ne kurulum kökünde ne de paket public varlıklarında CMS sahipliğindeki /cms yönetici takma adlarını, /cms yönlendirmelerini, /admin rotalarını veya bir public/cms/index.php devrini geri getirmemelidir.

Bu bölüm tarihseldir. 1.31.53 güncelleyicisi eski kök yönetimli arşiv sözleşmesini doğruluyordu: artisan ve composer.json arşiv kökünde ya da tek bir sarmalayıcı dizin içinde bulunmak zorundaydı. 1.32.31 gibi paket köklü yapıtlar kasıtlı olarak kök artisan içermediğinden, bu eski istemciler uygulamadan önce Package validation failed because composer.json and artisan were not found at the archive root. hatasıyla başarısız oluyordu.

Emekliye ayrılan köprü stratejisi iki adımlıydı:

• Eski kök yönetimli biçimde bir köprü sürüm yapıtı yayımlayın veya yeniden yayımlayın; bu yapıt, eski App\Support\System\Updates\* sarmalayıcılarına hâlâ sahip olan ve katı paket köklü fklavyenet/webblocks-cms arşivlerini zaten doğrulayan köprü yetenekli bir kaynaktan derlenmelidir. 1.32.33 köprüsü için kaynak ref v1.32.30 idi.
• Paket köklü sürümleri minimum_client_version değeri 1.32.18 veya daha yenisi olacak şekilde yayımlayın; böylece eski istemcilere köprüden önce en son paket köklü yapıt sunulmuyordu.
• Köprü uygulandıktan sonra kurulu güncelleyici, modern sürümlerin kullandığı katı paket köklü fklavyenet/webblocks-cms yapıt biçimini doğrulayıp uygulayabiliyordu.

scripts/build-root-managed-bridge-archive.sh VERSION [OUTPUT_DIR] [GIT_REF] yalnızca eski biçimli köprü ZIP'i için arşivlenmiş/elle kurtarma aracı olarak tutulur; örneğin, scripts/build-root-managed-bridge-archive.sh 1.32.33 dist v1.32.30. Derleyici; .env, storage/, project/, public/site/, public/storage ve kök config/ gibi kurulum sahipliğindeki yolları kasıtlı olarak hariç tutar; packages/webblocks-cms/config altındaki paket sahipliğindeki varsayılanlar paket çalışma zamanının parçası olmaya devam eder. Rutin paket-yerel doğrulama bu köprü yolunu çalıştırmaz.

Tamamlanan tarihsel yol 1.31.53 -> 1.32.33 bridge -> 1.32.34+ package-rooted idi. 1.32.30 gibi zaten köprü yetenekli kurulumlar köprüyü atlayıp doğrudan paket köklü bir 1.32.34+ sürümüne güncellendi. Güncel sürüm kapıları yalnızca paket köklü yapıtı ve paket-yerel güncelleyici davranışını korur.

Katalog onarımı ve eşitlemesi, System Updates'ten ayrı, açık bakım eylemleridir. Şunu kullanın:

Komut; --block-types, --slot-types, --page-layouts ve --icons ile kapsamlandırılmış bakımı destekler. Oluşturulacak, güncellenecek, değiştirilmeden bırakılacak veya atlanacak satırları raporlamak için önce --dry-run ile çalıştırın. Komut idempotenttir, kuruluma özgü/özel katalog satırlarını korur ve özel satırları silmez.

Daha düşük seviyeli blok türü eşitlemesi uyumluluk için kullanılabilir durumda kalır:

Blok türü onarım yolu, veritabanı destekli block_types kataloğunu mevcut kurulumlarda birlikte gelen çekirdek CMS kataloğuyla hizalı tutar:

• eksik çekirdek blok türleri oluşturulur
• mevcut çekirdek blok türleri yerinde güncellenir
• kuruluma özgü özel blok türleri korunur
• yinelenen çekirdek satırlar oluşturulmaz

Bu bakım iş akışı, her sürüm paketi uygulamasının geniş kapsamlı veritabanı destekli katalog onarımı yapmasına gerek kalmadan bir kurulumun katalog satırlarını yenileme ihtiyacını karşılar.

Güncelleyici, hâlâ kanonik CMS upstream'ine işaret eden git destekli bir kurulum klonu içinde çalıştığında, CMS artık kurulum sonrası komutlardan sonra origin push'u da otomatik olarak devre dışı bırakır; böylece gelecekteki yanlışlıkla yapılan git push denemeleri açıkça başarısız olurken normal fetch veya pull erişimi kullanılabilir kalır.

• Operasyonlar
• Kurulum
• Geliştirme İş Akışı