I just looked through the monthly BuddyPress.org site stats –
655k visits in October 2010, 323k visits in April 2010 (six months ago), and 201k visits in October 2009 (one year ago). That’s some great growth!
I just looked through the monthly BuddyPress.org site stats –
655k visits in October 2010, 323k visits in April 2010 (six months ago), and 201k visits in October 2009 (one year ago). That’s some great growth!
The 1.2 branch is now merged with the trunk. Please test it out and report any oddities.
Big surprise! Cool!
Thanks a million, Andy!
I noticed a few oddities so far on my multisite setup. Best to report them as new issues on Trac?
Also, I was spot-checking commits from the last few weeks to the 1.2 branch, and I noticed that most (all?) of them were not in the merged trunk. Or am I nuts?
They should be, I merged from r2844 to current. There may be some instances where changes simply would not work with the changes in the trunk, in those cases the trunk wins. Let me know more details and I’ll see if we can get anything missing in.
Can confirm Boone’s suspicions. The trunk won quite a bit of conflicts.
There were quite a few places where the changes were not compatible. Hopefully not too many that were incorrect. It was a huge merge with significant changes that would not work together so it may take a little bit of work to get those aligned again.
Also – we should look to merge much more frequently to avoid these issues. That’s easier said than done though.
WOW! I wasn’t expecting that at all!
Nice! Thank you Andy, will be testing it out.
Dev chat is this evening, if there’s anything specific you’d like to discuss, please leave a comment.
What time?
Let’s bring it up an hour – 7pm UK, 2pm east coast, 11am west coast.
Perhaps check on the status of BP integration with the TwentyTen theme?
A bit of an update:
I’ll bring cake.
I’ll be there.
I’ll try ad join in too. A good a time as any to try and start helping out
Also – remember we are on summer time now, so it’s actually 8pm UK time, 3pm east coast, 12pm west coast.
May miss the dev chat, but wanted to note I haven’t forgotten (well, not completely) a BP child theme of twenty ten. Just have to sit down and pound out the rest of it,
I’ve been looking through the feature requests and there are a lot of awesome suggestions, great work everyone.
What do you think about keeping the new features for 1.3 to just one or two? The release of WordPress 3.0 is in April and I’d like to get a new version of BuddyPress released sometime soon after that. The 1.2 branch will be brought up to scratch in time for the release, but I don’t want the next version lagging behind.
I think we can knock off a couple of major requests for 1.3 – basic privacy (limit my profile to friends / followers / not in public listings) and improved XProfile field and group management. These features will be on top of WP3.0 support work and also an improved install/upgrade interface. We could then start the vote post WP3.0/BP1.3.
That also brings up another important point – the new install/upgrade interface. With this new interface I’d like to start highlighting third party themes and plugins more. So for instance in the new installation wizard there will be a final completion step that will highlight some of the most popular BuddyPress plugins. Site admins will be able to select a plugin they are interested in and perhaps even install it right there. Moving forward I strongly feel that BuddyPress should just provide the base feature set and the tools to build fantastic extensions. It’s then possible to start blurring the line between what is “core” and what is not. There’s no reason why the best component extensions can’t be given as much of the spotlight as bundled core components.
Something to think about, feedback welcome.
Support for segregated networks in a multi network install. I’ll provide patches.
Thanks Ron, I’ve got my eye on a couple of your tickets in Trac right now.
I really like the ideas you mentioned in regards to the upgrading & installing. Alot of great plugins have been added to /built for BP recently. So it might even spur more people to make some!
Andy-
I think this is a wise approach. WordPress 3.0 is a very important, big release. Reducing potential user confusion by limiting updates to BP 1.3 is a good idea.
The less confusion the better.
Also, the basic privacy features in 1.3 would very simple, I’d expect that if a site admin wanted to provide a more powerful solution they would install your privacy plugin. It could even inherit and extend the basic settings in BP when the time comes.
I like the idea of a basic versus advanced privacy option. As you know, my plugin offers extensive, granular control–perhaps too much control for some users. I am reworking the admin privacy settings to allow site admins to decide how much granularity they want in the privacy settings, but the solution you are thinking about is a great idea.
If and when the time comes to consider merging some of my work, I’ll be more than happy to work with you in making sure it is a seemless integration that meets the requirements of core.
I think even if there’s a basic bp_loggedin_user_can( $action ) function would be a good start. Even if that function just returns is_site_admin() for now, getting the function in the code for future versions would be a good idea.
This could always be mapped to “current_user_can” later?
Andy, how are you going to do the basic tri-feature privacy settings? In an “if” before all the template loops?
Probably via filters, I don’t really want to edit the templates.
What about a call to the new privacy core component from within e.g. bp_has_groups() functions?
I’m a fan of keeping it simple. Toss in a couple new items, cleanup some outstanding issues (like you said) and basically iron out any remaining bugs. Making sure it works smooth with 3.0 with the network on or off should be a given.
Also: Yes, I am still working on the child theme for 2010.
I think this is a great approach. BP is moving forward plenty fast already, I think keeping the focus on compatibility and stability is the way to go. I also like the idea of closely integrating plugins rather than constantly adding code to the core.
Totally agree Andy !
Please go ahead with Privacy-Features and X-Profile-improvement for BP 1.3
I guess that is enough work until the release of WP 3.0
Only after those 2 features are being integrated, go ahead with a user-poll for other features.
Many thanks,
Erich
if you could also knock-off the following ticket for BP 1.3, that would be a big enhancement for using Private-Groups:
http://trac.buddypress.org/ticket/2166
Thanks again !
LDAP authorisation with synchronisation of extended profiles & group membership . All of a sudden you could offer a social networking layer to the e-mail systems of millions of organisations / companies / charities / universities.
Basically agree with everything you said, AP.
So should we be testing/patching BP trunk on WP 3.0-alpha exclusively at this point in time? From looking at past BP releases, they seem to require the latest WP at the time of release, but being new to BP, I’m not sure when one makes the switch to the latest WP.
Nevermind. The answer was in the original post. That’s what I get for scanning
.
+1 on the idea.
Slow and steady wins the race, so everything suggested for BP 1.3 seems pretty good. Also like the idea of featuring plugins next to core components, as long as the exception is setup that they work with the version of BP the person in installing. Frustrating to go through BP setup and then the plugin has been updated, etc.
Excellent work so far Andy. I also agree with limiting the feature releases and focusing on implementation. Great idea to show third party themes and plugins as well and a nice motivator for developers to boot. Privacy is still a top requested feature in our community.
I read somewhere about activity stream meta types? Would like to know more about that and how we could extend the update form to various update types in the future.
Only problem with featuring BuddyPress plugins is how do you choose which ones to feature and which ones to not feature? See lobbying and bureaucracy and people offended that their plugin wasn’t chosen.
Some kind of community vote can at least be a part of that. BuddyPress as a platform should lend itself nicely to such a thing.
I would also think recommended plugins, via the most involved developers (apeatling, djpaul, jjj, etc.) would be nice.
I think to start with it will be a recommended list based on what works and what is most popular. Once the new site is up and this is all working we can start taking monthly votes, or recommendations. Or perhaps we can devise some sort of algorithm based on the number of downloads etc.
Andy, I think you nailed it with the previous list, but here’s my two cents ~ +1 @Ron_R (also eyeing your patches), +1 to current_user_can(), +1 REST/RPC/ATOM API, Privacy (of course), & +1,000 Pages for Components.
Best Software Downloads and Reviews. the most comprehensive source for free-to-trysoftware downloads on the WebBEST 4 DOWNLOADS
I’ve started making a list of internal code improvements and features I’d personally like to add to the list for the next version of BuddyPress, comments very welcome.
DJPaul – how are we looking for putting together a full list based on community feedback, ready for a vote?
Add to REST API the XML RPC API & ATOM API
I wrote a proposal for GSoC to write an API.
Great, please submit it so we can review.
sir i have prepared a proposal for gsoc shall submit directly or shall i show u and submit directly
Andy – I’ll pull it together for you and send it across tomorrow (Thurs) evening.
Great, thanks, please post it on here.
I’ve attempted to filter out totally out-of-scope things (“fork WordPress” was my favourite) but have left some interesting and some controversial things in… have fun.
http://spreadsheets.google.com/ccc?key=0AtgQiOrXrZ0ZdE5rUnRzTXB0VWtqTUtvVkp1Rk9lYXc&hl=en
All great suggestions Andy and I think they mirror most of what people have been asking for or talking about.
What about the ability to post to a blog from the activity stream?
I think that’s plugin territory.
add to activity stream the activity of a standalone bbpress installation.
This is out of scope, someone could easily create a bbPress plugin that does this.
Any word on Jeff’s privacy API? Could we work with him to integrate it into the core?
Not sure of the status of Jeff’s work, but we can definitely look at it if there’s a stable enough version sometime soon.
Though I haven’t tried it yet, I’d think the oEmbed plugin would be useful enough to make it into core. If it made it into regular WP core, why not BP core?
Yes, that should definitely make it in, good call.
I know there is a plugin for this (a kind of), but there should be definitely the option within Core, in order to invite people to Groups. I mean not just inviting people you have already friended, but mainly people who are not already registered at the website. So that at least “Group-Admins” are able to easily invite people they know.
Similar to this, but not limited to people who are already members, but people who are not members yet. Currently it is hard for a Group-Admin to get members to join his Group, because it is not possible to invite people to join the website or the specific Group, as this is currently not possible.
This is a currently a blocker and should be available in BP 1.3
http://dev.commons.gc.cuny.edu/2009/12/18/new-buddypress-plugin-invite-anyone/
You might want to look up the definition of “blocker”.
sorry for my wording, I am not an english-native-speaker.
Just rename it to “Beta-Blocker”
Since we’re throwing out ideas, what about a Buddypress “Editor” in addition to the already existing “Admin”?
Basically it would let us promote members to do everything that an admin can except for installing or editing new themes or plugins. That way we could have multiple users who keep an eye on the site that could moderate blog posts, comments, groups, and activity threads without the risk of someone editing a core plugin or theme file.
BuddyPress should handle redirects when component slugs are modified (e.g. changing the groups component slug to players define('BP_GROUPS_SLUG', 'players')).
Changing root components to pages would fix this.
How is BuddyPress addressing presentation on mobiles? is this inside bp-theme scope?
Which browser? Is there a particular issue? Best to discuss this on the forums.
No time to write a recap of the past dev meetup – unless someone wants to volunteer? You can follow the conversation via the log (start here and read up).
Topics for the next meetup? I’ll put forward a couple:
1. Current 1.2 status, remaining bugs, RC release and target final date.
2. Volunteers for making a BuddyPress theme extension pack for the new 2010 default WP theme (I think this would be pretty awesome).
Can you explain #2 a little better?
Also, probably not the right place to discuss, but have there been any considerations in adopting html5 into the latest 1.2 theme?
The most future proof way to use BuddyPress will always be by using and extending the default theme. However, another way I’d like to see begin to develop is “extension packs” for existing themes. These would be template packs designed to be dropped in to a specific WordPress theme that would activate and provide BuddyPress support. These extension packs would be supported and maintained by one developer or a team of developers.
Actually, now that I think about it, html5 considerations *would* be a really good discussion for a future dev chat. Maybe not this one, but sometime in the not-so-distant future.
re: #2 – we probably won’t be in the dev chat, but Ron & I volunteer to do the ad-on for the new 2010 default theme.
Great!
Just a thought here before I forget it – probably Andy will need to vet the add-on theme if, as this sounds like, he wants “official” BuddyPress support for the 2010 due to its prominence?
it’ll probably some extra code bundled to drop in the new default theme. haven’t quite sorted it out (and uh, run it by the boss man), but it needn’t be a whole new theme. child, maybe.
We could start throwing out 1.3 roadmap ideas for the new poll?
Sure thing.
No, the way to do this is make a forum thread and invite suggestions. Then once the results are collated, we talk about and select roadmap ideas in a dev chat, which we then throw into a poll.
Well damn. Veto’ed. Haha!
If you’re a plugin developer, please read this post:
http://buddypress.org/forums/topic/important-plugin-devs-read-this
Topics for the dev meetup:
1. Status of beta, bugs, release target.
2. Local sites and putting localization files in the core (bp-languages), string freeze.
3. How to handle broadcasting to plugin developers information on how to update their plugins for 1.2.
4. @reply discussion as per http://buddypress.org/forums/topic/wire-posts-in-bp-12/page/2
@Andy P.
Hello Andy, i comment you this: I need an solution for this problem! I Wait you can help me!
I want what if any visitor not is register user, no can view the activity stream of the all users and if can view an register form.
In few words, only can allowed to view de activity if is registered user.
Thanks for your reply and sorry for my bad english, i’m learning!
I believe there is a plugin that will do this if you have a search.
John James Jacoby 4:35 pm on November 2, 2010 Permalink |
As Donncha would say “Holy Shmoly!”
Robert 5:07 pm on November 2, 2010 Permalink |
Nice work, Andy, JJJ, and crew!
Andy P 5:08 pm on November 2, 2010 Permalink |
Here’s the graph, I like this trajectory.
John James Jacoby 9:55 pm on November 2, 2010 Permalink |
Wow we really suck this month (Nov).
Xcobar 5:27 pm on November 2, 2010 Permalink |
Wow
Really great stats!
Congratutalions – ; )
Xcobar 5:29 pm on November 2, 2010 Permalink |
Ops , “congratuLations” .
Bjoern 5:29 pm on November 2, 2010 Permalink |
Buddypress is awesome! Keep up the good work!
modemlooper 6:44 pm on November 2, 2010 Permalink |
why was there a big spike from 04 – 05 2010 ?
Andy P 8:02 pm on November 2, 2010 Permalink |
New site launch.
Greg 7:18 pm on November 2, 2010 Permalink |
Spammers.. It’s been overwhelming lately.
Andy P 8:02 pm on November 2, 2010 Permalink |
We just killed most of the spam accounts.