Beiträge von b3317133

    Jetzt wird mir meine Seite, teils unsauber angezeigt.


    Regeneriere die CSS Dateien von Elementor z.B. hier beschrieben und Essential Addons for Elementor z.B. hier beschrieben.

    Passe weiterhin die Pfade in der Datenbank mit einem Plugin wie Better Search Replace entspr. für https/SSL an, mehr dazu findest Du, indem Du den Pluginnamen oder WordPress Umzug o.ä. in die Forumsuche eingibst.

    Vermutlich wurde der Website beim neuen Hoster unsachgemäss mit https/SSL eingespielt bzw. unvollständig umgestellt.

    Und wo genau sind welche SQL-Fehler wie im Titel beschrieben?

    Es ist nichts verwerfliches daran, sich bei Fragen zum eigenen Hosting an den Support des Webhosters zu wenden, das ist normalerweise klar der erste Ansprechpartner.

    Der Support des Webhosters sollte Dir mitteilen können, ob irgendetwas Absicht oder eine Masche oder eine normale Funktionen des Hostings ist.

    Einen wie auch immer gearteten Zusammenhang zum restlichen Text bzgl. mutmasslicher Drohemails usw. sehe ich nicht. Keine Ahnung was das mit dem Installieren eines Scripts bzw. mit Hostingfunktionen zu tun haben könnte.

    Diese URL ist keine WordPress Seite.

    Der Aufruf wird mehrfach per meta refresh weitergeleitet, Google folgt solchen Weiterleitungen.

    Code
    https://www.toXXXXXeck.ch/angebot.php
    -> https://ssl.toXXXXXck.ch/?zugang=angebot.toXXXXXeck.ch


    Diese Seite enthält ungültiges HTML und mehrfaches noindex:

    HTML
    <head/><meta name="robots" content="noindex,nofollow">
    <html>
    <head>
    <meta name="robots" content="NOINDEX,NOFOLLOW">
    </head>
    ...


    und leitet direkt auf die nächste Seite weiter:

    Code
    -> https://www.toXXXXXeck.ch/wp/angebot


    Der Pfad zu dieser Seite ist in der robots.txt der Domain manuell als verboten eingetragen:

    Code
    https://www.toXXXXXeck.ch/robots.txt
    ->
    Sitemap: http://www.toXXXXXeck.ch/sitemap.xml
    
    
    User-agent: *
    Allow: *
    Disallow: /wp/


    Insofern gar kein Wunder, dass Google das nicht erfassen will.

    Auf den Search Console Screenshots ist nicht sichtbar, welche URL getestet wurde.

    Ein Google Search Console Forum findet man z.B. so: https://www.google.com/search?q=Google+Search+Console+Forum

    Mit WordPress hat das alles rein gar nichts zu tun.

    • Link zur URL mit der diese Meldung auftritt? Siehe auch Forenregeln Punkt II.
    • Screenshot des Live URL Tests?


    Viele Search Console Fragen, die hier in einem WordPress-Forum eigentlich eher komplett fehl am Platz sind, sind auf falsche Interpretationen der Möglichkeiten, Anzeigen und Einträge in der Search Console zurückzuführen...

    Das hat nur noch historische Gründe, dazu gibt es immer wieder mal Diskussionen hier und da.

    Inzwischen soll eigentlich gar kein HTML aus Texteingabefeldern wie Titel gerendert werden, da z.B. bei defekten Tags das ganze Layout in Mitleidenschaft gezogen werden kann, ganz zu schweigen von XSS-Ansatzpunkten:

    Zitat

    esc_html() – Use this function anytime an HTML element encloses a section of data being displayed.

    Im standard Menü-Walker wird auch noch seit eh und je ein [FONT=Courier New]the_title[/FONT] Filter aufgerufen, zusätzlich zu einem seit 4.4.0 ergänzten [FONT=Courier New]nav_menu_item_title[/FONT] Filter, aber so richtig anzufassen und sauber [FONT=Courier New]esc_html[/FONT] dort einzubauen hat sich noch keiner getraut, vermutlich zu viele Altlasten und kein durchgängig sauberes Konzept bzw. alte Sonderfälle usw.

    Der neue Link ist jetzt eine HTML-Datei aus Excel:

    HTML
    <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"
    xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">
    <head>
    <meta name="Excel Workbook Frameset">
    <meta http-equiv=Content-Type content="text/html; charset=windows-1252">
    <meta name=ProgId content=Excel.Sheet>...


    Die HTML-Datei erzeugt ein Frameset und versucht dann weitere Dateien zu laden:

    Code
    <frameset rows="*,39" border="0" width="0" frameborder="no" framespacing="0">
     <frame src="Gehaltsliste-Dateien/sheet001.htm" name="frSheet">
     <frame src="Gehaltsliste-Dateien/tabstrip.htm" name="frTabs" marginwidth="0" marginheight="0">
     <noframes> ...  </noframes>
    </frameset>


    Diese Dateien gibt es aber derzeit nicht auf dem Server, daher wird stattdessen in den Frames zwei mal untereinander die WordPress 404 Seite gezeigt.

    Der Balken kommt aus dem generierten CSS Deines Themes, vermutlich ist das irgendwo in den Theme Einstellungen so eingestellt.

    CSS
    body {
        padding-bottom: 100px !important;
    }
    in:
    https://www.hochzeitskleider-brautmaedchen.at/wp-content/themes/wp-gusto/cache/gzip.php?theme-d7cdd807.css

    Der Link war vorher:

    Code
    https://pes-legenden.de/htdocs/gehaltslisten/Test.mht


    Der Link ist jetzt ein völlig anderer:

    Code
    https://pes-legenden.de/gehaltslisten/gehaltsliste.htm


    Der Link von vorher ohne [FONT=Courier New]/htdocs[/FONT] funktioniert und zeigt derzeit hier in Firefox wirre Daten an.

    Code
    MIME-Version: 1.0
    X-Document-Type: Workbook
    Content-Type: multipart/related; boundary="----=_NextPart_01D6604B.710EB010"
    Dieses Dokument ist eine Webseite in einer Datei, auch als Webarchivdatei bezeichnet.  Wenn diese Meldung angezeigt wird, unterstützt Ihr Browser oder Editor keine Webarchivdateien.  Laden Sie einen Browser herunter, der Webarchive unterstützt.
    ------=_NextPart_01D6604B.710EB010
    Content-Location: file:///C:/AAF228D2/GehaltslisteVorlage2.htm
    ...


    Mit WordPress hat das alles nichts zu tun.

    Wenn das W3 Total Cache Plugin komplett deaktiviert wäre, könnte keine Meldung des W3 Total Cache Plugins im Log erscheinen...

    Zitat

    ...WP_Query->get_posts, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection_QueryCaching->query, W3TC\_CallUnderlying->query, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query

    Zitat

    ...WP_Query->get_posts, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection_QueryCaching->query, W3TC\_CallUnderlying->query, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query


    Deaktiviere mal komplett das Plugin W3 Total Cache, ändert das etwas?

    Der Autor des W3 Total Cache Plugins schreibt hier zu einem ählichen Problem:

    Zitat

    ...In other words, if you are on a shared hosting, it’s recommended not to use database caching. ...

    Das beschriebene Problem wird hier vermutlich nicht gelöst werden, da das kommerzielle Hosting bei WordPress.com etwas völlig anderes ist, als die hier im Forum behandelten Fragen zu selbstgehosteten Installationen, die Unterschiede sind z.B. hier beschrieben.

    Suche Dir am besten in Deinem lokalen Umfeld jemanden, der sich gut mit WordPress auskennt, und lasse den das alles in Kombination bzw. Absprache mit dem WordPress.com Support machen, dann kannst Du dabei zusehen und lernen. Viel Erfolg!