Torsten Landsiedel

Habe nichts wieteres gefunden, so sollte es laut veröffentlichung funktionieren.

Hast du das so direkt in den Block-Editor eingetragen?

<strong>User Name:</strong> <?php the_author_meta( 'name' ); ?></p>
<strong>E-mail:</strong> <?php the_author_meta( 'email' ); ?></p>

Dann wundert mich nicht, dass es nicht funktioniert. PHP im Block-Editor wird ja nicht direkt ausgeführt.

Falls ich dich falsch verstanden habe sollte, dann poste mal deine gesamte Vorgehensweise. Schritt für Schritt, inkl. dem gesamten Code. Dann kann ich vermutlich auch helfen.

Alternativ zu dem Deaktivieren der Plugins gibt es zwei andere Möglichkeiten, um den Live-Betrieb nicht zu stören.

Mit dem Plugin Profiler kannst du schauen, ob und wenn ja, welches Plugin hier so lange Zeit benötigt:
https://de.wordpress.org/plugins/code-profiler/

Und das Health Check Plugin hat einen Troubleshooting-Modus mit dem alle Plugins deaktiviert werden, und dann einzeln wieder aktiviert werden können. Das passiert nur für dich als angemeldeten Admin. Der Besucher sieht weiterhin die funktionierende Website:
https://de.wordpress.org/plugins/health-check/

Da das mehrfach falsch zitiert wurde, nochmal der Inhalt vom Link:

WordPress uses it’s own CA bundle, located in WP/wp-includes/certificates.

The CA bundle that was shipped with WordPress up until recently was outdated, as discussed in this issue: https://core.trac.wordpress.org/ticket/45807.

Setting sslverify to false is not recommended, and instead you can download an updated version of the bundle, https://github.com/WordPress/WordPress/tree/master/wp-includes/certificates and replace it in the wordpress folder.

Erklärung: WordPress enthält einen Ordner /wp-includes/certificatesin dem eine Datei „ca-bundle.crt“ liegt, mit dem die SSL-Zertifikate verifiziert werden.

Nun kann es passieren, dass Zertifikate aus dem Verkehr gezogen werden müssen und so kann die ca-bundle.crt veraltet sein. Wenn das Zertifikat ungültig ist, dann lässt mich der Browser aber ggf. nicht mehr an die Website und verhindert so, dass ich das WordPress im Backend von WordPress selbst aktualisiere.

Mit zwei Tricks kann man das Ganze lösen.

Trick 1: Über den Filter https_ssl_verify wird die SSL-Prüfung in WordPress deaktiviert und ich komme wieder in das Backend und kann dort das Update starten.

Trick 2: Wir tauchen die Datei ca-bundle.crt im Ordner /wp-includes/certificates manuell aus und aktualisieren so die Liste validen Zertifikat.

Beides erfordert aber FTP-Zugang, um händisch den Code einzufügen oder die Datei zu aktualisieren.

Wenn ihr Trick 1 benutzt, unbedingt den Filter-Code danach wieder entfernen!

Ich vermute, dass REST-API, Loopback und cURL-Probleme zusammenhängen. Aber dieser hier ist etwas anderes:

Automatisch geladene Optionen können die Leistung beeinflussen.

Diese Warnung kommt, wenn eine Einstellung (Option) automatisch geladen wird (autoload=yes), die über 800 KB Größe hat. Das ist nur für sehr wenige Einstellungen sinnvoll, sie bei jedem Request zu laden. Typischerweise werden Einstellungen nur an bestimmten Orten benötigt und es reicht sie nur dann zu laden. Insbesondere, wenn sie so groß sind.

Mit diesem Plugin kannst du die betroffene Einstellung finden und ggf. den autoload deaktivieren:
https://de.wordpress.org/plugins/aaa-option-optimizer/

Typischer Kandidate wäre z.B. _transient _dirsize_cache

Für den anderen Fehler wäre ggf. noch zu klären, ob du beim Deaktivieren deines Caching-Plugins auch wirklich das Plugin außer Betrieb genommen hast. Bei vielen Caching-Plugins bleiben noch Überbleibsel, z.B. in der .htaccess.

Ich habe schon vor einigen Jahren eine „Free-Version“ von WordPress erstellt.

Diese Formulierung lässt mich ein wenig ratlos zurück, was du damit meinst. Nutzt du die Software (heruntergeladen von wordpress.ORG) oder meinst du damit, dass du bei WordPress.COM eine kostenlose (free) Website hast?
Siehe auch: https://wordpress.com/de/support/wordpress-com-und-wordpress-org/

Wenn ich es richtig verstehe, gibt man da im Kontaktformular eine E-Mail-Adresse ein und unter Werkzeuge im Adminbereich können personenbezogene Daten exportiert/gelöscht werden.

Nein, der Punkt unter Werkzeuge ist von WordPress out-of-the-box da. Das Plugin bietet einen Block/Shortcode/PHP-Funktion und Widget dazu an, um diese Abfragemöglichkeit direkt auf der Website (im Frontend) anzubieten.

Das steht so auch in der Plugin-Beschreibung:

This plugin allow website administrators to display Data Request Forms in front-end, for example in your Privacy Policy Page.

Der Ablauf ist dann derselbe, wie wenn es im Admin beantragt wurde:
https://wordpress.org/documentation/article/tools-export-personal-data-screen/

und

https://de.wordpress.org/plugins/gdpr-data-request-form/#data%20request%20workflow

Wenn ein Fehler auftaucht, müsstet ihr mal eure Errorlogs checken (ggf. Debugging aktivieren), um zu schauen, woran es liegt. Die E-Mail-Adresse ist der Key. Damit es etwas zum Download gibt, muss entweder ein User oder eine Kommentator/Kommentatorin mit dieser E-Mail-Adresse vorhanden sein (Core).

Vielleicht gab es ein Problem bei der Erstellung der Datei (Speicher voll, notwendige Bibliotheken nicht installiert, etc.). Aber da sollte uns, wie gesagt, der Errorlog helfen.

Ja, dann jetzt einzeln durchgehen, ob das korrekt ist. Sollte(n) die Seite(n) wirklich auf noindex stehen, weitergeleitet werden, etc. Woher kommen die Duplikate? Warum sind sie nicht mit einem canonical versehen? Nutzt du ein SEO-Plugin? Wenn ja, welches? Ist der Serverfehler (5xx) reproduzierbar oder nur Zufall?