Hallo zusammen,
in der Konfiguration des tinyMCE gibt es die Möglichkeit beim Image-Plugin zu setzen, dass das Bild in ein figure-Element geschrieben wird under User bekommt die Möglichkeit eine Caption einzugeben.: https://www.tiny.cloud/docs/tinymce/l…/#image_caption
Wenn ich aber in einer textarea mit dem Attribut tinyparams="image_caption : true" setze, passiert nix. Hat jemand damit Erfahrung? muss etwas anderes übergeben werden? Oder geht das gar nicht?
Ludger
Hallo Christoph, ist ja schon ein bisschen älter der EIntrag, aber vielleicht hilft es ja sonst noch jemandem: ich bekomme die Auswahl im select im image-tinymce-image-plugin, wenn ich die css-Formate mit dem Tag vor der Klasse eingebe: Bsp: classes="img.bild-im-text-links, img.bild-im-text-rechts, p.einzug"
Die verfügbaren Klassen werden kontextabhängig angeboten.
Ludger
Danke Heiko,
das war der Trick.
Viele Grüße
Ludger
Für ein Update einer wE 9.1.2 muss ich eine Kopie auf einem anderen Server anlegen auf dem noch PHP 7.x läuft. Der OnlineInstaller bietet aber nur 9.1.6 als niedrigste Version. Kann ich da ein Backup aus der 9.1.2 einspielen?
Ich habe auch die 9.1.2 vom Downloadserver heruntergeladen, weiß aber nicht, wie ich die auf dem anderen Server einrichte, weil scheinbar keine Setup-Datei dabei ist. Kann mir da jemand einen Tipp geben, was man mit den heruntergeladenen Dadteien anfängt?
Vielen Dank
Ludger
Hallo zusammen,
wE 9.2.3, PHP 8.2, MariaDB 10.5.13 encoding UTF-8: Wenn der Inhalt eines Ordners im Backend angezeigt werden soll und Elemente der Seiten in diesem Ordner nicht latin1-Zeichen enthalten (z. B.: Arabisch, Griechisch, Japanisch), wirft wE den Fehler "failed to encode data". Die Liste der Seiten in dem Ordner bleibt leer.
Der Fehler wird nicht bei allen Ordnern geworfen, die solche Seiten enthalten. Was den Unterschied zwischen den Ordnern ausmacht, kann ich nicht sagen.
Der Source code arround ist:
webEdition/we/include/we_global.inc.php:
345: if($data){
346: trigger_error(implode("\n---------------------------------------------------\n", $data), $type);
347: }
348: }
349:
350: function weMemDebug(): void{Die Ordner sind Kopien von Ordnern mit englischer Sprache, die anschließend mit den Inhalten in nicht latin-1 befüllt worden sind.
Hat jemand schon mal so ein Problem gehabt und kann mir einen Tipp geben, woran das liegen kann, oder wo ich etwas an den Inhalten anpassen kann?
Viele Grüße
Ludger
Hallo Markus, danke für Deine Schilderung. Ich habe jetzt auch den Wechsel zu einem anderen Provider angestoßen.
Viele Grüße
Ludger
Hallo Sascha, danke für Deine Überlegungen.
Komischerweise werden die Prozesse in der DB auch nach der PHP-Umstellung immer noch angezeigt und scheinbar trotzdem nicht beendet. Teilweise sind das Prozesse mit einer ID die 200000 Zähler niedriger ist als die aktuelle ID-Nummer. Also schon recht alte Prozesse.
Was in webEdition könnte dafür sorgen, dass Verbindungen über Wochen hinweg offengehalten werden?
Beste Grüße
Ludger
Hallo Sascha, danke für Deine Hinweise. Es kann durchaus sein, dass ähnliche Muster in beiden Projekten verbaut sind. Ein Query-Probklem wie Du das beschreibst, kann ich aber erst mal nicht ausmachen.
Ich habe mehrere wE-Sites bei Hosteurope. Nur bei den zweien tritt das Problem bisher auf. Ich dachte bisher, das habe mit der Menge der Zugriffe zu tun. Die anderen Projekte haben wenig Last.
Die Prozesse scheinen nicht beendet zu werden. Erst, wenn der MYSQL-Server neu gestartet wird, ist die Prozessliste wieder leer und der Vorgang fängt von neuem an.
Seltsam finde ich auch, dass das Problem kurzzeitig behoben werden kann, indem ich die PHP-Version von 8.1 auf 8.2 umstelle oder anders herum. Was bedeutet das?
Auf einer parallel installierten DEV-Kopie gibt es auch schlafende Prozesse, aber nur wenige. Da gibt es aber auch keine Last.
Ich werde mir eine lokale Kopie der Site in ddev installieren und da mal testen.
Hast Du zu dem hier beschriebenen noch eine Idee?
Beste Grüße
Ludger
In zwei unabhängigen Projekten mit mittlerweile WE 9.2.2 und PHP 8.1 /8.2 bleiben bei Hosteurope in Shared Hosting Paketen hunderte schlafende Prozesse liegen, was irgendwann dazu führt, dass die DB nur noch sehr langsam reagiert und jede Menge Fehler 503 generiert werden. Das Problem hatte ich schon mal im alten Forum mit Version 9.1.3 beschrieben: https://forum.webedition.org/viewtopic.php?…teurope#p105881
Der Support von Hosteurope antwortet nur pauschal und ist nicht hilfreich.
Tritt das Problem vielleicht bei anderen auch auf? Für Hinweise bin ich dankbar.
Hallo Finn, soll ich das dann in die Bugbase eintragen?
Hallo Steff11, vermutlich tut das nix zur Sache, aber es gibt so was manchmal bei TYPO3 bei bestimmten Updatekonstellationen, dass das Sessioncookie im Browser den Loginvorgang stört. Meist hilft es die Cookies zu löschen oder einen andern Browser zu nehmen. Aber das hast Du vermutlich schon versucht.
Hallo Finn,
ich habe zwar noch nicht gefunden, welcher Feature-Request dafür die Grundlage ist, aber ich kann mir Vorstellen, was der Grund sein könnte.
Hier also ein Feature-Request
Zwischen wE 9.1.5 und 9.2.2 wurde das Tag we:formfield type=select so verändert, dass immer ein leeres Option-Element ausgegeben wird. Dieses Option ist zudem disabled.
Dadurch wird aber der Redaktion die Möglichkeit genommen, einen Wert an Index-Position 0 im Select auszugeben, was durchaus der Fall sein kann. Stattdesseb wird eine wird der User gezwungen eine Auswahl zu treffen.
M.E. wäre es sinnvoll, statt der Vorgabe eines leeren Elements der Redaktion oder den Templateantwicklern an die Hand zu geben, wie sie das Element belegen möchten. Dafür könnte die Möglichkeit ergänzt werden, Value und Option-Inhalt getrennt anzugeben.
Die Funktion in der Klasse des formfield könnte ab Zeile 218 etwa so aussehen (nur unvollständig getestet in 9.2.2):
/**
*
* @param string $name
* @param array $tagAtts
* @param array $ff
* @param array $attribs @unused-param
* @return string
*/
protected static function select(string $name, array $tagAtts, array $ff, array $attribs): string{
$selected = $ff['value']['value'] ?? self::$doc->getElementFromKey($name, 'ffdefault');
$foo = explode("\n", strtr(self::$doc->getElementFromKey($name, 'ffvalues'), ["\r\n" => "\n", "\r" => "\n",]));
// $tagContent = (isset($attribs['multiple']) || !isset($attribs['required']) ? '' :
// self::htmlTag('option', ['disabled' => 'disabled', 'selected' => 'selected', 'value' => ''], ' '));
$tagContent ='';
foreach ($foo as $v) {
$v = trim($v);
if ($v === '') {
continue;
}
if (strpos($v, ',') !== false) {
$parts = explode(',', $v);
$part1 = trim($parts[0]);
$part2 = trim($parts[1]);
$atts = ['value' => htmlspecialchars($part1)];
if ($selected == $v) {
$atts['selected'] = 'selected';
}
$tagContent .= self::htmlTag('option', $atts, htmlspecialchars($part2));
} else {
$atts = ['value' => htmlspecialchars($v)];
if ($selected == $v) {
$atts['selected'] = 'selected';
}
$tagContent .= self::htmlTag('option', $atts, htmlspecialchars($v));
}
}
return self::htmlTag('select', $tagAtts, $tagContent, true);
}Dabei können die Option-Values und Inhalte wie beisher pro Zeile eingegeben werden. Wenn es ein Komma in der Zeile gibt, wird der Wert vor dem Komma als value und der hinter als Inhalt ausgegeben. Dadurch kann man auch ein leeres value-Attribut ausgeben, das man für required braucht.
Diese Funktion funktioniert vermutlich auch, wenn mehr als ein Komma angegeben wird, weil die Teile ignoriert werden. (Ohne Gewähr;-)
Hallo Fin,
ich möchte kein neues Feature, das das vermeintliche Feature ausbügelt, sondern, dass das Tag einfach eine solche Ausgabe erzeugt, wie es sie in den vergangenen 15 Jahren erzeugt hat. Dass die Ausgabe ohne Ankündigung und ohne Möglichkeit die neue Funktion zu deaktivieren geändert wird, ist aus meiner Sicht schlecht.
Oder übersehe ich was?
Es gibt für mich sonst nur zwei Möglichkeiten: Entweder ich kann die Sites, die diese Funktion einsetzen, nicht upgraden, oder ich muss per JS die überflüssigen leeren und deaktivierten Option-Elemente löschen. Beides eigentlich keie Option.
Beste Grüße
Ludger
Hallo, wird es dafür einen Fix geben? Für bestehende Sites, die das Tag formfield: select einsetzen ist das doch ein breaking change. Oder übersehe ich etwas?
Beste Grüße
Ludger
Ich habe Zeile 229 der Klasse des formfield-Tags jetzt mal so ergänzt:
$tagContent = (isset($attribs['multiple']) || !isset($attribs['required'])Das funktioniert für mich erst mal, aber ist ja nicht nachhaltig.
Aus meiner Sicht macht es nicht wirklich Sinn, das erste Option-Element fest als leer vorzugeben (man kann ja kein "Bitte wählen" vorgeben und auch noch zu disablen. Ich betreue meherere Sites mit Formularen mit formfield selects, von denen viele die Option brauchen, dass die User sie wieder auf "keine Auswahl" setzen können. Die wären so in 9.2.2 unbrauchbar und die verbessernden Javascripte müsste ich alle anpassen.
Wie wäre es denn stattdessen mit einem Feature, durch das man value und Inhalt der Option-Elemente getrennt voneinander (z.B mit Komma getrennt) setzen kann. Dann kann ich auch ein leeres value lasse, was bei Browservalidierung mit required ja funktionieren würde.
Hallo,
ich hatte das damals im alten Forum angestoßen. Eine Lösung habe ich nicht gefunden. Das Problem tritt sproradisch wieder auf. Ich kann durch wechseln von PHP 8.0 auf 8.1 oder anders herum die Site wieder zum laufen bringen. Das ist aber keine Lösung. Der Support von HE hat nur pauschale Antworten gegeben. Damals lief MYSQl mit Version 8.1.2. Die betroffenen Sites laufen jetzt mit MYSQL 5.7.43 (ist scheinbar geändert worden). Der mysqlnd wird allerdings mit Version 8.1.22 angegeben.
Danke Ulrich,
ob die Tags miteinander zu tun haben, weiß ich nicht. Formfield - select funktionierte in 9.1.6 jedenfalls noch anders. Bei dem Tag konnten die Redakteure die Option-Elemente des Selects frei bestimmen. In 9.2.2 ist das erste Option-Element vorgegeben und leer und vor allem disabled. Ein Atrribut Placeholder gibt es scheinbar nicht. Wie man das disabled wegbekommt, ohne JS drüber laufen zu lassen, habe ich noch nicht herausgefunden.
Danke Marc, Grundsätzlich finde ich das keine gute Idee, das in dieser Form vorzugeben. Es kann ja auch sein, dass in einem Formular eine Option (die erste) schon ausgewählt sein soll, oder die User die gewählte Option wieder abwählen können sollen.
Zudem werden schon bestehende Formfields jetzt auch so verändert, dass sie u.U., wie in meinem Fall durch das disabled nicht mehr bedienbar sind. Die einfache Lösung ist doch vielmehr ein leeres Option als erstes Element in die Selects zu bauen.
Wie kann ich denn verhindern, dass die leeren Options automatisch auf disabled stehen? Oder habe ich was übersehen?
Hallo zusammen,
nach einem Update auf wE 9.2.2 erzeugen we:formfield vom type select immer ein leeres Option-Element über den schon bestehenden, von den Redakteuren eingegebenen Option-Elementen. Das leere Option-Element ist zudem noch disabled, so dass der FE-Nutzer seine Auswahl nicht wieder zurücksetzen kann. Das ist aus meiner Sicht nicht hilfreich. Kann jemand das Verhalten bestätigen und ist das ein Bug?