Som många av er vet, deltog Syed Balkhi förra veckan i WordCamp Raleigh 2012. Under evenemanget väckte en av hans tweets en hel del debatt. I den här artikeln kommer vår grundare Syed Balkhi att debattera om WordPress Custom Post Types hör hemma i functions.php-filen eller i plugins. Nedan följer en tweet som startade denna debatt:
Lägg inte till anpassade inläggstyper i functions.php -> Du bör ALLTID använda ett webbplatsspecifikt plugin – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 november 2012
Efter tweeten, många ansedda personer i WordPress-gemenskapen hakade på. Du kan se hela konversationen här. Curtis McHale tog det ett steg längre och utvecklade ämnet i sitt nya blogginlägg.
Konversationen från Twitter tog upp några bra poänger.
Sammanfattning av argument
Argument för plugins: Användaren kommer alltid att ha datan även om de byter tema. Det kanske inte ser lika snyggt ut, men det kommer att finnas kvar.
Argument för Functions.php: Data utan design skulle vara irrelevant. Det skulle förvirra användarna ännu mer.
Vilken sida håller du mer med om? Tydligtvis har båda sidor sina problem, men vilken är den mindre av två onda ting?
Här är varför vi tror att anpassade inläggstyper ALLTID bör finnas i en webbplatsspecifik plugin eller en separat plugin helt och hållet.
Länge leve data
Anpassade inläggstyper är data. I de flesta fall kommer din data att överleva den nuvarande designen. Efter att ha bytt våra teman några gånger förstår vi det uttalandet tydligt. Inlägg, sidor, länkar, bilagor och revisioner är alla typer av inläggstyper som kommer inbyggda med WordPress. Utöver det har vi inläggstyper som böcker, vittnesmål, erbjudanden, etc. Kan du nu föreställa dig om vi byter tema och allt detta försvinner? Säkert vill vi inte att det ska hända.
Med utvecklare i vårt team borde detta inte spela så stor roll. Med tanke på att alla våra teman är specialdesignade av vårt team, vad spelar det egentligen för skillnad? Hemligheten ligger i två ord: tid och centralisering. Så länge vi har all nödvändig data, behöver vi bara ändra stylingen i framtiden. Vi behöver inte oroa oss för att kopiera och klistra in funktioner från en fil till en annan varje gång. Vad händer om du vill replikera funktionaliteten? Ta bara pluginet och släpp det på din nya webbplats. Ändra stylingen, så är du klar.
Regler och standarder
När du använder ordet ALLTID, som vi gjorde i vår tweet, kan det betyda både regel och standard. Både regler och standarder skapas för majoriteten. Det kommer alltid att finnas speciella undantagsfall där regler böjs och standarder bryts, men det betyder inte att vi ska skrota standarder helt och hållet.
Det finns massor av generiska inläggstyper som mestadels kräver samma uppsättning ytterligare metafält. Några exempel som kommer att tänka på är: Citat, Böcker, Recept, Vittnesmål, Portfölj, etc.
Med tanke på det stora antalet fotografi- och portföljteman som finns tillgängliga på den gratis och kommersiella marknaden, är det nästan meningslöst att låta användaren ange all sin anpassade inläggsinformation igen varje gång de byter tema. Låt oss titta på ett exempel på ett scenario:
Fotograf – Användaren sätter upp en WordPress som har bloggfunktionalitet (standard “post” CPT). Han vill lägga till en portfölj av sitt arbete (kräver en Portfolio CPT). Han vill visa kundrecensioner (kräver en Testimonial CPT). All denna information kommer säkert att leva kvar längre än en temadesign. Ett år senare vill användaren ändra utseendet på sin webbplats och ge den en uppfräschning. Hittar ett nytt tema som har alla liknande funktioner. I samma ögonblick som han byter tema, BOOM. All tidigare data som han har angett har försvunnit. Det finns en meny som heter Portfolio, och en meny som heter Testimonials, men ingen av datan finns där. Användaren tänker ”HERREGUD, jag har förlorat allt mitt innehåll”. Skapar en ny supportfråga i forumet. Skickar e-post till webbplatser som WPBeginner etc. Om de inte får något bra svar, måste de mata in all data igen. Detta är en dålig användarupplevelse.
Så hur löser vi detta problem?
Möjlig lösning?
Vi skapar en ny standardbas. Justin Tadlock började redan arbeta med detta problem för ett tag sedan genom att skapa en basportföljplugin. Kommer det att vara den perfekta lösningen för alla? NEJ, men det kommer att vara det för majoriteten.
Som Justin frågar i sitt inlägg, vilka standardfält bör inkluderas i portföljpluginet (med hänvisning till inläggsmetadata). Den här typen av konversation behöver ske bland utvecklare som skapar liknande funktionalitet i sina teman. Varför kopiera och klistra in samma sak om och om igen från ett tema till ett annat när det kan göras via ett plugin? När det väl blir en standard kommer andra temautvecklare att börja anpassa sig till det.
Till exempel ser vi en ökning av stilstöd för Gravity Forms i WordPress-temaramverk som Genesis och andra. Varför? För att de förstår att deras användare använder det.
Det finns några robusta WordPress-teman som levereras med funktionalitet som vi anser borde vara plugins. Jobbportal-teman, ärendehanteringsteman, annonsteman, fastighetsteman, etc. De borde alla drivas av ett basplugin. Det händer redan med WooCommerce. WooThemes har släppt många teman som har inbyggt stilstöd för pluginet. Andra temaföretag har lovat att släppa WooCommerce-baserade e-handelsteman också. Du kan byta från ett tema till ett annat och behålla alla dina produkter som de är. Det är nästan som att temat har ändrats men allt har bara fallit på plats. Det är den temaändringsupplevelse vi behöver sträva efter.
Varför inte göra samma sak med Portfolio, Testimonials och andra generiska anpassade inläggstyper? Är det för att det är för enkelt jämfört med att e-handel är ett större problem att lösa? Tydligtvis har e-handel alldeles för många fält jämfört med de andra, så det borde vara mycket enklare för dessa generiska inläggstyper. Det handlar bara om att göra en medveten ansträngning för att göra saker bättre.
Ta en titt på ReciPress plugin. Det skapar en anpassad metabox med receptfält och kopplar den till inlägg. Det är dock möjligt att koppla den till anpassade inläggstyper. Alla som använder detta plugin kan byta teman utan att behöva gå igenom en sådan besvärlighet.
Det vore trevligt att se teman som AgentPress drivas av ett centraliserat basplugin. Det vore bra att se övergången att byta teman bli enklare. Om en användare till exempel byter från ett fototema till ett annat, borde det inte vara kaos. Mindre fel kan uppstå, men åtminstone i det stora hela kommer saker att fungera.
Du kan alltid ge exempel på superanpassade inläggstyper som skapats för engångsanvändning av klienter, men det är undantaget, inte regeln.
Vad tycker ni om det här ämnet? Var ska koden för anpassade inläggstyper finnas? I functions.php-filen eller i plugins?
Yazmin
Efter att ha förlorat mina CPT:er otaliga gånger när jag bytt teman, tycker jag det är frustrerande att behöva sätta upp samma funktionalitet om och om igen i functions.php.
Jag föredrar helt plugin-vägen och det är metoden jag kommer att använda framöver även för mina affärsprojekt.
Joshua Jarvis
Har exakt samma problem med ett tema för fastigheter. "Listningarna" var alla anpassade typer i ett tema som nu är funktionellt föråldrat. När jag uppgraderade temat förlorade jag allt anpassat inläggsinnehåll, nu måste jag hitta ett sätt att överföra allt. Jag har alternativ, men om det vore ett plugin skulle detta inte vara nödvändigt.
Redaktionell personal
Vi beklagar verkligen din olägenhet. Det är därför vi skrev det här inlägget eftersom vi vet att det verkligen gör slutanvändarens liv svårare.
Admin
Hugh H. Sands
“Vi behöver inte oroa oss för att kopiera och klistra in funktionerna från en fil till en annan varje gång.”
Jag kan inte tänka mig att någon skriver kod för en CPT i functions.php när det är så enkelt att isolera den med includes
Den här debatten handlar oftast om data kontra design och jag undrar, som ganska ny inom WP, vad gäller prestanda? Medför plugins någon extra belastning?
Redaktionell personal
Den här artikeln bör svara på din fråga om plugins och prestanda:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Tack för länken, verkligen hjälpsamt!
Kelvin Alfonso
Jag har alltid inkluderat CPT:er via en separat fil i functions.php, men jag tror att jag kommer att gå över till plugins-vägen. Tack!
Sudhakar
Jag är nybörjare och har ingen expertis att kommentera vare sig för eller emot ett plugin eller functions.php. Men jag undrar om jag vill gå functions.php-vägen och göra det under ett barn-tema, vad är problemet då? Varför behöver jag ha det i ett plugin, skulle inte mitt barn-tema rädda mig från framtida temauppgraderingar och ändringar i teman?
Redaktionell personal
Ditt barn-tema skulle rädda dig från framtida temauppdateringar. Det kommer dock INTE att rädda dig om du byter tema. Eftersom du byter barn-temat om du byter aktivt tema.
Admin
Pat Ramsey
Jag tror på plugin-vägen för anpassade inläggstyper & taxonomier. Författarens omnämnande av ett webbplatsspecifikt plugin är hur jag gör det. Jag placerar alla anpassade inläggstyper, anpassade taxonomier & metaboxar i detta plugin, skräddarsytt för webbplatsens syfte. Till slut kommer webbplatsens tema att ändras, men datan lever vidare & är fortfarande lättillgänglig.
shawn
Om utvecklare fortsätter att ignorera det faktum att separering av "data" från "design" är nödvändigt för att skapa modulära appar, och det spelar ingen roll var datan placeras, kommer återanvändning av den datan / koden alltid att vara ett problem.
Det verkar finnas en uppfattning hos vissa i WP-communityt, av en eller annan anledning, att man bara kan komma åt data i WordPress-ekosystemet om den är innesluten i ett plugin, så vi fortsätter att se diskussioner som denna som bidrar till "Den stora plugin vs tema-debatten".
Fokus måste läggas på att utveckla WordPress' arkaiska pluginsystem, för att skapa bibliotek baserade på modulära designmönster som separerar kod / data från design. Bibliotek som kan användas i både teman och plugins...
Debatter som dessa är meningslösa i WP post PHP4-eran!!! (Repost)
Mark Simchock
Re: "Som Justin frågar i sitt inlägg, vilka standardfält bör inkluderas i portföljpluginet (med hänvisning till post meta). Den här typen av konversation behöver ske bland utvecklare som skapar liknande funktionalitet i sina teman."
Jag? Jag skulle föredra ett väl dokumenterat plugin som är konstruerat för att kunna utökas, snarare än en "sluten", "one size fits all"-metod som är svår att arbeta med (den koden).
Min poäng är, kanske är det möjligt att säga: ”Jag försöker inte vara allt för alla. Här är mitt grundläggande plugin. Här är hur du kan anpassa det. Det är designat för att kunna anpassas.” och bara lämna det där. Oavsett vad du gör är det svårt att förutse alla användningsfall, alla behov. Så varför bry sig? Varför inte närma sig det som ett ramverk (av något slag) och låta utvecklaren i behov anpassa efter behov?
Justin Tadlock
Det är faktiskt planen. Jag bygger en extremt liten och lätt anpassningsbar bas. Men jag skulle vilja veta vilka fält, om några, som borde vara standard.
Kevin Maines
Stavfel?:
"Med tanke på att alla våra team är specialdesignade av vårt team"
Redaktionell personal
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Jag tror att det borde finnas i ett plugin.
Om användaren inte behöver datan i framtiden kan de alltid konvertera inlägget av anpassad inläggstyp till den "vanliga" inläggstypen. Det finns plugins som gör det, sök i arkivet så hittar du minst ett.
Christophe Debruel
Jag bryr mig egentligen inte om vad folk säger. Anpassade inläggstyper hör hemma i ett plugin. Ett tema kan enkelt modifieras för att passa den anpassade inläggstypen i frontend. Jag tycker det är mer logiskt att styla temat för CTP än att ha olika teman med samma CTP-kod.
Ingo
"Pods Framework" kan också vara en bra plugin-lösning. För CPT, CT och CF.
http://wordpress.org/extend/plugins/pods/
Redaktionell personal
Ja, pods är fantastiskt.
Admin
Elliott Richmond
Plugin för mig. Åtminstone för en icke-teknisk klient, även om temat kanske inte fungerar korrekt, kommer det att bli uppenbart att det finns ett problem och det kommer att uppmana dem att anlita en utvecklare.
Kailas Mahajan
Allt beror på projektet…
Om man hanterar ett projekt som kräver att temat ändras efter en viss tidsperiod…kan man använda ett plugin.
eller om projekt som håller sig till ett tema.. kan gå med function.php
Ross W
Alla pratar om hur datan behöver stylas av temat, och exempel där det är fallet och där datan och temat kan separeras.
Vad jag inte ser är någon som pratar om fall där ett tema är beroende av att ha viss specifik data tillgänglig. Låt oss säga att du har ett tema som har en karta över länder och viss landspecifik data, och att temat utan den kartan och datan förlorar en del av sin nyckelfunktionalitet.
Ja, du skulle fortfarande kunna göra detta med data i ett plugin, men är det rimligt att ett tema antar att viss data finns? Är det rimligt att anta att pluginet som skapar datatyperna är installerat och aktiverat? (Äkta frågor... diskutera!)
Vad händer om min något icke-tekniska klient vill skapa en kopia av webbplatsen med sitt 'tema'. De aktiverar temat på en ny Wordpress-installation för att bara upptäcka att en hel del saker saknas eller är trasiga? De trodde att temat innehöll allt de behövde för att deras webbplats skulle se rätt ut?
Jag kan se användningsområden för båda tillvägagångssätten. För det mesta av mitt klientarbete sätter jag upp CPT:er, metarutor och några funktioner för att göra det enkelt att komma åt dem, i biblioteksfiler och inkluderar dem. Detta håller allt 'skräp' som mitt tema behöver för att fungera i ett paket, men det är enkelt att flytta CPT:erna till ett nytt tema om jag vill.
Naturligtvis, om en CPT ser ut som om den kan användas över flera teman och inte är SÅ specifik att den bara verkligen gäller för en enskild klients data, då gör du om den till ett plugin som kan distribueras efter behov.
Jag tror inte att det finns ett enkelt, envägsförhållande mellan data och teman. Det är inte alltid så att 'jag har lite data som behöver stylas'... ibland 'min styling behöver lite data'.
Tankar om det?
Andres Hermosilla
Jag håller absolut med om att det finns en fördel med att ha ett "komplett" paket. Ofta finns det mycket temakopplad funktionalitet som är bättre att binda in direkt (dvs. P2 från Auttomatic) jämfört med ett installerat tema och ett temaplugin.
Konstantin Kovshenin
Plugins. Punkt.
Curtis McHale
Din referens till AgentPress är en av anledningarna till att jag är 100% för CPT:er i plugins. Jag har behövt hantera teman som det, och det är så svårt att styla dem ordentligt om man inte tar bort den anpassade funktionen från temat. Min klient och jag spenderade 20 timmar på att få koden till en punkt där vi faktiskt kunde arbeta med den.
Birgit
min bästa och favorit, rekommenderade lösning är den mycket flexibla TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Redaktionell personal
Bra idé. Jag önskar att jag kunde förstå vad skärmdumpen visade utan att ladda ner pluginet.
-Syed
Admin
Birgit
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
Kanske detta fungerar för dig att läsa det: http://tinyurl.com/bf5dflt
Redaktionell personal
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
Sara
Jag föredrar alltid plugins framför functions.php för allt som materiellt skulle ”gå sönder” på front-end eller förlora data om temat ändrades. Detta är av exakt de skäl du nämner, och jag tycker också att det är HELT GALET för oss som inte riktigt är PHP-programmerare att försöka felsöka konflikter när man måste kommentera bort saker i functions.php för att isolera ett problem.
matt
ok, vilket cpt-plugin rekommenderar du?
Redaktionell personal
Tanken är att du ska registrera CPT:er i ett webbplatsspecifikt plugin. Det finns inget specifikt plugin ute än. Men detta är bara att kasta runt idén om att skapa ett bas-plugin för generiska inläggstyper.
Admin
Muhammad Waqas
Jag är mer övertygad om användningen av lokala funktioner. men i det här fallet tror jag att plugin kan lita på mer. Till exempel om du börjar använda wp med ett specifikt ramverk. I de flesta fall är det möjligt att du blir en slav under lång tid om du inte anlitar en wp-professionell för att hjälpa dig att fly från det ramverket utan att förlora dina inställningar och data. Å andra sidan kan plugins fungera i nästan alla teman.
När jag började arbeta med wp föredrog jag ramverk framför plugins. Verkligheten är att pluginutvecklare betraktar nybörjare och mindre kunniga personer när de utvecklar något. Jag tror personligen att de flesta wp-användare gillar manuella kodändringar snarare än att förlita sig på plugins för kärnfunktioner på webbplatser. På lång sikt är plugins inte pålitliga. Det tycker jag i alla fall.