[johnnydoe]

hey kevin,

there is really nothing to be sorry about, no stress, i’m already glad and thankful for the help you offer.

i’ve tried your code and i had still bad luck, but i’m going experiment with your code snippet tonight, i bet it’s probably an incorrect structure in my theme or something like that, but i keep trying

[Ivaylo Draganov]

That sounds great but after nearly 3 hours of attempting to get it working… I just feel too tired to keep trying.

I’ve set everything as per the instructions (cookiedomains, hashes, etc.).

Both WP and bbPress are generating cookies with the same names and same paths.

But by some unknown (to me) force they refuse to recognize each other’s cookies – when I log into one of them I get thrown out of the other.

It’s bbPress 0.9.6 with WP 2.9.2

Maybe I’ll try on clean installs tomorrow…

I just don’t have a clue what’s wrong

[Erlend]

Is there any timetable when the bbPress plugin project would be ready?

I’ve set my hopes for a Christmas Alpha

[Mark McWilliams]

Is there any timetable when the bbPress plugin project would be ready?

It’ll be a while yet I’m sure? If we go anything by the 1.2 Milestone on the bbPress Trac, it says another 5 months away, and remember that at the moment we’ve only got Pete Mall and JJJ working on it!

@Matt Mullenweg: Glad to see you around here again!

[hpguru]

bbPress plugin for WordPress with reply in WordPress theme reply form with Akismet maybe a good idea.

[Matt Mullenweg]

Love it.

[Matt Mullenweg]

Thanks for starting a new thread. Some of your sentences are unclear to me, so if I misunderstand a question just rephrase it and I’ll do my best to answer it.

The WordPress.org integration is done through a shared user table and the same settings for cookies. It is a bit of a hack right now because WP and bbPress have a different idea of how those global tables should look and fight to modify them, which is what took down WordPress.org the other day. (It’s very slow to modify the schema of a user table with hundreds of thousands of rows.)

As for running multiple instances of bbPress, on different domains even, we actually did a fair amount of work for that (was going to call it mubb.org) and it’s the code that currently powers TalkPress.com. However it’s not release quality and it becomes moot because once bbPress is a full WP plugin you get multi-site for free from WP’s built-in MS feature, so you could run as many bbPresses as you like from a single install.

[kevinjohngallagher]

Johnnydoe,

sorry mate, rushed off my feet tonight, try this:

bb_get_avatar( $user->ID, '48');

Is the code you’re looking for.

In order to get it to display the last poster you’ll need this:

bb_get_avatar( $topic->topic_last_post_id , '48');

Usual disclaimer, i’m guessing at this code. Just annoyed I forgot to add the “bb_” when telling you this morning, sorry.

[John James Jacoby]

Thinking part of the JS minify issue may have been not emptying the cache after changing the settings. Before I wasn’t automatically uploading the changes to the CDN.

Seems to be fine now, and can’t duplicate it when I want to see it.

If you really want it minified, I’m happy to get the plugin author involved in testing, to see if it’s a w3tc or bbPress issue.

[kevinjohngallagher]

I can shed some light on that.

Matt, I apologise in advance for this; but the constant slog in using this website in the months since the “bbpress2.0” theme release has been very tough. Did you know the homepage was a 404 for almost a week? And text was under 8px if you weren’t on a Mac or Linux. Patches and Changes were uploaded, changes not tested. We’ve a 6 page thread on it somewhere (it was sticked in the last 48 hours).

Anyway, the worst of those bugs meant that all HTML was parsed without exceptions (it wasn’t added to BackPress), so for just under 8 weeks, every single line of code we type into this forum has been converted to lots of & lts; and & gts; etc. It’s made giving solutions… difficult. Especially when copy/pasting. Especially for non PHP people.

Someone fixed the bug and added the fix to BackPress, but no-one picks up on the BackPress trac / forums (was bumped for 5 weeks) and no mails in the mailing list by a developer for almost 16 weeks. Eventually I reached out to Westi, who was awesome (no surprise really), and he stepped up and applied the patch (actually a few patches for us). It took another 13 days for it to be applied to this website. (I am also confident he’s now v easily contactable for everyone about backPress)

I ain’t intending on dredching up the past man, just… I know there’s some “ill will” around right now. Its not about “5 years of pent up anger” or anything like you said in the other post, it’s about last week, last month, the month before that etc.

With no intention of starting a long debate, would you have let the WordPress.org homepage be a 404 page for almost a week?

If no-one could give code exmaples on the WP.org support forums, would that have lasted from May to July?

We all drop the ball dude, its life, but if you wanted bbPress to help itself, it did. Ok, so not brilliantly or specacularly but it’s the dependancies placed upon us let us down, and the people we depended on were too busy making publicly disparaging comments at their WordCamp KeyNote speeches.

I often wonder if objectively you’d look at this post and think how you’ve done with bbPress: http://ma.tt/2009/08/kill-your-community/

I’m really glad you’re here and I’m thankful for your tone. I’m thankful for the information you’re giving. I, and I’m sure many others, are ok with us disagreeing on things, it’s the uncertainty coupled with the lack of respect (WordCamp comment + this website constantly breaking) thats stoked the flames of discontent.

In honesty bro, fair crack of the whip + information to make up our own mind = happy + repsectful community.

P.S. Sorry for the WTFmatt person. and haha, someone will be along to apologise for me in a minute

[Ashish Kumar (Ashfame)]

I am also in favor of using bbPress 0.9 as a standalone forum script rather than upcoming bbPress plugin.

Thanks for bringing this up!

[citizenkeith]

I greatly appreciate the consideration of using 2.0 instead of 1.2 which will at least slow down some confusion and make people realize the true weight of it as more than an update (and entirely different program).

Even from just a marketing perspective, calling the plugin 2.0 just has more impact. You’ll get more people adopting it, more feedback, more developers. It’s a win all around, IMHO.

Matt, I just wanted to quickly say thank you for coming back to bbPress.org forums and answering questions and communicating with us. There are a lot of passionate people here. We might not all agree on the direction, but I can tell you that already your presence (and JJJ and Pete) has helped morale immensely.

[John James Jacoby]

Always loved this idea personally. As a 2004 phpBB2.x graduate, I was constantly trying to make my forum software do stuff it wasn’t intended to do. This brings me back to those days.

[johnhiler]

I think most developers who run highly trafficked websites will prefer keeping stuff out of the core, to minimize bloat and to maximize scaling. Whereas most casual webmasters running a smaller forum will want as much in the core as possible.

It’s a natural tension. I think the best way to split the difference is to keep the core lean and mean, and then to have a set of pre-packaged plugins that are included in the main download that can be turned on (or can even default to being on). I think WordPress experimented with this direction last year? Not sure where it ended up though.

A few things were moved out of bbPress plugins into core, and it hasn’t really gone that well. “Subscribe to topic” was added to the core, and then promptly had a problem with spammed topics being blasted out over email. It’s a lot easier to apply a patch to a plugin than it is to get the patch approved in the core.

The “Page Links for bbPress” plugin was also moved into the core in 1.0. There were a number of code inefficiencies in that code that are now locked into the core. There was a recent patch released for the plugin version of Page Links (only for 0.9) that fixed this; that’s an example of how it can be helpful to keep non-essential stuff out of core.

[_ck_]

There is a filter on the $message

$message = apply_filters( 'bb_send_pass_message', $message, $user, $pass );

So yes, you can change it now without hacking the core.

<?php

/*

Plugin Name: New User Email Message

*/

add_filter('bb_send_pass_message','new_user_email_message',10,2);

function new_user_email_message($message,$user) {



$message.="n You can also change your password at any time by editing your profile. n";



return $message;

}

?>

[_ck_]

I greatly appreciate the consideration of using 2.0 instead of 1.2 which will at least slow down some confusion and make people realize the true weight of it as more than an update (and entirely different program).

I have to be honest though, I’ll probably be just going on my way once that plugin version is officially released to gold and the standalone versions become legacy.

You had a brilliant creation with 0.7, extremely lightweight and had the potential to be a pure framework and circumvent much of the legacy which shackles WP, but it’s all come full circle now and I simply cannot get behind such a radical reversion.

[_ck_]

Ah, your server has some kind of security option that does not allow code to execute directly from chmod 777 directories.

The first option would actually work better as far as not knowing the real directory or if you ever changed servers or directory names

ie. $browsertimer['log']=dirname(__FILE__).'/browsertimer.log';

Sorry this took so long to get going for you but don’t forget to work on why the queries are so high, that’s far more important.

[pastorbobsforum]

Well, now this is…interesting.

I uploaded the test.php

After http://pastorbob.limewebs.com/my-plugins/browser-timer/test.php

I get this: `Internal Server Error</p>

<p>Directory “(removed for security)/pastorbob.limewebs.com/my-plugins/browser-timer” is writeable by group`

Which had one good thing to it: it gave me my server directory.

But anyhow, after that I tried again the http://pastorbob.limewebs.com/?browsertimer I discovered that is working, without the extra modification that you’ve suggested.

Simply $browsertimer['log']=dirname(__FILE__).'/browsertimer.log'; and it worked.

I obviously modified the line to $browsertimer['log']='(removed for security)/pastorbob.limewebs.com/my-plugins/browser-timer/browsertimer.log'; and it worked just as well.

Now, my uneducated conclusion was that as long as I had one file called browsertimer.log in my entire forum folder the two expression would output the same result. The 2nd on the other hand is the best one.

What would your conclusion be?

Thank you anyway.

Regards,

Bob

[Matt Mullenweg]

I think this is worth discussing since it seems to be a core philosophical issue that comes up a bunch, with people citing text I wrote for the about page!

The general rule we’ve followed in WordPress, which has been successful for user adoption, has been that something is “core” functionality of it is something the vast majority (80%+) will appreciate, or if it something that makes WP more robust even if they don’t care about it (revisions), or if it’s something we want to promote because we think it will make WP or the web an intrinsically better place (oembed).

Something might be a hugely popular plugin but not perfect for core because: it ties in a commercial service (Akismet), it needs to update more frequently than core does (faster dev cycle), or it adds more overhead than is worth it. For the last, we can often bring in the bare minimum or framework into core and leave the rest as a plugin (podcasting support in WP, and PodPress, or SEO improvements we make).

A bonus of core is that (in theory) the code gets better reviewed, can be relied on by new plugins to be there and build on, and maintained as part of the overall package. It also often brings new folks who may have just worked on plugins before into improving core which increases exponentially the impact of their work.

Of course there is lots of common sense along the way, this is just meant as a general framework for approaching the problem.

[_ck_]

Okay let’s assume the host is doing something weird.

Make a temporary file in the same directory that you want the log to be.

ie. test.php

put this in the file

<?php echo __FILE__; ?>

Then access it from the web, ie. example.com/my-plugins/browser-timer/test.php

Whatever it shows you, change the ending test.php part to browsertimer.log

and then put it inside

$browsertimer['log']='full line here';

Now that has to work, as long as the my-plugins/browser-timer/ directory is chmod 777.

[pastorbobsforum]

I have deleted the .log file. I’ve made the modifications in browser-timer.php

$browsertimer=dirname(__FILE__).'/browsertimer.log';

The weird thing is that I can no longer see the .log file being created and I get the same log open error

My permissions on the folder are 777, as I said before.

Another thing is that I am getting a 550 Permission Denied in Filezilla when I try chmod, but it’s ok in their filemanager. Even Filezilla tells me that I have 777.

Any other ideas?

Bob

[Matt Mullenweg]

LOL.

Security is an excellent reason to upgrade (whether terrified or not) but it should be noted that 3.0 contains no security fixes, so it’s no more secure than 2.9.2. (Yes, it’s been that long since a security release. This doesn’t mean there isn’t anything hiding in the code, but we don’t know about it yet and the frequency between issues being brought up is going down even as our popularity is growing, which I hope means we’re becoming more intrinsically secure.)

[jmharrington]

I was able to easily solve my issue by finding one careless mistake. In my wp-config.php file I simply copied the authentication keys (4 of them) and pasted them into my bbpress’s config.php file. What I did not notice is that in wp-config.php they keys are prefixed like this:

define(‘AUTH_KEY’,’my unique key is here’);

While in the bbpress config.php, the keys are prefix like this:

define( ‘BB_AUTH_KEY’,’my unique key is here’ );

The only difference is AUTH_KEY versus BB_AUTH_KEY, but that made the difference. Hope this helps technotip…

thanks _ck_ for emphasizing the auth keys

[Gautam Gupta]

I just had a suggestion – when the plugin would be public and this site’s posts converted, we could have an if statement above the topic like

if ( topic_date is before bla bla date || one of the topic_tags == 'bb_old' ) { /* load a message which says that this is for bb 1.1 and below, this doesn't apply to the new plugin */ }

But I’m also not against changing its name or having its version as 2.0.

[_ck_]

The images are hosted elsewhere when using the [img] tag so bandwidth doesn’t matter.

Are you thinking of uploaded attachments which is another plugin entirely?

Unless maybe you mean you only trust certain users to be able to post images at all because you are afraid of content you don’t want from unknowns. That would be possible.

If you want the latter, try replacing the plugin with this:

<?php
/*
Plugin Name: Allow Images (moderators only)
*/
add_filter( 'bb_allowed_tags', 'allow_img_tag' );
function allow_img_tag( $tags ) {
if (bb_current_user_can('moderate')) {
$tags['img'] = array('src' => array(), 'title' => array(), 'alt' => array());
}
return $tags;
}
?>

That will allow moderators or higher to post image tags, everyone else will end up encoded. You could also optionally use the throttle permission which is the checkbox in the user’s profile that allows then to post faster than 30 seconds apart, but use it also as a flag that they can post images (just change moderate to throttle)