[buddypress-trac] [BuddyPress Trac] #6432: User feedbacks : Extend WP_Error and progressively stop using cookies to store messages.

[buddypress-trac]

#6432: User feedbacks : Extend WP_Error and progressively stop using cookies to
store messages.
-------------------------+------------------
 Reporter:  imath        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.4
Component:  API          |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |
-------------------------+------------------

Comment (by boonebgorges):

 Our current cookie-based implementation stinks, and it would be nice to
 have the ability to show more than one message on a pageload.

 That being said, the suggested improvement seems overengineered somehow. I
 have a couple of concerns and questions:

 - Interfering in the redirect (`add_query_arg()`) seems like it's going to
 cause problems. What if we have a query arg clash? What will this do to
 caching? What about people who are modifying redirects in various ways?
 - What's the advantage of extending `WP_Error` to do this?
 - Are we going to have a recommended method for plugins to register their
 own feedback_messages? Do they have to have their own component to do so?
 What if, say, a messages attachment plugin wants to add items to
 `messages->feedback_messages`?
 - Keying error messages by integers increases mental overhead during
 development and debugging. Can we use strings? (I guess this doesn't
 translate well? Then again, `?error=2,6` is not exactly a pretty URL in
 any language.) If you're going to use numeric error codes, at least you
 can use these codes as the array keys for the `feedback_messages` array (
 `3 => 'foo'` rather than `array( 'code' => 3, 'message' => 'foo' )`
 - Abstracting the feedback_messages makes a bit more sense if any of them
 are shared between different error conditions. Is this the case?

 I feel like there's gotta be a way to solve the core problem without
 introducing such a large amount of overhead. How about, eg, storing errors
 in usermeta? (Not sure what that would mean for logged-out users.) What
 about URL-encoding the error message itself?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6432#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac