Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Language handling

Translations are handled from language and trbwc.pot is the template for all translations in the plugin. It is uploaded together with v2.2 of Resurs Bank older  languages, to Crowdin, which is supposed to simplify translations for the plugin. For this plugin you are very warmly welcome to help with the translations for all nordic languages here.

File structure

The main goal with this plugin was to become PSR-4 compliant. I also decided to work as WooCommerce initially did, where most of important calls were made statically. This may change over time, but many important features as of today is handled this way to become easily reachable. For example the options that are handled within the domain "rbwc" is handled through Data::getResursOption() and Data::setResursOption().

This is how the structure looks today.

FileDescription
Gateway/AdminPage.phpEverything that handles the adminpage, tabs and sections.
Gateway/ResursCheckout.phpThis is a complement to ResursDefault. It acts like a payment method only, and is limited to the actions that takes place in Resurs Checkout. This is where address logics resides for iframe specific events.
Gateway/ResursDefault.phpThe primary gateway script. Acts as a payment method, but in reality it handles serveral, dynamically. This is where most of the business logic and order creation takes place (except for API calls).
Module/Api.phpHandles all API calls to and from Resurs Bank, via EComPHP (which is the library provided by Resurs Bank to handle Resurs Bank actions).
Module/Data.phpData handler. Handles how to store and retrieve options. Handles prefixes for the entire plugin, logging, urls, paths and all actions that are data driven.
Module/FormFields.phpConfiguration container. Hold fields and defaults for options used in the module.
Module/Plugin.phpEvents and actions that takes advantage of the internal filters and actions are registered and handled here.
Module/PluginApi.phpAPI Calls for the plugin (front-to-back) are handled here. Mostly ajax calls and requests from the admin-interface. Most of the calls are nonce driven, and normally controlled by is_admin().
Service/WooCommerce.phpSpecific actions based on WooCommerce takes place here. It's a tiny one, and handles most of the generic gateway calling (the ones that happens before ResursDefault initializes).
Service/WordPress.phpActions that is limited to WordPress events. Header events, filters and actions are registered here. This is the primary initializator for the plugin. Centralized filters and actions (including the deprecated)  are applied from here.
Service/OrderHandler

This order handling section covers all API based orderdata. It was implemented when

Error rendering macro 'jira' : null
(Github issue #52) was rebuilt to make sure orders are synchronized between browser tabs. It is built to render the checkout cart properly, which is then being sent over to Resurs Bank as a an updated paymentRow list. Then intentions is also that this handler should be included in the afterShop handling, where orders can partially be annulled or credited.

Service/OrderStatus

During the discovery that we still have race conditions between callbacks as they are very much sent asynchronously from Resurs Bank (which ends up in duplicate stock handling problems - which has been a huge problem on the plugin market, where the order stock is reduced twice. Developers had similar problems with this, which led us to a forced minimum requirement of WooCommerce 3.5.0. This problem has been solved by putting an external OrderStatus handler in place, and then applying a WC_Queue to all updates that should be set on an order. The code update can be viewed here.

Error rendering macro 'jira' : null
(Github Issue #57)

WooCommerce 3.5.0 supported PHP 5.2.4 and up but PHP 7.2 was recommended.

templates/*Templates, mostly built on phtml, resides here. Using an internal template renderer for it. Normally you would want to make sure the write access is limited in this folder (they should never be rewritten, unless the plugin is installed or reinstalled).
vendor/*Complements to the plugin. EComPHP resides here for example.
  • No labels