Page tree

Versions Compared

Key

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

...

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

Image Removed

The old formatting:

Image Removed

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
languagephp
themeEmacs
titleStatic filter calls
    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.

Image Removed

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.