Beiträge von b3317133

@mensmaximus Das ist schon klar. Nur wird dieser Filter nirgends im Core verwendet, daher kann es meiner Meinung nach bei gesetzter Konstante keine "forced" Core Updates geben, auch wenn das im Netz immer wieder mal anders beschrieben wird.

Zitat von itsmejay

Das ganze wird gesendet über POST- nicht über GET.

CF7 Getting Default Values from the Context:

Zitat

Available data sources are: get (HTTP GET variables), post (HTTP POST variables), and post_meta (custom fields)

Zitat von itsmejay

. Ich verstehe halt nicht was für ein redirect und wohin dieser gehen soll wenn sich doch alles bereits in Template1.php befindet?

Wie gesagt, zu viele Unklarheiten. Evtl. geht es auch per JavaScript ohne Redirect.

• In Dein HTML-Formular gibt man Daten ein, dann klickt man auf Senden?
• Das Ziel beim Absenden ist die Seite mit Deinem Template?
  
• Dann kommt der PHP-Code im Template "Template1.php" per $_POST an die Daten?
• Dann macht der der Code was damit und Du hast am Ende die PHP-Variable $result?
• Zu dem Zeitpunkt ist der Header von WordPress auf dieser Seite schon gesendet, also wp_head() schon aufgerufen?

Wenn das alles zutrifft, könnte man das Ergebnis in ein kleines JavaScript verpacken und von PHP aus ausgeben. Das JavaScript sucht sich dann beim Besucher im Browser das Formular innerhalb der gleichen Seite und setzt das Ergebnis in das gewünschte Feld, sowas in der Art, ungetestet:

echo "<script>jQuery(document).ready(function(){jQuery('.wpcf7-form input[name=\"your-name\"]').val('" . $result . "');});</script>";

Zitat von arol

Wie kann ich dann finden welche Code nicht kompatibel ist?

Meist durch das Lesen des Fehlermeldung, oder dem error.log beim Provider. Ggf. durch Aktualisieren von WordPress, wenn es sehr alt ist. Auch durch das Aktualisieren von Plugins & Theme. Oder durch das Entfernen alter Plugins für die es schon laaange keine Updates mehr gibt. Oder auch durch das Lesen von Code. Da gibt es viele Möglichkeiten...

Leider sind die Rahmenbedinungen weiterhin sehr dürftig. Dass das CF7 Formular in einem Widget steht, war bisher völlig unklar. Wie Dein Formular angezeigt wird, ist unklar. Wie Deinem Formular die Daten übergeben werden, ist unklar. Redirecte doch einfach mal auf die aktuelle Seite, nur eben mit dem passenden CF7-Parameter.

Stelle die PHP Version beim Hosting zurück auf 7.0.x.

Und die echte Lösung ist, repariere den Code, der offenbar nicht kompatibel zu PHP 7.1.x oder PHP 7.2.x ist.

Da ich nicht weiss, wie Dein template1.php aufgerufen wird und ob vor dem möglichen Redirect schon Ausgaben stattfinden, ist das schwer zu beantworten.

Üblicherweise im WordPress Kontext via wp_redirect( .. ) oder im einfachen PHP Kontext mit header( 'Location: http://example.com/contact/?your-name=John+Smith' ); o.ä., via JavaScript wäre während der Ausgabe der Seite ein Redirect möglich, kommt eben ganz auf Deine Rahmenbedingungen an.

Das allgemeine Vorgehen bei einem Hack ist z.B. hier beschrieben.

Zitat von Benedikt86

Habt ihr mir vielleicht einen Vorschlag wie ich solche Änderungen unterbinden kann?

Du könntest z.B. das Plugin WP GDRP Compliance, über das der Hacker eingebrochen ist, und das beim ersten o.g. Website nach wie vor in der Version 1.4.2 online ist, auf die Version 1.4.3 mit dem entspr. Fix aktualisieren. o_O

Wenn sich das Formular auf einer extra Seite befindet, kannst Du z.B. von Deiner Berechnung aus einen Redirect auf diese Seite mit dem entspr. Parameter machen und automatisch in ein Feld von CF7 einfügen.

PS. Nutzt Du wirklich WordPress 5.0?

Der Hacker hatte über die im Beispiel genannte und derzeit massiv genutzte Sicherheitslücke Schreibrechte für [FONT=Courier New]update_option()[/FONT] und konnte damit entweder einfach nur die [FONT=Courier New]siteurl[/FONT] überschreiben oder wenn er/sie/es mehr Lust/Expertise/Ein besseres Script gekauft hatte, den Laden ganz übernehmen mit [FONT=Courier New]users_can_register -> 1[/FONT] und [FONT=Courier New]default_role -> administrator[/FONT] und einen neuen Benutzer registrieren, der dann autom. ein Admin wird, meist admin13, t2trollherten, t3trollherten o.ä., und darüber dann auch entspr. Backdoors für später einbaut/hinterlässt.

Daher und aber auch generell bei jedem Hack ist eine umfassende Analyse aller Dateien in allen per PHP zugänglichen Ordnern und Dateien auf dem Server und dem gesamten Inhalt der Datenbank die einzig richtige Herangehensweise.

Das Entfernen eines Symptoms entfernt oft nicht wirklich auch die wahre Ursache bzw. sonstige Hinterlassenschaften.

@mensmaximus Den Filter [FONT=Courier New]automatic_updater_disabled[/FONT] kenne ich, aber wo im Core wird dieser Filter auch benutzt / überstimmt? Ich kenne keine Stelle.

Das berühmte Yoast 1.7.4 Update war ein Plugin Update, das von den wordpress.org Leuten mit dem nur für sie zugänglichen Flag [FONT=Courier New]$item->autoupdate[/FONT] in der "Update offer" ins Repository gestellt wurde, wenn ich das recht in Erinnerung habe, was dann hier das entspr. $update Flag auf true setzt und das Update automatisch installiert. Mit JetPack gab es mal einen ähnlichen Fall.

Auf Websites mit [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED == true[/FONT] oder [FONT=Courier New]add_filter( 'auto_update_plugin', '__return_false' );[/FONT] dürfte bzw. kann auch so ein spezielles Update nicht "forced" installiert werden. Im ersten Fall kommt der Codeflow gar nicht bis zur [FONT=Courier New]$item->autoupdate[/FONT] Abfrage, im zweiten Fall wird das Flag durch den Filter direkt danach wieder auf false gesetzt.

Zu dem Thema gibt es viel unklares und halbwahres im Netz, daher die Nachfrage.

Was für ein Plugin für Benachrichtigungen?

Und sind jetzt alle "Updater" Plugins deaktiviert?

Evtl. steht der Eintrag [FONT=Courier New]define( 'AUTOMATIC_UPDATER_DISABLED', true );[/FONT] bei Dir auch an einer falschen Stelle in der Datei [FONT=Courier New]wp-config.php[/FONT] ? Poste mal alles aus der [FONT=Courier New]wp-config.php[/FONT] ab der Zeile mit [FONT=Courier New]define ('WPLANG', ...[/FONT] , die Zeilen vorher nicht.

Schau mal die [FONT=Courier New]siteurl[/FONT] in den Datenbanken in der jeweiligen Tabelle [FONT=Courier New]wp_options[/FONT] an, ähnlich wie hier.

@mensmaximus Bei welcher genauen Core Version wurde das getan? Wo befindet sich der Code, der ein auf [FONT=Courier New]true[/FONT] gesetztes [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] für den Core überstimmt?

Am Rande für Mitleser, nicht [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] verwechseln mit [FONT=Courier New]WP_AUTO_UPDATE_CORE[/FONT], das z.B. auf autom. Updates von Plugins keinen Einfluss hat.

Die Links z.B. auf die Kontakt oder Datenschutz Seiten sind "hardgecodet" eingegeben, daher hat die "Permalinks" Einstellungen hier keine Auswirkungen.

Leere zwischen allen Versuchen Deinen Browser Cache.

Zitat von gerega

Ich weiß auch nicht, inwiefern ein Plugin, das ich mööööglicherweise in der letzten Zeit in meiner multisite-Installation verantwortlich sein könnte.

Deaktiviere temporär dieses Plugin, speichere dann erneut die Permalinks, funktioniert es dann?

Falls nein, deaktiviere der Reihe nach temporär alle vorhandenen Plugins, speichere jeweils dazwischen die Permalinks. Ändert das etwas?

Du kannst versuchen, ohne weitere Änderungen im Menü "Einstellungen > Permalinks > Speichern" anzuklicken, hilft das?

Weiterhin kann es sein, dass die Beseitigung des o.g. Hacks unvollständig war und dadurch ggf. noch Nebenwirkungen entstehen.

Die besagte Suchabfrage ist bei Dir in der "404 nicht gefunden" Seite integriert, die erscheint, wenn ein Link nicht funktioniert oder ins Leere zeigt.

Wenn [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] auf [FONT=Courier New]true[/FONT] gesetzt ist, sollte keinerlei Updates automatisch installiert werden, weder Core noch Plugins & Themes, mehr dazu hier.

Eigene Einträge bzgl. Updates in [FONT=Courier New]wp-config.php[/FONT] sollte man nicht mit entspr. Plugins kombinieren, hier gilt das "zu viele Köche" Sprichwort...

Die Inhalte der Beiträge usw. befinden sich in der Datenbank und werden von Better Search Replace gefunden.

Direkte Änderungen in den Theme-Dateien, z.B. in single.php, header.php o.ä. werden nicht von Better Search Replace gefunden.

Bzgl. "OFF" für Mitleser: Die REST-API ist bei WordPress standardmässig zugänglich. Um Zugriffe von aussen zu unterbinden, muss man explizit ein extra Plugin o.ä. installieren.

Bzgl. des eigentlichen Problems, inzwischen sind die Pfade offenbar teils mit doppelten Slashes wie [FONT=Courier New]//[/FONT] versehen, oder sie zeigen fälschlicherweise auf interne Dateipfade des Servers wie [FONT=Courier New]/www/htdocs/w00XXX/..[/FONT], das deutet darauf hin, dass irgendwas an der Datenbank herumgebastelt wird, was eine später Hilfe dann immer schwerer macht. Viel Erfolg damit.

Es handelt sich offenbar um ein Kauf-Theme, Hilfe von aussen ist daher nicht so leicht möglich weil man den Quellcode nicht einsehen und das Theme auch nicht testweise schnell mal installieren kann.

Könnte es sein, dass für den Slider und/oder die anderen Elemente der Startseite nur bestimmte Kategorien eingestellt sind? Würde dort mal in den entspr. Widgets oder den Einstellungen suchen.

Evtl. wurde sowas auch bei der Erstinstallation im Code des Themes eingefügt, hast Du die ganze Installation selbst gemacht?