Forum Replies Created
Site could be considered NSFW.
…depends where you work… 😉
Compared to some help requests I’ve answered, this site’s rather tame.
CSS design is a very complicated subject. The base BP theme’s CSS file is almost 2,500 lines long and has a vast and intricate style tree. Answering a RFC (request for comments) on a given set of changes to it is many hours of work, and is beyond what can be handled on these forums.
If you have a specific problem, eg: “When I set style X to Y, the level 2 menus explode” or “How can I invert the color scheme”, the users here will be happy to help you.
Also, be aware there are sweeping changes in the works for BuddyPress’ template system. The core development team is currently re-designing the entire template system to use page-fragment injection. In theory, this will allow BuddyPress to use almost any WordPress template set – not just ones designed specifically for BuddyPress.
I’d estimate they’re about 6 months away from release on this.
1.5 BP install with completely unmodified default theme, works perfectly. After upgrading the install to 1.6 (there were no errors during the upgrade process) …attempting to click on a group name or topic link results in an infinite redirect with the new 1.6 Default theme. All plugins disabled, of course.
This is with completely unmodified BP files from the distro .ZIP.
Best places to start checking?
You’re both right, actually.
First off, HostGator gives you incredibly little memory and CPU on their low-end plans. Like… 64MB RAM and 1/128 of a core. It’s nearly impossible to run anything more than a test site on an entry-level HostGator plan.
I currently run most of my BP sites on MediaTemple, and absolutely love them. They’re a lot more expensive ($25+ a month) than HostGator, but you get what you pay for: 512MB RAM, a full CPU core, root access, and the best technical support I’ve ever worked with.
As for BuddyPress, I’m currently watching a BP site with 1300 members, four active users plus a search robot, and caching disabled, *saturate* the above server.
So I’d say yes, BuddyPress probably has substantial CPU usage.
We’ll learn more about what’s causing that as we get unit testing merged into the BP core …but that’s something we’ll discuss on the TRAC not the forums.
My team is working on scaling BuddyPress to serve 1 Million+ users on a single installation. We’d be very interested in hearing about your experiences with performance optimization.
Members created in the WP back-end don’t appear in the members list until the first time they login to the site. This is “by design”, and is due to the way user accounts work in WordPress. Its also an optimization to prevent (potentially) huge numbers of users that have never used the site from slowing it down.
Search on buddypress.org has never worked properly and probably never will work properly. This is because proper, natural-language search is a hard problem that the developers behind WordPress and Buddypress don’t have any experience with.
The most efficient way to search buddypress.org is to go to Google and type in
“site:buddypress.org whatever you’re searching for”
`There’s a line where feedback becomes toxic, and you’re both walking it.`
Everything I posted was fact. I stated a problem, suggested a course of action, and explained the possible consequences if the problem was not corrected. Where was I being toxic?
The original forums page effectively worked as a “preferred forums” list. It ordered forums by last posted message and number of users. Because the BP-Media forum is (was) extremely active and has a huge number of users, it was always at the top of the list.
Recent changes to the BP site hid that page from the UI. Users can still, in theory, access plugin forums from the plugins list, but the list is ordered by last SVN commit date. That’s useless for someone trying to browse to a specific forum. They’d have to navigate 30 screens deep to find BP-Media.
Although *you* may think the core buddypress forums are more important than plugin forums, users on buddypress.org do not agree with you. And they’ve voted with their posts. That’s why, until you hard-coded the “core” forums into your template and hid the “plugin” forums, *over half* of the core forums were displaced from the list by very popular plugins like BP-Media and CubePoints integration.
Although these changes might improve *your* user experience by making it easy to navigate to the forums *you* visit most frequently, they harm the user experience for a large number of visitors to the site. You need to step outside your bubble and look at the bigger picture.
Buddypress.org was “yours to experiment on” until you let 100,000 users move-in and build a community. Now you have a kingdom. And if you fail to keep it running smoothly, you’ll have a rebellion.
But the only way to find the forum now is when somebody gives that link to a user. Previously, there was a list of forums on the site, and BP-Media’s support forum was on that list.
Also, just send me an email at the address listed on my BP profile, and I’ll get you set up with access to the spreadsheet.
Please post help requests for BP-Album in our forum. We don’t see them when you post them out here.
You might want to take a look at BP Cubepoints integration.
That is correct.
We’re also working on an embedded form that visitors can use to submit plugin status updates directly on the wiki page. The form submissions will be automatically added to another spreadsheet to make it easy for you to review them and update in the master spreadsheet.
OK, since it will probably disable the embeds each and every time a non-super edits the page, please do the following then:
1) Save a copy of the current page as a draft so @karmatosed can recover it if necessary
2) Remove all the manually pasted plugin links and statuses …(it will be much easier to edit them in the master spreadsheet).
3) Paste these three blocks of markup under the respective headings
Meh. No worries. Try dropping these blocks of markup in …hopefully one of them will work.
`[googleapps domain=”spreadsheets” dir=”pub” query=”hl=en_US&hl=en_US&key=0AkVTlWinFfKydDVTaWdpTGpQazUza1RrV0oxWURScUE&output=html&widget=true” width=”100%” height=”300″/]`
`[googleapps domain=”spreadsheets” dir=”pub” query=”key=0AkVTlWinFfKydDVTaWdpTGpQazUza1RrV0oxWURScUE” width=”100%” height=”300″/]`
`[googleapps domain=”spreadsheets” dir=”spreadsheets/pub” query=”key=0AkVTlWinFfKydDVTaWdpTGpQazUza1RrV0oxWURScUE” width=”100%” height=”300″/]`
`[googleapps domain=”spreadsheets” dir=”spreadsheet/pub” query=”key=0AkVTlWinFfKydDVTaWdpTGpQazUza1RrV0oxWURScUE” width=”100%” height=”300″/]`
@boonebgorges We’ve spent the better part of an hour trying to debug the BP codex page, but it won’t render the Google Docs embed, even when we add it in the admin back end.
WordPress.com officially supports Google Docs embeds announcement, support page, and the embed works properly on several different test sites we tried it on. The problem seems exclusive to buddypress.org.
Could you guys up one of us to super admin for a bit so we can check if it’s stripping embeds by normal editors as some sort of spam control measure?
Overall progress for today…
Google Code seems to have all their servers working again and the Fixing plugins for BuddyPress 1.5 wiki is coming together nicely. Over the next few days we’re going to be adding some new failure cases and improving the quality of the existing articles.
@boonebgorges We’d be honored if you linked to us from your blog. Also if there’s anything we missed that you’d like covered, just let me know and we’ll add it to the wiki.
We’ve updated the BuddyPress 1.5 plugins compatibility page. We split it into three different spreadsheets (that all auto-update from the master spreadsheet) as per @karmatosed ‘s request. We created embeddable widgets for each of these so karmatosed can embed them in the BP codex. As per @djpaul ‘s request we removed all non-error related tester comments.
It would be helpful if you could give one of our team members write-access to the codex blog so we can assist karmatosed with getting the embedded plugin spreadsheets working properly.
I was tired (18 hours and counting) and pasted the wrong block of code.
We fixed that one and moved on to a bunch of other things
Cool! Now we have a block of code we can use for another example. You need to hook to the ‘bp_setup_admin_bar’ action to get it to reappear.
Fire man an email (CarlRoett [at] gmail [dot] com) and I’ll walk you through it.
Hi Tosh. We’ve created a wiki page covering the problem your plugin was experiencing, and detailing how to fix it.
We used the code you sent us as the example to make it easier for you to fix the actual plugin. If you’re not comfortable with your code being up on the wiki page, let me know and we’ll create a new example from scratch.
Note that Google is updating the servers our wiki is hosted on today. If any of the wiki pages look a bit “odd”, just hit refresh a few times.
We just thought it would be helpful to other developers, as many people learn best by studying other developer’s code. As requested, the “Excellent” note has been removed from the spreadsheet.
FAIL = “Does not run on BuddyPress 1.5. No workaround available.”
MARGINAL = “Plugin works well enough to be used. Workarounds may exist for broken functionality. Or, all plugin features work but the plugin has huge numbers of debug errors indicating it will likely break in the near future unless it is updated.”
PASS = “All plugin functions work on BuddyPress 1.5”
PASS + “Excellent” = “High quality code. In the tester’s opinion, other developers can use this plugin as a working example to study when fixing their own plugins”.
If you think you’ve found a mistake in the list, contact us and we’ll fix it. Probably within a few hours.
Other status levels:
SCRAPING = “BP-Media Team has been sent the URL of a plugin that somebody wants tested.”
QUEUED = “A snapshot of the plugin info and files has been pulled and is waiting in the test queue”
SENDING = “Plugin test package is being sent to a tester via Skype”
TESTING = “Tester has acknowledged receipt of the test package”