Bu eklentileri ve temaları yazma dışındaki Wordpress değiştirmek için herhangi bir koşulda gerekli midir?

5 Cevap php

Geçenlerde önceki geliştirici wp-admin dizini değiştirilmiş bir proje üzerinde çalışmak zorunda. Bu Wordpress sürekli güncellenir beri, benim için kötü bir fikir gibi görünüyor. Ben Wordpress değiştirme ile uzmanlık bu düzeyde sadece değil miyim?

5 Cevap

Açık kaynak olmak, WordPress herhangi bir noktada değiştirilmiş ve genişletilmiş olması gibi yazılım için ortak bir şey olduğunu düşünüyorum.

Değiştirmek için değiştirmek veya değil dengeler arasında bir seçimdir. Yeni özellikler, belki de bunların işlevleri arzu edilenden daha az entegre olmasına neden olabilir modülleri olarak kapsüllenebilmektedir. Ancak, tam entegre değişiklikler yeni sürümler çıktıkça kolayca yazılımını güncelleyerek engelleyebilir.

Birisi doğrudan yazılımını değiştirmek için yazılımı ile çok aşina olmasını gerektirmez, ancak bu mutlaka kötü bir fikir değildir.

Bir yan not olarak, ben bunu (Tamam, bu beni dava, bir yumruk oldu) iyi bir mimarisi var ya aslında güvenli olmasını istiyorsanız, özellikle WordPress değiştirerek neredeyse bir zorunluluk olduğunu düşünüyorum.

Peki, o şimdi bir iç defacto çatal korumaktan sorumlu olduğu anlamına gelir sadece bu kötü bir fikir ... her zaman WordPress bir güncelleştirme bültenleri, yeni "gerçek içine değişiklikleri birleştirmek için üç-way fark yapmak zorunda "WordPress. (Üç yollu fark sizin eski sürümü çatal ve yeni sürüme ayarlamanız yama uygulamak, sonra bir yama seti oluşturmak için standart eski sürümü arasında bir diff yapmak demektir.) Ayrıca kendinizi tutmak için bir VCS kullanarak kendiniz olmalıdır aklı başında.

O zaman o kadar değil yukarı bu değilse, KISS prensibi takip ve uygulama kodunu oynayana değil yanlış bir şey yok.

Eğer aynı şeyi yapar ve sadece verimli öyle bir eklenti yazabilirsiniz eğer, o zaman bunu kendi çatal korumak zorunda değilsiniz yapmalıdır.

Ancak, WordPress yalnızca uygulama kodunu hack tarafından (sadece gerekmez kodu devre dışı bırakarak, çok iş olmadan bazen) iyileştirebildiği (verimlilik, güvenlik) de korkunç şeylerin bir yeri vardır. WordPress başlangıçta yazılım veya veritabanı tasarımı neredeyse sıfır bilgiye sahip kişiler tarafından yazılmış kirli eski spagetti kodu olduğunu ve on every request o kendi ne görmek için veritabanı sorgulama gibi muazzam aptalca bir çok şey yapar {[(1) Bu değişiklikleri asla zaman]}, - bu bir daha bu yapmaz böylece 2 kod satırları değiştirmek için 5 dakika alarak yanlış bir şey yok.

Ben o-top-20 Technorati-sıralanmış blogda teknoloji kurşun olarak çalıştı ve tek bir sunucuda WordPress ölçekli bir sürü iş yaptım ve sonra (genel erişim vs admin için ayrı sunucular ile) bir küme üzerine. Biz yukarı vekiller (yani Vernik veya kalamar) HTTP hızlandırıcılar gibi davranan ve PEAR :: Cache_Lite kullanarak önbelleğe dosya sistemi failover ile memcached takılı bir iç nesne / sayfa fragmanı önbellek sistemi ters etmişti. Biz gereksiz SQL ve pek çok işleme devre dışı bırakmak için, aklı başında, cache-HTTP başlıklarını göndermek gibi şeyler yapmak için WordPress değiştirmek zorunda kaldı.

Ben (sonunda biz ancak, bunun yerine bir çoğaltılmış küme için tercih) sorguları bir sürü dizin belirterek geliyordu MySQL'in bellek sadece NDB küme depolama motorunu kullanarak çalıştırmak için WP değiştirilmiş. Bu izin çok azaltılmış MySQL ayrıcalıkları ile koştu böylece kamu erişimi vs admin için ayrı sunucular ile çalıştırmak için değiştirerek, biz kamu tarafı aşağı sürüm kilitli sadece (üçüncü bir MySQL kullanıcı yetkileri yorumlama var) okur.

Eğer ciddi bir açıklama spam sorunu (yani 10K/hour) varsa, o zaman have eklentileri ötesinde bir şeyler yapmak için. Spam WordPress sadece kendi çekirdek başlatılırken, çünkü hiçbir eşzamanlılık bir bağımsız P4 yarım saniye gibi bir şey DOS sizsiniz, ve WP bir kod kıl yumağı olduğu için ilk çekirdek başlatılırken olmadan bir şey yapmak için hiçbir yolu yoktur.

"WP-Cron" braindead ve bu işlevleri gerçekleştirmek için gerçek bir crontab erişiminiz varsa devre dışı bırakılmalıdır. Yapmak zor değil.

Kısacası, ben bir değişiklik yapmak isteyebilirsiniz nedenlerini liste sonsuza kadar gidebiliriz.

Bu boyunca tabii ki en az bu değişiklikleri tutmak ve mümkün olduğunca açık olarak bunları belgelemek için idame nedenlerle bir gol oldu ve bu anlamda yaptığımız zaman eklentileri gibi birçok uygulamıştır.

Bir form doldurulmuş insanlar aynı anda WordPress ve phpBB hem kaydolmak için bu yüzden bir blog / forum kombinasyonu, birlikte kayıt işlemini kesmek. Ben eklentileri ile bunu yapmak için daha iyi bir yolu vardır eminim, ama bir beklenmedik fayda var mıydı - gerçekten istek dışı postalardan karıştırır. Her gün kayıt onları çeşitli olmasına rağmen, biz forumun hayatında yaklaşık iki spam mesaj yaşadım.

Değil tabii ki, tavsiye ederim bir şey - bu yazılımını yükseltme bizi durdurur.

Ben eğer mümkünse şiddetle özellikle WordPress gibi güncellemeleri yapan bir projede, modifiye çekirdek kodlara karşı savunmak eğilimindedirler. WordPress eklentileri ve benzeri ile bunu gerekenleri yapmak için yapılamaz, muhtemelen Drupal gibi daha genişletilebilir / jenerik sistemi ile daha iyiyiz. Başka bir şey bir blog odaklı CMS hack buna değer olmayabilir.

WordPress eski sürümleri (1.0 ve hatta erken 2.0s), ben yarasa WordPress kendisini değiştirerek bir göz olmaz.

Ancak, WordPress 'mimari olgunlaştı. Kenar Çubuğu artık elle kodlanmış olması gerekir. Bunun yerine, liman tema aletler kullanmak ve sadece (ne bir nimettir!) Widget oluşturabilirsiniz. Bir şey nasıl görüntüleneceğini sevmiyorum - sadece temayı değiştirmek! WordPress şey nasıl işleyeceğini sevmiyor musun? Bir plug-in oluşturun. Ben zor WordPress 'çağdaş modüler bileşenler (widget'lar, eklentileri, temalar) yerine yoluyla ele alınamaz WordPress kodunu kendisi değiştirmek için bir sebep düşünemiyorum basıldığında ediyorum.

Ben hep WordPress gibi açık kaynak apps "başlık altında" almak için kişinin tip değilim. Ancak, günümüzde, çekirdek WordPress kodunu değiştirmek için iyi bir sebep gerçekten var.