This was generated by AI during triage.
Background
The DAL 2.0 custom post types (zerobs_customer, zerobs_quote, zerobs_invoice, zerobs_company, zerobs_transaction, zerobs_form, zerobs_event, zerobs_quo_template) are not registered anywhere in the plugin. register_post_type does not appear in the plugin's own PHP in any of this repo's 1,509 commits, so they were already gone when CRM was added to the Jetpack monorepo in January 2023. The removal happened in the pre-monorepo history, during the move to custom tables.
The code that handled them is still here. It cannot run, because get_post_type() never returns any of those values and WordPress will not route post.php or edit.php to an unregistered type.
Found while investigating #15.
The trap
'zerobs_customer' and its siblings appear in roughly 200 places across 45 files, and most of those are live code. The same strings are used for three different things:
- DAL object-type strings. Throughout the DAL, logging, and the MailPoet and portal modules. Live, load-bearing.
- A WordPress user role.
zerobs_customer is a role name, checked in the portal router.
- Actual post types. The dead subset.
A grep-and-delete pass would break the plugin badly. The removal has to be driven by context, not by the string.
What is genuinely dead
Post-type usages with no registered type behind them:
zeroBSCRM_add_admin_styles() in ZeroBSCRM.ScriptsStyles.php: the $post->post_type and $_GET['post_type'] branches, and the zbs_extra_custeditscripts action inside them. That action's replacement, zbs_postenqueue_editview, is live elsewhere in the same file and carries a comment naming the old hook, so extensions were migrated across deliberately.zeroBSCRM_is_ZBS_custom_post_page() in ZeroBSCRM.AdminPages.Checks.php, plus the sibling zeroBSCRM_is_customer_edit_page() checks and their callers in ZeroBSCRM.MetaBoxes3.Contacts.php and class-learn-menu.php. All now always false.- The
post_updated_messages filter arrays in ZeroBSCRM.AdminStyling.php. WordPress only uses these for registered types.
remove_meta_box( 'submitdiv', 'zerobs_invoice', 'core' ) in ZeroBSCRM.InvoiceBuilder.php.- The
WP_Query with 'post_type' => 'zerobs_customer' in ZeroBSCRM.CustomerFilters.php.
- Commented-out SQL against
$wpdb->posts in ZeroBSCRM.DAL3.Helpers.php.
What must stay
zeroBSCRM_database_reset() in ZeroBSCRM.Database.php. It deletes leftover DAL 2.0 rows from $wpdb->posts for these post types. Installs that upgraded from 2.x still have those rows, and this is the only thing that clears them. The post types being unregistered is exactly why the rows are orphaned, not a reason to stop deleting them.- Every DAL object-type and user-role usage from the three categories above.
A related bug in the same function
zeroBSCRM_add_admin_styles() opens with:
if ( $hook == 'post-new.php' || $hook == 'post.php' || $hook == 'edit-tags.php' || 'edit.php' ) {The last term is a bare truthy string, so the condition is always true regardless of $hook. It has no visible effect today because the inner branches all fail, but it should go with the rest.
Side effect worth confirming
edit.php?post_type=zerobs_customer currently returns a 500. Nothing in the UI links to it, and the URL only appears in post_updated_messages strings that never render. Worth checking whether anything else still generates such a link before or after the cleanup.
Why this is not ready-for-agent
The keep-versus-remove boundary needs judgment, particularly around zeroBSCRM_database_reset() and anywhere the same string is doing DAL work. An agent working from a grep would be likely to over-reach. Someone should decide the boundary first, and it may be worth splitting into a few smaller passes by file.
Extension impact
Low. Anything relying on these being real post types has been broken for over three years, so removing the handlers cannot make it worse. The one public function that disappears is zeroBSCRM_is_ZBS_custom_post_page(), which returns false for every caller today and would continue to behave identically if callers were left with the constant.
Background
The DAL 2.0 custom post types (
zerobs_customer,zerobs_quote,zerobs_invoice,zerobs_company,zerobs_transaction,zerobs_form,zerobs_event,zerobs_quo_template) are not registered anywhere in the plugin.register_post_typedoes not appear in the plugin's own PHP in any of this repo's 1,509 commits, so they were already gone when CRM was added to the Jetpack monorepo in January 2023. The removal happened in the pre-monorepo history, during the move to custom tables.The code that handled them is still here. It cannot run, because
get_post_type()never returns any of those values and WordPress will not routepost.phporedit.phpto an unregistered type.Found while investigating #15.
The trap
'zerobs_customer'and its siblings appear in roughly 200 places across 45 files, and most of those are live code. The same strings are used for three different things:zerobs_customeris a role name, checked in the portal router.A grep-and-delete pass would break the plugin badly. The removal has to be driven by context, not by the string.
What is genuinely dead
Post-type usages with no registered type behind them:
zeroBSCRM_add_admin_styles()inZeroBSCRM.ScriptsStyles.php: the$post->post_typeand$_GET['post_type']branches, and thezbs_extra_custeditscriptsaction inside them. That action's replacement,zbs_postenqueue_editview, is live elsewhere in the same file and carries a comment naming the old hook, so extensions were migrated across deliberately.zeroBSCRM_is_ZBS_custom_post_page()inZeroBSCRM.AdminPages.Checks.php, plus the siblingzeroBSCRM_is_customer_edit_page()checks and their callers inZeroBSCRM.MetaBoxes3.Contacts.phpandclass-learn-menu.php. All now always false.post_updated_messagesfilter arrays inZeroBSCRM.AdminStyling.php. WordPress only uses these for registered types.remove_meta_box( 'submitdiv', 'zerobs_invoice', 'core' )inZeroBSCRM.InvoiceBuilder.php.WP_Querywith'post_type' => 'zerobs_customer'inZeroBSCRM.CustomerFilters.php.$wpdb->postsinZeroBSCRM.DAL3.Helpers.php.What must stay
zeroBSCRM_database_reset()inZeroBSCRM.Database.php. It deletes leftover DAL 2.0 rows from$wpdb->postsfor these post types. Installs that upgraded from 2.x still have those rows, and this is the only thing that clears them. The post types being unregistered is exactly why the rows are orphaned, not a reason to stop deleting them.A related bug in the same function
zeroBSCRM_add_admin_styles()opens with:The last term is a bare truthy string, so the condition is always true regardless of
$hook. It has no visible effect today because the inner branches all fail, but it should go with the rest.Side effect worth confirming
edit.php?post_type=zerobs_customercurrently returns a 500. Nothing in the UI links to it, and the URL only appears inpost_updated_messagesstrings that never render. Worth checking whether anything else still generates such a link before or after the cleanup.Why this is not
ready-for-agentThe keep-versus-remove boundary needs judgment, particularly around
zeroBSCRM_database_reset()and anywhere the same string is doing DAL work. An agent working from a grep would be likely to over-reach. Someone should decide the boundary first, and it may be worth splitting into a few smaller passes by file.Extension impact
Low. Anything relying on these being real post types has been broken for over three years, so removing the handlers cannot make it worse. The one public function that disappears is
zeroBSCRM_is_ZBS_custom_post_page(), which returns false for every caller today and would continue to behave identically if callers were left with the constant.