Alle Beiträge von souri | wp-entwickler.at

Google investiert in WordPress – Entsteht hier ein Gegengewicht zu Automattic?

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.

Bei WordPress ist das anders, da gibt halt ein „gemäßigter Diktator“ den Ton an.

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.

Zudem funktionieren responsive Images mit scrset noch nicht so, wie man das vom alten Editor gewöhnt ist. Problem? JA! Das kann sich schlecht auf das Google Ranking und die Benutzererfahrung auswirken. Warum? Weil Bilder nicht optimal sondern in zu großer Auflösung geladen werden.. Siehe: https://github.com/WordPress/gutenberg/issues/6177

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:

Link zum Tweet von John Blackbourn https://mobile.twitter.com/johnbillion/status/1058536248950833153

John Blackbourn ist ein wohlverdienter WordPress-Core-Entwickler und schmeißt jetzt das Handtuch, weil er merkt, was alle im Moment merken:

Wer konstruktive Kritik übt wird als Gegner von Gutenberg diffamiert..

Dazu kommt, dass Matt dem User die Schuld an der teilweisen Unbedienbarkeit von Gutenberg gibt:

Schuld ist immer der USER! Oh boy… Tweet von Matt: https://mobile.twitter.com/photomatt/status/1058497572111675393

Terminänderungen

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:

Aber xyz hat doch das Selbe gemacht, ällabätsch!

 

So könnte man diese Antwort auffassen:

Matt Mullenweg im WordPress-Core-Blog: https://make.wordpress.org/core/2018/11/19/5-0-gutenberg-status-update-nov-19/#comment-34455

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:

Slack Nachricht von Matt: https://wordpress.slack.com/archives/C02RQBWTW/p1542837346944900

 

Und dann gäbe es noch diesen unrühmlichen Tweet, den ich hier mehr oder weniger unkommentiert stehen lassen möchte:

Stay classy, Matt! https://mobile.twitter.com/photomatt/status/1062475366462308355

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.

https://de.wikipedia.org/wiki/Benevolent_Dictator_for_Life

 

Conclusio

Im Moment ist viel los im WordPress-Universum.

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

Speichere post meta/custom field Daten mit der WP API (JSON API) und AJAX – register_meta() heißt das Zauberwort!

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.

json photo
Photo by xmodulo

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()

 

Wichtig ist, „show_in_rest“ auf true zu stellen!

// add_action( 'init', register_meta_for_json' ); //BSP-Hook
 public static function register_meta_for_json() {
 $vorbereitetes_meta_args = array(
 'type' => 'string',
 'description' => 'Testmeta fuer JSON',
 'single' => true,
 'show_in_rest' => true,
 );

$Stars_args = array(
 'type' => 'number',
 'description' => 'Feld für Star-Rating',
 'single' => true,
 'show_in_rest' => true,
 );

register_meta( 'post', 'vorbereitetes_meta', $vorbereitetes_meta_args );
 register_meta( 'post', 'Stars', $Stars_args );
 }

 

 

 

Schritt 2: JavaScript-Datei einbinden und eigene Parameter anfügen

add_action( 'wp_enqueue_scripts', 'json_script');
 function json_script() {

wp_enqueue_script( 'wpent-json', plugins_url( 'wpent_json.js', __FILE__ ), array( 'jquery' ) );

$localize_script_args = array(
 'nonce' => wp_create_nonce( 'wp_rest' ), //extra wichtig - muss wp_rest sein!
 'jsonroot' => esc_url_raw( get_rest_url() ),
 'userID' => get_current_user_id(),
 );

wp_localize_script( 'wpent-json', 'WPENT_JSON_DATA', $localize_script_args );
 }

Schritt 3: Daten vorbereiten und per AJAX den JSON-Call machen

 

jQuery( document ).ready( function ( $ ) {
 $( '#eingabeformular' ).on( 'submit', function(e) {
 e.preventDefault();
 var title = $( '#eingabefeld_titel' ).val();
 var content = $( '#eingabefeld_content' ).val();
 var postmeta = { 'vorbereitetes_meta':"Metainhalt", 'Stars':"11"};

var data = {
 'title' : title,
 'content' : content,
 'status' : 'publish',
 'tags' : [2, 3],
 'categories' : [1, 4],
 'meta' : postmeta
 };

$.ajax({
 method: "POST", // oder type: 'POST',
 url: WPENT_JSON_DATA.jsonroot + 'wp/v2/posts', // url: 'meinedomain.at/wp-json/wp/v2/posts',
 dataType : 'json',
 contentType: 'application/json',
 data: data,
 beforeSend: function ( xhr ) {
 xhr.setRequestHeader( 'X-WP-Nonce', WPENT_JSON_DATA.nonce );
 },
 success : function( response ) {
 console.warn( response );
 },
 fail : function( response ) {
 console.warn( response );
 }
 });

});

} );

 

Andere Möglichkeiten

Andere Seiten haben auch schöne…Möglichkeiten für diesen Zweck. Hier der Überblick:

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: 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

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.