Description
While reviewing the current codebase, I noticed that a docblock comment still references an older hook registration pattern using Plugin_Name_Loader::run().
However, in the current implementation, hooks are registered via:
Plugin_Name::define_admin_hooks()Plugin_Name::define_public_hooks()
This makes the existing documentation misleading for developers using the Boilerplate as a reference.
Why this matters
The WordPress Plugin Boilerplate is widely used as a learning and production foundation. Accurate inline documentation is important to help developers understand the current architecture and hook lifecycle correctly.
Suggested resolution
Update the affected docblock to reflect the current hook registration flow without changing any functional behavior.
I’m happy to submit a small PR to update the documentation if this change is acceptable.
Description
While reviewing the current codebase, I noticed that a docblock comment still references an older hook registration pattern using
Plugin_Name_Loader::run().However, in the current implementation, hooks are registered via:
Plugin_Name::define_admin_hooks()Plugin_Name::define_public_hooks()This makes the existing documentation misleading for developers using the Boilerplate as a reference.
Why this matters
The WordPress Plugin Boilerplate is widely used as a learning and production foundation. Accurate inline documentation is important to help developers understand the current architecture and hook lifecycle correctly.
Suggested resolution
Update the affected docblock to reflect the current hook registration flow without changing any functional behavior.
I’m happy to submit a small PR to update the documentation if this change is acceptable.