ws_bank_manage.htm and ws_address_manage.htm. The buyer stays on ws_product.htm or ws_subscription_manage.htm and edits the address and bank details in modal windows. Dependent variants are taken into account.
The modal windows are implemented with Bootstrap 4. The functions also work with other Bootstrap versions.The examples require jQuery and the WEBSALE function
ws_AJAXloadTemplate. The latter is included in the module for reloading templates or in the system or core library.Overview of the five templates
The order isn’t a recommendation but a dependency: step 1 loads the templates from steps 2 to 4 via AJAX. So build step 1 first and add the others afterward.
Step 1: Product detail view
This template carries the main load. It displays the subscription product, usesDC-FPAboOrderOk to check whether all requirements are met, and provides the three modal windows for login, address, and bank details.
ws_product.htm
ws_product.htm
The
DC-FPAboOrderOk flag is the core of the logic. Three checks set it to false: missing billing address, missing bank details, and missing interval selection. Only when all three pass is the checkout button no longer disabled.If you have additional requirements, simply add another line following the same pattern.Step 2: Login in the modal window
ws_login.htm provides the login and registration fields that step 1 loads into the modal window via AJAX. The entire subscription part is contained in the one-time parameter WS-OTP3(loginSubscription). The negated section above it ensures that the regular page content isn’t delivered along with it when the template is requested as an AJAX fragment.
Within it, WS-OTP1(NewUserSubscription) distinguishes between the login of an existing customer and a new registration. Both forms reference each other via ws_AJAXloadTemplate, so the buyer can switch between the two views in the modal window without leaving the product page.
ws_login.htm
ws_login.htm
The three
DC-SPRegisterParams…_set lines store the one-time parameters in session parameters. This is the only way the buyer can find their way back into the subscription context after registering or after a confirmation email.The links also carry otpsubscriptionprodindex and, for dependent variants, otpsubscriptionvarindex. This way, the modal window still knows which product was involved after switching between login and registration.Step 3: Billing address in the modal window
The subscription module needsws_address_manage.htm in two places. The upper block in ST-Ajax provides the plain address display that step 1 and step 5 load into their subscriptionAddress container. The lower block provides the address form for the modal window.
Again, a one-time parameter separates the two worlds, this time WS-OTP3(updateAddressSubscription). The page’s normal address form is kept in a negated section so that the customer account continues to work as usual.
ws_address_manage.htm
ws_address_manage.htm
Step 4: Bank details in the modal window
ws_bank_manage.htm is the most extensive of the four reloaded templates because it has to cover three states: displaying an already selected bank account, selecting from the existing bank accounts, and creating or editing a bank account.
The entire selection depends on SUBS-FixedPaymentCodeUsed(4). The value 4 is the payment method code for direct debit. The module uses it to check whether a fixed payment method for subscriptions is set in the shop.config and whether it is direct debit. Only then are bank details needed at all.
ws_bank_manage.htm
ws_bank_manage.htm
The example includes
ws-module-ajaxgeneric-1.8.5.js. This module is missing from the JavaScript library overview and is added here.BANK-SEPADirectMandateType(2) stands for a recurring SEPA mandate. If one exists, the bank details are locked and the buyer creates a new bank account instead.Step 5: Subscription overview in the customer account
ws_subscription_manage.htm is a new template that doesn’t exist in older shops yet. It shows all of the customer’s subscriptions and offers, for each subscription, the delivery interval, quantity, and the three buttons for deleting, pausing, and activating.
Here too, the delivery address and bank details are shown in modal windows. The two ws_AJAXloadTemplate calls at the very end fill the containers once when the page loads.
ws_subscription_manage.htm
ws_subscription_manage.htm
The price check in the listing is a useful detail:
PR-LoadData fetches today’s product price, DC-FPCurrentPrice_set stores it, and the comparison with SUBS-Data_PR_Price shows the customer a price change compared to the price at the time the subscription was taken out.Overview of the message codes
The listing from step 5 shows the success and error messages as numbered sections. The previous documentation doesn’t state which number is set when. The following tables have been added here. As a single tag,~MSG-Subscription_success~ and ~MSG-Subscription_error~ output the current code. As a section without a parameter, they are true as soon as any code is set. With a parameter, they check for a specific number.
Codes 9, 10, and 11 are missing from the sample listing. If you adopt it, add a message for these three; otherwise the page stays silent in case of an error.
Subscription states
~SUBS-Data_state_code~ outputs the state as a number; the four section tags query it individually. This has also been added here.
The sample listing labels
SUBS-Data_state_isactive, SUBS-Data_state_isnew, and SUBS-Data_state_istriggered all three as “aktiv” (active). That’s fine for display purposes, but it hides a difference: only for new subscriptions does SUBS-Buttonvalue_triggernewsubscriptions offer the button the customer can use to trigger the first order themselves.Compared to the previous documentation, nine places in the listings have been corrected: two typos in sample texts, a
span with href that doesn’t work as a link, the outside click on the bank modal (twice), which previously closed the address modal, and four instances of accessing the global event instead of the click function’s parameter.