Beiträge von MysteryCode

    besteht standardmäßig die Möglichkeit die Ansicht zu ändern?

    Inwiefern willst du die Ansicht denn ändern?


    Auf die Reihenfolge des Prozesses kann man keinen Einfluss nehmen. Da die meisten Formulare auf der FormBuilder-API vom WSC basieren, sind diese prinzipiell per Erweiterungen erweiterbar und bis zu einem gewissen Grad beeinflussbar. Prinzipiell kannst du per CSS alle Teile der Formulare ansprechen und nach deinen Wünschen anpassen (lassen).

    Bitte beachte, dass wir keinen Support für individuelle Codeanpassungen als Teil unseres regulären Support geben können.


    bleiben die Buttons Registrieren und Anmeldung weiterhin vorhanden, wieso?

    Das liegt in der Tatsache begründet, dass Buttons im Gegensatz zu den meisten Eingabe-Objekten (aktuell) keine Abhängigkeiten unterstützen. Ich kann entsprechend zwar ein Formularfeld ausblenden, wenn ein bestimmter Wert gesetzt ist, aber keine Buttons.

    Ich bin mir relativ sicher, dass WoltLab das auch nicht implementieren wird, da das vermutlich ein sehr seltener Anwendungsfall ist und die Kosten den Nutzen übersteigen. Ich kann mir das gerne zu gegebener Zeit ansehen und prüfen, ob wir hier eine eigene Implementation vorantreiben können. Mit Shop 8.0 und 8.1 ist das allerdings nicht zu erwarten.


    Wäre es nicht sinnvoll, das Boolean-Feld generell weg zu lassen und Als Gast bestellen als Button einzufügen?

    Das produziert dann einen Seitenaufruf mehr, der nicht notwendig ist. Zudem würde es die technische Umsetzung verkomplizieren.


    Derzeit erwartet zusätzlich der Button "Registrieren" ebenfalls ein Benutzernamen oder eine E-Mail und ein Kennwort im Formular, wieso?

    Wie unschwer zu erkennen ist, beziehen sich die Daten, die im Formular des Shops abgefragt werden, auf ein existierendes Benutzerkonto. Es handelt sich hier um ein simples Login-Formular.

    Die Registrierung können wir leider nicht im gleichen Formular einbinden, da es sich hier um eine deutlich komplexere Integration handelt, in die zudem auch diverse Drittanbieter eingreifen. Würden wir das im Shop-Formular einbinden, müssten alle betroffenen Pakete Anpassungen vornehmen, mit dem Risiko, dass das gar nicht möglich ist, weil man dann ggf. die Installation des Shops voraussetzen müsste.

    Das Kennwort kann aus Sicherheitsgründen nicht mit in das Registrierungs-Formular übernommen werden. Bezüglich der E-Mail-Adresse habe ich ein Issue angelegt und werde für Shop 8.1 eine Unterscheidung vorsehen und das korrekte Feld ausfüllen lassen.


    Grundsätzlich finde ich den gesamten Ablauf sehr irreführend, gerade für einen "normalen Benutzer".

    Inwiefern?

    In der Regel wird zunächst ein möglicher Benutzer-Account abgefragt bzw. die Möglichkeit zur Registrierung angeboten. Anschließend kann entsprechend dem Kundenkonto bzw. muss bei einer Gast-Bestellung die Adresse angegeben werden. Darauf basierend entscheidet sich, welche Zahlungsarten zur Verfügung stehen und zum Schluss wird eine Bestell-Übersicht angezeigt, die explizit bestätigt werden muss.

    Verglichen mit einem großen Online-Händler, den wohl jeder kennen dürfte:

    Über den Warenkorb kann man auf "Zur Kasse gehen" klicken, hier wird man direkt mit dem Login-Formular konfrontiert. Sollte man kein Konto besitzen, wird man zur Registrierung weitergeleitet. Danach wird zuerst die Adresse abgefragt, anschließend die Zahlungsart, danach noch die Versandoptionen und rechts im gleichen Formular eine kleine Übersicht. Effektiv also genauso wie es von VieCode Shop gehandhabt wird, nur, dass wir das aus technischen Gründen und der Wartbarkeit halber in einzelne Formulare getrennt haben.

    Alle Informationen zum Stand der Updates für WSC 6.0 findest du hier:

    Gesunde Faulheit!

    Aber gesunde Faulheit wäre doch einfach den Update-Button zu betätigen? :P


    Da macht es nach meinem Empfinden eine Neuanfang weniger Aufwand

    Sagen wir es so: Ich habe vor ein paar Monaten ein Forum neu aufgesetzt und alle Daten importiert (weit mehr als über die gestellten Importer möglich ist). Das ist ein immenser Aufwand, war aber noch deutlich weniger Aufwand als Exporter zu schreiben, die jeden Fall abdecken.

    Ich glaube auch, dass das nur wieder ein ewiges Provisorium werden würde, bei dem in 4 Jahren niemand mehr weiß, warum es da ist und man es lieber nicht anfasst. :D

    Mit 5.6 wieder einen klaren Schnitt zu setzen dürfte optimal sein - dann kann der Code auch dank PHP 8.1.2 so raus, wie er im Repo steht. 😅

    Ich schätze die Release-Routine ist einfach noch nicht darauf ausgelegt, dass jetzt immer vorsorglich explizit die nächste WSC-Version ausgeschlossen wird und eine Freigabe dann auch ohne tatsächliche Änderungen an den Paketen in Form eines Updates erfolgen kann.


    Insofern abwarten und Tee trinken bis Peter dazu kommt die Releases zu packen und bereitzustellen. :)

    Ich habe das gerade eben getestet. Eine gute und eine schlechte Nachricht:

    In der initialen Bestellung des Abos steht kein explizites Datum. Das begründet sich vermutlich dadurch, dass das bis zur Freischaltung (und damit dem Beginn des Abos) einfach nicht bekannt ist.

    Ab der ersten Verlängerung lässt sich dann aber mit obigem Snippet der genaue Bereich ausgeben.


    Erst-Rechnung:


    Verlängerung (nicht Neu-Buchung!):


    An der Erst-Rechnung wird sich leider auch nichts ändern lassen, da die Daten zum Zeitpunkt der Erstellung der Bestellbestätigung und Rechnung nicht zuverlässig zur Verfügung stehen.

    Ich habe gerade beim Aktualisieren meines Rechnungs-Layouts festgestellt, dass ich wohl mal mein Template bezüglich Subscriptions erweitert habe:

    Smarty: vorher
                                    {if $product->invoiceSummary}
                                        <div class="small">{lang}{@$product->invoiceSummary}{/lang}</div>
                                    {/if}
    Smarty: nachher
                                    {if $product->invoiceSummary}
                                        <div class="small">{lang}{@$product->invoiceSummary}{/lang}</div>
                                    {/if}
                                    {if $product->type == 'SubscriptionRenewProduct'}
                                        <div class="small">{lang}{@$product->summary}{/lang}</div>
                                    {/if}

    Ich bin mir aktuell nicht sicher, ob das damals eine exklusive Lösung war oder allgemein brauchbar wäre. Mir scheint ich habe das damals zum Anzeigen des Abrechnungszeitraums genutzt. Ob das Snippet noch funktionstüchtig ist, kann ich aus dem Stegreif aber nicht sagen.

    Zur ersten Frage:

    Für einen Betrieb in der WoltLab Cloud müssen die Apps und Erweiterungen (egal von welchem Entwickler) zwingend im Plugin-Store von WoltLab erworben werden. Anderweitige Quellen wie ein Download oder externe Paketserver sind in der Cloud nämlich nicht möglich.

    Prinzipiell kann man Pakete manuell von WoltLab prüfen lassen, aber ich denke nicht, dass jemand so viel Geld rumliegen hat, wenn es auch anders ginge. ;)

    Nach der Freischaltung deines Kaufs im Plugin-Store müsstest du die Erweiterung dann ganz normal via Paketsuche im ACP installieren können. Im Zweifelsfall kannst du da bestimmt bei WoltLab auch nachhaken. :)


    Und zur Frage nach Benachrichtigungen:

    Normalerweise kann der Shop den Betreiber (also die in den Optionen hinterlegte E-Mail-Adresse) über neue Bestellungen informieren. In dem obigen Zitat ging es explizit um Partner, sprich, wenn die entsprechende Erweiterung (ich glaube sie heißt Mandaten-System / App Store) genutzt wird.

    Ich kriege bei jeder neuen Bestellung bwispielsweise eine E-Mail und schaue dann bei Neukunden, ob die Zahlung vollständig eingegangen ist, prüfe die Daten und schalte die Bestellung dann frei, wenn alles in Ordnung ist. Bei Bestandskunden nehme ich die Benachrichtigungen nur zur Kenntnis.