Posts by coolworx

Naja, weil er zum Zeitpunkt des Schreibens des Objektes ja noch keine Objekt-ID zur Verfügung hat, die er im Objektnamen hintendran hängen möchte.
Der kompletten gewünschten Objektnamen kann er doch erst zusammensetzen, sobald er die ID hat...

Hallo stornyhubs,

ich gehe davon aus, dass Du ein Objekt erstellst mithilfe eines Formulars? Und das erstellte Objekt soll einen gewünschten Datei- bzw. Objektnamen erhalten?

Wenn das so ist, solltest Du das Objekt zunächst mit we:write ohne das Attribut "name" schreiben und es im Nachgang umbenennen. Dabei holst Du Dir per request die ersten drei Teile (Name, Vorname, Geburtsdatum)und setzt diese mit php zusammen, z. B. so:

<?php
$tempNewFilename=$_REQUEST['Name'] . "-" . $_REQUEST['Vorname'] . "-" . $_REQUEST['Geburtsdatem'];
?>

Danach kommt z. B.

<we:ifWritten type="object" formname="blubb">

<we:var type="request" name="we_editObject_ID" to="global" nameto="currentOID" />

An dieser Stelle vervollständigst Du Deinen gewünschten Objektnamen, z. B. so:

<?php
$newFilename=$tempNewFilename . "-" . $GLOBALS['currentOID'];
?>

und trägst diesen direkt in der Datenbank nach:

<?php
$db = new DB_WE();
$sql="UPDATE tblObjectFiles SET Filename=$newFilename WHERE ID='".trim($GLOBALS['currentOID'])."'";
$db->query($sql);                        
?>

</we:ifWritten>

ACHTUNG! Diese Vorgehensweise ist nicht unbedingt updatefähig! Sie funktioniert für uns seit Version 9.x und aktuell bis 10.1.2.1 (Nightly)

Darüber hinaus solltest Du darauf achten, dass die Request-Vars. sofern sie nicht mit we:userInput erfasst wurden, für MySQL vorbereitet wurden, z. B. mit dem Attribut "prepareSQL=true"

Hallöchen,

wir lösen das seit geraumer Zeit so:

<?php
$GLOBALS['eMailServer']="Name<norepl@domain.de>";
?>

... und bei we:sendMail wie folgt:

<we:sendMail id="123" recipient="$mailRecipient" from="\$eMailServer" reply="\$eMailAdmin" subject="\$subject" charset="UTF-8" mimetype="text/html" />

Ich habe es befürchtet.

Ist es denkbar, dies ggf. zu ändern?

Seit Jahren erzeuge ich die (Unter-)Seiten einer Webpräsenz mit Objekten, statt mit Dokumenten.

Aktuell bin ich eine einer Multidomain-Installation und musste feststellen, dass Objekte mit gleichnamiger URL (URL-Feld 1) trotz verschiedener Klassen und verschiedener Arbeitsbereiche (zumindest derzeit) nicht möglich sind. Es kommt immer die Meldung, dass die gewünschte URL bereits besteht.

Beispiel:

Für beide Domains soll es z. B. eine Seite "Datenschutz" (URL-Feld 1) geben

Klasse 1 (Seiten_Domain_1)
Voreinstellung für die Darstellung: /domain1/index.php
Arbeitsbereich: /domain1
Vorlage: /domain1/templates/seiten

Klasse 2 (Seiten_Domain_2)
Voreinstellung für die Darstellung: /domain2/index.php
Arbeitsbereich: /domain2
Vorlage: /domain2/templates/seiten

Meine Annahme, dass gleichlautende URLs in einer Multidomain-Installation immer dann möglich sind, wenn diese in verschiedenen (der jeweiligen Domain zugeordneten) Arbeitsbereichen angesiedelt sind, trifft wohl nicht zu.

Daher die Frage, ob es sich hier u. U. um einen Bug (WE 10.0.4.0) handelt?
Gibt es hier evtl. Erfahrungen, wie der vorgenannte Weg dennoch umgesetzt werden kann?

Hallo Matze,

Deine Fragestellung ist tatsächlich sehr allgemein. webEdition stellt Dir für das, was Du machen willst, alles zur Verfügung und im Prinzip hast Du doch schon erkannt, mit welchen we:tags das ganze funktioniert.

we:form, we:write, we:ifWritten, und im Kundenbereich auch we:userInput

Schaue Dir diese Tags doch einfach nochmal an. Fertige Lösungen gibt es hier nicht. Hier ein ganz grobes Beispiel:

<we:ifNotVarEmpty formname="">
<we:write formname="" />
<we:ifWritten>
...
<we:else />
...
<we:form type="" formname="">
...
</we:form>
</we:ifWritten>
</we:ifNotVarEmpty>

Ohne es genau zu wissen, vermute ich, dass die Zeichenübermittlung in den Textboxen von webEdition nicht korrekt interpretiert werden kann (Emojis sind keine html-entities?).

Einen Filter schließe ich aus, denn ich kann mir nicht vorstellen, dass ein solcher eingebaut wäre.

Hast Du denn mal probiert, ob das manuelle Einsetzen eines Emojis in eine Textbox mit wysiwyg="true" zum gleichen oder einem anderen Ergebnis führt?

Schön, dass es funktioniert!

Hallo Heiko,

wir machen so etwas ähnliches mit Galerieordnern, die angelegt werden müssen.

Du könntest am oder vor dem Import der News mit php abfragen, aus welchem Jahr und welchem Monat die News stammt und dann per php ein Verzeichnis anlegen, dessen ID dann als parentID für das zu erzeugende oder zu speichernde News-Dokument angelegt wird.

<?php
$jahr=$ergebnisJahr;
$monat=$ergebnismonat;
//zuerst erzeugen wir den Jahresordner unter "aktuelles"
$parentID_aktuelles = (int)$GLOBALS['aktuelles']; 
$folder_jahr = new we_folder_document();
$folder_jahr->we_new($parentID_folders, $jahr);
$folder_jahr->we_save();

//holt sich die ID des eben angelegten Jahresordner
$pathJahr = "/aktuelles/" . $filename;
$currentFolder = path_to_id($pathJahr);
//nun legen wir den Ordner für den Monat 06 an
 $parentID_monat = (int)$currentFolder;
 $folder_monat = new we_folder_document();
 $folder_monat->we_new($parentID_jahr, "$monat");
 $folder_monat->we_save();
 //holt sich die ID des eben angelegten Monats-Verzeichnisses
 $pathMonat = "/aktuelles/".$jahr."/"."$monat";
 $IDcurrentNews = path_to_id($pathMonat);
 ?>

Die Variable $IDcurrentNews wäre dann das Verzeichnis (ID), in das die betreffende News abgelegt wird.
Allerdings müsstest Du noch klären, wie Du verfährst, wenn für den gleichen Monat ein zweite oder gar dritte News importiert werden würde.

Ich habe das jetzt alles mal so runtergeschrieben - also keine Garantie für einwandfreie Funktion. Sollte auch nur eine kleine Hilfestellung sein.

Ach ja, und updatesicher ist das selbstredend nicht!!!

Hallo srudolph,

das scheint mir ein Fall für die Bugbase zu sein.

Unter https://qa.webedition.org/view.php?id=14450 haben wir ein anderes Problem eingetragen, das nachvollziehbar seit Version 10.0.0 auftritt. Bei uns werden die Bilder allerdings ins korrekte Verzeichnis hochgeladen, aber werden im Frontend nicht ausgegeben.

Ich empfehle Dir, Deinen Fall dort ebenfalls zu schildern.

Wir hatten am Mittwoch das gleiche Problem - komischerweise aber nur auf einem unserer Server, die alle übrigens gleich konfiguriert sind.

Am Donnerstag trat das Problem nicht mehr auf.

Bei einem oder zwei betreffenden Feldern könnte man das zumindest so abfangen, dass der böse Code nicht innerhalb von <script></script> steht, indem man die Tags per PHP entfernt. Bei vielen Feldern ist das natürlich ein entsprechender Mehraufwand...

<we:var type="request" name="we_ui_formname[meinFeld]" nameto="tempFeld" to="local" />
<?php
$search = array("<script>","</script>");
$replace = array("","");
$modified = str_replace($search, $replace, $tempFeld);

$_REQUEST['we_ui_formname']['meinFeld']=$modified;
?>
<we:write type="object" classid="" formname="formname" publish="true" ... />

Hallo an alle Teilnehmer der webEdition Intensivtage,

ich freue mich auch im Namen des gesamten Vorstandes über das positive Feedback, zumal wir dieses Mal eine etwas übersichtlichere Runde gebildet haben. Das hat unserem Austausch jedoch keinen Abbruch getan und wir hatte eine schöne und vor allem informative Zeit.

Ich verspreche hoch und heilig, dass es beim nächsten Mal kein Guinness mehr geben wird, dafür aber ums so mehr Primitivo.

Seltsam. Bei mir funktioniert es einwandfrei:
WE 9.3.1 PHP 8.3.15
Seite ist als Objekt erstellt. Ich vermute, dass bei Christoph die Arbeitsbereiche evtl. nicht korrekt eingestellt sind, oder in den Einstellungen die SEO-URLs

Nach dem Absenden von

https://domain.tld/de/kontakt
wird
https://domain.tld/de/kontakt#meldung

aufgerufen

<we:ifCaptcha formname="kontakt" name="captcha">
....
<we:else />

<span class="meldung green bbx" id="meldung">
Vielen Dank. Die Nachricht wurde erfolgreich versandt.
</span>
       
<we:ifNotVarEmpty match="Absenden" type="post">
<span class="meldung orange" id="meldung">
Bitte geben Sie den richtigen Spamschutz-Code ein.
</span>
</we:ifNotVarEmpty>
       
<we:form method="post" name="kontakt" id="self" params="#meldung">
....
</we:form>
</we:ifCaptcha>

Hallo Christoph,

klar, funktioniert auch in 9.2.3 wir setzen das sehr häufig ein.

Hallo Martin,

ich nehme an, dein Code stammt aus einer Version 9.2.3?

Ich habe mal unsere Suche angeschaut. Diese funktioniert einwandfrei.
Hast Du es mal mit einem Rebuild der Index-Tabelle probiert?

<we:ifSearch name="search" set="true">
    <we:ifVarEmpty name="search" type="global">
        <span class="headline gradient">Du hast keinen Suchbegriff eingegeben</span>
        <we:form type="search" name="search" method="post" id="self">
            <we:search type="textinput" class="input i100 bbx" maxlength="80" placeholder="Gib hier Deinen Suchbegriff ein" name="search" />
        </we:form>

        <we:else />

        <we:listview type="search" name="search" classid="2" casesensitive="false">
            <we:ifFound>
                <we:listviewRows to="global" nameto="results" />

                <span class="headline gradient">Gefunden für <em>"<we:search type="print" name="search" />"</em> - <we:var name="results" type="global" /> Treffer</span>            
                <we:repeat>

                    <we:field name="we_id" to="global" nameto="objectID" />
                    <we:object id="\$objectID">
                        <we:include id="159" type="template" name="profilpic-inc" />
                    </we:object>

                </we:repeat>

                <we:else />

                <span class="headline gradient">Kein Ergebnis für Deinen Suchbegriff</span>

                <we:form type="search" name="search" method="post" id="self">
                    <we:search type="textinput" class="input i100 bbx" maxlength="80" placeholder="Neue Suche" name="search" value="" />
                </we:form>

            </we:ifFound>
        </we:listview>
    </we:ifVarEmpty>
</we:ifSearch>

Hallo Sascha,

yep, habe mir das ganze jetzt auch noch einmal angeschaut und auch noch einmal getestet. Du hast Recht, ohne $obj->resetParentID() , das tatsächlich nicht ausgeführt wird, scheint das gesamte Konstrukt nicht zu funktionieren. Sieht nach einem Bug aus. Ich trage das einfach mal in die Bugbase ein.

Das SQL-Statement bleibt unverändert.

Hallo Sascha,

danke für den Hinweis, aber das hatte ich alles schon geprüft. Zwischenzeitlich bin ich mir 100%ig sicher, dass

                $obj->resetParentID();
                $obj->ParentID = 1729;

aktuell definitiv nicht (mehr) ausgeführt wird. Aufgrund fehlender Hinweise sowohl im wE-Log, als auch im Serverlog habe ich keinerlei Ansatzpunkte. Ich versuche jetzt noch, mir die entspr. Klasse rauszusuchen und zu schauen, was darin enthalten ist.

Hallo Marc,

$obj->ParentID = '1729';
Löst keinen Fatal Error aus.

Die einfachen Anführungszeichen habe ich ebenfalls entfernt, ebenso das obj->we_save().
Dennoch werden die Objekte lediglich geparkt, nicht aber in das vorgesehene Verzeichnis geschoben.

Hallo Finn,

leider nein.