Core components for the WordPress payment processing library. This library is used in the WordPress plugin Pronamic Pay: https://www.pronamicpay.com/, but also allows other plugin developers to set up a payment plugin.
Currently we often use 2 version updates/upgrades options:
Example 1
pronamic_pay_version
pronamic_pay_db_version
Example 2
pronamic_pay_mollie_version
pronamic_pay_mollie_db_version
The normal version is always upgrade 'directly' and the db_version only after manual clicking the "Run the upgrader" button in the WordPress admin dashboard.
We make this distinction because database upgrades sometimes cost more resources and users may want to make a backup first.
Yet this distinction is strange, because the normal version upgrade also creates roles via $this->create_roles() and flushes the rewrite rules via flush_rewrite_rules();, both are basically database actions as well.
Furthermore, the "Run the upgrader" button also requires updates/upgrades to be performed immediately. This while it is actually always better to perform the updates / upgrades in the background via https://actionscheduler.org/.
All this makes me think we need to refactor the update/upgrade process. Maybe we should just simplify this so that all upgrades just happen instantly. Of course, with heavy upgrades, a developer can choose to run them in the background.
If you also look at, for example, updating Google Chrome, the user never has to manually confirm an update/upgrade.
And the current install routine is only executed on admin_init, this not very handy for users who update via WP-CLI?
Currently we often use 2 version updates/upgrades options:
Example 1
pronamic_pay_versionpronamic_pay_db_versionExample 2
pronamic_pay_mollie_versionpronamic_pay_mollie_db_versionThe normal
versionis always upgrade 'directly' and thedb_versiononly after manual clicking the "Run the upgrader" button in the WordPress admin dashboard.We make this distinction because database upgrades sometimes cost more resources and users may want to make a backup first.
Yet this distinction is strange, because the normal
versionupgrade also creates roles via$this->create_roles()and flushes the rewrite rules viaflush_rewrite_rules();, both are basically database actions as well.https://github.com/pronamic/wp-pay-core/blob/c505efb9a7888fe5d15059804ad52fe617d4945f/src/Admin/Install.php#L139-L150
Furthermore, the "Run the upgrader" button also requires updates/upgrades to be performed immediately. This while it is actually always better to perform the updates / upgrades in the background via https://actionscheduler.org/.
All this makes me think we need to refactor the update/upgrade process. Maybe we should just simplify this so that all upgrades just happen instantly. Of course, with heavy upgrades, a developer can choose to run them in the background.
If you also look at, for example, updating Google Chrome, the user never has to manually confirm an update/upgrade.
And the current
installroutine is only executed onadmin_init, this not very handy for users who update via WP-CLI?https://github.com/pronamic/wp-pay-core/blob/c505efb9a7888fe5d15059804ad52fe617d4945f/src/Admin/Install.php#L72-L82
We currently have upgrades in the following extensions: