WordPress Custom Post Types Debatte: Functions.php oder Plugins?

 

Wie viele von Ihnen wissen, hat Syed Balkhi letzte Woche das WordCamp Raleigh 2012 besucht. Während der Veranstaltung löste einer seiner Tweets viele Diskussionen aus. In diesem Artikel wird unser Gründer Syed Balkhi diskutieren, ob benutzerdefinierte WordPress-Beitragstypen zur Datei functions.php oder zu Plugins gehören. Unten ist ein Tweet, der diese Diskussion gestartet hat:

Fügen Sie keine benutzerdefinierten Beitragstypen in functions.php hinzu -> Sie sollten IMMER ein ortsspezifisches Plugin verwenden: wpbeg.in/vcXr7j #wcraleigh

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

Nach dem Tweet mischten sich viele seriöse Leute in der WordPress-Community ein. Sie können das vollständige Gespräch hier sehen. Curtis McHale ging noch einen Schritt weiter und ging in seinem neuen Blog-Beitrag auf das Thema ein.

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

Zusammenfassung der Argumente

Plugins Argument: Der Benutzer hat immer die Daten, auch wenn er das Thema wechselt. Es mag nicht so hübsch aussehen, aber es wird dort bleiben.

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

Mit welcher Seite stimmen Sie am meisten überein? Natürlich haben beide Parteien ihre Probleme, aber was ist das geringere der beiden Übel?

Aus diesem Grund denken wir, dass benutzerdefinierte Beitragstypen dies tun sollten FÜR IMMER leben in einem ortsspezifischen Plugin oder in einem Plugin vollständig.

 

Es lebe die Daten

Benutzerdefinierte Beitragstypen sind Daten. In den meisten Fällen überleben Ihre Daten das aktuelle Design. Nachdem wir unsere Themen mehrmals geändert haben, verstehen wir diese Aussage klar. Beiträge, Seiten, Links, Anhänge und Rezensionen sind alle Arten von Beiträgen, die mit WordPress geliefert werden. Außerdem haben wir Arten von Posts wie Bücher, Testimonials, Angebote usw. Können Sie sich vorstellen, ob wir ein Thema wechseln und verschwinden? Sicher wollen wir nicht, dass das passiert.

Mit Entwicklern in unserem Team sollte dies nicht viel ausmachen. Welchen Unterschied macht es wirklich, wenn man bedenkt, dass alle unsere Themen von unserem Team individuell gestaltet wurden? Das Geheimnis liegt in zwei Worten: Zeit und Zentralisierung. Solange wir über alle erforderlichen Daten verfügen, müssen wir in Zukunft nur noch den Stil ändern. Wir müssen uns nicht jedes Mal um das Kopieren und Einfügen von 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 auf Ihrer neuen Website ab. Ändern Sie den Stil und voila.

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 Vorschriften gelten für die Mehrheit. Es wird immer Sonderfallszenarien geben, in denen die Regeln verbogen und die Standards gebrochen werden, aber das bedeutet nicht, dass wir die Standards vollständig loswerden sollten.

Es gibt Unmengen von generischen Post-Typen, für die meist derselbe Satz zusätzlicher Metafelder erforderlich ist. Einige Beispiele, die mir in den Sinn kommen, sind: Zitate, Bücher, Rezepte, Testimonials, Portfolio usw.

Angesichts der großen Anzahl von Fotografie- und Portfolio-Themen, die auf dem freien und kommerziellen Markt verfügbar sind, macht es fast keinen Sinn, dass der Benutzer jedes Mal, wenn sich ein Thema ändert, alle benutzerdefinierten Post-Typ-Informationen erneut eingibt. Schauen wir uns einen Beispielfall an:

Fotograf – Der Benutzer hat ein WordPress konfiguriert, das über eine Blog-Funktionalität verfügt (CPT “Post” -Standard). Sie möchten ein Portfolio Ihrer Arbeit hinzufügen (erfordert ein CPT-Portfolio). Sie möchten Kundenreferenzen anzeigen (erfordert ein CPT-Testimonial). 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 aktualisieren. Suchen Sie ein neues Thema mit allen ähnlichen Funktionen. In dem Moment, in dem sich das Thema ändert, BOOM. Alle zuvor eingegebenen Daten sind verschwunden. Es gibt ein Menü namens Portfolio und ein Menü namens Testimonials. Es sind jedoch keine Daten vorhanden. Der Benutzer denkt “HEILIGE SCHEISSE, ich habe alle meine Inhalte verloren.” Erstellen Sie neue Support-Fragen im Forum. Senden Sie E-Mails an Websites wie WPBeginner usw. Wenn sie keine gute Antwort erhalten, müssen sie alle Daten erneut eingeben. Dies ist eine schreckliche Benutzererfahrung.

Wie lösen wir dieses Problem?

Mögliche Lösung?

Wir schaffen eine neue Standardbasis. Justin Tadlock hat bereits vor einiger Zeit begonnen, an diesem Problem zu arbeiten, indem er ein Basis-Wallet-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 im Portfolio-Plugin enthalten sein sollen (in Bezug auf das Meta-Meta). Diese Art von Konversation sollte zwischen Entwicklern stattfinden, die ähnliche Funktionen in ihren Themen erstellen. Warum immer wieder dasselbe kopieren und von einem Thema zum anderen einfügen, wenn dies über ein Plugin möglich ist? Sobald es zum Standard wird, werden andere Themenautoren 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 Funktionen ausgestattet sind, von denen wir glauben, dass sie Plugins sein sollten. Themen der Jobbörse, Themen zur Problemverfolgung, Themen zu Kleinanzeigen, Immobilienthemen usw. Alle sollten mit einem Basis-Plugin funktionieren. Es passiert bereits mit WooCommerce. WooThemes hat zahlreiche Themen veröffentlicht, die eine integrierte Styling-Unterstützung für das Plugin bieten. Andere Themenunternehmen haben ebenfalls versprochen, WooCommerce-basierte E-Commerce-Themen zu starten. Sie können von einem Thema zum anderen wechseln und alle Ihre Produkte unverändert lassen. Es ist fast so, als hätte sich das Thema geändert, aber alles passte einfach zusammen. Das ist die Erfahrung des Subjektwechsels, nach der wir streben müssen.

Warum nicht dasselbe für Portfolio, Testimonials und andere Arten von benutzerdefinierten generischen Posts tun? Ist es, weil es zu einfach ist vs. E-Commerce ist ein größeres Tier zu erobern? Offensichtlich hat E-Commerce im Vergleich zu den anderen zu viele Felder, so dass es für diese generischen Beitragstypen viel einfacher sein sollte. Es geht nur darum, sich bewusst darum zu bemühen, Dinge zu verbessern.

Schauen Sie sich das ReciPress-Plugin an. Erstellen Sie eine benutzerdefinierte Metabox mit Rezeptfeldern und fügen Sie sie Posts hinzu. Es ist jedoch möglich, es mit benutzerdefinierten Beitragstypen anzuhängen. Jeder, der dieses Plugin verwendet, kann Themen ändern, ohne den ganzen Aufwand zu durchlaufen.

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

Sie können jederzeit Beispiele für benutzerdefinierte Beitragstypen angeben, die für eine einmalige Verwendung durch Kunden erstellt wurden. Dies ist jedoch die Ausnahme und nicht die Regel.

Was haltet ihr von diesem Thema? Wo sollte sich der Code für benutzerdefinierte Beitragstypen befinden? In der Datei functions.php oder in Plugins?

%d bloggers like this: