Page Comparison

...

• 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 

  Jira Legacy
  server Tornevall Networks columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId ef1f2374-e58a-319f-9d38-10348dbac859 key RWC-332

  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.

...