[QUOTE=Marco Steinhäuser;10044]Hallo Markus,
na dann: Herzlich Willkommen! 
Und vielen Dank für den Bugreport, den ich eingetragen habe:
https://bugs.oxid-esales.com/view.php?id=1069
[/quote]
Danke.
Hier habe ich dies bereits als Modul gefixt. Der betreffende Bereich der Originalklasse hat schon zwei ID’s gehabt (#1104S und #1496C - auskommentierte Zeilen) finde ich aber nicht im Bugtracker.
1104S sagt mir ‘it’s not a bug, it’s a feature’
Einbinden als: oxarticle => datame/datame_modul_oxarticleVariantlistNoInherit
<?
class datame_modul_oxarticleVariantlistNoInherit extends datame_modul_oxarticleVariantlistNoInherit_parent{
/**
* Diese Methode ist eine 1:1 Kopie der Elternklasse (oxarticle::getSelectLists()).
* Hier wurde implementiert, dass die Slave-Artikel nicht die Selectlist des Masters (falls Slave keine Selectlist hat) erbt.
* => Siehe auskommentierte Zeilen #1104S ff.
*/
public function getSelectLists($sKeyPrefix = null)
{
//#1468C - more then one article in basket with different selectlist...
//optionall function parameter $sKeyPrefix added, used only in basket.php
$sKey = $this->getId();
if ( isset( $sKeyPrefix ) ) {
$sKey = $sKeyPrefix.'__'.$this->getId();
}
if ( self::$_aSelList[$sKey]) {
return self::$_aSelList[$sKey];
}
// all selectlists this article has
$oLists = oxNew( 'oxlist' );
$oLists->init('oxselectlist');
$sSLViewName = getViewName('oxselectlist');
$sSelect = "select $sSLViewName.* from oxobject2selectlist left join $sSLViewName on $sSLViewName.oxid=oxobject2selectlist.oxselnid ";
$sSelect .= 'where oxobject2selectlist.oxobjectid=\''.$this->getId().'\' ';
//sorting
$sSelect .= ' order by oxobject2selectlist.oxsort';
$oLists->selectString( $sSelect );
// //#1104S if this is variant ant it has no selectlists, trying with parent
// if ( $this->oxarticles__oxparentid->value && $oLists->count() == 0 ) {
// //#1496C - select fixed ( * => $sSLViewName.*)
// $sSelect = "select $sSLViewName.* from oxobject2selectlist left join $sSLViewName on $sSLViewName.oxid=oxobject2selectlist.oxselnid ";
// $sSelect .= "where oxobject2selectlist.oxobjectid='{$this->oxarticles__oxparentid->value}' ";
// //sorting
// $sSelect .= ' order by oxobject2selectlist.oxsort';
// $oLists->selectString( $sSelect);
// }
$dVat = 0;
if ( $this->getPrice() != null ) {
$dVat = $this->getPrice()->getVat();
}
$iCnt = 0;
self::$_aSelList[$sKey] = array();
foreach ( $oLists as $oSelectlist ) {
self::$_aSelList[$sKey][$iCnt] = $oSelectlist->getFieldList( $dVat );
self::$_aSelList[$sKey][$iCnt]['name'] = $oSelectlist->oxselectlist__oxtitle->value;
$iCnt++;
}
return self::$_aSelList[$sKey];
}
}
Wenn Du magst und des Englischen mächtig bist, kannst Du das künftig gern selbst machen.
Klar, kann ich… wenn ich das System ein wenig besser kenne
… oder ist das für euch der gleiche Aufwand falsche Bugs im Forum auszusortieren wie im Bugtracker?
Was sagt denn die Lagerverwaltung direkt am Artikel?
Admin-Lager:0
Frontend (Artikelliste): Rote Ampel
Forntend (Artikelinfo): Rote Ampel, “Dieser Artikel ist nicht auf Lager und muss erst nachbestellt werden.”
Bei negativen Einträgen ist das gleich. Die ‘Ampel’ funktioniert auch soweit.
Was ich komisch finde, ist dass ich ja unter
Admin->Stammdaten->Grundeinstellungen->Einstellungen->Lager->‘Negative Lagerbestände erlauben’
das Häkchen weggemacht habe und Kunden diesen Artikel trotzdem kaufen können.
Irgendwei sehe ich keinen Unterschied ob das Häkchen gesetzt ist oder nicht.
Sollte aber leicht nachvollziehbar sein, habe das gerade an einen Artikel ohne Slave-Produkte und Auswahlliste getestet.
Nach dem ich den Artikel bestelle ist der Lagerbestand im Admin negativ.
Den Feature Request habe ich erfasst.
Super.
Den mit den nicht Globalen Masterartikeln
oder das mit den Drupal ähnlichen Templatesystem… Ähnliches wird ja derzeit groß diskutiert.
Noch eine kleine Verbesserung…
Die Smarty-Klasse kann man ja auch erweitern und dementsprechend in der erweiterten Klasse ein paar Pluginorder hinzufügen.
So kann man die OXID spezifischen Plugins in einen eigenen Pluginordner machen. Sollte dann leichter sein, wenn man Smarty updated.
Hier meine Smarty-Klasse:
class Datame_class_smarty extends Smarty{
function __construct(){
parent::__construct();
}
function fetch($resource_name, $cache_id = null, $compile_id = null, $display = false){
$this->plugins_dir[]=$this->template_dir.'../plugins/';
$this->config_dir=$this->template_dir.'../'.oxLang::getInstance()->getLanguageAbbr().'/';
if(file_exists($this->config_dir.'lang.conf')){
$this->config_load('lang.conf',$resource_name);
}
// print_r($this);
return parent::fetch($resource_name, $cache_id, $compile_id, $display);
}
}
So hat mein Template ein eigenes Pluginverzeichnis und es wird automatisch eine Smarty-Sprachdatei geladen mit der Sektion der Ressource.
Ich denke, wenn man den Core ändert (als kleiner Dienstleister möchte ich das nicht), dann kann man recht komfortabel einiges in diese Klasse packen.
Nun ja, da wohl noch einige von xtc kommen werden wird wohl noch einiges an Smartyerfahrung hier ins Forum einfließen.
