Posts by Revilo

Hallo zusammen,

nach einem MySQL Update von 5.7 auf 8.0 mussten wir bei einem älteren Projekt (läuft mittlerweile auf 10.0.4) feststellen, dass dadurch verschiedene Tabellen (bei uns tblWebUser & tblObjectFiles) so stark beschädigt wurden, dass wir die Daten nicht mehr retten konnten (Index/Key-File beschädigt).

Im Austausch mit unserem Provider wurde uns mitgeteilt, dass die Speicherengine MyISAM der Grund dafür sei und wir auf InnoDB wechseln sollten, da MyISAM nicht mehr zeitgemäß sei.

Wir haben daraufhin die Tabellen auf InnoDB geändert. Im Zuge der Datenwiederherstellung aus älteren Backups haben wir eine Update-Wiederholung von webEdition durchgeführt. Dabei wurden die zuvor auf InnoDB geänderten Datenbanktabellen wieder auf MyISAM geändert.

Nach kurzer Onlinerecherche bin ich auf diesen älteren Forumsbeitrag gestoßen: https://forum.webedition.org/viewtopic.php?t=40775

Aussage von damals:

Quote

Aktiv unterstützen wir MariaDB, und dort dann MyISAM und Aria als Engine.
Da InnoDB auch nicht alles von MyISAM untersützt - eben den Volltext, dürfte es hier bei der Migration/Update der entsprechenden Tabellen immer Fehler geben. Wenn man das von Hand anpaßt (trifft nur die Indextabelle) sollte das gehen. Aktiv probiert haben wir das noch nicht, da es keine Notwendigkeit dafür gab.
=> Nur WE selbst wird auch an allen Stellen wieder versuchen Aria/Myisam Tabellen anzulegen (Klassen/Updates), das wird dann auch immer scheitern.

Ich nehme an, dass das auch noch der aktuelle Stand ist.

Hat jemand Projekte, die auf MySQL 8 problemlos laufen bzw. von 5.7 auf 8.0 problemlos geupdatet werden konnten und hat Tipps für uns?

Wir würden solche Datenverluste in Zukunft gerne vermeiden, da es hier wirklich ein Glücksfall war, dass wir die Daten noch einigermaßen wiederherstellen konnten. Der Datenverlust ist leider viel zu spät aufgefallen.
Normalerweise nutzen wir auch MariaDB, aber bei diesem Projekt aus irgendwelchen Gründen an die sich niemand mehr erinnern kann leider nicht.

Viele Grüße

Oliver

Hi,

ich habe den Cache gerade nochmal aktiviert und mir die Fehler aus der Datenbanktabelle gezogen. Es scheint, als würde er einzelne includes nicht mehr finden. Vorallem Dateien, die über <we:css> oder <we:js> eingebunden werden.

Das Fehlerprotokoll lässt sich aus dem Backend heraus dann auch nicht mehr benutzen, weil bei Klick auf jeglichen Button (z.B. Weiter, Zurück) das Fehlerprotokoll als leer ohne Fehler anzeigt wird.

Fehler, die bei einem Seitenaufruf aufgetreten sind:

Ich trage das jetzt aber auch in der Bugbase ein

Hallo zusammen,

wir haben ein webEdition Projekt in dem der Redis-Cache aktiv ist.

Beim Updaten von 10.0.2 auf 10.0.3 haben wir ein eigenartiges Fehlerbild gehabt, bei dem die Seiten manchmal geladen wurden, manchmal gar nicht und manchmal einen Fehler ausgegeben haben.

Letztendlich war das auf den Redis-Cache zurückzuführen. Nachdem wir diesen in den webEdition Einstellungen deaktiviert haben, hat die Seite wieder vernünftig funktioniert.

Hat jemand mit dem Einsatz des Redis-Cache in webEdition Erfahrungen und eine Idee wie man mit dem Redis-Cache bei einem Update, bzw. nach einem Update verfahren muss?
Aus dem webEdition Backend heraus kann man den Cache auch nicht bereinigen. Wenn wir den Redis-Cache jetzt wieder aktivieren, haben wir wieder die oben beschriebenen Probleme.

Muss der Redis dann immer manuell über die Shell geflusht werden?

Viele Grüße

Oliver

Das Formular ist zwar bereits in mehreren Schritten umgesetzt worden, aber dass jeder Schritt ein Formular ist und die Daten weitergegeben werden haben bei der damaligen Umsetzung wie ich hörte bereits Probleme verursacht, weshalb darauf verzichtet werden musste.

Hallo zusammen,

wir haben ein längeres Formular (we:form type="object") bei dem die Nutzer scheinbar öfters zu lange fürs ausfüllen/überlegen benötigen, sodass die Standard-Gültigkeitsdauer des Formtokens von 30 Minuten nicht ausreicht, um das Formular abzuschicken.

Mit <we:formToken lifetime="7200" /> kann man die Gültigkeitsdauer ändern. Das greift aber nicht bei Formularen, die mit we:form gebaut wurden. Kennt jemand eine alternative Lösung?

Viele Grüße
Oliver

order="we_category" wirft auch einen Fehler oder zumindest eine Warnung - bin mir gerade nicht sicher.

order="Text" == order="we_category" ? Das hat bei mir leider nicht funktioniert

Hallo zusammen,

ich update gerade ältere Projekte und dabei ist mir aufgefallen, dass es früher wohl mal möglich war dem Order-Attribut einer Listview "we_category" mitzugeben, sodass nach Kategorien sortiert werden konnte.

Das ist schon länger nicht mehr möglich.

Hat jemand zufällig ein Workaround, wie das in einer 9.3er webEdition Version möglich gemacht werden kann?
Der Ansatz die Listview durchzugehen, dort Elemente mit Kategorie als Key in ein Multidimensional-Array zu schreiben und dann außerhalb der Listview mit einer entsprechenden Schleife auszugeben ist hier nicht möglich, weil die Listview noch mit Get-Parametern filterbar ist und wir auch die we-Tags für die Pagination benötigen, die nur innerhalb der Listview funktionieren.

Wahrscheinlich muss das Element einfach komplett überarbeitet werden, sodass der Multidimensional-Array-Ansatz funktionieren kann.
Ich dachte, ich frage aber trotzdem mal nach...

Beispiel-Code zur Veranschaulichung:

<we:listview name="teaserlistObject" type="object" classid="\$tlvClassId" order="we_category" searchable="true">
	<we:repeat>
	</we:repeat>

	<we:ifFound>
		<we:comment> Pagination </we:comment>
		<div>
			<we:comment> Gesamtzahl Seiten </we:comment><we:listviewPages to="global" nameto="tlvPageTotal" />
			<we:ifVar match="1" name="tlvPageTotal" operator="greater" type="global">
				<we:ifBack><a href="<we:back only="href"></we:back>">Zurück</a> </we:ifBack>
				<we:ifNext><a href="<we:next only="href"></we:next>">Weiter</a></we:ifNext>
			</we:ifVar>
		</div>
	</we:ifFound>
</we:listview>

Viele Grüße

Oliver

Haben die Umgebung neu aufgesetzt und die Update-Schritte mit den korrekten PHP-Versionen ausgeführt.
Das Datenbankproblem bestand weiterhin, konnte aber mit den o.g. Fixes behoben werden.

Der Fehler Undefined constant "WE_SITE_PATH" trat nicht mehr auf.

Danke euch!

Ich habe mir einzelne Einträge angeschaut.
Die, die ich mir stichprobenartig angeschaut habe, hatten immer identischen Inhalt.

Mit folgender Abfrage habe ich dann alle Duplikate einer Duplikatgruppe gelöscht - außer die mit der höchsten ID (da aktuellster Eintrag).

DELETE c
FROM tblContent c
JOIN (
  SELECT 
    DocumentTable,
    DID,
    MD5(Name) AS md5_hex,
    MAX(ID) AS KeepID
  FROM tblContent
  GROUP BY DocumentTable, DID, md5_hex
  HAVING COUNT(*) > 1
) dup
  ON c.DocumentTable = dup.DocumentTable
 AND c.DID = dup.DID
 AND MD5(c.Name) = dup.md5_hex
 AND c.ID != dup.KeepID

Bei einer Wiederholung des Updates gab es bei der Datenbank-Aktualisierung keine Probleme mehr. Allerdings hängt sich der Update-Prozess bei "Patche ausführen" bei 95% auf und kommt nicht weiter..

Das Update-Protokoll zeigt keine Fehler an, allerdings findet sich im Fehlerprotokoll folgender Eintrag:

Exception

Undefined constant "WE_SITE_PATH"

SECURITY_REPL_DOC_ROOT/webEdition/we/classes/update/we_update_updater.class.php

686

Hat jemand zu dem neuen Problem eine Idee?

Mit folgender Abfrage konnte ich mir die Duplikate anzeigen.

SELECT 
  DocumentTable,
  DID,
  MD5(Name) AS md5_hex,
  COUNT(*) AS cnt,
  GROUP_CONCAT(ID ORDER BY ID) AS IDs
FROM tblContent
GROUP BY DocumentTable, DID, md5_hex
HAVING cnt > 1
ORDER BY DocumentTable, DID

Das sind 106 doppelte Einträge (=212) und sieht dann so aus:


Ich würde jetzt hingehen und die Einträge mit der höheren ID behalten (da aktueller) und die mit der kleineren ID entfernen (da älter).

Oder spricht da etwas dagegen?

Wie kann sowas überhaupt passieren?

Hey Finn,

läuft auf PHP 8.1.33 und MariaDB 10.5.23

Guten Tag zusammen,

wir haben ein komplexeres Projekt von 8.1.1 auf 8.1.6 und schließlich auf 9.1.6 geupdatet.

Beim Update von 8.1.6 auf 9.1.6 ist ein Fehler aufgetreten als die Struktur der Datenbanktabelle tblContent geändert werden sollten.
Eine Update-Wiederholung hat daran nichts geändert.

Ein Problem war, dass der Spalte DocumentTable die enum-Option tblTemporaryDoc gefehlt hat. Das habe ich händisch angepasst und das Update erneut wiederholt. Allerdings wieder ohne Erfolg.

Im Update-Protokoll steht folgender Fehler:
(tblContent.sql) Einige Datenbankanfragen konnten nicht durchgeführt werden.: 1062 Duplicate+entry+%27tblFile-32161-%5CxEDO%5CxDF%5Cx0FE%5CxBF%5CxC68P%5D%5Cx01%5CxB5q%5CxCA%5CxBC%5CxA9%27+for+key+%27prim%27 -- ALTER TABLE `tblContent` MODIFY `nHash` binary(16) AS (unhex(md5(`Name`))) PERSISTENT AFTER `Dat` --

Es scheint als hätte er ein Problem damit die nHash Spalte zu ändern, weil die Einträge dann nicht mehr eindeutig wären.

Hat jemand eine Idee wie wir das Problem lösen können?

Viele Grüße

Oliver

enctype="multipart/form-data" ist gesetzt.

Dem userInput type="img" ein Value zu übergeben war natürlich Quatsch.

we:write beachtet das scheinbar eh und überschreibt den Wert im Gegensatz zu z.B. Textfeldern nicht, wenn er leer übermittelt wird.

Wenn ich keine Datei auswähle, klappt das Speichern der Änderungen im Objekt nun wunderbar mit we:write. Wenn im Objekt keine Datei hinterlegt ist und ich eine nachträglich auswähle und über das Formular hochlade, klappt es auch mit we:write.

Es klappt nur nicht, wenn im Objekt bereits eine Datei hinterlegt ist und ich diese überschreiben will. Ist das so gewollt? Vermutlich werde ich das im Frontend einfach anpassen müssen und zuerst eine "Bild löschen" Funktion bieten, bevor ein neues Bild hochgeladen werden darf.

Anbei noch der write-Befehl:

<we:write type="object" formname="memberEditObject" classid="1" onduplicate="overwrite" onpredefinedname="overwrite" forceedit="true" name="\$Name" />

Hallo zusammen,

ich hänge mich hier mal mit dran.

Ich möchte, dass Nutzer über das Frontend nachträglich Objekte bearbeiten können.
Mit we:write bin ich leider nicht weitergekommen, aber mit deinem Code Finn habe ich es hinbekommen, dass Änderungen am Objekt gespeichert werden.

Nun ist nur noch die Problematik, dass Bilder nicht hochgeladen/gespeichert & in das Objekt eingetragen werden, wenn diese geändert werden. Das wird wohl vom we:write Befehl mit übernommen, wie ich in den Core-Dateien gesehen habe.

Upload-Feld im Formular:

<we:ifNotFieldEmpty name="Bild2" type="img">
	<we:field type="img" name="Bild2" to="global" nameto="setBild2"/>
	<we:field type="img" name="Bild2" thumbnail="editmode" class="me2" />
<we:else/>
	<we:setVar to="global" nameto="setBild2" value=""/>
</we:ifNotFieldEmpty>

<we:userInput type="img" name="Bild2" parentid="644" inputclass="form-control" keepratio="true" width="1920" height="960" value="\$setBild2" />

Habt ihr eine Idee wie ich das erreichen kann?

Viele Grüße
Oliver

Nachtrag:
Ich habe die Upload-Felder im Formular mal entfernt und dann hat es auch problemlos mit we:write geklappt.
Ist der Aufbau des <we:userInput type="img"> falsch?
Feldnamen etc. sind genau so, wie beim Formular für das Erstellen des Objekts. Da klappt es problemlos.

Quote from WBTMagnum

Hallo,

Zusätzlich zur Durchsuchbarkeit kannst du auch mit unterschiedlichen Verzeichnissen (z.B. /objects/draft, /objects/public) und dem Workspace arbeiten um die Objekte im Backend besser nach Zustand zu trennen.

Alternativ könnt ihr noch direkt mit SQL arbeiten um an die geparkten Objekte heranzukommen. Entweder via PHP oder über <we:listview type="sql"/>. Nachteil: Damit bist du nicht updatesicher.

Last but not least: Du kannst natürlich einen Feature Request für die Berücksichtigung geparkter Objekte in der Listview in der Bugbase einbringen.

Liebe Grüße,
Sascha

Verrückt, die listview type="sql" kannte ich nicht. Leider ist dort aktuell ein Bug drin, daher fällt diese Möglichkeit auch weg. Via PHP kann ich aber nicht mit $DB_WE arbeiten, sondern muss mir das ganze selbst zusammenbauen, oder?

Den Feature-Request reiche ich gleich mal ein.

Quote from Finn

Das sollte trotzdem funktionieren, ihr könnt ja basierend auf dem Status einen 404 Header setzen und ein stellvertretendes Template ausgeben.

Das wird dann wohl der Workaround sein, den wir einsetzen müssen..

Danke euch!

Gute Idee, aber diese Möglichkeit können wir leider nicht nutzen, weil unsere Objekte durch SEO-URLs aufrufbar sind wie ich gerade sehe.

Deshalb benötigen wir den Park-Zustand.

Achso, du meintest wahrscheinlich, dass wir die Objekte veröffentlichen aber durchsuchbar = false ist und nach der Prüfung die Flag auf true gestellt wird.

Das wäre in der Tat eine Möglichkeit.

Viele Grüße
Oliver

Hey Finn,

die "durchsuchbar"-Flag hat leider auch keinen Effekt bei geparkten Objekten.

Viele Grüße
Oliver

Hallo zusammen, ich steige hier mal ein.

In unserem Fall können Nutzer Objekte einreichen, die dann geprüft und veröffentlicht werden sollen. Der Nutzer soll aber immer die Möglichkeit haben seine eingereichten Objekte nachträglich zu bearbeiten - auch wenn sie geparkt sind.

Eine Möglichkeit eine Listview über geparkte Objekte zu machen gibt es nicht oder?

Der Nutzer (Kunde) wird im Objekt verknüpft. Ich könnte anhand der UserID also alle verknüpften Objekte auslesen und bearbeitbar machen, sofern diese nicht geparkt wären.

Hat jemand eine Idee?

Wie s.rudolph schon angemerkt hat, sind die $DB_WE Methoden um z.B. einen Select auszuführen privatisiert worden.

Viele Grüße
Oliver

Läuft jetzt, danke dir!