To me, this would be the single most important bbPress feature imaginable. Facebook, not OpenID.
–myballard.
OpenID is a means of authentication. Facebook is an authenticator. The problem is that the autenticator has opted for it’s own proprietary means of authentication, rather than using OpenID. In addition to its own API, Facebook could, should and probably will support OpenID. As of last month, Facebook has joined OpenID, but they’ve not implemented anything that I know of yet.
Next time you’re on Facebook, search for “Facebook should support OpenID” – there’s 800+ folks who agree. Which is a start, given that it’s developers, not hoi polloi, who are going to be concerned with this.
I have the code managed through svn and after a quick svn switch http://svn.automattic.com/bbpress/tags/1.0-alpha-2 (followed by an svn update for good measure) everything appears normal.
(+1 beer on Sam et al next visit)
Glad to see the GPL bit is working 
Employment is stifling any development time for me at the moment, so I’m way quieter than I’d like to be!
Oh how I love the smell of brand-name luncheon meat in the morning.
macwise, no offence meant, and apologies if any taken. i’m too short on time at the mo and had meant to add a pointer to php.net (which I’ve pointed ppl at previously) before I got sidetracked by a demanding supervisor. ’tis better to have a community where you feel ok to ask – after all, the only dumb questions are those that remain unspoken.
You might find this useful. Its Eric Raymond’s article on “smart questions”.
The topic tag list is a list, so marking it up as such is semantically correct, so the best practice way of rendering that list in the way you want is, as Trent suggests, through CSS.
This article covers inline lists, which is what you’re describing.
See this for a more terse example.
Null, you might find http://php.net useful. It has descriptions of all methods and classes, as well as examples and suggestions of ways to do things.
I’d suggest checking for function_exists on a bb_menu function or class_exists rather than file_exists, because you’re introducing an extra dependency on the site layout, which is subject to change.
In the long run you’ll keep users more friendly if you don’t dictate how they browse. Most people (even my mum) know about tabbed browsing now and know to middle click to open a link in a background tab.
Also, FWIW, target is not (and never has been) a standard attribute of HTML4 or XHTML, so if you want your pages to validate, avoid it.
Having said that… The Google Analytics plugin for BBPress filters the content and adds stuff to the anchors, so that should help:
http://boakes.org/download/googleanalytics.txt
The use of separate keys is important for several reasons, firstly, you’re not just using the Akismet database, you’re contributing to it with every message you send. Each time Akismet makes an assessment and you don’t disagree with that assessment, you’re contributing. Being able to remove contributions from bad people once they’re identified is a useful ability, if everyone used the same key this would be more difficult.
Obviously bad people very much want to be able to affect the DB so that their spam can get through.
So when bad people are spotted, they must be stopped. The key helps here too because (I recall from looking at the original plugin source) it becomes part of the connection URL, so it’s possible if necessary, to block connections to that URL at the firewall level, so the servers can concentrate on fulfilling requests from good guys.
A single hidden key would be very quickly compromised, and would thus be very quickly disabled, and you’d be back to needing your own key.
It doesn’t have to know the difference. You set
$special
to be a special class before the loop, then the last thing you do in the loop is set
$special
to be something else. So the first time round the loop
$special
has it’s original value, then at the end of the first loop it’s value is changed (so it’s no longer the initial value).
The fact that the value is repeatedly reset to the other value is irrelevant (there is overhead in this, but it’s comparable to calling a function each time round the loop to check for “is this the first item” and it has the advantage that it’s not API specific.
A lazy short circuit solution which makes the first displayed entry in a loop appear different:
$special="specialClass normalClass";
for {
echo ... class="$special" ...
$special="normalClass";
}
I trac‘d it last week… Uni will be over soon, then I’ll have time to play with stuff like this.
LDAP is a data-access protocol and not a solution in itself. Think of it as being similar to the fact that HTTP can access all kinds of different documents, so LDAP can be used to access information in directory servers, each of which may have different organizational structures, and within those structures, you often find entries describing users and entries describing roles.
I’ve just looked at the LDAP plugin source and currently login appears to be based on authenticating to the LDAP server using the credentials that are supplied to bbPress, roles dont’ appear to be considered… yet.
It looks nice and clean, although, I notice in your own forum it doesn’t currently validate. Once you get that all happy, don’t forget to validate the css too.
Cool! So now the CSS fix? 
Tip: you really need to stop repeating the errors that have been debugged for you.
You cannot do $rw["location"] == get_bb_location() because you are comparing (on the left hand side of the ==) the name of a function with (on the right hand side of the ==) the result of a function.
You could do:
if ( call_user_func($rw["location"]) == get_bb_location() ) {
// do something
}
But that’s probably not going to achieve what you’re trying to do because it’s going to depend on what the function actually does (whose name is stored in $rw[“location”]) … so if it returns a boolean value, then it’s not going to work because get_bb_location() returns a page name.
Incidentally the whole idea of storing the name of the function in the database is slightly more black belt than “noob” territory. You’d be better off storing a flag in the DB then translating the flag into a function name in the your code, because it’s more easily traced.
Isn’t there a simpler way?
Probably – describe in words (not code) exactly what you hope to achieve in the piece of code that is not working (this is often a healthy trick when something doesn’t work – by articulating the problem you can often recognize if you’ve overlooked something obvious or better in the design).
Can you confirm what I asked earlier about the content of $rw[“location”]?
If that is what you’re doing then modify this example:
<?php
function exampleOne() {
return "bb";
}
function exampleTwo() {
return "press";
}
$rw["one"] = "exampleOne";
$rw["two"] = "exampleTwo";
$switchOne = call_user_func($rw["one"]);
$switchTwo = call_user_func($rw["two"]);
echo($switchOne);
echo($switchTwo);
?>
Obviously you don’t need the example methods, but just use call_user_func on the name of the method you’re pulling from the DB.
I think I answered this earlier …
$switch = eval("return ".$rw["location"]);
… because $rw[“location”] is, I think, the name of a function which you’re pulling from the DB.
that’s because the underline changes the size of the anchor element. a simple solution is to create a transparent underline for the standard anchor element, then change the color when hovered.
That comes with bitter experience
Once it’s working, it’s then a good time start thinking about integration. Since this is a plugin it will have to work with many themes, so for maximum flexibility you might want to switch from pixel based sizing to either percentages or ems so that everything is sized relative to the default font.
