Hilfestellung bei zusätzlichem Menüpunkt im Adminbereich

arnedrews · October 14, 2012, 8:11pm

Moin,

Ich habe darüber zwar schon einiges gefunden im Netz und auch hier im Forum, aber so richtig hab ich das noch nicht begriffen, wenn ich ehrlich bin.

Also, ich will gar kein komplettes Modul dazubasteln, sondern einfach nur ein kleines Menü im Adminbereich.
Auch wenn es nicht der eleganteste Weg ist, habe ich das dennoch direkt in der [I]admin/menu.xml[/I] gemacht, in dem ich einfach einen zweiten OXMENU-tree rangehängt habe:


<?xml version="1.0" encoding="ISO-8859-15"?>
<OX>
    <OXMENU id="NAVIGATION_ESHOPADMIN">
        [ ... spare ich mir hier mal aus Platzgründen ... ]
    </OXMENU>

    <OXMENU id="MEINE_TOOLS">
        <MAINMENU id="meine-tools">
        	<SUBMENU id="meinetools-item1" cl="meinetools_file" rights="malladmin" />
        </MAINMENU>
    </OXMENU>
    
</OX>

Soweit so gut, alles wird angezeigt. Jedoch weiß ich nicht, wo ich nun z.B. den Anzeigenamen für “MEINE_TOOLS” angeben muß, geschweige denn, warum er die Datei [I]meinetools-tool1.php[/I] nicht aufruft?!
Diese habe ich direkt im Verzeichnis [I]admin[/I] abgelegt.

Ich denke, daß es relativ leicht ist und ich nur die richtige Datei bzw. DB-Tabelle nicht gefunden habe…
Wäre nett, wenn mir jemand kurz auf die Sprünge hilft.
Danke!

[B]EDIT[/B]
Habe es gefunden, war ja doch nicht sooo schwer…

Für Leute mit ähnlicher Frage:

Die entsprechende “Übersetzung” gehört in die [I]out/admin/de/lang.php[/I].
Dort einfach das Array [I]$aLang[/I] erweitern:


$aLang = array(
    // Die Standardeinträge lasse ich mal weg...

    'MEINE_TOOLS' => 'Meine Toolbar',
    'meine-tools' => 'Toolgruppenname',
    'meinetools-item1' => 'Toolname 1'
);

Soll das Toll auch für andere Sprachen übersetzt werden, müßt Ihr das natürlich auch in den Language-Dateien der entsprechenden Sprache eintragen!

Ich habe eine Datei entsprechend im Verzeichnis [I]admin[/I] angelegt:


class Meinetools_File extends oxAdminView {

    protected $_sThisTemplate = 'meinetools-file.tpl';

}

Der Klassenname entspricht der Angabe des [I]cl[/I]-Attribut vom entsprechenden Submenu mit führenden Großbuchstaben je Wort.
Die Template-Datei [I]meinetools-file.tpl[/I] kann beliebig benannt werden und muß im Verzeichnis [I]out/admin/tpl[/I] vorhanden sein.
Darin könnt ihr dann alles machen, was Ihr vor habt…

Viel Spaß!

marco.steinhaeuser · October 15, 2012, 11:07am

Danke für die Lösung, Arne

Gruß

arnedrews · January 5, 2013, 11:55pm

Moin,

Ich wollte hier für die es mal benötigen erklären, wie das oben erwähnte auch in Version 4.7 der OXID CommunityEdition funktioniert!

[I][U]WARNUNG:[/U] Ich verwende für dieses Beispiel echten Code, den ich einsetze, um über das Admin-Panel den Cache komplett leeren zu können! Benutzung auf eigene Gefahr![/I]

[B][U]Menü bearbeiten[/U][/B]
Die XML-Datei findet ihr jetzt unter [B]application/views/admin/menu.xml[/B].
Die Anpassungen macht ihr genau wie oben beschrieben, daran ändert sich erstmal nichts!


<?xml version="1.0" encoding="ISO-8859-15"?>
<OX>
    <OXMENU id="NAVIGATION_ESHOPADMIN">
        <!-- den Standardkram lasse ich hier aus Platzgründen wieder weg -->
    </OXMENU>

    <OXMENU id="ADDITIONAL_TOOLS">
        <MAINMENU id="additional-tools">
        	<SUBMENU id="clear-cache" cl="clear_cache" rights="malladmin" />
        </MAINMENU>
    </OXMENU>
</OX>

Die Übersetzung erfolgt in [B]application/views/admin/de/lang.php[/B].


$aLang = array(

    // einfach dieses Array am Ende erweitern

    'ADDITIONAL_TOOLS' => 'Zusatz Tools',
    'additional-tools' => 'Administration',
    'clear-cache' => 'Clear Cache'

);

[B][U]Die Controller-Datei[/U][/B]
Die Angabe des [B][I]cl[/I][/B]-Attributs in der [B]menu.xml[/B] definiert weiterhin die aufzurufende PHP-Datei, jedoch liegt die nun im Verzeichnis [B]application/controllers/admin/[/B].


// Dateiname: clear-cache.php
class Clear_Cache extends oxAdminView {


    public function render() {
        
        parent::render();

        $sCurrentAdminShop = oxSession::getVar( 'currentadminshop' );

        if (!$sCurrentAdminShop) {
            
            $sCurrentAdminShop = ( oxSession::getVar('malladmin') )?
                    'oxbaseshop':
                    oxSession::getVar( 'actshop');

        }

        $this->_aViewData['currentadminshop'] = $sCurrentAdminShop;
        oxSession::setVar( 'currentadminshop', $sCurrentAdminShop );

        return 'clear-cache.tpl'; // <-- Unsere Template-Datei!
 
    }


}

Beim Klassennamen wie gewohnt darauf achten, den Dateinamen mit UpperCase für jeden Anfangsbuchstaben zu verwenden!

[B][U]Die Template-Datei[/U][/B]
Die entsprechende Template-Datei müßt ihr unter [B]application/views/admin/tpl/[/B] anlegen:


[{php}]


$cacheFolder = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'tmp' . DIRECTORY_SEPARATOR;
$cacheFolderSmarty = $cacheFolder . 'smarty' . DIRECTORY_SEPARATOR;


$fileRemoveCommands = array(
        'rm -f ' . $cacheFolder . '*.txt',
        'rm -f ' . $cacheFolderSmarty . '*'
    );


foreach ( $fileRemoveCommands as $command ) {

	echo '<h4 class="clear-cache-command">Sende Befehl: ' . $command . '</h4>';
	system( $command );
        
}


[{/php}]

Wer in den Templates PHP-Code verwendet muß natürlich die Option “PHP-Code in Template-Dateien ausführen” im Shop aktivieren!

Ich hoffe das kann mal jemand brauchen, viel Erfolg!

jkrug · January 6, 2013, 11:08pm

Hallo Arne,

vielen Dank für den Code. Kennst du die fertigen Module dafür?
Was ich nicht verstanden habe: Warum trennst du eigentlich sauber in Controller und View (Template) und lagerst schlussendlich die Funktion aber doch in’s Template aus?

Viele Grüße

Joscha

arnedrews · January 6, 2013, 11:58pm

Hi Joscha,

Ja, die Module dafür kenne ich (zumindest zwei davon, falls es noch mehr gibt).
Das ist auch nicht für den Produktiveinsatz gedacht. Ich verwende das nur für die Erstellung eigener Templates aufgrund individueller Kundenwünsche. Da nervt es einfach, immer per Hand die Verzeichnisse leeren zu müssen.
Naja, und im Produktiveinsatz sollte man den Smarty-Cache eh nicht so häufig leeren

Ich habe nur gedacht, daß es für Einsteiger etwas verständlicher ist, wenn Sie die Code-Zusammenhänge sehen, daher habe ich das als kleines Beispiel genommen.

Du hast natürlich recht, die Funktion an sich gehört natürlich in den Controller, das macht definitiv mehr Sinn! Danke für den Hinweis!

Aber das sollte hier auch nur als Leitfaden dienen, weil ich häufiger schon gesehen habe, daß einige Probleme haben, mit dem Zufügen eigener Menü-Items.

udel · January 16, 2013, 3:32pm

Ab Version 4.7/5.0 gibt es ja den Ordner translations für die Sprachdateien. Allerdings bekomme ich da nicht die Übersetzungen für den Adminbereich geladen. Mache ich was falsch, oder müssen die Adminübersetzungen weiterhin in out/admin/de gepackt werden - und wenn ja, warum?

vanilla_thunder · January 16, 2013, 3:53pm

lies den 3. Beitrag nochmal. Ist sogar fett markiert.

Hebsacker · January 16, 2013, 4:03pm

/application/views/admin/{locale} ?

Die Pfade kann man auch unter translate.oxidforge.org nachsehen (Login mit guest|guest)

udel · January 16, 2013, 4:43pm

[QUOTE=vanilla thunder;113740]lies den 3. Beitrag nochmal. Ist sogar fett markiert.[/QUOTE]

siehst Du, da liegt doch das Problem. Ich packe meine Übersetzung nämlich in
modules/me/out/admin/{locale} und sie wird trotzdem geladen. Was ich nicht versehe ist, warum man in 4.7/5.0 einen extra ordner für translations anlegt, aber darin dann nicht die Übersetzungen für den Adminbereich ausliest. Ist doch unsinnig, oder etwa nicht? Daher meine Frage - ob es einer bestimmten Struktur/Benennung bedarf, damit auch aus dem Ordner “translations” geladen wird.

vanilla_thunder · January 16, 2013, 6:23pm

du meinst, du willst innerhalb deines Modulordners einen Ordner “translations” anlegen? Keine Ahnung ob das Sinn macht/funktioniert. Im Shop im out/translations sind ja frontend Übersetzungen. Also gehören da höchstens auch die Frontend Übersetzungen rein

der alte Pfad wurde wohl beibehalten um die Abwärtskompatibilität zu gewährleisten.

marco.steinhaeuser · January 16, 2013, 7:55pm

Hi,

unsinnig ist das gewiss nicht, sonst hätten wir’s nicht so gemacht Pfeif Dir das hier mal rein:

Gruß

arnedrews · January 17, 2013, 8:37am

Die Trennung von Front- und Backend ist Bestandteil der Grundlogik an sich. Dazu gehören dann sinvollerweise auch die Translations. Halte Dich an #3 und berücksichtige evtl. den Hinweis von [I]Josha[/I] aus #4, dann klappt das

udel · January 17, 2013, 9:23am

[QUOTE=vanilla thunder;113761]du meinst, du willst innerhalb deines Modulordners einen Ordner “translations” anlegen? Keine Ahnung ob das Sinn macht/funktioniert. Im Shop im out/translations sind ja frontend Übersetzungen. Also gehören da höchstens auch die Frontend Übersetzungen rein

der alte Pfad wurde wohl beibehalten um die Abwärtskompatibilität zu gewährleisten.[/QUOTE]

Ja klar funktioniert das - also ab 4.7/5.0. Nur halt für den Admin nicht. Ich hab mir gestern Abend noch mal den Quelltext angesehen (CE oxLang.php Z.857).

$sFullPath .= ($blForAdmin) ? '/views/admin/' : '/translations/';

Da wird ja ganz klar zwischen Front- und Backend unterschieden. Die Logik entzieht sich mir. Translation ist Translation nach meinem Verständnis. Ist zwar kein Akt, wenn man es weiß, aber logisch erscheint mir das nicht. Hätte admin nach ‘translations/admin’ gepackt.

arnedrews · January 17, 2013, 10:59am

Ich persönlich finde die Trennung absolut logisch. Mache ich in meinen Systemen nicht anders. Admin ist eben immer etwas abgekoppelt vom User-System, das macht schon Sinn.