Eigenes Feld aus oxarticles im backend (article_main.tpl) inkl. wysiwyg anzeigen


#1

Hallo,

ich verusche bzw. möchte mein angelegtes feld oxarticles.oxtab2 im backend unter den artikel-stammdaten anzeigen lassen inkl. wysiwyg editor, genau wie es bereits bei oxartextends.oxlongdesc der fall ist.

Dafür habe ich mir folgendes zusammen gewurstelt

Dafür habe ich 2 dateien angepasst.

ArticleMain.php:

protected function _getEditValue($oObject, $sField)
    {
        $sEditObjectValue = '';
        if ($oObject) {
            $oDescField = $oObject->getLongDescription();
            $sEditObjectValue = $this->_processEditValue($oDescField->getRawValue());
            $oDescField = new \OxidEsales\Eshop\Core\Field($sEditObjectValue, \OxidEsales\Eshop\Core\Field::T_RAW);
        }

        return $sEditObjectValue;
    }

Wurde ersetzt durch:

protected function _getEditValue( $oObject, $sField )
    {
        $sEditObjectValue = '';
        
        
        if ($sField === "oxarticles__oxlongdesc") {
            if ($oObject) {
                $oDescField = $oObject->getLongDescription();
                $sEditObjectValue = $this->_processEditValue($oDescField->getRawValue());
                $oDescField = new oxField($sEditObjectValue, oxField::T_RAW);
            }
        } else {
            if ($oObject && $sField && isset($oObject->$sField)) {
                if ($oObject->$sField instanceof oxField) {
                    $sEditObjectValue = $oObject->$sField->getRawValue();
                } else {
                    $sEditObjectValue = $oObject->$sField->value;
                }

                $sEditObjectValue = $this->_processEditValue($sEditObjectValue);
                $oObject->$sField = new oxField($sEditObjectValue, oxField::T_RAW);
            }
        }

Zusätzlich wurde noch die funktion public function render() angepasst:

Diese zeile wurde hinzugefügt:

$this->_aViewData["editor2"] = $this->_generateTextEditor( "100%", 300, $oArticle, "oxarticles__oxtab2", "details.tpl.css");

Abschliessend habe ich [{$editor2}] in die article_main.tpl eingefügt.

Im prinzip funktioniert das ganze auch. Das problem ist nur, das mir nun für jedes feld (oxlongdesc und oxtab2) jeweils 2 wysiwyg editoren angezeigt werden.

Hat hier jemand evtl. ein tip, hilfe oder ein denkanstoß?!


#2

Hast du mal einen zusatztab probiert?

Gruss Marcel


#3

Du meinst im backend ein separaten tab erstellen unter bei klick auf einen artikel? Ja das habe ich auch probiert ohne erfolg.


#4

#5

Ohne den wysiwyg-editor klappt es bestens. Ich habe 3 zusatzfelder in der oxarticles tabelle definiert (oxtab2, oxtab3 und oxtab4) und diese kann ich ohne probleme im backend (artikelstammdaten) ausgeben, bearbeiten und speichern.

<textarea class="editinput" maxlength="[{$edit->oxarticles__oxtab2->oxvalue}]" name="editval[oxarticles__oxtab2]" style="width:100%; height:150px; float:left;" [{$readonly}]>[{$edit->oxarticles__oxtab2->value}]</textarea>

So klappt es wie gesagt wunderbar aber ich hätte gerne das textarea-feld inkl. wysiwyg-editor :wink:


#6

So ich hab das jetzt anders gelöst. Man muss lediglich die article_main.tpl anpassen.Kein gefummel in den php dateien usw…

<div class="ddoe-wysiwyg" id="ddoew">
       <div class="ddoe-wysiwyg-editor">
		<textarea class="editinput" [{if $blTextEditorDisabled }]disabled [{/if}]id="editor_[oxarticles__oxtab2]" name="editval[oxarticles__oxtab2]" style="width: [{if $iEditorWidth}][{$iEditorWidth}][{else}]100%[{/if}]; height: [{if $iEditorheight}][{$iEditorheight}][{else}]300px[{/if}];">[{$edit->oxarticles__oxtab2->value}]</textarea>
	</div>
</div>

Das gilt jetzt für mein db-feld oxtab2 in der oxarticles tabelle. Das kann man jetzt ewig so fortführen …

Zusätzlich würde ich noch folgenden css befehl implementieren, ansonst kriegt man ein horizontalen scrollbalken im backend wenn der inhalt aus dem db-feld die länge vom eigentlichen editor überschreitet. Mit diesem css-befehl bricht der text dann ganz normal um.

.ddoe-wysiwyg { white-space:normal; }

Ich hoffe ich konnte damit jemandem helfen. :slight_smile:


Zusätzliche Editoren-Felder im Artikel in OXID 6 (mit WYSIWYG)
#7

@gajel: Deine Lösung halte ich als mehreren Gründen für supoptimal:

  1. Es werden Core-Dateien überschrieben, die nach jedem Update erneut angepasst werden müssen
  2. Es löst das Problem nur an dieser Stelle (auch wenn es hier laut Forumsbeitrag tatsächlich nur um diese Stelle gehen soll), aber es funktioniert nicht allgemein an den anderen Stellen im Shop wo der WYSIWYG-Editor zum Einsatz kommt. Man müsste in den Fällen auch diese Core-Admin-Templates (z.B. Hersteller, CMS usw.) per Hand anpassen.
  3. Es ignoriert die Shop-Funktionen “copyLongDesc” (\source\Application\views\admin\tpl\headitem.tpl), “_processLongDesc” (\vendor\oxid-esales\oxideshop-ce\source\Application\Controller\Admin\ArticleMain.php) und “generateTextEditor” (\source\Application\Controller\Admin\AdminDetailsController.php), die beim Laden und Speichern des Artikels für die Langbeschreibung zur Anwendung kommen.

Sauberer wäre es ein eigenes kleines Modul zu entwickeln.

Knackpunkt - zum aktuellen Zeitpunkt - ist es aber, dass wenn Du alles sauber entwickelt hast, wieder über Deinen Anfangs beschriebenen Fehler

“Im prinzip funktioniert das ganze auch. Das problem ist nur, das mir nun für jedes feld (oxlongdesc und oxtab2) jeweils 2 wysiwyg editoren angezeigt werden.”

stoßen wirst. Der Fehler liegt im “Summernote WYSIWYG Editor for OXID eShop 2.1.1”:

https://bugs.oxid-esales.com/view.php?id=6884

Wenn Du also mit Deinem kleinen Modul zum jetzigen Zeitpunkt einen anderen Editor verwenden würdest, würden Dir nur so viele Editoren angezeigt, wie Du Felder erweitert hast.


#8

@Mario_Lorenz

Es werden Core-Dateien überschrieben, die nach jedem Update erneut angepasst werden müssen

Das stimmt so nicht da ich ja im meinem letzten beitrag erwähnt habe:

So ich hab das jetzt anders gelöst. Man muss lediglich die article_main.tpl anpassen.

Aber ansonsten gebe ich dir natürlich recht das es mit einem kleinen modul sicher eine saubere lösung wäre und den von dir erwähnten bug schaue ich mir mal :slight_smile:


#9

@gajel: Gut, ich habe mich da vielleicht nicht präzise genug ausgedrückt: Aber auch die \source\Application\views\admin\tpl\article_main.tpl gehört gewissermaßen zu den Core-Templates des OXID-Backends.
Das Template und die anderen dortigen Templates werden definitiv bei jedem Update überschrieben.
Als Regel sollte für Dich gelten: alles was nicht in Deinem Vendor liegt (vendor\DeinVendor) und von dort während des composer-Updates automatisch in die (source…) kopiert wird, ist “überschreibtechnisch” tabu. Das rächt sich alles, wenn Du dort Hand anlegst.