Support » Allgemeine Fragen » Schema Markup mit custom fields individuell einfügen

  • Hallo,
    ich möchte gerne auf jeder einzelnen page meiner WP-site ein individuelles Schema-Markup manuell mit Hilfe von custom fields im Quellcode unterbringen. Das Markup ist als JSON-LD codiert, d.h., es ist ein script-tag, das aber kein wirklich ausführbares JavaScript ist.

    Das Markup soll nicht sichtbar erscheinen für Besucher, es handelt sich um Metadaten für z.B. Google. Es kann im Head, aber auch z.B. am Ende des body eingefügt werden.

    Ich habe hier eine Anleitung gefunden, https://torquemag.io/2016/12/schema-markup-wordpress/, würde aber gerne noch ein paar Sachen wissen dazu.

    Wenn man zusätzlich zu den auf jeder page dann eingerichteten custom fields deren Laden durch in obigem Artikel genannten PHP-Code

    <?php
    $schemamarkup = get_post_meta(get_the_ID(), 'schemamarkup', true);
    if(!empty($schemamarkup)) {
    	echo $schemamarkup;
    }
    ?>

    im Head erreichen will, wird dann wirklich auf jeder Seite deren individuelles JSON-LD-Markup geladen? Ich habe mal gelesen, man könne mit diesem php-Code für die header.php nur erreichen, dass dann auf jeder page ein und derselbe Inhalt eines custom fields geladen wird. Dann würde also überall das gleiche Markup geladen, ich habe aber auf jeder page ein anderes.

    Falls das grundsätzlich möglich ist, also per header.php individuelle JSON-LD-Markups pro page zu laden, muss dann der jeweils für jede page vergebene Name des custom field überall gleich sein, also z.B. „schema-markup“ lauten? Oder soll bzw. kann der Name überall unterschiedlich sein, z.B. „schema-startseite“, „schema-kontaltseite“ usw.?

    Könnte man so ein individuelles Laden von verschiedenem JSON-LD-Markup pro page anstelle der header.php auch allein mit der functions.php bewirken, wenn das Markup z.B. nicht zwingend im head des Quellcodes erscheinen muss, sondern am Ende des body?

    Grüße,

    Martin999

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)
  • Custom Fields (oder eigene Felder, wie sie in der deutschen Übersetzung heißen) werden in WordPress mit der Funktion get_post_meta() abgerufen. Ich finde die Funktion interessant, weil sie die ursprüngliche Funktion der Custom Fields beschreibt: Meta-Angaben zu einem Beitrag oder einer Seite (wobei hier das „post“ in get_post_meta() genauso Seiten oder andere Inhaltsarten meint). Wo immer Beiträge oder Seiten einzeln ausgegeben (also nicht zu Archiven zusammengefasst) werden, kannst du auch den Meta-Eintrag für genau diese Seite oder diesen Beitrag abrufen und z.B. im Theme-Template header.php ausgeben. Natürlich wird da nicht überall der gleiche Wert ausgegeben, aber die Art der Ausgaben – also z.B. dass die Information im Header steht – ist immer gleich.

    Eigene Felder kannst du zu jedem Beitrag und jeder Seite eingeben, ganz ohne Plugin oder zusätzliche Programmierung. Dazu musst du nur beim Bearbeiten von Seite oder Beitrag auf das Pulldown-Menü „Ansicht anpassen“ gehen und die Ansicht für „Eigene Felder“ aktivieren. Allerdings wird dir dann ein Formularfeld angezeigt, bei dem du ein beliebiges Paar aus Schlüssel und Wert erstellen kannst. Die Funktion
    get_post_meta( int $post_id, string $key = '', bool $single = false )
    erfordert als zweiten Parameter aber die Vorgabe eines Schlüssel.
    Nehmen wir an, du schreibst einen Reiseblog und möchtest zusätzlich zu deinen Berichten den Namen des besuchten Orts als Meta-Information angeben. Solange du einheitlich „Stadt“ als Schlüssel einträgst, kannst du zuverlässig get_post_meta( get_the_ID(), 'stadt' ); die Meta-Information ausgeben. Sobald du aber anfängst, den Schlüssel beliebig einzugeben, also z.B. mal als „Stadt“, mal mit Tippfehler „Start“, „Statt“, … oder mal als „Ort“, „Region“, „Dorf“, usw. liefert get_post_meta( get_the_ID(), 'stadt' ); nichts. Die Lösung sind so genannte Metaboxen, also Eingabefelder die bereits den Schlüssel („Stadt“) fest vorgeben und damit Fehler reduzieren.
    Weil das alles ein wenig umständlich zu programmieren ist, nutzen viele Anwender das Plugin Advanced Custom Fields, mit dem du Metaboxen in wenigen Sekunden einrichten kannst.

    Für die Ausgabe der Custom Fields kannst du entweder in einem Child Theme Code zu deinen Templates hinzufügen oder du nutzt ein Plugin wie Code Snippets und fügst dort eine eigene Funktion zur Ausgabe von Custom Fields hinzu. Mit add_action( 'wp_head', 'my_post_meta') bindest du die Ausgaben im Header ein, mit add_action( 'wp_footer', 'my_post_meta') im Footer. Die Lösung über Code Snippets ist deutlich wartungsfreundlicher als ein eigenes Child Theme, das nach jedem Update des Parent Themes auf mögliche Änderungen geprüft werden muss.

    Thread-Ersteller Martin999

    (@martin999)

    Danke für die verständlichen Ausführungen.

    Also wenn ich für jede page den gleichen einheitlichen Schlüsselnamen, z.B. „schema-markup“ verwende, dann wird bei den Seitenaufrufen durch Besucher immer individuell der jeweilige „Wert“ bzw. JSON-LD-Code der betreffenden page in den Quellcode eingefügt.
    Dass bei jeder page wegen des gleichen Schlüsselnamens dann sämtliche JSON-LD-Codes von allen pages in den head eingefügt werden, kann hoffentlich nicht passieren :). Ich gehe mal davon aus.

    Der zweite Schritt mit dem get_post_meta bewirkt dann die eigentliche Ausgabe bzw. Einfügung der jeweiligen Markups pro page. Entweder manuell in ein Template des child themes oder mit dem genannten Plugin.

    Grundsätzlich kann ich mir den Ort der Ausgabe aussuchen, denn Google ist mit head und body gleichermaßen einverstanden und technisch habe ich ebenfalls die Wahl – je nach gewähltem template. Oder können es nur die von dir genannten header.php und footer.php sein? Erinnere ich mich recht, dass der get_post_meta-Befehl immer am Ende der header.php bzw. footer.php muss? Das Plugin Code Snippet macht das vermutlich automatisch richtig.

    Spräche eigentlich etwas gegen die „vollmanuelle“, völlig untechnische Implementierung der pro Seite unterschiedlichen JSON-LD-Markups: Einfach das jeweilige script-tag im HTML-Modus des WP-Editors in den WP-Code der Seite einfügen?
    Anders als HTML-tags wie <p> <h1> usw. wird so ein script-tag

        <script type="application/ld+json">
        {
          "@context": "http://schema.org",
          "@type": "Person",
          "name": "George Bush",
          "disambiguatingDescription": "41st President of the United States",
          "children": {
            "@type": "Person",
            "name": "George W. Bush",
            "disambiguatingDescription": "43rd President of the United States"
          }
        }
        </script>

    doch nicht angezeigt für den Besucher, der die Seiten aufruft.

    Ginge dann halt nur im body, z.B. ganz am Schluss und nicht im head, aber was spräche sonst dagegen?

    Grüße,

    Martin999

    Erinnere ich mich recht, dass der get_post_meta-Befehl immer am Ende der header.php bzw. footer.php muss?

    Nein, wieso – kannst du überall einbauen, also entweder per Hook (wp_head/wp_footer) oder in einem Template.

    Einfach das jeweilige script-tag im HTML-Modus des WP-Editors in den WP-Code der Seite einfügen?

    Ja, Sicherheitsbedenken. Benutzer sollen im Editor kein JavaScript oder PHP ausführen. Deshalb wird dein <script … vom Editor in <script umgewandelt.

    Du kannst aber für jedes Feld deines JSON-Codes ein Eigenes Feld erstellen, was die Eingabe erleichtert.

    Abgesehen davon … hast du mal nach Plugins geschaut, die das schon vollständig umsetzen? Vielleicht gibt es da was und du kannst dir die Arbeit sparen.

    Thread-Ersteller Martin999

    (@martin999)

    Ja, Sicherheitsbedenken. Benutzer sollen im Editor kein JavaScript oder PHP ausführen. Deshalb wird dein <script … vom Editor in <script umgewandelt.

    Du meinst, WP wandelt es um von einem script mit Inhalt („Punkte“) zu leeren script-tags? Soweit ich weiß, ist es kein wirklich ausführbares JavaScript, sondern nur eine auf JavaScript basierende Markup-Sprache für Meta-Informationen und der „type“ sollte das eigentlich ausdrücken. Aber ob das WP versteht… du vermutest, WP hält das für ausführbares JavaScript?

    Ich habe es jetzt bei einer unwichtigen Seite einfach mal ausprobiert und den obigen Beispiel-Code von Ex-US-Präsident Bush am Ende des WP-Codes im Editor eingefügt, abgespeichert und dann im ausgegebenen Quellcode des Browsers angeschaut. Sieht alles ganz normal aus. Allerdings hat WP die script-tags in <p>-tags gepackt. Ob das für die Sumas dadurch dann wie Text behandelt wird und nicht wie JSON-LD-Code? Förderlich ist es wohl nicht.

    Du kannst aber für jedes Feld deines JSON-Codes ein Eigenes Feld erstellen, was die Eingabe erleichtert.

    Für jedes Feld ein eigenes Feld? Meinst du die ganz normale, oben angesprochene custom field plus „get_post_meta“-Option, bei der es so ein Problem nicht gibt? Oder meinst du eine weitere Variante, bei der ich custom fields etwas anders anwende?

    Abgesehen davon … hast du mal nach Plugins geschaut, die das schon vollständig umsetzen? Vielleicht gibt es da was und du kannst dir die Arbeit sparen.

    Ein Plugin, mit dem ich den JSON-LD-Code erstelle, will ich ganz bewusst nicht. Was das reine „Einfügen“ von JSON-LD-script-tags pro Seite an einer gewünschten Stelle angeht, alternativ zu den custom fields, das wäre eine Überlegung wert. Ich versuche halt immer, alles so einfach und „untechnisch“ wie möglich zu lösen, daher die Idee mit dem Editor-Code. Lieber ein Mal etwas mehr Arbeit und dafür eine langfristig sichere, leicht zu wartende und alles unter Kontrolle haltende Methode.

    Grüße,

    Martin999

    Bei meiner Antwort ist trotz Code-Formatierung untergegangen, was ich eigentlich schreiben wollte: Tags werden im Beitrags-/Seiten-Editor in Character Entities (Zeichen-Umschreibungen, z.B. „& lt;“ statt <) umgewandelt.

    Ich versuche halt immer, alles so einfach und „untechnisch“ wie möglich zu lösen, daher die Idee mit dem Editor-Code.

    Da wäre ein Plugin sicher die gescheitere Lösung. Für die Ausgabe der Custom Fields musst du schließlich auch Code einfügen.

    Thread-Ersteller Martin999

    (@martin999)

    Tags werden im Beitrags-/Seiten-Editor in Character Entities (Zeichen-Umschreibungen, z.B. „& lt;“ statt <) umgewandelt.

    Ich habe es mal ausprobiert und der obige Beispiel-Code über US-Präsident Bush ließ sich ohne Umwandlung der Tag-Klammer ganz normal eingeben, speichern und wird im Browser-Code auch unverändert ausgegeben. Mit einer Ausnahme: Der ganze script-tag wird in einen Absatz-tag <p> gepackt. Sieht dann so aus:

    <p><script type="application/ld+json">
        {
          "@context": "http://schema.org",
          "@type": "Person",
          "name": "George Bush",
          "disambiguatingDescription": "41st President of the United States",
          "children": {
            "@type": "Person",
            "name": "George W. Bush",
            "disambiguatingDescription": "43rd President of the United States"
          }
        }
        </script></p>

    Ist das eine neue Methode wie WP das script-Tag eliminiert, anstelle der Klammer-Umwandlung? Oder erkennt WP den eigentlich ungefährlichen (nicht ausführbaren) Code und verpasst hier WP einfach nur einen nötigen Container, ähnlich wie bei anderen Elementen, die irgendwo „drin“ sein müssen?
    Wie gesagt, eigentlich ist es ja kein gefährliches, ausführbares JavaScript, nur eine Sprache zur Codierung von Meta-Informationen.

    Da wäre ein Plugin sicher die gescheitere Lösung. Für die Ausgabe der Custom Fields musst du schließlich auch Code einfügen.

    Im Vergleich zur Option mit custom fields/header.php ist ein Plugin wohl kein großer Unterschied mehr, das stimmt. Wobei man nicht weiß, wie und was genau so ein Plugin macht.

    Im Vergleich zur vollmanuellen Eingabe direkt im Editor hingegen wäre ein Plugin technisch relativ „aufwendig“.

    Wenn das mit den Absatz-tags kein Problem darstellt, würde ich momentan diese Variante wählen.

    Grüße,

    Martin999

    Es ist scheinbar so, dass es auch an den Benutzerrechten und Vorgaben in der wp-config.php liegt, ob Benutzer im Seiten-/Beitragseditor ungefiltertes HTML eingeben dürfen:

    https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-some-users-allowed-to-post-unfiltered-html

    Grundsätzlich könntest du also wohl auch JSON in Beiträgen/Seiten einfügen. Ob das so sinnvoll und schön ist, ist dann eine andere Frage. Ich halte persönlich eine Eingabe in Custom Fields, die dann im Header oder Footer ausgegeben werden, für die sauberste Lösung. Ob du das mit einem Code Snippets umsetzt (wofür du wiederum ein Plugin installiert haben musst) oder rasch selbst ein Plugin schreibst, kommt aufs gleiche raus.

    Thread-Ersteller Martin999

    (@martin999)

    Verstehe. Dann ist es ja gut, dass ich Admin meiner Sites bin und das wird auch so bleiben. Die von WP zusätzlich vergebenen „<p>“ werden wohl nicht weiter stören.

    Grundsätzlich könntest du also wohl auch JSON in Beiträgen/Seiten einfügen. Ob das so sinnvoll und schön ist, ist dann eine andere Frage. Ich halte persönlich eine Eingabe in Custom Fields, die dann im Header oder Footer ausgegeben werden, für die sauberste Lösung.

    Die vollmanuelle Editor-Variante hätte vielleicht noch den Vorteil, dass sie zukunftsicher im Hinblick auf Gutenberg ist.

    Mit custom fields (und einheitlichem Schlüssel-Namen) das JSON-LD vom eigentlichen Content und auch im Handling sauber zu trennen, finde ich aber auch sympathisch. Ginge die Ausgabe im head oder body anstelle eines Codes in footer.php oder header.php eigentlich auch mit der functions.php auf ähnlich (relativ) einfache Weise? In der functions.php habe ich schon ein paar extra Kleinigkeiten drin, dann hätte ich alle „Extrasachen“ dort an einem Platz.

    Google bietet noch eine weitere, nämlich dynamische Variante an, die aber gerade für mich wohl am wenigsten in Frage kommt, da eher technisch anspruchsvoll: „Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets in your content management system.“
    Man könnte also nach dem Laden der Seite als Letztes noch per JavaScript den JSON-LD-Code zusätzlich laden lassen.

    Grüße,

    Martin999

    Ginge die Ausgabe im head oder body anstelle eines Codes in footer.php oder header.php eigentlich auch mit der functions.php auf ähnlich (relativ) einfache Weise?

    Ja, hatte ich bereits beschrieben: Du hängst deine Funktionen mit Hooks ein.

    Denk daran, dass die functions.php beim nächsten Update des Themes überschrieben wird. Um das zu vermeiden, musst du entweder ein Child Theme erstellen und dort eine functions.php anlegen oder ein Plugin wie Code Snippets nutzen.

    Thread-Ersteller Martin999

    (@martin999)

    Denk daran, dass die functions.php beim nächsten Update des Themes überschrieben wird.

    Da ich in der functions.php schon ein paar Kleinigkeiten drin habe, z.B. die Unterdrückung eines Emoji-JavaScriptes und der WP-Version, bin ich mir dessen bewusst. Ich hätte dann alle (bisherigen) „Besonderheiten“ eben nur an dieser einen Stelle, in der functions.php.
    Dies und die Tatsache, dass auch eine header.php beim nächsten theme-Update überschrieben wird, sprechen für den hook in der functions.php.

    Ist so ein Hook in der functions.php mit dem erforderlichen Code in der header.php vergleichbar bezüglich Resourcen, Zukunftssicherheit, Zuverlässigkeit ect.?

    Ich vermute, das sind beides recht normale WP-Standardfunktionen, die von Entwicklern beide recht häufig in ähnlicher Form angewendet werden und wohl auch in ein paar Jahren noch so funktionieren würden?

    Grüße,

    Martin999

    Dies und die Tatsache, dass auch eine header.php beim nächsten theme-Update überschrieben wird, sprechen für den hook in der functions.php.

    Da beide überschrieben werden ist das ja gerade keine Lösung. Außer du hast das Theme selbst geschrieben und es wird keine Updates geben, die das Theme überschreiben. Oder du hast ein Child-Theme gebaut und meinst die functions.php deines Child-Themes.

    Ich vermute, das sind beides recht normale WP-Standardfunktionen, die von Entwicklern beide recht häufig in ähnlicher Form angewendet werden und wohl auch in ein paar Jahren noch so funktionieren würden?

    Ja, das sind Standard-Hooks, die werden sich nicht ändern. Da bauen tausende / abertausende von Themes und Plugins darauf auf …

    Gruß, Torsten

    Thread-Ersteller Martin999

    (@martin999)

    Hallo Torsten,

    Da beide überschrieben werden ist das ja gerade keine Lösung. Außer du hast das Theme selbst geschrieben und es wird keine Updates geben, die das Theme überschreiben. Oder du hast ein Child-Theme gebaut und meinst die functions.php deines Child-Themes.

    „Lösung“ nicht, aber es ist auch kein sonderliches Problem, wenn header.php/functions.php bei Theme-Updates überschrieben werden. Zumindest bei der functions.php habe ich das fest auf dem Schirm, weil ich dort eh schon ein paar kleine Extracodes drin habe. Vergessen werde ich es also sicher nicht. Und ein wenig Code nach dem Update wieder reinkopieren ist keine große Sache. Oder ich lege mir ein Childtheme zu.

    Deswegen wäre mir ja die functions.php lieber als die header.php. Dann konzentriert sich das alles wie bisher nur auf die functions.php.

    Ja, das sind Standard-Hooks, die werden sich nicht ändern. Da bauen tausende / abertausende von Themes und Plugins darauf auf …

    Sehr gut, genau das wollte ich hören. Dann gehe ich mal davon aus, dass auch das auf mich wartende Gutenberg mit einer dann schon bestehenden custom field/functions.php-Variante problemlos zu Recht kommt. Ich finde die Quelle nicht mehr, aber irgendwo habe ich mal gelesen, dass Gutenberg an den custom fields/Metaboxen und deren Nutzung nichts Relevantes ändern wird.

    Wenn dem so ist, dann hätte ich mit der Option custom field/functions.php auf jeden Fall eine für mich gut funktionierende Alternative.

    Ob das besser ist, als die von mir zunächst ins Auge gefasste vollmanuelle Methode, also die JSON-LD-script-tags direkt in den Editor einzugeben bzw. reinzukopieren… ist mir noch nicht wirklich klar, weil ich an dieser „Holzmethode“ halt die Unabhängigkeit von Updates jeder Art und das „Techniklose“ recht sympathisch finde.
    Abgesehen von dem automatischen „in Absätze packen“ des JSON-LD-Markups durch WP (was sich auch deaktivieren ließe) scheint es zu funktionieren.

    Grüße,

    Martin999

Ansicht von 12 Antworten - 1 bis 12 (von insgesamt 12)
  • Das Thema „Schema Markup mit custom fields individuell einfügen“ ist für neue Antworten geschlossen.