wake-up-neo.com

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

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):

Es 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?

86
fuxia

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:

  • Ändern von WP Kernfiltern (wp_head -Inhalt, z. B. 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 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:

  • WP Core Gallery CSS entfernen/überschreiben
  • Filtern der Länge von Post-Auszügen, "read more" -Texten usw.
  • Alles, was über add_theme_support() implementiert wurde (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 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.

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 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.

71
Chip Bennett

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 (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.

49
Ralf912

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 (Multisite) - Hosten Sie die Multisite-Installation OR Ist es eine gehostete Multisite-Lösung, die Plugins zulässt?
      • Ja: Ist die betreffende Funktionalität spezifisch für diese Site 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 unabhängigen Sites? (z. B. 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 Site 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 mit gemeinsamer Funktionalität ist es 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, die von einem geringen Prozentsatz der Sites (z. B. <1%) genutzte gemeinsame Funktionalität in functions.php-Dateien zu duplizieren.
17
Matthew Boynes

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

  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 - Einstellungen für WordPress-Permalinks
5
Brad Dalton

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 :


  1. Bauen Sie ein Plugin-Skelett aus

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 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 um zukünftige Projekte schneller zu erledigen.


  1. Ein Themenskelett aufbauen

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 häufig 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 alles oben Genannte tun, werden Sie feststellen, dass die Antwort von Chip nicht nur ideal ist, sondern auch optimal wird.

4
Privateer

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.

2
CO4 Computing