Beiträge von b3317133

Deaktiviere das Cache-Plugin oder leere dessen Cache. Weiterhin leere danach Deinen Browser-Cache.

Danke für die Rückmeldung, das genannte Plugin scheint nach etwas Lektüre im Plugin Support Forum durch seine grundsätzliche Herangehensweise noch diverse andere Nebeneffekte zu haben, würde es nicht mehr verwenden.

Die [FONT=Courier New].jpg_backup[/FONT] Dateien werden möglicherweise durch Dein Gallery Plugin erzeugt, siehe auch hier bzw. hier im Support Forum des Plugins.

Und lädst Du dieim Screenshot sichtbaren Dateien mit [FONT=Courier New]_Enhancer[/FONT] im Namen schon so benannt hoch oder läuft ggf. noch ein anderes "Optimierungs" Plugin für Bilder?

In meinem Vergleich zur Google Cache Version ist kein Produkt auf Entwurf sondern nur diese Reihenfolge ist vertauscht, alles andere auf der Startseite ist identisch.

Cache: Nordhessenpower - Pina Colada - Happy Day - Bahama Mama
Live: Pina Colada - Nordhessenpower - Bahama Mama - Happy Day

Im Menü fehlen im Vergleich zum Cache alle Einträge mit dem Post-Type "page", evtl. waren alle Seiten warum auch immer kurzzeitig auf Entwurf oder Privat o.ä. und das Menü wurde parallel gespeichert o.ä.

Da es keine Revisionen im Menü gibt, wirst Du das schwer rausfinden können, vor allem wenn Dein Backup (vom Provider) schon eine Woche alt ist, die Veränderung vor vier Tagen aber noch gar nicht eingetreten war.

Ich vermute ein PEBCAK Problem, ein Update als Ursache würde ich ausschliessen.

Ein Vergleich der Google Cache Version vom 11.05. mit der aktuellen live Seite zeigt (ausser den besagten Menüeinträgen und einem vertauschten Produkt) auf der Startseite keine Veränderung, sämtlicher HTML-Code inkl. Menü-ID und alle Versionsnummern sind gleich geblieben.

Wenn der Cookie-Banner nicht angezeigt wird, hast Du möglicherweise in Deinem Browser bereits ein entspr. Zustimmungscookie gesetzt, es kann aber auch andere Gründe haben.

Bzgl. der "unsicher" Meldung wurde der Website vermutlich ursprünglich mit http installiert und dann nicht korrekt auf https umgezogen, dazu finden sich im Forum eine Vielzahl von Beiträgen, Stichwort z.B. Better Search Replace usw., es kann aber auch andere Gründe haben.

Ohne Link zur Seite wird Dir kaum jemand sinnvoll weiterhelfen können... :oops:

Zitat von Wassermann22

Einfach den .htaccess .. [codeblock] .. zu löschen reicht ja nicht.

Eigentlich schon.

Zitat von Wassermann22

Doch das SSL-Zertifikat und Cookie-PlugIn funktionieren nicht.

Was funktioniert damit nicht? Link zur Seite? Beide Themen haben nichts mit einem [FONT=Courier New].htaccess[/FONT] Schutz zu tun.

In den Überlegungen fehlt noch das Stichwort "Retina" Auflösung, da werden ganz kurz gesagt vom entspr. Gerät bevorzugt doppelt so grosse Auflösungen wie als Pixel angegeben geladen und verwendet.

Die verwendeten Grössen und damit auch die Angaben in [FONT=Courier New]srcset[/FONT] bzw. [FONT=Courier New]sizes[/FONT] werden in WordPress je nach Einsatzsstelle des Bildes z.B. als Header oder Beitragsbild oder im Content oder im Sidebar oder in einem Slider oder in einer Archivansicht bzw. in einem Suchergebnis oder als hinterlegtes Bild für strukturierte Daten für soziale Medien oder Suchmaschinen komplett unterschiedliche sein.

Weitere Details zu den in Deinem Fall wo und wie nötigen Auflösungen am besten beim DIVI-Support anfragen.

Das Menü scheint richtig eingerichtet zu sein.

Menüpunkte löscht man unter Design > Menüs im Bereich Menüstruktur, zu sehen als rechte Spalte im ersten Screenshot. Menüpunkt mit kleinem Pfeil aufklappen, Löschen. Siehe dazu auch Suchmaschinen z.B. "WordPress Menü bearbeiten" oder weiterführende Hinweise von @Kurt Singer.

Dann ist die Seite aus dem Menü "weg" aber nicht sonst aus WordPress "weg".

Welche Seite hast Du gelöscht, wie hiess die? Wo war die vorher im Menü zu sehen? Link zur Homepage?

Eine Einstellung Deines Themes mit Hilfe einer verlinkten Theme Dokumentation aufzufinden sollte doch ein vergleichsweise einfaches Ding sein. Woran scheitert es genau?

Ansonsten wäre es ggf. eine Überlegung wert, generell für Änderngen an Deinem Website jemanden zu suchen, der/die sowas kann. :oops:

Es fehlen vermutlich die Anführungszeichen bei den Parametern.

[auto-iframe link="https://url.xy" tag="bla" width="100%" height="100%" autosize="no"]

Ansonsten kann man nur raten, es fehlen alle nötigen Angaben, siehe auch Forenregeln.

Klicke den o.g. Link zur Dokumentation Deines Themes an...

Alternativ wende Dich an die Person, die den Website eingerichtet hat, die kann Dir diese Einstellung sicherlich zeigen.

Natürlich kann man irgendeinen Code auf das Problem werfen, der Grund für den aktuellen Effekt steht bereits oben in #13, aber der Grund wird dynamisch vom Theme erzeugt, daher wäre der richtige Ansatz, in den Theme Einstellungen die passende Einstellung zu finden.

Was genau ist denn bei "Form Text Typography" eingestellt? Screenshot?

Du könntest es mal hier lt. Theme Dokumentation versuchen.

Weiterhin handelt es sich offensichtlich um ein Kauf-Theme, da hat man entspr. Support überlicherweise mitgekauft, was ergab eine Anfrage dort?

Das ist vermutlich in den Einstellungen Deines Theme so eingestellt, die entspr. CSS-Regel [FONT=Courier New]text-transform: capitalize;[/FONT] steht in einer dynamisch erzeugten CSS-Datei.

Screenshot / Foto des Bereichs Design -> Menüs?

Evtl. wird kein manuell erstelltes Menü verwendet und neue Seiten autm. hinzufügen o.ä. ist aktiv, das könnte man auf einem Screenshot ggf. erkennen.

Und wo genau hast Du diese Seite gelöscht, die jetzt "weg" ist? Screenshot / Foto auch davon?

Hast Du denn den in #5 genannten Link zur Theme-Dokumentation mal angeklickt und dort den Punkt zu "Import .. Customizer Settings"?

Dort sieht man, dass es eine Import/Export Funktion von OceanWP geben sollte...

Anhand der bisheringe Angaben dürfte hilfreich sein:

• PHP Dokumentation
• API Dokumentation des genutzen Newslettersystems

Alternativ:

• Allgemeine Dokumentation des genutzen Newslettersystems
  
• Support des genutzen Newslettersystems

XML-RPC geht an [FONT=Courier New]wp-login.php[/FONT] vorbei. Zugriffe auf [FONT=Courier New]wp-login.php[/FONT] werden auch für normale passwortgeschütze Seiten in WordPress benötigt. Zugriffe auf [FONT=Courier New]/wp-admin/..[/FONT] werden u.a. für AJAX-Aufrufe im Frontend von diversen Plugins und auch Themes benötigt. Eine wie auch immer geartete [FONT=Courier New].htaccess[/FONT] Sperre hat meistens unerwünschte Folgen. Daher sicheres Passwort, fertig.

Poste einen Beitrag o.ä. mit dem zweiten Admin.

Jedes System das fertige Seiten mit rein statischem HTML/JS/CSS generiert ist sicherer.

Voraussetzung ist natürlich, dass die FTP-, bzw. besser SFTP-Zugangsdaten nicht abhanden kommen...