Danke, @la-geek , für diesen Tipp.
Nur: Der Problembehandlungsmodus kann, soweit mein Test in meinem „Sandkasten“ zeigt, nur mit Adminitstratorenrechten aktiviert werden. Das Problem tritt jedoch nur dann auf, wenn ich nicht als Administrator angemeldet bin. Und wenn ich mich als Admin anmelde, den Problembehandlungsmodus aktiviere und mich abmelde und wieder anmelde, wird der Modus mit der Abmeldung offenbar beendet.
Ein explizites Recht zur Aktivierung des Problembehandlungsmodus habe ich nicht gefunden.
Ich werde also dieses Standardverfahren nicht anwenden können.
Mir bleibt wohl nichts anderes als der mühevolle Weg des Als Admin anmelden – Plugin deaktivieren – als Redakteur anmelden und schauen, ob es geht. Doch ich denke nicht, dass das diese Mühe wert ist. So häufig komme ich wohl nicht in diese Situation und wenn, habe ich immer noch die Möglichkeit über die Admin-Anmeldung das Verhalten zu umgehen.
Vielleicht stoße ich ja irgendwann einmal durch Zufall auf die Ursache.
Mir bleibt wohl nichts anderes als der mühevolle Weg des Als Admin anmelden – Plugin deaktivieren – als Redakteur anmelden und schauen, ob es geht.
2 unterschiedliche Browser nehmen 🙂
Oder ein „Neues privates Browser-Fenster“. 🙂
Ahhh, zwei Browser. Geschickt! 😉 Ich hab’s mit einem privaten Firefox probiert, doch es funktioniert nicht, die Plugins sind dann als Redakteur weiterhin aktiviert. 🙁
Ich habe mir nun eine Übersicht über die verwendeten Plugins erstellt. Zwei habe ich gefunden, die in der nicht funktionierenden, neuen Installation aktiviert sind, in der funktionierenden, alten, jedoch nicht. Alle anderen Plugins sind identisch, können also wohl nicht die Ursache sein.
Doch die Deaktivierung dieser zwei Kandidaten bringt keine Änderung.
Auch die Einstellung der neuen Inst auf PHP 7.4., unter dem die alte, funktionierende, Installation läuft, bringt nichts. Genauso wie auch die Umstellung der alten auf 8.0 nichts bringt: Das Verhalten ist dort nicht reproduzierbar.
Die Änderung in der alten Inst auf utf8mb4 in der wp-config wie in der neuen bringt auch nichts: es funktioniert dann auch noch.
Sonst habe ich mit dem Plugin „System-Info“ keine Unterschiede feststellen können. Damit bin ich mit meinem Latein am Ende.
Bug-Meldung? Wenn ja: Wo?
Der Problembehandlungsmodus des Plugins Health Check bezieht sich immer nur auf den gerade angemeldeten Benutzer. Wenn du damit temporär Plugins deaktivierst, bekommen andere Benutzer (bzw. du selbst mit einer Anmeldung unter einem anderen Account in einem privaten Fenster) davon nichts mit. Du kannst aber ganz normal Plugins vorübergehend deaktivieren und gleich im anderen Browser-Tab die Auswirkung testen. Das hatte Angelika wohl gemeint.
Danke, @pixolin , so verstanden ist das freilich hilfreich…
Spät aber doch mische ich mich hier ein:
Wenn so etwas nicht richtig funktioniert, kann es an den Rechten der jeweiligen Rolle liegen.
Ich weiß zwar nicht was bei dir der Unterschied zwischen
Bin ich nicht als Admin eingeloggt
und
Speichere ich den gleichen Post als (Super-)Admin
ist?
Aber die beiden Rollen unterscheiden sich wahrscheinlich bez. des Rechts „ungefiltertes HTML“ verwenden zu dürfen. Ein Benutzer, der das nicht verwenden darf, kriegt bei manchen Konstellationen von Kommentaren diese Probleme. (Nicht immer, aber oft wird dann eben „lt;!–“ uä. draus)
Das mit den Rechten pro Rolle kann man mittels des Plugins „User Role Editor“ einfach prüfen uo. ggf. zuweisen.
@pezi
Super-Admin ist ein Administrator in einem WordPress-Netzwerk (Multisite), der das Recht hat, neue Websites anzulegen, vorhandene Websites zu löschen, Themes und Plugins zu installieren/(netzwerkweit) aktivieren/löschen, übergeordnet Benutzer anzulegen und ihnen (für einzelne Websites) eine (Super-)Administratoren-Rolle zuzuweisen. Er/sie hat darüber hinaus in allen Websites des Netzwerks die üblichen Administratoren-Rollen, etwa wenn es um die Verwaltung von Beiträgen und Seiten geht.
Die Administratoren/-innen in einem WordPress-Netzwerk dürfen nur Änderung innerhalb der Website vornehmen, für die sie die Rolle zugewiesen bekommen haben.
Alle Administratoren (also auch Super-Administratoren) dürfen ungefiltertes HTML verwenden.
Achso! Danke.
Alle Administratoren (also auch Super-Administratoren) dürfen ungefiltertes HTML verwenden.
Klar soweit.
Nur der TO hat (oder hatte) eben genau die Probleme, welche auftauchen, wenn einem Benutzer „ungefiltertes HTML“ nicht erlaubt ist.
Das passierte mir nämlich grade vorhin, als ich was kommentieren wollte und mit dem (nur um das Recht „ungefiltertes HTML“ kastrierten) Admin-Account eingeloggt war. (Jene Rolle habe ich deswegen (s. letzten Absatz) angelegt.)
Dann fiel mir, das hier mal jemand ähnliche Probleme beschrieb und da es noch offen war, wollte ich das loswerden.
In dem Fall bleibt mir nur ein Zitat:
Achso! Danke.
OK, @pezi , nach einigem Suchen habe ich das Recht „unfiltered_html“ im User Role Editor entdeckt.
Der User, bei dem HTML verändert wird, gehört zur Rolle „Redakteur (editor)“ und das Recht wird als gesetzt angezeigt. Allerdings erscheint es im User Role Manager unter der Rubrik „Deprecated“.
Nun habe ich beim Testen festgestellt, dass der Text <!-- hier ist ein Kommentar --> ohne Änderung übernommen wird, <!-- hier ist <br /> ein Kommentar --> dann allerdings als nicht-Admin zu <ampersand>lt;-- hier ist <br /> ein Kommentar --<ampersand>gt; verändert wird.
Als (Super-)Admin bleibt der Text so, wie er ist.
Ich sehe gerade, das mit dem <br /> innerhalb eines Kommentars habe ich bereits berichtet… sorry für die Dopplung…
Bei mir steht das unter Kern > Allgemeines
und nur der Admin (habe keine Multisite, keinen superadmin daher ist der „normale“ Administrator der mit allen Rechten) darf „ungefiltertes HTML“ verwenden.
Ab Redakteur runter hat normalerweise keiner die Option aktiv.
Daher? schlagen HTML Kommentare bei den Rollen meist fehl.
Meistens, weil ja, so einfache Kommentare funktionieren noch – aber irgendwelche Codes innerhalb und schon schlägts fehl …
