Maybe throw a notice if signups table creation failed

[imath]

This is a suggestion by aaclayton

My live installation was using a database user who does not have table creation permissions (for security best practices). I've since re-installed BuddyPress 2.0 using a database user with administrative privileges, and the wp_signups table is alive and well now. It might be a good idea to put a failsafe in the BP installation script to make sure the wp_signups table was successfully created, and warn the user if it was not, since it will prevent new user registrations from occurring with no obvious evidence as to why.

[boonebgorges]

This seems fine to me, but let's try to make the language a bit more explanatory. How about:

"BuddyPress was not able to create a required table: %1$s. This sometimes indicates that your MySQL permissions do not allow for automatic table creation. Please create the table manually using the following query:"

[imath]

Replying to boonebgorges:

"BuddyPress was not able to create a required table: %1$s. This sometimes indicates that your MySQL permissions do not allow for automatic table creation. Please create the table manually using the following query:"

"Beaucoup Mieux!!" i'll update the patch using it.

[DJPaul]

This seems super edge-casey.

[imath]

Replying to DJPaul:

This seems super edge-casey.

I agree, and while testing it, i thought why doing it for signups table and not for other BuddyPress tables ? A reason can be that some admins do not expect BuddyPress to create this table on non multisite configs.. As it actually happened (#5575 comment 11)... hesitating

[boonebgorges]

Yes, it's super edge-casey, but it will totally break any website where it comes up. (And, as aaclayton suggests, there are legitimate reasons for setting up a server in this way.)

I think a decent strategy here in the medium term is to create a Codex page that addresses the problem of uncreated tables, along with some suggestions for fixing the problem, and then consider a more general check and warning for sites where the tables were not able to be created (which may link to the codex page).

Worth looking into: Does WP have any similar checks for when it needs to create tables, ie when you upgrade to MS?

[imath]

Replying to boonebgorges:

Worth looking into: Does WP have any similar checks for when it needs to create tables, ie when you upgrade to MS?

Nope! Just tested, there's the very ugly message "Error establishing a database connection".. And then user is stuck :(

[aaclayton]

I'll just chime in here as the edge case in question. This issue arose after migrating my site to a new hosting environment. I configured the new SQL server and created two users, one for the web user and one for administrative purposes.

For most database environments, it's arguably sensible from a security standpoint to give the application user account as few permissions as are actually required to function properly. I failed to consider the role of automatic WordPress installs, upgrades, and plugins which often automate some database management, particularly when transitioning between major versions.

The WordPress codex itself says for your SQL user to have global permissions: ​http://codex.wordpress.org/Installing_WordPress#Step_2:_Create_the_Database_and_a_User

I could hardly fault a WordPress plugin for not assuming that these sort of baseline instructions are met, so I would understand completely if you don't add an additional safety net in BuddyPress to protect against this sort of thing.

That being said, I will probably not have been the only person to experience this out of the multitude of BP users worldwide, and this sort of problem could be very difficult for a typical user to diagnose and correct.

[imath]

Just in case, updated the patch with boonebgorges 's explanations in his first comment.

[DJPaul]

Do bp_core_add_admin_notice() messages persist beyond the next page load?

If all thinks it's a good improvement to add this kind of alert notice for problems upgrading the signups table, I don't hugely mind, but I'd suggest putting the documentation/solution for the problem on the codex, and having the alert be more generic.

e.g. "BuddyPress found a problem when trying to manage user registration. [Find a solution here]."

User messages talking about database tables and MySQL and user permissions are complex (what's a table? why does this thing need to create one?), and if you don't know what this context is, I don't think our helpful message would be helpful. We need to be accommodating of the many users who install WP on a one-click shared hosting package, and install BuddyPress through wp-admin, and never touch wp-config.php or know anything about databases.

Moving the explanation to the codex allows us more space to explain what happened, why it's a problem, and the steps that the user can take ("you can ask your site administrator or web host to run this SQL script on your database", etc), and point any users to the support forums if they still have problems.

[imath]

Replying to DJPaul:

Do bp_core_add_admin_notice() messages persist beyond the next page load?

In this particular case, no because the bp_core_install_signups() function where bp_core_add_admin_notice() is used is only run during upgrade routine.

If all thinks it's a good improvement to add this kind of alert notice for problems upgrading the signups table, I don't hugely mind, but I'd suggest putting the documentation/solution for the problem on the codex, and having the alert be more generic.

e.g. "BuddyPress found a problem when trying to manage user registration. [Find a solution here]."

I also think it's a good idea, but this will need to put in this page all potential troubles, i guess. I found this page on the codex : ​http://codex.buddypress.org/getting-started/troubleshooting/

[johnjamesjacoby]

This error occurs at a low enough level where we should feel comfortable trusting the environment that's presented to us. If anything, let's consider an upstream patch to WordPress to implement a proper warning for everyone.

Closing as wontfix here.