-
Notifications
You must be signed in to change notification settings - Fork 58
Add plugin architecture doc #3623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add plugin architecture doc #3623
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this. I left couple of suggestions, mostly about removing any references to code line numbers, as in case of changes, we would need to update the docs as well
|
@Narek13 thanks for the feedback, all line numbers are removed also I updated the modularity library name. |
|
Line numbers can be tied to a commit when they are really needed (Copy Permalink). But it makes more sense for huge files.
Fun fact: it's still Inpsyde in its readme 🐢 https://github.com/inpsyde/modularity |
docs/plugin-architecture.md
Outdated
| - Loads the Composer autoloader | ||
| - Checks for class existence to prevent conflicts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds a bit confusing if talking about class_exists( '\WooCommerce\PayPalCommerce\PluginModule' ). Maybe like this would be more clear:
| - Loads the Composer autoloader | |
| - Checks for class existence to prevent conflicts | |
| - Loads the Composer autoloader if needed (e.g. may be already loaded in some tests) |
| - Loads the Composer autoloader | ||
| - Checks for class existence to prevent conflicts | ||
| - Contains plugin metadata and constants definitions | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe should add that it starts the bootstrap process, in plugins_loaded hook.
docs/plugin-architecture.md
Outdated
| } | ||
| ``` | ||
|
|
||
| This allows modules to access services via `PPCP::container()->get('service.id')` after initialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules already have the container (and usually pass it where needed). PPCP:: is more about some third-party interop, such as api/order-functions.php or some tests.
docs/plugin-architecture.md
Outdated
|
|
||
| ### Module Interface Implementation | ||
|
|
||
| Most modules implement the Inpsyde Modularity interfaces (`modules/ppcp-api-client/src/ApiModule.php`): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Most modules implement the Inpsyde Modularity interfaces (`modules/ppcp-api-client/src/ApiModule.php`): | |
| Most modules implement the Inpsyde Modularity interfaces. For example in `modules/ppcp-api-client/src/ApiModule.php`: |
docs/plugin-architecture.md
Outdated
|
|
||
| - **ppcp-settings**: New React-based admin settings interface | ||
| - **ppcp-vaulting**: Saved payment methods functionality | ||
| - **ppcp-webhooks**: PayPal webhook handling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think webhooks fit more into core, iirc some things even will not work without them.
docs/plugin-architecture.md
Outdated
| // In modules with container access | ||
| $service = $container->get( 'service.id' ); | ||
|
|
||
| // In WordPress hooks after plugin initialization | ||
| $service = PPCP::container()->get( 'service.id' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // In modules with container access | |
| $service = $container->get( 'service.id' ); | |
| // In WordPress hooks after plugin initialization | |
| $service = PPCP::container()->get( 'service.id' ); | |
| // In our modules/services/extensions (also often passed to hook handlers via `use`) | |
| $service = $container->get( 'service.id' ); | |
| // In third-party plugins etc. (if not adding a custom module via the `woocommerce_paypal_payments_modules` filter) | |
| $service = PPCP::container()->get( 'service.id' ); |
|
@AlexP11223 thanks for the feedback, content is updated. |
This PR adds a new document explaining the plugin architecture.