Wo soll ich meinen Code ablegen: plugin oder functions.php?

Gibt es ein einfach zu verstehendes Schema , um zu entscheiden, welche Art von Code zu einem Plugin oder dem des Themes gehört functions.php?

Es gibt viele Fä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):

• benutzerdefinierte Beitragstypen und Taxonomien
• Kontaktformulare
• Shortcodes
• benutzerdefinierte Widgets
• add_theme_support( 'automatic-feed-links' );
• SEO funktioniert wie benutzerdefinierte metaElemente
• Themenwechsel

Es gibt oft Vor- und Nachteile für beide Seiten. Unsere beliebteste Frage Best Collection of 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 verwandte Frage von Chip Bennett auf unserer Meta-Site: Fragen, die speziell nach einer Lösung "ohne Plugin" fragen

Verwandte Themen : Wo lege ich die Codefragmente ab, die ich hier oder anderswo im Web gefunden habe?

Ich würde mit der folgenden Frage beginnen: Bezieht sich die Funktionalität auf die Darstellung von Inhalten oder auf die Erstellung / Verwaltung von Inhalten, der Website oder der Benutzeridentität?

Wenn sich die Funktionalität nicht speziell auf die Darstellung von Inhalten bezieht , liegt sie direkt im Plugin-Gebiet. Diese Liste ist lang:

• Modifizieren der wichtigsten WP - Filter ( wp_headInhalte wie kanonische Links, Generator und andere HTML - Metas usw.)
• Site Favicon
• Post-Content-Shortcodes
• Post-Sharing-Links
• Fußzeilenskripte von Google Analytics (und ähnlichen)
• SEO Tools / Kontrollen
• usw.

Wenn sich die Funktionalität auf die Präsentation von Inhalten bezieht , ist dies ein Kandidat für die Aufnahme in das Thema. An dieser Stelle würde ich auf das Kriterium des Motivwechsels bei @ Raf912 zurückgreifen : Fehlt Ihnen die Funktionalität, wenn Sie das Motiv wechseln? Wenn die Antwort auf diese Frage Nein lautet , gehört die Funktionalität zum Thema. Einige Beispiele:

• Entfernen / Überschreiben des WP Core Gallery CSS
• Filtern der Länge von Post-Auszügen, "read more" -Texten usw.
• Alles, was über implementiert wurde add_theme_support()(ich denke, dies sollte offensichtlich sein)
• Benutzerdefinierte CSS

Normalerweise bieten diese beiden Fragen eine ziemlich klare Unterscheidung. Es gibt jedoch Ausnahmen.

Benutzerdefinierte Beitragstypen

Benutzerdefinierte Beitragstypen sind beispielsweise eine einzigartige Mischung aus Inhaltsgenerierung und -darstellung, da die Vorlagenhierarchie für Archivindexseiten mit einem Beitragstyp und für einzelne Beitragsseiten funktioniert . Der inhaltsgenerierende Aspekt von CPTs platziert sie normalerweise direkt im Plug-in-Gebiet. Plugins können jedoch keine Vorlagenseiten definieren, die für ein bestimmtes Thema in das Design / Layout / den Stil 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 (Immobilieneinträge, 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 die Entwickler des Themas die Flexibilität behalten, das Design / Layout / den Stil dieses CPT in den Vorlagendateien des Themas zu definieren.

Social Media Links

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 der Darstellung 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 angezeigt? usw.

Langfristig besteht die Lösung für diese Diskrepanz darin, dass entweder der Kern definiert, wo diese Links definiert werden, oder dass die Entwicklergemeinschaft des Themas 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:

• schreibe den code in die functions.php
• Thema wechseln

• Vermissen Sie die Funktionalität, funktioniert der Blog nicht richtig oder es verbleiben Fragmente des alten Themas (zB 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. Nachdem Sie das Thema gewechselt haben, 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-Posts.

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!

• Soll dieser Code auf einer Single-Site-Installation von WordPress gehostet werden?
  • Ja - Ändert sich das Thema der Site nur bei größeren Neugestaltungen und Funktionsverschiebungen?
    • Ja - Ist der fragliche Code spezifisch für dieses aktuelle Design ?
      • Ja: functions.php
      • Nein: Plugin
    • Nein (es ändert sich oft oder nach Lust und Laune) - Plugin
  • Nein (Multsisite) - Hosten Sie die Multisite-Installation, ODER handelt es sich um eine gehostete Multisite-Lösung, die Plugins zulässt?
    • Ja: Ist die betreffende Funktionalität für diese Site spezifisch oder kann / sollte sie von anderen Sites im Netzwerk verwendet werden?
      • Speziell für diese Site: functions.php
      • Auf mehrere Sites aufgeteilt - Möchten Sie dies auf jeder Site erzwingen?
        • Ja: Plugin, im mu-plugins-Verzeichnis gespeichert oder netzwerkaktiviert
        • Nein: Handelt es sich um ein Netzwerk von Websites, die nichts miteinander zu tun haben? (zB verschiedene Kunden)
          • Ja: Wäre es schlecht oder unprofessionell, wenn Client A das von Ihnen für Client B, C und D geschriebene Plugin sehen oder aktivieren würde? (z. B. könnte dies die Website beschädigen oder unerwünschte Funktionen verursachen)
            • Ja: functions.php
            • Nein: Plugin
          • Nein: Wahrscheinlich Plugin
    • Nein (wird von einem Dienst wie VIP gehostet, der keine Plugins zulässt): benutze functions.php

• Übergeordnete Themen - Manchmal ist es bei gemeinsamer Funktionalität besser, ein übergeordnetes Thema zu erstellen und die Funktionalität in die Datei functions.php des übergeordneten Themas einzufügen.
• Plugin-Verzeichnisse von großen Installationen mit mehreren Standorten können schnell unregelmäßig werden. Daher ist es manchmal am besten, gemeinsame Funktionen, die von einem geringen Prozentsatz von Standorten verwendet werden (z. B. <1%), in functions.php-Dateien zu duplizieren.

Von hier aus 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

1. Neuen benutzerdefinierten Beitragstyp hinzufügen - Code
2. Fügen Sie dem Benutzer-Code neue Felder hinzu
3. Neue Widgets hinzufügen - Code
4. Benutzerdefinierte Permalinks hinzufügen - WordPress-Permalink-Einstellungen

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 einen Lebensunterhalt mit Programmieren verdienen und sich unter Fristen auf WordPress-Sites befinden, 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 sollten Sie ernsthaft überlegen, Folgendes zu tun , wenn Sie regelmäßig mit WordPress arbeiten :

1. Bauen Sie ein Plugin-Skelett auf

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:

• Das Hinzufügen von Funktionen über Plugins dauert nicht mehr lange
• Sie können damit beginnen, eine solide Liste von Plugins zu erstellen, die Sie bei Bedarf für andere Projekte wiederverwenden können. So sparen Sie sich auf lange Sicht viel Zeit.
• Sie können sie öffentlich zugänglich machen, wenn Sie zusätzliche Sichtbarkeit wünschen

Sie können jetzt die Dinge richtig aufbauen und zukünftige Projekte schneller erledigen.

2. Baue ein Themenskelett aus

Dies sollte alles erledigen, was in einem Thema häufig benötigt wird:

• Ein zentrales Stylesheet mit häufig verwendeten Stilen (Zurücksetzen usw.)
• Eine richtige index.php-Datei, die alles verarbeitet, was Sie für eine Vorlage benötigen
• Eine functions.php-Datei - Sie werden sie bei weitem nicht so oft verwenden, aber sie wird sich dennoch als nützlich erweisen.

Wenn Sie dies erledigt haben, bauen Sie ein untergeordnetes Themenskelett auf, das Ihr primäres Thema verwendet.

• Fügen Sie das Stylesheet unter Bezugnahme auf Ihr übergeordnetes Thema hinzu.
• Fügen Sie die Datei functions.php hinzu

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:

• Verbringen Sie Ihre neu gewonnene Freizeit damit, sich mit PHP, WordPress, JavaScript, CSS und / oder mySQL vertraut zu machen. Je mehr Sie davon lernen, desto schneller werden Sie die Dinge erledigen.
• Aktualisieren Sie Ihre Plugin-, Theme- und Child-Theme-Skelette, wenn Sie Dinge finden, die Sie verbessern sollten. Egal wie gut Sie sind, wenn Sie weiter lernen, werden Sie Verbesserungen finden, die vorgenommen werden müssen.

Und wenn Sie all dies 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.