This page covers a live example on how to build external plugins to communicate with the main release. In this example, we intend to use a newer library the EComPHP, which no longer requires SOAP as a component. However, since the plugin has wider compatibility with PHP 7.x and the new library do not offer anything older than PHP 8.1 - we can not really import such feature in the current module. Doing so, will force all merchants up to the latest PHP version and as of today, this is not possible.
This is why we are building an extension to the main plugin, that is compatible with the new library.
Features covered in this documentation, why's and effects
- getPaymentMethods synchronization
This feature is mainly used for synchronization of payment methods used by the simplified shop flow and MAPI. This should be safely done as each API handles their own calls. During initial tests, you may want to keep the soap payment methods visible as the "SOAP method" can be different to the "MAPI method" (I.E. You normally can't create payments with MAPI based payment methods in the SOAP interface).
- getPayment information
This feature is used over several points of the parent plugin, so it is important that for example "aftershop" (payment management) is still running intact requests. The filters has to change so that old getPayment requests (if SOAP is required) can get relevant information for the payment management even if MAPI is active. Using filters to overwrite the ['ecom']-block in the payment information is therefore a very bad idea.
First step - Creating the loader and configuration
- To get pre-configured data from the main plugin, you can use the built in quick-method rbwc_get_option that is supposed to be used instead of an insecure filter.
- If you tend to build an implementation that injects itself into the primary plugin configuration, you will first need to handle the current configuration templates. This can be done with the filter rbwc_get_configuration_fields (see below).
Getting configuration fields
In the newly built extension we use the filter rbwc_get_configuration_fields to make sure that we can keep track on the original configuration array that resides in the main plugin.
It is also good to know that the extension will not function properly without its parent features. This is done by using the plugins_loaded action like this: