WordPress, bir siteyi hızlı bir şekilde kurup çalıştırmanın en popüler yollarından biridir. Bununla birlikte, bir çok WordPress geliştiricisi profesyonel olsalar dahi bir çok hata yaparlar. Bu yazımızda WordPress geliştiricilerinin yaptığı 10 hatayı ele alacağız. Bu hataları yaptıysanız endişelenmeyin. Çünkü iyi bir geliştirici olmak için, hatalar yapmak ve bu hatalardan dersler çıkarmak gerekir. Her hata bir öğrenme fırsatıdır.

1. WordPress Temasının JavaScript Kodunu Tek Bir Ana Dosyaya Yerleştirme

İncelediğim bir internet sitesinin sayfa hızı optimizasyonu üzerinde çalışırken, kullandıkları tüm kütüphanelerinmain.js, theme.js ve custom.js gibi isimlerle uygulandığını fark ettim. Bu sistem şu nedenlerden dolayı kötü bir uygulamadır:

  1. Bu dosyaların boyutu zamanla büyüyebilir, çünkü tema aktif olarak geliştirilir, özellikleri artar ve bazen 1 MB boyutunda dosyalar görürsünüz. Bazı sayfalarda dosyadaki kodun yalnızca %10’una ihtiyaç duyulsa bile, dosya site genelinde yüklenecektir. Bu, sayfaların yüklenmesinin daha uzun sürmesine ve yavaş olmasına neden olur. Özellikle de sayfanın header bölümünde engelleme kodu oluşturuyorsa.
  2. wp_dequeue_script() Sayfa hızını iyileştirmek veya başka bir JavaScript koduyla yüklenebilecek bir çakışmayı önlemek için bazı sayfalardaki kodun bir kısmını boşaltmak gibi işlevleri kullanamayacağınız için dosyanın içindeki kodu yönetmeyi daha zor hale getirir. Elbette, dosya birden çok dosyaya bölünebilir, ancak daha sonra web sitesi yöneticisi temanın main.js dosyasını güncellerse, tüm sürecin baştan başlaması gerekir.

2. Değişkenler, Fonksiyonlar, Sabitler veya Sınıflar İçin Çok Yaygın Adlar Kullanmak

Bir eklenti geliştirirken, aynı adı kullanan başka eklentiler olması durumunda kodlarınız çakışabilir. Böyle durumda bir adlandırma kuralı kullanmak en iyisidir. Bu nedenle birçok geliştirici, değişkenlerini ve fonksiyon adlarını isimlendirirken, benzersiz bir ön ek kullanır. Kod çakışmasını ortadan kaldırmanın yanı sıra, çok sayıda eklenti etkinleştirildiğinde aradığınız şeyi bulmanız da kolaylaşacaktır.

Öte yandan bazı geliştiriciler, karşılaştıkları iki sorunu çözmek için PHP ad alanlarını kullanmayı tercih ederler. Bahsetmek istediğim bu sorunlar:

  1. Oluşturulan kod ile, dahili PHP veya üçüncü taraf sınıflar, işlevler veya sabitler arasındaki ad çakışmaları
  2. Extra_Long_Names İlk sorunu çözmek veya kaynak kodun okunabilirliğini artırmak için tasarlanmış takma ad (veya kısaltma). Bu benim favorim yöntemlerimden biridir çünkü çoğu zaman çok fazla kod içeren temalar veya eklentiler geliştirmeye çalışıyorum. Bu yöntem ile uzun benzersiz adlara sahip olma konusunda fazla endişelenmeden kodu kolayca yönetebiliyorum.

Genellikle yanlış şekilde kullanılabileceklerinden, kullanmadan önce bahsettiğim bu “ad alanlarının” iyi anlaşılmasını tavsiye ederim.

Başlayacağınız projeye bağlı olarak, çalışmanızın mevcut kodlama stiline bağlı kalması gerekebilir. WordPress için PHP kodlama standartlarını halihazırda takip eden mevcut bir eklenti veya temayı genişletmeniz gerekiyorsa, kodun temiz ve sade olması için tutarlı bir stile sahip olmak ve bunlara bağlı kalmak en iyisidir. Performansı artırmak için bazı kuralların, evrensel olarak uygulandığına dikkat edin. Ayrıca, kodun okunabilmesi için girintili bir yapıda yazılması gerekir. Özellikle kod iç içe geçmişse dikkat etmek gerekir. (örneğin, if‘in içinde if veya iç içe geçmiş foreach vefor)

3. WordPress Temel İşlevsellik Potansiyelini Kullanamamak

WordPress, eklentilerimizde ve temalarımızda, çağrılabilen ve düzenli olarak güncellenen bir kütüphane paketiyle birlikte geldiğinden, mevcut temel işlevlerden mümkün olduğunca çok yararlanmak en iyisidir. Varlıklar dizininde, zaten WordPress çekirdek dosyalarında (örneğin, jQuery veya Color Picker) bulunan dosyalara sahip WordPress temaları ve eklentileri gördüm. Paketin büyüyeceği ve ağ üzerinden yüklenmesinin daha uzun süreceği gerçeğinin yanı sıra, tüm üçüncü taraf kütüphanelerinin düzenli olarak güncellendiğinden emin olmanız gerekir. Bu da ilgilenilmesi gereken başka bir husustur.

Kütüphaneler zaten WordPress geliştirme ekibi tarafından güncellendiğinden, hafif ve bakımı daha kolay bir projeye sahip olabileceğiniz için WordPress’in sunduğu olanaklardan yararlanın. Düzenli olarak WordPress güncellemeleri yaparak, daha fazla özelliğe (bir eklenti, bir tema veya Kontrol Paneli sürekli olarak iyileştirildiği için WordPress çekirdeğinin ta kendisi) erişebilir ve daha güvenli bir WordPress kullanabilirsiniz. Çünkü eski kod sürümlerinde güvenlik açıklarının bulunması durumunda yapılan bu güncellemeler ile, tüm açıklar kapatılmaya çalışılır. Kısacası güncel bir WordPress’in özelliklerinden yararlanmalısınız.

4. Eklentiyi veya Temayı Değiştirirken, Eylemler ve Filtrelerden Yararlanın

Bir WordPress eklentisini veya temasını doğrudan düzenlemek, tabii ki bu paketin geliştirilmesine doğrudan dahil olmadığınız ve koduna katkıda bulunmadığınız sürece kötü bir fikirdir. Eklentiye veya temaya otomatik güncelleme yapılırsa, paketteki herhangi bir doğrudan değişiklik kaybolur ve dosyaları baştan düzenlemeniz gerekir.

Bu nedenle, ana temayı veya eklentinin kendisini düzenlemeden, mevcut işlevselliğini değiştirebileceğinizden, eylemleri ve filtreleri kullanmak ve bir alt tema oluşturmak, bir temayı değiştirmek için en etkili yaklaşımdır. Dahası, WordPress.org’da ücretsiz indirilebilecek bir eklenti sunuyorsanız ve daha sonra ana eklentiye bağlı olacak bir premium uzantı oluşturmak istiyorsanız, ücretsiz eklentiyi öyle bir şekilde geliştirmelisiniz ki kolayca geliştirilebilir ve premium uzantılar eklenebilir olsun.

5. Sayfanın Önbelleğe Alınabileceğini Düşünmeden PHP Kodu Yazmak

Bu yaygın bir PHP hatasıdır ve önceki gibi, PHP kodlama standartlarına bağlı kalırsanız, bundan kaçınmak nispeten kolaydır. Bazı geliştiricilerin, yalnızca PHP kodu tetiklendiğinde geçerli olan PHP parçacıklarını, temalara ve eklentilere uygulama alışkanlığı vardır.

Müşteriniz, temanızdaki veya eklentilerinizdeki koşulları tetiklemeden sayfayı önbelleğe alan bir eklenti (örneğin, W3 Total Cache veya WP Rocket) yüklerse, PHP kodunuz işe yaramaz hale gelecektir. Sayfaların duyarlı hale getirilmesi amaçlanıyorsa; bu gerçekten gereklise, medya sorguları ve JavaScript aracılığıyla front-end tarafında yapılmalıdır. İdeal olarak, sitenizi duyarlı hale getirmek için JavaScript kullanmaktan kaçınmak istersiniz.

6. Git gibi bir Sürüm Kontrol Sistemiyle Profesyonel Şekilde Yapılan Değişiklikleri İzlememek

Alt tema veya özel bir eklenti gibi kodlanmış dosyalar ideal olarak sürüm kontrolü altında olmalıdır. Git, neyin değiştiğinin bir kaydını oluşturur ve geliştiricilerin aynı WordPress projesi üzerinde birlikte çalışmasına veya web sitesinde bir şeyler ters gittiğinde kolayca önceki bir sürüme dönmesine olanak tanır. Dahası, müşteriler Git’i, söz konusu proje için işe alınan tüm geliştiriciler tarafından yapılan tüm iş geçmişini takip etmek için kullanabilir.

Başlangıçta, özellikle genç geliştiriciler için göz korkutucu olsa da, Git’i anlamak zamana değer olacak ve bir Git GUI yazılımı, Git depolarınızla etkileşimde bulunma biçiminiz olacak ve bütünü oluşturacaktır. Böylelikle daha eğlenceli bir öğrenme eğrisine sahip olabilirsiniz.

7. Statik .css ve .js Dosyaları Yerine CSS veya JavaScript Çıktısı İçin .php Dosyası Kullanmak

style.php : Sadece özel CSS kodu oluşturmak ve yazdırmak için kullanılan bu tür dosyalara sahip temalar ve hatta WordPress eklentileri gördüm. Renkler, yazı tipi boyutları ve öğelerin etrafındaki boşluklar gibi unsurlar temanın ayarlarında belirlenip ve ardından veritabanına kaydediliyor. Daha sonra style.php okunuyor (örn. <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' />) ve gösterge tablosunda güncellenen özel ayarlara göre CSS kodunu oluşturuyor.

Bu, WordPress performansı açısından gerçekten kötü bir uygulamadır. Çünkü:

  1. CSS dosyası head etiketinin içinde yüklendiği için (bu normal ve çoğu bu şekilde yüklenir), tarayıcının sayfayı oluşturmadan önce dosyayı tamamen indirmesi gerektiği için, burada bir performans sorunu vardır. WordPress ortamı bazı eklentiler nedeniyle yavaş ise bu, yükleme süresini önemli ölçüde geciktirecektir. Veritabanından değerleri almak için önbelleğe alma teknikleri kullanılsa veya WordPress ortamının yalnızca bir kısmı yüklense bile bu sorun çözüme tam anlamıyla kavuşmayacaktır. Bunun yerine statik bir .css dosyası kullanmak en iyisidir.
  2. PHP dosyasında, bir şeyi kontrol etmeleri gerektiğinde geliştiriciler tarafından kodun okunması daha zor olacaktır. Elbette, dosya tarayıcıda çalıştırılabilir (ve çok büyük ihtimalle, güzel görünen bir sayfa olmayacaktır), ancak projenin yerel bir kopyasına sahipseniz ve temanın koduna göz atıyorsanız bir CSS veya JavaScript sözdizimi bulmak için script.php kullanmak, okunabilirliği zorlaştırır.

Bunun çözümü basit: Herhangi bir özel CSS’yi eklenti dizininin dışına kaydedin.

Örneğin; /wp-content/uploads/theme-name-custom-css/style-5.css gibi bir kullanımda, tema veya eklentinin güncellenmesi durumunda, özel dosya kaybolmayacaktır.

8. WordPress Eklentileri ve Temaları için Doğru Mimariyi Kullanın

Eklentinin boyutuna ve doğasına bağlı olarak (örneğin, bağımsız bir eklenti veya yalnızca WooCommerce gibi bir ana eklenti etkinleştirildiğinde çalışan bir eklenti uzantısı), doğru mimari ve kod organizasyonu kurulmalıdır. Bir müşteri için amacı belli olan bir WordPress eklentisi oluşturmanız gerekiyorsa ve bunun WordPress çekirdeği, temalar ve diğer eklentilerle sınırlı bir etkileşimi varsa, eklentinin daha sonra önemli ölçüde genişleyeceğinden emin değilseniz karmaşık sınıflar tasarlamanıza gerek yoktur.

Eklentide çok sayıda kod olacaksa, Nesneye Yönelik Programlama (OOP) yaklaşımı, kullanmak mantıklı olacaktır. Örneğin, çok sayıda kısa kodunuz varsa, hepsini ayrı bir sınıf dosyasında tutabilirsiniz. class.shortcodes.phpveya Kontrol Paneli ve front-end görünümünde yüklenmesi gereken CSS ve JavaScript dosyaları varsa, bir sınıf gibi class.scripts.php front-end dosyalarını, enqueue_public_scripts(), enqueue_admin_scripts() yöntemlerinde olduğu gibi bir biçim içinde kullanılabilir ve sıraya dizilebilir .

HTML’i PHP koduyla karıştırmak yerine, MVC modelini eklentilere ve temalara uygulayarak onu ayrı tutmak daha iyidir. Buna iyi bir örnek WooCommerce eklentisidir. Mantık tasarımdan ayrı olduğu için tema veya çeşitli filtreler aracılığıyla kolayca üzerine yazılabilen çeşitli düzenler için şablonlara sahiptir. HTML düzenini içeren şablon çoğunlukla önceden işlenmiş bilgileri yazdırmak için kullanılır. PHP yöntemleri içinde HTML koduna sahip olmak genellikle kötü bir uygulamadır (elbette küçük HTML kodu bitleri için istisnalar vardır). Özellikle de boyutu büyüdükçe birden fazla geliştirici tarafından sağlanan bir eklenti için.

WordPress Eklenti El Kitabına göre, bir dizi olası mimari model varken, bunlar genel olarak üç varyasyona ayrılabilir:

9. Kod Yazarken WordPress Güvenliğini Ciddiye Alın

Birçok acemi geliştirici, müşterinin istediği sonuçlara daha fazla odaklandığından, WordPress geliştirmede güvenliği genellikle ciddiye almaz. Müşterinin web sitesi saldırıya uğrayana veya WordPress.org’da yayınlanan eklentiniz bir güvenlik açığına sahip olana ve binlerce web sitesi etkilenene kadar her şey yolundadır. WordPress bile, ilk günlerinden beri çok sayıda güvenlik açığı ile uğraşmıştır. Bunu olabildiğince güvenli hale getirmek ve bir şey olması durumunda derhal harekete geçmek, iyi test edilmiş bir güncellenme yayınladığımızdan emin olmak geliştiricinin sorumluluğundadır.

En önemli güvenlik ipuçlarından bazıları şunlardır:

XSS Güvenlik Açıkları:

Bundan kaçınmak için iki şey yapılmalıdır:

  • veri girişini temizleme
  • çıktı verilerini temizleme

Verilere ve kullanıldığı bağlama bağlı olarak, WordPress’te kodu temizlemek için birkaç yöntem vardır. Herhangi bir girdi verisine veya yazdırılacak veriye güvenilmemelidir. Veri girişini temizlemenin yaygın bir işlevi şudur: sanitize_text_field(). Geçersiz UTF-8 karakterlerini kontrol eder. Tüm etiketleri çıkarır, satır sonlarını, sekmeleri ve fazladan beyaz boşlukları çıkarır. Veri yazdırmaya gelince ise, bağlantıların çıktısını almak için; esc_url() iyi bir örnektir. Geçersiz URL’leri reddeden, geçersiz ve tehlikeli karakterleri ortadan kaldıran bir işlevdir.

Dosyalarınıza doğrudan erişimi önleyin:

Çoğu ana bilgisayar buna izin verdiği için dosyalara doğrudan erişilebilir. Ancak, bu olursa ve kod bununla başa çıkmak için düzgün bir şekilde yazılmazsa, potansiyel saldırganlar için değerli bilgiler içeren bazı hatalar (örneğin, eksik işlevler) bulunabilir. Eklentilerde ve temalarda sıklıkla gördüğünüz yaygın bir kod parçacığı şudur:

// Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Sabit ABSPATHtanımlı değilse (herhangi bir WordPress yüklemesi için geçerli olmalıdır), komut dosyası çıkacak ve hiçbir şey yazdırmayacaktır.

Nonce Kullanın:

WordPress belgelerinde belirtildiği gibi, Nonce, URL’leri ve formları kötüye kullanım türlerinden, korumaya yardımcı olmak için “bir kez kullanılan sayıdır”.

Örnek vermek gerekirse; bu URL adresi gönderiyi çöp kutusuna atmak için kullanılacaktır.

http://example.com/wp-admin/post.php?post=123&action=trash

Bu URL’ye eriştiğinizde, WordPress kimlik doğrulama tanımlama bilgisi bilgilerini doğrular ve doğru izne sahipseniz (örneğin, tüm ayrıcalıklara sahip bir yöneticiyseniz) gönderiyi siler.

Bir saldırganın yapabileceği şey, aşağıdaki örnekte olduğu gibi üçüncü taraf bir sayfada bir bağlantı oluşturarak tarayıcınızın bu URL’ye bilginiz olmadan erişmesini sağlamaktır:

img src="http://example.com/wp-admin/post.php?post=123&action=trash"

Saldırgan yukarıdaki isteği WordPress’e gönderirken, tarayıcı otomatik olarak kimlik doğrulama çerezinizi ekler ve WordPress bunu dikkate alır.

Saldırgan Nonce değerini (aslında WordPress’te oturum açmış olan yönetici için oluşturulmuş) bu kadar kolay alamayacağından bir Nonce devreye giriyor. Bu durumda yeni istek URL’si şöyle görünecektir:

http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Geçerli bir Nonce olmadan, tarayıcıya WordPress tarafından iyi bilinen hata mesajıyla birlikte bir 403 Yasak yanıtı gönderilir: “Bunu yapmak istediğinizden emin misiniz?

Çoğu kişi WordPress güvenliğini ciddiye almasa da, web sitelerinin asla saldırıya uğramayacağını düşünüyor. Herhangi bir bilgisayar korsanı bunları tespit edip kullanmadan önce istismar edilebilir güvenlik açıklarını belirlemek için her zaman web sitelerimiz için sızma testleri yapmalıyız.

Genellikle, WordPress web sitelerini tutarlı bir şekilde otomatik olarak tarayan botlar vardır ve bilinen bir güvenlik açığı bulunduğunda, bu güvenlik açığından yararlanılır ve sunucu spam yapmak, veritabanından özel bilgiler almak, web sitesinin belirli sayfalarına gizli bağlantılar yerleştirmek için kullanılır. Her tür tehlikeli web sitesine yönlendirebilir (örneğin pornografi, yasadışı uyuşturucular). Bazen, hackler o kadar iyi gizlenir ki, web sitenizin düzgün bir şekilde taranmasına ihtiyaç duyarsınız ve saldırıya uğramış kodu tespit etmek için belirli dosyaların güncellendiği tarihi görmeniz gerekir. Bu yüzden WordPress’i yeniden yüklemek bile gerekebilir. Böylece saldırıya uğramış dosyaların üzerine orijinal WordPress çekirdek dosyaları yazılır.

10. WordPress İşlevlerini ve Kod Parçacıklarını Anlamadan Kullanmayın

Çoğunlukla, geliştiriciler StackOverflow gibi yerlerde takılıp kaldıklarında ve bir çözüm bulduklarında, bu kodun arkasındaki mantığı anlamaya zahmet etmezler.

PHP betikleri içinde kod parçacıkları kopyalandığında ve bu kopyalama işleminden sonra karşılaşılan herhangi bir hatada ne yapacağınızı bilemezsiniz. Kopyaladığınız bu kod parçacıklarının neden ve nasıl olduğunu öğrenmeniz gerekir. Bu hata aşağıdaki gibi sonuçlar doğuracaktır:

  1. Kod, mevcut proje koduyla aynı stili kullanmaz. Evet, kutudan çıktığı gibi çalışan parçacıkları kopyalayıp yapıştırmak kolaydır ve küçük bir kişisel proje için uygun olsalar da (bir gün büyük bir projeye dönüşebilir, kim bilir), çoğu zaman iyi değildir.
  2. Kod işini yapsa da, gerçekleştirilmesi gereken görev için önerilmeyen etkisiz işlevler içerebilir. Kod optimize edilmediyse, bu “kopyala ve yapıştır” uygulaması, özellikle projenin çeşitli yerlerinde, web sitesinin daha yavaş ve daha zor yüklenmesine neden olabilir.
  3. Kod yeniden kullanım için lisanslanmamış olabilir ve kodu bir müşterinin projesine dahil etmek, müşterinize birçok yasal soruna açabilir.

Herkes hata yapar ve her hata kendini geliştirmek için bir fırsattır.

Paylaşmak İster Misiniz?