Beiträge von b3317133

Du hast die Datei ISO-8859-1 encoded gespeichert und Dein einzelner Aufruf kunden.php gibt sie als ISO-8859-1 aus, siehe auch HTTP Header in der Browser Console > Netzwerkanalyse.

Content-Type text/html; charset=ISO-8859-1

WordPress benutzt aber UTF-8, daher gehe vor wie oben beschrieben.

Lt. PHP-Quellcode ist ein entspr. Parameter in der Free Version vorhanden, Du kannst den ja mal testweise auf [FONT=Courier New]'on'[/FONT] stellen und bei Funktion und Gefallen dann das Pro Plugin erwerben.

smart-grid-gallery/includes/functions/parameters.php


       'origincode_gallery_video_ht_view2_content_in_center_lightbox'              => 'off',

Änderungen in Plugin Code natürlich nur mit entspr. Backups und Updates des Plugins überschreiben wieder alles...

Deaktiviere diesen Mechanismus in Rank Math, eine Weiterleitung statt 404 ist nur für einzelne ganz gezielte Links gedacht die irgendwo extern falsch zu Dir verlinkt sind o.ä., alternativ wende Dich an die Person, die dieses Plugin eingerichtet hat, die sollte das wissen und entspr. einstellen können.

Und schau Dir einfach den HTML-Quelltext Deiner Seite in Deinem Browser an, dann siehst Du den Link zur CSS-Datei, dafür brauchst Du kein Pagespeed... Was sagt der Programmierer des CSS dazu?

Im HTML-Quelltext sieht man auch, dass weiterhin offenbar Optimierungs-, Minify- oder Cache-Plugins laufen, warum auch immer, offenbar gibt es kein echtes Interesse an Hilfe, bin raus, ist mir zu mühsam. Viel Erfolg.

Diese Datei existiert nicht auf Deinem Server und irgendein völlig unsinniger Mechanismus leitet bei Dir "404 nicht gefunden" Links auf die Startseite weiter, was dann eine neue Instanz von WordPress startet und das Ergebnis runterlädt und was der Browser dann natürlich nicht als CSS interpretieren kann und dann geht es erst weiter... Was sagt der Programmierer des CSS dazu?

Ergänzend: Für Hilfe bei der Suche nach Ladeproblemen deaktiviere alle Optimierungs-, Minify- und Cache-Plugins, aber das weisst Du ja bereits schon.

Die Quelldatei für Kunden ist nach wie vor ISO-8859-1 encoded, daher werden die Sonderzeichen so gezeigt.

Stelle das Encoding vor dem Upload der Datei im Texteditor auf UTF-8 (ohne BOM) um oder wandle die Daten per PHP Code vor der Ausgabe in UTF-8 um.

Nach wie vor ist völlig unklar, welches CSS Du meinen könntest... keine Antworten = keine Hilfe möglich.

Welches CSS? Welche extra Datei? Was sagt der Programmierer des CSS dazu? Screenshot der entspr. Meldung?

Die Ladezeit der leutaschklamm Seite wird nach kurzem Einblick vor allem durch eine Vielzahl von externen Einbindungen ([plain]fonts.googleapis.com, fonts.gstatic.com, m.media-amazon.com, http://www.komoot.de, maps.google.com, api.mapbox.com, account.komoot.com, tiles-api.maps.komoot.net, events.mapbox.com, maps.googleapis.com, zig subdomains von tiles-api.maps.komoot.net[/plain] und viele, viele weitere externe Dateien von verschiedenen Trackern) beeinflusst.

Für Hilfe bei der Suche nach Ladeproblemen deaktiviere alle Optimierungs-, Minify- und Cache-Plugins, derzeit mind. aktiv: Autoptimize, weiterhin alle Tracking-, Statistik- und Werbung-Plugins (Google Analytics, Adsense o.ä., WP-Statistics, VG Wort, Amazon, ...), dann kann man ggf. zuordnen, was wo wie woher kommt bzw. für die genannte "enorme Ladezeitverzögerung" verantwortlich sein könnte.

Bei Kunden ist der [FONT=Courier New]<html>[/FONT] und [FONT=Courier New]<head>[/FONT] Tag mit Inhalt zu viel und die Quelldatei ist ISO-8851-1 encoded statt UTF-8.

Bei Social ist ein [FONT=Courier New]<body>[/FONT] Tag zu viel und die Bilder sind wegen [FONT=Courier New]<td width="1%"></td>[/FONT] in der ersten Zeile der Tabelle unsichtbar.

Die Position wird vom verwendeten Script berechnet, das betrifft auch andere Breakpoints bzw. Bildschirmbreiten wenn nur zwei Bilder nebeneinander stehen usw.. Vermutlich gibt es eine Einstellung im entspr. Plugin, zumindest der Code [FONT=Courier New]data-show-center="on"[/FONT] in einem der Beispiele des Plugins mit zentrierter Anzeige lässt darauf schliessen.

Zitat von angalo

Wo kann ich da mit der Fehlersuche ansetzen?

Beispielsweise in der Dokumentation von Contact Form 7. Dort ist auch was zum genannten Tag zu finden:

Zitat

reCAPTCHA v3 doesn’t need a CAPTCHA widget ... to work, so [recaptcha] form-tags are no longer necessary.

Weiterhin in den Forenregeln, ein Link zur Seite fehlt...

#site-navigation button:active,
#site-navigation button:focus {
   outline: none;
}

Evtl. zusätzlich noch [FONT=Courier New]border: none;[/FONT] wobei ich hier den grauen Rand nicht reproduzieren konnte...

Deaktiviere testweise alle Optimierungs-, Minify- und Cache-Plugins. Weiterhin deaktiviere testweise alle "Sicherheits"-Plugins. Und leere dann Deinen Browser Cache. Ändert das etwas am Verhalten? Link zur Seite?

Evtl. steht in der [FONT=Courier New]wp-config.php[/FONT] irgendwo noch [FONT=Courier New]define('RELOCATE',true);[/FONT] oder es läuft ggf. noch irgendein SSL/https Plugin...[FONT=Courier New][/FONT]

Ein Theme aktualisiert man immer im gleichen Ordner, nicht wie hier offenbar in einem neuen Ordner, sonst kann und wird da sehr viel schiefgehen. Eine vorherige Version kann man vorher z.B. per FTP sichern und bei Bedarf dann den ganzen Ordner durch die alte Version ersetzen.

Generell ist natürlich ein vollständiges Backup des ganzen Websites inkl. Datenbank vor dem Einspielen von Updates ratsam.

Weitere Hinweise bei "leeren Seiten" ergeben sich aus dem PHP Error Log beim Hosting, vermutlich ein Fehler 500 durch was auch immer, von alter PHP Version bis hin zu sonstigen Inkompatibilitäten mit dem Child Theme oder Plugins o.ä. ist alles möglich.

Am besten wendet man sich an die Person, die den Website ursprünglich eingerichtet hat, die sollte den nötigen Sachverstand mitbringen, die Probleme zu identifizieren und zu beheben.

Und ergänzend ein technischer Tipp am Rande: Aus irgendwelchen Gründen wird neben der jQuery Version von WordPress parallel eine weitere jQuery Version 3.2.1 von einem externen CDN eingebunden, das sollte man beheben. Diese Einbindung und auch die Einbindung externer Google Webfonts fehlen zudem in der Datenschutzerklärung.

Meinst Du mit "WP" evtl. wordpress.com? Dann wäre ggf. der Support von wordpress.com zuständig.

Evtl. stimmen auch irgendwelche DNS Einträge bei UD nicht (mehr).

Dieses Forum hier ist nur für selbstgehostetes WordPress von wordpress.org - die Unterschiede werden z.B. hier erklärt.

Deine Beschreibung ist bisher leider zu ungenau, siehe auch Forenregeln.

Zitat von RW1

... kommt ein Hinweis von UD, meinem Provider.
Wer kann mir helfen?

Dein Provider.

Oder jemand mit FTP-Zugang und/oder UD-Zugang zum dort Nachvollziehen, was passiert sein könnte.

Backup einspielen und Passwörter ändern ist meist nicht ausreichend, da das in der Regel die Lücke nicht schliesst, der Angreifer wird vermutlich wiederkommen, meist vollautomatisierte Bots.

Das allgemeine Vorgehen mit allen notwendigen Schritten bei einem Hack ist z.B. hier beschrieben.

Die im ersten Screenshot sichtbare ".. not allowed .." Seite ist lt. dem Link in der URL-Zeile eine Seite eines "Akeeba Kickstart" Plugins o.ä. und nicht der WordPress Update Vorgang, den man üblicherweise über den blauen Button "Update Now" im zweiten Screenshot erreicht.

Würde vorschlagen, dieses Plugin zu deaktivieren bzw. die Person anzusprechen, die den Website eingerichtet hat, die sollte helfen können.

Falls auch eine Lösung ausserhalb von WordPress in Betracht kommen sollte, z.B. dieses System hier wird hier im Umfeld von einigen Sportvereinen genutzt (mit teils etwas notwendiger Hilfe bei der Installation).

Wann/wo genau erscheint diese Meldung? Was genau klickst Du vorher an? Screenshots?

Versuche es auch mal mit einer älteren PHP Version oder mit einem anderen Theme.