Wichtigen Code in functions.php speichern? Eigenes Plugin dafür erstellen? Nein! Wichtiger Code kommt in den Ordner mu-plugins!

Oft wird man gefragt:

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.

https://codex.wordpress.org/Must_Use_Plugins

Der WordPress-Codex sagt über mu-plugins:

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!

 

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:Zb Dropdown beseitigen

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

Nonces in WordPress

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.

Wie bereits im Artikel WordPress Sicherheit bei Formulareingaben und AJAX Aufrufen – verwendet Nonces! beschrieben wurde, sollen Nonces dabei helfen, URLs und Formulare auf Websites vor missbräuchlicher Benutzung und anderem Unfug zu schützen.

Erstellung

URLs

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.

Beispiel für wp_nonce_field in Formularen.

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:

Validierung der wp-nonce mit wp_verify_nonce.

Weiterführende Informationen:

Die verdammt intelligenten E-Mail-Vorlagen von BuddyPress – ein Einblick in die inneren Organe

BuddyPress hat mit der Version 2.4 Funktionen zur Anpassungen der Mails eingeführt.

Dadurch lassen sich mit Platzhalter sehr einfach die ausgehenden Mails bearbeiten:

 

Alles was in den geschwungenen Klammern {} steht wird Daten von BuddyPress ersetzt.

BuddyPress nennt das Email-Tokens und hat dazu auch einen eigenen Hilfeartikel: https://codex.buddypress.org/emails/email-tokens/

Soweit so gut. Das sind also Dinge, die der User sieht. Dinge an der Oberfläche. Wie kommt es soweit aka welcher Code steht dahinter?

Der Post-Types: bp-email

Erstellt wird der Post Type bp-email in class-bp-core.php:301.

 

Die Taxonomie: bp-email-type

Die Taxonomie wird verwendet, um die Situation zu beschreiben in der die Mail verschickt wird.

Die Taxonomie wird im Backend als „Situation“ bezeichnet:

Erstellt wird diese Taxonomie unter buddypress/bp-core/bp-core-taxonomy.php:

https://github.com/buddypress/BuddyPress/blob/78800bc6767ef30ce1831d914a6f17f1dfab5e9c/src/bp-core/admin/bp-core-admin-schema.php#L498

Taxonomy und Post-Type Namen

Finden sich in der Datei buddypress/class-buddypress.php:

Für den Post-Type also bp-email und für die Taxonomie bp-email-type.

 

Vorgegebene E-Mail Vorlagen erstellen

In der Datei buddypress/bp-core/admin/bp-core-admin-schema.php:498 werden dann die default Posts erstellt, die dann im Backend so ersichtlich sind:

https://github.com/buddypress/BuddyPress/blob/78800bc6767ef30ce1831d914a6f17f1dfab5e9c/src/bp-core/admin/bp-core-admin-schema.php#L498

 

Der Text für die default Mails findet sich in buddypress/bp-core/bp-core-functions.php unter bp_email_get_schema():

Die Taxonomie-Terms werden für den Zweck der Mail verwendet:

Der Text davon kommt aus buddypress/bp-core/bp-core-functions.php unter bp_email_get_type_schema():

 

Zusammenspiel von Posts und Terms

Die Textvorlagen der Email-Posts haben einen Key, der direkt auf ein Term referenziert:

 

activitiy-comment bei der Textvorlage des Posts
activitiy-comment bei der Term-Textvorlage
Verknüpfung der Textvorlage beim Post und beim Term

So sieht die Verknüpfung zwischen Post und Term dann im Backend aus:

WooCommerce – eine kleine Einführung in die Struktur von Order ID, Order Items ID, Order Meta

WooCommerce (WC) ist ein großartiges E-Commerce-Tool und arbeitet mit WordPress sehr gut zusammen.

Man bekommt mit WC einen WebShop mit dem Look and Feel von WordPress im Backend. Wer also recht firm in WordPress ist, wird mit WooCommerce gleich gut zurecht kommen.

Aber wie schaut’s denn mit der Datenstruktur aus?

Wo werden grundlegende Daten in der Datenbank gespeichert? Hier und jetzt gibt’s ein bisserl Licht in’s Dunkle!

tl;dr

Um an Bestellzeilen-Metas zu kommen gehe ich den Weg:

  1.  Post-ID aus Tabelle Posts holen = order_id
  2. Hole order_item_id von der Zeile line_item aus woocommerce_order_items mit order_id .
  3. Mit order_item_id in woocommerce_order_itemmeta holt man nun das entsprechende Meta

 

Tabellenstruktur / Datenbankschema

Als kurze Übersicht und Einführung zum besseren Verständnis empfiehlt es sich, mal kurz das Datenbankschema von WooCommerce durchzugehen:

 

Die zwei Tabellen, die in dem Artikel hauptsächlich behandelt werden sind so aufgebaut und verknüpft:

Order Items und Order Item-Meta Tabellen

Wie wird eine Bestellung gespeichert?

  • Ganz normal als WordPress-Post in der Tabelle posts
  • Der Post hat einen eigenen Custom Post Type mit Namen shop_order
    • Hier ein Beispiel einer Bestellung mit der Post-ID 1092

 

Wo werden die Bestellzeilen, Produktzeilen, USt-Zeilen usw gespeichert?

  • Dafür legt WooCommerce eine eigene Tabelle mit dem Namen woocommerce_order_items an.
  • Die order_id ist die post_id der Bestellung und verknüpft somit die beiden Tabellen:

Die order_item_id oder : Wie ist ein Produkt mit den Produktmetadaten verknüpft

  • Bestellzeilen-Metas sind in der Tabelle woocommerce_order_itemmeta daheim
  • In der vorhin beschriebenen Tabelle woocommerce_order_items gibt es eine order_item_id für jedes bestellte Produkt.
  • Für alle Produkte kann es Metafelder geben. Die Metafelder sind mit dem Produkt (=dem Order-Item) über die Order-Item-ID verknüpft. In unserem Fall zb die ID 1438.

Daten in der normalen Postmetas/Custom Fields

Da ging es jetzt um die WC eigenen Tabellen. Natürlich werden einige Daten auch in der normalen postmeta-Tabelle gespeichert. An die ranzukommen ist aber eh keien große Kunst:

Bestellungsdaten in der Postmeta-Tabelle von WordPress.

WordPress Multisite und Plesk – eine Leidensgeschichte mit Problemlösungen

Die Multisite-Funktionalität von WordPress ist wirklich super.

Eine Installation, einmal Plugins und Themes warten und viele unabhängige Seiten damit aufziehen. Toll!

Dazu noch BuddyPress, wo jede Gruppe oder jeder Benutzer einen eigenen (Multisite) Blog bekommen kann. Wow! Das alles gratis und out of the box!

Doch dort wo viel Licht ist, gibt’s auch viel Schatten.

Und die Schatten werden bei einer Multisite-Installation mit Plesk immer länger, wenn man frisch ins Fahrwasser geworfen wird.

Hier also einige Lösungen:

Konnte keine Datenbankverbindung aufbauen – Datenbankfehler wegen Dateiberechtigungen

Datenkbankfehler! GRML! Wie kann das sein? WordPress funktioniert ja. Funktionierte ja vor der Multisite Installation.

Woran liegts?

Plesk hat die Dateiberechtigung der wp-config.php geändert und die WP-Installation kann nicht mehr auf die Datenbank-Login-Daten zugreifen:

Einfach die Dateiberechtigung ändern:

 

Das hat nicht geholfen? Dann helfen vielleicht folgende Tutorials:

404-Fehler mit nginx

Arr, da hat man es endlich geschafft, eine Multisiteumgebung zu installieren, der Hauptblog funktioniert und dann das: Beim Wechseln auf den nächsten Blog kommt es zum 404er! 🙁

Ein Blick in die Logs von Plesk helfen:

Das Problem ist schnell erkannt- nginx sucht in einem Verzeichnis, das es nicht gibt:

Das Verzeichnis kann es ja nicht geben, also nicht lokal auf der Festplatte! Hier handelt es sich nur um eine schöne URL, die von WordPress erstellt wird!

Lösung 1 – FPM von Apache bedienen

Diese Lösung ist recht einfach:

Man stellt also auf FPM-Anwednung von Apache bedienen um. Wird das von nginx bedient, ist Apache nicht involviert. Nginx kann aber erstmal nix mit den .htaccess-Regeln anfangen

Lösung 2 – Nginx korrekt konfigurieren

Der Lösungsweg dauert länger hat aber den Vorteil, dass man weiterhin nginx verwenden kann!

Plesk selbst bietet da ein gutes Tutorial an:

 

Grundsätzliche Infos

Plesk Tutorial zum Aufsetzen einer Multisite-Umgebung

https://support.plesk.com/hc/en-us/articles/115001016553-How-to-set-up-multisite-WordPress-network

 

Configuring Wildcard Subdomains for multi site under Plesk Control Panel

https://codex.wordpress.org/Configuring_Wildcard_Subdomains_for_multi_site_under_Plesk_Control_Panel

WordPress Testinstanzen, Testumgebungen und Sandboxen

In einem normalen Entwicklungsstadium gibt es meist 3 Umgebungen:

  • Test-
  • Staging- und
  • Liveinstanz

Damit können Pluginupdates eingespielt und gestestet werden, es kann auf einer ähnlichen Arbeitsumgebung wie der Liveseite entwickelt und programmiert werden und mit dem Kunden gemeinsam am Projekt gearbeitet werden.

Was mache ich, wenn ich nur schnell ein Plugin austesten will oder ein mal kurz etwas ausprobieren möchte?

There’s an…app for that!

Oder besser gesagt: Dafür gibt es natürlich Tools/Services/Seiten.

Poopy.life – Gratis!

http://poopy.life/

Ja ja ja, der Name ist natürlich fragwürdig und soll Aufmerksamkeit erregen. Ziel erreicht!

Der Name wurde gewählt, damit man diese Instanz nicht dauerhaft verwendet und für die Entwicklung und Zusammenarbeit mit Kunden verwendet. Schaut doch ein bisserl blöd aus, wenn man dem Kunden die URL „deinneuesprojekt.poopy.life“ weitergibt…:D

Mit poopy.life kann ich schnell, einfach und kostenlos neue WordPress-Installationen erzeugen.

Die Lebensdauer ist limitiert, die Instanz verfällt also nach einer gewissen Zeit, zb wenn man sich 7 Tage lang nicht einloggt:

Diese Instanz zerstört sich innerhalb von 7 Tagen von selbst. Poopy, übernehmen Sie!

Die Instanz ist recht schnell, die ExecTime ist auf 10 Minuten!! gesetzt und man bekommt alle Möglichkeiten! Man kann alle Plugins installieren und damit auch den Server unsicher machen!

Arbeitsumgebung – was läuft denn so am Server?

Blöde Idee am Rande: Natürlich könnte man einen Proxy verwenden, die URL dynamisch umschreiben, mit neuer URL ausgeben und so den Sinn und Zweck dieses Gratisangebots ein bisserl kaputt machen….

Weitere Infos:

 

wpsandbox.io – ab $ 50,–

  • https://wpsandbox.io/

Die Macher von poopy.life bieten das gleiche Service auch als kommerzielle Version mit viel mehr Möglichkeiten an.

In der Bezahlversion habe ich SSH und SFTP zugriff und kann die PHP-Version auswählen.

Der Preis ist für das schnelle Testen nicht gerade verlockend:

Ab 50 Dollar pro Monat für simple Testseiten….

Dafür bekomm ich schon einen x-beliebigen, günstigen vServer. Und genau das wär die Alternative:

Eigener vServer mit zb Plesk – ab ca € 3,99

Jeder x-beliebige vServer mit Plesk reicht aus um mal schnell eine WordPress-Testumgebung hochzuziehen. Mit let’s encrypt SSL-Zertifikat, SSH- und SFTP-Zugang usw.

 

WordPress-Multisite – Eine komplette Übersicht + Meinungen dazu

Multisite-Umgebungen in WordPress eignen sich für viele Anwendungsfälle, zb für

  • Mehrsprachigkeit – wo jede Sprache eine eigene Multisite-Seite bekommt
  • Soziale Netzwerke, wo jede Gruppe oder Benutzer eine eigenen Blog bekommt
  • Kundenverwaltung, wo jeder Kunde eine eigene Multisite-Seite/Blog bekommt

 

Es gibt sehr viele Möglichkeiten, eine Multisite-Umgebung aufzusetzen und zu konfigurieren. Dazu hier ein paar Gedanken:

tl;dr

  • Subdomain-Installation bringt Aufwand mit DNS, Plesk (und eventuell nginx)

Cool Stuff

  • Jede Multisite kann eine eigene Domain haben
  • Bessere Strukturierung von Inhalten und Teilbereichen mit integrierter Rechteverwaltung
    • Wird eine Datenstruktur zb mit Meta-Feldern aufgebaut, bin ich immer im Post-Edit bereich und tu mir da schwer, andere Benutzer mit Rechten zu versehen. Vor allem wenn da Benutzer mit unterschiedlichen Berechtigungen behandelt werden müssen
  • Multisites für zb Kunden können öffentliche und private Bereiche haben – so können die Kunden Ihren Kunden oder Bekannten Zugang zu den öffentlichen Bereichen geben
  • Jeder Multisite für Kunden oder BuddyPress-Freunden kann von denen selbst verwaltet werden. Themes können gewechselt und weitere Benutzer verwaltet werden
  • Trennung von sensiblen und öffentlichen Daten
  • Medienverwaltung ist einfacher und getrennt!  Werden soziale Netzwerke ohne Multisite aufgezogen, so sehen alle User alle Medien

Ordnerstruktur oder Subdomains – SSL, Permalink und Verzeichnisprobleme aufgelöst

Vorab: nginx kann in beiden Fällen Probleme machen!

Soll die Multisite-Umgebung unter

  • zweiteseite.hauptdomain.com oder
  • hauptdomain.com/zweiteseite

erreichbar sein?

Eine Entscheidungshilfe soll nachfolgende Gegenüberstellung geben.

Multisite mit Ordnerstruktur

Bei der Ordnerstruktur sind die Multisites unter hauptdomain.com/zweiteseite oder hauptdomain.com/dritteseite erreichbar.

Vorteile

  • Kein Problem mit SSL-Zertifikaten wie let’s encrypt.
    • Weil auf die Hauptdomain eh ein SSL-Zertifikat ausgestellt wurde, gilt das für alle Teile einer URL, die darauf folgen.
    • hauptdomain.com/zweiteseite oder hauptdomain/blogs/dritteseite sind alle vom Zertifikat erfasst.
  • Kein Problem mit DNS & Domainkonfiguration am Server (zb Plesk)
    • Da für jeden weiteren Multisite-Blog keine Domain angelegt wird, muss ich am Server nichts konfigurieren. Ich brauch mich auch nicht um die DNS-Verwaltung kümmern.
    • Gerade DNS macht bei Hostern gerne Probleme.
  • URLS der Multisites können mit Permalinks leicht beeinflusst werden.
  • Schnellerer und besserer Workflow beim Erstellen einer weiteren Seite. Zb durch Kunden oder User. Ich muss mich dadurch nicht um Domain- oder DNS-Handling kümmern.
  • Weniger nginx-Probleme – da jede Unterseite nur über weiteres URL-Rewriting/Permalinks gelöst werden.

 

Nachteile

  • Permalinks könnten Probleme machen. Gleichlautende Seiten oder CPT-Posts könnten mit dem Slug/Namen der Multisite-Seite kollidieren.
    • Ein Beitrag mit dem Titel Essen und der URL meineseite.com/essen macht Probleme, wenn ich einen Multisite-Blog mit der URL meineseite.com/essen habe!
    • Lösung: Posts sollten sowieso immer einen nummerischen Permalink-Prefix haben, zb: /%post_id%/%postname%/

 

Multisite mit Subdomains

Vor und Nachteile der Ordnerstruktur-Konfiguration sind hier meist vice versa zu sehen. Zusätzlich:

  • Subdomains könnten als saubere Trennung gesehen werden
  • Domain könnte sehr lang werden!
    • Wird eine Multisite unter einer übergeordneten Subdomain betrieben, wird die URL sehr lange, komplex oder unschön.
    • Hauptseite ist unter subdomain.meinedomain.at erreichbar. Wird nun eine Multisite darunter eingerichtet, kommt es zu solchen URLS: multisiteblog.subdomain.meinedomain.at.
  • Wildcard-DNS-Eintrag wird benötigt.

 

Plesk

 

„/blog/“-Slug in URL entfernen

Man könnte sich an /blog/ in der Url stören. Das lässt sich aber ganz einfach beseitigen!

  • Im Netzwerkbereich (domain.at/wp-admin/network/site-settings.php?id=1) die Permalinkstruktur anpassen und das /blog/ wegnehmen:
    • Alt:
    • Neu:

 

Dafür gibt es natürlich auch ein Plugin:

R3DF Multisite Blog Slug Remover

 

Erzwungene Subdomain-Installation doch noch als Unterverzeichnis-Installation durchführen

Da deine Installation nicht neu ist, müssen die Websites in deinem WordPress-Netzwerk Subdomains verwenden. Die Haupt-Website einer Installation in Unterverzeichnissen benötigt eine modifizierte Permalink-Struktur, die möglicherweise bestehende Links beeinträchtigt.

Das kennt man und ärgert sich darüber, oder?

Trotz komplett neuer Installation kommt also der Zwang, die Multisite nur als Subdomain-Installation durchzuführen!

Das Ziel wär aber folgendes:

 

Die Lösung?

  • Alle Artikel und Seiten löschen.
  • Eventuell auch: Permalinkstruktur auf schöne Urls ändern

Was mache ich mit WP_ALLOW_MULTISITE?

Bei der Installation bekommt man folgende Anweisungen:

 

In der Datei wp-config.php steht bereits der Eintrag

define( 'WP_ALLOW_MULTISITE', true );

und daher würde das dann so aussehen:

WP_ALLOW_MULTISITE brauche ich nur, um die Multisite-Installation überhaupt zu ermöglichen.

Wenn ich den vorgegebenen Block aus dem ersten Screenshot in die wp-config.php kopieren muss, kann ich WP_ALLOW_MULTISITE löschen oder überschreiben!

Siehe:

 

Domainmapping – Domains für die einzelnen Blogs aufschalten

Früher brauchte man ein Plugin, um extra Domains für die „Unterseiten“ zu verwenden.

Seit einiger Zeit ist diese Funktionalität aber im WordPress-Core enthalten:

https://codex.wordpress.org/WordPress_Multisite_Domain_Mapping

 

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

Das verwünschte HTTP Error Problem beim Medienuploader

Es ist einer der ärgerlichsten Probleme mit WordPress die man kennt.

Ein Fehler beim Upload von Bildern.

Man sucht alle Logdaten durch, schaut sich die Firewall und Jails an und kommt nicht dahinter, woher das Problem kommt.

Es gibt für das Problem mehrere Ursachen und einige Lösungen.

Gesperrte IP-Adresse?

Es kann zb bei Plesk passieren, dass die eigenen IP-Adresse gesperrt ist.

Das kann man einfach begutachten und beheben, indem man bei den Tools & Einstellungen die eigenen Adresse wieder freischaltet:

 

ModSecurity/WebAppFirewall überprüfen

ModSecurity kannn oft die Ursache für ein Problem beim Medienupload sein.

In den Einstellungen von Plesk wird sogar darauf hingewiesen, dass manche ModSecurity Regelsätze Probleme mit zb WordPress bereiten.

Sicherheitsplugins überprüfen

Plugins wie iThemes Security, Wordfence o.ä. können auch dafür zuständig sein, dass gewisse Anfrangen an WordPress nicht weitergeleitet oder geblockt werden.

 

PHP-Version ändern

Oft hilft es auch einfach die PHP-Backend-Version auf zb FastCGI zu ändern.

So geht das beispielhaft:

Apache oder Server neu starten

Die Holzhammer-Methode wäre es, den Apache oder den Server neu zu starten.

feuer photo

Das hilft aber manchmal!