Wie viele von Ihnen wissen, nahm Syed Balkhi in der vergangenen Woche am WordCamp Raleigh 2012 teil. Während der Veranstaltung löste einer seiner Tweets eine ziemliche Debatte aus. In diesem Artikel wird unser Gründer Syed Balkhi diskutieren, ob WordPress Custom Post Types in die functions.php-Datei oder in Plugins gehören. Im Folgenden finden Sie einen Tweet, der diese Debatte ausgelöst hat:
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
Nach dem Tweet meldeten sich viele angesehene Leute aus der WordPress-Community zu Wort. Sie können die gesamte Diskussion hier verfolgen. Curtis McHale ging noch einen Schritt weiter und erläuterte das Thema in seinem neuen Blogbeitrag.
Die Konversation auf Twitter brachte einige großartige Punkte zur Sprache.
Zusammenfassung der Argumente
Argument Plugins: Der Benutzer wird immer die Daten haben, auch wenn er das Thema ändert. Sie sehen vielleicht nicht so schön aus, aber sie bleiben erhalten.
Functions.php Argument: Daten ohne Design wären irrelevant. Es würde die Benutzer noch mehr verwirren.
Welcher Seite stimmen Sie eher zu? Natürlich haben beide Seiten ihre Probleme, aber welches ist das geringere Übel?
Wir sind der Meinung, dass Custom Post Types IMMER in einem Site-spezifischen Plugin oder einem separaten Plugin untergebracht werden sollten.
Lang leben die Daten
Benutzerdefinierte Beitragstypen sind Daten. In den meisten Fällen werden Ihre Daten das aktuelle Design überdauern. Da wir unsere Themes schon ein paar Mal gewechselt haben, verstehen wir diese Aussage sehr gut. Beiträge, Seiten, Links, Anhänge und Überarbeitungen sind alle Arten von Beitragstypen, die in WordPress integriert sind. Darüber hinaus gibt es Beitragstypen wie Bücher, Testimonials, Deals usw. Könnten Sie sich nun vorstellen, dass bei einem Wechsel des Themes all diese Typen verschwinden würden? Das wollen wir natürlich nicht.
Da wir Entwickler in unserem Team haben, sollte dies kein großes Problem darstellen. Wenn man bedenkt, dass alle unsere Themes von unserem Team individuell gestaltet werden, was macht es da schon für einen Unterschied? Das Geheimnis liegt in zwei Worten: Zeit und Zentralisierung. Solange wir alle notwendigen Daten haben, müssen wir in Zukunft nur noch das Styling ändern. Wir müssen uns nicht jedes Mal mit dem Kopieren und Einfügen der Funktionen von einer Datei in eine andere beschäftigen. Was ist, wenn Sie die Funktionalität replizieren möchten? Nehmen Sie einfach das Plugin und fügen Sie es auf Ihrer neuen Website ein. Ändern Sie das Styling, und Sie sind fertig.
Regeln und Standards
Wenn Sie das Wort IMMER verwenden, wie wir es in unserem Tweet getan haben, kann es sowohl Regeln als auch Standards bedeuten. Beide, Regeln und Normen, sind für die Mehrheit gedacht. Es wird immer Sonderfälle geben, in denen Regeln gebogen und Standards gebrochen werden, aber das bedeutet nicht, dass wir die Standards ganz abschaffen sollten.
Es gibt tonnenweise generische Beitragstypen, die meist die gleichen zusätzlichen Metafelder erfordern. Einige Beispiele, die mir in den Sinn kommen, sind: Zitate, Bücher, Rezepte, Testimonials, Portfolio usw.
In Anbetracht der großen Anzahl von Fotografie- und Portfoliodesigns, die auf dem freien und kommerziellen Markt erhältlich sind, macht es fast keinen Sinn, den Benutzer zu zwingen, alle seine benutzerdefinierten Post-Type-Informationen jedes Mal neu einzugeben, wenn er ein Design wechselt. Werfen wir einen Blick auf ein Beispielszenario:
Fotograf – Der Benutzer richtet ein WordPress ein, das über eine Blog-Funktionalität verfügt (Standard-„Post“-CPT). Er möchte ein Portfolio seiner Arbeit hinzufügen (erfordert ein Portfolio CPT). Er möchte Kundenreferenzen zeigen (erfordert ein Testimonial CPT). All diese Informationen werden sicherlich über das Design eines Themas hinausgehen. Ein Jahr später möchte der Benutzer das Aussehen seiner Website ändern und ihr einen neuen Anstrich geben. Er findet ein neues Theme, das alle ähnlichen Funktionen hat. In dem Moment, in dem er das Theme wechselt, BOOM. Alle Daten, die er zuvor eingegeben hat, sind verschwunden. Es gibt ein Menü namens Portfolio und ein Menü namens Testimonials, aber keine der Daten ist mehr da. Der Benutzer denkt „HOLY CRAP, ich habe alle meine Inhalte verloren“. Er erstellt eine neue Supportanfrage im Forum. Er sendet E-Mails an Websites wie WPBeginner usw. Wenn sie keine gute Antwort erhalten, müssen sie alle Daten erneut eingeben. Das ist eine beschissene Benutzererfahrung.
Wie können wir dieses Problem also lösen?
Mögliche Lösung?
Wir erstellen eine neue Standard-Basis. Justin Tadlock hat bereits vor einiger Zeit begonnen, an diesem Problem zu arbeiten, indem er ein Basis-Portfolio-Plugin erstellt hat. Wird es die perfekte Lösung für alle sein? NEIN, aber es wird für die Mehrheit sein.
Wie Justin in seinem Beitrag fragt, welche Standardfelder in das Portfolio-Plugin aufgenommen werden sollten (in Bezug auf die Post-Meta). Diese Art von Konversation muss unter den Entwicklern stattfinden, die ähnliche Funktionen in ihren Themes erstellen. Warum das Gleiche immer wieder von einem Theme in ein anderes kopieren und einfügen, wenn es auch über ein Plugin möglich ist? Sobald dies zum Standard wird, werden sich andere Theme-Autoren daran anpassen.
Zum Beispiel sehen wir eine zunehmende Unterstützung für Gravity Forms in WordPress-Theme-Frameworks wie Genesis und anderen. Warum? Weil sie verstehen, dass ihre Benutzer es verwenden.
Es gibt einige robuste WordPress-Themes, die mit Funktionen ausgestattet sind, die unserer Meinung nach Plugins sein sollten. Job Board Themes, Issue Tracking Themes, Kleinanzeigen Themes, Real Estate Themes, etc. Sie alle sollten von einem Basis-Plugin angetrieben werden. Bei WooCommerce ist dies bereits der Fall. WooThemes hat zahlreiche Themes mit integrierter Styling-Unterstützung für das Plugin veröffentlicht. Andere Theme-Firmen haben versprochen, ebenfalls auf WooCommerce basierende eCommerce-Themes zu veröffentlichen. Sie können von einem Theme zu einem anderen wechseln und alle Ihre Produkte unverändert beibehalten. Das ist fast so, als ob das Theme gewechselt wurde, aber alles an seinem Platz bleibt. Das ist die Erfahrung beim Wechsel des Themes, die wir anstreben sollten.
Warum nicht dasselbe mit Portfolio, Testimonials und anderen generischen benutzerdefinierten Beitragstypen tun? Liegt es daran, dass es zu einfach ist, während der eCommerce ein größeres Ungeheuer ist, das es zu besiegen gilt? Es ist klar, dass eCommerce im Vergleich zu den anderen Bereichen viel zu viele Felder hat, so dass es für diese generischen Beitragstypen viel einfacher sein sollte. Man muss sich nur bewusst darum bemühen, die Dinge besser zu machen.
Werfen Sie einen Blick auf das ReciPress-Plugin. Es erstellt eine benutzerdefinierte Metabox mit Rezeptfeldern und fügt sie an Beiträge an. Es ist jedoch auch möglich, sie mit benutzerdefinierten Beitragstypen zu verknüpfen. Jeder, der dieses Plugin verwendet, kann das Thema wechseln, ohne dass er sich die Mühe machen muss.
Es wäre schön, wenn Themes wie AgentPress durch ein zentrales Basis-Plugin betrieben werden könnten. Es wäre schön, wenn der Wechsel von Themes einfacher würde. Wenn ein Benutzer zum Beispiel von einem Fotografie-Theme zu einem anderen wechselt, sollte es kein Chaos sein. Kleinere Fehler könnten passieren, aber zumindest im Großen und Ganzen werden die Dinge funktionieren.
Man kann immer Beispiele für super angepasste Beitragstypen anführen, die für die einmalige Nutzung durch einen Kunden erstellt wurden, aber das ist die Ausnahme, nicht die Regel.
Was denkt ihr über dieses Thema? Wo sollte der Code für benutzerdefinierte Beitragstypen untergebracht werden? In der Datei functions.php oder in den Plugins?
Syed Balkhi says
Hey WPBeginner readers,
Did you know you can win exciting prizes by commenting on WPBeginner?
Every month, our top blog commenters will win HUGE rewards, including premium WordPress plugin licenses and cash prizes.
You can get more details about the contest from here.
Start sharing your thoughts below to stand a chance to win!
Yazmin says
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 says
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 says
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.
Admin
Hugh H. Sands says
„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 says
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/
Admin
Hugh Sands says
Thanks for the link, really helpful!
Kelvin Alfonso says
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 says
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 says
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.
Admin
Pat Ramsey says
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 says
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 says
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 says
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 says
Typo?:
„Considering all of our teams are custom designed by our team“
Editorial Staff says
Fixed it. Thanks for catching that
Admin
Affan Ruslan says
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 says
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 says
„Pods Framework“ could be a good plugin solution, too. For CPT, CT and CF.
http://wordpress.org/extend/plugins/pods/
Editorial Staff says
Yes, pods is awesome.
Admin
Elliott Richmond says
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 says
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 says
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 says
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 says
Plugins. Period.
Curtis McHale says
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 says
my best and favorite, recommended solution is the highly flexible TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Editorial Staff says
Neat idea. I wish I could understand what the screenshot was showing without downloading the plugin.
-Syed
Admin
Birgit says
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 says
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 says
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 says
ok, so which cpt plugin do you recommend?
Editorial Staff says
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.
Admin
Muhammad Waqas says
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..