WordPress Custom Post Types Debate - Functions.php oder Plugins?

Wie viele von Ihnen wissen, war Syed Balkhi letzte Woche beim WordCamp Raleigh 2012 dabei. Während dieser Veranstaltung löste einer seiner Tweets eine ziemliche Debatte aus. In diesem Artikel wird unser Gründer Syed Balkhi debattieren, ob benutzerdefinierte PostPress-Typen in der Datei functions.php oder in Plugins enthalten sind. Hier 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 - wpbeg.in/vcXr7j #wcraleigh

- WordPress-Anfänger (@wpbeginner) 4. November 2012

Nach dem Tweet stimmten viele seriöse Leute in der WordPress-Community mit. Sie können die vollständige Konversation hier sehen. Curtis McHale ging noch einen Schritt weiter und erläuterte das Thema in seinem neuen Blogpost.

Das Gespräch von Twitter brachte einige großartige Punkte.

Zusammenfassung der Argumente

Plugins-Argument: Der Benutzer hat die Daten immer, auch wenn er das Thema ändert. Es sieht vielleicht nicht so hübsch aus, aber es wird dort bleiben.

Functions.php Argument: Daten ohne Design wären irrelevant. Es wird Benutzer noch mehr verwirren.

Mit welcher Seite stimmst du mehr überein? Offensichtlich haben beide Seiten ihre Probleme, aber das ist das kleinere von zwei Übeln?

Deshalb glauben wir, dass Custom Post Types dies tun sollten IMMER Live in einem Site-spezifischen Plugin oder einem separaten Plugin zusammen.

Lang lebe Daten

Benutzerdefinierte Beitragstypen sind Daten. In den meisten Fällen überleben Ihre Daten das aktuelle Design. Nachdem wir unsere Themen ein paar Mal geändert haben, verstehen wir diese Aussage klar. Posts, Seiten, Links, Anhänge und Revisionen sind alle Arten von Posts, die in WordPress integriert sind. Darüber hinaus gibt es Posttypen wie Bücher, Testimonials, Deals usw. Jetzt können Sie sich vorstellen, dass wir ein Thema ändern und all diese verschwinden lassen? Das wollen wir bestimmt nicht.

Mit Entwicklern in unserem Team sollte das nicht viel ausmachen. In Anbetracht der Tatsache, dass alle unsere Themen von unserem Team individuell entworfen wurden, welchen Unterschied macht es dann wirklich? Das Geheimnis liegt in zwei Worten: Zeit und Zentralisierung. Solange wir über alle erforderlichen Daten verfügen, müssen wir in Zukunft nur noch das Styling ändern. Wir müssen uns nicht jedes Mal um das Kopieren und Einfügen der Funktionen von einer Datei in eine andere kümmern. Was ist, wenn Sie die Funktionalität replizieren möchten? Nehmen Sie einfach das Plugin und legen Sie es in Ihre neue Site. Ändern Sie das Styling und Sie sind fertig.

Regeln und Standards

Wenn Sie das Wort IMMER wie in unserem Tweet verwenden, kann dies sowohl Regeln als auch Standards bedeuten. Sowohl Regeln als auch Standards sind für die Mehrheit gemacht. Es wird immer Sonderfälle geben, in denen Regeln festgelegt und Standards verletzt werden. Das bedeutet jedoch nicht, dass wir die Standards vollständig loswerden sollten.

Es gibt unzählige generische Post-Typen, für die meist derselbe Satz zusätzlicher Meta-Felder erforderlich ist. Einige Beispiele, die mir in den Sinn kommen, wären: Zitate, Bücher, Rezepte, Testimonials, Portfolio usw.

In Anbetracht der großen Anzahl von Fotografie- und Portfolio-Themen, die auf dem freien und kommerziellen Markt verfügbar sind, macht es fast keinen Sinn, den Benutzer jedes Mal, wenn er ein Thema ändert, alle seine benutzerdefinierten Post-Typ-Informationen erneut einzugeben. Schauen wir uns ein Beispielszenario an:

Fotograf - Der Benutzer kann ein WordPress einrichten, das über eine Blog-Funktionalität verfügt (standardmäßig CPT "post"). Er möchte ein Portfolio seiner Arbeit hinzufügen (erfordert ein Portfolio-CPT). Er möchte Kundenberichte zeigen (erfordert ein CPT-Testimonial). All diese Informationen werden sicherlich an einem Themendesign vorbeigehen. Ein Jahr später möchte der Benutzer das Erscheinungsbild seiner Website ändern und eine Aktualisierung durchführen. Sucht ein neues Thema, das alle ähnlichen Funktionen hat. In dem Moment, in dem er das Thema wechselt, ist BOOM. Alle vorherigen Daten, die er eingegeben hat, sind verschwunden. Es gibt ein Menü mit dem Namen Portfolio und ein Menü mit dem Namen Testimonials. Es sind jedoch keine Daten vorhanden. Der Benutzer denkt "HOLY CRAP, ich habe alle meine Inhalte verloren". Erstellt eine neue Supportfrage im Forum. Sendet E-Mails an Sites wie WPBeginner usw. Wenn keine gute Antwort erhalten wird, müssen sie alle Daten erneut eingeben. Dies ist eine beschissene Benutzererfahrung.

Wie lösen wir dieses Problem??

Mögliche Lösung?

Wir schaffen eine neue Standardbasis. Justin Tadlock hat bereits vor einiger Zeit mit der Arbeit an diesem Problem begonnen, indem er ein Basis-Portfolio-Plugin erstellt hat. Wird es für jeden die perfekte Lösung 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 Post-Meta). Diese Art von Konversation muss unter Entwicklern stattfinden, die ähnliche Funktionen in ihren Designs erstellen. Warum sollten Sie immer dasselbe von einem Thema in ein anderes kopieren und einfügen, wenn dies über ein Plugin möglich ist? Sobald es sich zu einem Standard entwickelt hat, werden sich andere Autoren daran anpassen.

Beispielsweise sehen wir eine zunehmende 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 Funktionen ausgestattet sind, von denen wir glauben, dass sie Plugins sein sollten. Job-Board-Themen, Issue-Tracking-Themen, Kleinanzeigen-Themen, Real Estate-Themen usw. Sie sollten alle über ein Basis-Plugin bereitgestellt werden. Bei WooCommerce ist dies bereits geschehen. WooThemes hat zahlreiche Designs veröffentlicht, die eine integrierte Unterstützung für das Plugin enthalten. Andere Themenunternehmen haben versprochen, auch WooCommerce-basierte E-Commerce-Themen zu veröffentlichen. Sie können von einem Thema zum anderen wechseln und alle Ihre Produkte so belassen, wie sie sind. Das ist fast so, als ob sich das Thema geändert hätte, aber alles passte genau richtig. Das ist das Thema, bei dem wir Erfahrung suchen.

Warum machen Sie nicht dasselbe mit Portfolio, Testimonials und anderen generischen benutzerdefinierten Beitragstypen? Ist es deshalb so, weil es zu einfach ist gegen E-Commerce ist eine größere Bestie, die es zu überwinden gilt? E-Commerce hat eindeutig zu viele Felder im Vergleich zu den anderen, daher dürfte es für diese generischen Post-Typen viel einfacher sein. Es geht nur darum, sich bewusst dafür einzusetzen, die Dinge besser zu machen.

Schauen Sie sich das ReciPress-Plugin an. Es erstellt eine benutzerdefinierte Metabox mit Rezeptfeldern und hängt sie mit Beiträgen an. Es ist jedoch möglich, es mit benutzerdefinierten Posttypen anzufügen. Jeder, der dieses Plugin verwendet, kann Themen ändern, ohne sich umständlich damit auskennen zu müssen.

Es wäre schön zu sehen, wie Themen wie AgentPress von einem zentralen Basis-Plugin angetrieben werden. Es wäre schön zu sehen, dass der Übergang von wechselnden Themen einfacher wird. Wenn ein Benutzer beispielsweise von einem Fotografie-Thema zu einem anderen wechselt, sollte dies kein Chaos sein. Kleinere Fehler können auftreten, aber zumindest im Großen und Ganzen werden die Dinge funktionieren.

Sie können immer Beispiele für besonders angepasste Posttypen angeben, die für die einmalige Clientnutzung erstellt wurden. Dies ist jedoch die Ausnahme, nicht die Regel.

Was denkst du über dieses Thema? Wo sollte sich der Code für benutzerdefinierte Posttypen befinden? In der Datei functions.php oder in Plugins?