Methoden zur Integration von Plugin-Daten in Themes


17

Ich möchte einige Meinungen zu den Best Practices für die Entwicklung von WordPress-Plugins erhalten, die eine Theme-Integration ermöglichen.

Lassen Sie mich mit einem hypothetischen Beispiel eines Szenarios beginnen, auf das ich neugierig bin, damit ich bei der Beantwortung dieser Frage einen Sinn habe. Stellen Sie sich vor, ich erstelle ein Plugin namens "Discography". Discography registriert drei benutzerdefinierte Post-Typen: "Bands", "Albums" und "Tracks". Das Plugin bietet auch Meta-Felder mit Details zu den einzelnen Beitragstypen sowie benutzerdefinierte Taxonomien zum Organisieren der einzelnen Beitragstypen. Diese Beitragstypen sind mit dem Plugin " Beiträge 2 Beiträge" verknüpft. Innerhalb des Administrators kann der Benutzer neue Bands hinzufügen, die Alben zugeordnet werden können, die wiederum Tracks zugeordnet sind, denen über Meta-Boxen und Taxonomien viele andere Daten hinzugefügt werden.

Ich möchte, dass es einige Standardanzeigen für die Daten bereitstellt. Ein fortgeschrittener Benutzer / Entwickler hätte nur diesen Administrator. Es würde ihr leicht fallen, diese Daten zu erfassen und im Thema zu verwenden. Ohne einige Standardansichten wäre dieses Plugin jedoch für die meisten Benutzer nutzlos. In diesem Beispiel können Sie Folgendes anzeigen (Klammern geben an, wie die Informationen in der Reihenfolge der Vorlagenhierarchie angezeigt werden können):

  • Bands (single-prefix-band.php, single.php, index.php, shortcode)
  • Alben (single-prefix-album.php, single.php, index.php, shortcode)
  • Tracks (Single-Prefix-Track.php, Single.php, Index.php, Shortcode)
  • Bandliste (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Albumliste (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Album Timeline (Vorlage-Album-Timeline.php, Seite-Album-Timeline.php, Seite- {ID} .php, Seite.php, Index.php, Shortcode)

Es ist wichtig, dass es für diese Beitragstypen eine Standarddarstellung gibt, da in den Standardvorlagendateien nicht alle Informationen angezeigt werden, die für die einzelnen Beitragstypen erforderlich sind. Zum Beispiel zeigt das Twenty Eleven-Design standardmäßig nur den Namen, die Kategorien, die Beschreibung und das Veröffentlichungsdatum eines Albums an. Nicht sehr nützlich für ein Album. Ich möchte eine einzelne Post-Vorlage bereitstellen, die die Band, das Veröffentlichungsdatum, das Plattenlabel, die Albumversionen, die Tracks usw. berücksichtigt. Als Plug-in-Entwickler würde ich das für wichtig halten. Ich weiß, dass die Vorlage nicht für jedes Thema funktionieren würde, aber es sollte einige Standardeinstellungen geben, die weiter in das Thema des Benutzers integriert werden können.

Auch hier bin ich gespannt, wie ich mit dieser Situation am besten umgehen kann. Ich denke, Sie können Folgendes tun.

Shortcodes

Shortcodes können sehr flexibel und benutzerfreundlich eingesetzt werden, um es Nicht-Entwicklern zu ermöglichen, überall auf der Site Bands, Alben, Tracks, Bandlisten usw. hinzuzufügen. Es wäre hilfreich, Bands auf bestimmten Seiten zu präsentieren oder separate Seiten für jede Band zu erstellen (nicht sehr effizient, aber einige Benutzer gehen die Dinge auf diese Weise an). Der Shortcode würde HTML generieren, das an eine bereitgestellte CSS-Datei gebunden wäre, die eine schöne Standardansicht der gewünschten Daten liefern würde. Alles wäre in den Plugin-Dateien enthalten und es müsste nichts mit dem Theme gemacht werden.

Vorlagendateien

Das Plugin kann auch mit Vorlagendateien geliefert werden. Die Vorlagendateien können für eine schöne Standardansicht markiert und gestaltet werden. Sie können Ihrem Benutzer Anweisungen zum Verschieben der Dateien in den Themenordner geben, damit das Thema die richtigen Vorlagen findet, wenn die Beitragstypen angezeigt werden. Sie könnten sogar eine Schnittstelle bereitstellen, über die der Benutzer die Dateien mit einem einzigen Klick verschieben kann (Hinweis: Ich würde bei der Aktivierung keine Dateien im Themenordner des Benutzers erstellen, da das Hinzufügen von Dateien zu ihrem Thema ohne dessen Initiierung böse ist). .

Sie können diese Dateien auch mithilfe von Filtern verwenden, ohne sie aus dem Plug-in-Ordner zu verschieben, sodass alles in sich geschlossen bleibt. Ich habe die Filter "template_include" und "{$ type} _template" gesehen, die für diesen Zweck verwendet wurden. Tatsächlich können Sie Vorlagen aus dem Themenordner verwenden. Wenn diese nicht vorhanden sind, können Sie auf diese Filter zurückgreifen, um die Standardansichten bereitzustellen.

Die Frage

Ich würde gerne wissen, was andere für die besten Praktiken in diesen Situationen halten, wenn die vorgestellten Ideen in irgendeiner Weise problematisch sind und Alternativen, die ich nicht angegeben habe.

Vielen Dank!


3
Wenn nur alle Fragen zu WPSE so gut durchdacht wären ... :)
scribu

@scribu ... du sagst das nur, weil ich einen Link zu deinem Plugin eingefügt habe;) Im Ernst, danke für das Kompliment. Ich hatte Angst, dass dies eine dumme Frage wäre, aber es ist eine, die mich schon eine Weile plagt.
tollmanz

Ein weiteres +1 von mir. Lesen Sie für das "Warum" @scribu Kommentar.
Kaiser

@kaiser & scribu ... Ich hoffe, Sie beide denken über dieses Thema nach. Ich würde gerne hören, was Sie zu sagen haben.
tollmanz

@tollmanz Schon erledigt. Aber solch ein intensives Q braucht ein wenig Nachdenken und Zeit.
Kaiser

Antworten:


4

Ich kann nicht jedes einzelne Q beantworten, das Sie gefragt haben, da das Lesen des Q bisher genug Zeit in Anspruch genommen hat;), aber ich versuche Ihnen einige Einblicke in meine persönlichen Erfahrungen mit der Entwicklung von kostenlosen Open Source-Plugins zu geben.

1. Mach niemals zu viel. Features sind der Tod jedes Plugins. Erstellen Sie zuerst eine Basisversion und testen Sie die Reaktion Ihrer Benutzer. Wenn Ihrem Plugin viel Aufmerksamkeit geschenkt wird, können Sie die am häufigsten angeforderten Funktionen einbinden.

2. Vermeiden Sie es, jeden Anwendungsfall zu füllen. Sie müssen Ihr Plugin pflegen. WP bietet alle drei Monate eine neue Version an. Und manchmal ist es schwierig, all Ihren Plugins zu folgen. Ein Beispiel: Eine neue Version der Einstellungs-API wird derzeit in Trac behandelt. Wenn dies abgeschlossen ist, besteht die Möglichkeit, dass viele Plugin- oder Theme-Entwickler einen großen Teil des Codes ändern müssen und einige Leute - wie ich - sogar eine Abstraktionsebene über die API geschrieben haben. Sie müssen also zurückgehen, Ihre Basis- / Abstraktionsschicht neu schreiben und dann alles überarbeiten, was Teile davon aufruft. Ich verspreche, dass dies eine Menge Arbeit ist. Und noch mehr, wenn es eng an Ihren Code gebunden ist. Wenn Sie anfangen, viele Anwendungsfälle zu bearbeiten, haben Sie auch eine Menge von WP-Kerncode-Entwicklungen, die Sie überwachen müssen, und Sie müssen viel Arbeit leisten, um Ihren Code auf dem neuesten Stand zu halten.

3. Versuchen Sie niemals, viele Codebeispiele (oder Vorlagen) in Ihren Plugins oder Designs zu bündeln. Wenn Sie Entwickler und Endbenutzer ansprechen möchten : Verwenden Sie Ihr Blog zur Dokumentation. Entwickler hassen solche Dinge und Endbenutzer sind nie zufrieden (siehe: Füllen jedes Anwendungsfalls).

4. Teilen Sie Ihren Code mit Bedacht in einzelne Dateien auf. Faustregel: Eine Datei für ein Teil. Beispiel: styles.php, scripts.php, taxonomies.php, cpts.php usw. Lade alles aus einer "Mutter" -Klasse (Factory) und behalte deine Sachen "pluggable". Wenn Sie etwas umschreiben müssen, werden Sie es leicht finden. Wenn Entwickler nach etwas suchen, werden sie es leicht finden. Viele gut benannte Dateien, schaden Sie nicht.

5. Wenn Sie eine Liste der grundlegenden Stile (Klassen) erhalten haben, überlassen Sie dies dem Benutzer . Die Wahrscheinlichkeit ist einfach zu hoch, dass Stile aus dem Theme oder anderen Plugins Ihre Definitionen abfangen (unabhängig davon, wie viel Spezifität Sie einbringen). Versuchen Sie einfach, es irgendwo mit so wenig Text wie möglich zu erklären.

6. Liebe dein Plugin. Aber lass los, wenn dir langweilig ist. :)


Nun - in kurzen Worten - etwas über Ihre Plugin-Idee im Detail:

A. Vorlagendateien sind fehlerhaft. Wie gesagt: Dokumentiere es in deinem Blog, biete dort Beispiel-Markups und Styles an. Ihr Blog wird davon profitieren (und Sie auch, wenn Sie Anzeigen haben).

B. Shortcodes sind kool. Sie schaden niemandem, wenn das Plugin (in den meisten Fällen) nicht mehr vorhanden ist und können später zu TinyMCE-Schaltflächen (die die Leute lieben) erweitert / weiterentwickelt werden.

C. Stellen Sie klar, dass Ihr Plugin ein anderes Plugin benötigt. Stellen Sie dies in Frage und fügen Sie einen Hinweis zu admin_notices (über register_activation_hook) hinzu, wenn das andere Plugin nicht beendet wird (in diesem Fall verknüpfen) oder nicht aktiviert ist (Sie können dies für den Benutzer bei der Aktivierung tun). Beachten Sie auch, dass dieses Plugin aus einer vertrauenswürdigen Quelle stammt und für die nächsten Jahre beibehalten wird.

Hinweis: Nichts, was ich geschrieben habe, ist mehr als meine persönliche Meinung, die meine Erfahrung widerspiegelt.


1
+1 für TinyMCE (oder andere) Shortcode-Schaltflächen, diese Technik ist für technisch nicht versierte Benutzer so hilfreich und hilft bei der gesamten Themeintegration.
Wyck

1
Danke für deine Gedanken. Hier gibt es eine Menge allgemeiner Plugin-Weisheiten. In Bezug auf meine Frage klingt es so, als ob Ihre Methode darin besteht, sehr wenig in Bezug auf die Themenintegration zu geben. Sie möchten, dass der Benutzer dies anhand der Dokumentation herausfindet. Ich kann sehen, warum dies eine vernünftige Methode ist, aber gleichzeitig wird eine solche Datei dazu führen, dass viele Benutzer das Gefühl haben, dass etwas im Plugin fehlt. In meinem Beispiel haben die Benutzer das Gefühl, dass etwas kaputt ist, wenn es keine eingebaute Unterstützung für die Anzeige der Bands / Alben / Tracks gibt.
Tollmanz

Wenn Sie dabei bleiben möchten, dann würde ich vorschlagen, dass Sie wirklich einen Shortcode verwenden, um einem cpt (oder irgendwo anders drinnen) Markierungen hinzuzufügen. In Bezug auf Stile: Ich überprüfe einfach, ob ein bestimmtes Stylesheet irgendwo im Ordner child> parent theme vorhanden ist. Wenn ja: Das Core-Stylesheet wird stillschweigend außer Kraft gesetzt. Auf diese Weise können Sie möglicherweise beide Entwickler als Endbenutzer zufriedenstellen.
Kaiser

@kaiser ... beide soliden Punkte gibt.
tollmanz

2

In einigen Fällen müssen Sie die Balance zwischen dem Erstellen eines Plugins oder eines Themas abwägen. Wenn Ihr Szenario viele Anpassungen / Funktionen erfordert, ist es in der Regel besser, stattdessen ein Thema zu erstellen. Auf diese Weise kann der Benutzer das Erscheinungsbild anpassen, was immer einfacher ist, als wenn der Benutzer die Funktionalität anpassen muss (indem er überall Shortcodes blockiert). Sie haben eine bessere Funktionskontrolle, es funktioniert mit anderen Plugins usw.

Ein Plugin, das sich stark in die verschiedenen Themen auf dem Markt einfügt, wird Ihnen sicherlich viel Ärger und ehrlich gesagt viel Arbeit bereiten.

Anstatt beispielsweise ein sehr integriertes Plugin auf der Basis von Musik- und Diskografie-Management zu erstellen, erstellen Sie stattdessen ein Thema für diesen Zweck. Dies wird immer beliebter in Nischenmärkten, die benutzerdefinierte Arbeit erfordern. Ein Beispiel aus der realen Welt wäre ein immobilienbasiertes Thema. Ich würde kein Plugin dafür verwenden, da es einen so umfangreichen Funktionsumfang hat. Stattdessen wird es von Grund auf als Thema erstellt, da Themen davon profitieren können jedenfalls alle Funktionen von Plugins.

Aus Marketingsicht ist es auch wahrscheinlich, dass ein Nischenthema beim Abwägen von Front-End-Funktionen besser geeignet ist als ein Plug-In.


Ein guter Punkt, um dies als Plugin zu konzipieren (insbesondere für die Marketingvorteile). Das größte Problem dabei ist, dass ein Plugin und seine Daten nicht immer zu einem ganzen Thema führen müssen. Es kann nur eine kleinere Komponente einer Site sein, die leider thematisiert werden muss. Ich verstehe jedoch allgemein, dass es einfach nicht möglich ist, alle Benutzergruppen zufriedenzustellen, und dass es besser ist, nur eine Gruppe anzustreben.
tollmanz

2

Virtuelle Seiten

Eine dritte Technik, die ich gesehen habe, war, eine spezielle Seite als Platzhalter für Ihr Plugin zuzuweisen und den 'the_content'-Filter zu verwenden, um alles auszugeben, was Sie zur Ausgabe benötigen.

Auf diese Weise können Sie Vorlagen erstellen, die sich in die Themenstruktur einfügen, da Sie sich nicht mit Kopfzeilen, Seitenleisten, Fußzeilen und Wrapper-Divs befassen müssen.

Ein gutes Beispiel dafür finden Sie im bbPress-Plugin:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931


Würden Sie ein Codebeispiel anbieten? Ich denke, das ist etwas, was viele Plugin-Entwickler gerne sehen würden. (+1).
Kaiser

Sie können sich das neue bbPress-Plugin als Beispiel ansehen.
Scribu

Das ist sehr interessant. Ich muss mir den Code ansehen, bevor ich ein Urteil fällen kann.
tollmanz

@scribu: Ich habe danach gesucht, um einen Link hinzuzufügen, kann ihn jedoch nicht über plugins.svn finden. Könnten Sie bitte einen Link für spätere Leser posten? Vielen Dank.
Kaiser

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.