| Table of Contents |
|---|
...
- The plugin, when creating an order-api URLs, is using Woocommerce-approved components to generate a proper url based on which permalink setup you run with.
- The plugin first had plans to implement a filter that made it possible to add extra data into signing urls (where success/fail works) so that developers can pass their own values, but I realized that if someone implements data in this section in a wrong way, the entire URL sent to Resurs Bank could break. Therefore that plan has been revoked (
)Jira Legacy server Tornevall Networks serverId ef1f2374-e58a-319f-9d38-10348dbac859 key RWC-218 - The plugin is for the moment not splitted up based on modules like order management, callbacks, etc since most of the handling events occurs in the payment gateway.
- The plugin do not by javascript validate any customer data in the checkouts before sending it to Resurs Bank. This is almost entirely about false security that does not require very much to bypass and regex validation requirements may change over time, which is considered smarter to let the remote endpoint cover, than patching the plugin each time changes has to be applied to these parts. Besides from regex-keys that may contain errors, by hooking up to billing data fields will also bind us to less freedom regarding customized templates that may have different policies for handling specific data.
Special features
Each order in the order view will save its current API status
...
The admin functions are going into a more native state than before. Instead of bulked configuration rows, all settings are stored in wp_options per keyed row. See image below. This makes the configuration sections in the plugin less sensitive when it comes to serialized arrays. Everything are saved with a unique prefix that indicates that the data belongs to the plugin. The admininstration configuration are now also built with the WC_Admin_Settings API (output_fields method): https://docs.woocommerce.com/wc-apidocs/source-class-WC_Admin_Settings.html#191-671, which increases WooCommerce-version 3.4.0 as the least requirement.
...
The same thing occurs reversely on AJAX calls. This is something you can read more about in the Scripts and AJAX section. However, very shortly, when snake_case-based AJAX calls arrives, they are translated to camelCase requests in the primary Ajax-call handler ResursBank\Module\PluginApi. If the call above (doThisAction) was an ajax call, the action would be named resursbank_do_this_action. When handled internally it is retranslated to PluginAPI\doThisAction().
Other principles
- Always add since-docblocks in the code, so we always can refer from which version the feature was added. Best practice is to add it when we know which version we're working on, or before the major release if it is long-time pullrequests.
- We follow PSR-schemes and inspections like phpcs, mess detector and beautifyers. "NotCamelCaps"-inspections from WooCommerce are excluded.
Contribution Section
This is a section for contributors. If you thinking of helping develop the plugin this is where you should look.
How it is built
The first version was built in a halfway careless way; the purpose was to reach out for a PSR-4 variant, but due to the lack of knowledge, that never happened. It was neither never entirely released as the time ran out for it. The current version that is located in Bitbucket is however PSR-4 controlled. The purpose of this is to save as much performance and memory usage as possible, so the decision is put on just only load the parts of the plugin that is necessary to run with at the moment.
What is different compared with the inhouse version?
Everything.
- The codebase. You'd be scared if you look at v2.x
- With filters, actions and detailed logging for problem tracking.
- Data loss protection when bridging orders via Resurs Bank. Instead of having a big load of parameters in the url, we're happy with one single base64-encoded variable than can be decoded on its way back to the checkout without loosing original charset or content.
- The forms that handles getAddress-requests are being built into session handlers instead of running through long javascript controls, which means both selected country and eventually company data can be controlled on a better level.
Sidenotes and details
- The plugin, when creating an order-api URLs, is using Woocommerce-approved components to generate a proper url based on which permalink setup you run with.
Special features
Each order in the order view will save its current API status
Example: Your current credentials are "userTest". This user belongs to the test environment. You do a few test orders with this username and then change to production with "userLive". If you're going back to the old test orders, they will still be viewable but with the old credentials that belonged to the specific order. The metadata that takes care of this part of the plugin will create a unique keyset and encrypt each credential set with this and is not plain text.
This feature can be disabled from the advanced menu.
Saving configuration
The admin functions are going into a more native state than before. Instead of bulked configuration rows, all settings are stored in wp_options per keyed row. See image below. This makes the configuration sections in the plugin less sensitive when it comes to serialized arrays. Everything are saved with a unique prefix that indicates that the data belongs to the plugin. The admininstration configuration are now also built with the WC_Admin_Settings API (output_fields method): https://docs.woocommerce.com/wc-apidocs/source-class-WC_Admin_Settings.html#191-671, which increases WooCommerce-version 3.4.0 as the least requirement.
The old formatting:
Filter and action execution
The plugin has its own way to handle filters. There's a centralized place for where the magics happen and where the filters gets their proper names. It's not actually necessary, as it always runs the apply_filters method. See below:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
use ResursBank\WordPress;
WordPress::applyFilters('theNewFilter', 'theNewValue', []);
WordPress::applyFiltersDeprecated('theOldFilter', 'theOldValue'); |
The above two calls translates the filters to rbwc_theNewFilter and resurs_bank_theOldFilter. Running an IDE, this will cause this kind of look while using the filters, so the only purpose is to make it a bit clearer if we use new filters or old filters.
Filters are executed like the one above but the constant RESURSBANK_SNAKECASE_FILTERS, in the inital area of the plugin coverts them to snakecase for the moment.
Other principles
- Always add since-docblocks in the code, so we always can refer from which version the feature was added. Best practice is to add it when we know which version we're working on, or before the major release if it is long-time pullrequests.
- We follow PSR-schemes and inspections like phpcs, mess detector and beautifyers. "NotCamelCaps"-inspections from WooCommerce are excluded.
...