[buddypress-trac] [BuddyPress Trac] #3659: Recently Active widget doesn't scale

[buddypress-trac]

#3659: Recently Active widget doesn't scale
--------------------------------------+---------------------
 Reporter:  mpvanwinkle77             |       Owner:
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  2.2
Component:  Core                      |     Version:  1.2.10
 Severity:  normal                    |  Resolution:
 Keywords:  needs-patch dev-feedback  |
--------------------------------------+---------------------

Comment (by r-a-y):

 > It looks like you've decided to store all cached instances of a given
 widget together to make invalidation easier.

 Yeah, that and if a site doesn't use a persistent object cache, the DB
 table could become bloated since a site could use multiple instances of
 the same widget.  Multiply that number if on multisite.

 The problem with my approach is like you said - the transient could
 potentially hold a large array of instances.

 Your approach is pretty good as well.  I could be just thinking way too
 conservatively though, so we'll most likely adopt your method. :)

 > With this setup, persistent caches will purge all of a widget's cached
 instances at once (according to whatever cleanup routine the admin has set
 up) instead of one at a time.

 This isn't necessarily true.  I invalidate a widget's instance if the
 widget is updated or deleted.  This is okay for the majority of widgets
 except for cases where the widget output is variable such as the Friends
 widget, which relies being on a user profile page.

 > // as per WP docs, transient keys can only be 40 characters in length -
 Your technique here will not guarantee unique keys if widget classes share
 the first 35 characters of their names.

 I was thinking about that myself!  As a first pass, I wanted to easily see
 what cached widgets were being added.  But when this gets finalized, we
 could use the md5() approach for the transient keys.

 > When applied to BuddyPress, each component should be responsible for
 registering its own cache classes. (I know that doing it centrally doesn't
 hurt anything because those widgets simply won't exist if the component is
 not activated, but still :) )

 Separating by component definitely makes sense.  Will definitely do that
 when creating a patch for core later on.

 > bp_widget_cache_add_wp_head_hook() is pretty hacky. Let's just add a
 do_action() hook in bp_update_user_last_activity().

 For sure, just needed to get something working in the meantime without
 hacking core.

 > Reaching into the $wp_registered_widgets global is truly terrible.

 Yeah I know!


 > But preliminarily, it looks like this is going to provide huge benefits
 for lots of BP sites!

 Yeah, I think it works quite well.  Could also be used in theory for any
 WP widget!

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