WordPress Custom Post Types Debate - Functions.php eller plugins?

Så många som du vet har den här veckan Syed Balkhi deltagit i WordCamp Raleigh 2012. Under evenemanget fick en av hans tweets en ganska debatt. I den här artikeln kommer vår grundare Syed Balkhi att diskutera om WordPress Custom Post Types hör till i functions.php-filen eller i plugins. Nedan är en tweet som startade denna debatt:

Lägg inte till anpassade posttyper i functions.php -> Du ska alltid använda en sajtspecifik plugin - wpbeg.in/vcXr7j #wcraleigh

- WordPress Nybörjare (@wpbeginner) 4 november 2012

Efter tweetet, många välrenommerade personer i WordPress-communityet chimed in. Du kan se hela samtalet här. Curtis McHale tog det ett steg längre och vidareutvecklade ämnet i hans nya blogginlägg.

Samtalet från twitter tog upp några bra poäng.

Sammanfattning av argument

Plugins argument: Användaren kommer alltid att ha data även om de ändrar temat. Det kanske inte ser så vackert ut, men det kommer att stanna kvar.

Funktioner.php Argument: Data utan design skulle vara irrelevant. Det kommer att förvirra användarna ännu mer.

Vilken sida håller du med? Tydligen har båda sidorna sina problem, men som är mindre av två onda?

Därför tror vi att anpassade inläggstyper ska ALLTID lever i en webbplatsspecifik plugin eller en separat plugin helt och hållet.

Långa Live Data

Anpassade inläggstyper är data. I de flesta fall kommer dina data att överleva den aktuella designen. Efter att ha ändrat våra teman några gånger förstår vi det uttalandet tydligt. Inlägg, sidor, länkar, bilagor och revideringar är alla typer av posttyper som kommer inbyggda med WordPress. Utöver det har vi posttyper som böcker, testimonialer, erbjudanden etc. Nu kan du tänka dig om vi ändrar ett tema och har alla dessa försvunna? Visst skulle vi inte vilja att det skulle hända.

Att ha utvecklare i vårt team, detta borde inte betyda mycket. Med tanke på alla våra teman är specialdesignade av vårt team, vilken skillnad gör det egentligen? Hemligheten ligger i två ord: tid och centralisering. Så länge vi har alla nödvändiga uppgifter, allt vi skulle behöva i framtiden är att ändra stilen. Vi behöver inte oroa oss för att kopiera och klistra in funktionerna från en fil till en annan varje gång. Vad händer om du vill replikera funktionaliteten? Ta bara pluggen och släpp den på din nya sajt. Ändra styling, och du är klar.

Regler och standarder

När du använder ordet ALTID som vi gjorde i vår tweet kan det innebära både regel och standarder. Både regler och standarder görs för majoriteten. Det kommer alltid att finnas speciella fallscenarier där reglerna är böjda och standarder bryts, men det betyder inte att vi borde bli av med standarderna helt och hållet.

Det finns massor av generiska posttyper som oftast kräver samma uppsättning ytterligare metafält. Några exempel som kommer att tänka på är: Citat, Böcker, Recept, Testimonials, Portfolio, etc..

Med tanke på det stora antalet fotograferings- och portföljteman som finns på den fria och kommersiella marknaden, är det nästan ingen mening att få användaren att skriva in alla sina egna posttypsuppgifter varje gång de ändrar ett tema. Låt oss ta en titt på ett exempelfallsscenario:

Fotograf - Användarinstallation en WordPress som har en bloggfunktionalitet (standard "post" CPT). Han vill lägga till en portfölj av sitt arbete (kräver en portfölj CPT). Han vill visa kundpresentationer (kräver en CPT-test). All denna information kommer säkert att leva förbi en temat design. Ett år senare vill användaren ändra utseendet på sin webbplats och ge det en uppdatering. Hitta ett nytt tema som har alla liknande funktioner. Det ögonblick han byter temaet, BOOM. Alla tidigare uppgifter som han skrev in har försvunnit. Det finns en meny som heter Portfolio, och en meny som heter Testimonials men ingen av data finns där. Användarens tycker "HELT CRAP, jag förlorade allt innehåll". Skapar nya supportfrågor i forumet. Skickar e-postmeddelanden till webbplatser som WPBeginner etc. Om de inte får något bra svar måste de skriva in alla data igen. Detta är en galen användarupplevelse.

Så hur löser vi problemet?

Möjlig lösning?

Vi skapar en ny standardbas. Justin Tadlock började redan arbeta med det här problemet ett tag tillbaka genom att skapa en basportfölj plugin. Ska det vara den perfekta lösningen för alla? NEJ, men det kommer att vara för majoriteten.

Som Justin frågar i hans inlägg, vilka standardfält ska ingå i portföljen plugin (refererar till posta meta). Denna typ av konversation behöver hända bland utvecklare som skapar liknande funktioner i sina teman. Varför kopiera och klistra in samma sak om och om från ett tema till ett annat när det kan göras via ett plugin? När det blir en standard kommer andra teman författare att börja anpassa sig till det.

Till exempel ser vi en ökning av stilstöd för Gravity Forms i WordPress-tematiska ramar som Genesis och andra. Varför? Eftersom de förstår att deras användare använder det.

Det finns några robusta WordPress-teman som kommer laddas med funktionalitet som vi tror borde vara plugins. Teman för arbetsstyrning, teman för utmatning av spårning, teman för klassificerade annonser, fastighets teman etc. De ska alla drivas med ett basplugin. Det händer redan med WooCommerce. WooThemes har släppt många teman som har inbyggt styling stöd för plugin. Andra temaföretag har lovat att släppa ut WooCommerce-baserade eCommerce-teman också. Du kan byta från ett tema till ett annat och behålla alla dina produkter. Det är nästan som temat ändrats men allting föll rätt på plats. Det är den temaförändrande erfarenhet som vi behöver sträva efter.

Varför gör inte samma sak med Portfolio, Testimonials och andra generiska anpassade posttyper? Är det för att det är för enkelt vs. eCommerce är ett större odjur att erövra? Det är uppenbart att e-handel har alltför många fält jämfört med de andra, så det borde vara mycket lättare för dessa generella posttyper. 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 fäster den med inlägg. Det är dock möjligt att fästa det med egna posttyper. Den som använder det här plugin kan ändra teman utan att behöva gå igenom ett sådant krångel.

Det skulle vara trevligt att se teman som AgentPress drivs av en central basplugin. Det skulle vara kul att se övergången till att ändra teman blir lättare. Om en användare exempelvis byter från ett fotografi till ett annat, borde det inte vara kaos. Mindre fel kan hända, men åtminstone i större bild fungerar sakerna.

Du kan alltid ge exempel på super anpassade posttyper skapade för en gångs klientanvändning, men det är undantaget, inte regeln.

Vad tycker ni om det här ämnet? Var borde den anpassade posttypkoden ligga? I funktionerna .php-filen eller i plugins?