Beiträge von threadi

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/

Ich weiß nicht wieso man noch Shortcodes verwenden sollte wenn es dafür Block-Einstellungen gibt die man per Plugin nachrüsten kann. Ja, eine Alternative - aber nicht brauchbar imho.

Du hast nicht das Theme Storefront sondern eines namens "Rife Free".

Das Foto von dem Du sprichst ist das Bild mit der Kerze auf der Startseite? Oder ein anderes?

Du nutzt scheinbar den Block Editor für die Inhaltspflege, also auch die Art wie Du das Bild dort hinterlegt hast. Wenn es wirklich das Kerzenbild ist, dann wäre es durchaus ungünstig dieses verkleinert auf dem Handy anzuzeigen da man die Texte dann gar nicht mehr lesen kann. Du könntest das Plugin hier verwenden:
https://wordpress.org/plugins/responsive-block-control/
Damit kannst Du steuern wann ein Block sichtbar sein soll. So könntest Du das jetzige Bild auf Mobil ausblenden und ein anderes Mobil einblenden.

Du nutzt scheinbar das kommerzielle Thrive Theme und an der Stelle wird eine Beitragsliste ausgegeben, keine Galerie in dem Sinne. Thrive selbst stellt dazu hier eine Hilfeseite bereit in der auch von "random" die Rede ist:
https://help.thrivethemes.com/en/articles/44…st-list-element

Wenn das nicht hilft, wende dich am besten an den Support des von dir genutzten Themes.

Du machst es willigen Helfern aber auch nicht einfach mit dieser unsäglichen Rechtsklicksperre, die man wie immer leicht umgehen kann.

Ergänze das mal im CSS:

.woocommerce div.product p.price del, .woocommerce div.product span.price del {
  display: block;
  margin-bottom: 1em;
}

Um welches Plugin handelt es sich? Was sagt der Support des Plugins dazu?

Sollte dort zu finden sein, ja. Wo es ist hängt von deinem Hosting-Paket ab. IONOS beschreibt das hier: https://www.ionos.de/hilfe/hosting/…zu-log-dateien/

Was @b3317133 beschreibt ist das Debug-Logging von WordPress selbst. Das kann man alternativ dazu ebenso aktivieren und in der darüber erzeugten debug.log dann nachschauen was der Fehler ist.

Eventuell wäre ein Link hilfreich um den Zustand zu sehen. Denn "Layout mehr oder weniger weg" und "404 Seite nicht gefunden" kann weiterhin sehr vieles bedeuten.

Wirf auch mal einen Blick ins Error-Log vom Hosting. Dort müsste die eigentliche Ursache erkennbar sein. Der Support vom Hoster kann dabei sicher helfen.

Wo hast Du das Plugin-Update vorgenommen? Im Staging oder im Live?

Was heißt "komplett down"? Was ist konkret zu sehen?

Dafür muss man nicht zwingend einen eigenen Block erstellen. Es gibt genug zur Auswahl womit man auch das was man ausgeben will sicherlich umsetzen kann.