Som många av er vet deltog Syed Balkhi i WordCamp Raleigh 2012 den gångna veckan. Under händelsen utlöste 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. Under är en tweet som startade denna debatt:
Don't add Custom Post Types in functions.php -> You should ALWAYS use a site-specific plugin – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) November 4, 2012
Efter tweeten kom många välrenommerade personer i WordPress-communityn in. Du kan se hela konversationen här. Curtis McHale tog det ett steg längre och utvecklade ämnet i sitt nya blogginlägg.
Konverteringen från Twitter tog upp några bra punkter.
Summary av argumenten
Argument för tillägg: Användaren kommer alltid att ha data även om de ändrar theme. Det kanske inte ser lika snyggt ut, men det kommer att finnas kvar.
Functions.php Argument: Data utan design skulle vara irrelevant. Det kommer att förvirra användarna ännu mer.
Vilken sida håller du mest med om? Clearly both sides have their issues, but which is the lesser of two evils?
Här är varför vi anser att Custom Post Types ALLTID bör finnas i ett site-specifikt plugin eller ett separat plugin helt och hållet.
Data lever länge
Custom Post Types är data. I de flesta fall kommer dina data att överleva den nuvarande designen. Efter att ha bytt themes ett par gånger förstår vi det uttalandet clear. Posts, Pages, Links, Attachments och Revisions är alla typer av post types som kommer built-in med WordPress. Högst upp på det har vi post typer som Böcker, Rekommendationer, Erbjudanden, etc. Nu kan du föreställa dig om vi ändrar ett theme och har alla dessa försvinna? Visst, vi skulle inte vilja att det skulle hända.
Eftersom vi har utvecklare i vårt team borde detta inte spela någon större roll. Med tanke på att alla våra themes är customize-designade av vårt team, vilken skillnad gör det egentligen? Hemligheten ligger i två ord: tid och centralisering. Så länge vi har all nödvändig data behöver vi i framtiden bara ändra stylingen. Vi kommer inte att behöva oroa oss för att copy and paste funktionerna 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 site. Ändra stylingen, och you are done.
Regler och standarder
När du använder ordet ALLTID, som vi gillar i vår tweet, kan det betyda både regel och standard. Både regler och normer är skapade för majoriteten. Det kommer alltid att finnas specialfall där regler böjs och standarder bryts, men det betyder inte att vi ska göra oss av med standarder helt och hållet.
Det finns massor av generiska typer av inlägg som mestadels kräver samma uppsättning ytterligare metafält. Några exempel som jag kommer att tänka på skulle vara: Citat, Böcker, Recept, Rekommendationer, 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 ingen mening att få användaren att åter ange all sin information om custom post type varje gång de byter tema. Låt oss ta en titt på ett exempel på ett scenario:
Fotograf – Användaren har publicerat en WordPress som har ett blogginlägg (standard ”post” CPT). Han vill add to en portfölj av sitt arbete (obligatorisk Portfolio CPT). Han vill visa rekommendationer från kunder (obligatorisk Testimonial CPT). All denna information kommer säkert att leva kvar efter att temat har designats. Ett år senare vill användaren ändra utseendet på sin site och ge den en uppdatering. Hittar ett new theme som har all liknande funktioner. I samma ögonblick som han byter theme, BOOM. All tidigare data som han har enter har försvunnit. Det finns en meny som heter Portfolio och en meny som heter Testimonials, men ingen av uppgifterna finns där. Användaren tänker ”HOLY CRAP, jag förlorade all min content”. Skapar en new supportfråga i Forum. Skickar email till webbplatser som WPBeginner etc. Om de inte får något bra response måste de skriva in all data igen. Detta är en skit användares upplevelse.
Så hur löser vi den här issue?
Möjlig lösning?
Vi skapar en new standardbas. Justin Tadlock började redan arbeta med denna issue för ett tag sedan genom att skapa ett plugin för en basportfölj. Kommer det att vara den perfekta lösningen för alla? NEJ, men det kommer att vara för majoriteten.
Som Justin frågar i sitt inlägg, vilka standardfält bör ingå i portföljens plugin (med hänvisning till post meta). Denna typ av konversation måste ske bland utvecklare som skapar liknande funktionalitet i sina teman. Varför copy and paste samma sak om och om igen från ett theme till ett annat när det kan göras via ett plugin? När det blir en standard kommer andra författare av teman att börja anpassa sig till det.
Vi ser till exempel en ökning av stilsupport för Gravity Forms i WordPress temaramar som Genesis och andra. Varför är det så? För att de förstår att deras användare använder det.
Det finns några robusta WordPress teman som levereras hämtar med funktionalitet som vi anser bör vara tillägg. Job Board teman, Issue Tracking teman, Classified Ads tema, Real Estate Teman, etc. De bör alla drivas av en bas plugin. Det händer redan med WooCommerce. WooThemes har släppt många themes som har built-in styling support för pluginet. Andra theme-företag har lovat att släppa WooCommerce-baserade eCommerce-teman också. Du kan byta från ett theme till ett annat och behålla alla dina produkter som de är. Det är nästan som om temat gillades men allt bara föll rätt på plats. Det är upplevelsen av att byta theme som vi måste sträva efter.
Varför inte göra samma sak med Portfolio, Testimonials, och andra generiska custom post types? Är det för att det är för enkelt vs. ecommerce är ett större odjur att erövra? Clear, eCommerce har alldeles för många fält jämfört med de andra, så det borde vara mycket lättare för dessa generiska post types. 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 custom metabox med receptfält och attachment den med posts. Det är dock möjligt att attachment den med custom post types. Den som använder detta plugin kan ändra themes utan att behöva gå igenom ett sådant krångel.
Det skulle vara trevligt att se teman som AgentPress drivas av ett centraliserat bas plugin. Det skulle vara bra att se övergången till att byta themes bli enklare. Till exempel, om en användare byter från ett fotograferingstema till ett annat, borde det inte vara kaos. Mindre error kan hända, men åtminstone i det stora hela kommer saker och ting att fungera.
Du kan alltid ge exempel på super custom post types som skapats för engångsanvändning av kunder, men det är undantaget eller ej regeln.
Vad tycker ni om det här ämnet? Var ska koden för custom post types finnas? I filen functions.php eller i tillägg?
Yazmin
Having been on the end of losing my CPTs numerous times as I switched themes, I find it frustrating to have to set up the same functionality over and over again in functions.php.
I completely prefer the plugin route and that is the method I will be using from here on out for my business projects as well.
Joshua Jarvis
Having this exact issue with a real estate theme. The ”listings” were all custom types in a theme that is now functionally obsolete. When I went to upgrade the theme I lost all the custom post content, now I have to figure out a way to transfer it all. I have options, but if it were plugin, this wouldn’t be necessary.
Editorial Staff
Extremely sorry about your inconvenience. This is why we wrote this post because we know that it really makes the end-user’s life harder.
Administratör
Hugh H. Sands
”We won’t have to worry about copying and pasting the functions from one file to another every single time.”
I can’t imagine someone writing code for a CPT in functions.php when it’s so easy to isolate it with includes
This debate goes most of the times around data vs design and I wonder, being quite new to WP, what about performance? Do plugins impose any overload?
Editorial Staff
This article should answer your question about plugins and performance:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Administratör
Hugh Sands
Thanks for the link, really helpful!
Kelvin Alfonso
I’ve always included CPT’s through a separate file into the functions.php but I think I’ll be switching over to the plugins route. Thank you!
Sudhakar
I am a beginner and I have no expertise to comment one way or the other in favor or against of a plug-in or functions.php. But I am wondering if I want to go the functions.php route and do it under a child theme, what is the problem then? Why do I need to have it in a plug-in, wouldn’t my child theme save me from future theme upgrades and changes in the themes?
Editorial Staff
Your child theme would save you from future theme updates. However, it will NOT save you if you change your themes. Because you change the child theme if you change the active theme.
Administratör
Pat Ramsey
I’m a believer in the plugin route for custom post types & taxonomies. The author’s mention of a site-specific plugin is how I do it. I place any custom post types, custom taxonomies & metaboxes in this plugin, tailored for the site’s purpose. Eventually the site’s theme will change but the data lives on & is still easily accessible.
shawn
If developers continue to ignore the fact that separating ”data” from for ”design” is necessary to create modular apps, and it does not matter where it is the data placed, reusing that data / code will always be problem.
There seems to be a perception by some in the WP community, for one reason or the other that you can only access data in the WordPress ecosystem if it is wrapped in a plugin so we keep seeing discussions like this contributing to ”The great plugin vs theme debate”.
Focus needs to placed on evolving the WordPress’ archaic plugin system, to creating libraries based on a modular design patterns that separate code / data from design. Libraries that can be used in both themes and plugins….
Debates like these are pointless in the WP post PHP4 era!!! (re-post)
Mark Simchock
Re: ”As Justin asks in his post, what standard fields should be included in the portfolio plugin (referring to post meta). This type of conversation needs to happen among developers who are creating similar functionality in their themes.”
Moi? I would prefer a well documented plugin that’s engineered to be enhanced than a ”closed”, one size fits all approach that difficult to work with (that code).
My point is, perhaps it’s possible to say, ”I’m not trying to be all things to all people. Here’s my basic plugin. Here’s how you trick it out. It’s designed to be tricked out.” and just leave it at that. No matter what you do it’s difficult to anticipate every use case, every use need. So why bother? Why not approach it as a framework (of sorts) and let the dev in need just customize as needed?
Justin Tadlock
That’s actually the plan. I’m building an extremely small and easily-customizable base. But, I’d like to know what, if any, fields should be standard.
Kevin Maines
Typo?:
”Considering all of our teams are custom designed by our team”
Editorial Staff
Fixed it. Thanks for catching that
Administratör
Affan Ruslan
I believe it should be on plugin.
In case the user might not need the data in future, they can always convert the custom post type post to the ”normal” post type. There’s plugin to do so, search in the repo and you’ll find at least one.
Christophe Debruel
I don’t really care what people say. Custom post type goes into a plugin. A theme can easily be modified to fit the custom post type in the frontend. I find it more logic to style the theme for the CTP than having different themes with the same CTP code.
Ingo
”Pods Framework” could be a good plugin solution, too. For CPT, CT and CF.
http://wordpress.org/extend/plugins/pods/
Editorial Staff
Yes, pods is awesome.
Administratör
Elliott Richmond
Plugin for me. At least for a non technical client, although the theme might not function correctly it will become apparent that there is a problem and that will prompt them to get a developer onboard.
Kailas Mahajan
Its all depend on the project…
if one handling project which needs to change theme after a certaine period of time…can use plugin..
or if project which are sticking with the one theme.. can go with function.php
Ross W
Everyone’s talking about how the data needs to be styled by the theme, and examples where that’s the case and where the data and theme can be separated.
What I don’t see is anyone talking about cases where a theme depends on having some specific data available. Lets say you have a theme that has a map of countries and some country-specific data, and that, without that map and data the theme loses some of its key functionality.
Yes, you could still do this with the data in a plugin, but is it reasonable for a theme to assume that some data exists? Is it reasonable to assume that the plugin that creates the data types is installed and enabled? (Genuine questions…discuss!)
What if my slightly non-technical client wants to create a copy of the site with their ’theme’. They enable the theme on a new Wordpress install only to find that a whole load of stuff is missing or broken? They thought that the theme contained all that they needed for their site to look right?
I can see uses for both approaches. For most of my client work I set up CPT’s, meta-boxes, and some functions to make accessing them simple, in library files and include them. This keeps all the ’stuff’ that my theme needs to work in one package, but keeps it simple to move the CPT’s to a new theme should I want to.
Of course, if a CPT looks like it could be used across multiple themes and isn’t SO specific that it only really applies to a single client’s data then you turn it into a plugin that can be deployed at will.
I don’t think there’s a simple, one-way relationship between data and themes. It’s not always the case that ’I have some data that needs styling’…sometimes ’my styling needs some data’.
Thoughts on that?
Andres Hermosilla
I definitely agree that there is a benefit to having one ”complete” package. Often times there is very theme specific functionality that is better to be tied in directly (i.e. P2 from Auttomatic) vs. installed theme and theme plugin.
Konstantin Kovshenin
Plugins. Period.
Curtis McHale
Your reference to AgentPress is one of the reasons I’m 100% for CPT’s in plugins. I’ve had to deal with themes like that and it’s so hard to skin them properly unless you remove the custom function from the theme. My client and I spent 20 hours getting the code to a point we could actually work on it.
Birgit
my best and favorite, recommended solution is the highly flexible TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Editorial Staff
Neat idea. I wish I could understand what the screenshot was showing without downloading the plugin.
-Syed
Administratör
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
Perhaps this will work for you to read it: http://tinyurl.com/bf5dflt
Editorial Staff
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
I always prefer plugins over functions.php for anything that would materially ”break” on the front end or lose data if the theme were changed. This is for precisely the reasons you cite, and I also feel that it is NUTSO for those of us who are not really php programmers to try to troubleshoot conflicts when you have to be commenting out stuff in functions.php to isolate a problem.
matt
ok, so which cpt plugin do you recommend?
Editorial Staff
The idea is that you should register CPT’s in a site-specific plugin. There is not a specific plugin out there yet. But this is just tossing around the idea of creating a base plugin for generic post types.
Administratör
Muhammad Waqas
I’m more convinced with the use of local functions. but in this case I think plugin can be trusted more. For example if you start using wp with a specific framework. In most of cases It possible that you’ll become a slave for a long time unless until you hire a wp professional to help you escape from that framework without losing your settings and data. On the other hand plugins can work at almost at every theme.
When I started working with wp I preferred framework over plugin. The reality is that plugin developer consider newbie and less literate people when developing something. I personally believe that most part of wp users like manual code hacks than depending on plugins for core functions of sites. in long term plugins aren’t reliable. I fee so..