Wie überschreibe ich die steckbare Funktion im Thema?

In der gesamten Dokumentation, auf die ich gestoßen bin, wird das Überschreiben der steckbaren Funktion über Ihr Plugin beschrieben.

Was ist, wenn Sie stattdessen Themen entwickeln?

Meine functions.php erfordert eine andere Datei, die die get_user_by()in definierte Funktion überschreibt pluggable.php.

Wenn ich den if( function_exists() )Anruf weglasse, wird der Fehler "Kann nicht neu deklarieren ..." angezeigt.

Wenn ich den if( function exists() )Aufruf einbinde, erhalte ich keine Fehlermeldung, aber meine Funktion wird dann natürlich ignoriert, da die steckbare Version vorhanden ist.

Basierend auf Dominics großartigem Beitrag zur WordPress-Startreihenfolge ist klar, dass er vor dem Thema pluggable.phpgeladen wird und so weiter, sodass der Fehler erklärt wird.functions.php

Die Frage ist also: Wie können Sie diese schöne steckbare Architektur innerhalb eines Themas nutzen, ohne Plugins schreiben zu müssen, die dann mit dem Theme gebündelt oder installiert werden müssen?

Weitere Hinweise : Es scheint also das Argument zu sein, dass Themen nicht versuchen sollten, das zu tun, was Plugins tun. Dieses Argument ist jedoch älter als vier Jahre (gemäß der 4-stelligen Trac-Nummer). Ich würde gerne von einigen Schlagern hören, ob diese Philosophie angesichts der komplexen Topologie der heutigen Themenentwicklungslandschaft immer noch gilt. Ich würde gerne glauben, dass wir uns seitdem weiterentwickelt haben.

Kontext : Ich entwickle eine einmalige CMS-Lösung für einen Kunden mit vielen benutzerdefinierten Metadaten, der Anpassung des Admin-Backends, dem Anmelde- / Authentifizierungsprozess und den Funktionen. Und natürlich gibt es die Designkomponente - hier kommt der Thementeil ins Spiel. Tatsache ist, dass dies einfach keine wiederverwendbaren Komponenten sind - sie werden niemals auf einen anderen Kunden angewendet, sie werden niemals unter GPL und Open Source gestellt und sie sind die meisten sicherlich nicht auf anderen WordPress-Bereitstellungen verteilt / installiert werden. Bestenfalls gibt es einige Best Practices, die ich für zukünftige Projekte nutzen werde, aber das ist ausschließlich ein Referenz- / Kopier-Einfüge-Job.

Dies klingt für mich nicht nach einem Anwendungsfall für Plugins. Das Thema ist installiert, möglicherweise ein untergeordnetes Thema von Twenty Eleven, möglicherweise ein eigenständiges Thema, dessen Funktionen.php eine Schiffsladung von Includes aufruft, die jeweils einen anderen Aspekt des betreffenden CMS behandeln. Anschließend verwenden die Designvorlagendateien benutzerdefinierte "Vorlagen-Tags", die in den Includes definiert sind. Ich möchte keine Themendateien mit Abhängigkeiten von einem Plugin oder einem anderen, das aktiviert wird usw. Es ist einfach nicht sinnvoll, Komplexität in das System einzubauen. Sicher, ich kann es in den Plugins-Ordner legen, der unbedingt verwendet werden muss, aber das fühlt sich immer noch wie ein Hack an - im Moment ist alles enthalten , was mit den für dieses Projekt vorgenommenen Anpassungen zu tun hat wp-content/themes/my-theme/. Ich möchte auch nicht in Betracht ziehen müssen, in einigen Plugin-Ordnern nach Dingen zu suchen.

Versteh mich nicht falsch. Ich liebe Plugins und ich benutze sie und schreibe sie. Und ich verwende Plugins in Verbindung mit dieser Art von hochgradig angepasster Theme-Entwicklung, wenn das Plugin von Drittanbietern stammt und Best Practices darstellt, die weit über das hinausgehen, was ich möglicherweise in einem angemessenen Zeitrahmen einführen könnte. Wenn ich jedoch die Kernfunktionalität für ein einmaliges Szenario ändern muss, wende ich mich Action-Hooks und Filter-Hooks zu und möchte mich auch auf steckbare Funktionen für die Benutzer- und Authentifizierungsseite verlassen können.

Wenn Sie dies für einen einzelnen Client erstellen, sollten Sie dies unbedingt nutzen mu-plugins.

Es gibt viele Dinge in WordPress, die Sie nicht tun können functions.php. Pluggable-Funktionen sind eine davon, aber offensichtlicher ist, dass eine Reihe von Hooks (sowohl Aktionen als auch Filter) zuvor ausgelöst wurden functions.php. In einigen Fällen werden diese Hooks sogar vor regulären Plugins ausgelöst, für die Sie dann mu-pluginsein netzwerkaktiviertes Plugin verwenden müssen. In noch anderen Fällen ist sogar ein Mu-Plugin zu spät. Vielleicht brauchst du etwas in sunrise.php. Oder sogar etwas (eine Konstante oder etwas anderes) in wp-config.php.

Ich würde lieber einige Hooks zu steckbaren Funktionen hinzufügen, als es einfacher zu machen, sie zu überschreiben. Wir werden wahrscheinlich nie wieder eine steckbare Funktion haben - sie datieren Haken vor und ich habe fast nie eine Situation gesehen, in der sie einen Vorteil gegenüber einem guten altmodischen (neuartigen?) Haken haben.

Sechs Jahre später stimme ich Andy Skelton immer noch zu: "Es gibt viele Unterschiede zwischen der Funktionsdatei eines Themas und einem Plugin. Lassen Sie es uns so bleiben."

Abgesehen davon könnte eine solche Änderung niemals stattfinden. Es würde viele Dinge kaputt machen. Unzählige Themen, die Funktionen im Hauptteil aufrufen functions.php, würden zu einem schwerwiegenden Fehler führen, wenn pluggable.phpsie nicht bereits geladen worden wären - wie current_user_can()oder wp_create_nonce(). Sie würden alle scheitern. Und es würde auch Plugins kaputt machen, die normalerweise anfangen könnten, diese Funktionen aufzurufen plugins_loaded. (Bewegen Sie sich einfach pluggable.phptiefer hinein wp-settings.phpund ich wette, die Hälfte des Kerns würde brechen - oder zumindest der Customizer.)

Schließlich gibt es die unvermeidliche Idee, dass ein Thema eine separate Datei enthalten pluggable.phpkönnte, die wir bereits beim Laden von Plugins laden und daher steckbare Funktionen überschreiben könnten. Abgesehen davon, dass dies eine schlechte Idee ist (siehe die ersten vier Absätze dieses Kommentars), wäre sie immer noch nicht kompatibel, da man bis zum setup_themeHook durch Filtern von Stylesheet- und Vorlagenwerten überschreiben könnte, welches Thema geladen werden soll.

Leider ist dies angesichts der Architektur von WordPress nicht haltbar. Das Gute ist, es gibt unzählige (bessere) Möglichkeiten, dies zu tun.

(Ursprünglich hier veröffentlicht: http://core.trac.wordpress.org/ticket/2479#comment:5 )

Im Rahmen eines einmaligen Projekts ist es absolut angemessen, Code zu verwenden, der unbedingt verwendet werden muss mu-plugins. Wenn es darum geht, "alles an einem Ort zu haben", erstellen Sie einfach einen Symlink im Themenverzeichnis zum mu-pluginsDrop-In, damit es beim Durchsuchen des Themenverzeichnisses angezeigt wird.

Ich kann mir keinen Weg vorstellen, dies zu früh in der Ladesequenz zu erreichen.

Die vernünftigste Lösung wäre das Hinzufügen eines benutzerdefinierten Includes zu wp-config.php(per Code oder Aufforderung an den Benutzer), aber ein Vergleich mit diesem Bündelungs-Plugin wäre wahrscheinlich sinnvoller.