Wie viele von Ihnen wissen, hat Syed Balkhi letzte Woche an WordCamp Raleigh 2012 teilgenommen. Während der Veranstaltung löste einer seiner Tweets eine ziemliche Debatte aus. In diesem Artikel wird unser Gründer Syed Balkhi darüber diskutieren, ob WordPress Custom Post Types in die functions.php-Datei oder in Plugins gehören. Unten ist ein Tweet, der diese Debatte ausgelöst hat:
Fügen Sie keine benutzerdefinierten Beitragstypen in functions.php hinzu -> Sie sollten IMMER ein standortspezifisches Plugin verwenden – http://t.co/bebYXq2F #wcraleigh
— WordPress Anfänger (@wpbeginner) 4. November 2012
Nach dem Tweet meldeten sich viele angesehene Leute aus der WordPress-Community zu Wort. Sie können die vollständige Unterhaltung hier einsehen. Curtis McHale ging noch einen Schritt weiter und erläuterte das Thema in seinem neuen Blogbeitrag.
Die Konversation von Twitter brachte einige großartige Punkte hervor.
Zusammenfassung der Argumente
Plugin-Argument: Der Benutzer hat die Daten immer, auch wenn er das Theme wechselt. Es sieht vielleicht nicht so schön aus, aber es bleibt erhalten.
Argument für Functions.php: Daten ohne Design wären irrelevant. Es wird die Benutzer noch mehr verwirren.
Welcher Seite stimmen Sie mehr zu? Beide Seiten haben offensichtlich ihre Probleme, aber welche ist das kleinere Übel?
Hier ist der Grund, warum wir glauben, dass Custom Post Types IMMER in einem standortspezifischen Plugin oder einem separaten Plugin leben sollten.
Es lebe die Daten
Benutzerdefinierte Post-Typen sind Daten. In den meisten Fällen werden Ihre Daten das aktuelle Design überdauern. Nachdem wir unsere Themes ein paar Mal geändert haben, verstehen wir diese Aussage klar. Beiträge, Seiten, Links, Anhänge und Revisionen sind alles Arten von Post-Typen, die mit WordPress integriert sind. Darüber hinaus haben wir Post-Typen wie Bücher, Testimonials, Angebote usw. Können Sie sich jetzt vorstellen, wenn wir ein Theme ändern und all diese verschwinden?
Da wir Entwickler in unserem Team haben, sollte das nicht viel ausmachen. Wenn man bedenkt, dass alle unsere Themes von unserem Team individuell gestaltet werden, was macht das wirklich 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 keine Sorgen machen, die Funktionen jedes Mal von einer Datei in eine andere zu kopieren und einzufügen. 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 Regel als auch Standard bedeuten. Sowohl Regeln als auch Standards werden für die Mehrheit gemacht. Es wird immer Sonderszenarien geben, in denen Regeln gebogen und Standards gebrochen werden, aber das bedeutet nicht, dass wir Standards ganz abschaffen sollten.
Es gibt unzählige generische Beitragstypen, die meistens die gleiche Reihe zusätzlicher Metadatenfelder erfordern. Einige Beispiele, die mir einfallen, wären: Zitate, Bücher, Rezepte, Testimonials, Portfolio usw.
Angesichts der großen Anzahl von Fotografie- und Portfolio-Themes, die auf dem kostenlosen und kommerziellen Markt erhältlich sind, ergibt es fast keinen Sinn, den Benutzer jedes Mal, wenn er das Theme wechselt, alle seine benutzerdefinierten Post-Typ-Informationen neu eingeben zu lassen. Betrachten wir ein Beispiel-Szenario:
Fotograf – Der Benutzer richtet ein WordPress ein, das eine Blog-Funktionalität hat (Standard „post“ CPT). Er möchte ein Portfolio seiner Arbeiten hinzufügen (erfordert ein Portfolio CPT). Er möchte Kundenreferenzen anzeigen (erfordert ein Testimonial CPT). All diese Informationen werden sicherlich ein Theme-Design überdauern. Ein Jahr später möchte der Benutzer das Aussehen seiner Website ändern und ihr ein neues Aussehen geben. Findet ein neues Theme, das alle ähnlichen Funktionen hat. In dem Moment, in dem er das Theme wechselt, BOOM. Alle zuvor eingegebenen Daten sind verschwunden. Es gibt ein Menü namens Portfolio und ein Menü namens Testimonials, aber keine der Daten ist vorhanden. Der Benutzer denkt: „HEILIGER BLAUER DUNST, ich habe meinen gesamten Inhalt verloren“. Erstellt eine neue Support-Frage im Forum. Sendet E-Mails an Seiten wie WPBeginner usw. Wenn sie keine gute Antwort erhalten, müssen sie alle Daten neu eingeben. Das ist eine beschissene Benutzererfahrung.
Wie lösen wir also dieses Problem?
Mögliche Lösung?
Wir schaffen einen neuen Standard-Basis. Justin Tadlock hat bereits vor einiger Zeit mit der Arbeit an diesem Problem begonnen, indem er ein Portfolio-Basis-Plugin erstellt hat. Wird es die perfekte Lösung für alle sein? NEIN, aber für die Mehrheit.
Wie Justin in seinem Beitrag fragt, welche Standardfelder in das Portfolio-Plugin (bezogen auf Post-Metadaten) aufgenommen werden sollten. Diese Art von Konversation muss unter Entwicklern stattfinden, die ähnliche Funktionalitäten in ihren Themes erstellen. Warum sollte man immer wieder dasselbe von einem Theme zum anderen kopieren und einfügen, wenn es über ein Plugin erfolgen kann? Sobald es zum Standard wird, werden andere Theme-Autoren beginnen, sich daran anzupassen.
Zum Beispiel sehen wir eine Zunahme der Stilunterstü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 Funktionalitäten geliefert werden, die unserer Meinung nach Plugins sein sollten. Job Board Themes, Issue Tracking Themes, Classified Ads Themes, Real Estate Themes usw. Sie sollten alle von einem Basis-Plugin angetrieben werden. Das passiert bereits mit WooCommerce. WooThemes hat zahlreiche Themes veröffentlicht, die eine integrierte Stilunterstützung für das Plugin haben. Andere Theme-Unternehmen haben versprochen, auch WooCommerce-basierte E-Commerce-Themes zu veröffentlichen. Sie können von einem Theme zu einem anderen wechseln und alle Ihre Produkte so belassen, wie sie sind. Das ist fast so, als ob das Theme geändert wurde, aber alles ist perfekt an seinen Platz gefallen. Das ist die Theme-Wechselerfahrung, nach der wir streben müssen.
Warum nicht dasselbe mit Portfolio, Testimonials und anderen generischen benutzerdefinierten Post-Typen machen? Liegt es daran, dass es zu einfach ist im Vergleich zu E-Commerce, das ein größeres Problem darstellt? Offensichtlich hat E-Commerce viel zu viele Felder im Vergleich zu den anderen, daher sollte es für diese generischen Post-Typen viel einfacher sein. Es ist nur eine Frage der bewussten Anstrengung, Dinge besser zu machen.
Schauen Sie sich ReciPress plugin an. Es erstellt eine benutzerdefinierte Metabox mit Rezeptfeldern und hängt sie an Beiträge an. Es ist jedoch möglich, sie an benutzerdefinierte Post-Typen anzuhängen. Jeder, der dieses Plugin verwendet, kann Themes wechseln, ohne sich mit solch einem Aufwand auseinandersetzen zu müssen.
Es wäre schön zu sehen, dass Themes wie AgentPress von einem zentralisierten Basis-Plugin angetrieben werden. Es wäre großartig, den Übergang beim Wechseln von Themes zu erleichtern. Wenn ein Benutzer beispielsweise von einem Fotografie-Theme zu einem anderen wechselt, sollte dies kein Chaos sein. Kleinere Fehler können auftreten, aber zumindest im Großen und Ganzen wird es funktionieren.
Sie können immer Beispiele für stark angepasste Post-Typen anführen, die für die einmalige Nutzung durch Kunden erstellt wurden, aber das ist die Ausnahme, nicht die Regel.
Was denkt ihr über dieses Thema? Wo sollten die Custom Post Types Codes liegen? In der functions.php-Datei oder in Plugins?
Yazmin
Da ich schon mehrmals meine CPTs verloren habe, als ich Themes gewechselt habe, finde ich es frustrierend, die gleiche Funktionalität immer wieder in functions.php einrichten zu müssen.
Ich bevorzuge die Plugin-Route vollständig und das ist die Methode, die ich von nun an auch für meine Geschäftsprojekte verwenden werde.
Joshua Jarvis
Habe genau dieses Problem mit einem Immobilien-Theme. Die „Listings“ waren alles benutzerdefinierte Typen in einem Theme, das jetzt funktional veraltet ist. Als ich das Theme aktualisieren wollte, verlor ich alle benutzerdefinierten Post-Inhalte, jetzt muss ich einen Weg finden, alles zu übertragen. Ich habe Optionen, aber wenn es ein Plugin wäre, wäre das nicht nötig.
Redaktion
Es tut uns außerordentlich leid wegen Ihrer Unannehmlichkeiten. Deshalb haben wir diesen Beitrag geschrieben, weil wir wissen, dass er das Leben des Endbenutzers wirklich erschwert.
Admin
Hugh H. Sands
„Wir müssen uns keine Sorgen mehr machen, die Funktionen jedes Mal von einer Datei in eine andere kopieren und einfügen zu müssen.“
Ich kann mir nicht vorstellen, dass jemand Code für ein CPT in functions.php schreibt, wenn es so einfach ist, ihn mit Includes zu isolieren.
Diese Debatte dreht sich meistens um Daten vs. Design und ich frage mich, da ich neu bei WP bin, was ist mit der Leistung? Belasten Plugins irgendwelche Überlastung?
Redaktion
Dieser Artikel sollte Ihre Frage zu Plugins und Leistung beantworten:
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Danke für den Link, sehr hilfreich!
Kelvin Alfonso
Ich habe CPTs immer über eine separate Datei in die functions.php aufgenommen, aber ich glaube, ich werde auf die Plugin-Route umsteigen. Danke!
Sudhakar
Ich bin Anfänger und habe keine Expertise, um mich zugunsten oder gegen ein Plugin oder functions.php zu äußern. Aber ich frage mich, wenn ich den functions.php-Weg gehen und es unter einem Child-Theme machen möchte, was ist dann das Problem? Warum muss ich es in einem Plugin haben, würde mein Child-Theme mich nicht vor zukünftigen Theme-Upgrades und Änderungen an den Themes retten?
Redaktion
Ihr Child-Theme würde Sie vor zukünftigen Theme-Updates bewahren. Es wird Sie jedoch NICHT retten, wenn Sie Ihre Themes ändern. Denn Sie ändern das Child-Theme, wenn Sie das aktive Theme ändern.
Admin
Pat Ramsey
Ich bin ein Verfechter des Plugin-Ansatzes für benutzerdefinierte Beitragstypen und Taxonomien. Die Erwähnung eines sitespezifischen Plugins durch den Autor ist, wie ich es mache. Ich platziere alle benutzerdefinierten Beitragstypen, benutzerdefinierten Taxonomien und Metaboxen in diesem Plugin, das auf den Zweck der Website zugeschnitten ist. Irgendwann wird sich das Theme der Website ändern, aber die Daten bleiben erhalten und sind immer noch leicht zugänglich.
shawn
Wenn Entwickler weiterhin die Tatsache ignorieren, dass die Trennung von „Daten“ von „Design“ notwendig ist, um modulare Apps zu erstellen, und es keine Rolle spielt, wo die Daten platziert sind, wird die Wiederverwendung dieser Daten / dieses Codes immer ein Problem sein.
Es scheint in der WP-Community aus dem einen oder anderen Grund die Wahrnehmung zu geben, dass man Daten im WordPress-Ökosystem nur dann abrufen kann, wenn sie in ein Plugin verpackt sind, weshalb wir immer wieder Diskussionen wie diese sehen, die zu „Der große Plugin vs. Theme-Debatte“ beitragen.
Der Fokus muss auf der Weiterentwicklung des archaischen WordPress-Plugin-Systems liegen, hin zur Schaffung von Bibliotheken, die auf modularen Designmustern basieren, die Code / Daten von Design trennen. Bibliotheken, die sowohl in Themes als auch in Plugins verwendet werden können...
Debatten wie diese sind im PHP4-Zeitalter von WP sinnlos!!! (Repost)
Mark Simchock
Re: „Wie Justin in seinem Beitrag fragt, welche Standardfelder sollten im Portfolio-Plugin enthalten sein (bezogen auf Post-Meta). Diese Art von Gespräch muss unter Entwicklern stattfinden, die ähnliche Funktionalitäten in ihren Themes erstellen.“
Ich? Ich würde ein gut dokumentiertes Plugin bevorzugen, das so entwickelt wurde, dass es erweitert werden kann, anstatt einen „geschlossenen“, universellen Ansatz, der schwer zu handhaben ist (dieser Code).
Mein Punkt ist, vielleicht kann man sagen: „Ich versuche nicht, für jeden alles zu sein. Hier ist mein Basis-Plugin. Hier ist, wie man es aufpeppt. Es ist so konzipiert, dass es aufgemotzt werden kann.“ und es dabei belassen. Egal, was Sie tun, es ist schwierig, jeden Anwendungsfall, jedes Bedürfnis vorherzusehen. Warum also die Mühe machen? Warum nicht als eine Art Framework angehen und den Entwickler, der es braucht, einfach anpassen lassen?
Justin Tadlock
Das ist eigentlich der Plan. Ich baue eine extrem kleine und leicht anpassbare Basis. Aber ich würde gerne wissen, welche Felder Standard sein sollten, falls überhaupt.
Kevin Maines
Tippfehler?:
„In Anbetracht dessen, dass alle unsere Teams von unserem Team individuell gestaltet werden“
Redaktion
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Ich glaube, es sollte im Plugin sein.
Falls der Benutzer die Daten in Zukunft nicht mehr benötigt, kann er den benutzerdefinierten Beitragstyp jederzeit in den "normalen" Beitragstyp umwandeln. Es gibt Plugins, die das ermöglichen, suchen Sie im Repository und Sie werden mindestens eines finden.
Christophe Debruel
Es ist mir eigentlich egal, was die Leute sagen. Benutzerdefinierte Beitragstypen gehören in ein Plugin. Ein Theme kann leicht modifiziert werden, um den benutzerdefinierten Beitragstyp im Frontend anzupassen. Ich finde es logischer, das Theme für den CTP zu gestalten, als verschiedene Themes mit demselben CTP-Code zu haben.
Ingo
„Pods Framework“ könnte auch eine gute Plugin-Lösung sein. Für CPT, CT und CF.
http://wordpress.org/extend/plugins/pods/
Redaktion
Ja, Pods ist großartig.
Admin
Elliott Richmond
Plugin für mich. Zumindest für einen nicht-technischen Kunden, auch wenn das Theme möglicherweise nicht richtig funktioniert, wird deutlich, dass ein Problem besteht und dies ihn dazu veranlasst, einen Entwickler einzuschalten.
Kailas Mahajan
Es hängt alles vom Projekt ab…
Wenn man ein Projekt bearbeitet, das nach einer bestimmten Zeit das Thema ändern muss…kann man ein Plugin verwenden.
oder wenn Projekte, die bei einem Theme bleiben.. können mit function.php gehen
Ross W
Alle reden darüber, wie die Daten vom Theme gestylt werden müssen, und Beispiele, wo das der Fall ist und wo Daten und Theme getrennt werden können.
Was ich nicht sehe, ist, dass jemand über Fälle spricht, in denen ein Theme davon abhängt, dass bestimmte Daten verfügbar sind. Nehmen wir an, Sie haben ein Theme, das eine Karte von Ländern und einige länderspezifische Daten enthält, und dass das Theme ohne diese Karte und Daten einige seiner Kernfunktionen verliert.
Ja, das könnte man auch mit den Daten in einem Plugin machen, aber ist es zumutbar, dass ein Theme davon ausgeht, dass bestimmte Daten vorhanden sind? Ist es zumutbar, davon auszugehen, dass das Plugin, das die Datentypen erstellt, installiert und aktiviert ist? (Ehrliche Fragen…diskutieren!)
Was ist, wenn mein leicht nicht-technischer Kunde eine Kopie der Website mit seinem 'Theme' erstellen möchte? Sie aktivieren das Theme bei einer neuen WordPress-Installation und stellen fest, dass eine ganze Menge Zeug fehlt oder kaputt ist? Sie dachten, das Theme enthielte alles, was sie für das Aussehen ihrer Website benötigen?
Ich sehe Verwendungsmöglichkeiten für beide Ansätze. Für die meisten meiner Kundenarbeiten richte ich CPTs, Metaboxen und einige Funktionen ein, um den Zugriff darauf zu vereinfachen, in Bibliotheksdateien und binde sie ein. Dies hält all den 'Kram', den mein Theme zum Funktionieren benötigt, in einem Paket, aber es ist einfach, die CPTs in ein neues Theme zu verschieben, wenn ich möchte.
Natürlich, wenn ein CPT so aussieht, als könnte er in mehreren Themes verwendet werden und nicht SO spezifisch ist, dass er nur für die Daten eines einzelnen Kunden gilt, dann verwandeln Sie ihn in ein Plugin, das nach Belieben bereitgestellt werden kann.
Ich glaube nicht, dass es eine einfache, eindeutige Beziehung zwischen Daten und Themen gibt. Es ist nicht immer so, dass 'ich habe einige Daten, die gestylt werden müssen' ... manchmal 'mein Styling braucht einige Daten'.
Gedanken dazu?
Andres Hermosilla
Ich stimme definitiv zu, dass ein „komplettes“ Paket von Vorteil ist. Oft gibt es sehr themenspezifische Funktionalitäten, die besser direkt integriert sind (z. B. P2 von Auttomatic) als ein installiertes Theme und ein Theme-Plugin.
Konstantin Kovshenin
Plugins. Punkt.
Curtis McHale
Ihr Verweis auf AgentPress ist einer der Gründe, warum ich zu 100 % für CPTs in Plugins bin. Ich hatte es mit solchen Themes zu tun und es ist so schwer, sie richtig zu gestalten, es sei denn, man entfernt die benutzerdefinierte Funktion aus dem Theme. Mein Kunde und ich haben 20 Stunden damit verbracht, den Code so weit zu bringen, dass wir tatsächlich damit arbeiten konnten.
Birgit
Meine beste und bevorzugte, empfohlene Lösung ist das hochflexible TOOLBOX: http://wordpress.org/extend/plugins/toolbox/
Redaktion
Gute Idee. Ich wünschte, ich könnte verstehen, was der Screenshot zeigt, ohne das Plugin herunterzuladen.
-Syed
Admin
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
Vielleicht hilft Ihnen das beim Lesen: http://tinyurl.com/bf5dflt
Redaktion
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
Ich bevorzuge immer Plugins gegenüber functions.php für alles, was das Frontend erheblich „beschädigen“ würde oder Daten verloren gehen, wenn das Theme geändert würde. Das liegt genau an den von Ihnen genannten Gründen, und ich finde es auch verrückt für diejenigen von uns, die keine echten PHP-Programmierer sind, Konflikte zu beheben, wenn man Dinge in functions.php auskommentieren muss, um ein Problem zu isolieren.
matt
ok, welches CPT-Plugin empfehlen Sie?
Redaktion
Die Idee ist, dass Sie CPTs in einem seitenspezifischen Plugin registrieren sollten. Es gibt noch kein spezifisches Plugin dafür. Aber das ist nur das Herumwerfen der Idee, ein Basis-Plugin für generische Post-Typen zu erstellen.
Admin
Muhammad Waqas
Ich bin mehr von der Verwendung lokaler Funktionen überzeugt, aber in diesem Fall denke ich, dass Plugins mehr Vertrauen verdient haben. Wenn Sie zum Beispiel mit einem bestimmten Framework mit WordPress beginnen. In den meisten Fällen werden Sie wahrscheinlich lange Zeit ein Sklave sein, es sei denn, Sie stellen einen WordPress-Experten ein, der Ihnen hilft, aus diesem Framework zu entkommen, ohne Ihre Einstellungen und Daten zu verlieren. Andererseits können Plugins bei fast jedem Theme funktionieren.
Als ich mit WP zu arbeiten begann, bevorzugte ich Frameworks gegenüber Plugins. Die Realität ist, dass Plugin-Entwickler bei der Entwicklung von etwas an Anfänger und weniger gebildete Leute denken. Ich persönlich glaube, dass die meisten WP-Benutzer manuelle Code-Hacks bevorzugen, anstatt sich für Kernfunktionen von Websites auf Plugins zu verlassen. Langfristig sind Plugins nicht zuverlässig. Das empfinde ich so..