[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 imath):

 First, thanks a lot for your feedback.

 Feedback messages have a time of persistance limited to next page load
 (max). I wanted to avoid writing data into the DB, that's why i've used
 the url to pass feedback codes.
 Using user_meta seems the wrong moves to me, because as soon as we will
 delete the feedback message it will delete the whole 'user_meta' cache.
 URL-encoding the message will result in very unpretty urls :)

 But about the pretty urls concern, i'm not sure for this particular case
 it's a concern we should have, i think the real benefit of using pretty
 links is when you need to share them. I doubt people will be likely to
 share errors :)

 WP_Error: i think jjj suggested to extend it for this particular need.
 It's an interesting way of structuring a feedback > code, message and
 extra data. I need to extend it because you can't get a list of particular
 messages: you can get all, or one. This explains why the feedback messages
 are structured like `array( 'code' => 3, 'message' => 'foo' )` and not
 like` array ( 3 => 'foo' )`.

 > What if, say, a messages attachment plugin wants to add items to
 messages->feedback_messages?
 You're right this needs to be taken in account, and as the patch is a very
 first draft, it's not dealing with this possibility, i was just testing my
 idea :) I guess we can create a new method in BP_Component a bit like `the
 setup_admin_bar()` function works.

 I think (but i may be wrong) we need a standardized way of getting the
 message at runtime, and i think referencing errors using codes (numbers)
 is very common in software development (e.g.: 404). Moreover i can imagine
 the interest of these codes in unit tests :) I'm not sure using strings
 will be a great thing. About your concern on debugging: most of the time
 functions are returning false in case of an error with no extra
 informations, and i'm not changing anything to this. Are we using the
 `$bp->template_message` global for debug needs ? If so we can still get
 the error code global and fetch the message to set `$bp->template_message`
 with it if `WP_DEBUG` is on :)

 You're probably right about the query arguments potential clash. If we
 don't want to change anything to `bp_core_redirect()` to avoid this risk,
 is using keyed transients, a bad idea ? eg: `'bp-' . bp_loggedin_user_id()
 . '-feedback'` or `'bp-' . sanitize_key( bp_core_current_user_ip() ) .
 '-feedback'` if the user is not logged in.

 The easy move would be to directly store the message in it and forget
 about the `WP_Error` thing..., so of course we can just do that.

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