Plugin Boilerplate Generator

Example

With classes and all six options, the main file requires what it wrote:

require_once CONTACT_BUCKET_PATH . 'includes/class-contact-bucket.php';
require_once CONTACT_BUCKET_PATH . 'includes/class-contact-bucket-settings.php';
require_once CONTACT_BUCKET_PATH . 'includes/class-contact-bucket-assets.php';
require_once CONTACT_BUCKET_PATH . 'includes/class-contact-bucket-rest.php';

function contact_bucket() {
	static $instance = null;

	if ( null === $instance ) {
		$instance = new Contact_Bucket();
		$instance->hooks();
	}

	return $instance;
}
add_action( 'plugins_loaded', 'contact_bucket' );

and the plugin class constructs the rest:

public function hooks(): void {
	add_action( 'init', array( $this, 'init' ) );

	( new Contact_Bucket_Settings() )->hooks();
	( new Contact_Bucket_Assets() )->hooks();
	( new Contact_Bucket_Rest() )->hooks();
}

Two details in there are the point of the whole thing. The instance is built on plugins_loaded, not at the bottom of the file, so every other plugin has had its chance to add the filters yours reads. And hooks are registered in hooks() rather than in a constructor, so a class can be built in a test without attaching itself to WordPress.

The REST route’s permission callback is a real capability check:

'permission_callback' => array( $this, 'can_read' ),

Not __return_true, which is how plugins end up with public endpoints they did not mean to publish.