Posts by coolworx

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.

Hallo zusammen,

bisher habe ich (bis Version 9.2.2) nachstehenden Script in einem Cronjob erfolgreich eingesetzt.

    <we:listview type="object" classid="7" name="hlw" condition="oldHLW">
        <we:ifFound>
            <we:repeat>
                HLW_OBJECT: <we:field name="we_id" />
                <we:field name="we_id"  nameto="IDpark7" to="local" />
                <?php
                $obj = new we_contents_objectFile();
                $obj->initByID((int)$IDpark7);
                // Objekt in neues Verzeichnis verschieben
                $obj->resetParentID();
                $obj->ParentID = '1729';
                $obj->we_save();
                $obj->we_unpublish();
                ?>
            </we:repeat>
        </we:ifFound>
    </we:listview>

Leider funktioniert das Verschieben in ein anders Verzeichnis in 9.2.3 nicht mehr. Ist irgendetwas an den Parametern verändert worden? Gibt es evtl. einen Workaround?

Hallo Christoph,

das Problem hatte ich auch schon. Du könntest die Werte in der tblCaptchaDef einmal löschen und das Formular im Frontend noch einmal aufrufen. Danach müssten Deine Änderungen, die Du im Template gemacht hast, greifen

Hallo,

in dem von Marc erwähnten Bugfix ging es um die Felder

we:userInput type="select"

we:sessionField type="select"

Hier war das Problem, dass es keine Möglichkeit gab, ein "Bitte Auswählen" zu platzieren, das nun in den genannten we-Tags mittels Attribut "Placeholder=xy" möglich ist.

Hierfür gab es auch einen guten Grund, und zwar, dass viele User über das Selectfeld mehr oder weniger gestolpert sind bzw. keine (notwendige) Auswahl getroffen haben und den Inhalt, so wie er ist, einfach übernommen haben, was in vielen Fällen letztlich zu einem nicht korrekten Datensatz führte.

Was das i. d. F. für das Tag we:formfield bedeutete, kann ich nicht beurteilen, da ich das noch nie eingesetzt habe.