Beiträge von sommers
-
-
Danke, Nils! Könntest du mir einen Hinweis geben, wo (in welcher Klasse o.ä.) ich die Änderungen lokalisieren kann?
-
Hallo!
Wir haben aktuell das Problem mit einer WE 9.1.5.1-Installation. Dort werden in einem <we:link>-Tag im Inhaltsfeld "Text" eingegebene „kaufmännische und“ (&) in & umgewandelt, wobei bei jedem neuen Bearbeiten des Links das umgewandelte & wieder in & umgewandelt wird.Ich hatte mir eingebildet, dazu bereits mal etwas hier gesehen zu haben, habe jetzt aber nichts gefunden bei meiner Suche. Ein vergleichbarer Bug im Attribut-Feld wurde ja in WE 9.1.4 bereits behoben.
Kennt jemand einen Workaround? WE-Update der Instanz ist derzeit nicht möglich. -
Könntest du mal als Versuch probieren, die erste Zeile "direkt" ins Template zu geben, also statt dem "php echo"
(ich konnte mit deinem Code das Problem unter 9.2.2.0 (Revision: 14807, PHP 8.2.11), allerdings nicht rekonstruieren, das funktioniert bei mir ohne Fehler)
-
Hallo zusammen,
beim Versuch, unter wE 8 genutzte Hooks für wE 9(.1.5) umzuschreiben bin ich auf ein Problem mit dem Unpublish-Hook gestoßen: so wie es im Sample-Hook dargestellt ist, scheint keine Information über das auslösende Dokument zur Verfügung zu stehen ($param/$params). Der Publish-Hook funktioniert dagegen problemlos.
Ich habe bereits einen Bug-Report geschrieben, doch kann das Problem vielleicht jemand bestätigen oder mache ich gar einen Fehler?
Hier der Link zum Bug-Report mit meinem Beispiel-Code
https://qa.webedition.org/view.php?id=14113 -
-
Von einer Kundin erreicht uns folgender Hilferuf:
ZitatWe have noticed that since the update we go back to the root directory every time we want to add a new link - previously we went back to the last location. This is the same for images as well.
Is it possible to change the settings to allow us to go back to the way it was before?
Das Verhalten kann ich bestätigen, wenn man ein neues Bild oder einen Link auswählen möchte, landet man immer wieder im Root-Verzeichnis, während in früheren webEdition-Versionen das zuletzt aufgerufene Verzeichnis der Default war.
("Since the update": hier wird derzeit wE 9.1.5 verwendet)
Ich befürchte, es gibt keine Einstellungsmöglichkeit, um das vorherige Verhalten wieder zurück zu bekommen, oder? Bzw.: handelt es sich um einen Bug? -
-
-
In einer Installation, die kürzlich auf 9.1.5 aktualisiert wurde, können vorhandene Inhalte, die in einer Textarea mit (z.B.) name="intro text" nicht mehr bearbeitet werden. Bei inlineedit=false und vorhandenem Inhalt öffnet sich zwar das Modal Window, der Inhalt wird aber nicht geladen. Das gleiche Verhalten ist auch unter wE 9.2.0 zu beobachten. Bei einem neuen Template ohne Inhalt erscheint diese Textarea im Editmode gar nicht.
Unabhängig von der Frage "Bug oder Feature": kennt jemand einen verlustfreie Möglichkeit, ein solches Feld z.B. umzubenennen (also im Bsp. zu name="introtext" und somit im Idealfall wieder bearbeitbar zu machen? -
Habs eingetragen und noch um we:select sowie we:textarea (removefirstparagraph=true) ergänzt, da funktioniert nämlich Wert 0 auch nicht.
webEdition CMS - Quality Assurance -
Ich frage mich gerade, ob ich auf dem Schlauch stehe, oder ob das schlicht ein Eintrag für die Bugbase werden sollte:
ich kann in ein normales Textfeld nicht die Ziffer 0 eintragen, in der Ausgabe ist dieses Feld dann nicht definiert/wird nicht ausgegeben (man kommt z.B. auch nicht mit to="global" an den Wert). Uns ist es im Rahmen der Umstellung auf wE 9.1.5 aufgefallen, es hat in früheren Versionen noch funktioniert. In 9.2.0 tritt dieses Verhalten ebenso auf. -
Ja, kann ich beides bestätigen.
In älteren Versionen ist der Eintrag für listview in der Tag-Hilfe noch vorhanden.
Das Problem mit der unformatierten Seite dürfte daher kommen, dass die URl im webEdition Popup ohne https aufgerufen wird (Aufruf "open_tagreference ") und dann das Laden der Assets fehlschlägt
http://www.webedition.org/de/webedition-…w-type-document -
Hallo Kay,
kann ich so nicht bestätigen, die folgende Zeile liefert bei mir das erwartete Ergebnis
Das Feld "Date" in der entsprechenden Vorlage sieht so aus:
Wie ist das bei dir?
Viele Grüße
Stefan -
Betrifft es Objekte?
Läuft das Update ganz durch? Es gibt einen Fall, da werden die Objekte nicht aktualisiert, weil das Update nicht ganz durchläuft. Ein Rebuild zerschießt diese dann endgültig.
-> Lösung ist in dem Fall eine Update-Wiederholung ohne Rebuild o.Ä. Einfach nach dem Update nochmal eine Update-Wiederholung hinterher.
Vielleicht hilfts jaIn dem Beispiel waren keine Objekte betroffen, nur Dokumente. Eine Update-Wiederholung direkt nach dem Update (welches wie gesagt sauber durch lief) brachte leider auch keine Besserung..
mokraemer leider ist von der 8.0.5 ja nur ein Update zur 8.0.6 möglich?
-
-
sommers ich dachte in dem Fall tatsächlich nur an die Bugbase - grundsätzlich sind die FRs im Forum gut und sinnvoll. Bei Kleinigkeiten kann man es, denke ich, auch direkt machen. Aber jetzt steht es mal im Forum, mal sehen ob da was kommt
Ich habe den FR jetzt einmal in die Bugbase eingetragen.
-
Wir haben aktuell einen Fall, bei dem Inhalte teilweise verschwinden, wenn man ein Update von webEdition 8.0.5 auf 8.0.6 durchführt. Das Update läuft ohne Unterbrechung durch
PHP Version 7.4.32MySQL Version 5.7.41
Verschiedene Strategien führten zum selben Ergebnis, z.B. haben wir einen kompletten Rebuild (Dokumente und Templates) durchlaufen lassen vor dem Update und haben eine Update-Wiederholung vor dem Update auf 8.0.6 gemacht.
Einziger Fehler im Update-Log:Codetblversions.sql: Einige Datenbankanfragen konnten nicht durchgeführt werden.1115 Unknown+character+set%3A+%27ENUM%27 -- ALTER TABLE `tblversions` MODIFY CreatorID int unsigned NOT NULL DEFAULT '0' AFTER `CreationDate`,MODIFY TemplateID int unsigned NULL AFTER `Path`,MODIFY Extension tinytext NULL AFTER `Filename`,MODIFY IsDynamic BOOLEAN NOT NULL DEFAULT '0' AFTER `Extension`,MODIFY IsSearchable BOOLEAN NOT NULL DEFAULT '0' AFTER `IsDynamic`,MODIFY DocType mediumint unsigned NOT NULL DEFAULT '0' AFTER `ClassName`,MODIFY Category text NULL AFTER `DocType`,MODIFY RestrictOwners BOOLEAN NOT NULL DEFAULT '0' AFTER `Category`,MODIFY Owners tinytext NULL AFTER `RestrictOwners`,MODIFY OwnersReadOnly text NULL AFTER `Owners`,MODIFY WebUserID bigint unsigned NULL AFTER `Language`,MODIFY Workspaces text NULL AFTER `WebUserID`,MODIFY Templates tinytext NULL AFTER `Workspaces`,MODIFY MasterTemplateID int unsigned NULL AFTER `Templates`,MODIFY TableID mediumint unsigned NULL AFTER `MasterTemplateID`,MODIFY ObjectID int unsigned NULL AFTER `TableID`,MODIFY IsClassFolder BOOLEAN NULL, Charset ENUM('','UTF-8','ISO-8859-1','ISO-8859-2','ISO-8859-3','ISO-8859-4','ISO-8859-5','ISO-8859-6','ISO-8859-7','ISO-8859-8','ISO-8859-9','ISO-8859-10','ISO-8859-11','ISO-8859-12','ISO-8859-13','ISO-8859-14','ISO-8859-15','Windows-1251','Windows-1252') NOT NULL default '' AFTER `ObjectID`,MODIFY active BOOLEAN NOT NULL DEFAULT '0' AFTER `Charset`,MODIFY fromScheduler BOOLEAN NOT NULL DEFAULT '0' AFTER `active`,MODIFY fromImport BOOLEAN NOT NULL DEFAULT '0' AFTER `fromScheduler`,MODIFY resetFromVersion bigint unsigned NULL AFTER `fromImport`,MODIFY InGlossar BOOLEAN NOT NULL DEFAULT '0' AFTER `resetFromVersion` -- 1115 Unknown+character+set%3A+%27ENUM%27 -- ALTER TABLE `tblversions` MODIFY CreatorID int unsigned NOT NULL DEFAULT '0' AFTER `CreationDate`,MODIFY TemplateID int unsigned NULL AFTER `Path`,MODIFY Extension tinytext NULL AFTER `Filename`,MODIFY IsDynamic BOOLEAN NOT NULL DEFAULT '0' AFTER `Extension`,MODIFY IsSearchable BOOLEAN NOT NULL DEFAULT '0' AFTER `IsDynamic`,MODIFY DocType mediumint unsigned NOT NULL DEFAULT '0' AFTER `ClassName`,MODIFY Category text NULL AFTER `DocType`,MODIFY RestrictOwners BOOLEAN NOT NULL DEFAULT '0' AFTER `Category`,MODIFY Owners tinytext NULL AFTER `RestrictOwners`,MODIFY OwnersReadOnly text NULL AFTER `Owners`,MODIFY WebUserID bigint unsigned NULL AFTER `Language`,MODIFY Workspaces text NULL AFTER `WebUserID`,MODIFY Templates tinytext NULL AFTER `Workspaces`,MODIFY MasterTemplateID int unsigned NULL AFTER `Templates`,MODIFY TableID mediumint unsigned NULL AFTER `MasterTemplateID`,MODIFY ObjectID int unsigned NULL AFTER `TableID`,MODIFY IsClassFolder BOOLEAN NULL, Charset ENUM('','UTF-8','ISO-8859-1','ISO-8859-2','ISO-8859-3','ISO-8859-4','ISO-8859-5','ISO-8859-6','ISO-8859-7','ISO-8859-8','ISO-8859-9','ISO-8859-10','ISO-8859-11','ISO-8859-12','ISO-8859-13','ISO-8859-14','ISO-8859-15','Windows-1251','Windows-1252') NOT NULL default '' AFTER `ObjectID`,MODIFY active BOOLEAN NOT NULL DEFAULT '0' AFTER `Charset`,MODIFY fromScheduler BOOLEAN NOT NULL DEFAULT '0' AFTER `active`,MODIFY fromImport BOOLEAN NOT NULL DEFAULT '0' AFTER `fromScheduler`,MODIFY resetFromVersion bigint unsigned NULL AFTER `fromImport`,MODIFY InGlossar BOOLEAN NOT NULL DEFAULT '0' AFTER `resetFromVersion` --
Hat jemand eine Idee?
-
Thema
FR: we:conditionAdd um var="array" und compare="IN" erweitern
Beim Tag we:conditionAdd lassen sich derzeit nur Strings im Attribut var verwenden und das compare-Attribut ist auf die Werte "=, !=, <, >, <=, >=, like, not like" beschränkt.
Als Beispiel soll dienen:
<we:conditionAdd field="Kontakt_Adresse_PLZ" var="plzrange" compare="IN" />
plzrange sei ein Array und mit dieser Abfrage ließe sich leicht ob sich Kontakt_Adresse_PLZ in der entsprechenden Range befindet.
Siehe auch die Diskussion hier:
Vergleich mit einem Array in einer Conditionsommers14. März 2023 um 18:49 -
Beim Tag we:conditionAdd lassen sich derzeit nur Strings im Attribut var verwenden und das compare-Attribut ist auf die Werte "=, !=, <, >, <=, >=, like, not like" beschränkt.
Als Beispiel soll dienen:
<we:conditionAdd field="Kontakt_Adresse_PLZ" var="plzrange" compare="IN" />plzrange sei ein Array und mit dieser Abfrage ließe sich leicht ob sich Kontakt_Adresse_PLZ in der entsprechenden Range befindet.
Siehe auch die Diskussion hier:
Vergleich mit einem Array in einer Condition