A few months back a client brought me a block-based plugin they were proud of. They wanted it to become part of the WordPress ecosystem proper, maybe a canonical plugin, or at least hosted under the WordPress GitHub organization. “Ahmad,” they said, frustrated, “we’ve got this amazing code, but the path to getting it recognized and properly managed within WordPress’s official channels feels like a black box.”
They had already tried the obvious thing and pushed it to a public GitHub repo, on the theory that open source is open source. What came back was a list of questions nobody had answered. Who owns it in five years? What is anyone actually promising to maintain? How do you keep it in line with WordPress standards over time? Plenty of projects live happily without answers to those. A project that wants to sit inside WordPress does not. Assuming ordinary open-source habits would be enough for an official repository was the first thing that went wrong.
Why official WordPress GitHub repositories demand more
A personal GitHub repo is your playground. An official WordPress GitHub repository, particularly for a canonical plugin or a tool the project depends on, runs on different rules. The code is the easy part. What the organization is really asking for is shared responsibility, continuity after you lose interest, and a project that points in the same direction as WordPress itself. Go in without knowing the criteria and you get friction, then disappointment. The criteria published on make.wordpress.org set out the principles behind that:
- Community ownership, meaning no single point of failure. The code serves the project rather than a person.
- Responsible stewardship. Maintainers sign up for ongoing management, not just a launch.
- Quality assurance, because anything under the WordPress name has to hold up.
- Transparency about status, purpose and roadmap.
- Inclusivity, so outside contributors can get involved without the standards slipping.
What clearing the bar actually involves
Those principles come down to a handful of concrete requirements. You need documentation that states the problem and the goals, ideally linked from a Make WordPress blog post. Updates have to keep coming. An established Make Contributor team has to sponsor the project, and you need more than one active maintainer. That last one reads like bureaucracy until you have watched a useful project go stale because the only person who understood it changed jobs.
The maintenance side is a real commitment: triage issues while they are still fresh, answer people, say what changed, and follow the WordPress coding standards. If you register custom post types, register them in a plugin rather than a theme, and use proper text domains so the strings can be translated. Roughly like this:
<?php
/**
* Plugin Name: bbioon Custom Post Type
* Description: Registers a custom post type for client projects.
* Version: 1.0.0
* Author: Ahmad Wael - bbioon
* Text Domain: bbioon-cpt
*/
function bbioon_register_project_post_type() {
$labels = array(
'name' => _x( 'Projects', 'Post Type General Name', 'bbioon-cpt' ),
'singular_name' => _x( 'Project', 'Post Type Singular Name', 'bbioon-cpt' ),
// ... more labels
);
$args = array(
'label' => _x( 'Project', 'Post Type Label', 'bbioon-cpt' ),
'description' => __( 'Client Projects', 'bbioon-cpt' ),
'labels' => $labels,
'supports' => array( 'title', 'editor', 'thumbnail', 'custom-fields' ),
'hierarchical' => false,
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'menu_position' => 5,
'show_in_admin_bar' => true,
'show_in_nav_menus' => true,
'can_export' => true,
'has_archive' => true,
'exclude_from_search' => false,
'publicly_queryable' => true,
'capability_type' => 'post',
'show_in_rest' => true,
'rewrite' => array( 'slug' => 'projects' ),
);
register_post_type( 'bbioon_project', $args );
}
add_action( 'init', 'bbioon_register_project_post_type' );
?>Nothing in that snippet is clever, which is the point. It has a plugin header that says what the thing is, _x() and __() around the strings for translation, and a bbioon_ prefix on the function and text domain so it does not collide with somebody else’s code. Those details are what keep a plugin compatible and maintainable once other people are working on it.
Lifecycle and security
Then there is the long game, which is repository lifecycle management. A project that stops being maintained and is not a canonical plugin gets archived. Six months without a new maintainer and it is gone from the active list. Security has its own rules. Do not assume an experimental repository falls under the project’s HackerOne bug bounty, because it only does if it is explicitly listed. When a vulnerability turns up, coordinate with the Security Team quickly. The whole community’s trust in these repositories rests on that part working.
Where this leaves you
Getting something into the WordPress GitHub organization, whether that is a canonical plugin or a block theme, takes more than code that works. It takes community standards you are willing to follow, maintenance you can sustain, and a working knowledge of how the project governs itself. Skip that and the likely outcome is a repo that stalls and never really becomes part of WordPress.
This gets complicated quickly. If you are tired of debugging someone else’s mess and want your site to just work, send my team a note. We have most likely seen your version of it.
