Code of Conduct and Migrations

Owned by Thomas Tornevall
Last updated: Mar 06, 2022

If this plugin is imported to the RB repository there are a few suggestions on how to do this.

Important

  • Make sure that documentation are updated even for smaller changes.
  • Make sure escaping/sanitizing guidelines are followed!
  • Make sure the domain and slug are renamed from tornevalls-resurs-bank-payment-gateway-for-woocommerce to resurs-bank-payment-gateway-for-woocommerce.
  • This plugin has a prefix for all actions, filters and data it uses: trbwc. This has to be reviewed and changed to match Resurs Bank, so that data is properly linked to the correct version.
    Make sure you verify that correct data is changed here as filters also are running under the short name "rbwc".
    The prefix itself is set in the initialization script of the plugin as a constant, so to change this part you should instead use the filter rbwc_get_plugin_prefix.  At least if you want to keep this forged and make it possible to import and export features between your own release and this.
    The trbwc and rbwc are also used in frontend scripts so keep in mind that it cannot be changed in ALL places.
  • The internal prefix for getResursOption and several features used for saving data is not affected by other slugs way of setting their own prefixes. This question was initially added here, as a part of the tests with different slugs/prefixes. A discovery that we could not change the prefix without breaking the database storage made me realize that the plugin should be transparent in its data saving. Example: If you run a forked edition of the plugin, but the decides to switch to the original codebase, data should not be entirely reset between the changes, but be transparent. 
    Error rendering macro 'jira' : null
    covers the same question.
  • For this plugin repository, make sure that no forks delivers the entire tree of older plugins.

Smart developing

  • If you are not happy with how parts of this plugin is built, before you start rewriting large blocks of code, check if there is a filter to handle what you want to change or build it based on filters; create a new applyFIlter (or action) and start build your own plugin part (there is plenty of space fo this). The create a pull request so that it can be imported if the idea behind the change could be an improvement for the official release.
  • Take a look at the merged commit, for an example of how to do "smart implementions". The example covers how to move a set of configuration from one tab to another without destroying the original codebase. This task is based on 
    Error rendering macro 'jira' : null
    where a config setting was supposed to move around configuration data. With this extra plugin, this setting could be enforced into a permanent state by changing private $forcePaymentMethodsToFirstTab = false; to true. As long as the slug belongs to the original codebase, this setting will not be fully enabled. In a fork, the intentions of this example (and fix) is to override the "slug rules". By doing this "smart", the original codebase and slugs can remain untouched and your fork can be entirely customized.

Coding standards, casings, etc (or: should I use snake_case or camelCase usages?)

You can read more about this in the Actions, filters, triggers section since this is just a sumup.

In the initiation of the plugin there was a constant added: RESURSBANK_SNAKECASE_FILTERS. The plan was to use camelCases even in the filter/actions. However, many plugins are using snake_case calls so the constant was put there as a permanent setting. When you use the internal WordPress::applyFilters and WordPress::doAction most of the work are automated. So internally, we hook up with camelCased filters an actions, like this: WordPress::doAction('doThisAction'). When sending this command to the filters and actions, it is in the same time converted to snakecase formatting.

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

Suggestions

  • Make sure your major release are updated with clear warnings about breaking changes on import.
  • Since plugin names are forced into the name used when submitted to WordPress "Plugin Name" must be renamed from "Tornevalls Resurs Bank payment gateway for WooCommerce" to "Resurs Bank Payment Gateway for WooCommerce".
  • Keep in mind that "What we want" is not the same as "What WordPress requires". Some things that eventually is for implementation may break WordPress guidelines. To make sure the plugin is not removed from the repo due to security issues, the guidelines must be followed.
    Read more: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/
  • The plugin is following PSR4-rules.

PHP Versions

This plugin follows a path that honors WooCommerce but takes merchant setups in consideration. By means, as of march 2022, WooCommerce recommends PHP 7.4 as the lowest target version of PHP very much because all other PHP releases has passed their end of life support. The plugin has not yet started to use higher PHP version support in the codebase, so currently syntax for PHP 7.0 is actively used. If you start using higher code syntax, 7.0 for this release must be honored for a while more.

trbwc vs rbwc

trbwc is actually the first work name for the plugin. That one was used as a slug for all translations before it had to be change to tornevalls-resurs-bank-payment-gateway-for-woocommerce.