Gibt es ein leicht verständliches Schema , um zu entscheiden, welche Art von Code zu einem Plugin oder zum functions.php
des Themas gehört?
Es gibtvieleFälle und viele Debatten zu diesem Thema, vor allem, weil es einige Missverständnisse über die Funktionsweise von WordPress gibt. Ich bitte um eine Antwort basierend auf Fakten, nicht auf Meinungen.
Es sollte erklären, wie mit diesen Punkten umgegangen wird (und wahrscheinlich mit mehr):
add_theme_support( 'automatic-feed-links' );
meta
ElementeEs gibt oft Vor- und Nachteile für beide Seiten. Unsere beliebteste Frage Beste Sammlung von Code für Ihre functions.php-Datei hat eine Menge Code-Schnipsel als Antworten, die zumindest umstritten sind.
Wir brauchen Kriterien, die ein Anfänger verstehen kann, vielleicht eine Checkliste - mit Gründen.
Siehe auch die zugehörige Frage von Chip Bennett auf unserer Meta-Site: Fragen, die speziell nach einer Lösung "ohne Plugin" fragen
Related: Wo lege ich die Codefragmente ab, die ich hier oder anderswo im Web gefunden habe?
Ich würde mit dieser Frage beginnen: Bezieht sich die Funktionalität auf Präsentation des Inhalts oder auf Generierung/Verwaltung des Inhalts oder der Website oder der Benutzeridentität?
Wenn die Funktionalität nicht spezifisch mit Darstellung von Inhalten zusammenhängt, liegt sie direkt im Plugin-Gebiet. Diese Liste ist lang:
wp_head
-Inhalt, z. B. kanonische Links, Generator und andere HTML-Metas usw.)Wenn die Funktionalitätmit Präsentation des Inhalts zusammenhängt, ist es ein Kandidat, um in das Thema aufgenommen zu werden. An dieser Stelle würde ich auf das @ Raf912-Kriterium zum Themawechsel zurückgreifen : würden Sie die Funktionalität beim Themawechsel vermissen? Wenn die Antwort auf diese Frage nein lautet, gehört die Funktionalität zum Theme. Einige Beispiele:
add_theme_support()
implementiert wurde (ich denke, dies sollte offensichtlich sein)Normalerweise bieten diese beiden Fragen eine ziemlich klare Unterscheidung. Es gibt jedoch Ausnahmen.
Benutzerdefinierte Beitragstypen sind beispielsweise eine einzigartige Mischung aus Inhaltsgenerierung und -darstellung, da die Vorlagenhierarchie für einzelne Beitragstypen funktioniert Archivindexseiten und einzelne Beitragsseiten . Der inhaltsgenerierende Aspekt von CPTs platziert sie normalerweise direkt im Plug-in-Gebiet. Plug-ins können jedoch keine Vorlagenseiten definieren, die von Natur aus in das Design/Layout/den Stil eines bestimmten Themas passen (insbesondere, wenn das CPT andere als die üblichen Titel/Inhalte/Metas anzeigt oder mit diesen benutzerdefinierte Taxonomien verknüpft sind).
Langfristig besteht die Lösung für diese Ungleichheit darin, eine Standardkonvention/einen Standardkonsens für die Definition von CPTs für bestimmte Arten von Inhalten (Immobilienlisten, Kalenderereignisse, E-Commerce-Produkte, Buch-/Medienbibliothekseinträge usw.) .). Auf diese Weise bleiben benutzergenerierte Inhalte zwischen Themen übertragbar, die die Standard-/Konventionsdefinition eines bestimmten CPT implementieren, während Entwickler von Themen die Flexibilität behalten, das Design/Layout/den Stil dieses CPT in den Vorlagendateien für Themen zu definieren.
In ähnlicher Weise würde ich normalerweise sagen, dass Social-Media-Profil-Links, die in aktuellen Themen so gut wie allgegenwärtig sind, Plugin-Territory sind, da sie nichts mit Präsentation von Inhalten zu tun haben. Die beste Lösung wäre, diese Profile irgendwo im Kern zu definieren. Derzeit gibt es jedoch keine Standard-/Konsensmethode zum Definieren dieser Links. Sind sie auf Website-Ebene oder auf Benutzerbasis am besten definiert? Wenn pro Benutzer, wird das Meta des Benutzers in der Vorlage verfügbar gemacht? usw.
Langfristig besteht die Lösung für diese Diskrepanz darin, dass entweder der Kern definiert, wo diese Verknüpfungen definiert werden, oder dass die Theme-Entwicklergemeinschaft einen eigenen Konsens entwickelt. In der Zwischenzeit bleibt nichts anderes übrig, als sie in jedem Thema definiert zu lassen.
Ein einfacher Test, wo der Code am besten platziert ist:
vermissen Sie die Funktionalität, funktioniert der Blog nicht richtig oder es verbleiben Fragmente des alten Themas (z. B. Shortcodes)?
ja: steck es in ein plugin
nein: lass es in functions.php
Beispiele: Schreiben Sie einen Shortcode. Nachdem Sie das Thema gewechselt haben, verbleiben die einfachen Shortcodes in Ihren Posts. Also wird es besser in einem Plugin platziert.
Schreiben Sie eine Funktion, um die letzten Kommentare aufzulisten. Nach dem Umschalten des Themas ist alles in Ordnung, da möglicherweise das andere Thema eine entsprechende Funktion hat.
Es kommt wirklich auf den Code an und darauf, was er macht. Einige Codes beeinflussen nur das Design oder den Inhalt des Themas, andere modifizieren Blog-Beiträge.
Ich glaube, es gibt keine einfache Antwort auf diese Frage, aber ich wette, wir könnten ein Flussdiagramm erstellen, um bei der Entscheidung zu helfen. Hier ist eine grobe Übersicht über ein solches Flussdiagramm, das erweitert werden kann und sollte. Kommentar mit Vorschlägen!
Von hier Themes VS Plugins
Fügen Sie einem untergeordneten Design benutzerdefinierten Code hinzu, damit Ihr benutzerdefinierter Code nicht verloren geht, wenn Sie das übergeordnete Design aktualisieren.
Sie können auch ein Site-spezifisches Plugin erstellen, das auch Ihren gesamten benutzerdefinierten Code enthält.
Was das Schreiben von Code im Vergleich zu Plugins angeht, können Sie Plugins für und die Funktionen verwenden. Für die meisten Ihrer Anforderungen ist Handcodierung jedoch am besten geeignet, da es einfacher zu ändern ist, es sei denn, Sie möchten ein Plugin verwenden bin ein themenentwickler.
function modify_contact_methods($profile_fields) {
// Add new fields
$profile_fields['Twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';
return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');
http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods
Ich weiß, dass dies ein totes Pferd ist und dass Chip es so ziemlich verdeckt hat, aber ich wollte ein paar Gedanken hinzufügen.
Wenn Sie sich einen Lebensunterhalt mit der Programmierung verdienen und feststellen, dass Sie unter bestimmten Fristen an WordPress-Sites arbeiten, werden Sie feststellen, dass es wirklich auf die Zeit ankommt.
Besonders für Anfänger ist es viel schneller und einfacher, einfach alles, was Sie brauchen, in ein Thema einzufügen und es als erledigt zu bezeichnen.
Davon abgesehen, wenn Sie regelmäßig mit WordPress arbeiten, sollten Sie ernsthaft in Betracht ziehen, Folgendes zu tun :
Dies sollte alles erledigen, was Sie normalerweise für ein Plugin benötigen, einschließlich Aktivierung, Deaktivierung, Versionsaktualisierung, Erstellen von Admin-Panels und Deinstallieren.
Wenn Sie sich dafür Zeit nehmen, finden Sie:
Sie können jetzt die Dinge richtig aufbauen und um zukünftige Projekte schneller zu erledigen.
Dies sollte alles erledigen, was in einem Thema häufig benötigt wird:
Wenn Sie dies erledigt haben, bauen Sie ein untergeordnetes Themenskelett auf, das Ihr primäres Thema verwendet.
Sobald Sie diese beiden Dinge erledigt haben, wird das Erstellen neuer Websites für Benutzer viel schneller.
Wenn Sie dies tun, können Sie Folgendes bearbeiten:
Und wenn Sie alles oben Genannte tun, werden Sie feststellen, dass die Antwort von Chip nicht nur ideal ist, sondern auch optimal wird.
Die einfache Antwort lautet:.
Ist der Code von einer der Funktionen abhängig, die in ein bestimmtes Thema integriert sind? Wenn ja, geben Sie ein Thema ein.
Soll dieser Code zwischen Websites und zwischen Themen übertragbar sein? Wenn ja, dann stecke ein Plugin ein.
Wenn die Antwort auf beides Nein lautet, stellen Sie sich die Site 5 Jahre in der Zukunft vor, wenn es Zeit für eine Neugestaltung ist. Ist die Funktion des Codes, den Sie schreiben, etwas, das das nächste Design-Update übersteht? Wenn ja, fügen Sie ein Plugin hinzu.
Auch wenn Sie keine untergeordneten Designs verwenden und das Design aktualisieren möchten, empfehle ich Ihnen, ein Plugin zu verwenden.