Multisite Replaced By Same Posts Database

[allcalmarketing]

I have everything set up working correctly with the below. It's multisite and the second database is a standard WP setup. The function successfully connects the root multisite with the second posts and postmeta database. How do I replace all the multisite post and postmeta with the same standard WP post and postmeta database table?

global $wpdb;
$wpdb->add_callback( 'db_callback' );
function db_callback( $query, $wpdb ) {
if ( $wpdb->base_prefix . 'posts' == $wpdb->table || $wpdb->base_prefix . 'postmeta' == $wpdb->table ) {
return 'wpposts';
}
}

[allcalmarketing]

I figured out a solution..... I added $query = preg_replace('/wp_\d+_/', 'wp_', $query); in the public function query( $query ) {

Next question, is there a way to only partition post_type=product and the corresponding postmeta?

[JJJ]

I figured out a solution..... I added $query = preg_replace('/wp_\d+_/', 'wp_', $query); in the public function query( $query ) {

Awesome! Nice job.

is there a way to only partition post_type=product and the corresponding postmeta?

Unfortunately, not easily or natively.

You'd need to query wp_posts manually each time to get the post_type from the ID'd row, and go from there.

It likely would not be worth it to keep a custom table to map IDs to post types, because the core table is already indexed & optimized.

[allcalmarketing]

Gotcha. The use case was more along the lines of sharing a single database of products with a number of other sites. There's a ton of ways to import or "sync" but actually sharing the same database of tables with read only would be clean. The reason for the product segment is because the satellite sites would have their own individual pages and posts.

[JJJ]

Please revert the edit to LudicrousDB::query(). Rewriting every multisite table prefix inside the database class bypasses normal routing and will be overwritten on upgrade. More importantly, making every site use one posts and postmeta pair collapses WordPress's site-level table isolation; IDs, schema upgrades, plugin assumptions, and writes can collide.

Routing only post_type = product rows is not a safe LudicrousDB partition either. LudicrousDB selects a database connection for a table/query; it does not split rows within posts. Many reads do not include a post_type condition, and product metadata lives in postmeta, where the type is not known without joining back to posts.

The safe boundary is the complete table pair (usually the complete site table set), not selected rows from those tables. If the goal is shared products across sites, use a purpose-built multisite product-sharing layer or a synchronization/indexing design rather than rewriting core database queries.