Gelişmiş WordPress Geliştiricilerinin Yaptığı En Kötü 12 Hata

WordPress, bir siteyi hızlı bir şekilde kurup çalıştırmanın çok popüler bir yoludur. Ancak, aceleyle, birçok geliştirici korkunç kararlar veriyor. WP_DEBUG true olarak ayarlamak gibi bazı hataların yapılması kolay olabilir. Tüm JavaScript'inizi tek bir dosyada toplamak gibi diğerleri, tembel mühendisler kadar yaygındır. Hangi hatayı yapmayı başarırsanız başarın, yeni ve deneyimli geliştiricilerin yaptığı en yaygın 12 WordPress hatasını öğrenmek için okumaya devam edin. Kendinizi bu hatalardan birini yaparken bulursanız, umutsuzluğa kapılmayın. Her hata bir öğrenme fırsatıdır.

1. WordPress Tema JavaScript Kodunu Bir Ana Dosyaya Yerleştirme

Bir keresinde, bir müşterinin web siteleri için sayfa hızı optimizasyonu yaparken, özel kod da dahil olmak üzere kullandıkları tüm kitaplıkların main.js , theme.js veya custom.js adlı tek bir dosyada bulunduğu premium bir tema kullandıklarını fark ettim. . Bu uygulama aşağıdaki nedenlerden dolayı kötüdür:

1. Dosya, zamanla, tema olarak gerçekten büyük olabilir, aktif olarak geliştirilir, özelliklerde büyür 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 indirilmesinin daha uzun sürmesine ve özellikle sayfanın baş bölümünde oluşturmayı engelleyen kod olması durumunda daha yavaş oluşturulmasına neden olur.
2. wp_dequeue_script() gibi işlevleri, sayfa hızını artırmak veya olabilecek diğer JavaScript kodlarıyla çakışmayı önlemek için bazı sayfalarda kodun bir kısmını boşaltmak için kullanamayacağınız için, dosyanın içindeki kodu yönetmeyi zorlaştırır. aktif eklentilerden biri tarafından yüklenir. Elbette, dosya birden fazla dosyaya bölünebilir ve WordPress'te sıraya alınabilir, ancak daha sonra web sitesi yöneticisi temanın main.js dosyasının bir güncellemesini yaparsa, tüm sürecin baştan başlaması gerekir.

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

Bir eklenti geliştirirken, aynı adı kullanan başka eklentiler olması durumunda kod çakışmasını önleyen bir adlandırma kuralı kullanmak daha iyidir. Bu nedenle birçok geliştirici, değişkenlerini ve işlev adlarını benzersiz ve eklentinin kendisiyle ilgili bir şeyle önekler. Kod çakışmasını ortadan kaldırmanın yanı sıra, etkinleştirilmiş çok sayıda eklentiniz olduğunda işleri bulmanızı kolaylaştırır.

Öte yandan, öğeleri kapsüllemek ve kitaplık ve uygulama yazarlarının sınıflar veya işlevler gibi yeniden kullanılabilir kod öğeleri oluştururken karşılaştıkları iki sorunu çözmek için PHP ad alanlarını kullanmayı tercih eden geliştiriciler vardır:

1. Oluşturdukları kod ile dahili PHP veya üçüncü taraf, sınıflar, işlevler veya sabitler arasındaki çarpışmaları adlandırın
2. İlk sorunu düzeltmek veya kaynak kodun okunabilirliğini geliştirmek için tasarlanmış Extra_Long_Names takma (veya kısaltma) yeteneği. Bu benim favorim çünkü sıklıkla çok fazla kod içeren temalar veya eklentiler geliştiriyorum. Bununla, uzun benzersiz adlara sahip olma konusunda fazla endişelenmenize gerek kalmadan kodu kolayca okuyabilir ve yönetebilirim.

Genellikle yanlış şekilde kullanılabildikleri için, bunları kullanmadan önce ad alanlarını iyi anlamanızı tavsiye ederim.

Alacağınız projeye bağlı olarak, işiniz çoğunlukla mevcut olandan ayrı değilse, mevcut kodlama stiline bağlı kalmanız gerekebilir. WordPress için PHP kodlama standartlarını zaten takip eden mevcut bir eklentiyi veya temayı genişletmeniz gerekiyorsa, kodun temiz ve okunması kolay hale gelmesi için tutarlı bir stile sahip olmak için bunlara bağlı kalmak en iyisidir. Performansı artırmak için kodlama stilini göz ardı ederek bazı kuralların evrensel olarak uygulandığını unutmayın. Örneğin, dizedeki herhangi bir şeyi değerlendirmiyorsanız, tek tırnak (çift tırnak yerine) kullanmak her zaman en iyisidir. Ayrıca, özellikle iç içe koda sahipse (örneğin, IF s içinde IF s, iç içe FOREACH s ve FOR s) kodun okunabilmesi için girintili olması gerekir.

3. Mevcut WordPress Temel İşlevselliğinden Gerçek Potansiyeline Yararlanmamak

WordPress, eklentilerimizde ve temalarımızda çağrılabilecek düzenli olarak güncellenen bir kitaplık paketiyle birlikte geldiğinden, mevcut temel işlevlerden mümkün olduğunca yararlanmak en iyisidir. Varlık dizininde zaten WordPress çekirdek dosyalarında bulunan dosyaları olan WordPress temaları ve eklentileri gördüm (örn., jQuery veya Color Picker). Paketin büyüyüp ağ üzerinden yüklenmesi daha uzun sürmesinin yanı sıra, tüm üçüncü taraf kitaplıklarının düzenli olarak güncellendiğinden emin olmanız gerekir, bu da dikkat edilmesi gereken başka bir şeydir.

Kitaplıklar zaten WordPress geliştirme çekirdek ekibi tarafından güncellendiğinden ve hafif ve bakımı daha kolay bir projeye sahip olabileceğiniz için, WordPress'in sunduğu şeylerden yararlanın. Düzenli olarak WordPress güncellemeleri yaparak, daha fazla özelliğe (ister bir eklenti, ister bir tema veya Kontrol Paneli sürekli olarak geliştirildiği için WordPress çekirdeğinin kendisi olsun) erişebilir ve eski kod sürümlerinde güvenlik açıklarının bulunması durumunda web sitesini daha güvenli hale getirebilirsiniz.

4. Eklenti veya Temanın Eylemler ve Filtreler Yoluyla Değiştirilmesini Kolaylaştırmamak

Bir WordPress eklentisini veya temasını doğrudan düzenlemek, elbette, bu paketin geliştirilmesine doğrudan dahil olmadıkça ve koduna katkıda bulunmadıkça kötü bir fikirdir. Eklenti veya tema için otomatik bir güncelleme yapılırsa, pakette yapılan doğrudan değişiklikler kaybolacak ve dosyaları baştan düzenlemeniz gerekecek.

Bu nedenle, bir Alt tema (ana temayı genişleten) oluşturmanın yanı sıra eylemleri ve filtreleri kullanmak, bir temayı değiştirmeye yönelik en etkili yaklaşımlardır, çünkü ana temayı veya eklentinin kendisini düzenlemeden mevcut işlevselliği değiştirebilirsiniz. Ayrıca, WordPress.org'da ücretsiz indirme için bir eklenti sunuyorsanız ve daha sonra ana eklentiye bağlı olacak bir premium uzantı oluşturmak istiyorsanız, ücretsiz eklentiyi şu şekilde geliştirmelisiniz. genişletmek ve premium uzantılar eklemek kolay.

5. WP_DEBUG ile geliştirme false olarak ayarlayın

Varsayılan olarak, WP_DEBUG sabiti, herhangi bir PHP hatasını, uyarısını ve bildirimini yazdırmamak için 'false' olarak ayarlanmıştır. Canlı bir ortamda, bu, özel sunucu yollarını ve komut dosyalarını genel görünümden gizli tuttuğu için önerilen bir seçimdir; bu, güvenlik nedenleriyle harikadır. Bununla birlikte, geliştirme aşamasında, kodumuzdaki herhangi bir hatayı bize bildireceğinden, 'true' olarak ayarlanması en iyisidir. Hatalar, işlevselliği doğrudan etkilemese bile, genellikle sizi daha iyi kod yazmaya ve daha iyi kodlama alışkanlıkları geliştirmeye zorlayacaktır. Bana oldu. Bu aynı zamanda geliştirdiğiniz eklentinin veya temanın herhangi bir WordPress kurulumunda PHP hatası oluşturmamasını da sağlayacaktır.

Bu, çoğu deneyimli geliştiricinin yaptığı bir şey olsa da, özellikle aceleyle olur. İş ne kadar acil olursa olsun, geliştiriciler her zaman en iyi PHP uygulamalarını göz önünde bulundurarak WordPress kodlama standartlarını korumaya çalışmalıdır.

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

Bu yaygın bir PHP hatasıdır ve bir önceki gibi, PHP kodlama standartlarına bağlı kalırsanız, bunu önlemek nispeten kolaydır.

Bazı geliştiricilerin, yalnızca PHP kodu her zaman tetiklendiğinde geçerli olan temalara ve eklentilere PHP parçacıkları uygulama alışkanlığı vardır. Örneğin, belirli eylemlerle HTTP Kullanıcı Aracısına yanıt veren bir PHP işlevi yapılmalı veya yapılmamalıdır (örneğin, yalnızca mobil kullanıcılar için olan komut dosyalarının sıraya alınması).

İstemciniz, temanızdaki veya eklentilerinizdeki koşul şartlarını tetiklemeden sayfayı önbelleğe alan bir eklenti kurarsa (örneğin, W3 Total Cache veya WP Rocket), PHP kodunuz işe yaramaz hale gelecektir. Amaç sayfaları duyarlı hale getirmekse, bu, medya sorguları ve JavaScript aracılığıyla ön uçta yapılmalıdır. İkincisi, yalnızca gerçekten gerekliyse. İdeal olarak, sitenizi duyarlı hale getirmek için JavaScript kullanmaktan kaçınmak istersiniz.

7. Git Gibi Bir Sürüm Kontrol Sistemi Üzerinden Profesyonel Bir Şekilde Yapılan Değişiklikleri İzlememek

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

Başlangıçta, özellikle genç geliştiriciler için göz korkutucu olabilse de, Git'i anlamak zaman ayırmaya değer olacak ve SourceTree (favorilerimden biri) gibi bir Git GUI yazılımı, Git depolarınızla etkileşim kurma şekliniz olacak, böylece bütünü oluşturacaksınız. öğrenme eğrisi daha eğlenceli. Nasıl çalıştığını anladıktan sonra, Git'i kullanmanın birkaç yolunu daha ayrıntılı olarak açıklayan Toptal Developers'ın Git En İyi Uygulamaları ve İpuçlarını kontrol etmeyi düşünün.

8. CSS ve JavaScript Dosyalarını Gerekmediğinde Sıraya Alma

Çok sayıda HTTP isteğine sahip olmak, web sitesinin yüklenmesini yavaşlatır, dolayısıyla Google PageSpeed'de daha düşük bir puana sahip olur ve bu da arama sıralamasını büyük olasılıkla etkiler. Eklentiler arasındaki çakışmalar nedeniyle JavaScript hatalarına da yol açabilir. Örneğin, ortak bir jQuery kitaplığı kullanan ve iki kez yüklenebilen ve sorunlara neden olabilecek iki eklenti olabilir. Ve gerçekten, bu en iyi örnek, çünkü jQuery çok yaygın olarak canlı web sitelerine birden çok kez yükleniyor. Bu muhtemelen kötü yazılmış eklentiler veya temalar nedeniyle olur.

9. Statik .css ve .js Dosyaları Yerine CSS veya JavaScript Kodu Çıktısı Almak için .php Dosyalarını Kullanma

Sadece özel CSS kodu oluşturmak ve yazdırmak için kullanılan style.php gibi dosyaları olan temalar ve hatta WordPress eklentileri gördüm. Renkler, yazı tipi boyutları ve öğelerin etrafındaki boşluklar gibi şeyler temanın ayarlarında ayarlandı ve ardından veritabanına kaydedildi. Ardından style.php okunur (örneğin, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) ve özel ayarlara dayalı olarak CSS kodunu oluşturur. kontrol panelinde güncellendi.

Bu, WordPress performansı açısından gerçekten kötü bir uygulamadır. İşte onunla birlikte gelen ana dezavantajlar:

1. CSS dosyası head etiketi içinde yüklendiğinden (ki bu normaldir ve çoğu bu şekilde yüklenir), tarayıcının sayfayı oluşturmadan önce dosyayı tamamen indirmesi gerektiğinden bununla birlikte gelen bir performans sorunu vardır. WordPress ortamı bazı eklentiler nedeniyle yavaşsa, bu yükleme süresini önemli ölçüde geciktirecektir. Veri tabanından değerleri almak için önbelleğe alma teknikleri kullanılsa veya WordPress ortamının yalnızca bir kısmı yüklenmiş olsa bile. Bunun yerine statik bir .css dosyası kullanmak en iyisidir.
2. PHP dosyasında, kodu (PHP değişkenleri ve koşul cümleleriyle karıştırılmış CSS kuralları), bir şeyi kontrol etmeleri gerektiğinde geliştiriciler tarafından okunması daha zor olacaktır. Elbette, dosya tarayıcıda çalıştırılabilir (yazdırıldığında girintili veya hoş görünmeyeceğinden eminim) ancak projenin yerel bir kopyasına sahipseniz ve temanın koduna göz atın ve ihtiyacınız bir CSS veya JavaScript sözdizimi bulmak için (script.php kullanılması durumunda), okunabilirliği zorlaştırır.

Çözüm: Herhangi bir özel CSS'yi eklenti dizini dışında kaydedin. Örnek: /wp-content/uploads/theme-name-custom-css/style-5.css . Bu şekilde, tema veya eklentinin güncellenmesi durumunda özel dosya kaybolmaz.

10. WordPress Eklentileri ve Temaları İçin Doğru Mimariyi (Kod Organizasyonu) Kullanmamak

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 istemci için tek amaçlı bir WordPress eklentisi oluşturmanız gerekiyorsa ve WordPress çekirdeği, temalar ve diğer eklentilerle sınırlı bir etkileşimi varsa, eklentinin önemli ölçüde genişleyeceğinden emin olmadığınız sürece karmaşık sınıflar oluşturmak etkili değildir. üzerinde.

Eklenti çok sayıda kodla zenginleştirilmiş olacaksa, Nesneye Yönelik Programlama (OOP) kodlama yaklaşımı (çok sayıda sınıfa sahip) kullanmak mantıklı olacaktır. Örneğin, çok sayıda kısa kodunuz varsa, class.shortcodes.php gibi ayrı bir sınıf dosyasında veya Gösterge Tablosu ve ön uç görünümünde yüklenmesi amaçlanan CSS ve JavaScript dosyaları varsa bunların hepsini tutabilirsiniz. daha sonra class.scripts.php gibi bir sınıf kullanılabilir ve enqueue_admin_scripts() yöntemi içinde admin alanına yüklenmesi amaçlanan dosyaları sıraya enqueue_public_scripts() gibi bir yöntem içinde ön uç dosyaları kuyruğa alabilir.

HTML'yi PHP koduyla karıştırmak yerine, MVC modelini eklentilere ve temalara uygulayarak ayrı tutmak daha iyidir. İyi bir örnek WooCommerce eklentisidir. Mantık tasarımdan ayrıldığı 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öntemlerinde HTML koduna sahip olmak genellikle kötü bir uygulamadır (elbette küçük HTML kodu parçaları için istisnalar vardır), özellikle 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 desen olsa da, bunlar genel olarak üç varyasyonda gruplandırılabilir:

• İşlevleri içeren tek eklenti dosyası
• Bir sınıf, somutlaştırılmış nesne ve isteğe bağlı olarak işlevler içeren tek eklenti dosyası
• Ana eklenti dosyası, ardından bir veya daha fazla sınıf dosyası

11. Kod Yazarken WordPress Güvenliğini Ciddiye Almamak

Birçok acemi geliştirici, müşterinin istediği sonuçlara daha fazla odaklandığından, güvenlik genellikle WordPress geliştirmede ciddiye alınmaz. İstemcinin web sitesi saldırıya uğrayana veya WordPress.org'da yayınlanan eklentinizin bir güvenlik açığı bulunup binlerce web sitesini etkileyene kadar her şey yolundadır. Bu şeyler bazen olur ve WordPress çekirdeği bile CMS'nin ilk günlerinden bu yana çok sayıda güvenlik açığıyla uğraşmıştır. Mümkün olduğunca güvenli hale getirmek ve bir şey olması durumunda derhal harekete geçmek ve sağlam, iyi test edilmiş bir yama yayınladığımızdan emin olmak bizim sorumluluğumuzdur.

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 sterilize etmek ve çıktı verilerini sterilize etmek. Verilere ve kullanıldığı bağlama bağlı olarak, WordPress'te kodu temizlemenin birkaç yöntemi vardır. Herhangi bir girdi verisine veya yazdırılacak herhangi bir veriye güvenilmemelidir. Veri girişini sterilize etmek için yaygın bir işlev sanitize_text_field() işlevidir. Geçersiz UTF-8 karakterlerini kontrol eder, tek < karakterlerini HTML varlıklarına dönüştürür, tüm etiketleri çıkarır, satır sonlarını, sekmeleri ve fazladan beyaz boşlukları ve sekizlileri çıkarır. Verilerin yazdırılmasına gelince, geçersiz URL'leri reddeden, geçersiz karakterleri ortadan kaldıran ve tehlikeli karakterleri kaldıran esc_url() işlevi bağlantıların çıktısını almak için iyi bir örnektir.

Dosyalarınıza doğrudan erişimi engelleyin: Çoğu ana bilgisayar buna izin verdiği için dosyalara doğrudan erişilebilir. Ancak, bu gerçekleşirse ve kod bununla başa çıkmak için düzgün yazılmazsa, potansiyel saldırganlar için değerli bilgiler içeren bazı hatalar yazdırılabilir (örneğin, eksik işlevler veya bildirilmeyen değişkenler). Eklentilerde ve temalarda sıklıkla gördüğünüz yaygın bir kod parçacığı:

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

ABSPATH sabiti tanımlanmadıysa (ki bu herhangi bir WordPress kurulumu için olmalıdır), komut dosyası çıkar ve hiçbir şey yazdırmaz.

Nonces Kullanın: WordPress belgelerinde belirtildiği gibi, nonce, URL'leri ve formları kötü amaçlı veya başka türlü belirli yanlış kullanım türlerinden korumaya yardımcı olmak için "bir kez kullanılan bir sayıdır".

Örneğin, bir gönderiyi çöpe atmak için gösterge tablosundaki aşağıdaki URL kullanılacaktır: http://example.com/wp-admin/post.php?post=123&action=trash —Bu URL'ye erişirken, WordPress kimlik doğrulama çerezi bilgilerini doğrulayacaktır. ve doğru izne sahipseniz (örneğin, tüm ayrıcalıklara sahip bir yöneticiyseniz), bu gönderi silinecektir.

Saldırganın yapabileceği şey, aşağıdaki örnekte olduğu gibi bir üçüncü taraf sayfasında bir bağlantı oluşturarak bilginiz olmadan tarayıcınızın bu URL'ye erişmesini sağlamaktır: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> WordPress'e bu istekte bulunurken, tarayıcı otomatik olarak kimlik doğrulama çerezinizi ekler ve WordPress isteği geçerli olarak kabul eder.

Bu, saldırganın nonce değerini (aslında WordPress'te oturum açmış olan yönetici için oluşturulan) kolayca elde edemeyeceği için bir nonce devreye girdiğinde gerçekleşir. Yeni istek URL'si şöyle görünür: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

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

Çoğu insan WordPress güvenliğini ciddiye almasa da, web sitelerinin asla saldırıya uğramayacağını düşünerek, barındırmaya güvenerek (bu yardımcı olabilir, ancak yalnızca belirli bir noktaya kadar) ve ticari eklentiler/temalar satın aldıkları gerçeğine (genellikle yol açar) çok güvenli oldukları varsayımına göre), herhangi bir bilgisayar korsanı onları tanımlayıp istismar etmeden önce, istismar edilebilir güvenlik açıklarını belirlemek için web sitelerimiz için her zaman sızma testleri yapmalıyız.

Çok sayıda hacklemenin, özellikle web sitenizi hackleme niyetiyle tek bir kişi tarafından yapılmadığını unutmayın. Genellikle, WordPress web sitelerini tutarlı bir şekilde otomatik olarak tarayan botlar vardır ve bilinen bir güvenlik açığı bulunduğu anda, bu güvenlik açığından yararlanılır ve sunucu spam göndermek, veritabanından özel bilgiler almak, web sitesinin belirli sayfalarına gizli bağlantılar yerleştirmek için kullanılır. her türlü tehlikeli web sitesine (örneğin, pornografi, yasadışı uyuşturucular) yol açacaktır. Bazen saldırılar o kadar iyi gizlenir ki, saldırıya uğramış kodu tespit etmek için web sitenizi düzgün bir şekilde taramanız ve belirli dosyaların güncellendiği tarihi görmeniz gerekir. Bu nedenle, WordPress'i yeniden yüklemek (evet, son sürüme sahipseniz aynı sürüm) bile iyidir, böylece saldırıya uğramış dosyaların üzerine orijinal WordPress çekirdek dosyaları yazılacaktır.

12. WordPress İşlevlerini ve Kod Parçacıklarını Anlamadan Kullanmak

Çoğu zaman, geliştiriciler StackOverflow gibi yerlerde takılıp bir çözüm bulduklarında, bu kodun arkasındaki mantığı anlama zahmetine girmeden veya bu kodun daha hızlı yüklenecek veya daha az yüklenecek şekilde değiştirilip değiştirilemeyeceği konusunda bir şeyi çalıştırmayı başardıkları için mutlu olurlar. Kod satırları.

Bu uygulamayı o kadar çok gördüm ki, kod parçacıkları PHP betiklerinde kopyalanırken, bu kodun yalnızca üçte biri gerçekten kullanıldı.

Bunun aşağıdakiler de dahil olmak üzere birkaç dezavantajı olabilir:

1. Kod, mevcut proje koduyla aynı stili kullanmaz. Evet, kutudan çıktığı gibi çalışan parçacıkları kopyalayıp yapıştırmak rahattır ve küçük bir kişisel proje için iyi olsalar da (bir gün büyük bir projeye dönüşebilir, kim bilir), bu uygulama genellikle geldiğinde iyi değildir. stil tutarlılığının korunması gereken ticari çalışmalara.
2. Kod işini yapsa da, başarılması gereken görev için önerilmeyen etkisiz işlevler içerebilir. Kod optimize edilmezse, bu "kopyala ve yapıştır" uygulaması, özellikle proje içindeki çeşitli konumlarda birden fazla snippet kullanılıyorsa, web sitesinin bakımının yavaş ve daha zor olmasına neden olabilir.
3. Kod yeniden kullanım için lisanslanmamış olabilir ve kodun bir müşterinin projesine dahil edilmesi onları birçok yasal soruna açabilir.

Sürekli İyileştirme

Herkes hata yapar ve her hata kendinizi geliştirmek için bir fırsattır. WordPress geliştiricileri olarak sektörümüz çok hızlı ilerliyor ve hiçbir zaman bir şeyleri yapmanın tek bir “doğru yolu” yoktur. Ancak, ne kadar çok pratik yapar ve öğrenirseniz, o kadar iyi olursunuz.

Belirttiğim hatalardan herhangi birine katılmıyor musunuz, yoksa bir tanesini gözden kaçırdığımı mı düşünüyorsunuz? Yorumlarda bana bildirin, tartışalım.