Wohin mit meinem Code: plugin oder functions.php?

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

Es gibt viele Fälle und viele Debatten zu diesem Thema, vor allem, weil es einige Missverständnisse über das Innenleben von WordPress gibt. Ich bitte um eine Antwort, die auf Fakten basiert, nicht auf Meinungen.

Es sollte erklären, wie man mit diesen Punkten (und wahrscheinlich mehr) umgeht:

  • benutzerdefinierte Post-Typen und Taxonomien
  • Kontaktformulare
  • Shortcodes
  • benutzerdefinierte Widgets
  • add_theme_support( 'automatic-feed-links' );
  • SEO funktioniert wie benutzerdefinierte meta Elemente
  • Thema wechseln

Für beide Seiten gibt es oft Vor- und Nachteile. Unsere beliebteste Frage Beste Sammlung von Code für Ihre functions.php-Datei hat eine Menge Code-Schnipsel als Antworten, die zumindest diskutabel sind.
Wir brauchen Kriterien, die ein Anfänger verstehen kann, vielleicht eine Checkliste – mit Gründen.

Sehen Sie auch die verwandte Frage von Chip Bennett auf unserer Meta-Seite: Fragen speziell nach einer Lösung “ohne ein Plugin” fragen

Related: Wo finde ich die Code-Snippets, die ich hier oder irgendwo anders im Internet gefunden habe?

Solutions Collecting From Web of "Wohin mit meinem Code: plugin oder functions.php?"

Ich würde mit dieser Frage beginnen: Betrifft die functionalität die Darstellung von Inhalten oder die Erzeugung / Verwaltung von Inhalten oder der Website oder der Benutzeridentität?

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

  • Ändern von core-WP-Filtern ( wp_head Inhalt, wie kanonische Links, Generator und andere HTML-Metas, etc.)
  • Standort Favicon
  • Post-Inhalts-Shortcodes
  • Post-Sharing-Links
  • Google Analytics (und ähnliche) Fußzeilenskripte
  • SEO-Tools / Kontrollen
  • etc.

Wenn die functionalität mit der Präsentation von Inhalten zusammenhängt , ist dies ein Kandidat für die Aufnahme in das Thema. An diesem Punkt würde ich zu @ Raf912s Theme-switch-Kriterium zurückkehren : Würden Sie die functionalität beim Wechseln von Themes verpassen? Wenn die Antwort auf diese Frage nein ist , gehört die functionalität zum Thema. Einige Beispiele:

  • Entfernen / Überschreiben des WP-Core Gallery CSS
  • Filtern der Länge des Postauszugs, Lesen des Textes usw.
  • Alles implementiert über add_theme_support() (Ich nehme an, dieser sollte offensichtlich sein)
  • Benutzerdefinierte CSS

Normalerweise werden diese beiden Fragen eine ziemlich klare Differenzierung ermöglichen. Es gibt jedoch Ausnahmen.

Benutzerdefinierte Beitragstypen

Zum Beispiel sind benutzerdefinierte Beitragstypen ein bisschen eine einzigartige Mischung aus Inhaltserzeugung und -präsentation, wenn man bedenkt, wie die Vorlagenhierarchie für Archiv-Indexseiten des einzelnen Posttyps und einzelne Post-Seiten funktioniert. Der Inhaltserzeugungsaspekt von CPTs würde sie normalerweise direkt in Plugin Territory platzieren; Plugins können jedoch keine Vorlagenseiten definieren, die in das Design / Layout / Stil für ein bestimmtes Thema passen (insbesondere wenn das CPT nicht den üblichen Titel / Inhalt / Meta anzeigt oder ihm benutzerdefinierte Taxonomien zugeordnet sind).

Langfristig besteht die Lösung für diese Ungleichheit, IMHO, eine Standardkonvention / -konsens für die Definition von CPTs für bestimmte Arten von Inhalten (Immobilienangebote, Kalenderereignisse, E-Commerce-Produkte, Buch- / Medienbibliothekseinträge, etc.) .). Auf diese Weise bleiben nutzergenerierte Inhalte zwischen Designs verfügbar, die die Standard / Convention-Definition eines bestimmten CPT implementieren, während Theme-Entwickler die Flexibilität behalten, das Design / Layout / Stil dieses CPT in den Theme-Vorlagendateien zu definieren.

Social Media Links

Genauso würde ich normalerweise sagen, dass Social-Media-Profil-Links, die allgegenwärtig in aktuellen Designs sind, Plugin-Territorium sind, weil sie nichts mit der Präsentation von Inhalten zu tun haben. Die beste Lösung wäre, diese Profile irgendwo im core zu definieren; Derzeit gibt es jedoch kein Standard / Konsens-Mittel zur Definition dieser Verbindungen. Sind sie am besten auf der Ebene der Site-Einstellung oder auf der Basis von Nutzern definiert? Wenn pro Benutzer, welches Meta des Benutzers in der Vorlage verfügbar gemacht wird? etc.

Die Lösung für diese Disparität besteht also langfristig darin, dass jeder der beiden Bereiche definiert, wo diese Links definiert sind, oder ob die Community der Themenentwickler einen eigenen Konsens entwickelt. In der Zwischenzeit gibt es wirklich nichts dafür, sie in jedem Thema definiert zu halten.

Ein einfacher Test, bei dem der Code am besten platziert ist:

  • schreibe den Code in die functions.php
  • Thema wechseln
  • Vermisst du die functionalität, funktioniert der Blog nicht richtig oder sind Fragmente des alten Themas (zB Shortcodes) übrig?

    • ja: stecke es in ein Plugin

    • nein: lass es in functions.php

Beispiele: Schreiben Sie einen Shortcode. Nachdem Sie das Thema gewechselt haben, bleiben die einfachen Shortcodes in Ihren Beiträgen. Es wird also besser in einem Plugin platziert.

Schreiben Sie eine function, um die letzten Kommentare aufzulisten. Nach dem Umschalten des Themas ist alles in Ordnung, weil vielleicht das andere Thema eine äquivalente function hat.

Es hängt wirklich vom Code ab und was er tun wird. Einige Codes beeinflussen nur das Styling oder den Inhalt des Themas, andere ändern Blogposts.

Ich glaube nicht, dass es eine einfache Antwort auf diese Frage gibt, aber ich wette, wir könnten ein Flussdiagramm erstellen, um bei der Entscheidung zu helfen. Hier ein grober Überblick ü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 Design der Website nur bei größeren Redesigns und Änderungen der functionalität?
      • Ja – Ist der betreffende Code spezifisch für dieses aktuelle Design ?
        • Ja: functions.php
        • Nein: Plugin
      • Nein (es ändert sich oft oder nach Lust und Laune) – Plugin
    • Nein (Multisisite) – Hosten Sie die Multisite-Installation ODER ist es eine gehostete Multisite-Lösung, die Plugins zulässt?
      • Ja: Ist die fragliche functionalität spezifisch für diese Site oder kann / sollte sie von anderen Sites im Netzwerk verwendet werden?
        • Spezifisch für diese Seite: functions.php
        • Auf mehrere Websites verteilt – Möchten Sie es auf jeder Website erzwingen?
          • Ja: Plugin, gespeichert im mu-plugins-Verzeichnis oder netzwerkaktiviert
          • Nein: Ist das ein Netzwerk von nicht verwandten Websites? (zB verschiedene Kunden)
            • Ja: Wäre es schlecht oder unprofessionell, wenn Client A das Plugin, das Sie für die Clients B, C und D geschrieben haben, gesehen oder aktiviert hat? (zB könnte es die Seite beschädigen oder unerwünschte functionalität verursachen)
              • Ja: functions.php
              • Nein: Plugin
            • Nein: Wahrscheinlich Plugin
      • Nein (gehostet von einem Dienst wie VIP, der keine Plugins zulässt): benutze functions.php

Ein paar andere Gedanken, die ich nicht kannte:

  • Übergeordnete Themen – manchmal mit gemeinsamen functionen wäre es besser, ein übergeordnetes Thema zu erstellen und die functionalität in die functions.php-Datei des übergeordneten Themas zu stellen.
  • Plugin-Verzeichnisse von großen Installationen mit mehreren Standorten können schnell widerspenstig werden, weshalb die von einem geringen Prozentsatz von Websites (z. B. <1%) genutzte gemeinsame Funktionalität am besten in functions.php-Dateien kopiert werden kann.

Von hier Themen VS Plugins

Fügen Sie einem untergeordneten Design benutzerdefinierten Code hinzu. Wenn Sie also das übergeordnete Design aktualisieren, geht Ihr benutzerdefinierter Code nicht verloren.

Sie können auch ein Site-spezifisches Plugin erstellen, das Ihren gesamten benutzerdefinierten Code enthält.

Was das Schreiben von Code im Vergleich zu Plugins angeht, können Sie Plugins für und die functionen verwenden. Handcodierung ist jedoch am besten, da es einfacher zu modifizieren ist, außer in einigen Fällen wie Meta-Boxen, in denen Sie ein Plug-in verwenden können 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 neue Felder hinzu – Code oben
  3. Neue Widgets hinzufügen – Code
  4. Fügen Sie benutzerdefinierte Permalinks hinzu – WordPress Permalink Einstellungen

Ich weiß, dass es ein totes Pferd ist, und dieser Chip hat es ziemlich gut abgedeckt, wollte aber ein paar Gedanken hinzufügen.

Wenn Sie Ihren Lebensunterhalt verdienen Programmierung und finden Sie sich auf WordPress-Websites unter Terminen arbeiten, werden Sie feststellen, dass es wirklich auf die Zeit kommt.

Meistens, besonders für diejenigen, die gerade erst anfangen, ist es viel schneller und einfacher, einfach alles, was Sie brauchen, zu einem Thema hinzuzufügen und es fertig zu machen.

Wenn Sie jedoch regelmäßig an WordPress arbeiten, sollten Sie Folgendes ernsthaft in Erwägung ziehen :


  1. Erstellen Sie ein Plugin-Skelett

Dies sollte alles behandeln, was Sie normalerweise mit einem Plugin tun müssen, einschließlich Aktivierung, Deaktivierung, Versionsaktualisierung, Erstellung von Admin-Panels und Deinstallation.

Wenn Sie sich die Zeit dafür nehmen, finden Sie:

  • Es braucht nicht mehr viel Zeit, um functionalität über Plugins hinzuzufügen
  • Sie können beginnen, eine solide Liste von Plugins zu erstellen, um sie bei Bedarf in anderen Projekten wiederzuverwenden. Dadurch sparen Sie auf lange Sicht viel Zeit.
  • Sie können sie öffentlich zugänglich machen, wenn Sie zusätzliche Sichtbarkeit wünschen

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


  1. Baue ein Themenskelett aus

Dies sollte alles behandeln, was normalerweise in einem Thema benötigt wird:

  • Ein zentrales Stylesheet, das häufig verwendete Stile enthält (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 nicht annähernd verwenden, aber sie wird immer noch nützlich sein.

Sobald Sie damit fertig sind, erstellen Sie ein untergeordnetes Themenskelett, das Ihr primäres Thema verwendet.

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

Sobald Sie diese zwei Dinge erledigt haben, wird das Erstellen neuer Websites für Personen viel schneller.


Wenn Sie das oben genannte tun, können Sie dann Folgendes bearbeiten:

  • Verbringen Sie Ihre neue Freizeit mit PHP, WordPress, JavaScript, CSS und / oder mySQL … je mehr Sie davon lernen, desto schneller werden Sie Dinge erledigen.
  • Aktualisieren Sie Ihre Skelette für Plug-ins, Designs und untergeordnete Designs, wenn Sie Dinge finden, die Sie verbessern sollten. Egal wie gut du bist, wenn du weiter lernst, wirst du Verbesserungen finden.

Und wenn Sie all das oben genannte tun, werden Sie feststellen, dass die Antwort von Chip nicht nur ideal ist, sondern auch optimal.

Die einfache Antwort ist das ..

Ist der Code von einer function abhängig, die in ein bestimmtes Thema integriert ist? Wenn ja, dann lege ein Thema ein.

Möchten Sie, dass dieser Code zwischen Websites und zwischen Themen übertragbar ist? Wenn ja, dann setze ein Plugin ein.

Wenn die Antwort für beide oben nicht stimmt, dann stellen Sie sich die Seite 5 Jahre in der Zukunft vor, wenn es Zeit für ein Redesign ist. Ist die function des Codes, den Sie schreiben, etwas, das das nächste Design-Update überleben wird? Wenn ja, setze ein Plugin ein.

Wenn Sie keine untergeordneten Themen verwenden und das Thema aktualisieren möchten, sollten Sie auch ein Plug-in verwenden.