[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 13:52:09 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 boonebgorges):
Using cookies for feedback messages means a couple of things:
- There are weird character encoding issues. I can't find the tickets at
the moment, but a number of times in the past we've had double-escaped
- The cookie will be loaded and messages displayed on the very next
successful pageload. But this is not always the right place to show the
message. Say, for example, you do something in one tab, but then load BP
in another tab; the message will be shown on the second tab rather than
the first. This probably doesn't happen much in regular use, but I see it
fairly often during development (especially when errors etc result in
broken redirects and pageloads).
All this being said, the cookie implementation works fine, so I don't
think it's worth introducing a large infrastructure to replace it.
After hearing more about why you chose `WP_Error` to build this proof-of-
concept, I feel pretty sure that it's not the best idea. For one thing,
many of our messages are not errors at all :) It also seems like an abuse
somehow: `WP_Error` objects are meant to be developer-facing, and it's
likely that developers and site admins have developed workflows for
logging `WP_Error`-formatted errors. Using the class for our purposes
Despite what I suggested earlier, I think that a transient/usermeta is
probably not much of an improvement on the cookie implementation, and it
adds the overhead of going to the database (and interfering with caching,
as you note).
If there's a situation where the current cookie implementation is causing
specific problems, let's address them. Otherwise I guess I lean toward
closing this ticket.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6432#comment:5>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac