Bricks-Archiv-Template greift auf der falschen Taxonomie

Das Symptom ist unauffällig genug, um es zu übersehen: Auf /glossar_kategorie/kraeuter/ steht in der Breadcrumb plötzlich „Blog“, der Zurück-Link führt ins Blog-Archiv, und der Beitrags-Loop ist komplett leer.

Die Ursache liegt nicht bei der Glossar-Taxonomie, sondern bei einem ganz anderen Template — dem Blog-Kategorie-Archiv, dessen Bedingung zu weit gefasst ist.

Getestet mit

• WordPress 6.8
• Bricks 2.3.7
• Zwei Taxonomien: category (Standard) und glossar_kategorie (eigene, an einem CPT)

Wo die Zuordnung wirklich steht

Bricks speichert die Template-Bedingungen nicht dort, wo man sie vermutet, sondern in der Post-Meta des Templates:

wp post meta get TEMPLATE-ID _bricks_template_settings --format=json --path=/PFAD/ZUR/INSTALLATION

Das ist die einzige verlässliche Quelle. Was die Oberfläche anzeigt, ist eine Interpretation davon.

Die Bedingung, die zu breit greift

So sah das Blog-Kategorie-Template aus:

{
  "main": "archiveType",
  "archiveType": ["term"],
  "taxonomy": ["category"],
  "id": "a1b2c3"
}

Das sieht völlig plausibel aus — Term-Archiv, Taxonomie category, fertig. Tatsächlich schränkt der Schlüssel taxonomy aber nicht ein. Er wird bei der Auswertung nicht als Filter herangezogen. Übrig bleibt „jedes Term-Archiv“ — und damit fängt dieses Template auch die Glossar-Kategorien ab.

Die Bedingung, die funktioniert

Der wirksame Schlüssel heißt archiveTerms. Er nimmt Einträge im Format taxonomie-slug::all oder taxonomie-slug::term-id:

{
  "main": "archiveType",
  "archiveType": ["term"],
  "archiveTerms": ["category::all"],
  "taxonomy": ["category"],
  "id": "a1b2c3"
}

taxonomy darf zusätzlich stehenbleiben, ersetzt archiveTerms aber nicht.

Wenn ein Template gleichzeitig ein CPT-Archiv und dessen Term-Seiten abdecken soll, sieht das so aus:

{
  "main": "archiveType",
  "archiveType": ["postType", "term"],
  "archivePostTypes": ["glossar"],
  "archiveTerms": ["glossar_kategorie::all"],
  "taxonomy": ["glossar_kategorie"],
  "id": "d4e5f6"
}

Zwei Stunden am falschen Template

Ich habe die ganze Zeit am Glossar-Template gesucht. Bedingungen umgestellt, Loop-Query geprüft, Rewrite-Regeln neu geschrieben, Caches geleert. Das Glossar-Template war die ganze Zeit korrekt konfiguriert.

Mein Denkfehler: Ich bin davon ausgegangen, dass ein spezifischeres Template automatisch gewinnt. Tut es nicht zuverlässig. Wenn mehrere Templates auf dieselbe Seite passen, entscheidet die Reihenfolge — und ein zu breit konfiguriertes Template reißt alles an sich, was ihm zuerst unterkommt.

Sichtbar wurde es, als ich alle Archiv-Templates gleichzeitig ausgelesen habe statt nur das vermeintlich schuldige:

wp post list --post_type=bricks_template --format=ids --path=/PFAD/ZUR/INSTALLATION 
  | tr ' ' 'n' 
  | while read id; do
      echo "--- $id $(wp post get $id --field=post_title --path=/PFAD/ZUR/INSTALLATION)"
      wp post meta get $id _bricks_template_settings --format=json --path=/PFAD/ZUR/INSTALLATION
    done

Woran ich das nächste Mal zuerst denke: Bei einem Template, das an der falschen Stelle rendert, ist selten das Template schuld, das man erwartet. Erst alle auflisten, dann nach dem suchen, dessen Bedingung zu wenig Einschränkung enthält.

Zwei weitere Stolpersteine

archiveType: ["taxonomy"] matcht eine einzelne Term-Seite nicht. Der richtige Wert ist "term". Das ist verwirrend, weil in der Oberfläche von „Taxonomie“ die Rede ist.

Das reine CPT-Archiv, also /glossar/ ohne Term, braucht eine eigene Bedingung mit "main": "postType". Es fällt nicht unter archiveType.

Kontrolle

Nach jeder Änderung beides prüfen — Meta zurücklesen und Frontend mit Cache-Umgehung:

wp post meta get TEMPLATE-ID _bricks_template_settings --format=json --path=/PFAD/ZUR/INSTALLATION
curl -s "https://DEINE-DOMAIN.AT/glossar_kategorie/kraeuter/?nocache=$(date +%s)" | grep -c 'glossar-card'

Die zweite Zahl muss größer als null sein. Kommt null zurück, greift immer noch ein fremdes Template.

Häufige Fehler

Die Bedingung ist richtig, es rendert trotzdem falsch.
Prüf, ob ein zweites Template ebenfalls passt. Bricks meldet keinen Konflikt, es nimmt einfach eines.

Der Loop im Archiv bleibt leer.
Die Query im Archiv-Loop muss auf is_archive_main_query stehen. Eine eigene Query ignoriert den Term der aktuellen Seite.

Muss ich die ID der Bedingung selbst vergeben?
Ja, jede Bedingung braucht eine eigene id aus sechs Zeichen. Ohne ID wird der Eintrag stillschweigend verworfen.