Moin Martin,
damit alle was von der Antwort haben, einmal hier:
Im Prinzip ist es so, wie Nils schon gesagt hat, da dein Template ja Teil einer bestehenden Funktion ist, musst du an der Stelle mit define anstelle von const arbeiten.
Und zusätzlich fehlte noch eine schließende ")" Klammer.
strict_types darf an der Stelle auch nicht gesetzt werden.
Ich habe das Dokument erstmal geparkt, damit da keine Tokens verbraucht werden.
Ich hänge mich eben dran, weil es passt (finde ich): Wie greife ich auf die OF_ID des Elternobjekts zu? Das Feld OF_ID kommt ja in allen Objekten vor.
Also ich habe die 2 Objekte Kunde und News, und News hat ein Feld /Kunde (intern in der DB object_1)
Für den Fall gibt es kein <we:field>, oder übersehe ich was?
Beziehst du dich auf eine Listview oder auf eine SEO-Objektansicht?
Moin Martin,
da scheint ein Syntaxfehler in der Zeile oder der Zeile davor zu sein.
Hallo Silvia,
das Verhalten ist erklärbar: <we:ifObject classid="3"> innerhalb von <we:repeat> filtert die Treffer nicht, sondern prüft nur pro Treffer, ob es sich um ein Objekt der Klasse 3 handelt und gibt dann zusätzlich die Description aus. Die Suche selbst liefert weiterhin alle Objektklassen.
Die Filterung gehört direkt in den Listview-Tag:
<we:listview type="search" name="suche" rows="20" order="Title" classid="3">Damit werden allerdings nur noch Objekte der Klasse 3 durchsucht.
Für Dokumente und Objekte müsstest du irgend sowas bauen...
<we:repeat>
<we:ifDocument>
<li>… Ausgabe Dokument …</li>
</we:ifDocument>
<we:ifObject classid="3">
<li>… Ausgabe Objekt …</li>
</we:ifObject>
</we:repeat>Wichtiger Hinweis dazu: Bei dieser Variante stimmen Trefferzähler und Paginierung (rows="20", we:listviewStart/End) nicht mehr, weil die ausgefilterten Objekte mitgezählt werden. Das würde auch in deiner Variante so nicht klappen. Deshalb ist das classid-Attribut am Listview die sauberere Lösung, eventuell mit zwei Listviews hintereinander, einer für Dokumente und einer für Objekte oder mit PHP.
LG
Finn
Edit:
Wenn du die Doctypes definiert hast, sollte glaube ich auch sowas gehen:
<we:listview type="search" name="suche" rows="20" order="Title" doctype="Standard" classid="3">
Moin Moin,
mit prePublishDate wirst du an der Stelle nicht weiterkommen.
webEdition merkt sich pro Dokument/Objekt genau einen Veröffentlichungs-Zeitstempel: das Feld Published in tblObjectFiles (bzw. tblFile für Dokumente). 0 heißt „nicht veröffentlicht", alles andere ist der Timestamp der letzten Veröffentlichung. Beim Parken wird das Feld wieder auf 0 gesetzt, vorherige Information ist damit weg.
ich würde in der Klasse ein Feld anlegen, z. B. firstPublished und dieses als Referenz nutzen.
Man könnte eventuell irgendwas mit den Versionen versuchen, aber ich glaube mit dem Feld bist du schneller dran.
Hey,
Ich habe folgendes dazu in der Tag Referenz gefunden:
Falls das nicht geht, wäre sicherlich interessant welche wE Version du verwendest.
Alternativ kannst du noch probieren Name+E-Mail als Variable an <we:sendMail/> zu übergeben.
Liebe Grüße,
Sascha
Das sollte die Lösung sein.
Moin Rainer,
so ist es!
Wir sind dran, an einem Relaunch der Webseite und einer Neugestaltung des webEdition Backends.
Der Launch, ist dann sicherlich eine gute Möglichkeit, die USPs stärker in den Vordergrund zu rücken.
Moin Uwe,
für die Darstellung würde ich JS empfehlen.
Die benötigten Daten kannst du dann mit einem Listview übergeben.
Mit https://fullcalendar.io/ z.B. lassen sich dann Ansichten wie im Screenshot umsetzten.
In diesem Fall lädt sich das Script die Daten von einem json Endpunkt.
<we:ifRegisteredUser>
<we:ifVarSet name="status" type="get">
<we:condition name="filter">
<we:conditionAdd field="Status" compare="=" type="request" var="status" />
</we:condition>
<?php header('Content-Type: application/json; charset=utf-8'); ?>
<we:listview type="object" classid="4" workspaceID="215" searchable="true" condition="\$filter" >
[
<we:repeat>
<we:field type="checkbox" name="Ganztaegig" to="global" nameto="ganztaegig" />
<we:field type="text" name="Ort_Intern" to="global" nameto="ortID" />
<we:field type="text" name="Datum_Beginn" to="local" nameto="dateStart" />
<we:field type="text" name="Datum_Ende" to="local" nameto="dateEnd" />
<we:ifNotVarEmpty name="ortID" type="global">
<we:object id="\$ortID">
<we:field type="text" name="Name" to="global" nameto="ortName" />
</we:object>
</we:ifNotVarEmpty>
<?php
if ($GLOBALS['ganztaegig'] == 1){
$GLOBALS['ganztaegig'] = true;
}else {
$GLOBALS['ganztaegig'] = false;
}
?>
{
"id":<we:field type="int" name="we_id" />,
"title": "<we:field name="Titel" type="Text" striphtml="true" htmlspecialchars="true" />",
"start": "<?php echo date("Y-m-d", $dateStart) . "T" . date("G:i:s", $dateStart); ?>",
"end": "<?php echo date("Y-m-d", $dateEnd) . "T" . date("G:i:s", $dateEnd); ?>",
"allDay": <?php echo json_encode($GLOBALS['ganztaegig']); ?>,
"url": "<we:field type="link" name="we_href" />",
"extendedProps": {
"person": "<we:field name="Int_Kontakt_verantwortliche_GB_Person" type="Text" />",
"besucher": "<we:field name="Int_Erwartete_Besucherzahl" type="Text" />",
"ort": <?php echo json_encode($GLOBALS['ortName']); ?>
}
}<we:ifNotPosition position="last" type="listview">,</we:ifNotPosition>
</we:repeat>
]
</we:listview>
</we:ifVarSet>
</we:ifRegisteredUser>Datei: webEdition/we/include/we_classes/contents/we_objectFile.class.php
Zeile 47-55
$this->EditPageNrs = array_merge($this->EditPageNrs, [
we_base_constants::WE_EDITPAGE_PROPERTIES,
we_base_constants::WE_EDITPAGE_INFO,
we_base_constants::WE_EDITPAGE_CONTENT,
we_base_constants::WE_EDITPAGE_WORKSPACE,
we_base_constants::WE_EDITPAGE_PREVIEW, // ← diese Zeile entfernen
we_base_constants::WE_EDITPAGE_VARIANTS,
we_base_constants::WE_EDITPAGE_VERSIONS,
we_base_constants::WE_EDITPAGE_SCHEDULER
]);
Ich habe das nicht getestet. Aber in die Richtung könntest du schauen.
Moin Moin,
kannst du nochmal konkretisieren, was genau du umsetzten möchtest?
Theoretisch ist es auch im Frontend möglich User zu verwalten und zu editieren.
Bzgl. deines Fehlers beim Einloggen, wäre ein Blick in das Errorlog vermutlich aufschlussreich.
Moin Michael,
updatesicher fällt mir gerade nichts ein.
Ab der 10.1.1 wird das Sperren von Dokumentenreitern nativ unterstützt. Ob das auch für Objekte gilt, bin ich mir gerade unsicher.
Ja funktioniert tatsächlich. Nur was ist eigentlich wenn es die gleiche Feldbezeichung in beiden Objekten gibt? Oder ich mehrere Unterobejkte mit der selben Feldbezeichnung gibt?
Das ist nicht möglich. Klassen, deren Objekte verlinkt werden können, werden auf diesen Fall geprüft.
Moin Christoph,
das we:write schreibt nur, wenn der entsprechende edit Parameter gesetzt ist. Das wird auf der Detailseite nicht der Fall sein.
Ja man kann Tricksen, ganz viel sogar.
Du kannst die Objekte auch direkt mit PHP schreiben (nicht Updatesicher) du kannst auch mit PHP einen Request bauen, der an einen geschützten Endpunkt geht, welcher dann we:write ausführt.
Du könntest auch in der Detailseite einen iFrame zum Bearbeiten öffnen, welcher den Editlink aufruft, so bleibst du auf der entsprechenden Seite.
Also Möglichkeiten gibt es viele, die alle mehr oder weniger elegant sind. Was spricht gegen eine extra Edit-Seite?
Das Anlegen von Dateien direkt aus der IDE wäre auf jeden Fall spannend, ist aber vermutlich nicht trivial.
Ich träume gerade auch von einem MCP.
Also aus der Erinnerung kannst du doch einfach direkt auf die Fields des Objekts zugreifen, ohne ein we:object im listview.
Aber vielleicht trügt mich auch meine Erinnerung gerade.
Ziel wäre das Verhindern von ungewollten Löschungen richtig?
NilSole würde dein Ansatz über die Browserschnittstelle das Problem lösen?
Hast du eine Testinstallation, bei der du das Verhalten reproduzieren kannst?
Das Verhalten ist identisch zu der webedition.org, da habe ich alle Inhalte über die Versionierung wiederherstellen müssen.
Es handelt sich hier wohl nicht um die PHP Version, sondern um die Mindestvoraussetzungen der Datenbank.
Diese muss vorher in eine MySQL 8 oder MariaDB überführt werden. Dann läuft das Update korrekt durch.
Ich habe dazu ein Ticket aufgemacht: https://qa.webedition.org/view.php?id=14659
