Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


This is how the structure looks today.

Image Removed2022-03-10Image Added

Gateway/AdminPage.phpEverything that handles the adminpage, tabs and sections. Should this be moved to the Module section?
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/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/PluginHooks.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().
Module/ResursBankApi.phpHandles 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.phpWorkspace for Resurs Bank as long as filters/actions can be used to change the behaviour of the core code.

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

Jira Legacy
serverTornevall Networks
(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.


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
serverTornevall Networks
(Github Issue #57)

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

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.
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.