cmsimple-xh / xhshop

A simple shop for CMSimple_XH

XHShop Plugin for CMSimple_XH

This plugin is based on the wellrad plugin 1.2.1 by Martin Damken, and is supposed to be further developed by the CMSimple_XH community. Many thanks to Martin for allowing us to change the license to GPLv3!

End users

There is growing documentation in our wiki.

Developers

For development purposes, you can directly clone this repo into the plugins/ folder of a CMSimple_XH installation. Afterwards you have to setup the demo content by running either

composer install
phing setup

or

setup.bat

The latter is a convenience for Windows users who don't want to install Composer, and just want to test a Git checkout. For full support of the development tools you have to install composer, though. Then run

composer install
phing

to see what's supported.

xhshop's Issues

Clarify license and fix exisiting issues

We have to clarify the license under which XHShop will be distributed. In any way we have to heed the license chosen by the original author (i.e. Martin Damken), which is as follows:

Das wellrad-Plugin wird unter der Creative Commons Attribution 3.0 Lizenz (CC-A 2.0) veröffentlicht. Das heißt Sie dürfen das Programm kostenlos nutzen, auch kommerziell, verbreiten und ändern – unter der Bedingung, dass Sie im Impressum mit einem Link auf die Projekthomepage (www.wellrad.de) auf seine Herkunft hinweisen.

Therefore we must change respective parts of the source code, e.g. in about,html:

The plugin is free as long as you add a link to one of the websites above to your template or give it a credit in your impressum page. If this is not o.k. with your project or your customer, please contact me for a commercial license!

The link has to point to www.wellrad.de. We may require another link to the XHShop homepage, but I'd rather make that mandatory.

Treuepunkte statt Gutscheincode

ein Gutscheincode wäre eine tolle Sache. Nicht nur für Werbeaktionen.
Ich gebe z.B. 10% bei über 100,- €, die schreibe ich als Gutschrift in die Rechnung. Beim Bestellen im Shop wäre aber ein Gutscheincode Quatsch, wenn keine Prüfung erfolgen kann, ob der Code gültig ist (wegen fehlender SQL - oder doch möglich?).

Aber Treuepunkte wäre vielleicht möglich - und die Kunden fahren total darauf ab!
Ein configurierbarer Prozentsatz des Warenwertes ergibt soundsoviel Treuepunkte (bei "0" in config = keine Treuepunkte), die errechnet und mitgeteilt werden (z.B. im Warenkorb ganz unten: "Sie erhalten für diese Bestellung 24 Treuepunkte"), und die auch in der Email stehen und weitergeleitet werden, und somit in der Datenbank des Shopbetreibers landen. Der kann sie dann in die Kundenkartei aufnehmen und damit verfahren wie er will.

Der Shopbetreiber kann natürlich Treuepunkte oder sonstige Gutschriften via Email oder eben in der Rechnung dem Kunden mitteilen usw.
Aber wenn sowas schon beim Bestellen, sogar bei der ersten Bestellung, im Shop steht, ist es tausendmal werbewirksamer. Kundenbindung: kleine Geschenke erhalten die Freundschaft! Und seien wir ehrlich: Der Shop soll ja (u.a.) zum Geldverdienen eingesetzt werden.

Require explicit configuration of shop page

Szenario:
Habe einen zweiten Shop in einer Installation angelegt.
D.h., einfach neue Seite angelegt, <div>{{{display_shop();}}}</div> in den Quellcode geschrieben, gespeichert. Shop wird problemlos angezeigt.
Da das natürlich Quatsch ist, habe ich diese (neue) Seite wieder gelöscht.
Noch im Pagemanager habe ich F5/reload gemacht, damit die gelöschte Seite aus dem Menü verschwindet.
Plötzlich meldet der Herr Debug:

XH-NOTICE: XHS_CMSimple_Bridge::getHeadingOfUrl($url) - xxx does not exist.
..\plugins\xhshop\XHS_CMS_Bridge.php:38

"xxx" ist der Seitenname der gelöschten Seite.
Man kann jetzt im Pagemanager (ohne die Seite zu verlassen) machen was man will - neue Seiten anlegen, löschen ... - die Debug-Meldung bleibt.
Erst, wenn man mal den PM verlässst, geht's weg.

Localize decimal separator

Bei Währungs-, Gewichts und anderen Zahlenangaben wird derzeit nur der Dezimalpunkt verwendet.
Ideal wäre, wenn Punkt oder Komma abhängig von der Herkunft des Besuchers verwendet werden könnte.

Alternative (nicht so günstig): Der Shop-Betreiber legt per Konfiguration fest, was verwendet wird.

Browser-Adresszeile bei Kategorie-Auswahl über Newsbox

http://fhs.bplaced.net/xhshop-demo/?Shop

Wenn ich im Shop Kategorie "Essen" wähle, bleibt in der Adresszeile stehen:
http://fhs.bplaced.net/xhshop-demo/?Shop

Wenn ich aus dem Neben-Menü in der Newsbox wähle, erscheint in der Adresszeile:
http://fhs.bplaced.net/xhshop-demo/?Shop&xhsCategory=Essen

Wähle ich nun eine andere Kategorie aus dem DropDown-Menü, bleibt in der Adresszeile immer das "Essen" stehen.

Ist das ein Problem?

Configuration of XHS_IMAGE_PATH in back-end

wellrad verwendet /images für Bilder, XH-Shop jetzt /images/shop
das finde ich sehr gut!

Für ehem. Wellrad nutzer:
wenn man die Bilder in /images nicht herausfiltern und verschieben will oder kann, kann man ja den Pfad ändern (required_classes.php).
Vllt. wäre es sinnvoll, das in der Hilfe zu erklären
(und falls einmal eine Konfigurierung im backend kommt, das aufzunehmen)

dont deal with taxes: messages

Wenn:
$plugin_cf['xhshop']['taxes_dont_deal_with_taxes']="true";
Dann erscheint in Step 3 trotzdem die MwSt. hinter den einzelnen Artikeln.

$plugin_tx['xhshop']['hints_price_info_no_vat']="Endpreis.<br />USt wird nach &sect;&nbsp;19 UStG.<br>(Kleinunternehmerregelung)<br>nicht erhoben.";
Diesen Text konnte ich (bei dieser Konstellation) überhaupt nicht finden.

Varianten mit Bildern

vielleicht wirklich zuviel verlangt - aber schön wärs doch
(hatte jahrelang gehofft, dass Martin hier was machen würde...)

Nur auf Detailseiten:
Varianten werden abgebildet, können durch Anklicken des Thumb (nicht notwendig) oder im Dropdown ausgewählt werden. Das ausgewählte wird dann vergrößert gezeigt.

Auch wenn viele eShops dazu übergehen, keine Varianten sondern für jede Farbe einen Artikel einzustellen, möchte ich nicht ohne Varianten auskommen müssen. Ich habe z.T. sehr viele Varianten und das würde die Listenansicht sprengen.
Wäre es viel Arbeit, das zu realisieren?

Additional fields in contact data

1. Ich benötige diese Felder (und könnte mir vorstellen, dass es anderen auch so geht...)
   
   das könnte ich machen

2. ein paar im backend benennbare "besondere Wünsche" wär auch nicht schlecht
   
   (die hab ich nicht ins backend reingekriegt...)

CMSimple_XH native Internationalisierung

Derzeit wird die Lokalisierung über Dateien in langs/ durchgeführt, die zwar ein sehr ähnliches Format wie die nativen CMSimple_XH Lokalisierungsdateien in languages/ haben, aber eben ein bisschen anders sind. Außer wenn der Shop auch unter anderen Systemen funktionieren soll (was ich für irrelevant halte), dann wäre es sinnvoll auf native CMSimple_XH Lokalisierung umzustellen, was den Vorteil hätte, dass mit wenigen Zeilen Code die Bearbeitung der Sprachtexte im Back-End ermöglicht werden könnte.

Bildeinfügen in den Produktbeschreibungen funktioniert nicht

Genau gesagt, funktioniert das Einfügen wie gewünscht, aber beim Speichern wird das Bild verstümmelt. Nach dem Einfügen z.B.:

<img src="./userfiles/images/test1.jpg" alt="" width="150" height="150">

Nach dem Speichern dann:

<img src="\&quot;userfiles/images/test1.jpg\&quot;" alt="\&quot;\&quot;" width="\&quot;150\&quot;" height="\&quot;150\&quot;">

Remove support for catalogue.inc

meines Wissens war es so, dass wellrad "catalog.inc" nur verwendet, wenn keine catalog.php vorhanden ist.

Da catalog.php sich besser mit einem editor bearbeiten lässt, kann meines Erachtens catalog.inc entfallen.

Ebenso die Fehlermeldung:

Fehler:
Pardon! Noch ist der xhshop-Shop nicht betriebsbereit.
Datei nicht gefunden: ./plugins/xhshop/data/catalogue.inc

nur Info: Umlautersetzung - keine Änderung nötig

interessant: die neue Umlautersetzung.
bisher war der link zur Detailseite im catalog so:
array('einzelne_Produkte:Bez%C3%BCge:Bez%C3%BCge_StillKis', ) und wurde jetzt nicht mehr gefunden.
habe im backend neu verlinkt, jetzt sieht es so aus
array('einzelne_Produkte:Bezuege:Bezuege_StillKis', )
gut, das ich catalog.php mit dem editor bearbeiten kann...

Automatic backup - catalog.php

sicher wünschenswert - muss aber nicht sofort!
bisher mach ich das vor jeder Änderung händisch

Insufficient date localization

Das Rechnungsdatum wird nur halbherzig lokalisiert, und zwar wie man sehen kann explizit nur für Deutsch, in welchem Fall aber setlocale() aufgerufen wird, was andere Plugins durcheinander bringen könnte.

Zu beachten ist weiterhin, dass $datum gar nicht wirklich verwendet wird, sondern das Datum weiter unten erneut formatiert wird, und per utf8_encode() nach UTF-8 konvertiert wird. Das würde aber nur für diejenigen Locales klappen, die ISO-8859-1 kompatibel sind.

Jedenfalls sollten wir überlegen, ob wir hier nicht einfach XH_formatDate() verwenden. Das sollte dann immer so aussehen wie bei lastupdate() was zumindest okay ist, und falls ext/intl verfügbar eigentlich sehr gut passt.

Prepared email attachments for notification email

das hier wäre ein Wunsch von mir, es ging bisher auch ohne - ist aber lästig -
wäre eine schöne Entlastung wenn viele Bestellungen reinkommen.

(Die Bestellbestätigung kommt unabhängig hiervon als Mail mit Anhang (z.Z. bill.rtf) wie bisher)

1. vorbereitete Versandbestätigung
   Es wird eine zusätzliche Email erzeugt, die nur der Shopbetreiber erhält. Diese würde Name und Emailadresse des Kunden so enthalten, dass der Shopbetreiber sie nach erfolgtem Versand nur noch losschicken braucht, ohne Name und Emailadresse reinkopieren zu müssen:
   Betreff: Versandbestätigung - < Kundenname > - < Schopname > hat Ihre Bestellung verschickt
   Text: in Sprachdatei

2. vorbereitete Aufforderung zur Bewertung
   Es wird eine weitere zusätzliche Email erzeugt, die nur der Shopbetreiber erhält. Diese würde Name und Emailadresse des Kunden so enthalten, dass der Shopbetreiber sie z.B. zwei Wochen später nur noch losschicken braucht, ohne Name und Emailadresse reinkopieren zu müssen:
   Betreff: Bitte Bewertung abgeben - < Kundenname > - Ihre Bestellung bei < Schopname >
   Text: in Sprachdatei

Diese beiden Emails sollten jeweils an separate Emailadressen gemailt werden, die in der Sprachdatei steht. Wenn da nichts steht, wird keine Email verschickt.

PS kann man diesem issue ein Label "super Idee aus der Praxis - XH-Shop wird flügge" zuweisen

Link preview image to product details

bei Klick auf den Artikelnamen wird auf die Detailseite verlinkt, ist richtig.
bei Klick auf auf das Priviewpicture:
http://test-natu-1-7.natur-und-handgemacht.de/userfiles/images/ --- ERROR
Ich hatte noch kein hi_fancybox 4.0 installiert.
Gemacht.
Jetzt kommt: Fehler: The requested content cannot be loaded.
Einstellung in required_classes ist
define('XHS_PREVIEW_PIC_PATH', $pth['folder']['images']);
(bei XHS_IMAGE_PATH klappt das)

Muss ich doch ein Verzeichnis /images/shop verwenden?
Oder in hi_fancybox irgendwelche Einstellung ändern?

Doubtful special treatment of bots

At the beginning of index.php there is a special treatment for some bots. This is apparently there to prevent PHP's URL rewriting for these bots. However, we already recommend to switch session.use_trans_sid off, and if this is the case, the code is actually a no-op. Furthermore, for this purpose url_rewriter.tags has been superseeded by session.trans_sid_tags as of PHP 7.1 so we would have to cater to this, if we want to cater to session.use_trans_sid on.

TL;DR: I suggest to remove these three lines.

cart button missing on start page

vergl. Demo:

Produkt in Warenkorb.
Cart Button erscheint auf allen CMS-Seiten.
Klick auf das XH im Header -> Startseite erscheint - aber ohne Cart Button ???

Paypal-Problem

es gibt da noch das alte Paypal-Problem. Wurde bei mir NIE gelöst, trat z.B. im Mai wieder paarmal auf. Frage ist, ob das bei einem von euch auch auftritt oder ob das ein Serverproblem ist (Strato). Immerhin habe ich auch das Updatecheckproblem wie wolgang_58.

https://cmsimpleforum.com/viewtopic.php?f=16&t=4100&start=10

1. Variante
   Der Kauf wird ausgelöst, paypal klappt, Kunde und ich kriegen vom Shop die email -
   aber: der Warenkorb bleibt voll und kommt nicht der Shopbildschirm mit "... email verschickt etc. ..."
   Dann aber oh Wunder kommt der Bildschirm doch, wenn ich erneut auf Warenkorb klicke...

2. Variante
   Kauf klappt, Paypal klappt, aber Warenkorb bleibt voll, kein ThankYou und keine Bestätigungsemail
   Datei in temp_orders wird nicht gelöscht (hier kann man die Bestelldaten auslesen)
   es wird kein Cookie für die Bewertung gesetzt.
   Es entsteht kein Schaden durch unbearbeitete Bestellung, weil paypal eine eigene Zahlungsemail sendet, die ankommt.

Beim Testen: Beide Varianten kommen natürlich nur vor, wenn man tatsächlich mit paypal bezahlt. Wenn man nicht mit paypal bezahlt, also abbricht, oder die Bezahlung nicht klappt (z.B. falsche emailadresse eingegeben), ist es ja gewollt, dass man ja in den immer noch vollen Warenkorb zurück kommt, um eine andere Zahlungsart wählen zu können.

nicht lieferbar - andere Farbe

habe grad die Shop-Übersicht im backend bearbeitet. Dabei ist mir aufgefallen, dass ich es gut fände, wenn "nicht lieferbar" in einer anderen Farbe z.B. grün erscheinen würde

Replace oddOrEven() with CSS

In catalog.tpl (und in html - Kopie.tpl, welches aber wohl sowieso entfernt werden könnte) wird die Methode ::oddOrEven() aufgerufen, um entsprechende CSS-Klassen für die Produktübersicht zu vergeben. Das wäre früher sicher mal relevant, aber das könnte man heutzutage doch auch wunderbar per CSS lösen.

Add system check

Sollte eine Prüfung auf XH Version ab 1.7.x stattfinden?
Oder mindestens auf das FA-Plugin?

Don't remove line breaks from annotation

Die Angaben im Feld "Anmerkungen" werden an irgendeiner Stelle "bereinigt" und erscheinen anschließend nur noch als "Fließtext" hintereinander (Zusammenfassung, Mails ...)
Ich meine, dass vom User eingegebene Zeilenumbrüche wieder hergestellt/erhalten/umgewandelt werden sollten -> nl2br ?

help files

Ich werde wohl die Help-Files basteln - so nach und nach.
Damit ich nicht in die ganz falsche Richtung laufe, bitte ich euch, von Zeit zu Zeit mal hier zu schauen.
Falls euch etwas auffällt, was nicht stimmt, oder nicht geht, dann bitte melden.
Achtung: Jetzt und in den nächsten Tagen müsst ihr noch nicht lesen, sondern nur gucken!
Der Inhalt ist nämlich noch Dummy!

Add customer name to subject of confirmation mail

Betreff: Ihre Bestellung - Vorname Nachname - XH-Shop DEMO

Ausfuhrumsatzsteuer

Das wurde bereits in #48 angesprochen, verdient aber ein eigenes Ticket.

Also, was machen wir mit $plugin_tx['xhshop']['hints_no_vat_export_bill'] und $plugin_tx['xhshop']['hints_no_vat_export']? Beide Sprachtexte werden nicht verwendet. Also einfach rausschmeißen, oder die entsprechende Funktionalität einbauen?

Smash shopsettings.php

Der ursprüngliche Wellrad-Shop bemüht sich um Unabhängigkeit vom Trägersystem – das macht meiner Meinung nach wenig Sinn für den XHShop. Besonders shopsettings.php verursacht einigen Mehraufwand, da die Konfigurationsformulare manuell vom Plugin anstatt automatisch von CMSimple_XH erstellt werden. Ich schlage daher vor, shopsettings.php zu zerschlagen. Im Einzelnen:

• Einstellungen → Shop (noch unklar)
• Einstellungen → Kontakt wandert nach config.php
• Einstellungen → Steuern wandert nach config.php
• Einstellungen → Versand wandert nach config.php (bzw. Sprachdateien)
• Einstellungen → Zahlweisen speichert nicht in shopsettings.php, und ist daher nicht Gegenstand dieses Vorschlags, sondern von #64
• Artikel → Kategorien → Einstellungsformular wandert nach config.php

shipping_graded - missing in language file (['hints'])

Diese Meldung (siehe Überschrift) kommt bei der Bearbeitung der Versandkosten im deutschen Backend.

XH 1.7.0 / xhshop-master

Warenkorb: MWSt. und Hinweis

Bei mir steht im Warenkorb unter den Artikeln:

Zwischensumme (oder besser Warenwert) 27,90 €
Versandkosten (25 kg) 5,90 €
Rechnungssumme 33,80 €
Enthaltene MWSt.: 19% 5,40 €

Hinweis: Versandkosten frei bei einem Bestellwert über 49,99 €.

Hinweis: Bei Warenwert über 100 € : 10% Rabatt
Gutschrift bei der nächsten Bestellung >> Rabatt-Info

1. MWSt. anzeigen (bei größeren Beträgen wahrscheinlich Pflicht)

2. Hinweis: "ab 50,- €" wäre mir lieber gewesen, aber das rechnet der Shop nicht richtig

3. Hinweis: vllt. geht es nicht nur mir so, dass ein weiterer Hinweis, mögl. im backend editierbar, sinvoll und wünschenswert wäre

Negative billing amounts are possible

wenn man für 1,- einkauft (keine Mindestbestellmenge) und Nachlass 3,- ist, wird der Kaufpreis negativ. Martin hatte da eine Sperre drin, die ist wohl rausgeflogen?

Bez. mit paypal - 3. Schritt

• rechts unten: "Jetzt kaufen" ergibt Fehlermeldung
• links unten: "mit paypal bez."
  ... ist das Absicht so ?

Step 2 - debug notices

master 04.07.2017 20:30 inkl. mods
local, xampp, php 5.6.11 OHNE intl

Debug-Modus meldet:

NOTICE: Undefined index: street
..\plugins\xhshop\classes\app\xhs_frontend_view.php:25
NOTICE: Undefined index: zip_code
..\plugins\xhshop\classes\app\xhs_frontend_view.php:25
NOTICE: Undefined index: city
..\plugins\xhshop\classes\app\xhs_frontend_view.php:25

Die entsprechenden Felder haben kein Label.
Alle Felder sind type="text" und haben step="0.01" !!!

Nachtrag:
unter xampp, php 7.1.1 mit intl = identisches Bild

Country specific forwarding expenses

Beim Eintragen der Kundenadresse gibt es das Feld "Land", editierbar in lang/countries_de.txt

1. Diese Länderliste in Backend editierbar machen
2. Jedes Land einer Zone "national", "EU", "Europa" "Welt" zuordnen.
3. gewichtsabhängige Versandstaffel (vorhanden für "national") erweitern für "EU" "Europa" "Welt"
4. optimal wäre, zusätzlich zuzuordnen, ob MWSt. erhoben werden soll (z.B. Österreich-ja, Schweiz-nein),

Versandkosten sind Bestandteil des Vertrags, den der Shopbetreiber mit dem Kunden eingeht, nachdem eine Bestellbestätigung verschickt wurde. Außerdem muss rechtlich der konkrete Betrag vor "jetzt kaufen" verbindlich angezeigt werden. "Höhere Versandkosten erfragen" ist nicht zulässig.

Es gibt ein Addon, bei dem jedem Land ein Geldbetrag zugeordnet werden kann,
z.B. "Österreich~15.10", editierbar in lang/countries_de.txt,
Dieser Betrag wird "im nächsten Schritt" zu den nationalen Versandkosten hinzu addiert.
Leider ist dieser Betrag bisher nicht abhängig von Versandsettings im backend, wird also auch berechnet bei "Versand frei", und ist auch nicht gewichtabhängig.
Setzt der Shopbetreiber den Betrag niedrig an, z.B. für 5kg, so zahlt er bei schweren Paketen drauf, während hohe Zuschläge die Kunden abschrecken.

Separate shop output from page content

.xhsLft und .xhsRght floaten, und das passt nicht unbedingt gut für nachfolgenden Text:

Ich denke, hier fehlt ein clear oder ein Block formatting context.

variants in catalog.php - blanks

$products['p595e69e48c4e4']['variants']['de'] = array('neutral', '--------rot', '--------grün', '--------blau', );
Die "-" habe ich als Ersatz für"Leerzeichen" hier zur Darstellung eingefügt.
Bei jedem Speichern kommt ein Blank hinzu. Nicht bei der ersten Variante.
Sichtbar wird das eigentlich nur bei "Produkt bearbeiten".

Shop-Aufruf nur einzelne Kategorie

soweit ich weiß kann man nur einen Shop pro CMS-Installation haben.

Bei einem großen Sammelsurium an unterschiedlichsten Artikeln wäre es vielleicht sinnvoll, quasi mehrere Teilshops zu haben, aber nur einen Shop pflegen zu müssen.

ist es möglich oder machbar, bei nur einem Shop verschiedene Shop-Aufrufe zu machen, wobei dann nur eine bestimmte Kategorie (oder mehrere) so im Shop erscheinen, als wenn es nur diese geben würde? Und natürlich auch nur die dazugehörigen Artikel angezeigt werden.

Was als link geht (...?Shop&wrsCategory=...) ist was anderes, weil hier zwar die verlinkte Kategorie ausgewählt wird, aber alle anderen Kategorien auch vorhanden sind und in der Shop-toc angezeigt werden.

Max. Bestellmenge pro Artikel

Wäre es nicht sinnvoll, bei Artikel->Artikel bearbeiten eine maximale Bestellmenge anzugeben?
Beispiel: Ein chinesisches Unternehmen will Alberts Dinkelkissen weltweit vertreiben und bestellt 100.000 Stück (unrealistisches Beispiel - illustriert aber, was ich meine).
Dieser Wert müsste dann dem Eingabefeld für die Bestellmenge als max="XXX" zugefügt werden.
Außerdem müsste auch hier step="XXX" individuell festgelegt werden. Ein 0.01 Stück Kissen kann man nicht bestellen - aber 0.75kg Hirse.
Momentan haben alle Textfelder step="0.01" - das dürfte auch nicht ganz richtig sein.

Prüfung auf hi_fancybox

Prinzipiell funktioniert alles auch ohne Fancybox. Man kann die Bilder anklicken, sie werden (in der großen Version angezeigt) - dann muss man aber mit dem Browser-Zurück-Button zurückschalten. Geht so.
Nur im 2. Schritt im Bestellvorgang, bei Klick auf AGB gibt es ein Problem. Da hier schon Daten übertragen werden, meldet der Browser beim Zurückschalten: "Dokument erloschen ...") und man muss reloaden.
Sollte man das Plugin von hi_fancybox abhängig machen? Also prüfen, ob installiert?

Alternative bill formats

Derzeit wird in der Bestellinfomail eine vorbereitete Rechnung im RTF-Format als Anhang bill.rtf versandt. In gewissem Rahmen kann das Aussehen des RTF-Dokuments durch Änderungen an bills/template.rtf angepasst werden. Mit dieser Rechnung scheinen aber einige Anwender nichts anfangen zu können, außer sie bedingt zum Copy&Paste in die eigene Auftragsverwaltung zu verwenden. Ebenfalls ist zu bedenken, dass es sich bei RTF um ein proprietäres Format handelt.

Es stellt sich die Frage, ob alternative oder zusätzliche Formate unterstützt werden sollten, wobei es nicht umbedingt um eine vollständige Rechnung gehen muss, sondern durchaus auch reine Datenaustauschformate interessant sein könnten, und falls ja, welche.

Siehe dazu #10 (comment) ff, wo bereits einige Diskussion zu diesem Thema stattfand.

F5 after ordering throws fatal error

Nach einem erfolgreichen Bestellvorgang, führt das Aktualisieren (F5) des Browsers zu einem fatalen PHP Fehler:

Fatal error: Uncaught Error: Call to a member function getVat() on null in …

no-taxes info missing from emails and bill

$plugin_cf['xhshop']['taxes_dont_deal_with_taxes']="true";
Nur bei "true":
Ist die Bestellung abgeschlossen (Seite thank you) meldet debug:

NOTICE: Undefined index: no_vat_bill
..\plugins\xhshop\classes\app\xhs_frontend_controller.php:474

Unnecessary file creation

Es gibt immer nur ein bill.rtf das nach Abschluss des Bestellvorgangs erstellt, und dann per Mail an den Shopbetreiber verschickt wird. Wenn zwei Bestellungen quasi zeitgleich vorgenommen werden kann es passieren, dass für beide Bestellungen das selbe bill.rtf verschickt wird. Sehr unwahrscheinlich, aber möglich – mit problematischen Folgen.

Entweder müsste bill.rtf gesperrt werden sobald mit dessen Erstellung begonnen wird, und es dürfte erst wieder freigegeben werden, wenn das Ergebnis gelesen wurde. Alternativ könnte man auch den Rechnungen eindeutige IDs zuweisen (etwa bill-12345.rtf), in welchem Fall sich alte Rechnungen auf dem Webspace ansammeln würden (kann aber auch ein Vorteil sein). In beiden Fällen müsste auf jeden Fall der bills/ Ordner vor direktem HTTP-Zugriff geschützt werden (ansonsten können Neugierige die aktuelle oder gar alle Bestellungen einsehen – Datenschutz).

Mir sieht es aber so aus, als müsse die Rechnung überhaupt nicht gespeichert werden, sondern könnte direkt an die Mail angehängt werden – das wäre wohl die eleganteste Lösung.

Custom attachment for confirmation mail

Für Gewerbliche Verkäufer gilt:

1. eine AGB als CMSimple-Seite muss vorhanden sein und darf nicht versteckt sein
   (z.Zt. wird glaube ich nur das Vorhandensein abgefragt)
2. Eine Widerrufsbelehrung muss meines Wissens mit der Bestellbestätigung verschickt werden.

Ich habe meine einfach in die Sprachdatei gepackt
$lang['mail']['greetings'] = "... BETTEN-BÄR



Widerrufsrecht für Verbraucher


(Verbraucher ist jede ...

Sollte man nicht besser ein Textfeld im Backend haben?

Improve config help texts

Ich bin eher dafür, so viel wie möglich Erklärungen zu Konfigurations-Optionen zu geben.

Vorschlag Hilfetexte für Kontakt-Konfiguration (de):

$plugin_tx['xhshop']['cf_contact_order_email']='E-Mail-Adresse, an die die Bestellungen verschickt werden';
$plugin_tx['xhshop']['cf_contact_company_name']='Shop-Name oder Firmen-Name';
$plugin_tx['xhshop']['cf_contact_name']='Name des Shop-Betreibers. Dieser Name wird u.A. unter die Bestätigungsmail gesetzt.';
$plugin_tx['xhshop']['cf_contact_street']='Shop-Adresse: Straße Nr.';
$plugin_tx['xhshop']['cf_contact_zip_code']='Shop-Adresse: Postleitzahl';
$plugin_tx['xhshop']['cf_contact_city']='Shop-Adresse: Ort';

Entsprechend übersetzt für EN.

Weiterin Änderung für taxes:

$plugin_tx['xhshop']['cf_taxes_vat_full']="volle Umsatzsteuer - Eingabe mit Dezimalpunkt";
$plugin_tx['xhshop']['cf_taxes_vat_reduced']="ermäßigte Umsatzsteuer - Eingabe mit Dezimalpunkt";

Das ist wichtig, sonst gibt es in Step 3 wieder (bei Komma):

NOTICE: A non well formed numeric value encountered
..\plugins\xhshop\classes\app\xhs_view.php:234

Artikel ohne Detailbild

master 04.07.2017 20:30 inkl. mods
local, xampp, php 5.6.11 OHNE intl

Erhält ein Artikel ein Vorschaubild (für Übersichtsseite), und kein Bild für Detailseite, dann:
Klick auf Bild in der Übersicht zeigt das Bilderverzeichnis in der Fancybox.
(Das hatten wir schon, aber jetzt habe ich mit dem neuen Master getestet.)
Außerdem wird auf der Detailseite - trotz Einstellung "kein Bild" das Vorschaubild von der Übersichtsseite angezeigt. Man kann es anklicken - in der Fancybox wird es einfach nochmal gezeigt.
Das - so vermute ich - liegt wohl daran, dass nach einem "best image" gesucht wird.
Das mit dem "best image" könnte wohl raus - oder?

Add to cart behavior is unintuitive

es tauchte ja schon mal die Frage auf, warum wellrad es ignoriert, wenn jemand denselben Artikel ein zweites Mal in den Warenkorb legen will.
Das ist Absicht und soll versehentliches Doppelbestellen vermeiden. Tut es auch und finde ich sinnvoll.
Einen weitenen Artikel mit einer anderen Variante nimmt er ja.

Aber das stillschweigende Ignorieren eines identischen Artikels führt zu Verwirrung.

Wäre es nicht besser, eine Abfrage einzuführen, etwa:
"Der Artikel befindet sich schon im Warenkorb. Wollen Sie einen weiteren bestellen. Ja? - Nein?

PS: muss nicht in vers. 1

Forwarding expenses off by one

Man kann einstellen, dass der Versand ab einem bestimmten Wert frei ist. Aber obschon die entsprechenden Labels von "ab" reden, wirkt die Einstellung wie "über". Beispiel: eingestellt Versandkostenfrei ab 50,00€: Warenwert 50,00€ ⇒ Versandkosten werden aufgeschlagen; Warenwert 50,01 ⇒ keine Versandkosten.

Siehe auch #14 (comment).

Products without detail-image

Werden Artikel/Produkte nur mit einem Vorschaubild aber ohne Bild (für Detailansicht) angelegt, gibt es Probleme:
Klickt man in der Shop-Übersicht auf dieses Vorschaubild, erscheint das Shop-Bilder-Verzeichnis(!!!) in der Fancybox.
zur Demo 1. Artikel: http://fhs.bplaced.net/xhshop-demo/?Shop

Mein Wunsch:
Bei Auswahl von "kein Bild" (an 2 Stellen) in der Artikelbearbeitung, sollte automatisch "no_image.jpg" verwendet werden.
Damit werden auch gleich ein paar Layoutprobleme behoben, die ich neulich feststellte.
Der <div> wird nämlich immer erzeugt und nimmt Platz weg, auch wenn gar kein Bild angezeigt wird.

Oder: no_image.jpg als default-Wert für jeden neuen Artikel.
Die Option "kein Bild" in der Selectbox damit ganz weg.
Wem das no_image nicht gefällt, kann es ja tauschen oder ein "weißes" hinlegen.

Add shipping cost notice

Meines Wissens ist für gewerbliche Verkäufe zwingend notwendig, bei jedem Artikel auf evtl. Versandkosten hinzuweisen. Im Shop, auf Detailseiten und im AddToCartButton
Es muss eine CMSimple-Seite z.B. "Versand" geben, auf die bei jedem Artikel mit "Versandkosteninfo" verlinkt wird, sie kann versteckt sein.
M.W. zulässig ist z.B. "66,- € inkl. MwSt., zzgl. Versand (Versand als Link)

ich habe mich aber für folgende zwei Zeilen entschieden (Platz ist genug):
inkl. MWSt. 19 %, zzgl. Versandkosten
Versandkosteninfo (als Link)

Ehrlich und transparent

Move help to standalone HTML files

Ich schlage vor die Hilfe, die derzeit im Backend direkt in der Seite ausgegeben wird, in CMSimple_XH typische standalone HTML-Dateien auszulagern. Das ist für eventuelle Übersetzer gewohnter, und auch individuelles Styling kann leicht angewendet werden, ohne das Pluginstylesheet damit zu füllen.

"Was ist neu?" gehört IMO gar nicht in die Hilfedatei, sondern besser in ein CHANGELOG, das eigentlich hier durch Github-Issues fortgeführt werden könnte.

"About" könnte im jetzigen Stil erhalten bleiben.