[buddypress-trac] [BuddyPress Trac] #6432: User feedbacks : Extend WP_Error and progressively stop using cookies to store messages.
noreply at wordpress.org
Wed May 13 09:55:43 UTC 2015
#6432: User feedbacks : Extend WP_Error and progressively stop using cookies to
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
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/>
More information about the buddypress-trac