Beiträge von threadi

Wo und wie hast Du denn die Umleitung eingerichtet? Im Hosting oder mit Hilfe eines WordPress-Plugins oder per manuellen htaccess-Eintrag? Abhängig davon wie Du sie eingerichtet hast, kann man dir dazu ggfs. auch Tipps geben.

Zitat

Jedoch kann ich die Error Log nicht lesen oder es findet keinen.

Den Satz verstehe ich nicht. Wenn Du Hilfe beim Error-Log brauchst, wende dich am besten an den Support deines Hosters.

Alternativ kannst Du auch wie hier beschrieben das Wordpress-eigene Debugging aktivieren:
https://wordpress.org/documentation/…g-in-wordpress/
Das erzeugt eine eigene Log-Datei in der das auch stehen sollte.

unexpected character 0x00

deutet auf ein Zeichensatzproblem hin. Das hat mit fehlerhaftem PHP-Code nichts zu tun. Lade dir die wp-config.php mal runter und schau sie dir in einem fortschrittlichen Editor wie Notepad++ an. Der zeigt dir an in welchem Zeichensatz die Datei gespeichert ist. Im Idealfall sollte das utf-8 ohne BOM sein. Wenn Du einen anderen Editor lokal nutzt, sollte der dir das ebenfalls anzeigen und Änderungen ermöglichen.

Die Ursache dafür ist oft ein Plugin oder das Tjeme was einen Fehler verursacht. Hier gibt es einen ausführlichen Artikel dazu: https://wordpress.org/documentation/…screen-of-death

Rat: schau ins Error-Log deines Hostings. Dort müsste erkennbar sein was die genaue Ursache ist. Ist es ein Plugin entferne dessen Verzeichnis aus /wp-content/plugins/.

Der Effekt hat nichts mit der Anzahl von Plugins zu tun sondern mit Funktionen, die die aktiven Plugins einbinden. Du musst herausbekommen, welches der von dir genutzten Plugins dafür verantwortlich ist. Hast Du wie oben beschrieben mal die Optimierungsplugins deaktiviert? Das wäre der erste Schritt um das mal zu testen.

Was meinst Du mit runtersetzen und welches Plugin meinst Du?

.. dann ist es wohl nur eine Frage der Zeit bis der Provider das entdeckt und dein Hosting wegen potentieller Gefährdung abschaltet. Wieso will sie sich mit neueren Versionen nicht anfreunden? Geht es um den Block Editor der seit Version 5 dabei ist? Du könntest auch ClassicPress mal probieren: https://www.classicpress.net

Den Nutzernamen kann man am ehesten in der Datenbank direkt ändern. Dort gibt es eine Tabelle "users" (mit Prefix deiner Installation davor) in der Du die Datensätze bearbeiten kannst. Für neuere WordPress-Versionen gibt es dafür auch Plugins, aber für so eine alte sehe ich da keine andere Chance.

Hier werden 3 Wege dazu beschrieben (wobei einer nicht mehr geht, da das Plugin nicht mehr zur Verfügung steht):
https://www.wpbeginner.com/wp-tutorials/h…-3-3-admin-bar/

Es gibt keine Stelle im WordPress-Quellcode der so einen Header setzen würde: https://github.com/search?q=repo:WordPress/WordPress x-redirected-by&type=code

Was hat deine Prüfung der .htaccess-Datei ergeben?

Der Header "x-directed-by" wird nur von 3 Plugins im WordPress-Repository gesetzt:
* Redirection
* Faust.js
* Xtool Redirecter

Wenn du eines davon hast, deaktiviere es. Mit "Gründern" sprechen reicht manchmal nicht aus (du meinst btw. eher den Plugin-Support des Plugins ..). Man muss selbst ausprobieren was eine Deaktivierung bewirkt. Sobald Du es deaktiviert hast, teste den Vorgang nochmal in einem privaten Browserfenster.

Und das .htaccess-Thema wäre weiterhin auch eine Möglichkeit.

Dieser Header wird nicht von WordPress gesetzt. Ich vermute du hast ein Plugin im Einsatz, was Weiterleitungen für dich übernimmt. So etwas wie Redirection: https://de.wordpress.org/plugins/redirection/

Wenn es das nicht ist, dann irgendein anderes. Schau dir mal deine Plugins an.

Auch könnte sich ein Blick in die .htaccess-Datei lohnen. Evtl. ist die Weiterleitung dort fest hinterlegt.

Ich kenne und nutze Divi (leider) bisher nicht. Allerdings ist das ein kommerzielles Produkt bei dem Du bei Fragen auch jederzeit deren Support kontaktieren kannst. Die haben auch selbst eine Community die hilft meines Wissens: https://divi.help

Vielleicht reicht auch schon dieses Video um dir eine Richtung zum Vorgehen zu geben:

Um dir dabei zu helfen müsste man wissen womit Du deine Seite bearbeitest? Ein Link zur Webseite, wie in den Forenregeln Punkt 2 geschrieben. wäre schon hilfreich um das zu erkennen.

Im Ticket wurde der Grund für die Änderung inzwischen beschrieben. Der FSE hat bisher nach Zusammenstellung des gesamten Quellcodes der auszugebenden Seite die darin enthaltenen Shortcodes ausgeführt. Dadurch war es möglich, dass z.B. ein Kommentar zu einem Post einen Shortcode enthält der dann auch ausgeführt wurde. Das stellt das potentielle Sicherheitsrisiko dar. Bei Klassik-Themes passiert das nicht da dort Shortcodes nur bei Inhalten von dafür berechtigten Nutzern ausgeführt werden (z.B. vom post_content).

Lösungen wurden im Ticket auch schon angesprochen, aber keine davon ist wirklich gut geeignet imho. Man muss ohnehin darauf warten was das Sicherheits- und Editor-Team dazu veröffentlichen - was wohl "demnächst" passieren soll.

Du kannst in einem HTML-Block keinen PHP-Code einfügen. Der wird dort nicht ausgeführt da der Block nur für HTML-Code gedacht ist.

Wie sieht denn dein Versuch es per Code Snippets zu lösen aus? Das wäre der richtige Weg wenn Du kein Child-Theme hast.

Der Grund ist weiterhin nicht öffentlich, wurde auch im gestrigen Slack-Dev-Chat nochmals erwähnt. Innerhalb des Security- und Editor-Teams wird derzeit das weitere Vorgehen besprochen, auch um eine möglicherweise Alternative Lösung für eine schnelle 6.2.2 zu finden.

Und aus genau diesem Grund müssten Betroffene noch etwas Geduld haben. Es lohnt sich imho nicht irgendetwas zu überstürzen. Ich würde eher die weiteren Entscheidungen abwarten. Denjenigen die daran beteiligt sind ist die Dringlichkeit durchaus bewusst.

Ich kenne btw. nicht ein einziges Projekt was betroffen ist und diejenigen die sich bis gestern im WordPress-Supportforum und Trac gemeldet hatten kann man auch an 2 Händen abzählen. Viele werden sich aber auch gar nicht melden oder gar nicht merken, dass sie betroffen sind ..

Von dem dort empfohlenen Rollback auf 6.2 würde ich abraten. Es hat schon seinen Grund wieso ein Sicherheitsfix veröffentlicht wurde ..

Du müsstest den Kritischen Fehler den du erhältst übers Error-Log mal genauer anschauen. Dort würdest Du erkennen, dass

private $helper = new Helper();

die Ursache ist.

Schreib diese Klasse mal so um:

class Printer {
    private $helper = null;
    private $table_name;


    public function __construct() {
      $this->helper = new Helper();
    }
  
    public function create_data($table) {
        $this->table_name = $this->helper->get_prefix() . $table;
        $sql = "SELECT * FROM $this->table_name";
        $this->archiv = $this->helper->get_results($sql);
    }
}

Wenn auch das nicht geht, schau unbedingt ins Error-Log. Das sagt mehr aus als Java-Logs in solchen Fällen oft

Du hast vermutlich das Astra Starter Plugin. Da gab es vor einiger Zeit einen Bug der genau das erzeugt. Lösung ist hier beschrieben: https://wpastra.com/docs/resolve-update-failed-1-issue/

Um das noch etwas ausführlicher zu beantworten:
WordPress hat eine eingebaute Import-Funktion die das von WordPress entwickelte und inzwischen auch von anderen CMS genutzte WXR-Format nutzt. Eine Beschreibung dazu ist hier zu finden: https://devtidbits.com/2011/03/16/the…-and-explained/ (und ja, der Artikel ist so alt - das Format hat sich aber auch nicht mehr geändert seither und wird weiterhin vielfach genutzt)

Wenn deine Eigenentwicklung also einen Export der Daten in diesem Format bereitstellen kann, dann könnte man die Daten sehr einfach in WordPress importieren.

Solltest Du keinen Entwickler haben der dich dabei unterstützen kann, kannst Du dich in der Jobbörse melden: https://forum.wpde.org/forums/jobboerse.33/