Beispiel für die php-Datei (testview.php):

class testview extends oxAdminDetails
{
public function render(){
parent::render();
/**
Mein Script z.B.
$this->eigeneFunktion();
**/
return ‘testtemplate.tpl’;
}

private function eigeneFunktion(){
}
}

Ich weiß nicht ob es unbedingt notwendig ist, das die Klasse genauso heißt wie die Datei selbst, ich mache es immer so und es gab bisher keine Probleme dabei Wichtig ist nur, das eine render-Funktion existiert, die als Rückgabewert den Namen des Templates enthält und dass die parent::render() – Funktion aufgerufen wird.

Beispiel für die tpl-Datei (testtemplate.tpl):

[{include file="headitem.tpl" title="GENERAL_ADMIN_TITLE_1"|oxmultilangassign skip_onload="true"}]<h1>Testtemplate-View</h1>
Mein erstes Admin-Template
[{include file="bottomnaviitem.tpl" }]
[{include file="bottomitem.tpl"}]

Damit das View auch im Menü angezeigt wird, muss die manu.xml im “/oxid/admin/”-Ordner angepasst werden. Diese Datei ist folgendermaßen aufgebaut:

<OX>
<OXMENU id=”NAVIGATION_ESHOPADMIN”>
<MAINMENU id=”meineModule”>
<SUBMENU id=”Testview” cl=”testview”></SUBMENU>
</MAINMENU>
</OXMENU>
</OX>

Die Datei ist eigentlich Selbsterklärend, MAINMENU definiert die erste Ebene der Manustuktur und SUBMENU die Zweite. Das Attribut ‘id’ ist der Name, der in der Navigation angezeigt wird und ‘cl’ definiert, welches View aufgerufen wird.

Damit man aber nicht jeder einzelnen Variante ein Bild verpassen muss habe ich einen kleinen Bugfix geschreiben. Dieser nimmt einfach das Bild des Originalproduktes, wenn kein Bild für die Variante eingetragen ist.

Unter dem Ordner modules die Datei article_variant_bugfix.php anlegen mit folgendem Inhalt:

<?php

class article_variant_bugfix extends article_variant_bugfix_parent
{
public function getIconUrl($index=”){

$url = parent::getIconUrl($index);
if(!$url && $this->isVariant()) {
return $this->getParentArticle()->getIconUrl($index);
}
return $url;
}
}

?>

Anschließend braucht man nur noch im Backend unter Stammdaten/Grundeinstellungen/System/Module folgendes hinzufügen:

oxarticle => article_variant_bugfix

Falls einer von euch Verbesserungsvorschläge hat: immer her damit!

Nachtrag: vergesst was da oben steht, anscheinend muss oxpicsgenerated die Nummer des letzen Bildes enthalten (wenn kein bild #1  sondern nur #2 und #3 vorhanden, dann muss es nicht 2 sondern 3 enthalten!)

Bitte nutzt diesen SQL:
UPDATE oxarticles set oxpicsgenerated = 0;
UPDATE oxarticles set oxpicsgenerated = 1 WHERE OXPIC1 != ” AND OXPIC1 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 2 WHERE  OXPIC2 != ” AND OXPIC2 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 3 WHERE  OXPIC3 != ” AND OXPIC3 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 4 WHERE  OXPIC4 != ” AND OXPIC4 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 5 WHERE  OXPIC5 != ” AND OXPIC5 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 6 WHERE  OXPIC6 != ” AND OXPIC6 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 7 WHERE  OXPIC7 != ” AND OXPIC7 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 8 WHERE  OXPIC8 != ” AND OXPIC8 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 9 WHERE  OXPIC9 != ” AND OXPIC9 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 10 WHERE  OXPIC10 != ” AND OXPIC10 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 11 WHERE  OXPIC11 != ” AND OXPIC11 != ‘nopic.jpg’;
UPDATE oxarticles set oxpicsgenerated = 12 WHERE  OXPIC12 != ” AND OXPIC12 != ‘nopic.jpg’;

Falls ein Menü auch im Warenkorb erwünscht ist, einfach im Backend unter Stammdaten / Grundeinstellungen / System / Bestellungen den Haken aus “Einige Navigationselemente während des Bestellprozesses ausblenden„ rausnehmen.

Ich frag mich sowieso, warum das standardmäßig angehakt ist. Für den Benutzer find ich das unmöglich! Schließlich will ich ja evtl. nur mal in meinen Warenkorb gucken und dann gleich wieder weitershoppen und zwar nicht auf der Startseite.

Naja, auch OXID kann nicht an alles denken!

wiedermal bin ich auf etwas gestoßen, das gar nicht so einfach zu finden ist. Deshalb hier meine Lösung zu dem Problem, wenn man in Typo3 eine Seite hat, die erfordert, dass ein ganz bestimmter Menüpunkt aktiviert werden muss:

[PIDinRootline=12]
lib.mainMenu.12.alwaysActivePIDlist = 5, 17
[global]

-> die 12 ist die ID der Seite, unter der man sich befindet
-> hier kann natürlich auch anstatt die “Überseitenid” (‘PIDinRootline’) die aktuelle Seitenid benutz werden (‘globalVar = TSFE:id = 12′)

-> die 5 und die 17 sind die Seiten die als ‘Aktiv’ gelten sollen

Verbesserungsvorschläge werden natürlich immer gerne entgegengenommen!

Ich habe da mal was vorbereitet:

// Wichtige Klassen includieren (aktuelles Skript liegt im OXID-Root)
include(‘core/oxsupercfg.php’);
include(‘core/oxutilsfile.php’);
include(‘core/oxconfig.php’);

// Pfadangabe wird auch gebraucht!
function getShopBasePath()
{
return ‘/mein/pfad/zum/oxid/shop/’;
}
// custom functions file
require getShopBasePath() . ‘modules/functions.php’;

// Generic utility method file
require_once getShopBasePath() . ‘core/oxfunctions.php’;

// Configdaten ausgeben durch oxConfig-Klasse:
echo oxConfig::getInstance()->getConfigParam( ’sThumbnailsize’);    // 100*120
echo oxConfig::getInstance()->getConfigParam( ’sZoomImageSize’);    // 500*300
echo oxConfig::getInstance()->getConfigParam( ’sIconsize’);        // 55*100
print_r(oxConfig::getInstance()->getConfigParam( ‘aDetailImageSizes’)); // Array ( [oxpic1] => 300*200

Und wie immer:

Wenn jemand eine elegantere Lösung hat, immer her damit!

Habe das mal mit fast 3000 Kategorien getestet und es würde eine Seite die sonst in ca. 2 Sekunden aufgebaut ist schon fast 5 Sekunden brauchen. Sowas kann man doch keinem Benutzer zumuten!
Deshalb hab ich mich durch das Klassengewirr begeben und bin auf eine  jetzt ganz nette Lösung gestoßen.

Einfach ein Modul erstellen! Also eine Klasse unter  module/new_fields_for_category.php anlgegen, die die Methode load (ursprünglich aus oxbase.php) überschreibt.

class new_fields_for_category extends oxcategory {
public function load($sOXID)
{
//getting at least one field before lazy loading the object
$this->_addField(‘new_field_1′, 0);
$this->_addField(‘new_field_2′, 0);
return parent::load($sOXID);
}
}

Tja, dann nur noch ins Backend einloggen und unter ‘Stammdaten/Grundeinstellungen/System/Module’ folgendes eintragen:

‘oxcategory => new_fields_for_category’

und schon kann man im Template darauf zugreifen:

[{$actCategory->oxcategories__new_field_1->rawValue}]

Falls jemand eine schönere Lösung hat, dann immer her damit

$(“#deinDiv”).keyup (function(event) {
if (event.keyCode == 13) {
Login.BtnLogin_OnClick();
}
});

1. Den Div mit Ajax ansprechen

2. Die Tastatureingabe abfragen

3. Beim Drücken der Taste “Enter” die Login-Funktion aufrufen -> fertig

$XML->product-results; //<- geht nicht!!

Auch das teil in ” zu Packen kann man vergessen.

$XML->’product-results’; //<- auch nix!

Bis ich dann nach nem halben Tag rumärgern und unzähligen anderen Versuchen auf die Idee gekommen bin, den Namen als string in ne Variable zu packen und diese dann so anzurpechen:

$prod_result = ‘product-results’;

$XML->$prod_result;

Damit hat es dann endlich funktioniert.

Wenn irrgentwer ne Elegantere lösung hat, gerne als Kommentar hinterlassen

Nachtrag:

$XML->{‘prod_result’}; //<- funktioniert auch

Jedenfalls hab ich mir gedacht könnte mein darauf erstelltes Skript evtl. für den Ein oder Anderen ein wenig Zeit ersparen:

// jedes Zeichen einzeln
$hex_array = str_split ($hex_number);
// jedes Zeichen mithilfe von hexdec() in Dezimal umwandeln
$dec_array = array_map(‘hexdec’,$hex_array);
// Summe bilden
$dec_sum = array_sum($dec_array);
// wieder in Hexadezimal umwandeln = Prüfsumme
$hex_sum = dechex($dec_sum);

Wenn jemand eine einfachere Art kennt eine solche Prüfsumme zu bilden, so möge er ein Kommentar ablassen