1. Objective

Omise-WooCommerce has always been coupled with WooCommerce plugin, which the plugin cannot be used as a stand-alone plugin and always require WooCommerce plugin to be activated first.
However, the legacy-codebase itself wasn't really aware of a case where WooCommerce plugin is disabled as much as it should be.

Although we have prevented such cases #78, and #83. But by the current design of the plugin-initial step, it still remains some issue (#90) that could be ceased out by redesigning the initial-step with a proper awareness of WooCommerce plugin.

Related issue(s):

• Omise-WooCommerce 3.2 can't be activated. #90 Omise-WooCommerce 3.2 can't be activated.

2. Description of change

Note: this refactoring would make a huge change on omise-woocommerce.php so I decided to make a series of pull-requests instead of throwing everything at once

By making a small change as much as possible in each pull request would also make me explain my thought better as well.

Feel free to let me know if you prefer to see the final product instead of a series of changes

Part 1

Enhancing the behavior of checking dependency plugin (in this case, WooCommerce).
I have done some researches on which "hook-event" we should hook to validate a dependency and initiate the plugin. And I have found 2 useful events, plugins_loaded and init.
ref: https://codex.wordpress.org/Plugin_API/Action_Reference

hook: plugins_loaded
According to the document:

This hook is called once any activated plugins have been loaded. Is generally used for immediate filter setup, or plugin overrides.

hook: init
Document says:

Fires after WordPress has finished loading but before any headers are sent.

Most of WP is loaded at this stage, and the user is authenticated. WP continues to load on the init hook that follows (e.g. widgets), and many plugins instantiate themselves on it for all sorts of reasons (e.g. they need a user, a taxonomy, etc.).

load_plugin_textdomain calls should be made during init, otherwise users cannot hook into it.

Hook plugins_loaded is fired before init.
For the first refactoring, I decided to have a dependency-checking at plugins_loaded then, send a signal to init event if the plugin can be initiated or not.

In case of WooCommerce plugin disabled, then the plugin should not initiate anything and stop itself from loading classes & registering stuff.

Here I choose to let plugin successfully activated itself and prevent it from initiating classes and hooks rather than disable the plugin as the current approach because in WordPress, there is no way to deactivate plugin right before the plugin successfully activate.

Meaning that, the actual sequences of the current approach are

• Plugin activated successfuly, WordPress displays Plugin activated message.
• Then, when admin page loaded, the plugin checks if WooCommerce installed, and deactivate the plugin in case of 'WooCommerce is disabled'.

Double messages, Omise menu is presented at the admin-sidebar. And because the plugin is successfuly activated, meaning that all of files have been loaded and executed once.

For the refactoring first-part. The plugin will be successfully activated even WooCommerce plugin is disabled but all classes and hooks won't be executed and instead, shows the message that "Omise-WooCommerce requires WooCommerce to be activated" first.

Part 2

See, #95: "Refactoring plugin-initial code structure - part 2: Relocating, renaming functions and method. "

Part 3

See, #96: "Refactoring plugin-initial code structure - part 3: Organizing Omise_Admin class."

3. Quality assurance

🔧 Environments:

• WordPress: v5.0.3
• WooCommerce: v3.5.3
• PHP version: v5.6.30

✏️ Details:

The main test-case will be separated into 3 cases as follows:

1. Attempting to install Omise-WooCommerce without WooCommerce should give you a warning message that Omise-WooCommerce requires WooCommerce plugin to be activated first.
   Omise-WooCommerce plugin can be activated, but all functions should be disabled, including no Omise menu at the WordPress admin-sidebar.

2. Install Omise-WooCommere plugin while WooCommerce plugin is enabled should give you a full-access to all Omise-WooCommerce feature, including the setting page.

3. Attempting to disable WooCommerce plugin while Omise-WooCommerce is still enabled should give you a same result as the case [1].

4. After the change, charge must be created, captured, refunded as usual.

4. Impact of the change

No

5. Priority of change

Normal

6. Additional Notes

No