Posts by Revilo

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 srudolph 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!

Hey,

wir haben seit dem Update von 9.1.5 auf 9.3.1 Probleme bei Listviews mit Conditions auf Datumsfelder.
Auf der alten Version mussten wir in der Condition zusätzlich den Feldtypen angeben, also genau so wie es in der DB stand.
Das scheint jetzt aber nicht mehr zu funktionieren. Auch ohne den Feldtypen (z.B. "EndDate") funktioniert es nicht.

Eigentlich gar nichts kompliziertes, hier sollen einfach alle vergangenen Events ausgegeben werden:

<we:date type="now" format="U" to="global" nameto="currNow"/>
<we:condition name="condEventsFilterListing">
<we:conditionAdd field="date_EndDate" var="currNow" type="global" compare="<="/>
</we:condition>

<we:listview type="object" name="lvEventsArchive" rows="\$eventsArchiveListingRows" classid="1" searchable="true" order="StartDate" desc="true" condition="\$condEventsFilterListing">
<we:ifFound>
<we:repeat>
gefunden
<we:repeat>
<we:ifFound>
</we:listview>

Drehe ich den compare-Operator um (>=) werden mir alle Objekte ausgegeben, auch die, die in der Vergangenheit liegen.

Handelt es sich hier um einen Bug oder hab ich irgendeine Änderung an den Datums-Conditions verpasst?

Viele Grüße
Oliver Geditz

Hi Getty24,

konntest Du das Problem lösen?

Stehe gerade vor dem gleichen Problem mit der 9.2.2. Es muss irgendeine Einstellung in MAMP sein, aber ich finde keine Fehlermeldung, die mir weiterhilft.

Hab's gefunden.

Die Funktion wurde von id_to_path zu id2path umbenannt

Liegt immer noch in der we_global.inc.php

Hi,

wir haben bisher in einem Save-Hook die webEdition Funktion "id_to_path" genutzt, um durch die ID eines Dokuments dessen Pfad zu ermitteln.

Heute haben wir das erste Mal ein Projekt auf webEdition Version 9.2.1 erstellt, PHP-Version 8.1.19.

Nachdem wir den Hook wie gewohnt eingerichtet haben, erscheint im Fehlerprotokoll "id_to_path is not a function", sobald der Hook aufgerufen wird.

Hat das Problem noch jemand? Ist das bekannt bzw. beabsichtigt?

Wir haben uns jetzt mit einem Workaround beholfen, aber die Funktion id_to_path() wäre trotzdem nice 2 have.

LG