[buddypress-trac] [BuddyPress] #2566: [patch] “Send Private Message” and “Mention this User” Button Filtering

[buddypress-trac at lists.automattic.com]

#2566: [patch] “Send Private Message” and “Mention this User” Button Filtering
-----------------------+----------------------------------------------------
 Reporter:  jeffsayre  |       Owner:  jeffsayre                                         
     Type:  defect     |      Status:  new                                               
 Priority:  major      |   Milestone:  1.2.6                                             
Component:  Core       |    Keywords:  has-patch, security, privacy, abstraction, filters
-----------------------+----------------------------------------------------

Comment(by jeffsayre):

 Yes, some of these issues would not occur if we were working with a MVC
 construct that enforced tight separation between presentation and logic.
 But we need to stay within the WordPress method of coding and designing,
 so we'll have to be more creative and flexible!

 You are correct, hnla, in stating that placing a class within the div
 would be bloat if a designer decided to position the buttons as list items
 instead. Of course, that is where child themes come in. It is simple
 enough to create a new, radical design by overriding any default BP theme
 and its corresponding CSS.

 This last point is exactly where the issue we having been debating in this
 ticket becomes truly problematic and the reason why I did not repatch this
 ticket last night. If the CSS is abstracted into a templatetag function,
 then it becomes pretty useless if a designer changes the CSS in their
 child theme. The only reason I abstracted the CSS in my first patch was
 because that is the way it is currently done with the "Add Friend" button.
 I simply wanted to keep consistency between all three buttons and offer a
 viable means of privacy filtering.

 But, after debating this issue in this ticket, it is clear we need a
 better solution. So what are our options?

 1.) If Statements: They could work. It would then be up to each template
 designer to make sure that the conditionals remained in their new child
 template (if they made one). Otherwise, privacy filtering for those
 buttons would not work anymore for any site using that theme.

 2.) Graphical Buttons: Whereas CSS is a great tool for not only
 positioning elements but also graphical rendering to some extent, I'm not
 too sure of the desirability of using CSS to draw buttons--at least
 buttons whose visibility needs to be controlled by individual users via
 privacy settings. So, another possible solution would be to go back to the
 1.1.x way of outputting buttons. Back then,
 [https://trac.buddypress.org/browser/tags/1.1.3/bp-themes/bp-
 default/_inc/images/add_friend_button.gif they were graphic objects]. The
 CSS was used solely for positioning and not for any of the graphical
 presentation (i.e. button borders or button shading). However, even with
 the use of graphical buttons in 1.1.x, the CSS was still abstracted into
 the function.


 '''Final Assessment'''
 Thinking this through, perhaps the first solution is the best alternative.
 Using graphical buttons instead of CSS-rendered buttons would work, but it
 would cause another issue. The CSS would still be outputted even if the
 buttons where hidden due to privacy filtering. This would cause blank
 divisions which is just bad form.

-- 
Ticket URL: <https://trac.buddypress.org/ticket/2566#comment:16>
BuddyPress <http://buddypress.org/>
BuddyPress