Möglicherweise eine Folge der geänderten[size=14] [/SIZE]MIME validation for uploaded files mit den jüngsten WordPress Updates 5.0.1, 4.9.9, usw.
In den aktuellen Bugreports sind einige ähnliche Meldungen zum Thema "MIME" dabei, z.B. #45615
Beiträge von b3317133
-
-
..aber ich möchte weg von der Datei index.php und dafür wpindex.php daraus machen (auf Dateiebene)
Das ist ohne sehr umfangreichen Änderungen im gesamten WordPress System nicht möglich.
-
Versuche es mal über [FONT=Courier New]/wp-login.php[/FONT]
Evtl. ist euer SECSIGN Plugin nicht mit WordPress 5.0 oder nicht mit dem Updateprozess allgemein kompatibel.
-
Ändert sich was, wenn man wie oben beschrieben temporär die aktuelle PHP Version 7.2.10 auf 7.1.x o.ä. zurückzustellt? Ist die PHP Boost Funktion aktiv? Ändert sich was, wenn man die deaktiviert? Mehr dazu z.B. hier.
-
Da man sich lt. Eingangsposting mit Firefox anmelden kann, liegt das Problem wahrscheinlich eher woanders.
Du kannst die beiden Verzeichnisse ersetzen, wenn Du die Backups z.B. aus einem originalen 4.8.8 Archiv nimmst. Bei anderen Versionen bzw. dem schrittweisen Einspielen ganzer Updates sind weitere Dinge zu beachten, mehr dazu hier.
Ergänzung: Die deutsche Version des originalen 4.8.8 Archivs ist derzeit noch nicht online, daher ggf. noch etwas warten, oder in der Datei [FONT=Courier New]wp-includes/version.php[/FONT] am Ende eine Zeile [FONT=Courier New]$wp_local_package = 'de_DE';[/FONT] ergänzen, falls beim Kunden die deutsche Version verwendet wird.
-
[plain]Schau mal hier -> https://www.facebook.com/1und1/posts/li…52285144338679/[/plain]
Interessant, gibt es evtl. einen aktuelleren Link als vom 2. März 2014?
-
Jede Seite hat normalerweise eine Klasse mit dem ID im body Tag, versuche es bei einer Seite mit ID 123 z.B. damit:
Code.page-id-123 { background-color: #f0f; }Oft sind einzelne Elemente der Seite nicht "durchsichtig", so dass man je nach Theme ggf. noch weiteres CSS benötigt.
-
Welche WordPress Version? Welcher Browser? Evtl. was ähnliches wie hier?
Ergänzung: Version offenbar 5.0.1, also evtl. was anderes als das verlinkte Problem. Aufruf der Loginseite mit den Eingabefeldern geht hier mit diversen Browsern.
Versuche mal die aktuelle PHP Version 7.2.10 auf 7.1.x o.ä. zurückzustellen, ändert sich dann was?
Und hast Du schon den Strato Support kontaktiert?
-
Ok, dann ist der Kunde offenbar noch im WordPress 4.8 Zweig, da gab es heute in derTat ein 4.8.8 Update. Es würde sich ggf. generell ein schrittweises Update auf die aktuelle 4.9.x empfehlen (nicht 5.x).
Evtl. kennt jemand anders ein IE-Problem mit der alten 4.8.x Version.
Nichtöffentliche Probleme bearbeite ich nur über die Jobbörse hier im Forum.
-
-
Für Fehler / Probleme mit Gutenberg am besten den entspr. Links hier folgen.
Oft ist vieles schon mehrfach gemeldet und wartet auf Bearbeitung, manches auch schon viele Monate, aber einmal mehr schadet sicher nicht.
-
Wahrscheinlich meinst Du das Update auf 4.9.9. Passiert das auch auf anderen PCs? Link zur Seite?
-
Kann es sein, dass der SR (5.0.4.1) die Ursache des Problems ist, obwohl der mit PHP 7.0 und WP 4.9.8 noch funktionierte??
Ja, aktuelle Version wäre wohl 5.4.8.1, frage dort, wo Du Slider Revolution gekauft/mitgeliefert bekommen hast, nach einem Update.
Kann es überhaupt sein, dass ein Plugin wie SR so ein Problem beim Login-Script macht?
Ja, auch beim Login werden die Plugins im Hintergrund aufgerufen und es ergeben sich im Fehlerfall dadurch auch diverse Effekte.
-
Würde versuchen, das Problem genauer einzugrenzen, z.B. über das Weglassen von z.B. wp-content oder evtl. vorhandenen Cache- oder Backup-Ordnern über die entspr. Datei-/Ordner Filterfunktion.
Ansonsten, hier auch noch nie Probleme mit Duplicator über die letzen Jahre bei zig Einsätzen. Einzige Ausnahme: Ein Website mit ca. 6 GB Daten im uploads Ordner...
-
Bin der Sache interessehalber noch etwas auf den Grund gegangen.
Die Startseite voller wirrer Zeichen ist ein UTF-8 BOM (3 Bytes) direkt gefolgt von einer validen gz Datei, die entpackt den HTML-Code der Startseite enthält.
Das heisst, der Server oder ein Cache-Plugin schickt die Daten gz-komprimiert an den Browser, der Browser erkennt aber durch das überzählige UTF-8 BOM die Komprimierung nicht und zeigt daher die gepackten Daten direkt an = wirre Zeichen.
Ursache allen Übels könnte also ggf. alleine nur das bereits zu Beginn genannte UTF-8 BOM in den wp-config.php sein...
-
Erstmal[FONT=Courier New] get_the_ID[/FONT] ändern in [FONT=Courier New]get_the_ID()[/FONT] und dann evtl. so, ungetestet:[FONT=Courier New]
PHPif ( !empty( $copyright = get_post_meta( get_the_ID(), 'copyright', true ) ) ) { $copyright = explode( '_', $copyright ); echo 'Artikelbild(er): © ' . $copyright[0] . ' / ' . $copyright[1]; }
[/FONT] -
@SirEctor Leicht OT, die "Managed WordPress" oder "WordPress Hosting" o.ä. Produkte grosser Webhoster beinhalten auch automatische Sprünge über "major" Updates hinweg. o_O Zudem dürfte der überzählige UTF-8 BOM mit ziemlich hoher Sicherheit nicht durch ein WordPress Update entstanden sein.
-
Tatsache, die ist weg. Gelöscht habe ich die allerdings nicht. Wie kann das passieren?
Das kann gar nicht passieren. Wenn die Datei einfach so "weg ist", dann ist der komplette Server als kompromitiert / gehackt zu betrachten.
Kann ich einfach die benötigten Daten in eine wp-config-sample.php eintragen..
Es sollten auch neue Keys erzeugt und anstelle der Platzhalter eingetragen werden.
-
Das Login- bzw. Cookie-Problem kommt dadurch, dass die Datei wp-config.php offenbar mit einem unpassenden Editor bearbeitet wurde und derzeit ein sog. UTF-8 BOM ausgibt anstelle von "gar nichts". Diese Ausgabe stört den restlichen Login-Prozess.
Falls also jemand an der wp-config.php gearbeitet hat, wäre hier der Ansprechpartner zu suchen, zumindest für das Login- bzw. Cookie-Problem.
-
Das macht Dein erstes Query.
Wahlweise erstellt WordPress diese Seite automatisch, wenn Post Type und Taxonomy öffentlich sind: [plain]deinseite.de/target/educatif/[/plain]
Ansonsten verstehe ich nach wie vor das Problem nicht.
