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

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ß?!

Hast du mal einen zusatztab probiert?

Gruss Marcel

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

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:

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:

1 Like

@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.

@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:

@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.

Hier ein link um das in ein Modul zu bringen

wenn ihr hier die Datei “unser_zusatz_feld_fuer_admin_article_main.tpl”
mit den template änderungen von @gajel anpasst, dann habt ihr das ordentlich und der WYSIWYG editor dupliziert sich nicht und alles ist update sicher in einem eigenständigem Modul hinterlegt.

unser_zusatz_feld_fuer_admin_article_main.tpl

[{* Den ursprünglichen Block übernehmen *}]
[{$smarty.block.parent}]

[{* Wir hängen unsere Änderungen an *}]
<br /><br />
<b>[{oxmultilang ident="SHOP_MODULE_GGPARENTARTIKELDESC_TITLE"}]</b><br/>

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

Ich habe das auch getestet und ein 2. RTE Feld mit einem custom DB-Feld integriert. Funktioniert soweit auch alles, beide RTEs werden im Artikel im Reiter Stamm angezeigt, aber einige RTE-Funktionen wie z.B. Stil, Tabelle, Mehr Farben Icons gehen nicht. Bzw. alle Dropdown Menüs gehen nicht. Mit nur einem RTE auf der Seite geht das. Das liegt doch mit Sicherheit an der doppelten ID oder was meint ihr?
class=“ddoe-wysiwyg” id=“ddoew”

Funktioniert bei euch alles einwandfrei?

Danke vorab Gruß Armin

In meinem vorherigem Post habe ich beschrieben wie es eingebaut werden muss, damit es ordnungsgemäß und updatesicher funktioniert.
Einfach dem Tutorial in meinem Link folgen, und dieses mit den template änderungen von @gajel updaten, die ich unten noch einmal gepostet habe. Dann gehts.