Hersteller-Filter ohne Attribute

[Modul-Link gelöscht]

Ein erstes und herzliches Hallo ans Forum! :slight_smile:

Ich habe kürzlich auch beschlossen, auf Oxid umzusteigen (als Entwickler). Macht bisher alles einen prima Eindruck und ein deutschsprachiges gutes Forum ist auch mal ganz entspannend! :wink:

Demo ist bereits off- und online installiert (+patch_4.4.4), erste Layout- und Funktionsänderungen wurden erfolgreich vorgenommen (ist ja auch nicht wirklich schwierig)…

Nun aber zu einem der ersten größeren Hürden:
Wie stellt man es mit möglichst wenig Aufwand am besten an, oberhalb der Kategorie-Ansichten einen simplen Filter nach Hersteller einzublenden? Und zwar (fast) genauso, als wenn ich den Weg über Attribute gehe, nur dass die Datenpflege damit viel zu umständlich wäre (erst die ganzen Attribut-Zuordnungen an Artikel UND Kategorien und dann noch mal alle entsprechenden Values und alles in Extra-Popups). Außerdem wären die Hersteller bei der Attribut-Lösung ja wieder NICHT mehr in der Suche verfügbar. Da dreht man sich also scheinbar im Kreis.

Man könnte evtl. beides doppelt pflegen, also als Hersteller UND als Attribut, aber das macht ja noch mehr Arbeit, oder wäre evtl. eine Idee für ein Modul, welches dass automatisiert (zumindest die Attribut-Befüllung).

Jedenfalls klingt es nach einer Kleinigkeit, aber ich bin mir nicht sicher, ob es nur mit Template-Änderungen möglich ist, den Filter aus dem Suchfeld in die Listview zu kopieren, und/oder wie man da sonst ansetzt.

Wäre klasse, wenn jemand ein paar Tipps parat hätte zu dem Thema, habe sonst leider nichts brauchbares finden können.

Edit:
na, toll, gleich der erste Post landet im falschen Forum… :frowning:
sorry, und kann den bitte gleich mal jemand ins deutsche Forum verschieben?

Hm, schade, dass niemand etwas dazu zu sagen weiß, aber wie sagt man so schön: Selbst ist der Mann (+Frau natürlich auch!)… :wink:

Also hier mal meine bisherige Lösung, die zwar sauber funzt aber irgendwie umständlich wirkt. Ich bin mir halt beim ersten Versuch ein Oxid-Modul zu schreiben überhaupt nicht sicher, welche Klassen man am besten erweitert. Es scheint da ja oft mehrere Möglichkeiten zu geben. Und ist es überhaupt korrekt, für ein Modul mehrere Dateien einbinden zu müssen, oder sollte man immer versuchen, alles in eine zu quetschen (wahrscheinlich oft gar nicht möglich, oder)?

[B]1.: alist => showmanu/manulist[/B]

<?php

class manulist extends manulist_parent
{
    public function execmanufilter()
    {
        // store this into session
        $aFilter = oxConfig::getParameter('manufilter');
        $sActCat = oxConfig::getParameter('cnid');
        $aSessionFilter = oxSession::getVar('session_manufilter');
        $aSessionFilter[$sActCat] = $aFilter;
        oxSession::setVar('session_manufilter', $aSessionFilter);
    }

    public function getManuCatlist() {
    	$ret = array();
    	$sActCat = oxConfig::getParameter('cnid');
    	$sLangAdd = oxLang::getInstance()->getLanguageTag();
        $sViewName  = 'oxmanufacturers';

        if (!$sActCat) return $ret;

        $oDb = oxDb::getDb(true);
        $sSelect  = "SELECT oxid,oxtitle,(SELECT COUNT(*) FROM oxarticles AS a,oxobject2category AS oc WHERE m.oxid=a.oxmanufacturerid AND a.oxactive=1 AND a.oxid=oc.oxobjectid AND oc.oxcatnid=".$oDb->quote($sActCat).") AS artcnt ";
        $sSelect .= "FROM {$sViewName} AS m WHERE m.oxactive=1 AND m.oxtitle{$sLangAdd}!='' HAVING artcnt>0 ORDER BY m.oxtitle{$sLangAdd}";

        $rs = $oDb->Execute($sSelect);

	if ($rs != false && $rs->recordCount() > 0) {
            while (!$rs->EOF) {
                $ret[] = $rs->fields;
                $rs->moveNext();
            }
        }

	return $ret;
    }
}

[B]2.: oxarticlelist => showmanu/manuarts[/B]

<?php

class manuarts extends manuarts_parent
{
    protected function _getCategorySelect( $sFields, $sCatId, $aSessionFilter )
    {
        $sArticleTable = getViewName( 'oxarticles' );
        $sO2CView      = getViewName( 'oxobject2category' );

        // ----------------------------------
        // sorting
        $sSorting = '';
        if ( $this->_sCustomSorting ) {
            $sSorting = " {$this->_sCustomSorting} , ";
        }

        // ----------------------------------
        // attribute filtering ?
        $sFilterSql = '';
        if ( $aSessionFilter && isset( $aSessionFilter[$sCatId] ) ) {
            $sFilterSql = $this->_getFilterSql($sCatId, $aSessionFilter[$sCatId]);
        }

        $oDb = oxDb::getDb();

        // ----------------------------------
        // manufacturer filtering ?
        $aFilter = oxSession::getVar('session_manufilter');
        if ($aFilter && $aFilter[$sCatId]) {
            $sFilterSql .= " AND $sArticleTable.oxmanufacturerid=".$oDb->quote($aFilter[$sCatId]);
        }

        $sSelect = "SELECT $sFields FROM $sO2CView as oc left join $sArticleTable
                    ON $sArticleTable.oxid = oc.oxobjectid
                    WHERE ".$this->getBaseObject()->getSqlActiveSnippet()." and $sArticleTable.oxparentid = ''
                    and oc.oxcatnid = ".$oDb->quote($sCatId)." $sFilterSql GROUP BY oc.oxcatnid, oc.oxobjectid ORDER BY $sSorting oc.oxpos, oc.oxobjectid ";

        return $sSelect;
    }
}

[B]3.: oxcmp_utils => showmanu/manuview[/B]

<?php

class manuview extends manuview_parent
{
    public function render() {
    	$aFilter = oxSession::getVar('session_manufilter');
    	$sActCat = oxConfig::getParameter('cnid');
    		
    	$manufilter = '';
    	if ($aFilter && $aFilter[$sActCat])
    	    $manufilter = $aFilter[$sActCat];

        $this->_oParent->addTplParam(
            'manufilter', $manufilter
        );

        parent::render();
    }
}

[B]4.:[/B] So, und wenn man das alles hat, kann man folgendes ins Template ([B]z.b. /out/custom/tpl/list.tpl[/B]) basteln (ich habe es oberhalb [{if $oView->getAttributes() }]


	[{if $oView->getListType()!='manufacturer' && $oView->getManuCatlist() && $pageNavigation->iArtCnt}]
	    <form method="post" action="[{ $oViewConf->getSelfActionLink() }]" name="_manulist" id="_manulist">
            <div class="catfilter">
                [{ $oViewConf->getHiddenSid() }]
                [{ $oViewConf->getNavFormParams() }]
                <input type="hidden" name="cl" value="[{ $oViewConf->getActiveClassName() }]">
                <input type="hidden" name="tpl" value="[{$tpl}]">
                <input type="hidden" name="fnc" value="execmanufilter">

                <table cellpadding="0" cellspacing="0">
                    <tr>
                        <td>
                            <label>[{ oxmultilang ident="DETAILS_MANUFACTURER" }]</label>
                        </td>
                        <td><select name="manufilter" onchange="oxid.form.send('_manulist');">
                            <option value=""> [{ oxmultilang ident="INC_SEARCHLEFTITEM_ALLMANUFACTURERS" }] </option>
                            [{foreach from=$oView->getManuCatlist() item=oManu}]
                            <option value="[{$oManu.oxid}]"[{if $manufilter == $oManu.oxid}] selected[{/if}]>[{ $oManu.oxtitle }] ([{ $oManu.artcnt }])</option>
                            [{/foreach}]
                        </select></td>
                    </tr>
                </table>
            </div>
            </form>
        [{/if}]

        [{if $oView->getAttributes() }]
            ...
        [{/if}]

[B]Ergebnis:[/B]
Es wird auf allen Kategorie-Listen (nicht Suche und nicht Herstellerlisten) nun unterhalb des Kategorienamens eine Hersteller-selectbox angezeigt, die nur die Hersteller der betreffenden Kategorie beinhaltet, soweit Artikel mit denen verknüpft sind (mit korrekter Anzahl dahinter). Der Filter wird genauso wie die Attribute pro Kategorie in der Session gespeichert (wobei die Frage bleibt, ob das immer sinnvoll ist) und funzt auch sonst sehr ähnlich.

Ich weiß (noch) nicht, ob dies eine gute Lösung ist, aber ich halte das Ergebnis für eine Standard-Funktion, die ruhig fest im Shop eingebaut sein dürfte (optional nutzbar), von daher bin ich sehr gespannt auf jegliche Resonanz, am liebsten seitens von Entwicklern! :smiley:

Achja, und nebenbei habe ich auch den Hersteller-Filter der Suche etwas optimiert, sodass dort nur die Hersteller angeboten werden, zu denen es auch wirklich Artikel gibt (analog zur Adminoption, auch ungenutzte Kategorien ausblenden zu können):

5.: oxmanufacturerlist => showmanu/manucats

<?php

class manucats extends manucats_parent
{
    public function loadManufacturerList()
    {
        $sLangAdd = oxLang::getInstance()->getLanguageTag();
        $oBaseObject = $this->getBaseObject();

        $sFieldList = $oBaseObject->getSelectFields();
        $sViewName  = $oBaseObject->getViewName();
        $this->getBaseObject()->setShowArticleCnt( $this->_blShowManufacturerArticleCnt );

        $sWhere = '';
        if ( !$this->isAdmin() ) {
            $sWhere  = $oBaseObject->getSqlActiveSnippet();
            $sWhere  = $sWhere?" where $sWhere and ":' where ';
            $sWhere .= "{$sViewName}.oxtitle{$sLangAdd} != '' ";
            $sWhere .= "AND {$sViewName}.oxid IN (SELECT oxmanufacturerid FROM oxarticles WHERE oxactive=1)";
        }

        $sSelect = "select {$sFieldList} from {$sViewName} {$sWhere} order by {$sViewName}.oxtitle{$sLangAdd}";

        $this->selectString( $sSelect );
    }
}

So sagt ehrlich: bin ich auf dem richtigen Weg, habe ich evtl. sogar zuviel verraten, könnte/sollte ich das als offizielles Modul anbieten oder ist es alles totaler Quatsch???

Grüße

Hi Mitmacher,

hab das Modul jetzt mal getestet und eingbaut, ich finds super, dankeschön dafür, wüsste jetzt auf anhieb auch nicht, was man hier noch besser machen könnte, ist mit Sicherheit der richtige Weg. Avenger oder MBa könnte Dir hier garantiert mehr erzählen, da ich aus der Frontend Ecke komme :slight_smile:

Allerbeste Grüße vom Chris

[QUOTE=Mitmacher;42933]Ein erstes und herzliches Hallo ans Forum! :slight_smile:

Ich habe kürzlich auch beschlossen, auf Oxid umzusteigen (als Entwickler). Macht bisher alles einen prima Eindruck und ein deutschsprachiges gutes Forum ist auch mal ganz entspannend! :wink:

Demo ist bereits off- und online installiert (+patch_4.4.4), erste Layout- und Funktionsänderungen wurden erfolgreich vorgenommen (ist ja auch nicht wirklich schwierig)…

Nun aber zu einem der ersten größeren Hürden:
Wie stellt man es mit möglichst wenig Aufwand am besten an, oberhalb der Kategorie-Ansichten einen simplen Filter nach Hersteller einzublenden? Und zwar (fast) genauso, als wenn ich den Weg über Attribute gehe, nur dass die Datenpflege damit viel zu umständlich wäre (erst die ganzen Attribut-Zuordnungen an Artikel UND Kategorien und dann noch mal alle entsprechenden Values und alles in Extra-Popups). Außerdem wären die Hersteller bei der Attribut-Lösung ja wieder NICHT mehr in der Suche verfügbar. Da dreht man sich also scheinbar im Kreis.

Man könnte evtl. beides doppelt pflegen, also als Hersteller UND als Attribut, aber das macht ja noch mehr Arbeit, oder wäre evtl. eine Idee für ein Modul, welches dass automatisiert (zumindest die Attribut-Befüllung).

Jedenfalls klingt es nach einer Kleinigkeit, aber ich bin mir nicht sicher, ob es nur mit Template-Änderungen möglich ist, den Filter aus dem Suchfeld in die Listview zu kopieren, und/oder wie man da sonst ansetzt.

Wäre klasse, wenn jemand ein paar Tipps parat hätte zu dem Thema, habe sonst leider nichts brauchbares finden können.

Edit:
na, toll, gleich der erste Post landet im falschen Forum… :frowning:
sorry, und kann den bitte gleich mal jemand ins deutsche Forum verschieben?[/QUOTE]
Den Hersteller Filter hast Du im Prinzip doch schon in der Suchbox…

Müsste man verlagern…

Öhm, ja, im ersten Überschwang hab ich mich wohl etwas weit aus dem Fenster gelehnt. :smiley:
Von wg. Basisfunktion und so, da werden die Ansichten wohl sehr unterschiedlich sein. Und vor allem hast Du natürlich Recht Avenger, es geht prinzipiell schon per Suche. Aber halt nur mit zwei “Einschränkungen”:

  1. Muss man erstmal drauf kommen, dass man auch ohne Suchbegriff suchen kann (ist zumindest selten so, und habe ich zuerst nicht erwartet und folglich nicht ausprobiert).
  2. Sind beim Suchen dann Kombinationen auswählbar (Kategorie + Hersteller), die zu keinem Ergebnis führen, was zumindest nicht so schön ist.

Also ich denke mal, mein Modul ist nicht lebenswichtig, aber für mich gilt halt gerade: der Kunde ist König, und der will es nunmal so haben, d.h. noch etwas anders mit einzelnen Hersteller-Buttons statt der <select>-Box, aber das ist bereits getestet und auch kein Problem mehr, wenn man die nötigen Parameter per GET zusammenbastelt. Und so ist es einfach ein Kleinwenig runder, gerade wenn man viel mit gleichen Artikeln von verschiedenen Herstellern hantieren muss, und hauptsächlich die Kategorien-Navigation nutzt. Ist sicherlich auch branchenabhängig…

So, aber mir ging es auch darum, einen interessanten und (halbwegs) sinnvollen Einstieg in die oxid-Programmierung zu bekommen, da ich bisher fast nur eigene Shop-Systeme entwickelt habe (und mal XTC), und dieses nie derart konsequent objekt-orientiert. Da gibt es noch viel Neuland zu entdecken für mich. :slight_smile:

Z.b. stellt sich die Frage, wie man es schafft, eigene MySQL-Statement cachen zu lassen von oxid/smarty? Ich glaube nämlich, mein Modul läuft am Cache vorbei :frowning:
(obwohl ich ja execute() nutze, aber wo zum Teufel ist diese Funktion definiert, und was macht die alles, außer mysql_query() absetzen? hm…)

[QUOTE=Mitmacher;43464]Öhm, ja, im ersten Überschwang hab ich mich wohl etwas weit aus dem Fenster gelehnt. :smiley:
Von wg. Basisfunktion und so, da werden die Ansichten wohl sehr unterschiedlich sein. Und vor allem hast Du natürlich Recht Avenger, es geht prinzipiell schon per Suche. Aber halt nur mit zwei “Einschränkungen”:

  1. Muss man erstmal drauf kommen, dass man auch ohne Suchbegriff suchen kann (ist zumindest selten so, und habe ich zuerst nicht erwartet und folglich nicht ausprobiert).
  2. Sind beim Suchen dann Kombinationen auswählbar (Kategorie + Hersteller), die zu keinem Ergebnis führen, was zumindest nicht so schön ist.

Also ich denke mal, mein Modul ist nicht lebenswichtig, aber für mich gilt halt gerade: der Kunde ist König, und der will es nunmal so haben, d.h. noch etwas anders mit einzelnen Hersteller-Buttons statt der <select>-Box, aber das ist bereits getestet und auch kein Problem mehr, wenn man die nötigen Parameter per GET zusammenbastelt. Und so ist es einfach ein Kleinwenig runder, gerade wenn man viel mit gleichen Artikeln von verschiedenen Herstellern hantieren muss, und hauptsächlich die Kategorien-Navigation nutzt. Ist sicherlich auch branchenabhängig…

So, aber mir ging es auch darum, einen interessanten und (halbwegs) sinnvollen Einstieg in die oxid-Programmierung zu bekommen, da ich bisher fast nur eigene Shop-Systeme entwickelt habe (und mal XTC), und dieses nie derart konsequent objekt-orientiert. Da gibt es noch viel Neuland zu entdecken für mich. :slight_smile:

Z.b. stellt sich die Frage, wie man es schafft, eigene MySQL-Statement cachen zu lassen von oxid/smarty? Ich glaube nämlich, mein Modul läuft am Cache vorbei :frowning:
(obwohl ich ja execute() nutze, aber wo zum Teufel ist diese Funktion definiert, und was macht die alles, außer mysql_query() absetzen? hm…)[/QUOTE]
Du kannst diesen Teil ja aus der Suchbox entfernen, und anders plazieren, muss ja nicht da bleiben…

Du kannst diesen Teil ja aus der Suchbox entfernen, und anders plazieren, muss ja nicht da bleiben…

Schön + gut, aber dann werden ja zum einen immer noch alle Hersteller angezeigt (auch die ohne Artikel) und zum anderen nicht Kategorie-bezogen, und darum ging es mir ja gerade! :stuck_out_tongue:
Ich habe insgesamt schon versucht, das Rad nicht neu zu erfinden, sondern bei Bedarf nur optimieren zu können. Allerdings stieß ich noch auf einige Probleme, z.b. bei Aufruf per Stichwort. Da muss ich wohl noch nachbessern, bzw. weitere views mit denselben Funktionen erweitern (scheint wohl nicht anders zu gehen)…

Hi Mitmacher,

ich habe jetzt festgestellt, dass die Pagination mit dem Modul nicht mehr richtig funktioniert. Sprich, die Anzahl der Artikel nach der Hersteller Selektion wird nicht korrekt an den list_locator übergeben.

Hast Du hier ne Idee, wie man das entsprechend ummünzen kann?

Allerbeste Grüße und Dankeschön vom Chris

Sorry, etwas spät, aber dennoch:

Ja, es gibt für alles eine Lösung… :wink: Und diesmal habe ich das Ganze mal als “ordentliche” Extension gepackt und stelle es hier zur freien Verfügung. Damit sollte es dann eigentlich hinhauen an allen Stellen und auch mit Pagination. Viel Spaß damit! :smiley:

(edit: habe mal das veraltete zip hier gelöscht, der aktuelle Download-Link steht im ersten Beitrag!)

Hi,

[QUOTE=Mitmacher;53037]Sorry, etwas spät, aber dennoch:

Ja, es gibt für alles eine Lösung… :wink: Und diesmal habe ich das Ganze mal als “ordentliche” Extension gepackt und stelle es hier zur freien Verfügung. Damit sollte es dann eigentlich hinhauen an allen Stellen und auch mit Pagination. Viel Spaß damit! :D[/QUOTE]

Kannst Du es noch in den eXchange stellen? Ich fürchte, hier im Forum geht es irgendwann unter…

Danke und Gruß

Hi Marco,

ja klar, da hast Du wahrscheinlich Recht, und ich war gestern auch schon in eXchange eingeloggt. Aber dann ging es plötzlich um Partner-Account und Boni-Konten, obwohl ich nur schnell was umsonst anbieten wollte, und da hatte ich auf die Schnelle gerade keinen Nerv drauf. :o Sollte ich beizeiten aber wohl mal nachholen, okay.

Was mich dabei aber immer noch brennend interessieren würde, ist, ob ich generell den richtigen Weg beschritten habe mit meinem Modul. Ist zwar nur ein kleines Randprojekt, aber trotzdem habe ich viel drüber nachgedacht, und bin der Meinung, es lässt sich kaum einfacher lösen(?). Allerdings musste ich ja so einige Funktionen überschreiben, und scheinbar bei JEDEM kommenden Shop-Update dann schauen, ob alles immer noch kompatibel ist. Das halte ich schon für recht mühsam, aber wird nicht anders funktionieren, richtig?

Also spare ich durch diese Modul-Überladung zwar die Notwendigkeit, ganze (und oft lange) Dateien vergleichen zu müssen, sondern brauche mich nur um einzelne Funktionen zu kümmern, gut. Aber auch die können recht lang/komplex sein, und ich muss evtl. nur eine Zeile ergänzen, was dann wieder im schlechten Verhältnis zueinander steht. Habe ich da evtl. generell etwas völlig falsch verstanden, oder muss man halt damit leben?

Kurzum: Wie stelle am einfachsten sicher, dass eigene Module auch in Zukunft immer kompatibel bleiben? Evtl. passt die Debatte aber besser in einen anderen Thread… :wink:

Beste Grüße!

Hi,

[QUOTE=Mitmacher;53079]ja klar, da hast Du wahrscheinlich Recht, und ich war gestern auch schon in eXchange eingeloggt. Aber dann ging es plötzlich um Partner-Account und Boni-Konten, obwohl ich nur schnell was umsonst anbieten wollte, und da hatte ich auf die Schnelle gerade keinen Nerv drauf. :o Sollte ich beizeiten aber wohl mal nachholen, okay.[/QUOTE]

Ja, gerade der erste Upload kann richtig Zeit kosten. Bitte einfach momentan ignorieren -> Augen zu und durch. Wir arbeiten derzeit an einer Lösung.

[QUOTE=Mitmacher;53079]Also spare ich durch diese Modul-Überladung zwar die Notwendigkeit, ganze (und oft lange) Dateien vergleichen zu müssen, sondern brauche mich nur um einzelne Funktionen zu kümmern, gut. Aber auch die können recht lang/komplex sein, und ich muss evtl. nur eine Zeile ergänzen, was dann wieder im schlechten Verhältnis zueinander steht. Habe ich da evtl. generell etwas völlig falsch verstanden, oder muss man halt damit leben?[/QUOTE]

Genau so ist es gedacht. Wenn Du in die Originaldateien, die mit den (momentan häufigen) Updates immer wieder überschrieben werden können, direkt änderst, kommst Du irgendwann an einen Punkt, wo ich selbst mit dem OSC schonmal war: Völliger Verlust der Updatefähigkeit, weil man gar nicht mehr nachvollziehen kann, wo überall Änderungen vorgenommen wurden. Dann braucht man nur noch zu warten, bis der Provider MySQL4 nicht mehr unterstützt und dann gibt’s einen grossen Knall.

[QUOTE=Mitmacher;53079]Kurzum: Wie stelle am einfachsten sicher, dass eigene Module auch in Zukunft immer kompatibel bleiben? Evtl. passt die Debatte aber besser in einen anderen Thread… :wink:
[/QUOTE]

Klar, die Module müssen immer nachgezogen werden, wenn z.B. Module als “deprecated” gekennzeichnet und ggf. rausgeschmissen werden. Kennst Du die Mailingliste für Entwickler? Das Core-Team ist angehalten, wichtige und modulrelevante Änderungen dort anzukündigen, sobald die Änderung eingebaut wird. Du kannst auch das SVN strapazieren :slight_smile:

Gruß

Hallo Mitmacher,

das Testen des Moduls mit aktuellen und zukünftigen Shop-Versionen wird sich wohl kaum vermeiden lassen, aber vielleicht lässt sich das Testen automatisieren, sprich Unit-Tests: Ob und wie das am besten zu bewerkstelligen ist, kann ich dir als PHP-Laie leider nicht sagen.

Aber zu deinem Modul… Klasse, genau zur rechten Zeit. Und noch eine kleine Frage:

Der Filter wird genauso wie die Attribute pro Kategorie in der Session gespeichert (wobei die Frage bleibt, ob das immer sinnvoll ist) und funzt auch sonst sehr ähnlich.

Wäre es möglich für dieses Verhalten ein Art Opt-out anzubieten? Ich hab letztens einen OXID-Shop mit ähnlichem Modul gesehen, dort wird an die Kategorie-URL (example.com/kategorie?mf=1) ein Parameter angehängt, der steuert ob der Filter zurückgesetzt wird oder nicht.

@Marco:

Ja, gerade der erste Upload kann richtig Zeit kosten. Bitte einfach momentan ignorieren -> Augen zu und durch. Wir arbeiten derzeit an einer Lösung.

Hehe, okay, ich weiß Bescheid :wink:

Genau so ist es gedacht. Wenn Du in die Originaldateien, die mit den (momentan häufigen) Updates immer wieder überschrieben werden können, direkt änderst, kommst Du irgendwann an einen Punkt, wo ich selbst mit dem OSC schonmal war: Völliger Verlust der Updatefähigkeit, weil man gar nicht mehr nachvollziehen kann, wo überall Änderungen vorgenommen wurden. Dann braucht man nur noch zu warten, bis der Provider MySQL4 nicht mehr unterstützt und dann gibt’s einen grossen Knall.

Ja, dateiseitig war es mir soweit klar, und ist ja schön gelöst! Aber was ist mit den Funktionen? Die Frage war evtl. nicht gut gestellt, und mir fehlt, wie gesagt, einiges OOP-Basiswissen. Aber ich hätte gehofft, man kann irgendwie geschickter die Original-Funktionen um Kleinigkeiten ergänzen, ohne gleich die gesamte Funktion in ein Modul aufnehmen zu müssen. Also quasi parent::foobar ausführen und dabei eigenen Code “einimpfen”. Aber wie sollte das funktionieren? Hm, wahrscheinlich gar nicht, wenn ich so drüber nachdenke… :wink:

Na egal, Mailingliste und SVN werde ich sicherlich auch mal konsultieren, wenn es die Zeit erlaubt. Danke für die Tipps! :slight_smile:

@oxUser:
Die nötigen Parameter wären:

example.com/kategorie/?fnc=execmanufilter&manufilter=

Aber wieso und wo sollte man dies brauchen (außer man nimmt kein <select>, sondern einzelne Buttons, wie ursprünglich angedacht)?

Grüße

Hi Mitmacher,

ich bins mal wieder :wink: Kannst Du das Modul bei Gelegenheit noch frisch für die 4.5 er machen? Das wäre wirklich genial!

Besten Dank und viele Grüße vom Chris

Moin Chris,

da bin ich tatsächlich schon am Basteln und fast fertig… :slight_smile:
Ich weiß ja nicht, wie die “offizielle” Lösung aussehe, aber um kompatibel zu bleiben, baue ich Versionsweichen ein. Mal schauen, ob dies auch für die Zukunft sinnvoll ist.
Auch will ich das Ganze gerne endlich mal im Modul-Bereich einstellen, mal sehen, ob ich es diesmal schaffe. Aber egal, in Kürze (evtl. heute noch) hier also entweder ein Link oder ein neues Zip.

Gruß
Sascha

Moinsen Sascha,

na, da freu ich mich aber! Eine offizielle Lösung sähe wahrscheinlich so aus, dasses einfach noch die alte Version irgendwo zum Downloaden geben würde. Keine Ahnung, inwiefern das für die Zukunft sinnvoll und vor allen Dingen wie aufwändig hier eine Versionsweiche umzusetzen ist.

Vielleicht kann man ja im Exchange mehrere Versionen einstellen?

Man kann, siehe:
http://www.oxid-esales.com/de/exchange/extensions/gutschein-zum-geburtstag?tab=get-extension&term=2222

Allerbeste Grüße und Dankeschön vom Chris

Jau, endlich geschafft! :cool:

Aber ich bin bei Versionsweiche geblieben, da recht einfach zu lösen in diesem Falle. Also gibt es nun “Show-Manu 1.1” für die Oxid-Versionen 4.4.3 - 4.5.0, siehe [hier].

Für die 4.5.0 habe ich auch beide Templates berücksichtigt (Basic + Azure), und das Ganze insgesamt um einiges vereinfacht, sodass nun weniger eingebunden werden muss… :slight_smile:

Viel Spaß damit!

Hi Mitmacher,

vielen Dank für die neue Version erstmal. Ich glaube allerdings, ich hab da noch nen Fehler gefunden.
Die Zeile:

 [{assign var="aManuCatList" value=$oView->getManuCatList()}]

im list.tpl schmeißt noch folgenden Fehler, wenn man sich die Liste nach Hersteller geordnet anzeigen lassen möchte, also über einen direkten Link:


Function 'getManuCatList' does not exist or is not accessible! (ManufacturerList)

Hier mal noch ein Testlink:
http://dev.meinestruempfe.de/Marke/Hudson

Könntest Du Dir das bitteschön mal ansehen?

Vielen Dank und allerbeste Grüße vom Chris

Holla die Waldfee, typisch, beim ersten Mal so einen Schnitzer reinzuhauen, und ich danke Dir dermaßen für die Rückmeldung, du glaubst es nicht! Ich wundere mich seit Tagen, was Phase ist (siehe hier), und dann kommt die Erleuchtung, doch selbst Schuld zu sein mit meinem buggy Modul. :o Cool, also gleich 2 DInge auf einmal gelöst, denn seit eben gibt es Show-Manu v1.2 zu laden. Damit läuft wohl endlich alles rund… :slight_smile:

Grüße!