...
This is how the structure looks today.
| 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/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/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(). | ||||||||||||
| Module/ResursBankApi.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). | ||||||||||||
| 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
| ||||||||||||
| 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.
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. |
...