So schaut die Mediawiki-Syntax schlussendlich formatiert im Frontend aus!
Konvertierung mit Pandoc
Pandoc ist eine Kommandozeilen Bibliothek, mit der man Texte und Dateien aus verschiedene Formate in verschiedene Formate exportieren kann.
Habe ich zb die Datei reisen.wiki, die in der Mediawikisyntax geschrieben ist, hilft mir folgender Befehl, wenn ich die Seite nach HTML umwandeln will.
Wir haben daher die Seiten von der Wikimedia-Syntax in das Markdown Format überführt.
Warum? Weil man damit keinen unnötigen Code hat und es für WordPress super Markdown-Plugins gibt.
Ursprünglich war die Idee, die Wikieinträge nicht zb nach Markdown umzuwandeln, sondern gleich in ein sauberes (saubereres) HTML. Das Ergebnis schaut dann aus wie in den folgenden Screenshots wobei zu beachten ist, dass das oben gezeigte Bild (rosarotes Österreich) nicht verlinkt ist, weil aus der Mediawiki-Syntax nur der Bildname im SRC des Image-Tags übrig bleibt.
Problem der Umwanldung nach HTML
Hat man in einem Wiki-Artikel zb Codeteile drin, die mit Codehighlighting sichtbar gemacht werden, wirds umständlich:
Umständlich, weil Pandoc freundlicherweise Css-Regeln einfügt.
Was grundsätzlich eh super ist, weil ich dann das Code-Highlighting im Export/in der umgewandelten HTML-Datei habe:
Das ist für die Weiterverwendung in WordPress aber suboptimal.
Weil ich dann im Beitragsinhalt/im Content CSS-Regeln habe, und die dort nicht hin gehören.
Alternativen
Man könnte den XML-Export vom Mediawiki verwenden. Dann braucht man auf WordPress-Seite einen Importer. Die XML-Exportdatei gefällt mir nicht so gut. Mit der Umwandlung in ein aufgeräumtes HTML von Pandoc kann ich die Inhalte gleich in den WordPress-Editor reinkopieren.
Markdown in WordPress
Mit diesem Markdown-Plugin https://wordpress.org/plugins/wp-githuber-md/ wird der Inhaltseditor angepasst und schaut dann so aus:
Auf der linken Seite hab ich den markdown formatierten Text, rechts das Ergebnis, das auch im Frontend angezeigt wird:
Die Dokumentation der WP JSON API ist nach wie vor recht spärlich. Die JSON-API fühlt sich immer noch ein bisserl wie ein Stiefkind an, aus WordPress Entwickler Sicht.
Was ich nicht ganz verstehen kann, denn Gutenberg setzt verstärkt darauf.
Gutenberg ist der WordPress-Core eigene Pagebuilder, der stark auf JavaScript (React) setzt, und daher von einer JSON-API profitiert.
Das als kleiner Exkurs 🙂
Wir beschäftigen uns gerne mit der WP API, zb hier und hier.
Worum geht es in dem Artikel? Einfach! Post Thumbnails
Beitragsbild mit JSON API holen
Will ich ein Post Thumbnail mit einem JSON Call holen, hilft mir die WordPress Dokumentation wenig.
Mit ein wenig Recherche bei Github/im Codeverwaltungssystem wird man aber fündig:
Ich bekomme durch den angehängten Parameter umfangreiche Infos zum Beitragsbild zb auch die diversen URLS der verschiedenen Bildergrößen, dich ich für responsive Images brauche:
Alternativen
Es gibt ein paar Hooks, mit denen ich den JSON-Response ändern kann. Nur: Warum sollte ich mir die Arbeit machen, das per HOOK und PHP zu lösen? Es gibt sicher Anwendungsfälle, aber für eine schnelle Lösung ist das nix.
Es gäbe auch ein Plugin, wer PHP nicht angreifen kann:
Damit die eigenen Artikel oder Produkte heutzutage aus der Masse heraus stechen, sollte man tief in die Trickkiste greifen.
Dieser Artikel soll aber nicht an dieser Trickkiste rütteln, sondern zwei Techniken näher beleuchten, die einem dabei helfen können. Es geht dabei um die HTML5 Attribute „srcset“ und „sizes“ und um die Technik des „lazy-loadings“.
Das Grundproblem
Wenn ich heute als Autor im Internet ein Bild hochlade, dann ist mir meist egal, welche Größe das Bild hat. Immerhin lebe ich Österreich oder Deutschland in einem Land, das mir schnelles, unlimitiertes Internet für wenig Geld anbietet. (Gut – für Deutschland gilt das unter Vorbehalt :p )
Doch bereits in Deutschland gibt es Orte, an denen das bereits Luxus ist. Um allen Nutzern der Website das best mögliche Erlebnis zu bieten, sollte ich die Bilder also besser aufbereiten, damit niemand mehrere Sekunden warten muss oder mehrere MB herunterladen muss, um die Seite komplett sehen zu können.
Die Techniken
srcset- & sizes-Attribut
Der erste Bereich sollte heutzutage wirklich kein Thema mehr sein.
Diese Funktionen geben mir bereits alles was ich brauche. Sie liefern gleich das ganze HTML mit dem srcset- und dem sizes-Attribut aus. Für Bilder, die nicht als featured-image eingebunden wurden, gibt es noch die Funktion „wp_get_attachment_image( $attachment_id )“, der wir als ersten Parameter die „$attachment_id“ des Bildes übergeben.
Auch hier erhalten wir wieder ein voll funktionsfähiges HTML mit srcset- und sizes-Attribut. Praktisch, dass WordPress im Hintergrund ohnehin für jedes hochgeladene Bild mehrere Versionen für die verschiedenen Größen anfertigt und auf der Festplatte des Servers abspeichert.
img-Element mit srcset- und sizes-Attribut
Aber da wir immer wieder auf Themes stoßen, die die beiden Attribute noch nicht verwenden, möchte ich hier auf ein praktisches Plugin verweisen, das Bilder aus dem Contentbereich nachträglich das srcset-Attribut verpasst.
responsify-wp
Es handelt sich um „responsify-wp“ von Stefan Ledin. Für das Plugin sei allerdings angemerkt, dass seine Möglichkeiten begrenzt sind und z.B. keine Bilder außerhalb des eigentlichen Contents mit den mächtigen HTML5-Attributen versehen kann.
Die wichtigsten Einstellungen zu responsify-wp
Sollte ein Theme sehr viele verschiedene Bildgrößen definieren, kann man in den Einstellungen praktischerweise steuern, welche Bildgrößen für die beiden Attribute verwendet werden sollen. Das verhindert das unnötige aufblähen des img-Elements.
responsify-wp. Steuerung, welche Bildgrößen verwendet werden sollen.
Warum sind diese Attribute somächtig?
Nun durch diese Attribute kann sich der Browser selbst aussuchen, in welcher Größe das Bild geladen und angezeigt wird. Auf Smartphones, deren Bildschirm sehr viel kleiner ist als ein 24‘‘ Bildschirm, brauche ich kein Bild laden, das die 9 fache Größe hat, oder? Das wäre in mehrfacher Hinsicht unnötig.
lazy-loading
Beim lazy-loading geht es nicht mehr darum, wie groß das Bild an sich ist, sondern darum, ob das Bild überhaupt geladen/angezeigt werden soll.
Bilder, die auf dem aktuellen Bildschirmausschnitt nicht zu sehen sind, müssen nicht unbedingt vom Server heruntergeladen werden.
Wer kann schon wissen, ob der Nutzer überhaupt weitere Bereiche der Seite ansieht oder nicht vielleicht schon auf einer anderen Seite ist?
Daher haben wir in weiterer Folge ein paar Tipps für Plugins, die einem das ermöglichen.
Anders als das srcset-Attribut, das in seiner Handhabung nun wirklich keine Hexerei ist, ist es doch mit erheblichem Mehraufwand verknüpft, diese Funktionalität selbst zu programmieren. Deshalb besprechen wir ein paar Plugins.
Dominant colors lazy loading
Zu Beginn hätten wir mit „Dominant colors lazy loading“ einen besonders interessanten Vertreter, der diese Funktion auch gleich mit einem weiteren grafischen Schmankerl versehen hat.
Zu Beginn wird die Mediathek vom Plugin nach Bildern durchsucht um eine dominante Farbe aus jedem einzelnen Bild zu identifizieren.
Einstellungen des Plugins ‚dominant colors lazy loading‘
So lange das Bild nicht geladen wird, wird der Bereich des Bildes stattdessen in der zuvor errechneten dominanten Farbe angezeigt.
Das löst auch gleich ein anderes Problem, das auftreten kann, wenn Bilder sehr viel später auf der Seite angezeigt werden, als reiner Text. Wenn statt dem Bild einfach nichts gezeigt werden würde, müsste sich das Bild erst einen Platz verschaffen um angezeigt zu werden. Dadurch kann es zu unschönen Sprüngen im Contentbereich kommen.
‚dominant colors lazy loading‘ bei der Arbeit: Aus einem hell-braunen Platzhalter wird ein Bild
Bei diesem Plugin ist zu beachten, dass es die WordPress-typische CSS Klasse (z.B. wp-image-5) für Bilder benötigt, um seiner Arbeit nachgehen zu können.
Sollte ein Theme diese nicht hinterlegt haben, wird dieses Plugin leider nicht funktionieren.
Andere lazy loading Plugins
Daneben sind noch „rocket lazy load“ und vor allem „crazy-lazy“ zu erwähnen, die in den meisten Fällen ohne Probleme funktionieren sollten. Ein etwas älterer Vertreter ist „lazy-load“, das allerdings seit über 2 Jahren kein Update mehr erhalten hat.
Google macht ja schon länger in WordPress. Angefangen von Webinaren, Videoanleitungen und Tutorials über AMP und bezahlte Entwickler, die WordPress-Code beitragen.
Google hat also sowieso im WordPress-Universum einen Fuß in der Tür.
Jetzt geht man anscheinend einen Schritt weiter, was für die Zukunft einige Umbrüche bringen könnte.
Google sucht WordPress-Entwickler
Alberto Medinas Blogpost mit dem Aufruf an WP-Entwickler
Google sucht also nach WordPress-Entwicklern, die sich an folgende Themen ranmachen sollen:
Projekt Gutenberg vorantreiben, damit die Usability besser wird (Dringend notwendig)
Themes erstellen, die moderne Webtechnologien verwenden
Mitarbeit am AMP-Plugin (ich persönliche halte wenig von AMP!)
Mitarbeit am TIDE-Plugin (Plugin zur Bewertung der Codequalität von Plugins uvm)
Google Sitekit Plugin um AdSense-, Analytics-, PageSpeed- und Suchkonsolen-Daten gebündelt im WordPress Dashboard anzeigen zu können.
Diesem Aufruf sind schon mehrere bekannte Namen aus dem WordPress-Universum gefolgt, der bekannteste dürfte derzeit Weston Ruter sein, der in seinem Blogpost seine Beweggründe erklärt:
Gerücht am Rande: Laut Informierten, bezahlt Google in der Schweiz ein Einstiegsgehalt von 170.000 Franken – gerüchteweise ohne Garantie auf Richtigkeit.
Hintergründe: Mitbestimmung beim wichtigsten CMS?
Google meint es also ernst.
Warum überhaupt?
WordPress ist die Unterlage von ca 30% der Webseiten überhaupt. Es wäre von Google fahrlässig, hier irgendwelchen Playern das Feld allein zu überlassen ohne ein Mitspracherecht zu haben.
Die Strategie erinnert ein wenig an Microsoft – und das erste Bild in diesem Blogpost hat eine umwerfende Ähnlichkeit zu diesem Sujet:
Microsoft liebt Linux? Und Google jetzt WordPress? Zufall?
Microsoft weiß um die Dominanz von Linux in der Serverumgebung.
Google weiß um die Dominanz von WordPress im CMS-Umfeld.
Beide wissen, dass sie sich aktiv an der Entwicklung dieser Open Source Projekte kümmern müssen, um mitbestimmen zu können.
Das Problem bei Open-Source-Projekten aus der Sicht von Unternehmen ist halt, dass da meist Individualisten, Querköpfe und Spinner am Werk sind. Programmierer eben.
Und Programmierer sind meist schlechte Führungspersönlichkeiten.
Daher sind Ziele oft verwässert oder Entwicklungen gehen in falsche Richtungen oder Zersplittern sich uvm.
WordPress ist da ein bissl anders gelagert:
Besondere Situation von Automattic in der open source Welt
WordPress ist zwar open source, also kann von jedem verwendet und verändert werden.
Aber hinter WordPress steht eine erfolgreiche Firma, die eigentlich über alle Aspekte von WordPress bestimmen kann.
Angefangen vom Namen und Logo. Beides gehören Automattic bzw einer Stiftung rund um den Gründer von Automattic, Matt Mullenweg.
Matt gibt auch die Schlagrichtung vor. Also wohin sich WordPress als Projekt bewegen soll. Welche Ziele in den nächsten Releases, also den nächsten Versionen, verfolgt werden sollen.
Das hat alles sein Gutes. Automattic bezahlt eine Menge an Entwicklern, die am WP-Sourcecode weiterschreiben. Den Core also weiterentwickeln, verbessern und aktuell halten.
Gemäßigter Diktator als Warnsignal für Google?
Das ist ein großer Vorteil gegenüber anderen Open Source Projekten, die keinen potenten Geldgeber im Hintergrund haben.
Ohne Matt und Automattic gäbe es WordPress in der Form nicht. Da steckt sehr viel „privates“ Geld in einem quelloffenen CMS. Das eigentlich von Nerds und Spinnern programmiert wird. Gerade open source Communitys haben selten eine Führungsperson.
Liste bekannter gemäßigter Diktatoren (BDFL) auf Wikipedia
Und Diktatoren sind halt das, was sie sind: Machtmenschen, die oft irgendwann den Bezug zur Realität verlieren.
Wäre ich Entscheider bei Google, würde mich sowas hellhörig machen.
Realitätsverlust? Gutenberg-Drama? Betriebsblindheit? Wird Matt wunderlich?
WordPress ist gerade im Umschwung.
Mit Gutenberg kommt ein neuer Editor, der von der Idee her wirklich Gutes bringen wird.
Derzeit ist Gutenberg aber für Ottonormalverbraucher quasi unbenutzbar.
Die einfachsten Dinge sind nicht offensichtlich zu lösen.
Zb das Einfügen von Bildern in einen Text ist eine grenzwertige Erfahrung. Das hab ich von Anfang an kritisiert und auch den Core-Entwicklern mitgeteilt. Geändert hat man seitdem nix.
Das Bilder-Einfügen ist also seit Anbeginn ein ungelöstes Problem und wird auch nicht Behoben, da von den Entwicklern und von Matt als „kein Problem“ angesehen werden.
Und da beginnen die Probleme. Die Offenheit der Core-Entwickler, die ja zu einem guten Teil Automattic-Mitarbeiter sind, ist nicht gegeben.
Im Gegenteil: Man fühlt sich sogar angegriffen, wenn man konstruktive Vorschläge und Kritik vorbringt.
Rund um das Thema hat sich eine Posse entwickelt, die derzeitig problematische Situation und das Spannungsfeld Automattic <-> Matt <-> WP-Entwickler verdeutlicht:
Gutenberg und die Version 5.0 von WordPress hätten am 19. November veröffentlicht werden sollen.
Da war Gutenberg nicht fertig – daher gab es sehr viele Stimmen dagegen.
Und Moment. 19. November? Da war doch was! Ach ja, Thanksgiving-, Cybermonday- und BlackFriday-Woche. Die umsatzstärkste Woche im amerikanischen E-Commerce.
Was war das doch für ein grandioser Terminvorschlag….
Neuer Veröffentlichungstermin?
26. November.
Dieser Termin wird auch nicht halten.
Daher wird Dezember vorgeschlagen. Was natürlich keine gute Idee ist, kurz vor der Weihnachtszeit.
Also wird’s 2019 werden.
Das hört sich nicht nach stringentem Projektmanagement an…
Zudem fragen sich viele (Core-) Entwickler, wer denn das nun alles beschlossen hat.
WordPress wird von einer Open Source Community entwickelt. Diese ganzen Änderungen kommen aber nicht von der Community. Wer hat da also wohl das sagen und warum?
Ablenkungsmanöver
Im Moment dürfte Matt unter Stress stehen. Manche seiner Antworten sind daher ein bisserl wunderlich.
So gibt es Stimmen, dass es zu viele offene Issues für den Release Candidate von WordPress gibt. Wie antworten trotzige Kinder? Genau:
Viele haben Angst vor einer Veröffentlichung einer neuen Major-Version im Dezember. Eh schon wissen: Weihnachten und Weihnachtszeit bei uns und noch mehr in den Staaten. Die obligatorische Matt-Antwort im Core-Slack-Channel:
Weitere Meinungen zu Matt, Gutenberg und Leadership
Der Kollege wirft ein paar interessante Fragen rund um die Rolle von Matt und den Release von Gutenberg auf. Er spricht darauf an, dass WordPress eigentlich kein Automattic-Produkt sondern ein Community-Produkt ist.
Es stehen gravierende Änderungen an, die zukünftige User verstören oder verzücken könnten.
Dennoch herrscht ein bissl Chaos.
Durch die aktuellen Schritte, die Google im WordPress-Universum unternimmt, kommt es mir so vor, als wollte Google einen stabilisierenden Faktor reinbringen. Natürlich geht es da aber auch um Mitbestimmung.
Derweilen nur schleichend und nicht offensichtlich.
Ich bin gespannt, ob ich mit dieser Theorie auch nur annähernd richtig liege.
Aus betriebswirtschaftlicher Sicht wäre es nur logisch.
Links
Google Sitekit – Plugin zum gebündelten Anzeigen aus Google Spionage..äh..Tracking-Tools.
Wir befassen uns daher beruflich und aus privatem Interesse sehr mit dieser API. Die diversen Vorzüge haben wir ja vorgestellt.
Hin und wieder kitzeln uns dann aber gewisse Fragen und suchen nach Meinungen und Antworten.
Einer der Fragen ist:
Soll ich vorhandene Endpoints verwenden, oder explizit eigene Endpoints für gewisse Aktionen und Funktionen erstellen?
Versuchen wir’s mit einer kleinen Auflistung der jeweiligen Vorteile und lassen euch die Entscheidung selbst treffen, was besser ist:
WordPress-Endpoints verwenden
Die WP-API bietet die Möglichkeit, fast jeden Teil eines Posts zu bearbeiten. Angefangen vom Titel über Terms, Tags, Kategorien und Custom Fields/Metafelder.
Man muss also selbst nicht viel coden, wenn man Posts bearbeiten will.
Als Beispiel:
Wenn ich eine Likefunktion einbauen will, kann ich mit der WP API einfach zb Terms oder Custom Fields befüllen, um den Like zu speichern. Dafür braucht man selbst keine Endpoints schreiben.
Durch die Verwendung von vorhandenen Endpoints erspare ich mir zusätzliche Implementierung und vor allem die Wartung.
Verwendung von eigenen Endpoints
Wenn ich die Likefunktion anders implementieren will, muss ich selbst WordPress-Code entwickeln. Ich muss also selbst Hand anlegen, habe aber mehr Möglichkeiten:
Ich kann ohne Änderung an der API oder an vorhandenen Endpoints steuern, wie Daten tatsächlich gespeichert werden (zB ob die Like-Zuordnung als Tags oder als serialisiertes Meta-Feld gespeichert werden)
Ich kann eigene Businesslogik einbauen, die zusätzliche Aktionen durchführt (zB Gewisse Posts dürfen nur von registrieren Nutzern geliket werden; liket ein User mehr als 10 Beiträge wird eine Mail an den Admin verschickt)
Ich kann Aktionen erlauben, die der Benutzer sonst nicht durchführen dürfte (zB dem Post einen Tag hinzufügen obwohl er ihn gar nicht bearbeiten darf)
Ich kann häufig gemeinsam verwendete Abfragen gleich vorweg kombinieren (Ich will alle Likes eines Beitrages erfragen aber auch alle Beiträge bekommen, welche die selbe Anzahl an Likes hat. Dafür brauche ich dann nicht zwei API-Requests, sondern kanns in einem Aufruf abfragen)
Außerdem ist eine API auch ein User Interface. Je sprechender ein Endpunkt-Name ist, desto besser.
Natürlich hat man die Vorteile nur, wenn man für diese Aktionen ausschließlich die eigenen Endpunkte verwendet. Sobald man vom Frontend oder Client einmal direkt etwas ausliest oder veränderst, verlierst man sie.
Viele der aufgezählten Punkte lassen sich aber auch über Hooks lösen, wenn man es drauf anlegt.
Wenn man aber in der obigen Liste etwas findet das zutrifft, ist ein eigener Endpunkt ein heißer Kandidat.
Die JSON-API von WordPress bringt immense Vorteile und wird auch schon stark benutzt. Wir haben schon sehr früh über die Entwicklung der JSON-API geschrieben und befassen uns daher schon lange mit der ganzen Thematik.
Leider gibt es bei der WP-API einige Baustellen. Angefangen von der überaus schlechten Dokumentation bis zu den gravierenden Änderungen bei Versionssprüngen.
Ein großes Problemfeld ist das Auslesen und Speichern von custom fields / post meta per JSON-API.
Daher: Die Geschichte der Custom Fields in WordPress ist eine Geschichte voller Missverständnisse!
In den ersten Versionen der JSON-API war es recht einfach möglich, Custom Fields zu befüllen. Aber mit den späteren Versionen wurde die einfache Speichermöglichkeit entfernt und nun sind gewisse Vorbereitungen notwendig.
Ein kleines Beispiel soll zeigen, wie man nun per AJAX ein Postmeta mittels JSON speichert. Wir gehen von einem Formular mit Eingabemöglichkeit für Titel und Content aus.
Schritt 1: Postmeta für WP-API vorbereiten mit register_meta()
register_meta() macht das Metafeld für alle Post Types verfügbar!
Durch register_meta() kann man das Custom Field per JSON einfügen/speichern, aktualisieren und auslesen!
Man könnte ein postmeta/custom field auch mit register_rest_field() einbinden, dann muss man sich aber um Speicherung usw selbst kümmern. Dafür gibt’s für Metas aber eh eine eigene Funktion – siehe oben!
Wohin mit Anpassungen am Theme? Wohin mit Code-Snippets von StackExchange? Wohin mit kleinen, eigenen Funktionalitäten?
Dafür ist eigentlich die Datei functions.php im Theme zuständig.
Problem Problem Problem: Wenn das nicht das eigene Theme ist, sind die Änderungen beim nächsten Theme-Update weg!
Was war daher die Lösung? Genau!
Child-Themes!
Dadurch bleiben Änderungen bei jedem Update erhalten.
Ist das die beste Lösung für eigenen Code?
Meistens nicht!
Ein Plugin ist für eigene Funktionalitäten meist die beste Lösung.
Blöd nur, dass man das deaktivieren kann. Oder, dass es viel zu spät in Abläufe eingreift.
Doch halt, dafür gibt es eine Lösung!
Eine, die noch viel einfacher ist, als eigene Plugins erstellen, irgendwelche functions.php Dateien anzugreifen o.ä.
Must Use Plugins ist die Lösung
Must Use oder mu-plugins sind eigentlich keine Plugins. Es sind PHP-Dateien, die von WordPress automatisch geladen werden, wenn Sie im Verzeichnis wp-content/mu-plugins abgelegt werden.
Must-use plugins (a.k.a. mu-plugins) are plugins installed in a special directory inside the content folder and which are automatically enabled on all sites in the installation.
Also:
mu-plugins sind Plugins, die in einem speziellen Verzeichnis im content Verzeichnis installiert werden. Diese Plugins werden automatisch auf allen Seiten einer Installation aktiviert. (Anmerkung: Mit Seiten sind Multisite-Blogs gemeint)
Die Vorteile sind also:
Kein formales Plugin notwendig, nur eine PHP-Datei mit Code. Daher weniger Arbeitsaufwand und Code Overhead
Dieser Code wird immer aktiviert. Es muss kein Plugin aktiviert werden.
Dieses „Plugin“ kann nicht deaktiviert werden, es scheint auch nicht in der Pluginübersicht auf
Code wird vor dem laden anderer Plugins geladen.
Code/Plugin wird auf allen Blogs einer Multisite aktiviert.
Diese Funktionalität von WordPress ist verdammt praktisch.
Ich brauch für kleinere Funktionen nicht gleich ein eigenes Plugin erstellen. Man kann Funktionalitäten einbauen, ohne dass diese deaktiviert werden oder bei Updates verschwinden.
Eine kleine, saubere und einfache Lösung, um WordPress in der Funktionalität zu erweitern. Super!
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
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
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
Dadurch erhält der Post-Type im Backend auf der Bearbeitenseite gar kein Dropdown, um ein Elternelement auszuwählen.
Im WP-Kontext sind Nonces eine zufällige Aneinanderreihung von Zahlen und Buchstaben, die zwar mehrmals verwendet werden (im Gegensatz zur üblichen Implementierung von Nonces – Number used once), aber ein klar definiertes Ablaufdatum haben.
werden mit wp_nonce_url( $actionurl, $action, $name ); aufgerufen.
$actionurl ist die URL, die wir mit der Nonce „absichern“ wollen.
required; Default: None
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$name ist der Name der so generierten Nonce.
optional; Default: _wpnonce
Als Rückgabewert erhalten wir eine bereinigte URL mit zusätzlicher Nonce. Diese sieht in etwa so „http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204“ aus.
Forms
werden mit wp_nonce_field( $action, $name, $referer, $echo ); aufgerufen. Diese Funktion generiert uns bis zu zwei hidden input Elemente.
$action definiert den Namen der action.
optional, aber empfohlen; Default: -1
$name ist der Name der so generierten Nonce.
optional. Default: _wpnonce
$referer gibt an, ob ein zusätzliches hidden input Element erstellt werden soll, das den Output der Funktion wp_referer_field beinhaltet.
optional; Default: true
$echo gibt an, ob die so erstellten inputs im HTML ausgegeben werden.
optional; Default: true
Als Rückgabewert erhalten wir ein oder zwei hidden input Elemente, wenn $referer true ist.
Validierung
Allgemein
check_admin_referer( $action, $name ); überprüft sowohl die Nonce als auch den $referer.
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$name ist der Name der so generierten Nonce.
optional; Default: _wpnonce
AJAX
check_ajax_referer( $action, $query_arg, $die ); überprüft nur die Nonce im Zuge eines AJAX-Requests.
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$query_arg ist der Name der so generierten Nonce
optional; Default: false
$die gibt an, ob das script angehalten werden soll, wenn die Überprüfung fehlschlägt
optional; Default: true
Basic
wp_verify_nonce( $nonce, $action ); überprüft nur die Nonce.
$nonce ist der Name der Nonce, die überprüft werden soll.
required; Default: None
$action ist der Name der action.
optional; Default: -1
Eine einfache Überprüfung könnte z.B. so aussehen:
