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

 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
 characters, etc.
 - 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
 could interfere.

 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/>
BuddyPress Trac