#613 closed defect (bug) (fixed)
bp-message.php actions error on first run (e.g. install).
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | major | |
| Severity: | Version: | ||
| Component: | Keywords: | has-patch | |
| Cc: |
Description
Not sure how important this is, but it does cause an error in the web server log.
SITUATION: WPMU 2.7, BP from Trunk, Clean install.
NOTE: BP files already put in place before running WPMU install.
1) WPMU installs with some WPMU errors in the log. Not BP's problem. Anyhow.
2) On the WPMU "successful install here, remember to chmod your folders back to 755, here's your admin password, click here to log in page", no errors are generated. So far so good.
3) Then you follow the link to take you to http://example.com/wp-login.php. Again, no errors. You log in...
4) It takes you to http://example.com/wp-admin/ and we have errors! A bunch, but one bug at a time:
[Sat Mar 21 14:58:45 2009] [error] [client 127.0.0.1] WordPress database error Table 'wordpress.wp_bp_messages_recipients' doesn't exist for query SELECT unread_count FROM wp_bp_messages_recipients WHERE user_id = 1 AND is_deleted = 0 made by require_once, require, do_action, call_user_func_array, messages_setup_nav, BP_Messages_Thread->get_inbox_count, referer: http://example.com/wp-login.php
After tracking this back, I believe it to be caused because:
1) messages_setup_globals() sets up the table name variables (action priority of 1).
2) The call to BP_Messages_Thread::get_inbox_count() is in messages_setup_nav(). This is an action priority 2.
3) messages_install() creates the tables - via messages_check_installed(), but that doesn't have a priority specified so it goes to 10.
Therefore, the first-ever get_inbox_count() SQL query happens after the table name variables are set, but before the tables are actually created. I've added a priority to messages_check_installed() in the attached patch (priority 1).
This can look a bit ambiguous but messages_check_installed() is alphabetically before messages_ssetup_nav(). An alternative fix would be to move the later priorities out by one (there are a few other actions in this file with a priority of 3).
This only happens on the very first load of the admin pages, so obviously to do with the BP installation routines. Patch attached.
Grr, ignore the fact that I named the patch 612.patch. That's just to confuse you. :p