- Der Aufbau der WordPress Datenbank ist hier beschrieben: https://codex.wordpress.org/Database_Description
- Themes und Plugins nutzen u.a. diese APIs für Zugriffe auf die Datenbank: https://developer.wordpress.org/apis/handbook/database/
- Im Einzelfall kann man an den APIs vorbei über die $wpdb Klasse etwas direkter mit der Datenbank kommunizieren: https://developer.wordpress.org/reference/classes/wpdb/
Beiträge von b3317133
-
-
Mit welcher Domain wurde WordPress installiert? Das sollte in diesem Fall mit der dyndns Domain gemacht werden...
-
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.
Codehttps://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:
Der Pfad zu dieser Seite ist in der robots.txt der Domain manuell als verboten eingetragen:Codehttps://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:
Zitatesc_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 Fehler in diesem Fall ist eher, dass das [FONT=Courier New]<br>[/FONT] im Desktop Menü nicht "escaped" wird, mehr dazu hier im WordPress Theme Developer Handbook.
-
- Link zur Seite? Siehe auch Forenregeln Punkt II.
- Screenshot Google Search Console wo das Crawling Datum sichtbar ist?
- Ergebnis Google Search Console Live URL Test?
- Die Datei für Suchmaschinen heisst robots.txt, nicht Root.txt
- Link zur Seite? Siehe auch Forenregeln Punkt II.
-
Die fehlenden Dateien bzw. Ordner auf den Server laden? Excel speichert "als Webseite" mehr als nur eine Datei. Lies mal etwas nach, wie frameset, frame usw. funktionieren (google).
Aber wie gesagt, mit WordPress hat das alles nichts zu tun.
-
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 Link war vorher:
Der Link ist jetzt ein völlig anderer:
Der Link von vorher ohne [FONT=Courier New]/htdocs[/FONT] funktioniert und zeigt derzeit hier in Firefox wirre Daten an.CodeMIME-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. -
Hier ist ein ähnliches gelöstes Problem, das auf ein Einspielen der Datenbanktablelle via MySQL Dumper statt phpMyAdmin zurückzuführen war. Hier ebenso. Evtl. in dieser Richtung weiterforschen. Viel Erfolg.
-
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
-
Der Link hat den falschen Pfad, [FONT=Courier New]/htdocs[/FONT] muss raus.
-
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. ...
-
Poste den Link, dann kann Dir evtl. jemand helfen... siehe auch Forenregeln, Punkt II.
-
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!