[Paul Gregory]

And here. Update to beta-3 and suddenly Forum Index doesn’t display anything.

To clarify, this was a page with the template “bbPress – Forums (Index)”.

Adding a new page with the same template also failed to show the index.

However, adding the shortcode

[bbp-forum-index]

to the page content makes the forum index appear again.

I’ve been a little out of the loop so I don’t know if this is intentional – maybe the index template isn’t the way to do it now and we’re supposed to use the shortcode. Using the shortcode does have the advantage of being able to add text before and after the forum index. Other template pages seem fine though.

In any event, it’s simple to fix.

[Paul Gregory]

@jjj Thanks. I’ll try and find time to support any tickets for including login and register page settings in WP itself.

It does seem that setting up a decent bbPress forum will almost always involve installing other plugins too, and a list of the little issues that can be resolved by these should form part of the final FAQ/documentation.

I’ve found that the plugin Register Plus Redux mentioned earlier lets me change the emailed link and is generally pretty useful.

Given that by default the system is already using /wp-login.php as a login link unless overridden, it’s not exceptionally naff as I first thought for bbPress Login Widget to use that as a default and allow admin to override it.

So who/where do I nudge to get the bbPress Login Widget extended to include an over-ridable Register link when logged out?

[Paul Gregory]

Assuming you’ve already added a blank page with the slug ‘forums’:

Change the page template to “bbPress – Forums (Index)”

OR

Include the shortcode [bbp-forum-index] in your page text

Also, go to the Permalinks page if you haven’t recently so everything else works.

See also https://bbpress.org/forums/topic/bbpress-20-theme-compatibility

There are a number of other things you’re probably going to have to do. I’m working on a checklist.

[Paul Gregory]

Yeah, that specific function’s not at all the right one, it seems to be a well-meaning but naive tip on kai920’s part.

But the basic idea of having a Register link within the bbPress Login Widget is sound, and I’m a bit concerned that it seems to be problematic.

There needs to be a good bundled method of having a link to Register that does NOT show up when a user is already logged in, and the Login Widget is the most logical place to put it. (Obviously it’s trivial to add a Register link to a menu or widget area that would be present all the time).

Two naff, but workable, solutions:

1) Add a field in the bbPress Login Widget for the registration page URL, with “/wp-login.php” set as the default. When the Login Widget is displaying the Log In details, display the registration link (if not blank and if registration is enabled). When the Login Widget is displaying the current user details and log out link, don’t show the registration link.

2) Encourage users to install a pair of simple widgets. I don’t know if decent ones exist, but they’d be called something like Logged In Text and Not Logged In Text, which as their names suggest are like Text widgets but only show their contents if is_user_logged_in() condition is true or false. It’s then simple to add a Register link or whatever to a Not Logged In widget, which could be placed above or below the bbPress Login Widget. If I can’t find an existing pair I’ll knock them out myself soon, although I suspect what I’ll end up doing on most sites is conditionally displaying one entire sidebar or another.

—

The reason both are naff is that it seems pretty clear that there should be a function or method that returns the correct (custom) login page, and the absence of it is causing problems.

Is WP completely unaware of custom registration pages? It seems so. There should be somewhere central that the URLs (or page IDs) of custom Register and Login pages etc are set – and that this should be site based rather than theme based, much like you can set the front page and posts page in WP Reading Settings.

Of course, that’s arguably a WP issue not a bbP issue, but bbP as plugin is at liberty to extend WP in useful ways because that’s what plugins do.

From what you’re saying it sounds like this isn’t part of immediate bbP plans.

I don’t know whether I’m missing a setting, or if it’s something you’ve fixed since b2 but: having registered using a bbPress registration page, the email that people get with their password includes a link to /wp-login.php rather than my /log-in page that uses the bbPress login template. Using that leaves people in an inappropriate interface that they are probably not intended to see, and will confuse (and lose) users.

Am I expected to override this myself with a plugin or in my template? That would mean hard-coding page references. It doesn’t seem right.

I think bbP should just bite the bullet and allow users to specify their login and register pages under Settings. And indeed specify the View Profile page etc. It seems to me that bbP really needs to know where the login page is, and searching for a page with either the bbPress Login template or the Login shortcode (the “magic” method) seems prone to error.

All that said, I don’t want to seem too negative – I am liking bbPress 2.0 a lot and thank you (and everyone involved) for your time on it.

[Paul Gregory]

Excellent progress.

@JJJ

Probably a bit late now, but could you please can you bung an “Updated: April 14 2011” or similar in the top post whenever you update?

As it stands, some people may come to that post and think that was the state of play 6 months ago!

[Paul Gregory]

@tooltrainer

I appreciate that “super sticky” or “stick to front” should do what you expect it to do, but it’s worth also rethinking what you want, and how it could be handled in a different way now that bbP is a plugin.

You appear to want every forum to have at the top a link to a closed topic with one post in it.

Well, couldn’t your forum guidelines content be a WordPress page? Then you could plonk a link in the relevant template and style it how you like?

(Or, have a widget area, or a special menu – something that would let you change the links and link text without having to change the template). In fact you could keep it as a topic, just link to it a different way.

I know super stickies are how forums normally handle this sort of thing, but not all the traditional fudges need to be carried across to bbP-as-plugin.

[Paul Gregory]

frooyo, if you see point 7.4 of the draft proposal you’ll see that it shouldn’t negatively affect this fork. Kevinjohn reckons that the bbPress plugin code and community will be excellently managed by JJJ. The fork will not prioritise integration with WordPress, meaning the fork can instead concentrate on being lightweight and modular (with 25 modules bundled in).

So that’s alright then. Oh, except at least one supporter of the fork thinks that “we will surely need to keep it tightly integrated with WordPress to market it and make it a success”.

I don’t really understand what part of bbPress it is that Kevinjohn wants to save. To me, it seems that the main thing he wants to keep from bbPress is the developers…

Right now, we’ve alot of exceptionally talented Developers, and not so much in the PM/BA department, and I’m merely trying to fill the gap I can be most helpful in.

Kevinjohn, you’re not filling a gap in bbPress, you’re creating a new project with all-new gaps and filling one or two of them.

Throughout the document you say “we” and “us” to mean either the bbPress community or the fork community. I wonder if at some points you forget that there even is a difference – that a fork is a breaking away. A new software, not a saving of the old software.

I was attracted to bbPress because it is the forum from the WordPress people and I like the tags. It is a shame that the project hasn’t flourished like WP has. I can understand that people will be attracted to a continuation of bbPress, but without the ties to WP the fork needs to stand alone with a clear identity. Heck, bbPress’s main problem is that it has a muddied identity – is it 0.9, 1.0 or plugin?

You say the proposal is a draft one, but I’m not entirely clear when/if you plan to release an amended version. I think that what you need to do after your blue-sky and requirement refinement phases is to publish a detailed proposal, a manifesto for the project, identifying what parts you’re taking from bbPress and what parts need to be rewritten, and asking “who’s with us?”.

Indeed, that’s what I hoped to see in the draft document, but instead I was disappointed by the contradictions and lack of detail. However, a definition that is refined by community consent rather than one man’s vision may well be the best start, and this fork may excite me yet.

With the fork defined clearly in a proper proposal, people who were particularly attached to rejected ideas can leave, and other developers and contributors will join. Everyone on the fork will believe in the project. You’ll know how many people are truly committed, and you can plan accordingly.

And this process will probably inspire even more forks from teams and individuals.

I suspect that the best post-bbPress projects will be rewrites of the core, like _ck_ has identified is necessary for her intriguing project. And that’s fine. Take the spirit, learn the lessons. Don’t keep bbPress code alive for the sake of it, just write the best forum software you can.

Kevinjohn, it may not seem it, but I wish your project well.

[Paul Gregory]

The title is “I want to fork bbPress”, but it’s really “I want to manage a bbPress fork. Here’s my feature wishlist. Who wants to code it?”

Kevinjohn, one of your 4 “Key Points For Discussion” is a matter you want to draw a line under (which was covered by the word “fork” anyway), and the other three are the areas that need the least discussion and the text itself explains why they don’t need discussing.

Indeed, a number of the points you make are a natural consequence of forking (eg ‘have a new website’) followed by some adjectives (‘have a better website’). However some of the ideas point towards a more substantial rewrite – rethinking categories and changing the database schema. The “blue sky” metaphor doesn’t exactly chime with a continuation of existing code either.

You prefer to fork 0.9 rather than 1.0 but you’re open to decisions from others.

You deride duplication of effort, yet you intend to fork bbPress.

You have “Focussing development efforts on the administration of the software, over front-end user needs” as a goal, which appears to mean that having a nice admin interface without any need to edit text files is more important than having a forum that people can use.

You may possibly have meant “needs” over and above basic functionality but if there are no fancy features on the front-end, how will the support forum “show-off”?

What sort of timeline are you attaching to this project?