Forum Replies Created
-
In reply to: bbPress 2.0: designed for scale?
Thanks JJJ. This clarifies things and I understand the priorities.
And I’d be very interested to see bbPress 2.0’s perf on one of the big .org forums.
BTW, I think this issue is orthogonal to deep integration. It is really about…
1. The size of the posts table relative to a typical WordPress blog posts table
2. The fact that there is no denormalization to eliminate huge complex queries
This isn’t an issue for a Worpress blog, even a massive multisite installation like WordPress.com, because the posts table for each blog is separate and there is seldom a need to do a cross-blog query. This means that WordPress for blogs can scale nicely without too many tricks.
One potential solution is to create a helper table that denormalizes the things you need and points to the actual post in the wp_post table.
In reply to: bbPress 2.0: designed for scale?It has been a month and I think that this is a worthwhile thing to discuss, so giving it a bump.
In reply to: What should be a Plugin, and what should be in CoreMatt, we’re at cross purposes. Your previous definition of “core plugin” aside, I still don’t quite understand why it wouldn’t be useful to have a place in the taxonomy for something that…
1. is a plugin
2. is released with core (same release criteria etc.)
Like akismet today. I think there are a ton of advantages, but I’ve mentioned them above and I won’t belabor them. I didn’t suggest that it was necessarily 80% functionality, so maybe it does fit your definition of core plugin to some extent.
I guess “bloat” is a bit pejorative and wasn’t my intention to poke at WordPress. But any large piece of software needs to have a strategy to deal with the inevitable growth of the code base as it evolves.
In reply to: Taking a look at bbPress 0.9> two dozen users that insisted on using “Greg” as their display name and similar avatars?
With normal users in a healthy forum with a sense of community, duplicates will self correct. People will create unique pictures to identify themselves.
With malicious users, that’s a moderation issue and should be an isolated incident in a healthy forum.
In an unhealthy forum you have bigger problems than duplicate profile pictures.
Like I said earlier in the thread, a lot depends on the nature of the forum. If it is a tight knit community, then you really don’t need to compromise the user experience to cater for the edge case you describe.
But in a support forum I could imagine this being more of an issue so I wouldn’t use non-unique display names in that situation.
Thanks Chris. There is one place I see akismet hooked up to the bozo plugin. When the Akismet service comes back with a positive then it checks that the bozo plugin is installed and if so sets that user to a bozo.
if ( ‘true’ == $response[1] && function_exists( ‘bb_bozon’ ) ) {
bb_bozon( bb_get_current_user_info( ‘id’ ) );
}
I thought this was the ONLY current way (aside from other plugins) that a user automatically becomes a bozo. Is that correct?
I have used the bozo plugin to manually deal with spammers. As far as I know it just makes their posts visible to them but invisible to everyone else. Simple but effective.
I HAVE had problems when using akismet, so I thought the issues were more on the akisment side than the bozo side. Were the problems you mention in that post happening without akismet active?
In reply to: Taking a look at bbPress 0.9_ck_, oh, I get it. You aren’t removing the login name and replacing it with the account email, you are just allowing users to log on using their email address.
So during registration users still need to provide a login name, and the path to their profile will always contain that login name.
Hmmm. I’m not sure whether that makes things easier or more complicated for the user.
In reply to: Taking a look at bbPress 0.9That sounds very useful – look forward to seeing it.
I also like the login with email address option. Trade off there is that it becomes harder to switch the email address associated with the account. Probably a good trade though.
_ck_, do you remember how your plugin handled the paths where WP/BBP currently uses the login name? For example, the “_ck_” in…
In reply to: Taking a look at bbPress 0.9One other thing… I was thinking of leveraging the XMLRPC support to enable publishing of posts from an iPhone app.
I guess I would have to find a different way to do this in 0.9.
In reply to: Taking a look at bbPress 0.9Just like to add that I’m personally not terribly worried about the admin section UI. There are other more important things (perf, for example).
I NEVER write admin pages for my own plugins, but rather use a simple config file. I often think how nice it would be to have pretty admin pages, but it never gets to the top of the priority list because user features are more important.
_ck_, thanks. A year ago I really didn’t understand the code base very well so the 0.9 versus 1.0 decision wasn’t terribly well informed. And I think that if I went to 0.9 I would want to also get out of deep integration to get all of the perf benefits.
Now that I’ve written a bunch of custom plugins it is probably a simple thing to get all this working. As part of the user management model it does seem like something that is a core part of the system though.
BTW, one little complication is to add something along the lines of the way 1.0+ caches userdata with one big query before rendering all the individual topics (thereby avoiding individual queries for display name at each topic). The plugin would need to take care of this too.
In reply to: Taking a look at bbPress 0.9Using display names versus login names is an ancient argument and there are pros and cons on each side. It is a user experience design decision that individual site owners will make.
_ck_, I agree display names have their drawbacks, but using the login name does too. For example:
– login names favor early joiners (which you may or may not want to do)
– login names have more restrictions (e.g. no spaces)
– login names are less “natural” in some types of community
– login names are more tricky to change
Display names have some additional drawbacks you didn’t mention
– confusion of two names for a member
I don’t think the spoofing is a real issue — like Ben says you can display the member role to avoid that. Two users CAN select the same display name, but people deal with duplicate names in real life all the time. The profile picture becomes more important though.
Personally, I think the argument in favor of display names gets stronger in proportion to the degree of community in your forum. So I wouldn’t use them on a support forum, but I would use them on an enthusiast site.
Long story, but I might switch back to 0.9 on one project if I can somehow get display name support.
IF I did use a fork, it would be 0.9 (to me this is an existing fork, not a new one) to get away from Backpress. This would be mostly for performance reasons and so I’ll be watching the db query count on the plugin version with interest.
In reply to: Taking a look at bbPress 0.9I have a WPMU install with an integrated forum. I ended up using 1.0+ with deep integration.
If my memory serves me one of the reasons was that 1.0 has display name support, but 0.9 doesn’t.
Nope, many sites will continue to use and advance bbPress standalone. Matt might not invest dev resources in that, but others will.
0.9 is a defacto fork today, and there has been talk of a more official fork. Even Matt has said…
“Since the stated roadmap for whatever is going to be called “bbPress” and live at bbpress.org is to build on the success of WordPress if you disagree with that direction it’s probably best to fork at that time.”
So I think Matt acknowledges the potential continued existence of standalone, but believes that independent roadmaps is the right approach. I was hoping to take a step back and discuss the relative merits of that versus an approach where plugin and standalone were more coupled.
I’m rapidly running out of hope that such a discussion is even possible in this community.
I guess one could also use the check on BBP_VERSION (or equivalent) to print an error message when the plugin refuses to activate.
But a user would still need to install the plugin or look in the code (or read the README if the plugin author was good enough to mention the dependency).
My underlying assumption is that 0.9 or another fork will keep standalone alive.
We can acknowledge this reality and discuss its relationship with bbPress-as-plugin, or we can continue the (now pointless I believe) argument of standalone versus plugin.
Personally, I think there are valid arguments for both coupled and independent roadmaps. I’d like to know what other people think.
In reply to: What should be a Plugin, and what should be in CoreMatt, you are partially correct. A lot of this is about where the line is drawn. But I guess I also added another line. This has been the topic of discussion in WP before, but I think the concept of a *core plugin* is important.
A core plugin is released along with the real core and is held to the same release criteria (testing) as the real core.
Maybe this is semantics and you would just call a core plugin part of core. If so, that’s great, but I would still suggest that we talk about three things…
1. the real core
2. core plugins
3. general plugins
Referring back to your original framework, I think two of the criteria for core apply to the real core:
– essential for robustness
– something we want to promote
If it is something the majority (80%+) will appreciate then it could be released in the real core OR as a core plugin (e.g. akismet).
The benefit of a “real core + core plugins” approach is that it eliminates the conflict when something has both majority appeal AND connects to a service (again, akismet example).
It also eliminates a lot of the angst people have about additional bloat in the real core, or about the quality concerns for important plugins.
Bottom line: you can have your cake and it it too. A core plugin does not add bloat, AND it is released with all the QA of a feature in the real core.
Hmmm. Seems that even the mod is hijacking threads on bbpress.org these days…
Feel free to start a different thread to talk about the specific performance aspects of bbPlugin versus bbStandalone.
One more attempt to focus this thread on the original question: I am interested in a discussion on the relative merits of evolving bbStandalone and bbPlugin independently versus in a coordinated fashion, NOT the relative merits of bbStandalone versus bbPlugin.
Repeating the advantages of both, with one additional pro that I thought of for the coupled roadmap.
Advantages of a coupled roadmap:
– Higher quality for standalone (benefitting from the larger installed base of the plugin)
– Better performance for the plugin (benefitting from the big standalone sites)
– More tight WP integration is likely for standalone
– Easier “cross-grades” between plugin and standalone version
Advantages of independent evolution of the plugin and standalone versions
– More flexibility in release roadmap for both versions
– No compromises for either version
Matt, absolutely. Point taken. All I am pointing out is that the involvement of large standalone sites will provide *additional* impetus for performance/scaling.
And to get the thread back to the original question, I am interested in a discussion on the relative merits of evolving bbStandalone and bbPlugin independently versus in a coordinated fashion, not the relative merits of bbStandalone versus bbPlugin.
My realization this morning was that these two paths already exist (you gave guidance on when to fork in another thread and someone recently pointed out that 0.9 is effectively already the standalone fork.)
So given that the two paths exist, I think it is useful to discuss the extent to which they should be independent of each other.
In reply to: What should be a Plugin, and what should be in CoreRegarding Matt’s “”As for bundling multiple plugins with core — ultimately it’s a cop-out. If something is good enough to be included with the core download, put it in core!””
I agree with everything johnhiler said on this, plus I would add that the advantage of core plugins is that their coupling with the real core will be more well defined and probably minimized. Making something a plugin puts a clear boundary around the set of features that it adds. It also guarantees that the real core can work without this functionality.
Without this to enforce discipline on the design, things are far more likely to become highly coupled spaghetti.
A related issue is core bloat. Something like Windows or WordPress adds features in every release and seldom removes them. The result is that the code base is monotonically increasing in size and complexity. It will ultimately collapse under its own weight. This means that significant rewrites become necessary from time to time.
The Unix “small and decoupled is beautiful” approach is maintainable for much longer for this reason.
Higher coupling does have its advantages (performance, UX), but they are usually short term gains, winning the battle but losing the war.
In reply to: How to change main color background for all pagesCan you clarify what you mean by “large header text”?
Kakumei wasn’t designed with a black background in mind, so you will probably need to restyle many elements to make it look decent.
A very easy way to find the CSS elements you need is to install Firebug in Firefox. You can then right click on any element in the page and Firebug will tell you its name and the line number where it is defined in style.css.
You can even change the element definition right there and see the impact of the change in your browser.
If you have trouble finding any specific elements after trying with Firebug, post here explaining what you did and we can point you to the right place in style.css.
In reply to: Whats the best spambot plugin?You mention “several” registrations. Is there a specific reason that you think this is a spambot as opposed to a human spammer?
In reply to: The cost of Deep IntegrationI can only speak to my own experience, where during one stage of our growth deep integration saved me a lot of time at the cost of a more expensive hosting plan. Here “more expensive” means in the region of a hundred dollars a month, so when I trade this off against the cost of my own time or the cost of hiring a developer it is a good trade. Or, I would argue, “intelligent design”. ;-P
Now we are reaching another inflection point and I am making an investment in efficiency. I fully expect the site to a be completely custom at some point in the future.
_ck_, I’d like to know more about the “guaranteed growth failure”. I understand how vertical scaling (bigger server) eventually runs out of steam, but (aside from cost) what is to stop horizontal scaling (more servers) for WP?
Also, it sounds like you have experience of hitting the ceiling. I am interested in the rough traffic level where this happens. 1MB per instance is definitely high, but with 2GB or RAM on a server you need a pretty busy site to max that out.
I find that the bottleneck is more often on CPU. So high query counts and deep call stacks seem to be more of a culprit than the instance size. Is there some other reason that you’re concerned about the size of the RAM footprint?
Hmmm, I have always specified the keys in my config files. When I’ve got a moment I will see whether the nonce thing is still an issue.
BTW, here is the BuddyPress thread where Andy confirmed that I needed deep integration. Of course, this may be outdated by now.
In reply to: The cost of Deep Integration_ck_, I would agree if it were just a matter of a clone theme. I operated our site like that for a couple of years. But when your customization goes beyond just a theme, then the costs of “cloning” get high in their own way.
To repeat this thread, the duplication results in higher dev cost, more complexity to maintain and more bugs (to use a Rails-ism, the code isn’t very DRY).
No question that it gets more performance and uses less resources though.
In reply to: The cost of Deep IntegrationI have now (1) figured out how to measure the number of queries correctly for both sides and (2) removed some very silly overhead that was immediately revealed after I achieved (1).
The result is that both Kakumei and my custom theme do around 40 queries on the front page of the forum.
Apologies for all the noise in the two posts before this one — a great illustration of more haste less speed.
ps. One mod to Kevin’s extremely useful suggestion regarding the use of SAVEQUERIES to see where those queries are going… in bbPress you need to print the queries for BOTH the bbPress and WP databases. In other words, you need the following in your forum footer:
global $wpdb, $bbdb;
print_r($wpdb->queries);
print_r($bbdb->queries);
Or just to get the number of queries for both…
global $wpdb, $bbdb;
echo ‘WPDB Queries: ‘ . $wpdb->num_queries;
echo ‘BBDB Queries ‘ . $bbdb->num_queries;
Of course, the “>”s that appear in my code above should be greater than signs.
My reasons for deep integration generally fall into two categories:
A: niggly issues like the fact that I couldn’t get WP and BBP to share the same nonce value for safe logout. These all magically go away with deep integration (e.g. I now only use WP’s login/logout functions).
B: it is much easier to create a custom user experience that crosses from blog to forum. My biggest example here is a site wide reputation system. So I need to display display profile pictures, badges and levels alongside forum posts and blog comments in the exact same way. I could do this without deep integration but then I would need to duplicate some functionality across WP and BBP plugins (e.g. writing a function on the bbPress side to get the avatar location).
I think at its core deep integration is about a trade off between [raw performance + server cost] on the one hand and [dev cost + ttm + maintainability] on the other.
So to your second question… the data I pull across is mainly user metadata as I described above.
And regarding plugins… very few plugins that aren’t custom.
One other thing: the deep integration we’re talking about is one way. I also integrate the other way (e.g. showing forum posts on blog pages) and this is done without deep integration. That is, I have created functions on the WP side to query the db for forum data.
