![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#36210 closed enhancement (wontfix)
$table_prefix should default to "wp_"
| Reported by: | Shelob9 | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Database | Version: | 2.5 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
Currently failing to specify a table prefix causes WordPress to not load. Since users of all levels are often encouraged to edit wp-config.php, it could get accidentally removed. In fact, since everything else in wp-config is a constant, the variable definition there looks wrong.
So, I propose that "wp_" be used as a default prefix, since it effectively is already. If the site doesn't have any wp_ prefixed tables, then they will still get the same errors, but this could prevent a lot of sites breaking for a simple reason.
I am attaching a patch that, inside of WPDB::set_prefix(), resets the value of the $prefix argument to "wp_" if it is empty and we are not in multisite.
Attachments (1)
Change History (6)
#1
follow-up:
↓ 4
@
10 years ago
- Milestone Awaiting Review
- Resolution → wontfix
- Status new → closed
- Version → 2.5
#2
@
10 years ago
A better approach would be to display a friendly error message when the $table_prefix variable isn't defined, but I'm also not sure if this is a common enough problem to warrant that.
#4
in reply to: ↑ 1
;
follow-up:
↓ 5
@
10 years ago
All existing sites that do not use a prefix would effectively break with such a change.
All existing sites without a prefix set do not work. That is what this patch fixes.
#5
in reply to: ↑ 4
@
10 years ago
Replying to Shelob9:
All existing sites without a prefix set do not work.
I think I'd prefer that. If an error occurs that causes table_prefix to not be set correctly, defaulting it could be dangerous. If I have two installs, and I accidentally misspell the var as $tabel_prefix (e.g.) in the latter, I'd prefer to get an error than risk setting data on the wrong tables.
Hi,
I do fear that a change like this would break sites and do more harm than good.
All existing sites that do not use a prefix would effectively break with such a change.
For those who are making changes in the config file, I've not experienced any who have accidentally changed their DB prefix line (and I've walked quite a few people through there).