Kodumu nereye koyacağım: plugin or functions.php?


86

Bir eklentiye veya temanın ne tür bir koda ait olduğuna karar vermek için anlaşılması kolay bir program var functions.phpmı?

Orada olan birçok vaka ve birçok tartışmalar bu konu hakkında WordPress işleyişiyle ilgili bazı yanlış vardır çünkü çoğunlukla. Fikirlere değil gerçeklere dayalı bir cevap istiyorum.

Bu hususların nasıl ele alınacağını açıklamalıdır (ve muhtemelen daha fazlasını):

Her iki taraf için de artıları ve eksileri vardır. İşlevlerimiz.php dosyanız için en popüler soru olan En İyi Kod Koleksiyonumuz , en azından tartışılabilir yanıtlar olarak birçok kod parçacığını elde etti.
Yeni başlayanların anlayabileceği ölçütlere, belki de bir kontrol listesine ihtiyacımız var - nedenlerle.

Ayrıca sitemize Chip Bennett tarafından verilen soruya bakınız: Özellikle "eklenti olmadan" bir çözüm isteyen sorular

İlgili: Burada veya web'de başka bir yerde bulduğum kod snippet'lerini nereye koyacağım?


Bu sorunun amacı için neyin gerçekleri oluşturacağını merak ediyorum. A kişisi, CPT'nin eklentiye girdiğini söylüyor, B kişisi CPT'nin temaya girdiğini söylüyor. Görüşlerden birini doğrulamak için bir gerçeği nasıl temin edebiliriz? Bu tehlikeli "yapıcı değil" e yakın olabilir.
Rarst

Yanıtlar:


72

Bu soruyla başlayacağım: İçeriğin sunulmasıyla mı, içeriğin veya sitenin veya kullanıcı kimliğinin oluşturulması / yönetimi ile ilgili işlevler mi?

İşlevsellik , özellikle içeriğin sunulmasıyla ilgili değilse , o zaman tamamen Eklenti Bölgesi dahilindedir. Bu liste uzun:

  • Çekirdek WP filtrelerini değiştirme ( wp_headkurallı bağlantılar, jeneratör ve diğer HTML metaleri, vb. İçerik
  • Site Favicon
  • İçerik sonrası kısa kodlar
  • Paylaşım bağlantıları yayınla
  • Google Analytics (ve benzeri) altbilgi komut dosyaları
  • SEO araçları / kontrolleri
  • vb.

İşlevselliği Eğer ilişkilidir için içeriğin sunumu , o zaman olduğu aday Tema dahil olmak için. Bu noktada, ben dönmek istiyorum Raf912 en Tema-şalter kriter @ : Temalar'ý geçtiğinizde işlevselliğini özler? Bu sorunun cevabı hayır ise , işlevsellik Temaya aittir. Bazı örnekler:

  • WP çekirdeği Gallery CSS'yi kaldırma / geçersiz kılma
  • Filtreleme sonrası alıntı uzunluğu, "daha fazla oku" metni vb.
  • Üzerinden uygulanan her şey add_theme_support()(Sanırım bunun açık olması gerekir)
  • Özel CSS

Normal olarak, bu iki soru oldukça açık bir farklılaşma çizgisi sağlayacaktır; ancak, istisnalar da var.

Özel Gönderi Türleri

Özel Posta Türleri, örneğin, Şablon Hiyerarşisinin tek tip arşiv sonrası dizin sayfaları ve tek gönderi sayfaları için çalıştığı şekliyle, içerik oluşturma ve sunumun benzersiz bir melezinin bir parçasıdır . CPT’lerin içerik oluşturma yönü normal olarak bunları Eklenti Bölgesinde düz bir şekilde yerleştirir; ancak, Eklentiler verilen herhangi bir Temanın tasarımına / düzenine / stiline doğal olarak uyan şablon sayfalarını tanımlayamaz (özellikle CPT, normal Başlık / İçerik / Meta'dan başka görüntülerse veya bununla ilişkili özel taksonomilere sahipse).

Uzun vadeli, bu eşitsizliğin çözümü, IMHO, verilen içerik türleri (emlak listeleri, takvim etkinlikleri, e-ticaret ürünleri, kitap / medya kütüphane kayıtları, vb.) İçin CPT'lerin tanımlanması için standart bir sözleşmeye / fikir birliğine sahip olmaktır. .). Bu şekilde, kullanıcı tarafından oluşturulan içerik, belirli bir CPT'nin standart / kongre tanımını uygulayan Temalar arasında taşınabilirken, Tema geliştiricileri, Tema şablon dosyalarında bu CPT'nin tasarımını / düzenini / stilini tanımlama esnekliğini korur.

Sosyal Medya Linkleri

Benzer şekilde, normalde sosyal medya profili bağlantılarının, mevcut temalarda her yerde bulunmalarından başka bir şey olmadığını, Eklenti Bölgesi olduğunu söyleyebilirim, çünkü içeriğin sunulması ile ilgisi yok . En iyi çözüm, bu profillerin çekirdekte bir yerde tanımlanması; Ancak, şu anda bu bağlantıları tanımlamanın standart / fikir birliği yoktur. Site belirleme düzeyinde veya kullanıcı başına en iyi tanımlanmış mı? Kullanıcı başına, şablonun hangi kullanıcının metaları gösteriliyor? vb.

Bu nedenle, uzun vadede, bu eşitsizliğin çözümü, bu bağlantıların nerede tanımlandığını belirleyen çekirdek ya da Tema geliştirici topluluğunun kendi fikir birliğini geliştirmesi için geçerlidir. Bu arada, her tema için onları tanımlamaktan başka bir şey yok.


add_theme_support( 'automatic-feed-links' );sunum değil. Ancak tema kurallarına göre gereklidir . Bir tema değişiminden sonra bu işlevselliği kaybetmek neden gerekli bir risk?
fuxia

1
Üzerinden uygulanan her şey add_theme_support()yalnızca Tema yoluyla uygulanabilir. Temanın add_theme_support( 'automatic-feed-links' )içinde kullanmak , oluşturulan besleme bağlantıları aynı olacağından, aslında Temadan Temaya kadar tutarlı bir deneyim sağlar .
Chip Bennett

4
Sanırım yanlış adlandı: Yayın bağlantıları tanıtım amaçlı değil. Bir sonraki tema bu işlevi çağırmazsa, kullanıcı feed linklerini kaybeder. Ve eklenti başına bunu sorunsuz bir şekilde ekleyebilirsiniz. Bu yüzden kafam karıştı. :)
fuxia

1
Biliyorsun: bu iyi bir nokta. :)
Chip Bennett

50

Kodun en iyi yerleştirildiği kolay bir test:

  • kodları functions.php dosyasına yazın
  • temayı değiştir
  • işlevselliğini özlüyor musun, blog düzgün çalışmıyor mu veya eski temanın parçaları (ör. kısa kodlar) kaldı mı?

    • evet: eklentiye ekle

    • no: fonksiyonlarında bırakın.php

Örnekler: Kısa kod yazın. Temayı değiştirdikten sonra kısa kodlar yazılarınıza bırakılır. Bu yüzden bir eklentiye daha iyi yerleştirilecektir.

Son yorumları listelemek için bir işlev yazın. Temayı değiştirdikten sonra her şey yolunda çünkü belki diğer temanın eşdeğeri bir işlevi var.

Gerçekten de kod ve ne yapacağına bağlı. Bazı kodlar yalnızca temanın stilini veya içeriğini etkiler, bazıları ise blog gönderilerini değiştirir.


11
+1 Kod temaya özgüyse, onu yazın functions.php. Birden fazla temaya başvurması gerekiyorsa, bir eklentiye ekleyin.
s_ha_dum

18

Bu sorunun kolay bir cevabı olduğunu sanmıyorum, ama iddiaya girerim karar için yardımcı olacak bir akış şeması yapabiliriz. İşte, genişletilebilecek ve genişletilmesi gereken böyle bir akış şemasının kaba taslakları. Önerileri ile yorum yapın!

  • Bu kod WordPress'in tek bir site kurulumunda barındırılıyor mu?
    • Evet - Sitenin teması sadece işlevsellikteki büyük yeniden tasarlamalar ve değişimlerle değişiyor mu?
      • Evet - Söz konusu kod bu güncel tasarıma özgü mü?
        • Evet: functions.php
        • No: Eklenti
      • Hayır (sık sık veya bir hevesle değişir) - Eklenti
    • Hayır (Multsisite) - Multisite kurulumunu barındırıyor musunuz VEYA eklentilere izin veren barındırılan bir multisite çözümü mü?
      • Evet: Söz konusu işlevsellik bu siteye özgü mü yoksa ağdaki diğer siteler tarafından da kullanılıyor mu / kullanılmalı mı?
        • Bu siteye özgü: functions.php
        • Birden fazla site arasında paylaşılıyor - Her sitede zorlamak istiyor musunuz?
          • Evet: Eklenti, mu-plugins dizininde saklanır veya ağ etkin
          • Hayır: Bu ilgisiz siteler ağı mı ? (örneğin farklı müşteriler)
            • Evet: Müşteri A, B, C ve D müşterileri için yazdığınız eklentiyi görmüşse veya etkinleştirmişse, profesyonelce olmaz mı? (örneğin, belki siteyi kırabilir veya istenmeyen işlevlere neden olabilir)
              • Evet: functions.php
              • No: Eklenti
            • No: Muhtemelen eklenti
      • Hayır (eklentilere izin vermeyen VIP gibi bir hizmet tarafından barındırılıyor): use functions.php
Buraya nasıl sığacağımı bilmediğim başka düşünceler:

  • Ana temalar - bazen paylaşılan işlevsellik ile bir ana tema oluşturmak ve işlevselliği ana temanın functions.php dosyasına koymak daha iyi olur.
  • Büyük çok bölgeli kurulumların eklenti dizinleri hızlı bir şekilde asılsız hale gelebilir, bu nedenle bazen düşük bir site yüzdesi (örneğin <% 1) tarafından kullanılan paylaşılan işlevsellik, işlev.php dosyalarında çoğaltmak için en iyi yoldur.

6

Buradan Temalar VS Eklentileri

Bir alt temaya özel kod ekleyin; böylece üst temayı güncellediğinizde özel kodunuz kaybolmaz.

Ayrıca tüm özel kodunuzu içeren siteye özgü bir eklenti de oluşturabilirsiniz.

Eklentilere karşı kod yazarken, eklentileri kullanabilir ve işlevlerini kullanabilirsiniz, ancak istediklerinizin çoğunda, el kodlaması, bir eklenti kullanmayı düşünebileceğiniz meta kutular gibi bazı durumlar dışında, değiştirilmesi en kolay olanıdır. Bir tema geliştiricisisin.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

  1. Yeni özel gönderi türü ekle - Kod
  2. Kullanıcılara yeni alanlar ekleyin - Yukarıdaki Kod
  3. Yeni widget ekle - Kod
  4. Özel kalıcı bağlantılar ekleme - WordPress Permalink Settings

5

Bunun ölü bir at olduğunu ve Chip'in onu tamamen kapladığını biliyorum, ama birkaç tane düşünce eklemek istedim.

Bir geçim programlaması yapar ve son başvuru tarihlerinin altındaki wordpress sitelerinde çalışırken kendinizi bulursanız, bunun gerçekten zamanın geldiğini anlayacaksınız.

Özellikle yeni başlayanlar için olmasa da, çoğu zaman bir temaya ihtiyaç duyduğunuz her şeyi eklemek ve bunu yapmak olarak adlandırmak çok daha hızlı ve kolaydır.

Söylendiği gibi, eğer düzenli olarak wordpress üzerinde çalışıyorsanız, aşağıdakileri yapmayı ciddi şekilde düşünmelisiniz :


  1. Eklenti iskeleti oluşturun

Bu, etkinleştirme, devre dışı bırakma, sürüm güncelleme, yönetici panelleri oluşturma ve kaldırma da dahil olmak üzere, genellikle bir eklentiyle yapmanız gereken her şeyi işlemelidir.

Bunu yapmak için zaman ayırırsanız, şunları bulacaksınız:

  • Eklentiler aracılığıyla işlevsellik eklemek artık fazla zaman gerektirmiyor
  • Gerektiğinde diğer projelerde yeniden kullanmak üzere sağlam bir eklenti listesi oluşturmaya başlayabilir ve uzun vadede kendinize çok zaman kazandırabilirsiniz.
  • Ekstra görünürlük istiyorsanız, bunları herkese açık hale getirebilirsiniz

Artık bir şeyleri doğru bir şekilde oluşturabilir ve gelecekteki projeleri daha hızlı bir şekilde yapabilirsiniz.


  1. Bir tema iskeleti oluşturun

Bu, genellikle bir temada ihtiyaç duyulan her şeyi ele almalıdır:

  • Yaygın olarak kullandığınız stilleri içeren bir temel stil sayfası (sıfırlar, vb.)
  • Herhangi bir şablon için ihtiyacınız olan her şeyi işleyen uygun bir index.php dosyası.
  • Functions.php dosyası - neredeyse kullanmazsınız, ancak yine de kullanışlı olur.

Bunu yaptıktan sonra, birincil temanızı kullanan bir alt tema iskeleti oluşturun.

  • Üst temanıza başvurarak stil sayfasını ekleyin.
  • Functions.php dosyasını ekleyin

Bu iki şeyi yaptıktan sonra, insanlar için yeni siteler oluşturmak çok daha hızlı hale gelir.


Yukarıdakileri yaparsanız, aşağıdakiler üzerinde çalışabilirsiniz:

  • Yeni bulunan boş zamanlarınızı PHP, WordPress, JavaScript, CSS ve / veya mySQL ile daha yakından tanıyarak geçirin ... bunları ne kadar çok öğrenirseniz işleri o kadar çabuk halledersiniz.
  • Geliştirmeniz gereken şeyleri bulurken eklentinizi, temanızı ve alt tema iskeletlerinizi güncelleyin. Ne kadar iyi olursanız olun, öğrenmeye devam ederseniz yapılacak iyileştirmeleri bulacaksınız.

Ve yukarıdakilerin hepsini yaparsanız, Chip'in cevabının o zaman sadece ideal olamayacağını, en uygun hale geleceğini göreceksiniz.


3

Basit cevap budur ..

Kod, belirli bir temada yerleşik olan işlevlerden herhangi birine mi bağlı? Eğer evet ise, o zaman bir temaya koyun.

Bu kodun siteler arasında ve temalar arasında aktarılabilir olmasını ister misiniz? Eğer evet ise, o zaman bir eklenti koyun.

Cevap yukarıdakilerin her ikisine de cevap vermiyorsa, siteyi 5 yıl sonra yeniden tasarlamanın zamanı geldiğinde hayal edin. Yazdığınız kodun işlevi bir sonraki tasarım güncellemesinden kurtulacak bir şey midir? Eğer evet ise, bir eklenti koyun.

Ayrıca, alt temalar kullanmıyorsanız ve temayı güncellemeyi planlıyorsanız, bir eklenti kullanmanızı da öneririm.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.