| Table of Contents |
|---|
...
This is a section for contributors. If you thinking of helping develop the plugin this is where you should look.
Code of Conduct
See more about the code of conduct here.
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.
...
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 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.
...
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.
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().
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.
...