Beiträge von Milbo

    Hallo alle Zusammen,
    Ich verwende ein eigenes Template für den Shop: shop.kmueller-fleischerei.de habe aber ein Override für den Cart.
    Nur weiß ich nicht mehr was ich darin gemacht habe oder machen wollte. Wenn ich den Cart-Override abschalte (sieht alles wie gehabt aus) ist das beschriebene Problem verschwunden.


    Unsere Hauptanweisung bei einem Update von vm2 zu vm3 ist es alle overrides auszuschalten und sich erstmal die neuen layouts anzusehen.


    Letztendlich gilt das immer, wenn es irgendwo klemmt. Zudem sind in vm3 die meisten overrides überhaupt nicht notwendig, weil man fast alles über CSS machen kann. Es macht auch Sinn, nur teile des layouts zu overriden. Joomla 3 kopiert immer alles (auch alle unterlayouts), daß macht relativ viel Ärger für nix. Beispiel, ich will eine Sache im Cart ändern, ich kopiere eine Datei. Es kommt ein update, 6 Dateien ändern sich. Ich muß eine Datei anpassen, kann auch Glück haben und alles läuft weiter (wir investieren viel Zeit darin, aber es ist schwer, da es buchstäblich zig 1000 installationen gibt).
    Wenn man allerdings joomla benutzt hat, hat man 6 Dateien, welche eigentlich alle überprüft werden müssten.


    Zusätzlich ist es zumeist so, Es ändern sich von 6 Dateien nur 4, davon eine mit kritischen Änderungen. Habe ich nur eine Datei überritten (lol), dann ist es relativ unwahrscheinlich, daß es genau die mit den kritischen Änderungen ist.

    Nein, die 0 ist das Trennzeichen und das funktioniert sehr gut. Denn man hat ja vorher das Datum, da weiss man ganz genau, ob das eine 2015 oder eine 15 ist. Man kann aber auch Orders : Order Number plugin kaufen.


    Wir hatten eine Steuerprüfung und haben sie 1a bestanden. Aber in Deutschland, das mag in Österreich anders sein.

    Nicht unbedingt. Wenn die Versionsnummer neuer ist, dann ja. Das Impressums Modul kann einzeln installiert werden.


    Ansonsten sind die Änderungen extra sublayouts, die auch im sublayout folder liegen. Geplant ist noch ein Sprachenmodul, welches die momentane die Seite beibehält. Unter category sind noch 2 layouts und unter productdetails das multiadd layout.


    Ein layout typ (Warenkorb zeigt mehrere Vats richtig an) ist in die normale Version übergegangen.


    Das ist so ein Beispiel was VM ausmacht. Das lief schon recht lange mit mehreren MwSts aber es wurde im Warenkorb nicht richtig angezeigt bzw nicht für alle Länder. Also konnte man sich das anpassen. Die konkrete Situation ist of einfacher, als eine Lösung für alle. Auch ein gutes Beispiel für die Membership, da ich verschiedene Layouts für Kunden entwickelt habe, daraus wieder eine Version für die Membership und später fliessts in die offizielle Version ein.

    Was hat das mit dem Zufallsgenerator zu tun? Nichts. LInk war falsch Invoices - VirtueMart Documentation


    Das Format ist RRRR0C für die Bestellnummer


    In Deutschland braucht man btw KEINE fortlaufende Nummer mehr, seit Jahren. Die Nummer muß nur eindeutig sein.


    15101151B3017
    151011KBF2025
    1510116DI5035
    1510126R3S036
    151012WSDC037


    Müssten Rechnungsnummern sein YYMMDDRRRR0C


    Die Nummern sind hier 17,25,35,36,37 die Rechnungen dazwischen wurden vermutlich gelöscht oder ähnliches. Bestellugen sollte man übrigens in einem liveshop nie löschen.


    Mehr Diskussion hier VM is wrongly resetting auto_increment after order deletion giving ref conflicts

    Es ist besser etwas anderes als jos_ dort zu haben, sonst sieht man sozusagen das es mal ein vm1 war. Du kannst das umbenennen, musst aber die configuration.php von joomla anpassen. Es könnte beim JED auch kostenfreie Tools geben, die das für einen machen.

    Neee, das ist schon seit vm2.0.0 so.


    Die Nummer IST fortlaufend und sie IST nach deutschem Recht. Man braucht da eigentlich überhaupt nichts machen. Die neue Version hat nur einen besseren Zufallsgenerator und nen Blocker, wenn einer zu oft versucht mit falschen Daten als Gast eine Bestellung einzusehen.


    Die Bestellung ist geschützt durch die Bestellnummer und den Bestellgeheimcode. Weitere Erklärungen hier Invoices - VirtueMart Documentation

    Es gibt da nochn Problem, wenn man Joomla benutzt zum erstellen der overrides.


    Ein Layout besteht oft aus Unterlayouts. Joomla kopiert immer das layout + die Unterlayouts. Damit handelt man sich aber schneller Probleme ein.


    Generell sollte man layout overrides vermeiden und versuchen die Anpassungen per css overrides zu machen. Wenn man um ein override nicht herumkommt, dann sollte man nur überschreiben, was man wirklich ändern will. Also z.B. man verändert den Warenkorb.


    Joomla würde jetzt einfach die default.php kopieren und alle Dateien die mit default_ anfangen. Meist will man aber nur die default_pricelist ändern, dann sollte man auch nur diese kopieren.


    Warum sollte man layout overrides vermeiden? Wir geben uns zwar viel Mühe, aber manchmal ist es nicht vermeidbar, daß eine funktionelle Änderung des Layouts notwendig ist, um ein Problem zu beheben. Wenn man dann VM updated wird weiterhin das alte Layout benutzt, d. h. entweder man hat nichts vom Fix, oder es läuft nimmer.

    VM ist ein opensource Projekt, der code ist für alle kostenlos.


    Anfangs gab es nur ein paar Leute (meist Entwickler), die ihre Shops gebaut haben und sich an der Entwicklung beteiligt haben. Durch den Erfolg kamen immer mehr reine Benutzer. Gleichzeitig wurde die Komponente immer komplizierter, so daß die Entwicklung nicht mehr von Voluntären getragen werden konnte. Man kann sehr selten gespendeten Code direkt verwenden, es muß praktisch immer nachgearbeitet werden. Das heisst die weitere Entwicklung von VM braucht mindestens einen (mich in dem Fall), der hauptsächlich die Core entwicklung macht und leitet. Viele sind auch einfach Dankbar und wollen, daß das Projekt vorrangeht. Früher gab es dafür einen Spenden button auf virtuemart.net. Allerdings eine Spende so ganz ohne Gegenleistung is doof. Zudem mussten wir die eh Versteuern, da wir kein gemeinnütziger Verein sind. Also
    eine Aufgabe der Membership ist es eine Möglichkeit zum Spenden zu geben.


    Außerdem kamen immer mehr professionelle Webagenturen bzw Shopbetreiber auf mich zu und fragten mich über Garantien. Man stelle sich vor, da hat man nen shop, der ne Million Umsatz pro Jahr macht und dann kommt ein Sicherheitsproblem raus. Also sagten mir viele "Der VM läuft ja gut und alles, aber wer fühlt sich verantwortlich für security patches", antwortete ich "ja ich natürlich", sagten die Betreiber, "ja das weiss ich jetzt, aber ich habe darüber nichts schriftliches". Also
    eine Aufgabe der Membership ist es eine Garantie zu geben, daß sicherheitsrelevante Bugs gefixed werden, oder auch ne Art Wartungsvertrag.
    Strenggenommen ein "Muß" in Deutschland.


    Andere Aufgabe ist die Entwicklung neuer Features durch "Crowdfunding". Die Entscheidung welches der 100 neuen Features als nächstes eingebaut wird, ist ziemlich komplex. Letztendlich benutzen wir Geld als Steuerfunktion. 5 Leute die irgendwas wollen, aber dafür kein Geld ausgeben wollen sind letztendlich für das Projekt unwichtiger, als 1, der auch bereit ist dafür zu zahlen. Zudem können mehrere Mitgliedschaften (Silber, Gold), die ein Feature wunsch beinhalteten zusammengelegt werden und das Feature bezahlen.


    Desweiteren baut man mit der Zeit immer mehr kleine Anpassungen, die aber für die Masse völlig unbrauchbar sind (nur Deutsche brauchen den Widerruf), also stehe ich vor der Wahl diese kleinen Schnipsel zu verkaufen, oder freizugeben. Einzeln Verkaufen lohnt nicht, für 5 euro z.B. ist bereits die Beantwortung eines 5-Minuten Tickets ein Minusgeschäft. Freigeben will man es auch nicht, man saß schon einige Stunden dran.
    Also wurde die nächste Idee geboren. Kleine, für einige nützliche Anpassungen, sind als "Value Added" in der Membership. Als extra Anreiz. Die Idee ist auch, das z.B. Templater eine Membership kaufen, da sie ja mit Hilfe des Systems ihren Lebensunterhalt bestreiten, also Interesse daran haben sollten, daß das System stabiler wird. Sie können die mitgelieferten extra layouts in ihre Templates einbauen.


    Man kann das ganze auch ganz anders sehen. Viele Shopsysteme kosten mindestens 100 euro im Jahr. Wir wollen halt irgendwie beides anbieten. Garnichts zahlen => kein Support. Membership => security support.


    Ahja und nochwas. Viele Leute haben im Forum geschrieben und sich verhalten wie Kunden, d. h. erwartet man muß ihre Fragen beantworten, oder man muß dieses Verbessern usw. Unsere Antwort wurde mehr und mehr "Du bist kein Kunde, frage wie in einer community üblich". Also fragten wiederum Leute, wie werde ich Kunde? => Membership.


    Mit der Membership erwirbt man sich auch das Recht unsere Ticket system für alle VM bugs zu nutzen. Fixes sind, wenn nicht security relevant, nicht garantiert, aber wir reagieren.


    Btw, Professioneller VM Support


    Man bedenke, wir machen Dinge in 1 Stunde, da sitzt der Anfänger Tage dran. Ich habe ja schon vor Tagen vorgeschlagen, dein Problem mit einer Silbermitgliedschaft zu erschlagen. 100 euro und du hättest den Widerruf + das andere Ding was dir fehlt. Mit Einbau und allem, eine Silbermitgliedschaft und eine halbe Stunde. Wären 150 euro gewesen und du wärst seit 5 Tagen fertig.

    Du hast ja jetzt 2 selbsterstellte Felder eingesetzt
    1. Multi Variant
    2. Allgemeine Variable für Produktvarianten


    Eine von den beiden würde ich erst mal entfernen


    Warum? Es gehört dazu, daß man auch beides kombinieren kann. Das kommt eben auf die Variantenart, und auf das Verkaufsgut an.


    Dinge wie Motive auf T-Shirts macht man z.B. so. Also die T-Shirts mit den Farben als MV oder Generic child variant und dann die Motive als Image varianten bzw String, is ja beides fast gleich.


    Bei einzelnen Kindern kann man dann auch sinnlose Motive entfernen (customfield disablen bei Schwarz auf schwarzen Shirt). In der Gallerie zeigt man wie ein paar Motive mit der Farbe aussehen, passt.