Default table name for main site

What do sub-site tables look like? wp_1_2_x or wp_2_x? Could it be that wp_1_ is the installation’s base table prefix?

It could be someone in the past had manually deleted the true main site tables and you are actually seeing a sub-site made into the main site by some rewrite rules or something.

Constructing a table name with $wpdb->prefix will include the appropriate blog ID for the current blog, so the result should be correct regardless of site or prefix. IMO, other plugins should not need to directly access another’s table. The table creator would ideally provide proper functions to query its tables without other plugins needing to resort to SQL. I realize this may not be the case here, I did say “ideally”.

In any case, if this and any other plugins all constructed the table name from $wpdb->prefix, they should all be able to access that table by its correct name. It’s more about consistency than any specific name.

Thanks for your reply.

As I was mulling over what I saw in phpMyAdmin, the thought did cross my mind because the sub-site tables are in the format wp_2_x and WP documentation states that the main site tables are unnumbered while sub-sites’ tables are numbered.

I checked wp-config.php and the table prefix is set to ‘wp_’ but searching the database yields no results for any unnumbered tables like ‘wp_options.’ Furthermore, in wp_1_options, the siteurl value is the main site’s url. So it would seem like someone manually deleted the true main site tables as well as the main site. This installation is pretty old ( Links Manager is still in use ) – maybe doing this with the main site tables was something they thought would be beneficial?

In this situation, would I be able to rename the wp_1_x tables created by the plugin to wp_x so that the plugin will actually find the tables? I don’t want to create the table manually, and since the plugin did create correctly formed tables, they should work better than something I’d try to recreate. What doesn’t sit well with me is the inconsistency of this set up – pulling data from two differently named sets of tables. Unless the name of the table is ‘superficial’ in the sense that it’s only a table name.

The ultimate solution would be to rebuild the site so that it is properly organized. Hardly justifiable just to get a plugin working. Maybe justified to have a stable, sustainable site well into the future.

Mirroring tables just to have alternate names would be the worst solution IMO. You are right to not have this sit well. Bluntly, it’s a terrible idea. I wonder if there is a way to have a table alias similar to domain aliases or symlinks (aka file shortcuts). I’m not that well versed in SQL.

It’s still not clear to me why you wouldn’t create the table from the start as "{$wpdb->prefix}foobar" if “foobar” were the plugin/table base name. When the “main” site is active, this should create a table named “wp_1_foobar”. Is it that this one table needs to be accessed from all sites? If so, what value does $wpdb->base_prefix contain? I would expect it to be wp_1_ for this site. It’s normally the prefix assigned in wp-config.php, but is easily overridden.

Global tables should be named "{$wpdb->base_prefix}foobar". What are the blogs and site table names for this site? wp_blogs or wp_1_blogs? In any case whatever the answer, if the table were created as "{$wpdb->base_prefix}foobar" and accessed as such as well, it wouldn’t matter what the assigned value is. It is consistently used, so the plugin can access its data regardless. For that matter, if the table were simply named “foobar” when created and when accessed, all would be fine.

As long as the name at creation is the same as the name during access, what the name or prefix is wouldn’t matter. The naming process just needs to be consistent. If the table name is wp_1_foobar but you are trying to access it with wp_foobar, there is a lack of consistency somewhere.