Beiträge von b3317133

Nunja, irgendwas überschreibt offenbar Deine [FONT=Courier New]/wp-includes/user.php[/FONT] mit dem Inhalt von [FONT=Courier New]wp-includes/cache.php[/FONT] oder setzt deren Code davor, also läuft irgendwas gewaltig schief. Könnte z.B. ein Hack sein, der nicht richtig funktioniert.

Sind auch andere Dateien in [FONT=Courier New]/wp-includes/[/FONT] oder [FONT=Courier New]/wp-admin/[/FONT] oder im Hauptordner [FONT=Courier New]/[/FONT] von Änderungen betroffen? Vergleiche die ganze Installation mit dem sauberen Archiv, dafür gibt es diverse Programme, Suchbegriff "Diff".

Weiterhin, werden irgendwelche "PHP Booster" o.ä. Mechanismen auf dem Server benutzt? Wurde kürzlich die PHP-Version verändert?

Und gibt es Einträge im PHP error-log des Servers?

In der Datei [FONT=Courier New]wp-includes/user.php[/FONT] von WordPress 5.1.1 steht normalerweise keine Deklaration von [FONT=Courier New]wp_cache_add()[/FONT].

Poste mal die ersten ca. 50 Zeilen Deiner Datei [FONT=Courier New]wp-includes/user.php[/FONT] mit Hilfe des kleinen "+" Symbols im Forum-Editor als "Code".

Um der Ursache weiter auf die Spur zu kommen, lade ein frisches .zip Archiv von WordPress 5.1.1 hier herunter und vergleiche dann alle Dateien aus dem .zip Archiv mit Deiner Installation.

Würde auf das CDN verzichten (ist mMn. bei Deiner Seite komplett unnötig, wäre nur bei hohem internationalen Traffic interessant) und entweder

a) die Domain mit und ohne www auf den gleichen Ordner zeigen lassen, ggf. mit ergänzendem .htaccess von SirEctor für direkte Grafik-Links

oder

b) die Domain mit www bei Ionos per "externem Redirect" auf ohne www weiterleiten, dann ohne .htaccess von SirEctor

Und zwischen allen Versuchen immer wieder das Browser-Cache leeren nicht vergessen, die Browser merken sich auch Redirects...

Wenn die Seite sauber "ohne www" eingerichtet wurde, sollte kein Ersetzen nötig sein.

Man muss dann natürlich auch alle Plugins entspr. korrekt einrichten, das war vorhin nicht der Fall. Ob es am Wartungsplugin oder an den Cache- bzw. CDN-Plugins lag, wäre dann noch zu klären wenn das Wartungsplugin weg ist.

Noch am Rande: Bei der RewriteRule von @SirEctor sollte man statt auf http:// auf https:// weiterleiten, dann spart man WordPress und dem Browser einen extra Redirect.

Mit Wartungsmodus aktiv machen sowohl Cache- als auch CDN-Plugins keinen Sinn, es führt (wie hier) eher zu Problemen.

Für "ohne www" muss WordPress erst auf "ohne www" eingerichtet und alle Pfade umgestellt werden (z.B. via "Better Search Replace").

Dann kann man für "nicht WordPress Links" wie z.B. Direktlinks zu Grafiken oder [FONT=Courier New]/readme.html[/FONT] o.ä. noch eine entspr. Weiterleitung in [FONT=Courier New].htaccess[/FONT] ergänzen, wie z.B. siehe @SirEctor. Seiten und Links, die von WordPress selbst generiert werden, werden nach der o.g. Einrichtung auch ohne extra [FONT=Courier New].htaccess[/FONT] ohnehin autom. auf "ohne WWW" weiterleiten, ausser eines Deiner Cache- bzw. CDN-Plugins funkt dazwischen.

Wenn man ein Problem sucht, eliminiert man erstmal alle unnötigen Dinge, die das Problem (mit)verursachen können. Der Punkt 3. hätte dauerhaft ohnehin nichts dort verloren.

1. Deaktiviere das WP Rocket Cache-Plugin.
2. Weiterhin alle anderen ggf. vorhandenen CDN- oder Optimierungsplugins wie Cloudflare usw.
3. Falls vorhanden entferne [FONT=Courier New]define( 'RELOCATE', true );[/FONT] aus der Datei [FONT=Courier New]wp-config.php[/FONT]

Ob Wartungsmodus oder nicht ist für das Nachvollziehen des genannten Problem eher nicht relevant.

Die angegebenen Redirects könnte man auch mit der Startseite oder [FONT=Courier New]/readme.html[/FONT] o.ä. testen...

Relevant ist dieser Code-Block in der Datei [FONT=Courier New]wp-content/themes/spicepress/style.css[/FONT]

@media (max-width: 480px) {
.wp-custom-header img {
    height: 250px;
}
}

Er setzt die Höhe bei kleinen Screens fix auf 250 Pixel.

Du kannst das z.B. über das Menü Design > Customizer > Zusätzliches CSS überschreiben, dort eintragen:

@media (max-width: 480px) {
.wp-custom-header img {
    height: auto;
}
}

Technische Hintergründe dazu unter dem Stichwort CSS Media Queries (google).

1. Leere Deinen Browser-Cache.
2. Leere alle ggf. vorhandenen Cache-Plugin Caches.
   
3. Link zur Seite?

Werden irgendwelche Plugins eingesetzt, die mit Spam zu tun haben? Oder sonstige Plugins, die WordPress Kommentare "erweitern", "ergänzen" o.ä.?

Kannst Du den Effekt selbst nachvollziehen (z.B. mit dem exakten Text, den die Autorin eingeben wollte)?

Sind Einträge unter Einstellungen > Diskussion > Kommentar-Blacklist vorhanden?

Was genau erscheint wirklich? In welcher Form? Gibt es einen Screenshot? Statt "spam delated" dürfte es eher sowas wie "spam detected", "spam deleted" o.ä. gewesen sein, oder?

Kann man auch so machen, es gibt verschiedene Lösungen.

Die o.g. Lösung via php Script erlaubt eine dynamische Auswertung, z.B. via [FONT=Courier New]attachment_url_to_postid(..)[/FONT] erstmal die [FONT=Courier New].jpg[/FONT] oder [FONT=Courier New].pdf[/FONT] Datei in der Mediathek suchen, dann schauen, ob sie mit einem Beitrag o.ä. per [FONT=Courier New]$attachment->post_parent[/FONT] verknüpft ist, schauen ob dieser Beitrag auf Status "Privat" steht, und dann entspr. reagieren, dabei auch denkbar eine Abfrage welche(r) Benutzer/Rolle genau angemeldet ist o.ä., oder ob via ACF o.ä. ein entspr. eigenes "geschützt" Feld in der Mediathek gesetzt wurde oder ganz andere Faktoren wie Uhrzeit, Datum usw., kommt eben ganz darauf an, was man genau braucht.

Man kann ein kleines .php Script erstellen, das WordPress startet und schaut, ob jemand eingeloggt ist, und per [FONT=Courier New].htaccess[/FONT] alle Aufrufe für [FONT=Courier New].jpg[/FONT] und [FONT=Courier New].pdf[/FONT] o.ä. auf dieses php Script leiten, darin bei Bedarf abfragen / auswerten, ob die Dateien geschützt sein sollen, und dann je nachdem die entspr. Datei oder aber eine Weiterleitung zur Hauptseite an den Browser senden.

Zitat von admin-RV-WPDE

In diesem Forum hier wird viel geredet, jedoch wenig geholfen. Was ich brauche ist ein CSS-code der mein Problem löst.

Das Forum ist für Hilfe zur Selbsthilfe für selbst installiertes WordPress gedacht.

Es wurde bereits die exakte Fehlerstelle und diverse Links zum Nachlesen dazu genannt.

Das Problem hat mit WordPress rein gar nichts zu tun sondern betrifft elementarste Grundlagen zu HTML und CSS.

Für Komplettlösungen ohne Mitdenken empfiehlt sich das Beauftragen eines kompetenten Dienstleisters in Deiner Region oder z.B. über die Jobbörse hier im Forum.

Kann unterschiedlichste Ursachen haben:

1. Prüfe die Angaben [FONT=Courier New]DB_xxx[/FONT] zur zugehörigen Datenbank in der Datei [FONT=Courier New]WordPress_03/wp-config.php[/FONT]
   
2. Befinden sich überhaupt Daten in dieser Datenbank?
3. Wurden bei der ersten "Backup-Wiederherstellung" Dateien wiederhergestellt oder die Datenbank oder beides? Wie genau?
   
4. Was genau wurde bei "Strato Backup-Control" wiederhergestellt? Derzeit sieht es so aus, als würden bei "funktionierenden" Seiten (z.B. bei Suche via Google) nur vorhandene alte Cache-Dateien angezeigt.

Für Mitleser, das verlinkte Protokoll hat die Photoshop-Endung [FONT=Courier New].psd[/FONT] ist aber eine normale Textdatei.

@Marcus[IS] Das Github Plugin nutzt den Shortcode [FONT=Courier New][my_gallery][/FONT].

Das genutztes Plugin könnte dieses hier sein, siehe auch [FONT=Courier New]/wp-content/plugins/mygallery/changelog.txt[/FONT] auf der o.g. Seite.

Ergänzend, bei 1.200 bestehenden Galerien würde es sich ggf. empfehlen, das Plugin an neuere WordPress Versionen anzupassen oder aber auch das Classic Editor Plugin zusätzlich zu verwenden. Dafür wäre es gut zu wissen, was genau "das Plugin nicht mehr funktioniert" bedeutet.

@Marcus[IS] Beim Github-Plugin wird ein anderer Shortcode verwendet, als im Beispiel von @Robbi

Zitat von Robbi

... über einen Shortcode in den Text eingefügt werden: [mygal=beispielgalerie].

add_shortcode( 'my_gallery', array( 'MyGallery', 'shortcode' ) );

Wenn der Beitrag im Backend von WordPress erscheint, aber nicht in der Datenbank, und wenn Du andere Beiträge in der Datenbank siehst, aber nicht im Backend von WordPress, dann schaust Du wie oben bereits vermutet in die falsche Datenbank.

Nach welcher Spalte ist der Screenshot sortiert?

Das ist nicht zwangsläufig so, daher stellt sich diese Frage. Nach welcher Spalte ist der Screenshot sortiert? Sortiere den mal nach ID aufsteigend und schau auf die letzte Seite, findest Du dort Deinen o.g. "neu erstellten Beitrag?"

Wenn Du sichergehen willst, lösche alle Tabellen der Datenbank und spiele die .sql Datei aus dem Backup neu ein und lösche alle WordPress-Dateien auf dem Server und spiele die Dateien aus dem Backup neu ein, mit entspr. Anpassung der [FONT=Courier New]wp-config.php[/FONT] bzgl. Datenbank nach dem Einspielen.

Wurden die Tabellen dabei vorher gelöscht?

Enthält das Backup Zeilen wie DROP TABLE IF EXISTS `1_comments`; CREATE TABLE `1_comments` ... usw.?