Beiträge von b3317133

Der o.g. Link zum RSS-Feed erzeugt hier eine endlose Redirect-Schleife auf sich selbst, daran wird es wohl liegen...

Wenn Du nicht genau weisst, wo das Script herkam, ist der Website als kompromitiert zu betrachten, solange die Herkunft nicht geklärt und das Einfallstor geschlossen ist.

Was ist mit "Sucuri MAlfinder" gemeint? Das Sucuri Security Plugin für WordPress? Die Remove Website Malware Dienstleistung von Sucuri?

Was antwortet der simplesite Support auf die Frage nach Exportmöglichkeiten der Website Daten?

Zitat von B&F Webdesign Studio

.. denn der übernimmt dann auch die Haftung.

Ein Anwalt übernimmt in der Regel eine Haftung im Rahmen der gesetzlichen Bestimmungen für seine Rechtsprüfung des aktuellen Standes des Shops. Und das war es auch schon.

Letztlich verantwortlich für alles ist immer der Shop-Betreiber.

Support und Hilfe zum neuen Gutenberg Editor gibt es am besten wie hier beschrieben.

Das "Classic Editor" Plugin ist Stand heute bei über 3 Millionen Websites im Einsatz, hier einige Downloadstatistiken, Du bist damit also bei weitem nicht alleine...

Zitat von mensmaximus

Bitte unbedingt sanitizen! Diese PHP Snippet Plugins eigenen sich zusammen mit $_GET Parametern..

Auch zusammen mit [FONT=Courier New]$_POST[/FONT] Parametern oder auch gerne mal mit [FONT=Courier New]$_COOKIE[/FONT] Werten, sanitizen sollte man natürlich immer alles. Wenn das o.g. PHP-Script jetzt via [FONT=Courier New]$_REQUEST[/FONT] "unsicher" ist, dann war es das vorher auch schon, aber es ist natürlich völlig richtig, auf diese Problematik hinzuweisen, einmal zum Thema SQL-Injection oder Remote File Inclusion aber auch gerade wenn wie bei der hier geplanten Änderung die übergebenen Werte auch wieder ausgegeben werden sollen, hier empfiehlt sich Lektüre zu esc_url(), esc_html(), esc_attr() usw.

Vermutlich würde man im PHP-Script [FONT=Courier New]$_POST['var_icfcode'][/FONT] ändern auf [FONT=Courier New]$_REQUEST['var_icfcode'][/FONT] damit wird sowohl [FONT=Courier New]$_POST[/FONT] als auch [FONT=Courier New]$_GET[/FONT] abgefragt, und für die Links in der ASCII-Datei würde man vermutlich wohl sowas in der Art nutzen:

bla bla <a href="https://www.example.com/informationen/hilfen-zum-behindertenrecht/icf_decoder/?var_icfcode=b167">b167</a> bla blub bla

Das sind aber wirklich einfachste HTML / PHP Formular Grundlagen, mit WordPress hat das eher nichts zu tun.

Man sucht mit preg_replace_callback() z.B. nach allen Zahlen und ersetzt die dann jeweils durch ein Stück HTML-Code mit der entspr. Zahl darin = ein Link.

Woher kommen denn die Links? Wohin sollen sie linken?

Wenn die Tabelle in einer ASCII-Datei vorliegt, kannst Du Links auch einfach dort reinschreiben?

Am Rande, ein Cookie Banner sollte reichen, derzeit einer oben (der mit dem von @SirEctor genannten Fehler) und noch ein anderer unten aus dem Plugin Jetpack.

Sicher, dass das hier funktionert?

wp_enqueue_script( 'my-great-script', get_template_directory_uri() . '/wp-includes/js/jquery/jquery.js', array( 'jquery' ), '1.2.4', true );

Das würde bedeuten, dass sich der WordPress Systemordner [FONT=Courier New]wp-includes[/FONT] innerhalb des (Parent) Theme Ordners befindet? Und weiterhin ist als Dependency / Abhängigkeit [FONT=Courier New]'jquery'[/FONT] angegeben, also die normale jQuery Systemversion von WordPress.

Und nach einem [FONT=Courier New]wp_deregister_script('jquery');[/FONT] wird / kann ein [FONT=Courier New]wp_enqueue_script('jquery');[/FONT] bzw. auch eine Dependency / Abhängigkeit eher nicht mehr funktionieren.

Welches Theme wird verwendet, wo genau wird welcher Code eingefügt, Link zur Seite?

Da sieht jetzt alles ok aus.

Der Redirect von https auf http innerhalb von WordPress ist allerdings immer noch vorhanden. Weitertesten wie siehe oben (Plugins deaktivieren, anderes Theme, ...)

Zitat von ASenna

Ich wäre dankbar für einen Tipp, in welche Richtung ich hier denken muss.

Beispielsweise in Richtung preg_replace_callback() o.ä. vor der Ausgabe...

Zitat von PGSolution

Habe nun die wp_config bearbeitet.

Und was steht in der Datei [FONT=Courier New]wp-config.php[/FONT] jetzt genau drin?

Die Zeilen mit den [FONT=Courier New]DB_xx..[/FONT] Datenbankzugangsdaten und die Zeilen mit den [FONT=Courier New]..xx_KEY[/FONT] und [FONT=Courier New]..xx_SALT[/FONT] beim hier Posten anonymisieren oder weglassen.

Eine Strato SSL-Weiterleitung würde sich auch auf sonstige statische Dateien wie /readme.html auswirken, zudem würde sie in die andere Richtung funktionieren, also http auf https und nicht wie derzeit bei den WordPress Seiten umgekehrt von https auf http...

@maxe Derzeit leitet irgendein Mechanismus von https zurück auf http weiter, und bei der Startseite wird es dann endlos, Ping Pong zwischen https und http, weil WordPress auf https eingerichtet ist.

Diesen "zurück zu http" Mechanismus gilt es zu finden und abzustellen, siehe auch Ergänzungen in #12.

Hm, hier funktionieren Aufrufe der einzelnen Seiten wie [plain]https://deineseite.de/about/[/plain], leiten aber per 301 auf http weiter, also läuft irgendwo noch ein Mechanismus, der das verursacht.

Deaktiviere der Reihe nach alle Plugins, befrage den Autor des Websites bzw. Child-Themes, ob dort oder in der wp-config.php ggf. irgendwelche Redirects eingebaut sind, und stelle sicher, dass in der .htaccess nur der Teil "Basic WP" steht, sonst nichts. Evtl. hilft es auch, zwischendrin "Einstellungen > Permalinks" zu speichern, das leert die internen rewriterules von WordPress. Der Redirect kommt relativ sicher irgendwo aus WordPress, da statische Dateien wie [plain]https://deineseite.de/readme.html[/plain] nicht auf http redirected werden.

[plain]https://deineseite.de/wp-login.php[/plain] funktioniert, melde Dich dort an, leere Deinen Browser-Cache und deaktiviere Deine Cache-Plugins falls noch nicht geschehen und verwende das Plugin "Better Search Replace", um in der Datenbank [plain]http://deineseite.de[/plain] durch [plain]https://deineseite.de[/plain] zu ersetzen. Weitere Stichworte für Suchmaschinen und Forumsuche: WordPress Umzug

Bei der anderen Seite ist lt. [plain]deineseite.de/wp-json[/plain] in WordPress unter "Einstellungen > Allgemein" einmal "http" und einmal "https" hinterlegt, das kollidiert wohl, weiterhin siehe Hinweise zum Cache-Plugin, deaktiviere das, bis alles funktioniert.

Nein, siehe in #2, was bei Standard-Visibility-PW-Schutz erfasst wird..

Die Seite ist offenbar für https eingerichtet und funktioniert derzeit von hier aus gut.

Leere Deinen Browser Cache und bei solchen Änderungen immer auch den WP Rocket Cache oder deaktiviere das Plugin.