En Yaygın WordPress Tema Geliştirme Hataları (ve Nasıl Düzeltilir)
Yayınlanan: 2019-05-14WordPress.org tema dizinine bir tema göndermek, çalışmanızı paylaşmanın ve WordPress topluluğuna katkıda bulunmanın harika bir yoludur. Şu anda dizinde 7000'den fazla tema var ve bunların en popüleri 300.000'i aşan aktif kurulum. (WordPress ile paketlenmiş ve milyonlarca yükleme sayısına sahip Yirmi____ Tema dahil değildir.)
Temanızı dizine göndermeden önce, inceleme sürecini anlamak önemlidir çünkü temanız bu gereksinimleri karşılamıyorsa anında reddedilebilir.
3 veya daha fazla farklı sorunu olan temalar onaylanmadı olarak kapatılabilir. Ancak tema yazarları, sorunları düzelttikten sonra temayı yeniden gönderebilir.
https://make.wordpress.org/themes/handbook/review/required/
Gözden geçirenler sizin tarafınızdadır ve gerekli standartları karşıladıktan sonra temanızın yayına girdiğini görmek ister. Temanızın dizine eklenmesini engelleyen yalnızca küçük sorunları varsa, gözden geçireniniz bunları düzeltmek için sizinle birlikte çalışacaktır.
Ne yazık ki temanızda çok fazla sorun varsa onaylanmadı olarak kapatılacaktır. Sorunları düzeltmeye karar verirseniz, temayı tekrar yükleyebilirsiniz - ancak sıranın arkasına katılacak.
100'den fazla temayı inceleme deneyimime dayanarak, temaların onaylanmasını engelleyen en yaygın sorunları tespit edebildim. Bunları bu yazıda sizinle paylaşarak, sıraya takılmaktan veya reddedilmekten kaçınmanıza yardımcı olabileceğimi umuyorum.
Temanızı Yükleme
Bir tema yüklediğinizde, incelenmek üzere kuyruğa katılır. Temanızın sıranın önüne geçmesi ve ilk incelemesini alması ortalama olarak iki ay sürecektir. Tüm gözden geçirenler, incelemeleri tamamlamak için sınırlı bir süreye sahip gönüllülerdir. Bekleme süresini çeşitli faktörler etkileyebilir. Daha fazla kişi temaları incelemek için gönüllü olduğunda, sıra hızla hareket eder. Tersine, çok sayıda sorunu olan temalar gönderildiğinde kuyruğu yavaşlatır.
Tüm gereksinimleri karşılayan bir tema göndermek, inceleme sürecini çok daha sorunsuz hale getirir ve nihayetinde temanız daha erken yayına girer. Bu kılavuzda, temanızı sırada bekletecek ve onaylanmasını engelleyecek en yaygın sorunları keşfedeceğiz.
Not: Sorunsuz temalar gönderme konusunda geçmişi olan tema yazarları, 'Güvenilir Yazarlar' olmak için başvurabilir.
Adlandırma Sorunları
Bir tema yüklediğinizde, yapılan ilk kontrol, adın önceden alınmış olup olmadığını görmektir. Dizinde bu ada sahip bir tema göremeseniz bile, sıklıkla seçtiğiniz adın zaten alınmış olduğu söylenecektir.
Bu nasıl olabildi? Bunun nedeni, testin yalnızca dizine karşı değil, tüm WordPress ekosistemine karşı kontrol etmesidir. Bir tema herhangi bir yerde (Github, ThemeForest, vb.) yayınlandıysa ve 50'den fazla etkin kuruluma sahipse, bu ad kullanılamaz.
Not: Temanızı başka bir yerde yayınladıysanız ve 50'den fazla kurulum biriktirdiyseniz, bu adı dizinde kullanmaya devam edebilirsiniz.
Çıkışsız Çıktı
Tema yorumcuları güvenliği çok ciddiye alır, hatta özel bir kaynak bile vardır. Güvenli temalar yazmak üzerine bütün bir makale yazılabilir, ancak bu bölümde bir yönü keşfedeceğiz: çıktıdan kaçmak.
Çıkışsız çıktı, temanızın kullanıcılarını riske atar. Burada, çıkış yapılmayan bir değer ($title) örneği verilmiştir:
$title = get_option('my_custom_title');
yankı '<h2>' . $başlık . '</h2>';Yukarıdakilerle ilgili sorun şu ki, $title'ın ne tür bir değer olması gerektiğini bildiğimiz halde, durumun böyle olup olmadığını kontrol etmedik.
Bir bilgisayar korsanı, veritabanındaki 'my_custom_title' değerini değiştirmeyi başardıysa, temanız bu değeri verir. Bu, amaçlanan çıktıyı satır içi Javascript ile değiştirebilecekleri için büyük bir risk oluşturur:
alert('Bu tehlikelidir');
Çözüm, yalnızca beklediğimiz veri türünü içerdiğinden emin olmak için tüm çıktılardan kaçmaktır.
Örneğimiz şu şekilde düzeltilebilir:
$title = get_option('my_custom_title');
yankı '<h2>' . esc_html( $başlık ) . '</h2>';esc_html kullanmanın dezavantajı, tüm HTML etiketlerini çıkarmasıdır. $başlık kalın veya italik içeriyorsa, örneğin:
$title = 'Bu makale <strong>çok</strong> faydalı'; echo esc_html( $başlık);
'Çok' kelimesi ön uçta kalın olmaz; bunun yerine <strong>very</strong> kodunun çıktısını alır.
Bu, bağlam için doğru çıkış işlevlerini kullanmanın neden önemli olduğunu gösterir. Çıktıda biraz HTML bekliyor olsaydık, wp_kses_post() veya wp_kses() kullanmak ve $allowed_html parametresini ayarlamak daha iyi olurdu.
Çıktı veren işlevlerden de kaçılması gerekir:
<a href="<?php echo esc_url( get_permalink() ); ?>">
İstisna, adlarında 'the_' içeren WordPress temel işlevleridir, bunlar genellikle zaten kaçar.
function the_permalink( $post = 0 ) {
/**
* Geçerli gönderi için kalıcı bağlantının görüntüsünü filtreler.
*
* @1.5.0'dan beri
* 4.4.0'dan beri `$post` parametresi eklendi.
*
* @param string $permalink Geçerli gönderi için kalıcı bağlantı.
* @param int|WP_Post $post Kimliği, WP_Post nesnesi veya 0. Varsayılan 0.
*/
echo esc_url( application_filters( 'the_permalink', get_permalink( $post ), $post ) );
}Çevrilemez Metin
Dizine kabul edilmek için tüm temaların %100 'çeviriye hazır' olması gerekir. Bu, tema çıktılarınızın her metin dizesinin çevrilebilir olması gerektiği anlamına gelir.
WordPress zaten çeviri sürecini idare edecek sistemlere ve işlevselliğe sahiptir, sadece dizelerinizin doğru işlevleri kullandığından emin olmanız gerekir.
Uygulaması basit olsa da, insanların HTML yazma şekline aykırı olduğu için bu genellikle gözden kaçar.
Normalde, şöyle bir şey yapabilirsiniz:
<h1>404 - Bulunamadı</h1>
Çevrilebilir hale getirmek için biraz PHP eklemeniz gerekir:
// __ işlevler yerelleştirmenin temelidir.
<h1><?php echo __( '404', 'metin-alanı'); ?>
// _e işlevleri değeri yansıtır.
<h1><?php _e( '404', 'metin-alanı'); ?>
// Dizeden kaçış ve yankı.
<h1><?php esc_html_e('404', 'metin-alanı'); ?>
// yerelleştirme ve değişkenler.
<h1><?php _n( 'Bir gönderi', '%s gönderi', $count, 'metin-alanı'); ?>İşlevlerin çıktısı olan dizeler de çeviriye hazır olmalıdır:
// çeviriye hazır değil :-(
<?php next_posts_link('Eski Yazılar'); ?>
// çeviriye hazır :-)
<?php next_posts_link( esc_html__( 'Eski Yazılar', 'metin-alanı' ) ); ?>İpucu: codex.wordpress.org'daki birçok kod örneği çeviri işlevlerini kullanmaz, bu yüzden bunları kopyalayıp yapıştırırken dikkatli olun.

Kaynakları Yanlış Sıralama
Temanızın kullandığı .css ve .js dosyaları doğru işlevler kullanılarak sıralanmalıdır: CSS için wp_enqueue_style() ve Javascript için wp_enqueue_script().
Yaygın bir hata, komut dosyalarını ve stilleri doğrudan <head> içine veya </body>'den önce kodlamaktır. Bu yaklaşımın iki sorunu vardır:
1. Kaldırmak imkansız
Bir eklentinin yüklediğiniz bir kaynağı kaldırması gerekiyorsa, bu mümkün değildir. Uygun kuyruğa alma işlevlerini kullanmış olsaydınız, şu şekilde yapılabilirdi:
/**
* Temayı javascriptten çıkarın.
*
* Geç öncelikli (100) wp_enqueue_scripts eylemine bağlı,
* böylece betiğin kuyruğa alınmasından sonra olur.
*/
function wptavern_dequeue_script() {
wp_dequeue_script('tema komut dosyaları');
}
add_action('wp_enqueue_scripts', 'wptavern_dequeue_script', 100);2. Çift Yükleme
Örneğin jQuery gibi bir kaynağı kuyruğa alırsanız ve bir eklenti de onu kuyruğa alırsa, WordPress onu yalnızca bir kez yükleyecek kadar akıllıdır.
/**
* jQuery'yi kuyruğa al
*
* jQuery, iki sıraya rağmen yalnızca bir kez yüklenecektir.
* jQuery, WordPress ile paketlenmiştir, bu nedenle bir src belirtmemize gerek yoktur.
*/
function wptavern_enqueue_script() {
wp_enqueue_script('jquery');
wp_enqueue_script('jquery');
}
add_action('wp_enqueue_scripts', 'wptavern_enqueue_script');Bunun yerine jQuery'yi <head> içine sabit kodlasaydınız, WordPress'in bunu bilmesinin bir yolu olmazdı ve iki kez yüklenirdi.
Eklenti Bölgesi İşlevselliği
Bir temanın kapsamı yalnızca bir web sitesinin tasarımını ve estetiğini ele almalıdır, diğer tüm işlevler WordPress'in kendisi veya eklentileri tarafından ele alınmalıdır.
Tema yazarları, temalarına daha fazla değer katmak amacıyla genellikle SEO kontrolleri veya özel gönderi türleri gibi ekstra işlevler eklemeye çalışırlar.
İşlevselliği bir temada birleştirmeyle ilgili sorun, verilerin taşınabilir olmamasıdır. Örnek olarak SEO kontrollerini alın, kullanıcı temayı değiştirirse sayfalarını optimize etmek için yaptıkları tüm çalışmaları kaybeder. Buna karşılık, bir SEO eklentisi kullanıldığında, veriler ve işlevsellik temadan bağımsızdır ve tema değiştirilirken korunur.
Eklenti bölgesi işlevselliğine ilişkin bazı örnekler:
- Analitik/İzleme
- SEO kontrolleri
- İletişim Formları
- Kısa kodlar
- Gutenberg Blokları
İpucu: Kodunuz veritabanına yazıyorsa, büyük olasılıkla eklenti bölgesidir. Bunun istisnası tasarımla ilgili ayarlardır (kenar çubuğu konumu, renkler vb.).
Önek Eklenmiyor
Önekleme, kodunuzun eklentilerden gelen kodla çakışmamasını sağlamanın bir yoludur. PHP'de ad alanı, aynı etkiyi elde etmenin daha iyi bir yoludur. Ancak, bazı kullanıcılar hala PHP'nin (5.2) bu özelliği desteklemeyen eski sürümlerini kullanıyor.
Justin Tadlock, önek eklenmesi gereken yaygın şeylerin bir listesini paylaştı:
- PHP işlev adları.
- PHP sınıf isimleri.
- PHP küresel değişkenler.
- Eylem/Filtre kancaları.
- Komut dosyası tutamaçları.
- Stil kolları.
- Görüntü boyutu adları.
Kaynak: https://themereview.co/prefix-all-the-things/
// fonksiyon örneği.
benim_prefix_example();
// sınıf örneği.
sınıf Önek_Örneğim { … }
// eylem ve filtre örneği.
do_action('benim_prefix_action');
application_filters('my_prefix_filter', $değerler);
// örnekleri kuyruğa al.
wp_enqueue_script('my_prefix_script', get_template_directory_uri() .'/js/custom-script.js');
wp_enqueue_style( 'benim_prefix_style', get_template_directory_uri() .'/css/styles.css');
// resim boyutu örneği.
add_image_size('my_prefix_image_size', 220, 180); // 220 piksel genişlik ve 180 piksel yükseklik.İstisna: Üçüncü taraf kaynakları kuyruğa alırken bir önek eklemeyin:
// bir üçüncü taraf komut dosyasını (chosen.js) kuyruğa alma.
wp_enqueue_script('seçilmiş', get_template_directory_uri() .'/js/chosen.js');Lisans Sorunları
Temanız ve tüm dosyaları %100 GPL uyumlu olmalıdır. Buna resimler, kitaplıklar, komut dosyaları ve yazı tipleri dahildir.
Tüm üçüncü taraf kaynakları, kaynak ve lisans bilgilerini listelemelidir.
Tüm lisanslar GPL dostu olmadığı için bu gereksinim özellikle zor olabilir. Unsplash lisansının yalnızca bir kısıtlaması vardır:
"Bu lisans, benzer veya rakip bir hizmeti çoğaltmak için Unsplash'tan fotoğraf derleme hakkını içermez."
Ancak bu kısıtlama, GPL uyumlu olmaması için yeterlidir ve bu nedenle wordpress.org temalarında Unsplash görüntüleri görmezsiniz.
GPL uyumlu lisansların bir listesi burada mevcuttur – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
Son günlerde, stocksnap.io, listeledikleri tüm görseller CC0 (GPL uyumlu) olarak lisanslandığından, dizindeki en yaygın görsel kaynağı olmuştur.
Ekran Görüntüsü Hataları
Gereksinimler, ekran görüntünüzün temanızın reklam gibi görünmeyen, düzenlenmemiş bir temsili olması gerektiğini belirtir. Bu, hiçbir photoshop çalışması, bindirme, kenarlık veya süslü efekt olmadığı anlamına gelir.
Görseller, yukarıda incelediğimiz aynı lisanslama gerekliliklerine de uymalıdır.
Bonus: Bir Kodlama Standardı Kullanın
Sizin için okunması ve anlaşılması kolay görünen kod, kodunuzu kontrol etmek için yalnızca 10-15 dakikası olan bir gözden geçiren için tam tersi olabilir.
Kodlama standartlarına ilişkin herhangi bir gereklilik bulunmamakla birlikte, birini takip etmek kodunuzun okunmasını, anlaşılmasını ve bakımını kolaylaştırır. Ben şahsen 'WordPress Kodlama Standartları'nı kullanıyorum ve tavsiye ediyorum, başkaları da var.
PHP_CodeSniffer ve WordPress kural setini kod düzenleyicinizde kullanmak, bir standarda bağlı kalmayı çok daha kolay hale getirebilir – https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards
Çözüm
Tema Gereksinimleri, son kullanıcı düşünülerek oluşturulur. Yukarıda sıraladığım yaygın hataları yapmaktan kaçının, temanız kısa sürede onaylanacaktır. İnceleme sürecini diğer taraftan da deneyimlemek isterseniz, hakem bile olabilirsiniz.
