WordPress Geliştiricilerinin Yaptığı En Yaygın 10 Hata

Biz sadece insanız ve insan olmanın özelliklerinden biri de hata yapmamızdır. Öte yandan, biz de kendi kendimizi düzeltiyoruz, yani hatalarımızdan ders almaya meyilliyiz ve umarım aynı hataları iki kez yapmaktan kaçınabiliriz. WordPress alanında yaptığım hataların çoğu, çözümleri uygularken zaman kazanmaya çalışmaktan kaynaklanıyor. Bununla birlikte, bu yaklaşımın bir sonucu olarak sorunlar ortaya çıktığında, bunlar genellikle başlarını yoldan çıkarırlar. Hata yapmak kaçınılmazdır. Ancak, diğer insanların (ve tabii ki kendinizin!) gözden kaçırdığı şeylerden öğrenmek, proaktif olarak izlemeniz gereken bir yoldur.

Yaygın Hata No. 1: Hata Ayıklamayı Kapalı Tutmak

Kodum düzgün çalışıyorken neden hata ayıklamayı kullanmalıyım? Hata ayıklama, tüm PHP hatalarının, uyarılarının ve bildirimlerinin (kullanımdan kaldırılan işlevler vb. hakkında) görüntülenmesine neden olacak, WordPress'te yerleşik bir özelliktir. Hata ayıklama kapatıldığında, hiç görmediğimiz, ancak bunlarla zamanında ilgilenmezsek daha sonra sorunlara neden olabilecek önemli uyarılar veya bildirimler oluşturulabilir. Kodumuzun sitemizin diğer tüm unsurlarıyla güzel bir şekilde oynamasını istiyoruz. Bu nedenle, WordPress'e herhangi bir yeni özel kod eklerken, geliştirme çalışmanızı her zaman hata ayıklama açıkken yapmalısınız (ancak siteyi üretime dağıtmadan önce kapattığınızdan emin olun!).

Bu özelliği etkinleştirmek için WordPress kurulumunuzun kök dizinindeki wp-config.php dosyasını düzenlemeniz gerekir. İşte tipik bir dosyanın bir pasajı:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Bu, kullanılabilecek kapsamlı bir yapılandırma seçenekleri listesi değildir, ancak önerilen bu kurulum, çoğu hata ayıklama gereksinimi için yeterli olacaktır.

Yaygın Hata No. 2: wp_head Hook Kullanarak Komut Dosyaları ve Stiller Ekleme

Komut dosyalarını başlık şablonuma eklemenin nesi yanlış? WordPress zaten çok sayıda popüler komut dosyası içerir. Yine de, birçok geliştirici wp_head kancasını kullanarak ek komut dosyaları ekleyecektir. Bu, aynı komut dosyasının, ancak farklı bir sürümün birden çok kez yüklenmesine neden olabilir.

Burada sıraya koymak, web sitemize komut dosyaları ve stiller eklemenin WordPress dostu bir yolu olan kurtarmaya geliyor. Eklenti çakışmalarını önlemek ve bir betiğin sahip olabileceği bağımlılıkları ele almak için kuyruğa alma kullanıyoruz. Bu, sırasıyla komut dosyalarını ve stilleri kuyruğa almak için wp_enqueue_script veya wp_enqueue_style yerleşik işlevleri kullanılarak elde edilir. İki işlev arasındaki temel fark, wp_enqueue_script ile komut dosyasını sayfanın altbilgisine taşımamıza izin veren ek bir parametreye sahip olmamızdır.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Komut dosyasının ekranın üst kısmındaki içeriği oluşturması gerekmiyorsa, ekranın üst kısmındaki içeriğin hızlı bir şekilde yüklendiğinden emin olmak için onu güvenli bir şekilde alt bilgiye taşıyabiliriz. Komut dosyasını kuyruğa almadan önce kaydetmek iyi bir uygulamadır, çünkü bu, başkalarının eklentinizin çekirdek kodunu değiştirmeden kendi eklentilerindeki tanıtıcı aracılığıyla komut dosyanızın kaydını silmelerine olanak tanır. Buna ek olarak, kayıtlı bir komut dosyasının tanıtıcısı, kuyruğa alınmış başka bir komut dosyasının bağımlılık dizisinde listeleniyorsa, vurgulanan kuyruğa alınmış komut dosyası yüklenmeden önce bu komut dosyası otomatik olarak yüklenir.

Yaygın Hata No. 3: Alt Temalardan Kaçınmak ve WordPress Çekirdek Dosyalarını Değiştirmek

Bir temayı değiştirmeyi planlıyorsanız her zaman bir alt tema oluşturun. Bazı geliştiriciler, yalnızca tema yükseltmesinden sonra değişikliklerinin üzerine yazıldığını ve sonsuza kadar kaybolduğunu keşfetmek için ana tema dosyalarında değişiklik yapacaktır.

Bir alt tema oluşturmak için, alt temanın klasörünün bir alt dizinine aşağıdaki içeriğe sahip bir style.css dosyası yerleştirin:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

Yukarıdaki örnek, varsayılan WordPress teması olan Twenty Sixteen'i temel alan bir alt tema oluşturur. Bu kodun en önemli satırı, çocuğu klonladığınız ana temanın dizin adıyla eşleşmesi gereken "Şablon" kelimesini içeren satırdır.

Aynı ilkeler WordPress çekirdek dosyaları için de geçerlidir: Çekirdek dosyaları değiştirerek kolay yolu seçmeyin. Bir WordPress yükseltmesinden sonra değişikliklerinizin üzerine yazılmasını önlemek için WordPress takılabilir işlevleri ve filtreleri kullanarak bu ekstra çabayı gösterin. Takılabilir işlevler, bazı temel işlevleri geçersiz kılmanıza izin verir, ancak bu yöntem yavaş yavaş aşamalı olarak kaldırılmakta ve filtrelerle değiştirilmektedir. Filtreler aynı sonucu elde eder ve çıktılarının değiştirilmesine izin vermek için WordPress işlevlerinin sonuna eklenir. Bir hile, takılabilir işlevleri kullanırken her zaman işlevlerinizi if ( !function_exists() ) ile sarmaktır, çünkü bu sarmalayıcı olmadan aynı takılabilir işlevi geçersiz kılmaya çalışan birden fazla eklenti önemli bir hata üretecektir.

Yaygın Hata No. 4: Sabit Kodlama Değerleri

Genellikle bir değeri (URL gibi) kodun herhangi bir yerine sabit kodlamak daha hızlı görünür, ancak yol boyunca hata ayıklama ve bunun sonucunda ortaya çıkan sorunları giderme için harcanan zaman çok daha fazladır. İstenen çıktıyı dinamik olarak üretmek için ilgili işlevi kullanarak, kodumuzun sonraki bakımını ve hata ayıklamasını büyük ölçüde basitleştiriyoruz. Örneğin, sitenizi bir test ortamından sabit kodlanmış URL'lerle üretime geçirirseniz, aniden sitenizin çalışmadığını fark edeceksiniz. Bu nedenle, dosya yolları ve bağlantılar oluşturmak için aşağıda listelenen gibi işlevler kullanmalıyız:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Sabit kodlamanın bir başka kötü örneği, özel sorgular yazmaktır. Örneğin, bir güvenlik önlemi olarak, varsayılan WordPress veri tablosu önekini wp_ yerine wp743_ gibi biraz daha benzersiz bir şeyle değiştiriyoruz. Tablo önekleri ortamlar arasında değişebileceğinden, WordPress kurulumunu taşırsak sorgularımız başarısız olur. Bunun olmasını önlemek için wpdb sınıfının tablo özelliklerine başvurabiliriz:

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Tablo adı için wp_users değerini nasıl kullanmadığıma dikkat edin, bunun yerine WordPress'in çalışmasına izin veriyorum. Tablo adlarını oluşturmak için bu özellikleri kullanmak, doğru sonuçları döndürmemize yardımcı olacaktır.

5 No'lu Genel Hata: Sitenizin Dizine Eklenmesini Engellememek

Arama motorlarının sitemi dizine eklemesini neden istemeyeyim? İndeksleme iyi, değil mi? Bir web sitesi oluştururken, siz onu oluşturmayı bitirip kalıcı bir bağlantı yapısı oluşturana kadar arama motorlarının sitenizi dizine eklemesini istemezsiniz. Ayrıca, site yükseltmelerini test ettiğiniz bir hazırlama sunucunuz varsa, Google gibi arama motorlarının bu yinelenen sayfaları dizine eklemesini istemezsiniz. Birden fazla ayırt edilemeyen içerik olduğunda, arama motorlarının bir arama sorgusu için hangi sürümün daha alakalı olduğuna karar vermesi zordur. Arama motorları bu gibi durumlarda yinelenen içeriğe sahip siteleri cezalandırır ve bunun sonucunda siteniz arama sıralamalarında zarar görür.

Aşağıda gösterildiği gibi, WordPress Okuma Ayarlarında "Arama motorlarının bu siteyi dizine eklemesini engelle" yazan bir onay kutusu vardır, ancak bunun altında "Bu isteği yerine getirmek arama motorlarına kalmış" şeklinde not edilmesi gereken önemli bir nokta vardır.

Arama motorlarının genellikle bu isteği yerine getirmediğini unutmayın. Bu nedenle, arama motorlarının sitenizi dizine eklemesini güvenilir bir şekilde engellemek istiyorsanız, .htaccess dosyanızı düzenleyin ve aşağıdaki satırı ekleyin:

 Header set X-Robots-Tag "noindex, nofollow"

6 No'lu Genel Hata: Bir Eklentinin Etkin Olup Olmadığını Kontrol Etmemek

Eklentim her zaman açıksa neden bir eklenti işlevinin olup olmadığını kontrol etmeliyim? Elbette, eklentiniz zamanın %99'unda aktif olacaktır. Ancak, bir nedenden dolayı devre dışı bırakıldığı zamanın% 1'ine ne dersiniz? Bu meydana gelirse, web siteniz muhtemelen bazı çirkin PHP hataları gösterecektir. Bunu önlemek için, fonksiyonlarını çağırmadan önce eklentinin aktif olup olmadığını kontrol edebiliriz. Eklenti işlevi ön uç aracılığıyla çağrılıyorsa, is_plugin_active() işlevini çağırmak için plugin.php kitaplığını eklememiz gerekir:

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Bu teknik genellikle oldukça güvenilirdir. Ancak, yazarın ana eklenti dizini adını değiştirdiği durumlar olabilir. Eklentide bir sınıfın varlığını kontrol etmek daha sağlam bir yöntem olacaktır:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Yazarların bir eklenti sınıfının adını değiştirme olasılığı daha düşüktür, bu nedenle genellikle bu yöntemi kullanmanızı öneririm.

7 No'lu Ortak Hata: Çok Fazla Kaynak Yükleme

Sayfalar için eklenti kaynaklarını yüklerken neden seçici olmalıyız? Kullanıcının gezindiği sayfada bu eklenti kullanılmıyorsa, bir eklenti için stilleri ve komut dosyalarını yüklemek için geçerli bir neden yoktur. Eklenti dosyalarını yalnızca gerektiğinde yükleyerek sayfa yükleme süremizi azaltabiliriz, bu da gelişmiş bir son kullanıcı deneyimiyle sonuçlanacaktır. Örneğin, eklentinin yalnızca alışveriş sayfalarımıza yüklenmesini istediğimiz bir WooCommerce sitesini ele alalım. Böyle bir durumda, şişkinliği azaltmak için herhangi bir dosyayı diğer tüm site sayfalarına yüklenmekten seçerek kaldırabiliriz. Aşağıdaki kodu temanın veya eklentinin functions.php dosyasına ekleyebiliriz:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Komut dosyaları, kayıtlı oldukları tanıtıcı aracılığıyla wp_dequeue_script($handle) işleviyle kaldırılabilir. Benzer şekilde, wp_dequeue_style($handle) stil sayfalarının yüklenmesini engeller. Ancak, bunu uygulamak sizin için çok zorsa, gönderi türü veya sayfa adı gibi belirli kriterlere göre eklentileri seçerek yükleme olanağı sağlayan Eklenti Düzenleyici'yi yükleyebilirsiniz. Yaptığınız değişiklikleri yansıtmak için önbelleği sürekli yenilemek zorunda kalmamak için, W3Cache gibi açmış olabileceğiniz tüm önbelleğe alma eklentilerini devre dışı bırakmak iyi bir fikirdir.

8 Numaralı Genel Hata: Yönetici Çubuğunu Korumak

WordPress Yönetici Çubuğunu herkes için görünür halde bırakamaz mıyım? Evet, kullanıcılarınızın yönetici sayfalarına erişmesine izin verebilirsiniz. Ancak bu sayfalar sıklıkla seçtiğiniz temayla görsel olarak bütünleşmez ve sorunsuz bir entegrasyon sağlamaz. Sitenizin profesyonel görünmesini istiyorsanız, Yönetici Çubuğunu devre dışı bırakmalı ve kendinize ait bir ön uç hesap yönetimi sayfası sağlamalısınız:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Yukarıdaki kod, temanızın functions.php dosyasına kopyalandığında yalnızca site yöneticileri için Yönetici Çubuğunu görüntüleyecektir. Kullanıcıların yönetici çubuğunu görmesini engellemek için current_user_can($capability) işlevine WordPress kullanıcı rollerinden veya yeteneklerinden herhangi birini ekleyebilirsiniz.

9 No'lu Genel Hata: GetText Filtresini Kullanmamak

Bir düğmenin etiketini değiştirmek için CSS veya JavaScript kullanabilirim, bunun nesi yanlış? Evet, yapabilirsin. Bununla birlikte, bunun yerine WordPress'teki gettext adlı en kullanışlı filtrelerden birini kullanabileceğiniz zaman, düğmeyi oluşturmak için gereksiz kod ve fazladan zaman ekliyorsunuz. WordPress'in yüklenen tüm çevirileri ayırt edebilmesini sağlayan benzersiz bir tanımlayıcı olan bir eklentinin textdomain ile bağlantılı olarak, sayfa oluşturulmadan önce metni değiştirmek için gettext filtresini kullanabiliriz. Kaynak kodunda load_plugin_textdomain($domain) işlevi için arama yaparsanız, söz konusu metni geçersiz kılmamız gereken alan adını size verecektir. Herhangi bir saygın eklenti, bir eklentinin textdomain alanının, eklentinin başlatılması sırasında ayarlanmasını sağlayacaktır. Değiştirmek istediğiniz bir temadaki bir metinse, load_theme_textdomain($domain) kod satırını arayın. Örnek olarak bir kez daha WooCommerce kullanarak, “İlgili Ürünler” başlığı için görünen metni değiştirebiliriz. Aşağıdaki kodu temanızın functions.php dosyasına ekleyin:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Bu filtre kancası, metin etki alanı yukarıda belirtilen textdomain aracılığıyla ayarlandığı sürece, uluslararasılaştırma işlevleri __() ve _e() tarafından çevrilen metne uygulanır.

 _e( 'Related Products', 'woocommerce' );

Başka hangi dizeleri özelleştirebileceğinizi görmek için eklentilerinizi bu uluslararasılaştırma işlevleri için arayın.

Yaygın Hata No. 10: Varsayılan Kalıcı Bağlantıları Korumak

Varsayılan olarak, WordPress, belirtilen içeriği döndürmek için gönderinin kimliğine sahip bir sorgu dizesi kullanır. Ancak, bu kullanıcı dostu değildir ve kullanıcılar URL'yi kopyalarken ilgili kısımlarını kaldırabilir. Daha da önemlisi, bu varsayılan kalıcı bağlantılar, arama motoru dostu bir yapı kullanmaz. "Güzel" kalıcı bağlantılar dediğimiz şeyi etkinleştirmek, arama motoru sıralamalarındaki performansı artırmak için URL'lerimizin yazı başlığından alakalı anahtar kelimeler içermesini sağlayacaktır. Özellikle siteniz önemli bir süredir çalışıyorsa ve arama motorları tarafından zaten dizine eklenmiş yüzlerce yayınınız varsa, kalıcı bağlantılarınızı geriye dönük olarak değiştirmek oldukça göz korkutucu bir görev olabilir. Bu nedenle, WordPress'i kurduktan sonra, kalıcı bağlantı yapınızı derhal bir gönderi kimliğinden biraz daha arama motoru dostu bir şeye değiştirdiğinizden emin olun. Oluşturduğum sitelerin çoğu için genellikle posta adını kullanırım, ancak mevcut kalıcı bağlantı yapı etiketlerini kullanarak kalıcı bağlantıyı istediğiniz biçime göre özelleştirebilirsiniz.

Çözüm

Bu makale hiçbir şekilde WordPress geliştiricileri tarafından yapılan kapsamlı bir hata listesi değildir. Yine de bu makaleden çıkarmanız gereken bir şey varsa, o da asla kısayol kullanmamanız gerektiğidir (ve bu sadece WordPress'te değil, herhangi bir geliştirme platformunda geçerlidir!). Kötü programlama uygulamalarıyla şimdi kazanılan zaman, daha sonra sizi rahatsız etmek için geri gelecek. Aşağıda bir yorum bırakarak geçmişte yaptığınız bazı hataları ve daha da önemlisi öğrendiğiniz dersleri bizimle paylaşmaktan çekinmeyin.