Beiträge von Milbo

  • Joomla + VM + SSL Vorgehensweise

    Durch den Post angeregt, habe ich mich erneut damit beschäftigt.


    Also in allen Versionen unter vm3.0.18.1 muß man das SSL auf Joomla UND Vm aktivieren! und das mit den sensiblen Bereichen, wie gesagt, würde ich lassen, da es wie Faro bereits bemerkte ganz schnell zu "gemischten" Inhalten führt.


    Noch viel schlimmer ist eigentlich das Session problem. SSL kann so eingestellt sein, daß man letztendlich eine neue Session erhält. So hätte man dann in den sensiblen Bereichen Produkte im Warenkorb und ansonsten nicht.

  • Anpassen an rechtliche Anforderungen für Deutschland?

    Es gibt Erweiterungen, welche das Erlauben. Allerdings,


    man tut sich selber keinen Gefallen, wenn man 7 MB große Fotos hochlädt, und immer ewig warten muß. Das ist auch nicht gut für den Endbenutzer. Denn man könnte das nur die "zeigethumbs" Funktion benutzen, mit entsprechenden Parametern und schon könnte man hochladen, was man will und es würde immer gleich groß gezeigt werden.


    Momentan werden die Bilder im Produktdetail nicht verändert, d. h. man kann dort leicht unterschiedliche Bilder haben, ohne das es zu Problem führt. In der Browseview werden angepassten Tumbs benutzt.


    Ansonsten würde ich mir mal Irfanview runterladen und mir dort die Batchprozess Möglichkeiten anschauen. Mit Hilfe von Irfanview kann man schnell, viele Bilder auf die gleiche Art und Weise bearbeiten.

  • Fehlermeldung nach Update auf Virtuemart 3.0.18

    Danke an alle. Also Oakmountain liefert hier denke ich den besten Hinweis. Es kann gut sein, daß es mit der verwendeten Datenbank und PHP Version zusammenhängt und mit Zeichen, welche vom ASCII Satz abweichen. z.B. äöüß


    Was ich allerdings nicht verstehe ist, warum das manchmal nicht übersetzt ist, denn so kann man nicht sehen, um welche Datei es sich handelt. Ich frage mich, ob ihr den Sprachenfallback aktiviert habt (vm config, erstes Tab). Der Fehler bestand übrigens schon vorher, er wird einfach nicht gemeldet, daher sieht man in das in der alten Datei nicht.


    Ihr könnt um Zeile 486 rum den vmdebug ergänzen, so daß man besser sehen kann, um welche Dateien es sich handelt

    Code
    1. if(!JFile::exists($toChk)){
    2. vmdebug('Media file does not exists',$toChk);
    3. vmError(vmText::sprintf('COM_VIRTUEMART_FILE_NOT_FOUND',$toChk));
    4. }

  • Syntax-Fehlermeldung Virtuemart 3.0.18

    Das ist vermutlich noch ein alter Key, welcher nicht base64 encoded war. Wenn es keinen Error gäbe, hätte er vermutlich einen neuen angelegt. Die einfachste Möglichkeit ist es den Key zu löschen, dann wird automatisch ein neuer erstellt.


    Oder man öffnet die Schlüsseldatei und reparierts. Wäre ganz gut die Datei zu haben, so das ich sehen kann, was falsch gelaufen ist.

  • Fehlermeldung im Frontend

    Also den Fehler gabs schon immer, geändert hat sich eigentlich nur, daß man den Fehler auch reported bekommt. In der vm3.0.18.1 habe ich es so geändert, daß man den Fehler nur sieht, wenn man als Admin eingeloggt ist, ansonsten wirds geloggt. Seltsam ist allerdings, warum das nicht übersetzt ist. Da bin ich noch nicht ganz dahinter gestiegen.

  • Gutscheine lassen sich nicht einlösen. Fehlermeldung oder der Kunde wird ausgeloggt.

    Zitat von cocca11

    Hallo an alle,
    ABER: sobald der Kunde dann während des Checkouts den Gutschein einlösen möchte, wird er entweder auf eine weiße Seite weitergeleitet und es erscheint die Meldung:


    Duplicate entry '' for key 'PRIMARY' SQL=INSERT INTO `jg3lh_session` (`session_id`, `client_id`, `time`) VALUES ('', 0, '1476716956')


    oder aber der Kunde wird ausgeloggt.


    Das Problem ist mir völlig unbekannt. Oder 2-3 Jahre her. Was für eine Version hat dein shop?


    Zitat von cocca11

    EDIT: Habe im Backend nun mal die Fehlermeldungen auf Maximum gestellt und heraus kam Folgendes:


    Warning: session_start(): Failed to decode session object. Session has been destroyed in /homepages/32/d545176391/htdocs/libraries/joomla/session/session.php on line 537


    Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /homepages/32/d545176391/htdocs/libraries/joomla/session/session.php:537) in /homepages/32/d545176391/htdocs/libraries/joomla/session/session.php on line 537
    Duplicate entry '' for key 'PRIMARY' SQL=INSERT INTO `jg3lh_session` (`session_id`, `client_id`, `time`) VALUES ('', 0, '1476994385')


    Diese Meldung ist vermutlich durch eine andere Komponente. Mir ist dieser Fehler nicht bekannt. Es geht hier um die Sessiontabelle, welche von joomla verwaltet wird.


    Zitat von StefanSTS

    Hallo Moni,
    für einen Shop sollte man in jedem Fall, auch wenn er klein ist, ein Budget von mindestens 70 bis 100 Euro pro Monat einkalkulieren.


    Das sehe ich nicht so. Das kommt sehr auf den Shop an und es kommt sehr darauf an, wer den shop gebaut hat. Also wie gut ist das benutzte Template, wie gut sind die Erweiterungen, und was wird alles benutzt.


    klar ein guter Shop, der viele Features einsetzt, da haste Recht. Solche Shops werfen aber auch soviel ab, daß die 100 euro einen nicht jucken sollten.

  • ccInvoices erhält keine Daten

    Ich verstehe auch nicht, warum es dafür eine 3. Party Komponente benötigt. Man kann so einiges bereits rudimentär in VM direkt einstellen. Dinge wie Schriftart, Größe, Header, Footer, usw. Der Rest geht über einen Layout override, wie Stefan schon beschrieben hat, da kann man dann Finetunen.

  • Joomla + VM + SSL Vorgehensweise

    Völlig richtig.
    Für die Bezahlarten braucht man garkein SSL! weil alles sensible über die Provider geht. Abgesehen davon, was man kauft. Um das abzufangen braucht man eh SSL für die ganze Seite (für die ganz Paranoiden).


    Aber halt auch, wegen Google. Das heißt die Option "nur für sensible Bereiche" sollte ich eigentlich löschen. Denn sie vermittelt nur eine falsche Vorstellung. Es war mal sinnvoll. Als server auch deutlich langsamer durch SSL wurden, aber das ist heutzutage wirklich Peanuts. Manche sagen es geht sogar mit SSL teils schneller (durch seltsame Effekte).


    Letztendlich um die Frage von hatschipu zu beantworten, wie macht man das jetzt? Ich empfehle ein Multidomain Zertifikat, was in seinem Fall für *.meinseite.de ausgestellt wäre. Wir haben so ein Zertifikat für https://virtuemart.net/ und man beachte das Zertifikat hier https://extensions.virtuemart.net/


    Es lohnt sich, gibt imho sogar besseres Ranking,.. munkelt man, obs stimmt weiß ich nicht. Wir hams eh gebraucht.

  • SQL Fehlermeldung bei abrufen in englisch

    Das ist seltsam, daß es nicht automatisch die Tabellen anlegt, daß hatte ich für die vm3.0.18 überprüft.


    Eventuell einfach den Tableupdater unter Migration aufrufen. Aber an deiner Stelle würde ich das Upgrade machen. Denn von vm2 auf vm3 ist meißtens relativ einfach. Der Updater kümmert sich imho um fast alles. Man muß sich hauptsächlich um Customfield plugins kümmern. Der Rest läuft von alleine. Ich meine mich zu erinnern, man muß noch wegen alter Bestellungen was auslösen und es gibt noch eine Möglichkeit überflüssige Customfields zu löschen. Das ist halt in den Tools extra, weils bis dahin nicht viel erprobt war und die Befürchtung bestand, daß es Shops zerschiesst, aber hat jetzt letztendlich in 2 Jahren keine Probleme gemacht.


    Tutorials gibts auf Docs How to upgrade VirtueMart 2 to VirtueMart 3 - VirtueMart Documentation Aber viel mehr steht da auch nicht, weils von vm core Seite nicht viel mehr ist.


    Falls du dennoch Probleme hast, empfehle ich den Migrator von daycounts Import & Export : VirtueMart 2/3 migrator


    oder nutze das englische Forum Updating from Virtuemart 2.x to VirtueMart 3

  • You must provide at least one recipient email address

    Der letzte Anhang geht nicht.


    Eventuell liegt es an der Einstellung "Email Adresse des Verkäufers verwenden". Diese geht imho nur, wenn der shop einen eigenen email server verwendet. Es kann auch am Template liegen. bzw an den Overrides. Um dies auszuschliessen braucht man nicht sein Template gleich umstellen, es reicht auch die com_virtuemart Ordner im template Verzeichnis umzubenennen. Denn es ist schon sehr seltsam, daß keine email in den Orders angezeigt wird. Gibst du die email im Bestellprozesse ein? Hast du einen Fullstarter genommen? So ein Komplettpacket mit Template?

  • Umleitung mit htaccess

    Ahh, das Thema. Ein großes Problem, was ich jetzt erst nach dem Release der vm3.0.18 so richtig erfasst habe.


    Die neue vm3.0.18.1 hat dein Problem eventuell behoben. Das Problem ist das Routing in Joomla und Vm. Mit htaccess kommst du da imho nicht weiter. Unser Router erstellt eine Menümap, also ein Zuweisung der Kategorien und Produkte zu eventuell vorhandenen Menüs. Da wurde jetzt nach der vm3.0.18 doch nochmal viel geändert, da dieses Thema auch für WP sehr interessant ist.
    Letzendlich wird die "Homepage" Ansicht bzw die "virtuemart" Ansicht entfernt und durch eine Kategorie ansicht ersetzt, welche für die Kategorie und Hersteller id eine 0 hat (also alle zeigen). Die Kategorieansichten haben jetzt auch alle Gruppenprodukte wie die alte Homepage (Featured, Meist gekauft, usw).


    Update mal auf die vm3.0.18, das ist eh Pflicht, weil die vm3.0.8 ni ganz sischer ist. Die vm3.0.18.1 wird die Tage als download aufm dev server sein. Dann installierste die.


    Es könnte btw auch einfach ein ungünstiges Menüsetup sein.

  • MwSt nur im Warenkorb anzeigen

    Das Hauptproblem liegt letztendlich darin, daß es keine Einstellung je Ansicht gibt. Aber letztendlich läßt es sich durch eine css umgehen. Wenn das nicht geht, dann per override bzw den vorhandenen override ändern (denn sonst würde es ja mit Stefans css gehen).

  • Nachkommastellen bei den Produktedaten

    Zitat von StefanSTS
    Code
    1. if ($this->product->product_packaging > 0) {
    2. echo '<div>'.JText::_('COM_VIRTUEMART_PRODUCT_PACKAGING').': ' . round($this->product->product_packaging.$this->product->product_unit, 3) .'</div>';


    Das ist leider falsch. Die Einheit darf nicht im Round stehen, es ist also

    Code
    1. echo '<div>'.JText::_('COM_VIRTUEMART_PRODUCT_PACKAGING').': ' . round($this->product->product_packaging, 3) . $this->product->product_unit .'</div>';


    und eigentlich ohne die : und noch besser mit sprintf, eigentlich. Aber es gibt da noch was viel besseres und da muß man noch nichtmal coden.


    product customfields :-) und zwar vom typ P, Property. Ich weiß grad nicht, wie es auf Deutsch heißt. Beim Prototyp stellste ein "COM_VIRTUEMART_CUSTOM_PARAM_ROUND" auf ja. (jaja is no ni übersetzt, mea culpa). Wenn man das dann im Produkt einstellt, kann man z.B. einstellen "zeige mir das Produktgewicht" und dort kann man direkt das Rounding einstellen. Einfach das Feld dahinter.


    Dann mußte in dein Layout das customfield einbauen, daß ist aber nur die Copy einer Zeile und gehört eigentlich zum Grundzeug, weil es einfach extrem viel vereinfacht, wenn man die Customfields und sublayouts versteht. :-)


    Mehr info hier Customfields - VirtueMart Documentation


    Hier Custom Fields - VirtueMart Documentation


    und hier Sublayouts - VirtueMart Documentation


    okey, merke gerade, das was ich jetzt schreibe sollte auch noch ins Manual, man rendert beliebe customfields so


    Code
    1. echo shopFunctionsF::renderVmSubLayout('customfields',array('product'=>$this->product,'position'=>'ontop'));


    Der Witz ist, "ontop" ist eine Position, welche man selber im prototype setzt. Das heißt da kann man auch schreiben "dielaenge" (ascii is immer besser). Das setzt man dann bei der Position im Prototype des Customfield ein und schon tauchen alles customfields mit dieser Position dort auf. Die Reihenfolge ist imho die, welche im Produkt gesetzt ist.


    Das ganze macht man dann am besten noch mit einen Stammprodukt, dann gilt das für alle Kinder. Das heißt in manchen shops, legt man das einmal an, macht immer Kinder von diesem Hauptprodukt und man muß sich nie mehr drum kümmern. :-)


    Ich merke gerade, das ist alles noch viel zu verborgen, aber macht eigentlich den Witz von vm3 aus. Es ist nicht nur einfacher zu warten, es ist auch viel schneller, weil die Customfields nur einmal angelegt werden. Sie werden dann bei 50 Produkten auch nur einmal geladen.

  • Tipps zur Mehrsprachigkeit erbeten

    Ah Stefan, so kompliziert ist es nicht. Im Gegenteil, es ist sogar extrem flexibel.


    Als erstes würde ich mal das durchlesen Multilanguage - VirtueMart Documentation zur Not mit nem Übersetzerprogramm.


    Man kann VM theoretisch mit verschiedenen Sprachen benutzen und das joomla einsprachig belassen !!


    Allerdings braucht man für jede Sprache ein Home menü item, damit der Languageswitcher bzw das Routing von Joomla funktioniert. VM selber braucht da eigentlich nichts. Der übliche Weg ist, daß man ein Menü mit Sprache = Stern hat, dann legste noch ein Menü pro Sprache an, mit EINEM Eintrag, der Home sein muß und eben eine Sprache ausgewählt hat, dann sieht man da auch in der joomla menü Konfig eine Flagge. Das ist die faulste Methode.


    Desweiteren hat VM einen normalen Fallback, z.B. deutsch ist gefragt, Produkt in deutsch nicht angelegt, lade englische Sprache und einen Fallback vom Fallback (von Portugiesisch auf spanisch von spanisch auf englisch, z.B.), der geht aber nur mit der Konfigurationsdatei einzustellen.