Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenDer Website ist definitiv gehackt, siehe z.B. auch hier.
Passieren kann das durch vielerlei Dinge, ein mögliches Einfallstor bei Dir ist die veraltete Version 1.4.2 des Plugins "WP GDPR Compliance", mehr dazu z.B. hier im Forum oder z.B. bei heise.de
Das allgemeine Vorgehen bei einem Hack ist z.B. hier beschrieben.
Für professionelle Hilfe kann man z.B. eine Anfrage in der Jobbörse hier im Forum stellen.
Die Eingabe bei "Suchen und Bieten" ist über ein einfaches Formular mit dem "Ninja Forms" Plugin gelöst, die Anzeigen selbst werden offenbar manuell über den "Visual Composer / WPBakery Page Builder" in die Seite eingefügt.
Die Funktion [FONT=Courier New]the_title()[/FONT] ist für Nutzung innerhalb der sog. WordPress "Loop" gedacht und funktioniert auch nur dort, mehr dazu siehe hier. Ausserhalb der "Loop" in Widgets usw. ist je nach Rahmenbedingungen ein anderes Vorgehen nötig.
- Den letzten Punkt kann ich nicht beantworten, den ich weiß nicht was damit gemeint ist.
Würde wie schon andere hier ggf. die Jobbörse im Forum empfehlen, um das ganze sauber von einem Profi aufräumen zu lassen.
Die bisherigen Angaben, keine Logfiles, offenbar kaum technische Erfahrung mit WordPress, SSL usw. deuten darauf hin, dass dieses Problem im Rahmen dieses Threads sehr schwer bis kaum lösbar sein wird.
@SEpp55 War evtl. zu unklar, hier eine kleine Ergänzung:
.. was eine extra eigene zusätzliche DS Erklärung auf der Maintenance Seite erfordern könnte...
(zur Zeit Maintenance on, weil DS Erklärung noch in Arbeit)
Tipp am Rande: Dein Maintenance-Plugin bindet einen externen "Open Sans" Google Webfont ein, das sendet die Besucher IP-Adresse an Google, was eine DS Erklärung auf der Maintenance Seite erfordern könnte...
Markiere den ganzen Text im Editor und klicke dann im Editor-Toolbar in der unteren Zeile das Symbol für "Formatierung löschen", sieht aus wie ein Radiergummi, ein schräg gestelltes Rechteck, dann sollte die Formatierung verschwinden.
Das geht mit [FONT=Courier New]setTimeout(..)[/FONT], wenn man z.B. bei Google nach javascript verzögerung einbauen sucht, findet man einige Seiten, die das ausführlich besprechen, z.B. diese hier.
Mit WordPress oder dem Contact Form 7 hat das aber eher nur am Rande zu tun.
Strato teilt derzeit auf der Loginseite folgendes mit:
Einschränkungen bei der Erreichbarkeit von Websites
Sehr geehrte STRATO Kunden,
aufgrund von DDos-Angriffen kommt es aktuell dazu, dass einige Websites per SSL kurzzeitig nur eingeschränkt erreichbar sind.
Unsere Sicherheitsmechanismen greifen und wehren solche Angriffe ab. Die Einschränkung hat keinen Einfluss auf die Unversehrtheit Ihrer Daten.Wir bedauern eventuelle Unannehmlichkeiten.
Viele Grüße
Ihr STRATO Team
Fragen:
Zwischenstand: Mit "Port 443" hat das alles eher weniger zu tun. Viel Erfolg bei der Lösung.
Kann ähnliche Probleme mit einem Strato SSL Zertifikat an anderer Stelle bestätigen.
@Kati28 Daher eher kein Hack.
Siehe auch ähnliche Meldungen bei Twitter bzw. auch allestörungen.de/stoerung/strato
Evtl. wurden Änderungen direkt im Theme vorgenommen?
Änderungen in Theme-Dateien werden bei jedem Theme-Update überschrieben. In WordPress ist dafür die Verwendung eines sog. Child-Theme vorgesehen, dort bleiben die Änderungen bei Updates des "parent" Theme erhalten.
Ausnahme: Wenn ausschliesslich nur CSS-Ergänzungen vorgenommen werden, trägt man diese im Menü "Design > Customizer > Zusätzliches CSS" ein, dort bleiben CSS-Ergänzungen auch bei einem Theme-Update erhalten, so dass in diesem Fall kein Child-Theme nötig ist.
Spiele ein Backup der alten Theme-Version ein, oder notiere die Änderungen aus einem Backup und übertrage diese dann in ein Child-Theme.
Seltsam, es sind gar keine Scriptschnipsel nötig.
Wenn alles orange weg ist und alleine nur die ganz normale WordPress Einstellung [FONT=Courier New]define('WP_DEBUG', false);[/FONT] benutzt wird, und trotzdem Warnings auftreten, liegt es ggf. an anderen Voreinstellungen des Servers o.ä.
Alternativ kannst Du den ursächlichen, bereits oben verlinkten Fehler in WooCommerce ggf. manuell beheben, bevor ein neues Update rauskommt.
Er sucht das Feld "your-name" und ließt die gesamte var $result aus.
Für Mitleser, es ist umgekehrt, das JavaScript sucht im Browser auf der Seite das Feld "your-name" und schreibt dort die dem Script mitgegebene PHP Variable $result rein.
Um eine PHP-Variable, die erst während der Ausgabe eines Seitentemplates ermittelt wird, serverseitig einem Feld eines CF7-Formulars "mitzugeben", muss der CF7-Shortcode erst nach dem Ermitteln der PHP-Variable ausgegeben werden und man muss zusätzlich das entspr. Attribut registrieren, dann geht sowas wie das hier, ungetestet [FONT=Courier New]<?php echo do_shortcode( '[contact-form-7 ... your-name="' . $result . '"]' ); ?>[/FONT]
Die Voraussetzungen sind aber in diesem Fall nicht gegeben, es wurde z.B. gesagt, das CF7 Formular wäre in einem Widget o.ä., daher ist das hinfällig.
@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.
Das ganze wird gesendet über POST- nicht über GET.
CF7 Getting Default Values from the Context:
Available data sources are: get (HTTP GET variables), post (HTTP POST variables), and post_meta (custom fields)
. 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.
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>";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.
