Agreed, no need to make it into a plugin.
Second that. Standalone is much better.
That info, on what vBulletin is doing and how this can open new doors for bbPress as a standalone platform, should be weighed seriously, before rushing into the plugin idea. The timing of this happening is hardly a coincidence… and a great opportunity.
I agree with you guys, but for a different reason.
vBulletin feels old and clunky compared to what we’re used to today – lightweight and easy to use sites with soft edges.
People like me need an alternative, and there simply is none….yet. So bbPress is simply the best and natural choice for the Forum 2.0 world.
@grassrootspa : Remember back in 2004 when Movable Type pushed everyone away with their new pricing plan? The result: BLAM! WordPress REALLY took off, fitting the bill as a viable free easy-to-install, easy-to-use alternative.
I remember it well. I was using Blosxom and decided to finally move over to MT right before they changed their pricing plan. I switched to WP and never looked back.
I hope Matt and all the developers will discuss this in the next IRC meeting.
MT made me learn perl and practically got brain damage from it back in 2003.
Then MT pulled that nonsense in 2004 and I jumped ship like so many others.
In hindsight MT did me a huge favor.
Best wishes to vbulletin users, I hope we can come up with a smoother conversion method for them.
I think bbpress should be available as both a plugin and standalone forum. There are so many WP users who is only missing a forum part to their blogs, and remove bbpress as their best option, now when its getting better & better to integrate with WP, would make a lot of people sad ( including me ).
If bbPress have a plugin / standalone installer – it will rule !
Coming at this as a software engineering problem I cant see why a both/and rather than either/or situation shouldn’t prevail. Let me explain, as it’s not particularly outside the box for it to happen.
I write a lot of automated tests for the code I produce day-to-day and that means I need to isolate the most important pieces of business logic from how they are invoked. For instance, a given request comes into the a webservice telling it to create a user for the system. I would separate the code that handles the webservice part (pulling parameter data from the incoming HTTP request, etc) from the code that then creates the user. I would isolate the steps, wrap automated unit tests around each, and be done.
Applying the same thing to bbPress, there is some core code that handles the management of forums containing topics, that contain posts by users. This code is packaged into a clean unit of deployment – the WordPress plugin – and there is absolutely no reason why the code shouldn’t also have a second wrapper that allows for its deployment stand-alone from the main body of a WordPress installation.
Just as I might have a webservice making calls to a body of well-tested code in my day-job, I dont see why a cleanly written WordPress plugin shouldn’t make calls into the tested bbPress core code. The body of WordPress code provides additional services that another wrapper could also provide – the core of bbPress should be unaware of the actual physical storage mechanisms being employed, or how it’s being invoked (assuming its written correctly).
At the end of the day the conversion to a WordPress plugin should bring health to the codebase – a level of focus on what is most important (managing structured conversations in a forum/topic format), and an abstraction from what is not important (that is, the underlying physical storage, web-hosting, etc).
paulhawke, there is nothing “clean” about wordpress design. The code may have been cleaned up over time, but the result after 5+ years is there is a ton of code.
But the critical part is it loads EVERYTHING, regardless of the task at hand, all functions, all options, all plugins. Only the admin area is excluded from the load. But even the admin functions in plugins are loaded because there is no api structure to load those portions only in admin. (I’ve attempted to address that last problem in some of my later plugins for bbPress).
Loading a bbPress page as a plugin for WordPress will require the same process, EVERYTHING has to load, but now it will be worse.
This is why caching is critical with WordPress or it gets slaughtered when there are many requests. As soon as bbPress 1.0 was retooled to use backpress, it inherited the same problems as WordPress.
bbPress as a plugin will have the same problems as with backpress, but now even more so as all the wordpress plugins are loaded. It’s deep integration regardless if the user wants it or not. You will not be able to use bbPress functions without all of WordPress loaded because it will be substituting for backpress.
It’s forced deep integration, easiest way to explain it, and that’s a very bad idea.
I didnt know WP loaded everything, thought it was built smarter than that. Anyway, how much is everything ? 1 sec more wait ? is it acceptable for mainstream users ? The only thing i care the most of is a 100% user integration / login, but it could maybe be solved by a “addon” betwen WP & bbPress ?
The problem is every website has different needs.
Some have only 10 visitors a day but the site operator wants every feature including the kitchen sink. They don’t care if it takes several seconds for their page to render as long a they have every fancy feature available and they can just use wp-super-cache to deal with the load.
But other sites have thousands of visitors a day and when a page takes too much cpu time or mysql time to render, then you multiply that by hundreds of simultaneous connections. Then you fail and your host kicks you off or you have to buy a bigger server.
WordPress started lean and mean, 1.5 was good, 2.0-2.1 was a great product. Then they started throwing in the kitchen sink. Then with every next release started breaking compatibility with every release, changing cookies, changing admin structure. 3.0 is a scary creature indeed.
There is no doubt in my mind that a bbPress plugin under WordPress is going to require 1 megabyte of code executing per instance with plugins in a realistic environment. The site operator with 10 visitors per day won’t care because they have every feature the could want in one package. The operator with an active, growing user based is going to have to constantly upgrade their server to handle the problem.
Active forums don’t deal well with caching, unlike blogs.
Blogs are write once, read many times.
Forums are write many times, read many times.
Different environment, different needs.
But performance should always be designed into software.
I think in the long run, that rather than porting bbPress to a WordPress plugin as a “straight port”, there will be a halfway house of using WP3.0’s custom post types and taxonomies. I’m guessing at this, but haven seen some attempts at this on the beta already, it seems to make alot of sense.
EDIT: found justin tadock’s example @ http://justintadlock.com/blog/wp-content/uploads/2010/04/forum-post-type.png
(sorry for the number of spelling mistakes, i simply can’t read these hideously small text they’ve forced on us by using font-size in pxels)
I’m not sure why, but the fonts look fine and comparable to other sites here, for me. This is with Chrome 5 on Windows or Linux. FWIW.
CTRL+ takes care of font resize if I need it without any trouble. But I’ve never had to do that here.
Now THIS site has really small fonts on my system: http://faustltd.com/
For some reason design and architecture firms always seem to want those tiny fonts.
Hi Guys
I’m new on the block, but have considerable experience with forum software and server enrironments. I also have a little fleet of WordPress sites, LOL. I haven’t grokked all the bbPress stuff yet, but this is a very interesting topic.
-ck- and paulhawke both made some very good points there.
Based on what I know of other systems, the observation about cacheing is accurate. Also a fairly competent Forum program is likely to become considerable larger than any blog because of the nature of the communications, which is many-to-many, rather than one-to-many. Tts not uncommon for forums to have fifty to a hundred thousand posts. How many blogs do you know like that? Just like WP, it all has to be iterated to do a page generation.
Forums are also very spiky, due to their many-to-many, interactive nature. One post begets another or another five. Other than add-ins, Blogs are effectively document retrieval systems where there is a time disconnect between related events.
For these reasons, I lean toward the idea of either hybrid or standalone development. Another concept would be that the plug-in have either less capabilities or some size limits coded in. Sure people could code around, but they would also be on notice that ‘you may be heading for trouble’.
I’m looking forward to what’s coming.
