Afraid I’ll need more information to be helpful then; the only time I’ve seen this is with Jetpack 2.0 installed. It’s possible some other plugin or theme is causing a similar issue, but it’s still a WordPress core bug at the core.
@robertfudge – unlikely, though it depends how that plugin adds fields. WordPress only provides one hook for adding extra profile fields, and it’s not robust enough to do very much with.
Version 2.1.3 does everything it can to suppress the issue in Jetpack 2.0. Jetpack 2.0.1 will come with its own fix. It’s actually a WordPress core issue causing this; see: https://core.trac.wordpress.org/ticket/22413
Doesn’t make any sense.
Performing the recounts will fix this for you. When users post content, recounts automatically for that topic. You’ll have better luck using the tools in bbPress than waiting for it to happen organically.
2.0 to 2.2 will be fine; nothing to be nervous about.
You missed a step.
Visit: Tools > Forums
Do all of the recounts and recalculations. You’ll want to do them one at a time, top down.
@grex22 @netweb – This issue is already fixed in trunk, and will come with 2.2. Basically, the stickies query wasn’t including the ‘closed’ post_status, and it now does.
Sorry about that.
@ridecbrcom-1 – Not cool. Bully people in your own forums, not ours.
I’m confused about what you’re trying to do. You’ll really want to stick to using the functions included with bbPress rather than trying to build your own MySQL queries to connect things.
bbPress uses a bunch of additional post_meta to connect forums, topics, and replies together. It also keeps counts in post_meta of how many topics and replies live inside any forum or topic. When things are off, they’re really off, like you’re showing in your link above.
My advice:
- Use bbPress core functions.
- Use the WordPress import/export tool if you’re moving between installations.
- Look at the bbPress functions for inserting forums/topics/replies, and use those as your guide if you still plan on building something custom.
In future versions, I’ll likely clean up some of the post_meta code, so it’s all in one place and easier to grok. Much of it was written as it was needed, so the post_meta isn’t super organized.
The result of the nonce check comes from WordPress’s function: wp_verify_nonce()
It does the token check like you’re looking for.
This does make sense, but opens up a security hole in the process. The purpose of this function is to make sure that requests go to the same place they came from, and you’re basically removing that part of it completely.
I put a filter on the $requested_url variable for 2.2; it will allow people with this type of configuration to swap out the URL contents, essentially setting your own match criteria.
What @zaerl says still holds completely true, however. Handling this at the server level should be the first thing you do.
Anything is possible.
You’ll want to research WordPress login plugins, if you want more control over the login page than what bbPress provides. You can use the login form shortcode, but that won’t prevent people from navigating to wp-login.php directly.
Try…
if ( is_bbpress() ) { ... }
Profiles fixed, and working good in trunk. Unstickying.
You have several options, but the easiest is to make a ‘bbpress.php’ at the root of your theme. It will act as a wrapper for your entire forums.
Look inside the bbp_author_link() function; there’s a great bunch of documentation in there on how to get that information out.
To say the code “isn’t very clean” is kind of silly; the best thing bbPress has going for it is how clean the code is to read and follow.
That fixes one issue, and breaks everything else. 🙂
My guess is the number is being formatted when it shouldn’t be, putting a comma after the 1, resulting in a string where it’s expecting an integer.
@renai42 – Thanks for the feedback. The great thing about bbPress being open-source is you’re able to fix the things you don’t like on your own with Subversion patches via our Trac.
Sorry you’re finding the CSS to be complicated. There are some compromises we made to be able to make bbPress as good as it can with every possible WordPress theme available. As such, some CSS rules are more strict than others, and we tend to have things wrapped in ID’s to allow groups of content to be styled and/aggressively reset.
The staff here are volunteers, every one of us. We operate under the assumption that if you’re in the code, asking code questions, that you’re comfortable taking on something new and foreign. I’ll defend the code here though, since bbPress’s code is nicely documented and orderly.
Volunteer community members represent the project, but they also represent themselves. If someone’s made you feel bad, that’s between you and them. We’re all adults here, and it doesn’t benefit anyone to talk above or below anyone else; when it happens, it weeds itself out pretty quickly.
Regarding CSS specifically, it’s in the name: it cascades down. This means you’re able to add whatever rules you’d like in the stack, and the browser will interpret those new rules in kind. If it’s not obvious enough to you, that just means you learned something new today. That’s not anyone’s fault, or anything that anyone should be upset about on either side.
Again, thanks for your feedback; if you’d like to talk privately about a specific matter or person, contact me privately (a Google search should bring up multiple ways to do this.)
Saying that it’s obvious isn’t really fair. WordPress works in specific ways for specific reasons; blindly, forcefully overriding it isn’t something to take lightly.
I’m looking at the 404 issue.
This will be fixed in 2.2. It’s fixed already in /trunk.
In my imagination, it’s just the new default thing. Let’s get it working first, see how dramatic it is, and go from there.
Should make it part of the default theme. Thought there was a ticket already; if not, make one and feel free to patch it up. 🙂
