Archiv der Kategorie: editor

Positionierung von Custom Fields oder wie bekomme ich Felder in die Sidebar: Der ‚context‘-Parameter ist dein Freund!

Wir verwenden ACF und Custom Fields sehr häufig um unseren Produkten einen deutlich komplexeren Aufbau zu ermöglichen.
Daher machen wir uns auch immer reichlich Gedanken darüber, wie wir den Aufbau so einfach und logisch wie möglich gestalten können.

Dazu gehört nicht nur die Auswahl der Darstellungsform, sondern natürlich auch die Auswahl des Orts, wo wir unsere Custom Fields eingeblendet haben wollen.

Wenn ein Artikel z.B. ein alternatives Beitragsbild erhalten soll, ist es unsinnig dieses Feld direkt nach dem Titel anzuzeigen. Es sollte natürlich seitlich in der Nähe des primären Beitragsbild zu finden sein. Und das können wir ja ganz einfach steuern, oder?

Custom Fields und ACF

Wie wir Custom Fields erstellen, soll hier nicht Thema sein. Daher gehe ich nur auf die Funktion ein, mit der wir die Position festlegen können.

Hierfür verwenden wir die Funktion „add_meta_box( $id, $title, $screen, $context, $priority, $callback_args );„. Diese Metabox soll dann unsere Custom Fields beherbergen.

Der „context“ gibt dabei an, in welchem Bereich die Metabox angezeigt werden soll und mit „priority“ können wir zu einem bestimmten Grad festlegen, ob die Metabox vor oder nach anderen Metaboxen angezeigt wird.

ACF hat dafür natürlich einen eigenen Einstellungsbereich, bei dem wir ohne etwas zu programmieren zu unsern Custom Fields kommen.

Beispiel für die ACF Einstellungen

Hier im Screenshot sehen wir die Auswahl der Position unserer neuen Feldgruppe mit ACF.

Die Freiheit der Benutzer, die (unnötige?) Arbeit des Entwicklers

Egal wie gut und durchdacht unsere Logik dahinter ist, so bietet WP jedem Benutzer die Möglichkeit seine Eingabemaske so umzustellen, wie er oder sie es gerne hätte.

Denn die Informationen, wie Custom Fields und ACFs im Backend angezeigt werden, speichert WP in der Datenbank für jeden Nutzer einzeln in der Tabelle „_usermeta“ mit dem Key „meta-box-order_page“ ab.

Aber ist diese Geistesanstrengung dann überhaupt nötig?

Absolut! Immerhin dürfen wir nicht vergessen, dass der Großteil der Nutzer dieses Feature vermutlich gar nicht kennt. Außerdem zählt ja auch der erste Eindruck. Und den geben immer noch wir vor!

Aber einen wichtigen Punkt gibt es hierbei zu bedenken und der ist auch der Grund für diesen Artikel.

Achtung bei nachträglichen Änderungen

Sobald wir uns entscheiden, ein Feld im Nachhinein umzustellen, kann es passieren, dass ein Nutzer von dieser Umstellung nichts mitbekommt.

Denn jeder Nutzer, der bereits aktiv mit unseren Custom Fields oder unsern ACFs gearbeitet hat, der hat noch die alten Positionsangaben in der Datenbank stehen und ist somit von unseren Umstellungen ausgeschlossen.
(Zumindest solange wir hier nicht programmatisch eingreifen und auch gleich diesen Wert in der „_usermeta“-Tabelle ändern…)

In Kurz: Hat ein User bereits ein bestehendes ACF-Feld bearbeitet, wird zu den Usermetadaten die Aufteilung des Backends gespeichert und Änderungen kommen beim User nicht an!

Das ist für alle Entwickler zu bedenken, die im Nachhinein ACF-Felder bearbeiten und in der Position verschieben.

 

weiterführende Links:

Custom Fields

Custom Meta Boxes

add_meta_box()

Creating a Field Group

Problem beim Post erstellen bei >300.000 Posteinträgen – Eltern-Dropdown (Page Parent) entfernen

WordPress und hohe Postanzahl

WordPress kommt gut mit Instanzen zurecht, die mehr als 300.000 Beiträge, Seiten oder andere Custom Post Type Einträge aufweisen.

Obwohl sich in der Datenbank aufgrund von Autosaves und Revisionen ein Vielfaches von 300.000 Einträgen befindet, sind Seiten im Front- und Backend noch geschmeidig bedienbar.

Das trifft auch auf Sharedhosting wie Uberspace zu, was viele im Vorhinein nicht vermuten würden.

Problemzone Elternseiten-Dropdown

So ganz uneingeschränkt stimmt das nicht.
Ein riesiges Problem ist das Elterndropdown im Backend:

Eltern- oder Pageparent Dropdown
Eltern- oder Pageparent Dropdown

In diesem Dropdown werden alle Seiten aufgelistet, die es so gibt.
Das heißt, dass ALLE Seiten/CPT aus der Datenbank geholt werden. Das ist schon mal ein Performanceproblem, da das eine ressourcenfressende Abfrage ist.

Das nächste Problem besteht darin, alle Seiten dann in HTML umzusetzen. Es kommt also für jeden Eintrag ein weiteres Objekt in dem Dropdown hinzu.

Bei zb vier Einträgen wie hier ist das kein Problem:

Dropdown-Einträge im HTML-Quelltext
Dropdown-Einträge im HTML-Quelltext

Müssen aber zb 300.000 Einträge erstellt werden, wird das schnell zum Flaschenhals am Webserver.

Also:

Der Webserver wird dadurch extremst ausgelastet und es kann zu einem Ausreizen des Arbeitsspeichers oder der Exec-Time kommen.

Was dann passiert, sollte klar sein, oder?

Wir bekommen eine (meist) weiße Seite mit einem Server-Error.

Das liegt sicher nicht in unserem Interesse.

Lösung: Dropdown beseitigen, zb

Einerseits könnte man aus dem Dropdown ein Autovervollständigenfeld machen, wie das zb bei der Tag-Auswahl bekannt ist.

Wenn man aber die Auswahl der Elternseite sowieso nicht braucht, kann man diesen Bereich gleich ganz entfernen.

Bei selbst erstellen Post Types reicht es, wenn ‚page-attributes‘ bei ’supports‘ weggelassen wird:

Register Post Type Beispiel
Register Post Type Beispiel

Dadurch erhält der Post-Type im Backend auf der Bearbeitenseite gar kein Dropdown, um ein Elternelement auszuwählen.

Wenn ich einem bestehenden Post-Type, wie zb „page“, das Dropdown wegnehmen möchte, brauche ich die Funktion remove_post_type_support():

Das war’s auch schon!

Links

https://codex.wordpress.org/Function_Reference/remove_post_type_support

https://codex.wordpress.org/Function_Reference/register_post_type

Gutenberg – Der neue WordPress Editor. Letztes Update vom 25.10.

Das hier wird ein Sammelartikel zu all den Neuigkeiten rund um Gutenberg.

Daher gibt’s hier laufend Erweiterungen und Updats.

Neue Artikel und Meinungen werden am Ende eingefügt!

  • Update vom 09. Oktober – Linkschleuder erweitert
  • Update vom 04. Oktober – Joost über Gutenberg
  • Update vom 23. + 25. Oktober: Metaboxen in Gutenberg angekommen

Was ist Gutenberg?

Gutenberg soll den derzeitigen Artikel-Bearbeiten-Bereich ersetzen.

Von der Idee her geht man weg von einem Contenbereich hin zu mehreren.

So kann man Content übereinanderstapeln oder untereinanderreihen. Inhalte werden dann in Zeilen, ähnlich Tabellenreihen, organisiert.

Man kann dann Inhalte verschieben – also ein Bild zwischen andere Bilderzeilen oder Textzeilen schieben.

Ziel

Der Editor von WordPress ist veraltet und fühlt sich auch nicht so hilfreich an.

WordPress wird von ähnlichen Apps wie wiix oder medium o.ä.  mächtig Feuer unter dem Arsch gemacht.

Warum?

Weil die bearbeitungsfreundlicher sind.

Außerdem möchte WodPress die ganzen Sitebuilderplugins mit Gutenberg ersetzen.

Generelle Infos

  • https://wordpress.org/plugins/gutenberg/
  • https://wordpress.github.io/gutenberg/

     

Diverse Infos

Gutenberg bekommt Metaboxen!

 

Ein großer Kritikpunkt an Gutenberg war die fehlende Unterstützung von Custom Fields/Metaboxen.

Mit nachfolgendem Commit sollte die Kritik nun langsam verstummen:

 

 

 

https://github.com/WordPress/gutenberg/commit/02d4734e667cbd423d78636bda5d34ec580bb3f9

Mehr Infos hier:

Gutenberg und WordPress lassen React fallen. Daraufhin ändert Facebook die Lizenz auf MIT ohne Anhang.

Matt Mullenweg beantwortet exzessiv Fragen zu Gutenberg:

Matt klärt ein paar offene Punkte zu Gutenberg und verteidigt einige Entscheidungen:

 

Die React-Problematik

Dazu möcht ich mich nicht lange auslassen, weil es hier um Patente und Lizenzrecht geht – und da amerikanisches Recht involviert ist..

React „gehört“ Facebook.

React steht nicht unter der GPL oder der MIT.

Wer React benutzt stimmt zu, dass man nicht mit Facebook wirtschaftlich konkurriert. Verkürzt gesagt.

Ein sehr provokativer Artikel dazu ist folgender:

https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2 – Wenn du ein Startup bist, verwende nicht React. (Wenn du darauf hoffst, von einer großen Firma aufgekauft zu werden)

Die Hauptaussage ist, dass es Probleme gibt, wenn man React benutzt und an eine andere Firma verkauft. Weil sich andere Firmen die Lizenzproblematik nicht einhandeln wollen.

GRAVIERENDES UPDATE

Das galt bis Anfang Oktober 2017. Facebook hat die Lizenz nun auf die MIT-Lizenz ohne Anpassungen geändert.

 

Meinungsspiegel

Joost de Valk von Yoast SEO über Gutenberg

  • https://yoast.com/gutenberg-alternative-approach/
  • Joost findet es gut, dass WordPress mit Gutenberg benutzerfreundlicher wird.
  • Gutenberg ist eine moderne Kopie des Medium-Editors.
  • Joost hat bedenken wegen JavaScript, der Geschwindigkeit/des Zeitplans der Entwicklungen
  • Es fehlen Schnittstellen zum Reinhängen in die Blocks – Yoast SEO kann noch nicht in die Gutenberg-Blocks integriert werden.
  • Es fehlen die Metaboxen und Joost kritisiert, dass die Gutenberg-Entwickler Metaboxen eventuell weglassen wollen.
  • Accessibility ist eine große Baustelle
  • Es gibt einen Vorschlag für ein mögliches Aussehen von Gutenberg – hier werden die Metaboxen ganz normal angezeigt:

 

 

Linkschleuder