Hier wird das Bild in Chrome jetzt angezeigt.
Die Refresh Rate ist relativ hoch, das könnte bei vielen Besuchern den Server etwas nerven, würde das von 2 Sekunden auf mindestens 1 Minute o.ä. hochstellen.
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 erstellenHier wird das Bild in Chrome jetzt angezeigt.
Die Refresh Rate ist relativ hoch, das könnte bei vielen Besuchern den Server etwas nerven, würde das von 2 Sekunden auf mindestens 1 Minute o.ä. hochstellen.
Ein Update des Plugins Ocean Extra bzw. die Reihenfolge von Updates ging schief. Hier im Ocean Extra Plugin Support Forum wird das Problem beschrieben und Lösungen vorgeschlagen, schau Dir das mal an.
Möglichkeiten:
Deaktiviere / entferne mal das [FONT=Courier New]refreshCam()[/FONT] Script. Wird das Bild dann auch in Chrome gezeigt?
Am Rande bemerkt enthält das Script derzeit einen http statt https Link.
Tipp am Rande: Es gibt Leute, die aktivieren irgendwelche Funktionen in irgendwelcher "Sicherheitssoftware", die auf ihrem Endgerät oder in ihrem Router installiert ist, ohne überhaupt zu wissen, dass sie dann ein VPN o.ä. nutzen.
Es laufen weiterhin Optimierungs-Plugins, mind. Ezoic. Damit kann man die Seite von aussen nicht vernünftig analysieren.
Und wo genau wird was genau "zerschossen" dargestellt? Sehe keine Kategorien und keine Tags auf der aktuellen Startseite.
Ergänzung: Nach wie vor ist die wichtigste Frage offen: Hat das Einspielen eines Backups von vor dem WordPress Update geholfen?
Ist es denn sicher eine Zip-Datei? Oder ggf. eine Duplicator [FONT=Courier New].daf[/FONT] Datei?
Verwende ein Programm wie 7-Zip o.ä. und extrahiere nur die genannte Datei.
Es besteht natürlich auch noch die Möglichkeit, dass die Zip-Datei fehlerhaft ist.
Link zur Seite wo man das ansehen kann?
Die Komponete geht oft aus der Reihenfolge der Einbindung und ggf. vorhandenen Attributen im entspr. Tag im HTML Quelltext hervor. Alternativ schaut man, für welche Elemente auf der Seite diese Schriften verwendet werden und ermittelt darüber die entspr. Komponente. Alternativ spricht man den Ersteller der Webseite an, der sollte wissen, wo welche Schriften eingestellt wurden. Alternativ schaut man sich das Theme und die Plugins und deren Einstellungen selbst an, gern auch mal den Code. Und wenn man es dann immer noch nicht rausgefunden hat, kann man die "temporär Komponenten deaktivieren" Alternative nutzen.
Und wenn Du Pages als Ergebnis suchst, setze den [FONT=Courier New]post_type[/FONT] Parameter für [FONT=Courier New]WP_Query()[/FONT] entsprechend.
Versuche es z.B. damit, siehe auch [FONT=Courier New]esc_like()[/FONT] und [FONT=Courier New]posts_where[/FONT] Dokumentation.
add_filter( 'posts_where', 'startswithfilter', 10, 2 );
function startswithfilter( $sql, $wp_query ) {
global $wpdb;
if ( $startswith = $wp_query->get( 'startswith' ) ) {
$sql .= $wpdb->prepare( " AND $wpdb->posts.post_title LIKE %s ", $wpdb->esc_like( $startswith ) . "%" );
}
return $sql;
}
Ergänzung: Und am Ende nach der Ausgabe nicht [FONT=Courier New]wp_reset_postdata()[/FONT] vergessen.
Ergänzung: Vertippte Variable im Code behoben.
Die og. Hinweise sind vorgesehene Ansätze von WordPress für Deine Problembeschreibung mit der vorhandenen WordPress API.
Zum geposteten Code: Dein Aufruf von [FONT=Courier New]the_title()[/FONT] bezieht sich nicht auf Deine [FONT=Courier New]$page[/FONT], da Du keine sog. WordPress Loop über Deine Ergebnisse erstellt hast. Verwende mit Deinem Ansatz z.B. [FONT=Courier New]$page->post_title[/FONT] wie weiter unten in Deinem Code oder eher [FONT=Courier New]get_the_title( $page )[/FONT].
Wirklich empfehlen kann man diesen Ansatz aber nicht. Die Ergebnismenge sollte vor bzw. durch der Suchabfrage eingeschränkt werden und nicht erst danach.
Hier ein paar Infos:
http://www.marbutec.de
Theme: Hello
...
Dieser hier im Forum angegebene Link ist http, nicht https. Das verursacht einen unnötigen Redirect. Gemeint sind generell Links zum Website, die Du irgendwo postest. Die Datenbank ist in Ordnung.
Dein hier angegebener Link ist mit http, daher erfolgt erstmal ein Redirect zu https durch WordPress, WordPress wird hier derzeit also doppelt geladen. Gib Deine Links überall direkt mit https an, dann geht das schon etwas schneller.
Da Du Elementor nutzt, und damit vermutlich den Gutenberg Editor nicht, kannst Du das Laden seiner CSS Datei entfernen, Hinweise dazu z.B. hier im wordpress.org Forum.
Dazu werden relativ viele Schriftart Dateien geladen, evtl. könnte man da was bereinigen (nicht zu viele verschiedene Stile o.ä.). Auch statt der beiden Icon Schriftarten (eicons (wohl nur für das Icon des mobilen Menüs) & fontawesome) könnte man ggf. nur eine nutzen.
Auch das Emoji Script ist eigentlich überflüssig, siehe Disable Emojis (viele Caching/Minify Plugins haben auch die Möglichkeit, das zu entfernen).
Generelle Hinweise zu Geschwindigkeit und verschiedene Minify/Caching Ansätze hier im Elementor Blog.
Evtl. eine eigene Taxonomy dafür anlegen, dann erstellt WordPress automatisch Übersichtsseiten usw.
Ansonsten den [FONT=Courier New]posts_where[/FONT] Filter ansehen, bei stackexchange uä. gibt es dafür einige Beispiele für Dein Vorhaben.
Ok, dann steckt das Problem noch woanders. Von aussen schwer ermittelbar.
Als Workaround dann den CustomSSL Block am Beginn der [FONT=Courier New].htaccess[/FONT] verwenden.
Versuche es wie beschrieben zuerst ohne den angepassten bzw. verschobenen Redirect Block nur mit einmal Speichern der Permalinks. WordPress sollte die Redirects alleine können.
Ergänzung: Es geht ja eigentlich auch darum, die Ursache des ggf. "tieferliegenden & globalen Problems" zu ermitteln. Der Redirect Block ganz oben wird funktionieren, versteckt das Problem aber nur.
Jeweils den Browser Cache leeren nach allen Änderungen. Der Browser merkt sich sonst die vorherigen Redirects.