WordPress Custom Postsoorten Debate - Functions.php of Plugins?

Zoals velen van jullie weten, woonde Syed Balkhi vorige week de WordCamp Raleigh 2012 bij. Tijdens het evenement leidde een van zijn tweets tot een behoorlijk debat. In dit artikel gaat onze oprichter Syed Balkhi in debat over de vraag of WordPress Custom Post Types thuishoren in functions.php file of in plugins. Hieronder is een tweet die dit debat heeft gestart:

Voeg geen aangepaste berichttypen toe aan functions.php -> Gebruik ALTIJD een site-specifieke plug-in - wpbeg.in/vcXr7j #wcraleigh

- WordPress Beginner (@wpbeginner) 4 november 2012

Na de tweet kwamen veel gerenommeerde mensen uit de WordPress-gemeenschap eraan. Je kunt hier het volledige gesprek zien. Curtis McHale ging nog een stap verder en werkte het onderwerp uit in zijn nieuwe blogpost.

Het gesprek van twitter bracht een aantal goede punten naar voren.

Samenvatting van argumenten

Plug-ins argument: De gebruiker heeft altijd de gegevens, ook als deze het thema wijzigen. Het ziet er misschien niet zo mooi uit, maar het blijft daar.

Functions.php Argument: Gegevens zonder ontwerp zouden niet relevant zijn. Het zal gebruikers nog meer verwarren.

Met welke kant ben je het eens? Het is duidelijk dat beide partijen hun problemen hebben, maar dat is de minste van twee kwaden?

Dit is de reden waarom wij vinden dat Aangepaste berichttypen dat zouden moeten zijn ALTIJD live in een site-specifieke plug-in of een afzonderlijke plug-in helemaal.

Lang leve data

Aangepaste berichttypen zijn gegevens. In de meeste gevallen overleven uw gegevens het huidige ontwerp. Nadat we onze thema's een paar keer hebben gewijzigd, begrijpen we die verklaring duidelijk. Posts, Pages, Links, Attachments en Revisions zijn alle soorten postsoorten die ingebouwd worden in WordPress. Bovendien hebben we berichttypen zoals Boeken, Testimonials, Deals, etc. Kun je je nu voorstellen dat we een thema veranderen en al deze laten verdwijnen? Zeker, we zouden niet willen dat dit gebeurt.

Ontwikkelaars in ons team hebben, dit zou niet veel uitmaken. Gezien al onze thema's zijn op maat ontworpen door ons team, wat maakt het eigenlijk uit? Het geheim schuilt in twee woorden: tijd en centralisatie. Zolang we alle benodigde gegevens hebben, hoeven we alleen maar de styling te veranderen. We hoeven ons niet elke keer opnieuw zorgen te maken over het kopiëren en plakken van de functies van het ene bestand naar het andere. Wat als u de functionaliteit wilt repliceren? Neem gewoon de plug-in en zet hem neer op uw nieuwe site. Verander de styling en je bent klaar.

Regels en normen

Wanneer u het woord ALTIJD gebruikt zoals in onze tweet, kan dit zowel regel als normen betekenen. Beide regels en normen zijn gemaakt voor de meerderheid. Er zullen altijd speciale scenario's zijn waarbij regels worden verbogen en normen worden overtreden, maar dat betekent niet dat we helemaal van de normen af ​​moeten..

Er zijn talloze generieke berichttypen die meestal dezelfde set extra meta-velden vereisen. Enkele voorbeelden die in je opkomen zijn: Citaten, Boeken, Recept, Getuigenissen, Portfolio, enz.

Gezien het grote aantal fotografie- en portfoliothema's die beschikbaar zijn in de vrije en commerciële markt, heeft het bijna geen zin om de gebruiker elke aangepaste posttypegegevens opnieuw in te voeren telkens wanneer ze een thema wijzigen. Laten we een voorbeeld van een casus-scenario bekijken:

Fotograaf - Gebruiker stelt een WordPress in die een blogfunctionaliteit heeft (standaard "post" CPT). Hij wil een portfolio van zijn werk toevoegen (vereist een Portfolio CPT). Hij wil getuigenissen van klanten laten zien (vereist een testimonial CPT). Al deze informatie gaat zeker voorbij een themaontwerp leven. Een jaar later wil de gebruiker het uiterlijk van zijn site veranderen en hem vernieuwen. Zoekt een nieuw thema met alle vergelijkbare functies. Op het moment dat hij van thema verandert, BOOM. Alle eerdere gegevens die hij heeft ingevoerd zijn verdwenen. Er is een menu met de naam Portfolio en een menu met de naam Testimonials, maar geen van de gegevens is er. De gebruiker denkt "HEILIGE CRAP, ik ben al mijn inhoud kwijtgeraakt". Creëert nieuwe ondersteuningsvragen op het forum. Verzendt e-mails naar sites zoals WPBeginner etc. Als ze geen goed antwoord ontvangen, moeten ze alle gegevens opnieuw invoeren. Dit is een waardeloze gebruikerservaring.

Dus hoe lossen we dit probleem op?

Mogelijke oplossing?

We creëren een nieuwe standaardbasis. Justin Tadlock begon al een tijdje met dit probleem aan de slag door een plug-in voor het basispakket te maken. Is het de perfecte oplossing voor iedereen? NEE, maar het zal voor de meerderheid zijn.

Zoals Justin in zijn post vraagt, welke standaardvelden moeten worden opgenomen in de portfolio-plug-in (verwijzend naar post-meta). Dit type gesprek moet plaatsvinden tussen ontwikkelaars die vergelijkbare functionaliteit in hun thema's maken. Waarom steeds hetzelfde ding van het ene thema naar het andere kopiëren en plakken als het via een plug-in kan? Als het eenmaal een standaard is, zullen andere thema's auteurs eraan gaan aanpassen.

We zien bijvoorbeeld een toename in stijlondersteuning voor zwaartekrachtformulieren in WordPress-themakaders zoals Genesis en anderen. Waarom? Omdat ze begrijpen dat hun gebruikers het gebruiken.

Er zijn enkele robuuste WordPress-thema's die geleverd worden met functionaliteit waarvan wij denken dat het plug-ins moeten zijn. Job Board-thema's, Issue Tracking-thema's, Thema Advertenties, Real Estate-thema's, enz. Ze moeten allemaal worden aangedreven door een basisplug-in. Het gebeurt al met WooCommerce. WooThemes heeft een groot aantal thema's uitgebracht met ingebouwde ondersteuning voor de plug-in. Andere themabedrijven hebben beloofd om op WooCommerce gebaseerde eCommerce-thema's ook vrij te geven. U kunt van het ene thema naar het andere overschakelen en al uw producten behouden zoals deze zijn. Dat is bijna alsof het thema is veranderd, maar alles viel gewoon op zijn plek. Dat is de themaveranderende ervaring waar we naar moeten streven.

Waarom niet hetzelfde doen met Portfolio, Testimonials en andere generieke aangepaste berichttypen? Is het omdat het te simpel is vs. eCommerce is een groter beest om te veroveren? Het is duidelijk dat eCommerce veel te veel velden heeft in vergelijking met de andere, dus het zou veel eenvoudiger moeten zijn voor deze generieke berichttypen. Het is gewoon een kwestie van bewust proberen om dingen beter te maken.

Neem een ​​kijkje op ReciPress plug-in. Het maakt een aangepaste metabox met receptvelden en koppelt deze aan berichten. Het is echter mogelijk om het te koppelen met aangepaste berichttypen. Iedereen die deze plug-in gebruikt, kan van thema veranderen zonder zo'n gedoe te moeten doorstaan.

Het zou leuk zijn om thema's als AgentPress te zien worden aangedreven door een gecentraliseerde basisplug-in. Het zou geweldig zijn om te zien dat de overgang van veranderende thema's gemakkelijker wordt. Als een gebruiker bijvoorbeeld van het ene fotografiethema naar het andere overschakelt, zou het geen chaos moeten zijn. Kleine fouten kunnen voorkomen, maar in ieder geval in het grotere geheel zullen de dingen werken.

U kunt altijd voorbeelden geven van super aangepaste berichttypen die zijn gemaakt voor eenmalig gebruik van een client, maar dat is de uitzondering, niet de regel.

Wat denken jullie over dit onderwerp? Waar moet de code van het aangepaste berichttype verblijven? In het bestand functions.php of in plug-ins?