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.
Image Removed
Image Added
| File | Description |
|---|
| Gateway/AdminPage.php | Everything that handles the adminpage, tabs and sections. Should this be moved to the Module section? |
| Gateway/ResursCheckout.php | This 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.php | The 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.php | Handles 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.php | Data 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.php | Configuration container. Hold fields and defaults for options used in the module. |
| Module/Plugin.php | Events and actions that takes advantage of the internal filters and actions are registered and handled here. |
| Module/ |
PluginApi| PluginHooks.php | API 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(). |
ServiceWooCommerce| Service/WordPress.php | Actions 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/OrderHandlerSpecific 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). | | Handles all API calls to and from Resurs Bank, via EComPHP (which is the library provided by Resurs Bank to handle Resurs Bank actions). |
| ResursBank/ResursPlugin.php | Workspace for Resurs Bank as long as filters/actions can be used to change the behaviour of the core code. |
| Service/OrderHandler.php | This order handling section covers all API based orderdata. It was implemented when | Jira Legacy |
|---|
| server | Tornevall Networks |
|---|
| columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | ef1f2374-e58a-319f-9d38-10348dbac859 |
|---|
| key | RWC-256 |
|---|
|
(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.php | 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. | Jira Legacy |
|---|
| server | Tornevall Networks |
|---|
| serverId | ef1f2374-e58a-319f-9d38-10348dbac859 |
|---|
| key | RWC-259 |
|---|
|
(Github Issue #57)WooCommerce 3.5.0 supported PHP 5.2.4 and up but PHP 7.2 was recommended. |
| Service/WooCommerce.php | Specific 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.php | Actions 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. |
| 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 and communication libraries resides here for example. |