bb_die() needs to be plugable

[_ck_]

Crashing a forum poster into a non-themed white screen and requiring them to hit the back button to fix an action is very unslick.

If bb_die() can allowed to be plugin replaced it can be made to do a variety of better alternatives like highlighting required form elements, pop-up divs, etc.

I'd rather the root problem were fixed instead.

We should make the bb_die screens more useful (by including more links - see #681).

We should maybe to better form validation (rather than using bb_die at all).

Form validation on the server side is pretty easy with the WP_Error class. Make a new WP_Error object that contains all the form errors: error_code = form_element_name, error_message = localizable_error_message.

Then, if there's an error, display the messages and use (array) $form_errors->get_error_codes() to figure out what elements to highlight.

I don't think client side (JS) form validation is all that useful for the few places we could put it.

How about at a minimum a custom bb_die template for the theme?

It actually could be the same as a 404 template, which correct me if I
am wrong, wordpress has but bbpress does not (yet) ?

It would just pass the appropriate message and then the forum operator could customize instructions, search form, etc.

(In [931]) Link back to front page on bb_die(). Fixes #681, see #690

bb_die() should die. It shouldn't run any PHP or call any actions.

I like the idea of custom-styled error pages, though. Perhaps we can include the active theme's stylesheet and see if the markup needs tweaking?

Custom-styled error pages are good for PR too. The number of times people have said "WordPress is teh sux0r" after seeing a WordPress styled DB error page on a slashdotted/dugg site is phenomenally large. (90% of the time, it's not even WordPress' fault, nor even the DB. Have a chat with your local, friendly sysadmin to find out why.)

690.diff for consideration.

Includes theme's stylesheet if bb_die is not called from the admin section.

This may make errors look completely hideous unless you're using kakumei.

Thoughts?

I really do think, though, that we should use bb_die() only in extreme cases. When errors are generated because of invalid data, we should just see if we can just output error messages on screen.

For example, when you try to write a new topic without any post content, we should show the user whatever page the were on, refill all the form elements they had filled out and have an error message appear above the form.

I'm revisiting this because I just noticed 0.9 still crashes people into an un-themed page. No other mature forum (or blog) software does this.

While the custom theme is simple answer, I'd like to see a real alternative in the error being handled by a plugin entirely.

ie. do_action('bb_die',$message,$title);

For example I'd create a plugin to deal with certain errors like posts being too short and return them to the posting area with the message displayed above the box or as a javascript pop-up.

[1702] contains a fairly ghetto implementation of a 404 template page.

Bumping this because we really should remove unthemed branding from the crash page if only to prevent a bad rep for bbPress like mdawaffe said.

Three possibilities:

1. move function bb_die to pluggable.php
2. change the header/footer functions to bb_get_header/bb_getfooter
3. call the header and footer via a do_action hook that can be unhooked and replaced by plugins

Anything new to this? I think it's pretty important to find a solution to this problem. And even though it's set as "back-end" it does appear to be as much a front-end problem in my eyes. A lot of "small" errors are being caught be this non-themed error-page. Like a blank post being posted by a user.

Milestone 1.0-beta deleted

Simple patch. bb_die should be pluggable with some do_actions.

The last patch wont let plugins use the bb_die() function.

I recommend adding another function say

bb_error_handler( $message /* Message to be displayed */, $scrollto = false /* If it is an error, then which element to scroll to */ ) /* Or make use of $args instead */

which could be called with the error message. Then the function would enqueue another script and css file which would make use of jQuery to display a nag message for error (like the BuddyPress Nav Bar, except the bg can be yellow and a close button) and use wp_localize_script function to echo the message. It would also scroll the user to the div specified in function so that the user could make necessary changes.

Ok, so no patch, entirely new process to be concieved, and a bug thats been aorund for 3+ years. Lets move this to 1.5, as it's not essential to getting 1.1 out the door.

Replying to kevinjohngallagher:

Ok, so no patch, entirely new process to be concieved, and a bug thats been aorund for 3+ years. Lets move this to 1.5, as it's not essential to getting 1.1 out the door.

So why did you moved this to 1.1 again?

Closing as wontfix since this won't make it in the standalone version.