Hallo Markus, danke für Deine Schilderung. Ich habe jetzt auch den Wechsel zu einem anderen Provider angestoßen.
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);
}
Alles anzeigen
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:
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?
Das Problem, dass Redakteure nicht Arbeitsbereiche zuweisen können und die Objekte die zugewiesenen Arbeitsbereich verlieren, beruht auf dem Konzept der "Arbeitsbereiche" bei Backend-User-Accounts und Objekten. Das Konzept erschließt sich mir noch nicht, bzw. ich weiß nicht, wie ich die von mir benötigte Rechtekontruktion damit umsetzen kann:
Bei User-Accounts sind Arbeitsbereiche, die Bereiche im Verzeichnis- oder Objektbaum, in denen der User Dokumente bzw Objekte bearbeiten darf. So weit so klar. Bei Objekten sind Arbeitsbereiche, wenn ich das richtig verstehe, die Verzeichnisse in denen eine Detailseite über das we:object-Element die Objekte darstellen darf.
Wenn nun eine Redakteurin nicht das Recht hat im Verzeichnis zu veröffentlichen, das dem Objekt in der Klasse oder direkt beim Objekt als Arbeitsbereich zugewiesen ist, verliert das bearbeitete Objekt nach dem Speichern seinen (z.B. von einem Redakteur mit anderen Rechten) schon zugewiesenen Arbeitsbereich. Die Möglichkeit den Arbeitsbereich neu zu vergeben hat der Redakteur nicht. Wenn der Arbeitsbereich aber weg ist, wird das Objekt mit dem we:object-Element auf der Detailseite aber nicht mehr dargestellt. Es wird als nicht gefunden mit Fehler 404 behandelt.
Davon betroffen ist übrigens nicht eine Anzeige des Objektes innerhalb einer Liste mit we:listview. Es ist also möglich, das Objekt als einzelnes mit we:listview rows= 1 und der ID des Objektes auf einer Seite auszugeben, die nicht zum Arbeitsbereich der Redakteurin gehört. Das ist nicht konsistent.
Mein Problem ist aber diese Situation umzusetzen: Ein Redakteur darf Objekte bearbeiten und veröffentlichen aber nicht im Dokumenten-Verzeichnis arbeiten bzw. veröffentlichen, in dem die Detailseite der Objektdarstellung liegt.
Ich glaube, dass dieser Fall häufig vorkommt, dass die Detailseite selber nicht bearbeitbar für die Redaktion sein soll, sondern nur die Objekte, die darauf dargestellt werden sollen. Ich würde bei der Rechtekonstruktion davon ausgehen, dass es aus der Sicht der Redakteure unerheblich ist, auf welchem Dokument die Objekte dargestellt werden. Dass das nur auf den korrekten Seiten passieren kann, dafür sorgt derjenige, der die Site entwickelt. Die Arbeitsbereiche der Objekte im Dateibaum (nicht im Objektbaum) sollten aus meiner Sicht beim erstellen oder bearbeiten der Objekte keine Rolle spielen.
Ich habe das Problem jetzt unschön so gelöst, dass ich den Redakteuren alle das Recht gegeben habe im Verzeichnis zu veröffentlichen, das auch "Arbeitsbereich" des Objektes ist. Anschließend habe ich die Zugriffsrechte jedes einzelnen Dokumentes im Backend auschließlich auf den Admin eingestellt. Da das in dem Projekt nur wenige Seiten sind, war das hier eine Option. Elegant finde ich es nicht.
Hat jemand vielleicht ein besseres Verständnis des Zusammenspiels der verschiedenen Arbeitsbereichs-Konzepte oder eine andere Lösung?
wE 9.1.5
Bei Objekten sind in der Klasse mehrere Arbeitsbereiche angegeben. Redaktuere mit eingeschränkten Rechten sehen aber im Objekt bei Arbeitsbereich keine Auswahl und auch der Button "Von Klasse übernehmen" hat keine Funktion. Wenn die Redakteure die Objekte veröffentlichen, haben sie anschließend keinen Arbeitsbereich mehr und werden mit <we:object > auf der Detailseite nicht ausgegeben bzw. nicht gefunden.
Habe ich bei der Einstellung der Rechte etwas übersehen? Oder ist das ein Fehler?
Das Problem hat etwas mit den Objekt-Seo-Urls zu tun. Wenn ich das Objekt, das keinen Arbeitsbereich hat, über die URL der Detailseite mit Parameter we_oid aufrufe, wird es durch we:object richtig dargestellt.
Gelöst: In den Objekt-Tabellen fehlten die Primärschlüssel für die Spalte OF_ID. Die konnten bei einem früheren Update vermutlich nicht angelegt werden, weil es beim Feld OF_ID identische Einträge gab.
Nach einem Update einer Site von 8.0.6 auf 8.1.6 sind die Objekte, die voher schon in der Version 8.0.6 angelegt waren, in einem Backup nicht vorhanden.
Neu angelegte Objekte, die zu Klassen gehören, die in der 8.0.6 vorhanden waren werden ebenfalls nicht in das Backup geschrieben.
Objekte, die zu einer Klasse gehören, die erst mit der Version 8..1.6 angelegt worden ist, sind aber vorhanden.
Woran könnte das liegen? Welche Verknüpfung fehlt in der Datenbank bei den alten Klassen und Objekten?
Viele Grüße
Ludger