A few weeks ago, BP’s internal metadata functions, like
groups_update_groupmeta(), were refactored to use WP’s core
_metadata() functions. See #4551
During the refactoring, special care was taken to preserve the exact behavior of each function, including the oddities and quirks (and bugs) that they’ve accumulated over the years. Now that a functionally identical refactoring is complete, I’d like to address these oddities.
If you’ve ever used one of the metadata functions from the activity, blogs, groups, or xprofile components, please read #5399 and review the proposed changes. A few of them are straightforward bugfixes that shouldn’t ruffle any feathers. Others are improvements that will break backward compatibility in some hypothetical edge cases, but in each instance I’m not aware of any actual edge case. If you have feedback – including pointers to existing plugins, themes, etc that would be broken by any of the proposed changes – please leave it here or on that ticket.
Thanks for participating.
I’ve caught up with yesterday’s devchat and to me it seems that messages are not something fully understood or making sense to all. This I also apologise if has been my fault. As always I have been and am around on Skype or IRC if you need to chat about things. I’m creating this post to hopefully set that straight.
Lets start with what everyone should know and that’s the main wireframe here (I’ve removed the member panel to keep us focused on what we’re doing as that has gone now).
The points I think it’s good to work on are these:
- Lets not redo or create a new wireframe layout (note I say new). Now is not the time and we already have one. This was decided on a while ago and important we don’t deviate at least. I’m keen we don’t go back to the drawing board, whilst it’s amazing that people are thinking about layouts, now is not the time to start afresh when we have a design.
- The above said, if the design is unworkable or causing us issues, we should review including it. We are rather late in the game as it is with this because of delays.
- If we do drop it, I am not and haven’t ever suggested we just leave default. My suggestion has always been we do a minimal refresh just not the layout. I would not be suggesting we bring any default CSS over – that’s not what has happened in any area.
Hopefully this has cleared up things. I am keen to move things forward, with that in mind I suggest the following:
- Please ask here any questions and we can get them answered. If not here, lets get them answered in the meeting.
- I’m a little bit concerned we’re not talking / interacting as effectively as possible. The dev chat was the first I heard about needing more wireframes. I’m keen we all keep communicating but with solutions. We have talked around things a lot now is the time for action.
- If we do not have a beta by Wednesday’s dev chat on 5th March.
- I will create a minimal patch that if we do not have something by Wednesday it goes up. This will make sure messages happens but not be all singing and dancing and a simpler layout.
- Request here any wireframes and we can make sure they get done. Anything unclear can have a wireframe made up. To this point I have made a few more here:
Replying to a message:
I’m excited we can get something happening but also cautious we do not overcommit and not get this released.
#weekly-updates time! As I write, it’s only about 303 days to Christmas, and about 30 days until the scheduled date for 2.0 beta 1. For people who are contributing towards specific tickets for 2.0, how are they going? Please post a status update here prior to Wednesday’s dev chat. Thanks!
BuddyPress uses ‘last_activity’ data extensively: for display purposes (‘last active 3 days ago’), to sort results, and to determine whether a WP user is a valid site member. At the same time, ‘last_activity’ has been a perennial performance bottleneck. In the case of users, the information was stored in
wp_usermeta. This table gets exceptionally bloated on busy sites, and it’s not properly indexed for the sorts of
ORDER BY queries we were performing on it. See #5128 for more background.
A fix for this longtime issue is in place for BuddyPress 2.0. (See r7860.) Short version: user last_activity data is now stored in a ‘last_activity’ row in the
wp_bp_activity table. We’ve modified our core queries to take advantage of the new location. And we’ve done a bit of trickery to make sure that the
wp_bp_activity table is available for storage, even if the Activity component is disabled. The performance improvements are pretty extreme; I’ll post benchmarks as we near 2.0′s release.
Plugin developers who use user ‘last_activity’ data are urged to account for the new schema. In the past, you may have accessed user last_activity like this:
update_user_meta( $user_id, 'last_activity', $time );
$last_activity = get_user_meta( $user_id, 'last_activity', true );
You are urged to use our API functions instead:
bp_update_user_last_activity( $user_id, $time );
$last_activity = bp_get_user_last_activity( $user_id );
In cases where you are making direct database queries based on this info, please consider using
BP_User_Query instead. At the very least, you should refactor your queries to use the new schema.
For the time being, ‘last_activity’ data will continue to be mirrored in
wp_usermeta, so your plugins will continue to work. However, you’ll get deprecated notices every time you use the
_user_meta() functions to access the information. And hey, the new way performs much better, so you’ll want to update anyway.
Here’s a list of the plugins I found in the wordpress.org plugin repo that will need updating:
Questions regarding this change? Need help migrating your code? Please leave a comment below.
(A quick note regarding ‘last_activity’ for groups and blogs. The basic problem there is the same as for users, but the scaling issues are much less severe, so they have not been touched for now. Keep an eye out for relevant updates.)
Once upon a time, we had #agenda posts going up once a week before the dev chat. They kind of died out when we switched the frequency and time of the dev chats around, but now that we seem to be on a bit of a roll again, I’d like to suggest we try something similar.
The goal is to put individual updates in a more visible place (finding the IRC logs is kinda tricky) and, by moving a lot of the updates to this site, to free up more time in the dev chats to give everyone more time to talk to each other synchronously and ask questions. If a feature developer has other time commitments for a particular meeting, moving the updates to the bpdevel site will make sure that everyone has the opportunity to read an update from them. Let’s see how this works for a couple of weeks, and we can make changes as necessary.
I’ll publish a #weekly-updates post on this site every week, and for everyone who’s contributing to a ticket, please leave a comment on that week’s update post with a summary of you’ve done. As a prompt when writing these: tell everyone what you contributed to last week, and what you’re aiming to do this/next week.
- We are now on track with the coding sprint as of Monday.
- A flurry of commits happened over the weekend.
- The major overhaul weekend task was to bring back the ids and classes to stop breaking scripting. This was quite an overhaul but worth doing.
- I am waiting from @hnla to hear about if you are going to take on messages – hope you are. (You have Trisha offering to help with that team which is great).
- We have most basic styling in – the sprint now moves onto styling, padding and making it look less thrown on a page
- Motor motor motor as speed through the code sprint fortnight.
- We could do with more hands on the sprint as we push on with issues – we are still at the template end though. As always if you want to do an issue or help please add note on github issues: