WordPress Custom Post Typer Debat - Funksjoner.php eller Plugins?

Som mange av dere vet, deltok den siste uken Syed Balkhi på WordCamp Raleigh 2012. Under hendelsen utløste en av hans tweets ganske debatt. I denne artikkelen vil vår grunnlegger Syed Balkhi diskutere om WordPress Custom Post Types hører til i functions.php-filen eller i plugins. Nedenfor er en tweet som startet denne debatten:

Ikke legg til egendefinerte innleggstyper i functions.php -> Du bør ALTID bruke et nettstedspesifikt plugin - wpbeg.in/vcXr7j #wcraleigh

- WordPress Beginner (@wpbeginner) 4. november 2012

Etter tweetet, mange anerkjente folk i WordPress samfunnet chimed i. Du kan se hele samtalen her. Curtis McHale tok det et skritt videre og videreutviklet emnet i hans nye blogginnlegg.

Samtalen fra twitter brakte opp noen gode poeng.

Sammendrag av argumenter

Plugins argument: Brukeren vil alltid ha dataene selv om de endrer temaet. Det kan ikke se så pent ut, men det vil bli der.

Funksjoner.php Argument: Data uten design ville være irrelevant. Det vil forvirre brukerne enda mer.

Hvilken side er du enig i? Klart begge sidene har sine problemer, men som er mindre av to onde?

Her er grunnen til at vi tror at egendefinerte innleggstyper skal ALLTID lever i et nettstedspesifikt plugin eller en egen plugin helt.

Long Live Data

Egendefinerte innleggstyper er data. I de fleste tilfeller vil dataene overleve det nåværende designet. Etter å ha endret temaene våre noen ganger, forstår vi dette utsagnet tydelig. Innlegg, sider, koblinger, vedlegg og revisjoner er alle typer posttyper som kommer innebygd med WordPress. På toppen av det har vi posttyper som bøker, testimonialer, tilbud, etc. Nå kan du forestille deg om vi bytter tema og har alle disse forsvinne? Sikkert ville vi ikke at det skulle skje.

Å ha utviklere i vårt team, dette burde ikke ha noe mye. Tatt i betraktning alle våre temaer er spesialdesignet av teamet vårt, hvilken forskjell gjør det egentlig? Hemmeligheten ligger i to ord: tid og sentralisering. Så lenge vi har alle nødvendige data, vil alt vi måtte gjøre i fremtiden, endre stilingen. Vi trenger ikke å bekymre oss for å kopiere og lime funksjonene fra en fil til en annen hver eneste gang. Hva om du vil gjenskape funksjonaliteten? Bare ta pluggen og slipp den i ditt nye nettsted. Endre styling, og du er ferdig.

Regler og standarder

Når du bruker ordet ALTID som vi gjorde i vårt tweet, kan det bety både regel og standarder. Både regler og standarder er laget for flertallet. Det vil alltid være spesielle tilfelle scenarier der regler er bøyd og standarder er brutt, men det betyr ikke at vi skal bli kvitt standarder helt og holdent.

Det er tonnevis av generiske innleggstyper som for det meste krever det samme settet med ekstra metafelt. Noen eksempler som kommer til å tenke ville være: Sitater, bøker, oppskrift, testimonials, portefølje mv.

Tatt i betraktning det store antallet fotograferings- og porteføljetemaer som er tilgjengelige på det frie og kommersielle markedet, gjør det nesten ingen mening at brukeren skal skrive inn alle sine egendefinerte innleggstypeinformasjon hver gang de endrer et tema. La oss ta en titt på et eksempelsscenario:

Fotograf - Brukeroppsett et WordPress som har en bloggfunksjonalitet (standard "post" CPT). Han ønsker å legge til en portefølje av sitt arbeid (krever en portefølje CPT). Han ønsker å vise klienterklæringer (krever en anbefaling CPT). All denne informasjonen kommer sikkert til å leve forbi et tema design. Et år senere vil brukeren endre utseendet til nettstedet og gi det en fornyelse. Finn et nytt tema som har alle de samme funksjonene. Det øyeblikket han bytter temaet, BOOM. Alle tidligere data som han skrev inn, har forsvunnet. Det er en meny kalt Portefølje, og en meny som heter Testimonials, men ingen av dataene er der. Brukerens mener "HOLY CRAP, jeg har mistet alt innholdet mitt". Oppretter nye støttespørsmål i forumet. Sender e-post til nettsteder som WPBeginner osv. Hvis de ikke mottar noe godt svar, må de på nytt angi alle dataene. Dette er en crappy brukeropplevelse.

Så hvordan løser vi dette problemet?

Mulig løsning?

Vi lager en ny standardbase. Justin Tadlock begynte allerede å jobbe med dette problemet en stund tilbake ved å lage en base portefølje plugin. Skal det være den perfekte løsningen for alle? Nei, men det vil være for flertallet.

Som Justin spør i innlegget hans, hvilke standardfelt skal inkluderes i porteføljeplatsen (refererer til postmeta). Denne typen samtale må skje blant utviklere som skaper lignende funksjonalitet i deres temaer. Hvorfor kopiere og lime det samme om og om igjen fra ett tema til et annet når det kan gjøres via et plugin? Når det blir en standard, vil andre temaer forfattere begynne å tilpasse seg det.

For eksempel ser vi en økning i stilstøtte for Gravity Forms i WordPress-temaer som Genesis og andre. Hvorfor? Fordi de forstår at brukerne bruker det.

Det er noen robuste WordPress-temaer som kommer i bruk med funksjonalitet som vi mener burde være plugins. Job Board temaer, Issue Tracking temaer, Classified Ads tema, Real Estate Temaer, etc. De skal alle bli drevet av en base plugin. Det skjer allerede med WooCommerce. WooThemes har gitt ut mange temaer som har innebygd styling støtte for plugin. Andre tema selskaper har lovet å frigjøre WooCommerce-baserte eCommerce-temaer også. Du kan bytte fra ett tema til et annet og beholde alle produktene dine som det er. Det er nesten som temaet endret, men alt gikk bare rett på plass. Det er temaendringsopplevelsen vi må streve for.

Hvorfor ikke gjør det samme med portefølje, testimonials og andre generiske tilpassede innleggstyper? Er det fordi det er for enkelt vs. eCommerce er et større dyr å erobre? Det er klart at e-handel har altfor mange felt sammenlignet med de andre, så det burde være mye lettere for disse generiske innleggstyper. Det handler bare om å gjøre en bevisst innsats for å gjøre ting bedre.

Ta en titt på ReciPress-plugin. Den lager en tilpasset metaboks med oppskriftsfelt og legger den til med innlegg. Det er imidlertid mulig å feste det med egendefinerte innleggstyper. Alle som bruker dette programtillegget, kan endre temaer uten å måtte gå gjennom et slikt problem.

Det ville være fint å se temaer som AgentPress, drevet av et sentralisert plugin. Det ville være flott å se overgangen til å endre temaer blir enklere. For eksempel, hvis en bruker bytter fra et fotograferingstema til et annet, bør det ikke være kaos. Mindre feil kan skje, men i det minste i det større bildet, vil det fungere.

Du kan alltid gi eksempler på super tilpassede posttyper opprettet for engangsklientbruk, men det er unntaket ikke regelen.

Hva tenker du på dette emnet? Hvor skal den egendefinerte posttypekoden være? I funksjonsfilen eller i plugins?