Beiträge von b3317133

@Henk1060 Wahrscheinlich das Rollback von Divi. Wie/warum es trotz angeblichem Theme-Wechsel auch nicht ging bleibt dabei ein Mysterium.

Zitat von Inke

Danke für deine Antwort. Die Artikel mit den großen Bildern habe ich von einer anderen Webseite übernommen - aber da sind die Bilder auch klein.

Bei Dir sind sie aber gross, warum? Wie hast Du diese Artikel denn übernommen?

Poste doch mal einen Link zu einem neuen Beitrag mit entspr. wie oben beschrieben formatierten Bild.

Für Mitleser: Wenn man nach einer Zeile Code für eine Ausnahme fragt, auf Rückfrage nach der genauen Realisierung den restlichen Code aber für sich behält, muss man in der Regel eben selbst weitersuchen...

Kannst Du die Links evtl. alternativ in die Beschreibung der Wegpunkte einfügen? Dort wo jetzt jeweils der Text unter dem Bild steht?

Ansonsten wäre es durch "keine Ahnung von der Programmierung" evtl. eher ein Fall für die Jobbörse im Forum.

Die Passwortabfrage auf der Coaching Seite nutzt u.a. den Link [FONT=Courier New]/wp-login.php?action=postpass[/FONT], das hängt also bei Dir direkt mit dem .htaccess Schutz für den Login zusammen.

Wie genau ist der .htaccess Schutz realisiert?

Zitat von Friedeburger

.. Wechsel auf ein anderes Theme hat auch nicht geholfen. ...

Seltsam, lt. aktueller Meldungen im Events Manager Plugin Support Forum liegt es an einer bestimmten neuen Divi-Version 3.20.1 und funktioniert mit einer älteren Version von Divi z.B. 3.19.18 oder 3.19.5 wieder.

Warum sind die Bilder weiter unten auf der Seite (ab 16. Oktober) ein anderes Format? Gab es da ein Theme-Update o.ä.?

Lade mal zu einem neuen Beitrag ein neues Bild mit dem Format z.B. 1024 x 683 hoch, so wie am 16. Oktober. Was passiert dann?

Die wahrscheinlichste Erklärung ist blindes Kopieren von Dingen, die man nur ansatzweise oder auch gar nicht versteht, ohne das trotz vielfacher daraus resultierender Probleme grundsätzlicher zu hinterfragen, siehe auch andere Threads. Kopiert wird bevorzugt von irgendwoher, nur möglichst nicht aus der offiziellen Dokumentation. Gelesen wird das Kopierte in der Regel eher gar nicht, sonst wären die falschen Anführungszeichen in diesem Fall sofort aufgefallen. Schuld an allem sind dann erstmal die Leute, die äusserst zeitnah und kostenlos versuchen, durch diverse Fragen wenigstens ansatzweise Ordnung in diesen Wahnsinn zu bringen, wobei die Fragen und Hinweise meist teilweise oder auch ganz unbeachtet bzw. unbeantwortet bleiben. Gearbeitet wird dabei mit mehr als uralten WordPress 4.8.8 und PHP 5.3.29, was nebenbei auch völliger Wahnsinn ist, aber egal, denn wenn "was passiert", fragt man einfach wieder im Forum nach... :confused:

Interessant, dass einfaches Copy & Paste doch so grosse Probleme verursachen kann, man lernt nie aus...

@starthubdj Wenn Du jetzt noch ein paar Zeilen aus dem oben beschriebenen error-Log posten würdest, in denen wp-login.php vorkommt, dann würde das evtl. anderen Besuchern des Forums zumindest ansatzweise helfen, das eigentliche Problem zu sehen und daraus zu lernen...

Wurde auch der Bilder-Cache geleert (siehe z.B. hier in der Anleitung) bzw. neue Thumbnails erstellt (siehe z.B. hier in der Anleitung)?

Vermutlich fehlte z.B. das im Link beschriebene Aktivieren von WP_DEBUG_LOG ...

Für Mitleser: Die Beschreibung von 2. mit Ausgabe in den Browser statt in die Datei deutet darauf hin, dass die oben verlinkte Anleitung zum Erstellen des Logs nicht korrekt befolgt wurde...

Es könnte auch sein, dass der in WordPress eingebaute Validator einfach nicht mit diesen CSS-Variablen umgehen kann...

Deaktiviere mal das Plugin Jetpack, bzw. mindestens die Funktion "Site Accelerator / Photon", die (wie übrigens die meisten Funktionen von Jetpack) auch nicht DSGVO konform ist...

Die erste Frage bleibt unbeantwortet:

Was steht im error-Log beim Hosting?

In der geposteten .htaccess sind keine Unterschiede zu einer standard .htaccess von WordPress erkennbar. Was wurde dort wg. PHP-Version geändert?

Wie verhält es sich mit anderen PHP-Versionen? Es kann kurz dauern, bis die Umstellung aus dem Backend auf dem Website ankommt...

Der Plugins-Ordner soll natürlich während des Loginversuchs umbenannt sein und erst danach wieder zurückbenannt werden, nur falls das unklar sein sollte...

Das access_log ist nicht das Error-Logfile, versuche es nochmal mit der o.g. Anleitung.

Inwiefern hat das Umbenennen des Plugins-Ordners nicht funktioniert? Wie genau wurde das gemacht? Was waren die Auswirkungen?

Was wurde wegen einer PHP-Umstellung an der .htaccess bearbeitet? Das macht man bei Strato üblicherweise unter Datenbanken & Webspace -> PHP-Version einstellen. Poste mal die aktuelle .htaccess

Ergänzung: Derzeit läuft auf dem im access_log genannten Website PHP 7.2.15, versuche es doch auch mal mit älteren Versionen.

Welches Theme wird denn verwendet? Wurde überhaupt schonmal ausprobiert, einfach [FONT=Courier New]<!--nextpage-->[/FONT] in den Inhalt (Text-/Code-Ansicht) einer Seite einzufügen? Was passiert dann?

Den Ordner erreichst Du per FTP, weisst Du was das ist?

Wie genau versuchst Du denn, das Plugin zu löschen?

Was bedeutet "das Updaten schlägt fehl"? Was passiert wann & wie genau?

Ergänzend, wenn WordPress 5.x installiert ist, wird Gutenberg als Plugin nicht benötigt, das Plugin dient inzwischen nur noch zum Betatesting neuerer Funktionen, das geht aus der Pluginseite leider nicht wirklich hervor. Vor der Veröffentlichung von WordPress 5.x war das anders.

Der in der Fehlermeldung genannte Website läuft mit WordPress 4.9.9, das aktuelle Gutenberg Plugin ist wie bei der Installation angegeben "Inkompatibel mit deiner WordPress-Version", siehe auch readme.txt im Plugin-Ordner "Requires at least: 5.0.0"

Entferne per FTP den Ordner wp-content/plugins/gutenberg/

Wenn man unbedingt Gutenberg nutzen möchte, muss man die ganze Installation auf die 5.x Version von WordPress aktualisieren, um Gutenberg danach wieder abschalten zu können, braucht man dann zusätzlich das "Classic Editor" Plugin.

Bzw. vorher entspr. geprüfte Backups aller Dateien & Datenbank.