En çok ihtiyaç duyduğunuzda güvenilir WordPress eğitimleri.
WordPress Başlangıç Rehberi
WPB Kupası
25 Milyon+
Eklentilerimizi kullanan web siteleri
16+
Yıllık WordPress deneyimi
3000+
Uzmanlardan WordPress eğitimleri

WordPress Özel Yazı Tipleri Tartışması – Functions.php mi Yoksa Eklentiler mi?

Bildiğiniz gibi, geçtiğimiz hafta Syed Balkhi WordCamp Raleigh 2012'ye katıldı. Etkinlik sırasında attığı tweetlerden biri oldukça hararetli bir tartışma başlattı. Bu makalede, kurucumuz Syed Balkhi, WordPress Özel Gönderi Türlerinin (Custom Post Types) functions.php dosyasına mı yoksa eklentilere mi ait olması gerektiği konusunda tartışacaktır. Tartışmayı başlatan tweet aşağıdadır:

Tweet'ten sonra, WordPress topluluğundaki birçok saygın kişi de görüşlerini belirtti. tam konuşmayı burada görebilirsiniz. Curtis McHale ise konuyu bir adım öteye taşıyarak yeni blog yazısında daha ayrıntılı açıkladı.

Twitter'daki sohbet harika noktalar ortaya çıkardı.

Argümanların Özeti

Eklenti argümanı: Kullanıcı temayı değiştirse bile her zaman veriye sahip olacaktır. Görünüşü o kadar güzel olmayabilir, ancak orada kalacaktır.

Functions.php Argümanı: Tasarım olmadan veri anlamsız olacaktır. Kullanıcıları daha da fazla kafalarını karıştıracaktır.

Hangi tarafla daha çok aynı fikirdeyiz? Açıkça her iki tarafın da sorunları var, ama hangisi daha az kötü?

Özel Gönderi Türlerinin HER ZAMAN bir siteye özel eklentide veya tamamen ayrı bir eklentide yaşaması gerektiğine inanmamızın nedeni budur.

Veri Çok Yaşasın

Özel Gönderi Türleri veridir. Çoğu durumda, verileriniz mevcut tasarımdan daha uzun ömürlü olacaktır. Temalarımızı birkaç kez değiştirdiğimiz için bu ifadeyi açıkça anlıyoruz. Gönderiler, Sayfalar, Bağlantılar, Ekler ve Revizyonlar, WordPress ile birlikte gelen yerleşik gönderi türleridir. Bunun üzerine, Kitaplar, Referanslar, Fırsatlar vb. gibi gönderi türlerimiz var. Şimdi bir tema değiştirip bunların hepsinin kaybolduğunu hayal edebilir misiniz? Elbette bunu istemeyiz.

Ekibimizde geliştiriciler varken, bunun pek bir önemi olmamalı. Temalarımızın tamamı ekibimiz tarafından özel olarak tasarlandığına göre, bunun gerçekten ne farkı var? Sır iki kelimede yatıyor: zaman ve merkezileştirme. Gerekli tüm verilere sahip olduğumuz sürece, gelecekte yapmamız gereken tek şey stilini değiştirmek olacaktır. Her seferinde fonksiyonları bir dosyadan diğerine kopyalayıp yapıştırmakla uğraşmak zorunda kalmayacağız. İşlevselliği tekrarlamak ister misiniz? Eklentiyi alın ve yeni sitenize bırakın. Stilini değiştirin ve işiniz bitti.

Kurallar ve Standartlar

Tweet'imizde kullandığımız gibi her zaman kelimesini kullandığınızda, hem kural hem de standart anlamına gelebilir. Hem kurallar hem de standartlar çoğunluk için yapılır. Kuralların esnetildiği ve standartların bozulduğu özel durum senaryoları her zaman olacaktır, ancak bu, standartları tamamen ortadan kaldırmamız gerektiği anlamına gelmez.

Çoğunlukla aynı ek meta alanlarını gerektiren çok sayıda genel gönderi türü vardır. Aklıma gelen bazı örnekler şunlardır: Alıntılar, Kitaplar, Tarifler, Referanslar, Portföy vb.

Ücretsiz ve ticari pazarda bulunan çok sayıda fotoğrafçılık ve portföy teması göz önüne alındığında, kullanıcının her tema değiştirdiğinde özel gönderi türü bilgilerinin tümünü yeniden girmesini sağlamak neredeyse anlamsızdır. Bir örnek senaryoya bakalım:

Fotoğrafçı – Kullanıcı, bir blog işlevselliğine sahip bir WordPress kurdu (varsayılan "post" CPT). İşlerinden oluşan bir portföy eklemek istiyor (Portfolio CPT gerektirir). Müşteri referanslarını göstermek istiyor (Testimonial CPT gerektirir). Tüm bu bilgiler kesinlikle bir tema tasarımının ötesinde yaşayacak. Bir yıl sonra, kullanıcı sitesinin görünümünü değiştirmek ve yenilemek istiyor. Benzer işlevlere sahip yeni bir tema buluyor. Temayı değiştirdiği anda, BOOM. Girdiği önceki tüm veriler kayboldu. Portfolio adında bir menü ve Testimonials adında bir menü var ancak verilerin hiçbiri orada değil. Kullanıcı "AMAN TANRIM, tüm içeriğimi kaybettim" diye düşünüyor. Forumda yeni destek soruları oluşturuyor. WPBeginner gibi sitelere e-postalar gönderiyor. İyi bir yanıt alamazlarsa, tüm verileri yeniden girmek zorunda kalacaklar. Bu berbat bir kullanıcı deneyimi.

Peki bu sorunu nasıl çözeriz?

Olası Çözüm?

Yeni bir standart temel oluşturuyoruz. Justin Tadlock daha önce bir temel portföy eklentisi oluşturarak bu sorun üzerinde çalışmaya başlamıştı. Herkes için mükemmel çözüm olacak mı? HAYIR, ama çoğunluk için olacak.

Justin'in gönderisinde sorduğu gibi, portföy eklentisine (gönderi meta'sına atıfta bulunarak) hangi standart alanlar dahil edilmelidir? Bu tür bir konuşma, temalarında benzer işlevsellik oluşturan geliştiriciler arasında gerçekleşmelidir. Bir eklenti aracılığıyla yapılabilecekken, neden aynı şeyi bir temadan diğerine kopyalayıp yapıştıralım? Bir standart haline geldiğinde, diğer tema yazarları da buna uyum sağlamaya başlayacaktır.

Örneğin, Genesis ve diğerleri gibi WordPress tema çerçevelerinde Gravity Forms için stil desteğinde bir artış görüyoruz. Neden? Çünkü kullanıcılarının bunu kullandığını anlıyorlar.

İşlevsellik yüklü gelen ve eklenti olması gerektiğini düşündüğümüz bazı sağlam WordPress temaları var. İş İlanı temaları, Sorun Takip temaları, İlan temaları, Emlak Temaları vb. Hepsi bir temel eklenti tarafından desteklenmelidir. Bu zaten WooCommerce ile oluyor. WooThemes, eklenti için yerleşik stil desteğiyle çok sayıda tema yayınladı. Diğer tema şirketleri de WooCommerce tabanlı e-ticaret temaları yayınlayacaklarını vaat ettiler. Bir temadan diğerine geçebilir ve tüm ürünlerinizi olduğu gibi tutabilirsiniz. Bu neredeyse tema değişmiş gibi ama her şey tam yerine oturdu. Bu, çaba göstermemiz gereken tema değiştirme deneyimidir.

Neden Portföy, Referanslar ve diğer genel özel gönderi türleriyle de aynı şeyi yapmıyorsunuz? Bunun nedeni, e-ticaretin fethedilmesi gereken daha büyük bir canavar olmasıyla karşılaştırıldığında çok mu basit olması? Açıkçası, e-ticaret diğerlerine kıyasla çok fazla alana sahip, bu yüzden bu genel gönderi türleri için çok daha kolay olmalı. Sadece işleri daha iyi hale getirmek için bilinçli bir çaba gösterme meselesi.

ReciPress eklentisine bir göz atın. Tarif alanlarıyla özel bir meta kutusu oluşturur ve gönderilere ekler. Ancak özel içerik türlerine eklemek mümkündür. Bu eklentiyi kullanan herkes böyle bir zahmete girmeden tema değiştirebilir.

AgentPress gibi temaların merkezi bir temel eklenti tarafından desteklenmesi harika olurdu. Tema değiştirme geçişinin daha kolay hale geldiğini görmek harika olurdu. Örneğin, bir kullanıcı bir fotoğrafçılık temasından diğerine geçtiğinde, kaos olmamalıdır. Küçük hatalar olabilir, ancak en azından büyük resimde işler yolunda gidecektir.

Tek seferlik müşteri kullanımı için oluşturulmuş, süper özelleştirilmiş gönderi türlerinin örneklerini verebilirsiniz, ancak bu kural değil istisnadır.

Bu konu hakkında ne düşünüyorsunuz? Özel gönderi türü kodları nerede bulunmalı? Functions.php dosyasında mı yoksa eklentilerde mi?

Açıklama: İçeriğimiz okuyucu desteklidir. Bu, bazı bağlantılarımıza tıklamanız durumunda komisyon kazanabileceğimiz anlamına gelir. WPBeginner'ın nasıl finanse edildiğini, neden önemli olduğunu ve bize nasıl destek olabileceğinizi görün. İşte editöryal sürecimiz.

Nihai WordPress Araç Seti

Araç Kitimize ÜCRETSİZ erişim kazanın - her profesyonelin sahip olması gereken WordPress ile ilgili ürün ve kaynaklardan oluşan bir koleksiyon!

Okuyucu Etkileşimleri

33 CommentsLeave a Reply

  1. Temaları değiştirdiğimde özel gönderi türlerimi defalarca kaybetme deneyimi yaşadığım için, functions.php'de aynı işlevselliği tekrar tekrar ayarlamak zorunda kalmak beni hayal kırıklığına uğratıyor.

    Eklenti yolunu tamamen tercih ediyorum ve iş projelerim için de bundan sonra kullanacağım yöntem bu olacak.

  2. Emlak temasıyla tam olarak bu sorunu yaşıyorum. “İlanlar” tamamen işlevsel olarak modası geçmiş bir temada özel türlerdi. Temayı yükseltmeye gittiğimde tüm özel gönderi içeriklerimi kaybettim, şimdi hepsini aktarmanın bir yolunu bulmam gerekiyor. Seçeneklerim var ama eklenti olsaydı bu gerekli olmazdı.

    • Yaşadığınız rahatsızlıktan dolayı son derece üzgünüz. Bu gönderiyi yazmamızın nedeni de bu, çünkü bunun son kullanıcının hayatını gerçekten zorlaştırdığını biliyoruz.

      Yönetici

  3. “Her seferinde fonksiyonları bir dosyadan diğerine kopyalayıp yapıştırmakla uğraşmak zorunda kalmayacağız.”
    CPT için kodları functions.php'ye yazmayı hayal bile edemiyorum, çünkü include'larla izole etmek bu kadar kolayken.

    Bu tartışma çoğunlukla veri ve tasarım etrafında dönüyor ve WP'ye oldukça yeni olduğum için performans konusunu merak ediyorum. Eklentiler herhangi bir ek yük getiriyor mu?

  4. CPT'leri her zaman functions.php'ye ayrı bir dosya aracılığıyla dahil ettim, ancak eklenti rotasına geçeceğimi düşünüyorum. Teşekkürler!

  5. Ben bir başlangıç seviyesindeyim ve bir eklenti veya functions.php lehine veya aleyhine yorum yapacak uzmanlığım yok. Ancak functions.php yolunu izlemek ve bunu bir alt tema altında yapmak istersem, o zaman sorun nedir diye merak ediyorum? Neden bir eklentiye ihtiyacım var, alt temam beni gelecekteki tema yükseltmelerinden ve tema değişikliklerinden kurtarmaz mı?

    • Çocuk temanız sizi gelecekteki tema güncellemelerinden kurtaracaktır. Ancak, temalarınızı değiştirirseniz sizi KURTARMAYACAKTIR. Çünkü aktif temayı değiştirirseniz çocuk temayı da değiştirirsiniz.

      Yönetici

  6. Özel gönderi türleri ve taksonomiler için eklenti yoluna inanıyorum. Yazarın siteye özel bir eklentiden bahsetmesi benim de yaptığım şey. Özel gönderi türlerini, özel taksonomileri ve meta kutularını sitenin amacına göre uyarlanmış bu eklentiye yerleştiriyorum. Sonuçta sitenin teması değişecek ama veri kalacak ve hala kolayca erişilebilir olacak.

  7. Geliştiriciler, modüler uygulamalar oluşturmak için “veri”yi “tasarım”dan ayırmanın gerekli olduğu gerçeğini görmezden gelmeye devam ederlerse ve verinin nereye yerleştirildiği önemli değilse, bu veriyi / kodu yeniden kullanmak her zaman sorun olacaktır.

    WP topluluğundaki bazı kişilerde, nedense, WordPress ekosistemindeki verilere yalnızca bir eklenti içine sarıldığında erişilebileceği algısı var, bu yüzden bu tür tartışmaların “Büyük eklenti mi tema mı tartışması”na katkıda bulunduğunu görüyoruz.

    Odak noktası, WordPress'in arkaik eklenti sistemini geliştirmeye, kodu / veriyi tasarımdan ayıran modüler tasarım desenlerine dayalı kütüphaneler oluşturmaya konulmalıdır. Hem temalarda hem de eklentilerde kullanılabilen kütüphaneler...

    Bu tür tartışmalar WP post PHP4 döneminde anlamsız!!! (yeniden gönderi)

  8. Re: “Justin'in gönderisinde sorduğu gibi, portföy eklentisinde hangi standart alanlar yer almalıdır (gönderi meta'sına atıfta bulunarak). Bu tür bir konuşma, temalarında benzer işlevsellik oluşturan geliştiriciler arasında gerçekleşmelidir.”

    Ben mi? Geliştirilmeye uygun, iyi belgelenmiş bir eklentiyi, çalışması zor olan (“kapalı”), herkese uyan tek bir yaklaşıma tercih ederim.

    Demek istediğim, belki de şöyle demek mümkün: “Herkes için her şeyi olmaya çalışmıyorum. İşte temel eklentim. İşte onu nasıl geliştireceğiniz. Geliştirilmek üzere tasarlandı.” ve sadece bununla bırakın. Ne yaparsanız yapın, her kullanım durumunu, her kullanım ihtiyacını öngörmek zordur. Öyleyse neden zahmet edesiniz? Neden bir tür çerçeve olarak yaklaşmıyorsunuz ve ihtiyaç duyan geliştiricinin istediği gibi özelleştirmesine izin vermiyorsunuz?

    • Aslında plan bu. Son derece küçük ve kolayca özelleştirilebilir bir temel oluşturuyorum. Ancak, hangi alanların standart olması gerektiğini bilmek isterim.

  9. Yazım hatası?:

    “Tüm ekiplerimiz ekibimiz tarafından özel olarak tasarlandığından”

  10. Bence eklentide olmalı.
    Kullanıcı gelecekte veriye ihtiyaç duymayabilir düşüncesiyle, özel gönderi türündeki gönderiyi her zaman "normal" gönderi türüne dönüştürebilir. Bunu yapabilen bir eklenti var, depoda arama yaparsanız en az bir tane bulursunuz.

  11. İnsanların ne dediği benim için pek önemli değil. Özel gönderi türü bir eklentiye gider. Ön yüzde özel gönderi türüne uyum sağlamak için bir tema kolayca değiştirilebilir. CTP kodunun aynı olduğu farklı temalara sahip olmak yerine, temayı CTP için stilize etmenin daha mantıklı olduğunu düşünüyorum.

  12. Eklenti benim için. En azından teknik olmayan bir müşteri için, tema doğru çalışmasa bile bir sorun olduğu ortaya çıkacak ve bu da onları bir geliştiriciyle anlaşmaya teşvik edecektir.

  13. Hepsi projeye bağlı…
    Belirli bir süre sonra tema değiştirmesi gereken bir projeyi yönetiyorsanız… eklenti kullanabilirsiniz.

    veya tek temaya bağlı kalan projeler için... function.php ile devam edebilirler

  14. Herkes verilerin tema tarafından stilize edilmesi gerektiğini konuşuyor ve durumun böyle olduğu ve verilerle temanın ayrılabildiği örnekler veriyor.

    Bir temanın belirli bir verinin mevcut olmasına bağlı olduğu durumlar hakkında kimsenin konuştuğunu görmüyorum. Diyelim ki ülkelerin haritasını ve ülkeye özgü bazı verileri içeren bir temanız var ve bu harita ve veri olmadan temanın temel işlevselliğinin bir kısmını kaybetmesi söz konusu.

    Evet, bunu bir eklentideki verilerle hala yapabilirsiniz, ancak bir temanın bazı verilerin var olduğunu varsayması makul mü? Veri türlerini oluşturan eklentinin yüklü ve etkin olduğunu varsaymak makul mü? (Gerçek sorular…tartışalım!)

    Biraz teknik olmayan müşterim, sitenin bir kopyasını kendi 'temasıyla' oluşturmak isterse ne olur? Yeni bir Wordpress kurulumunda temayı etkinleştirdiklerinde, bir sürü şeyin eksik veya bozuk olduğunu fark ederler mi? Sitelerinin doğru görünmesi için gereken her şeyin temada olduğunu sanıyorlardı?

    Her iki yaklaşım için de kullanımlar görüyorum. Müşteri işlerimin çoğu için CPT'ler, meta kutuları ve bunları kütüphane dosyalarında erişimi kolaylaştıran ve dahil eden bazı işlevler ayarlıyorum. Bu, temamın çalışması için gereken tüm 'şeyleri' tek bir pakette tutar, ancak istersen CPT'leri yeni bir temaya taşımayı kolaylaştırır.

    Elbette, bir CPT birden fazla tema arasında kullanılabilecek gibi görünüyorsa ve yalnızca tek bir müşterinin verilerine gerçekten uygulanan SO kadar özel değilse, o zaman istediğiniz zaman dağıtılabilecek bir eklentiye dönüştürürsünüz.

    Veri ve temalar arasında basit, tek yönlü bir ilişki olduğunu düşünmüyorum. Her zaman 'stilize edilmesi gereken bazı verilerim var' durumu söz konusu değildir... bazen 'stilimin bazı verilere ihtiyacı var'.

    Bu konuda ne düşünüyorsunuz?

    • Tek bir “tam” pakete sahip olmanın bir faydası olduğu konusunda kesinlikle katılıyorum. Genellikle doğrudan bağlanması daha iyi olan temaya özgü işlevsellikler vardır (örneğin, Auttomatic'ten P2) vs. yüklenmiş tema ve tema eklentisi.

  15. AgentPress'e yaptığınız gönderme, CPT'leri eklentiler için %100 desteklememin nedenlerinden biri. Bu tür temalarla uğraşmak zorunda kaldım ve özel işlevi temadan kaldırmadığınız sürece bunları düzgün bir şekilde giydirmek çok zor. Müşterim ve ben, kod üzerinde çalışabileceğimiz bir noktaya getirmek için 20 saat harcadık.

      • The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
        But with a theme update, custom code in the theme’s function.php might get lost.
        So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
        You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
        Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
        So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
        uff, hope this is understandable, because my English is not the best ;-)

        Belki bunu okumanız için işe yarar: http://tinyurl.com/bf5dflt

        • Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted :)

  16. Öncelikli olarak, temanın değiştirilmesi durumunda ön yüzde ciddi şekilde "bozulacak" veya veri kaybedecek her şey için functions.php yerine eklentileri tercih ederim. Bunun tam olarak belirttiğiniz nedenleri var ve ayrıca php programcısı olmayan bizler için bir sorunu izole etmek için functions.php'deki şeyleri yorum satırı haline getirmemiz gerektiğinde çakışmaları gidermeye çalışmanın DELİCE olduğunu düşünüyorum.

    • Fikir, özel alanları (CPT) siteye özel bir eklentide kaydetmeniz gerektiğidir. Henüz özel bir eklenti yok. Ancak bu sadece genel gönderi türleri için bir temel eklenti oluşturma fikrini ortaya atıyor.

      Yönetici

  17. Yerel fonksiyonların kullanımına daha çok ikna oldum, ancak bu durumda eklentinin daha çok güvenilebileceğini düşünüyorum. Örneğin, belirli bir çerçeve ile wp kullanmaya başlarsanız. Çoğu durumda, ayarlarınızı ve verilerinizi kaybetmeden o çerçeveden kurtulmanıza yardımcı olacak bir wp profesyoneli işe alana kadar uzun süre kölesi olmanız mümkündür. Öte yandan, eklentiler neredeyse her temada çalışabilir.

    WP ile çalışmaya başladığımda çerçeveyi eklentiye tercih ediyordum. Gerçek şu ki, eklenti geliştiricileri bir şey geliştirirken acemileri ve daha az bilgili insanları dikkate alıyor. Şahsen WP kullanıcılarının çoğunun, sitelerin temel işlevleri için eklentilere bağımlı olmak yerine manuel kod düzenlemelerini tercih ettiğine inanıyorum. uzun vadede eklentiler güvenilir değildir. Öyle hissediyorum..

Cevap Bırakın

Yorum bırakmayı seçtiğiniz için teşekkürler. Lütfen tüm yorumların yorum politikamıza göre denetlendiğini ve e-posta adresinizin YAYINLANMAYACAĞINI unutmayın. Lütfen isim alanında anahtar kelime KULLANMAYIN. Kişisel ve anlamlı bir sohbet edelim.