[WP Realty]

I’ve installed an integrated WordPress 3.0 (NOT MU) and the latest BBPress. When users register with WP they can not add any reply or start a new post in the forums.

I tested this with the default unaltered theme and same thing.

Looking in the DB I see that each member is a “member” in WP but there is no BB_METAUSERS table for bbpress. I think this isn’t required when an integrated solution is installed.

Any idea why all new members are set to “Inactive”?

J

[zaerl]

offical bbpress fork

There’s an official bbPress fork?

[XU3E]

This is realy good plugin but Its not working properly with new versions bbpress. _ck_ doesnt support it anymore because his own branch for 0.9.

Its fantastic oportunity for someone skilled to take this for keeping update with offical bbpress fork.

Perhaps… it should be implement in bbpress core or bb-plugin.

[Erlend]

@Gautam

By that you mean front-end posting with the native WP editor, right? Not an included, new editor, the way bp-wiki or scribu’s editor currently does it?

Because when I’ve applied a plugin to extend the WP editor, that should apply to the front-end editing as well.

Thanks for the hint about image uploads with P2, I hadn’t noticed the feature. I’ll probably have to do a fresh test install though, because it’s buggy on my current one. Will report back my experiences later.

[Greg]

Matt, 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.

[_KB_]

@kevinjohngallagher thanks dear, I’ve done it already, its a part of integration, But I really surprised why its won’t work for me??

but I’m curious that may be _ck_ tell me new thing.

OK, I’m going to disclose my config files and cookies, check it dear buddies….

for wordpress,

http://pastebin.com/embed_iframe.php?i=hPpMiDyZ

for zptest students

http://pastebin.com/embed_iframe.php?i=jcS2377M

If you need more things, I’ll share it..I really want to fix it….Thanks

[Joe Gibson]

Z – I got on a bbPress plugins page and found your ‘Open in new window’ plugin but the rascal doesn’t seem to work. Tried it in both ‘bb-plugins’ and ‘my-plugins’. It activates just fine. Is there a trick I’m missing?

Thanks,

Joe

[Joe Gibson]

Z – Thanks, the ‘s’ did it. Very appreciated.

The one last thing that would really make this editor the cat’s ass would be opening links in a new window. Is there a PHP version of “Target=_blank” we can slip into the code?

Joe

[yetanotherlogin]

To have WP send my admin password, I edited php.ini to use my ISP’s SMTP server instead of “localhost” (no SMTP server on this test host), restarted PHP-FastCGI, and clicked on the WP “Lost your password?”, but I get this:

“The e-mail could not be sent.

Possible reason: your host may have disabled the mail() function…”

So can’t get the admin password back. Anyway, since it doesn’t complain about the password and just loops back, I assume it has to do with the WP/bbPress integration?

[_KB_]

So, here exactly What I want,

Suppose I’ve planned to run multiple discussion boards, and I’m using

http://zptest.info/ ( WordPress )

http://zptest.info/students/ [bbpress 1]

http://zptest.info/teachers/ [bbpress 2]

http://zptest.info/management/ [bbpress 3]

I’ve done:

-1: Shared User Integration ( Works )

-2: Shared Database Integration ( Works )

-3: Shared Cookies Integration (Not Works, that’s what I want)

I’ve followed all instruction from bbpress Integration tutorial

Now cookies not works, you can test it at zptest.info

user: test

pass: test

(I can send also admin’s or ftp detail, if anyone really interested)

cookies are conflicting, sometimes not logout from other boards.

Suggestion:

I’m hopping there should be a plugin, just for set cookies for multiple boards in same domain.

People just do, user integration, and database integration.

then install ( cookies plugin ), that’s all,

Come on, _ck_, you can do it,

Thanks

KB

[Ivaylo Draganov]

phpinfo() tells me that PHP is Version 5.2.13

Now, pretend I am crazy and tripple check the settings at the top

LOGGED_IN_KEY

LOGGED_IN_SALT

The two keys and salts are the same. Keys I get from wp-config.php and salts from wp-admin/options.php.

take a REALLY good look at the cookie data – it changes between bbPress and WP but really only two parts should change, the expire date and the hash. So between the last | in the data

How the hash forms is still not quite clear to me, but obviously that’s where the issue lies. I notice that it’s different every time I log in (no matter from which side). I if log in/out of WP 10 times I get 10 different hashes. But maybe that’s the normal way.

Other things to note:

* I am using year long cookies plugin on the bbPress side

* bbPress has a trailing slash in these settings:

$bb->wp_siteurl = 'http://dev.example.net/';

$bb->wp_home = 'http://dev.example.net/';

whereas WP has them without the slash:

define('WP_HOME', 'http://dev.example.net');

define('WP_SITEURL', 'http://dev.example.net');

* as you can see I am doing this on a dev subdomain and not on the live site. Even though I did test it on the live site(with the main domain) too and the result was the same

* the lines you mentioned in the plugin did not match: I had that code on lines 70 and 83

* define('AUTH_COOKIE_VERSION', 2 ); should be added at the top of _freshly-baked-cookies.php, right? I did not exist there in the plugin download, so I added it before starting the tests

Thanks a lot for helping out

[yetanotherlogin]

Hello

This is the first time I’m setting up WordPress and bbPress, so it could be something very obvious, but from reading the tutorial, I couldn’t figure out what to enter at Step 2 – WordPress integration:

CHECKED Add integration settings

CHECKED Add cookie integration settings

WordPress address (URL) This value is required to continue.

? http://192.168.0.8:8787/wordpress/

Blog address (URL)

? http://192.168.0.8:8787/wordpress/

WordPress “auth” cookie key

?

FYI, on the test host, I have WP installed in /var/www/wordpress/ and bbPress in /var/www/bbpress. The two applications shared the same database in MySQL, since I assume it’s easier that way and they use a different prefix when creating tables.

Considering this context, does someone know what to type above

Thank you for any help.

[Erlend]

But you certainly are not going to get anyone who is NOT using WordPress to install WordPress just to create a forum. There are far better options out there.

You’re probably right. Yet allow me to give an example of how major plugins like bbPress and BuddyPress complement WordPress in a way that greatly adds to its appeal (i.e. grows the customer base beyond those interested in WordPress)

Much like WordPress, our project (jMonkeyEngine) is a continuation of someone else’s work. When we picked up the reins of the jmonkeyengine.com website, we were stuck with three separate content systems (SMF, DokuWiki, WordPress) and a mess of custom code. We looked at several options, like:

– Extend SMF (no doubt the heart of our community activities) into a full-scale CMS

– Tie all systems together with a solution like Atlassian’s Crowd

– Replace our custom front page with Joomla! and use JFusion to tie all four tightly together.

– Replace everything with a widely extended Joomla!

We practically tried all of those options and more in practice, either in testing environments or on our live site. Meanwhile I’d been looking at complete ‘community solutions’, like Elgg, OpenWack, JomSocial, BuddyPress…

(I definitely looked at Drupal as well, but they just didn’t seem to have anything near as simple as say JomSocial that just goes ‘boom, now you can start build your community).

Then bbPress came to BuddyPress, and I made a decision. I proposed an overhaul and we got moving:

http://www.jmonkeyengine.com/forum/index.php?topic=13934.0

The only reason we’re not spamming press-boards with ‘look at us!’ links yet is because we made the decision to move everything over at once, and that includes the risky decision of adopting the BuddyPress-Wiki plugin (every other essential has been covered by core features) to replace our DokuWiki. With D.P. Cartwright’s dedicated help we’re just about there though.

Erm, point ahoy!

So the point I’m trying to make is, we never stopped to consider WordPress as a CMS, until BuddyPress arrived as the major complement to fulfill our every need in one package, as opposed to 20+ plugins. Having used WordPress for my own portfolio page and general sandbox play I already knew how intuitive (extremely so when compared to Joomla!) and easy to extend it is. When the last remaining piece of the puzzle arrived, the choice was a no-brainer. I imagine many will come to the same realization with bbPress.

I know I did not prove you wrong; I just figured people might find this brief case study interesting.

[ZKuJoe]

Thanks for the feedback and the link to the plugin but I don’t want it to look or feel like a blog, just act like a blog. I prefer the thread/post structure over the entry/comment structure. I was originally using WordPress and had a MyBB forum on the same site, then I switched over to just a MyBB forum with a Blog plugin, but then found that bbPress felt like both a blog and forum without requiring different installations to achieve both. I just created certain categories that only I could post in (the “My” areas) for my “blog areas” and the rest are open for free discussion.

I am working on getting the first post of the latest topic to appear on the front page but I have to many other development projects on my plate at the moment.

[johnhiler]

“Shared-hosts are the bread and butter of WordPress usage. The good news is servers are way more powerful than when I wrote the first bbPress, and we can take advantage of that to provide a richer experience.”

This is definitely true. It’s kind of the Microsoft approach: grow the OS core, and lean on the hardware handle the growing codebase. It works for smaller sites that don’t hit scaling limits and for larger sites that can afford bigger hardware.

“The uncertainty of testing the interactions of N factorial plugins is daunting and gets untenable quickly.”

Plugin interaction is definitely a concern. But in practice, I have rarely if ever had plugins conflict with each other.

“Better to draw a line in the sand and promise the user ‘these things will always work together.'”

I think the “promise” model depends on having a large and growing team of developers actively managing the core. That hasn’t been the case in the past, so moving stuff into the core has actually slowed down development of the platform quite a bit. Perhaps things will be different in the future…

In any case, even with developers available to help build up the core – I’d still prefer to have a model that embraces plugin developers, and then has specific plugins blessed as official branches. This is where more social forms of source control like GitHub may be better than Subversion; plugins wouldn’t be dependent on just one developer, since anyone can seamlessly create and post a new branch. It’s much more like the pastebin stuff that’s constantly going on here in the bbPress forums.

Thanks for the reply!

John

[Matt Mullenweg]

Shared-hosts are the bread and butter of WordPress usage. The good news is servers are way more powerful than when I wrote the first bbPress, and we can take advantage of that to provide a richer experience.

I like the idea of plugin-centric development from a theoretical point of view, and obviously plugins have been at the core of WordPress’ success, but I think it can be taken too far and take away from the user experience.

It’s about taking responsibility. Even though you could break down almost every feature of WordPress into a plugin and distribute everything bundled, and even activate a bunch of them by default I think you lose a “buck stops here” for other developers to target. The uncertainty of testing the interactions of N factorial plugins is daunting and gets untenable quickly.

Better to draw a line in the sand and promise the user “these things will always work together.”

[kevinjohngallagher]

Ok mate, first thing to test is, if you specify an ID, do you get an image.

eg: bb_get_avatar(1);

If so, aweosome. then we’ve narrowed down the problem to the ID we’re passing.

i’d also add this line:

echo $topic->topic_last_post_id;

and see what that outputs. (should be a number).

[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

[John James Jacoby]

Spent the past week or so testing a few larger BuddyPress/bbPress installations with W3TC, and I can say that it works a treat with the bundled version of bbPress we tuck in there too.

Experienced the same JS minify on the inline JS also actually. Wonder if it’s a bug. I’ll see what I can dig up.

[_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

[_ck_]

Oh and it just dawned on me.

If you have an empty log (ie. no visitors) you’ll always get an open log error.

So be sure to load the front page as a test first.

[_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