Seit dem letzten Update der PRO Version im Februar 2019 sammelten sich eine Reihe von Nutzerwünschen und Bugfixes, die in Betaversionen mündeten. Nun bündelte ich und veröffentlichte die neue Version 3.4.13. Ausgiebige Tests zeigten, dass Alles rückwärtskompatibel ist. Nichts desto trotz ist es immer wieder spannend, ob sich nicht irgendwo, irgendwie ein Fehler oder eine Seltsamkeit „meldet“. Dann heisst es schnell sein und ggf. korrigieren.
Das hat sich in der Version 3.4.13 geändert – fast alle Änderungen betreffen das Erzeugen von Custom Post Types:
- Custom Fields beim Erzeugen von Custom Post Types:
Custom Fields können im Shortcode mit dem Parameter „createoptions“ definiert werden. Dieser isr in JSON codiert mit dem Schlüssel „customfields“.
Beispiel:
#BRO# {„extracustomfield1“: „extravalue1“}, {„1#SEP#extracustomfield2“: „extravalue2#SQM #SingleQuote#SQM#“}, {„2#SEP#extracustomfield2“: „extravalue3“} #BRC##BRO# und #BRC# steht für Bracket-Open/-Close für die JSON-Syntax. Würde man „echte“ eckige Klammern benutzen, käme WordPress durcheinander, da diese auch für den Shortcode selbst genutzt werden. #SQM# ist der Platzhalter für „Single Quote“. Mit „integer#SEP#“ kann man mehrere gleiche Schlüssel für die Custom Fields anlegen (hier: „extracustomfield2“ ist der Schlüssel) - Datum der erzeugten Custom Post Types:
Im JSON von „createoptions“ kann man mit dem Schlüssel „postdateoffset“ das Datum der Custom Post Types bestimmen. Ist der Wert des JSON-Schlüssels nicht gesetzt, wird die aktuelle PHP-Servertime genutzt. Diese ist ggf. anders als die WordPress-Zeit (insbes. bzgl. Zeitzonen).
Drei Varianten für den Wert des Schlüssels gibt es:
Falls der Wert eine Zahl ist, wird diese Zahl von der aktuellen PHP-Serverzeit als Sekunden abgezogen. (eine Stunde sind 3600 Sekunden).
Wenn der Wert „wptimezone“ ist, wird die Zeitzone der WordPress-Installation genutzt. Zeitzonen kann man auch mit dem „timezonestring“ festlegen. - Was macht man mit früher erzeugten Custom Post Types beim nächsten Einspielen neuer JSON-Daten? Bisher könnte man entweder alle alten CPTs löschen oder alle beibehalten.
Nun kann man mittels „some“ bei „deleteold“ im JSON von „createoptions“ das etwas flexibler machen.
Wenn „some“ gesetzt ist, kann man den key für alle CPTs mit twig-code versehen und so individuelle keys je CPT erzeugen, die von den JSON-Daten abhängen. Nur die CPTs werden bei einem Update gelöscht, deren key der gleiche ist wie bei einem neuen CPT. - Dazu kamen ein paar Bugfix e mit speziellen Buchstaben und dem Debugmode.
- Neu ist ein Shortcode-Parameter: Wenn „forcetemplate=1“ gesetzt ist, werden die Einstellungen aus dem JCI-Template sicher verwendet (andernfalls, im Normalfall überschreiben die Parameter aus dem Shortcode die des Templates)
