WordPress 5.6’daki Yenilikler (Erişilebilirlik, Performans, Güvenlik)

WordPress 5.6, yakında piyasaya sürülecek olan bir sonraki büyük WordPress sürümüdür. Bugün sizinle Core’da birleştirilen en ilginç özelliklere ve eklemelere derinlemesine dalmaktan heyecan duyuyoruz.

Gibi önceki sürümlerde , WordPress 5.6 Gutenberg yüklü ve henüz kendi web sitelerinde güncel eklentisi yok WordPress kullanıcıları için düzenleme deneyimini geliştirmeye Blok Editör birkaç versiyonunu içermektedir.

Yine de her şey Blok Düzenleyici ile ilgili değil. WordPress Core’a, yeni bir varsayılan Yirmi Yirmi Bir teması , büyük sürümler için otomatik güncellemeler, PHP 8.0 için daha iyi destek, REST API Kimlik Doğrulaması için Uygulama Şifreleri gibi çeşitli özellikler eklenmiştir .

Ve WordPress 5.6’da çok daha fazlası var. Erişilebilirlik iyileştirmeleri, kullanıcı arayüzü geliştirmeleri, tonlarca hata düzeltmesi ve geliştiriciler için büyük bir değişiklik listesi göreceğiz.

WordPress 5.6 geliştirme döngüsü hakkında daha fazla bilgi edinmek isterseniz aşağıdaki bağlantıları kontrol edin:

• 20 Ekim 2020: Beta 1
• 27 Ekim 2020: Beta 2
• 2 Kasım 2020: Beta 3
• 12 Kasım 2020: Beta 4
• 17 Kasım 2020: RC 1
• 1 Aralık 2020: RC 2
• 7 Aralık 2020: WordPress 5.6 sürümü için boş çalışma
• 8 Aralık 2020: WordPress 5.6 sürümü için hedeflenen tarih

Dalmaya hazır mısınız? Hadi gidelim:İçindekiler

1. Blok Düzenleyicideki Yenilikler
2. Yeni Bir Varsayılan Tema: Yirmi Yirmi Bir
3. Büyük Sürümler için Otomatik Güncellemeler
4. WordPress 5.6’daki Site Sağlığı Değişiklikleri
5. REST API Kimlik Doğrulaması için Uygulama Şifreleri
6. PHP 8 için Daha İyi Destek
7. Geliştiriciler için Ek Değişiklikler

Blok Düzenleyicideki Yenilikler

WordPress 5.6 ile, Gutenberg eklentisinin çeşitli sürümleri çekirdek haline getirildi, bu nedenle WordPress kullanıcıları ve yazarları , düzenleyicide birkaç iyileştirme fark etmelidir. Gelişmiş blok kalıpları, bilgi panelinde kelime sayıları, iyileştirilmiş klavye gezintisi, iyileştirilmiş sürükle ve bırak kullanıcı arayüzü ve çok daha fazlasını göreceğiz.

Blok düzenleyiciye eklenen tüm iyileştirmelerin ve değişikliklerin daha kapsamlı bir listesi için sürüm duyurusu yayınlarına bakın: 8.6 , 8.7 , 8.8 , 8.9 , 9.0 , 9.1 ve 9.2 . Gutenberg 9.3 ve 9.4’te uygulanan hata düzeltmeleri ve performans iyileştirmeleri de WordPress 5.6’ya dahil edilmiştir.

Blok düzenleyicide göreceğimiz daha ilginç değişikliklere dalalım.

1. Bloklar, Desenler ve Kullanıcı Arayüzü İyileştirmeleri
2. API V2’yi engelle
3. Blok Geliştiriciler için Ek Özellikler ve İyileştirmeler

Bloklar, Desenler ve Kullanıcı Arayüzü İyileştirmeleri

Yeni blok özellikleri, geliştirmeleri ve hata düzeltmeleri genel düzenleme deneyimini iyileştirecektir. Ayrıca, erişilebilirlik konusunda harika çalışmalar yapıldı . Aşağıda, web sitenizi WordPress 5.6’ya güncelledikten sonra, blok düzenleyicide göreceğiniz en ilginç özelliklerin özenle seçilmiş seçimini bulacaksınız.

Kapak Bloğundaki Videolar için Konum Kontrolleri

Gutenberg 8.6’dan beri Kapak Bloklarına eklenen videolar için konum kontrolleri, kullanıcıların odak noktasını hareket ettirmesine ve videolar için özel bir konum belirlemesine olanak tanır . Bu işlevsellik daha önce yalnızca görüntü arka planları için mevcuttu.

Kapak Bloğu için Video Konum Kontrolleri

Konum değerleri, odak noktası seçicide herhangi bir yere tıklanarak ve / veya klavyenizdeki ok tuşları kullanılarak ayarlanır. Shift tuşunu basılı tutarak değerleri 10’a kadar atlayabilirsiniz (ayrıca bkz . # 22531 ).

Blok Desen Güncellemeleri

WordPress 5.6 ayrıca Gutenberg 8.6 ile eklenen birkaç blok kalıbı geliştirmesini içerir .

Büyük başlık ve paragrafın düzeni, metni ve rengi güncellendi ( # 23858 )

İki sütun metin başlığı metin bloğunun dışına taşındı ve sütunların üzerine yerleştirildi ( # 23853 )

Alıntı deseni şimdi üstünde bir görüntü ve altta bir ayırıcı içerir.

Yeni Alıntı deseni bir görüntü ve bir ayırıcı içerir

Gutenberg 8.7 ( # 24143 ) ile yeni bir Başlık ve paragraf kalıbı eklendi .

WordPress 5.6’da Başlık ve Paragraf deseni

Blok ekleyici için iyi bir kullanılabilirlik iyileştirmesi , modelleri kategoriye göre filtrelemenize olanak tanıyan blok modeli kategorisi açılır listesidir . Bu, aralarından seçim yapabileceğiniz tonlarca deseniniz olduğunda son derece kullanışlıdır ( # 24954 ).

Blok deseni kategorisi açılır menüsü

Video Altyazı Desteği

Video Blokları artık video altyazılarını destekliyor .

Video Bloğuna video altyazıları ekleme

Editörler ve içerik oluşturucular, ” öğeyi kullanarak zamanlanmış metin parçalarını (altyazılar veya altyazılar gibi) görüntülemek için bir format ” ( # 25861 ) olan WebVTT formatında (Web Video Metin Parça Formatı) video altyazıları sağlamalıdır .<track>

Farklı dillerdeki altyazılara bağlanan öğeleri izleyin

.Vtt dosyalarınızı yükledikten sonra , site görüntüleyenlerin favori dillerinde altyazıları etkinleştirmelerine izin verilecektir.

Birden Çok Bloğu Sütun Bloğuna Dönüştürün

Kullanılabilirlikte ilginç bir gelişme, birden fazla seçilen bloğu bir Sütun Bloğuna dönüştürme yeteneğidir.

Birden çok blok seçin

Sütunlarda göstermek istediğiniz blokları seçmeniz ve ardından blok araç çubuğunun sağ üst düğmesini tıklamanız yeterlidir.

Seçilen her blok, bir Sütun Bloğunun bir sütununa dönüştürülecektir.

Üç blok üç sütuna dönüştürüldü

Kapak Bloğundaki Arka Plan Desenleri

Kapak blokları artık arka plan desenlerini gösterebilir.

Arka plan desenli bir kapak bloğu

Bir arka plan deseni eklemek için, bir desen görüntüsü yükleyin, ardından Tekrarlanan arka plan seçeneğini açın ( WordPress’teki Medya Kitaplığı hakkında bilmeniz gereken her şey burada ).

İşiniz bittiğinde, odak noktası seçiciyi ihtiyaçlarınıza göre ayarlayın ve sabit arka planlara sahip farklı kombinasyonlar deneyin.

Medya ve Metin Bloğuna Görüntü Boyutu Kontrolü Eklendi

İle Gutenberg 9.1 , yeni bir görüntü boyutu kontrolü Medya ve Metin Blokta görüntülere eklenmiştir.

Kullanıcılar artık mevcut tüm resim boyutları ( # 24795 ) arasından seçim yapabilir .

Medya ve Metin Bloğunda Görüntü Boyutu Kontrolü

API V2’yi engelle

Yeni bir Block API sürümü , blokların sarmalayıcı öğelerini oluşturmalarını sağlar. Yeni API sürümünün amacı, düzenleyicinin DOM’unu hafifletmek ve ön sayfa içeriğiyle eşleşmesini sağlamaktır. Ella van Durpe’ye göre:

Bunun en büyük yararı, temaların ve eklentilerin, biçimlendirme düzenleyicide aynıysa blok içeriğini daha kolay biçimlendirebilmesidir.

Yeni sürüm, apiVersionözelliği blok türü kaydında bildirmeyi gerektirir :

registerBlockType( name, { apiVersion: 2 } );

Yeni API ayrıca blok işlevinde useBlockProps kancayı gerektirir Edit. Bu kanca, bir bloğun sarmalayıcı öğesini bir blok öğesi olarak işaretler.

Bu kancaya iletilen herhangi bir özellik birleştirilecek ve sarmalayıcı öğesine döndürülecektir. Geliştirici notlarından alınan aşağıdaki örnek, basit bir kullanım durumunu gösterir:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

Daha fazla örnek için bkz. Blok API sürüm 2 .

Blok Geliştiriciler için Ek Özellikler ve İyileştirmeler

Block API Sürüm 2’nin yanı sıra, geliştiricilerin geçmesi gereken eklemelerin bir listesi burada .

Blok Destekler API

Blok Destekler API’si , blok geliştiricilerin bloklarına özellik eklemelerine olanak tanır. Renkler , arka planlar, yazı tipi boyutları Blok Destekleri API’si aracılığıyla bloklara eklenebilecek pek çok özellikten sadece birkaçıdır.

WordPress 5.6 ayrıca , “tutarlılığı artırmak ve bu seçenekleri bloklar halinde tanıtmayı kolaylaştırmak için” birkaç yeni blok desteği sunar.

Geliştiriciler karşılık gelen tuşlara ekleyerek yeni blok destekleri kullanabilirsiniz supportsmülkiyet block.json dosyasına veya doğrudan içine registerBlockType fonksiyonu .

Block Supports dev notundan alınan aşağıdaki örnek , nasıl çalıştığını gösterir:

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

Stil değeri, has-<value>-<preset-category>sınıf aracılığıyla (önceden ayarlanmış değerler için) veya bir styleöğeyle (özel değerler için) sarmalayıcı öğeye otomatik olarak eklenir .

Bu nedenle, Blok Desteklerinin yeni Blok API V2 ile kullanılması amaçlanmıştır .

Blok Destekleri dinamik bloklarla da kullanılabilir .

createBlocksFromInnerBlocksTemplate API’si

Geliştiriciler, diğer blokları içeren özel bloklar oluşturmak için InnerBlocks bileşenini kullanabilir . Örnekler, Sütunlar bloğu ve Sosyal Bağlantılar bloğudur.

Yeni createBlocksFromInnerBlocksTemplateBlok API, InnerBlocks şablonundan bloklar oluşturmanıza olanak tanır.

Depper görünümü ve kod örneği için geliştirme notlarına bakın .

Araç Çubuğu Bileşenleri

Birkaç değişiklik Araç Çubuğu bileşenlerini de etkiler :

1. ToolbarGroup Bileşeni

WordPress 5.6’dan önce Araç Çubuğu bileşeni, geliştiricilerin ilgili seçenekleri ortak bir kapta gruplamasına izin veriyordu. Şimdi bunun yerine yeni bir ToolbarGroup bileşeni kullanılmalıdır.

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>

2. ToolbarButton ve ToolbarItem Bileşenleri

Tablanabilir öğelerin doğrudan araç çubuğu öğeleri (yani <button>) olarak kullanılması kullanımdan kaldırılmıştır. Erişilebilirliği iyileştirmeyi amaçlayan araç çubuğu öğeleri, düğmeler için Araç Çubuğu Düğmesi ve diğer kontroller için Araç Çubuğu Öğesi kullanılarak eklenebilir . Aşağıdaki örnekte bir düğme ve bir açılır menü gösterilmektedir :

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

Çekirdek Blok Modellerini Devre Dışı Bırakma

Çekirdek desenler artık core-block-patternsdestek bayrağı ( # 24042 ) kullanılarak devre dışı bırakılabilir

Satır İçi Resim Düzenleyiciyi Devre Dışı Bırakma

Gutenberg 8.4, kullanıcıların görüntüleri doğrudan Blok Düzenleyiciden düzenlemesine olanak tanıyan bir Satır İçi Görüntü Düzenleme özelliği ekledi .

Satır İçi Görüntü Düzenleme

Geliştiriciler artık block_editor_settingsfiltreyi ( # 23966 ) kullanarak Resim Düzenleyiciyi devre dışı bırakabilir :

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );

Satır İçi Resim Düzenleme devre dışı bırakıldı

Yeniden Kullanılabilir Bloklar Ayrı Bir Pakete Taşındı

Daha önce @wordpress/editorpaketin bir parçası olan yeniden kullanılabilir bloklar, diğer editörlerde de kullanılabilmeleri için pakete taşındı@wordpress/reusable-blocks .

Yeni Bir Varsayılan Tema: Yirmi Yirmi Bir

WordPress 5.6 yepyeni bir varsayılan tema içerir. Twenty Twenty-One , tek bir sütun düzeni ve bir altbilgi kenar çubuğu ile oldukça erişilebilir, minimalist bir WordPress temasıdır .

Yeni tema, bir sistem yazı tipi yığını ve pastel arka plan renklerine dayalı minimal bir renk paleti kullanıyor.

Büyük Sürümler için Otomatik Güncellemeler

Otomatik güncellemeler, site güvenliğini artırmayı  ve site yöneticilerinin WordPress web sitelerini güncel tutmalarını kolaylaştırmayı amaçlayan, WordPress 3.7’de sunulan temel bir özelliktir .

Önceki sürümlerde otomatik küçük çekirdek güncellemeler uygulanmış olsa da, WordPress 5.6 ile site yöneticileri artık büyük sürümler için otomatik güncellemeleri manuel olarak da etkinleştirebilir (bunun üzerine bir saniye içinde daha fazlası).

Ne yazık ki, bu çok önemli bakım görevi, teknik bilgisi olmayan kullanıcılar için hala biraz kafa karıştırıcı olabilir. 

Bu nedenle, WordPress 5.6 , site yöneticilerinin ana çekirdek sürümler için otomatik güncellemeleri etkinleştirmesine izin veren yeni bir arayüz sunar .

Bu özelliğin kapsamı WordPress 5.6 beta döngüsü sırasında değişti ve orijinal geliştirici notu değiştirildi. Deyişiyle Jb Audras ,

Çekirdek otomatik güncellemelerinin ilk kapsamı şu konuma taşındı:

• Kullanıcı arayüzünün tasarımına bazı güncellemeler sağlayın.
• Mevcut kurulumlar için, davranış bugün olduğu gibi kalacaktır: varsayılan olarak küçük güncellemeleri etkinleştirmiştir, ancak bir kullanıcının büyük güncellemeleri seçmesi gerekir (ana bilgisayarlar veya ajanslar tarafından halihazırda kullanımda olan sabitler ve filtreler yine de geçerli olacaktır) öncelik).
• Yeni yüklemeler için varsayılan davranış değişecektir: varsayılan olarak küçük güncellemeleri etkinleştirmiş ve varsayılan olarak büyük güncellemeleri etkinleştirmiştir.

WordPress 5.6’dan başlayarak, yeni bir kullanıcı arayüzünün WordPress’in tüm yeni sürümleri için otomatik güncellemeleri etkinleştirmenize izin veren bir onay kutusu sağladığı Güncellemeler ekranında ana çekirdek sürümler için otomatik güncellemeleri etkinleştirebilirsiniz .

WordPress’in tüm yeni sürümleri için otomatik güncellemeleri etkinleştirin

Büyük sürümler için çekirdek otomatik güncellemeleri etkinleştirdikten sonra, yalnızca bakım ve güvenlik sürümleri için otomatik güncellemelere geç seçeneğine tıklayarak bunların yalnızca bakım ve güvenlik için tetiklenmesini etkinleştirebilirsiniz .

Yalnızca bakım ve güvenlik sürümleri için otomatik güncellemelere geçin

Geliştiriciler için Büyük Otomatik Çekirdek Güncellemeleri

Büyük çekirdek otomatik güncellemeler etkin olduğunda Birincisi, auto_update_core_majorseçenek depolanan veri tabanı ile option_valuesağladı. Dolayısıyla, get_site_option( 'auto_update_core_major' )geri dönerse true, otomatik güncellemeler onay kutusu işaretlenir.

Ardından WordPress, WP_AUTO_UPDATE_COREsabit veya allow_major_auto_core_updatesfiltre aracılığıyla büyük çekirdek otomatik güncellemelerin etkinleştirilip etkinleştirilmediğini kontrol eder ve onay kutusunu buna göre ayarlar.

Geliştiriciler, WP_AUTO_UPDATE_COREsabiti aşağıda gösterildiği gibi falseveya minorolarak ayarlayarak da büyük çekirdek otomatik güncellemeleri devre dışı bırakabilirler (ayrıca bkz. Wp-config.php aracılığıyla Arka Plan Güncellemelerini Kontrol Etme ):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Bu olası değerleri Not için WP_AUTO_UPDATE_COREolan true(tümü), 'beta', 'rc', 'minor', false.

Varsayılan olarak büyük çekirdek otomatik güncellemeleri devre dışı bırakmak için başka bir seçenek de yeni allow_major_auto_core_updatesfiltreyi kullanmaktır:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Çekirdeğe Otomatik Güncellemelerin Eklenmesi Hakkında Birkaç Yorum

Aralık 2018’de Matt Mullenweg, “Kullanıcıların temel Core sürümlerinin otomatik güncellemelerine katılmaları için bir yol sağlama” nın 7 numara olduğu 2019 için dokuz önceliği paylaştı . Belki biraz geç, ancak oraya geliyoruz.

Büyük otomatik çekirdek güncellemelerin, WordPress güvenliği ve genel deneyim üzerinde büyük bir etkisi olmalıdır. Açık olan bir şey var: Teknik açıdan, büyük otomatik çekirdek güncellemeleri özelliği, WordPress 5.6 sürümüyle% 100 başarılamayan karmaşık bir görevdir.

Slack üzerine düşünceli bir tartışmanın ardından Josepha Haden , Core katılımcılarından gelen endişeleri ve soruları özetledi .

Uzun vadeli ana hedef, WordPress ekosisteminin tamamında ( web’in% 30’undan fazlası) güvenliği artırmak için WordPress web sitelerinin çoğunda otomatik güncellemelerin mevcut olmasıdır .

Her neyse, Çekirdek Lider Geliştirici Helen Hou-Sandí’ye göre :

Aklımda, uygulanması gereken çok zor bazı teknik şeyler var ve bunun için ÇOK disiplinli ve odaklanmış teknik ürün sahipliği gerekiyor

Bu nedenle, zaman içinde büyük otomatik temel güncellemeler kullanıcı arayüzünde ek değişiklikler ve iyileştirmeler görmeliyiz. Şu andan itibaren bekleyebileceğimiz şey bu:

WordPress 5.6:

• Mevcut kurulumlarda, büyük güncellemelerin kullanıcı tarafından etkinleştirilmesi gerekir . Halihazırda kullanımda olan herhangi bir sabit ve filtre öncelikli olacaktır. Küçük güncellemeler varsayılan olarak etkindir.
• Yeni kurulumlarda, hem küçük hem de büyük güncellemeler varsayılan olarak etkindir .

WordPress 5.6.1:

• Geri bildirime göre temel otomatik güncellemeler kullanıcı arayüzünde bazı değişiklikler görmeliyiz.

WordPress 5.7:

• Büyük otomatik güncellemeleri devre dışı bırakan herkes için Site Sağlığı ekranına bir dürtü eklenmelidir.
• WordPress 5.7’deki kurulum sürecine bir otomatik güncelleme seçeneği eklenmelidir.

Temel otomatik güncellemelerle ilgili büyük bir endişe, kullanıcıların güvenidir. Helen’e göre:

Kullanıcıların, özellikle de WordPress ve / veya güncellemelerle daha önce kötü deneyimler yaşamış olanların güvenini proaktif olarak istemek için hala çok çalışabileceğimize inanıyorum.

Bununla birlikte, her WordPress web sitesi Çekirdek, eklenti ve temanın bir karışımıdır . Helen’in sözleriyle:

Çekirdek güncellemeler genel olarak oldukça güvenlidir ve yerleşik bazı korumalar vardır, ancak siteler herhangi bir kaynaktan herhangi bir kodu çalıştırabildiğinden, “her tür WordPress web sitesi” için “% 100” diye bir şey yoktur.

Temel otomatik güncellemeleri etkinleştiren kullanıcılar, web sitelerini düzenli olarak yedeklemeli veya planlarında otomatik yedeklemeler sağlayan bir web barındırıcısı seçmelidir .

Çekirdek otomatik güncellemeler, eklenti ve tema otomatik güncellemeleri dahil olmak üzere genel güncelleme deneyimini de etkileyecektir. Joost de Valk bir yorumda şunları kaydetti:

WordPress çekirdek otomatik güncellemelerini varsayılan olarak etkinleştirirsek, eklentiler için de aynısını yapmalıyız. Aksi takdirde, eklentiler ve temalar, temel güncellemeler nedeniyle düzeltmeleri gereken şeyler için güncellenemez. Bence kullanıcılar da şunu bekler: eğer WordPress otomatik güncellemeleri, eklentileri ve temaları da otomatik olarak güncellenmelidir.

WordPress 5.6’daki Site Sağlığı Değişiklikleri

Burada tartışılan tüm özelliklerin yanı sıra, WordPress 5.6 , artık arka planda farklı şekilde davranan Site Sağlığı aracının geliştirilmiş bir sürümünü de getiriyor .

Site Sağlık Kontrolü Veri Doğrulaması

Bir doğrulayıcı artık Site Sağlığı testleri için sorun yanıtlarını kontrol ediyor. Doğrulayıcı, herhangi bir geçersiz yanıtı atarak Site Sağlığı aracının ölümcül hatalara neden olmasını önler ve diğer kontrolleri durdurur.

Şu andan itibaren, geçersiz yanıtlar Site Sağlığı göstergesini ( # 50145 ) etkilemeyecektir .

REST Endpoind aracılığıyla Eşzamansız Kontroller

Site Sağlığı aracı, site sahiplerinin web sitelerinin sağlık durumundan haberdar olmalarını sağlayan güçlü bir güvenlik aracıdır.

Bu araç, web sitenizin sağlık durumuna genel bir bakış sağlayan bir dizi güvenlik testi yürütür.

Bu testler iki kategoriye ayrılır: doğrudan testler , sayfa yüklemede çalıştırma ve tamamlanması biraz zaman alabilen ve daha sonra JavaScript çağrılarıyla çalıştırılacak zaman uyumsuz testler .

Size rekabet avantajı sağlayan bir barındırma çözümüne mi ihtiyacınız var? 

Daha önce, bu testler admin-ajax.php çağrısıyla gerçekleştiriliyordu . WordPress 5.6 ile işler admin-ajax.php’den uzaklaşıyor ve bunun yerine yeni bir REST API uç noktası kullanılacak. WordPress 5.6’dan başlayarak, eşzamansız testler ad alanı altında bulunabilir /wp-json/wp-site-health/v1.

Yeni REST API geliştirmesi sayesinde, eklentiler ve temalar da REST uç noktalarından yararlanabilir ve sağlık testleri için Ajax eylemleriyle sınırlı değildir.

Her zaman uyumsuz test artık has_restvarsayılan olan bağımsız değişkeni bildirebilir false.

Aşağıdaki wp-admin / includes / class-wp-site-health.php kodu , WordPress 5.6’daki eşzamansız test dizisini gösterir:

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

Planlanmış Site Sağlığı kontrolleri :

Yavaş sayfa yüklemelerini ve zaman aşımlarını önlemek için eşzamansız testler uygulanmış olsa da , programlanmış testlerde bu tür bir endişe mevcut değildir.

Bunu akılda tutarak, has_restyukarıda bahsettiğimiz argümana ek olarak , test dizileri async_direct_test, bir testin çağrılabilir bir örneği olması gereken argümanı da (yukarıdaki kodu kullanarak) bildirebilir .

Planlanmış bir etkinlik sırasında bir test çalıştırılırsa test, REST API uç noktasını kullanmaz, ancak doğrudan çalışır.

REST API Kimlik Doğrulaması için Uygulama Şifreleri

Uygulama Şifreleri , çeşitli WordPress API’lerine kimliği doğrulanmış isteklerde bulunmak için yeni bir sistemdir.

Parolalar 24 karakter uzunluğundadır ve manuel olarak veya REST API aracılığıyla oluşturulabilen büyük harf, küçük harf ve sayısal karakterlerden oluşur.

Manuel olarak yeni bir uygulama şifresi oluşturmak için Profil ekranınıza gidin ve sayfayı aşağı kaydırın.

Kullanıcı Profili ekranındaki Uygulama Şifreleri

Uygulama Şifreniz için bir isim seçin ve onaylayın. WordPress yeni şifrenizi gösterecektir.

Yeni bir uygulama şifresi

Uygulama parolaları, aşağıda gösterildiği gibi, boşluklarla ayrılmış 4 karakterlik parçalar halinde görüntülenir:

gsUc UhkU 0ScI gdRd TGoU vrW5

Bununla birlikte, parolalar boşluklu veya boşluksuz kullanılabilir :

Yetkilendirme akışından geri aktarılan uygulama parolaları boşluk içermez. Uzun bir ipe bakan birinin el ile giriyorlarsa yerlerini korumalarını kolaylaştırmak için kesinlikle oradalar.

Boşluksuz ya da – heck – yığın halinde kullanılabilirler, eğer isterseniz, muhtemelen her karakterden sonra bir boşluk ekleyebilirsiniz.

Kullanıcı Profili ekranında, uygulama parolalarını görüntüleyebilir, oluşturabilir ve iptal edebilirsiniz. Son Kullanılan ve Son IP sütunları, artık kullanılmayan ve iptal edilmesi gereken parolaları kolayca bulmanızı sağlar.

Son Kullanılan ve Son IP alanları

Bu yazının yazıldığı sırada, Uygulama Şifreleri, REST API kimlik doğrulamalı istekler ve eski XML-RPC API ile kullanılabilir . Ancak, gelecekte ek API’lerle birlikte kullanılan Uygulama Şifrelerini görmemiz gerekir. George Stephanis şöyle açıklıyor:

Uygulama şifreleri kimlik doğrulama şeması, kullanılabilir olduklarında WordPress için gelecekteki API’lara da uygulanabilir. Örneğin, GraphQL veya diğer sistemler WordPress’te etkinleştirilirse, uygulama şifreleri onlara kutudan çıktıkları gibi sağlam, yerleşik bir kimlik doğrulama altyapısı sağlar.

Postman’da REST API’ye kimliği doğrulanmış bir çağrı

Wp-login.php’de Uygulama Şifrelerini kullanmak mümkün değildir.

Bu özelliğin daha yakından görünümü ve daha fazla teknik bilgi için aşağıdaki kaynakları kontrol ettiğinizden emin olun:

• Teklif: REST API Kimlik Doğrulaması / Uygulama Şifreleri
• Uygulama Şifreleri: Entegrasyon Kılavuzu
• Uygulama Şifreleri özellik eklentisi

PHP 8 için Daha İyi Destek

PHP 8.0 , tonlarca yeni özellik ve optimizasyon getiriyor ve bu da onu dilin evriminde gerçek bir kilometre taşı yapıyor. PHP’nin daha yeni sürümü, geriye dönük uyumluluğu bozan birçok güncelleme getiriyor ve kullanımdan kaldırılan birçok özellik artık resmi olarak kaldırıldı. Bu nedenle, WordPress’te PHP 8 için destek eklemek büyük bir zorluktur.

Aslında, WordPress Core katılımcıları WordPress 5.6’yı PHP 8 ile uyumlu hale getirmek için büyük çaba sarf etseler bile, olası her sorunun keşfedilmesini beklememeliyiz. Buradaki amaç, tüm WordPress ekosisteminin PHP 8 ile uyumlu olduğu bir noktaya ulaşmaktır ki bu şu anda kırılması gerçekten zor bir ceviz gibi görünüyor.

Ayrıca, bir WordPress web sitesi en az bir tema ve değişken sayıda eklenti içerir. Bu nedenle, beklediğimiz şey, WordPress Core’da PHP 8 için iyi bir destek olabilir, ancak eklentilerin ve temaların PHP 8 için hızla destek ekleyeceğine inanmak zor.

Jonathan Desrosiers’in söylediklerine katılıyoruz :

Daha geniş ekosistemdeki (eklentiler, temalar vb.) PHP 8 desteğinin durumunu bilmek imkansızdır. Bu nedenle, WordPress 5.6’nın PHP 8 ile “beta uyumlu” olduğu düşünülmelidir.

“PHP 8 ile Beta uyumlu” hala çok fazla çaba gerektiren devam eden bir süreci temsil etmek için iyi bir ifade gibi görünüyor, ancak aynı zamanda şimdiye kadar yapılan harika işleri de kabul ediyor.

Ancak,

Tüm eklenti ve tema geliştiricilerinin yanı sıra barındırma toplulukları da kodlarını PHP 8 ile uyumlu hale getirmeleri için çağrılır. Bu, WordPress’in gerçek anlamda “tam uyumluluğa” daha erken ulaşmasını ve son kullanıcıların yükü taşımasına gerek kalmadan sağlar.

Önemli

Otomatik testlerle belirlenen uyumsuzlukların çoğu giderilmiş olsa da, bazı manuel testler hala gereklidir. Bu nedenle, canlı web sitenizi PHP 8’e yükseltmeden önce bir aşamalandırma veya yerel ortamda titiz uyumluluk testleri çalıştırmanız şiddetle tavsiye edilir .

Dikkat Edilmesi Gereken Bazı PHP 8 Değişiklikleri

Yukarıda bahsettiğimiz gibi, WordPress’i PHP 8 ile tamamen uyumlu hale getirmek devam eden bir çalışmadır. Jonathan Desrosiers, WordPress geliştiricilerinin bilmesi gereken PHP 8 özelliklerinin ve değişikliklerinin bir listesini sağlar .

Adlandırılmış Parametreler

İle PHP adlı argümanlar parametre adı yerine parametre konumuna dayalı bir işleve argümanlar geçmek artık mümkün. Bu , kendi kendini belgeleyen, bağımsız değişkenler sırayla bağımsız olan ve varsayılan değerler isteğe bağlı olarak atlanabilen kod yazmaya olanak tanır .

Ne yazık ki, şu anda adlandırılmış parametreler, WordPress’te geriye dönük uyumluluk sorunlarına neden olabilir. Bunun ana nedeni, mevcut denetim tamamlanana kadar parametre adlarının önceden haber verilmeksizin değiştirilebilmesidir. Yani, bu yazının yazıldığı sırada:

WordPress işlevlerini ve sınıf yöntemlerini çağırırken adlandırılmış parametrelerin kullanılması açıkça desteklenmez ve bu denetim tamamlanana kadar kesinlikle önerilmez , çünkü denetim sırasında parametre adları önceden haber verilmeksizin değiştirilebilir. Bu denetim tamamlandığında, gelecekteki bir geliştirici notunda duyurulacaktır.

Dahili Fonksiyonlar için Katı Tip / Değer Doğrulamaları

Geçersiz tipte bir parametre geçirirken, dahili ve kullanıcı tanımlı işlevler farklı davranır. Kullanıcı tanımlı işlevler a atar TypeError, ancak dahili işlevler çeşitli koşullara bağlı olarak çeşitli şekillerde davranır.

Bu tutarsızlıkları gidermek için, PHP 8’de dahili parametre çözümleme API’leri , bir parametre türü uyuşmazlığı durumunda her zaman a üretir ThrowError.

WordPress Core’da katı tür bildirimi kullanılmaz. Ancak Core katılımcılar, geçersiz türlerin Core işlevlere aktarılmasını önlemek için çalışıyor. Bu çalışma tamamlanana kadar, bu PHP 8 değişikliği TypeError, “özellikle bir filtreye bağlanan kod aracılığıyla bir değerin türü yanlış bir şekilde değiştirilirse” e yol açabilir .

Aritmetik ve Bitsel Operatörler için Daha Katı Tip Kontrolleri

PHP’nin önceki sürümlerinde, bir dizi, kaynak veya aşırı yüklenmemiş nesnede aritmetik ve bitsel işleçlerin kullanılmasına izin veriliyordu, ancak davranış tutarsızdı ve hatta bazen mantıksızdı:

var_dump([] % [42]);
// int(0)

PHP 8 ile davranış her zaman aynıdır ve tüm aritmetik ve bitsel operatörler TypeError, işlenen bir dizi, kaynak veya aşırı yüklenmemiş nesne olduğunda bir istisna atar (bkz . RFC ).

Bu, birçok hata, uyarı ve uyarı değişiklikleri gibi Core katılımcılarından ekstra çalışma gerektiren başka bir değişikliktir.

Yine, hala çözülmemiş birkaç sorun nedeniyle , canlı web sitenizde PHP 8’e geçiş yapmadan önce bir evreleme veya geliştirme ortamında uyumluluk testleri çalıştırmanız şiddetle tavsiye edilir . WordPress ve PHP 8.0 hakkında daha fazlasını okuyun .

Geliştiriciler için Ek Değişiklikler

WordPress 5.6, geliştiriciler için tonlarca değişiklik getiriyor ve hepsini listemize dahil edemedik. Ancak burada, bakmaya değer olduğunu düşündüğümüz ilk 3:

1. wp_after_insert_post Eylem Kanca

WordPress 5.6’dan önce save_posts, bir gönderi yayınlandıktan sonra özel kod çalıştırmak için veya benzer eylemler kullanabilirsiniz . Şimdi WordPress 5.6 wp_after_insert_post, yalnızca terimler ve meta veriler kaydedildiğinde tetiklenen yeni eylem kancasını sunuyor.

Ek olarak, bu kancaların ateşlenmesini önlemek için çeşitli işlevler güncellendi. Yeni $fire_after_hooksparametre wp_insert_posts(), wp_update_post()ve wp_insert_attachment()işlevlerine eklenmiştir . Olarak ayarlanırsa false, son ek kancaların ateşlenmesini önler.

Daha derin bir genel bakış için geliştirici notuna göz atın .

2. Tip Döküm

Fonksiyonlarını Typecasting intval(), strval(), floatval()ve boolval()direkt tiplemeleri lehine Çekirdek kaldırılmıştır:

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

Doğrudan tip yayınlama , tip yayınlama işlevlerinden ~ 6 kat daha hızlı olduğundan , bu değişikliğin performans üzerinde doğrudan etkileri vardır .

3. WP_Error Nesneleri

WP_ErrorSınıf birden birleştirme izin geliştirilmiştir WP_Errorbirine örneklerini. Önceden bunu yalnızca elle yapabiliyordunuz. Şimdi, WordPress 5.6, birden çok WP_Errorörneği işlemeye yardımcı olacak üç yeni yöntem sunuyor . Aşağıdaki kod, geliştirici notundan bir örnektir :

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Geliştiriciler için Daha Fazla Okumalar

WordPress 5.6 tarafından sunulan geliştirmeye odaklanan tüm değişikliklerden bahsetmek imkansızdır, ancak aşağıdaki kaynakları kullanarak bunlar hakkında daha fazla bilgi edinebilirsiniz:

• WordPress ile birlikte gelen jQuery sürümünü güncelleme
• Çekirdek jQuery’yi sürüm 3’e güncelleme – bölüm 2
• WordPress ve PHP 8.0
• WordPress 5.6’da REST API Batch Framework
• WordPress 5.6’da çeşitli geliştirici odaklı değişiklikler

Özet

WordPress 5.6, hem kullanıcılar hem de geliştiriciler için tonlarca özellik ve değişiklik içeren büyük bir sürümdür. Web teknolojilerinin evriminin WordPress güvenliğini, performansını , kullanılabilirliğini ve erişilebilirliğini doğrudan nasıl etkilediğini görmekten her zaman heyecan duyuyoruz .

Ancak evrim asla durmaz ve gelecekteki potansiyel sürüm tarihlerine şimdiden göz atabiliriz .

Şimdi size kalmış: WordPress 5.6’da en çok neyi seviyorsunuz? WordPress 5.7’ye hangi özelliklerin eklenmesini istersiniz ?