Problemzone Elternseiten-Dropdown
So ganz uneingeschränkt stimmt das aber leider nicht. Zumindest nicht für das Backend.
Ein riesiges Problem ist das Elterndropdown im Backend:
In diesem Dropdown werden alle Seiten aufgelistet, die es so gibt.
Das heißt, dass ALLE Seiten/CPT-Posts 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:
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.
Aber auch wenn der Server diese Anfrage erfolgreich umsetzen kann, kommt es zu Problemen!
Im Browser muss das Dropdown ja mit 300.000 Einträgen befüllt werden! Das könnte den Browser crashen lassen. Aber sicherlich kommt es zu immenser Ladezeit, bis der Browser die Seite ganz darstellt. Weil es eben am Dropdown hakt.
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:
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!