Search Results for 'test'
-
Search Results
-
WordPress has a tendancy to throw a it’s toys out of the pram if it has an activated plugin that isn’t there.
BuddyPress is quite an intricate setup, and randomly deleting stuff won’t really solve the issues. Given that this wasn’t tested on anything but a live site, deleting things from a live production site when you don’t know whats going on is not a great idea
That’s not to say it couldn’t work though
The other thing you could do, and the people at BuddyPress will be able to direct you to this, is to de-activate the plugin directly from the database via something like phpmyadmin.
Realistically though, my biggest bit of advice is not to do things like this on a live production site. Test test and test again
Take care and good luck
Marius mate,
Testing these things on a local/development enviroment first is really going to help you. bbPress plugins sometimes require quite a bit of web-dev knowledge, and being able to work out all the hic-ups on your own machine before letting your users see it will make your life alot easier
By the looks of it, yourself and JohnHiller could be on different timezones, I’m on all day fixing the last few bugs in the bbProgress admin section, so shout if it goes back up and we’ll try and help.
I wanted to let everyone know that I’ve been working on a clone of bbPress which is built entirely in Pods. I’m not intending it to replace bbPress, but I am intending to continue development of the functionality to bring it to more of a vBulletin level. That’s the big picture anyway, I’m nearly done with getting bbPress functionality done itself.
You can see my progress here:
http://www.scottkclark.com/forums/beta-testers-unite/current-status-of-the-forums-package/
Once I’ve completed it, I will post the package on the Pods site so you can just import the package into your own site.
For info about Pods, go to http://pods.uproot.us/
Hi
Been trying to install Buddypress onto a clean BBPress instalation – but it keeps giving me an error:
Warning: require_once(WP_PLUGIN_DIR/buddypress/bp-core.php) [function.require-once]: failed to open stream: No such file or directory in C:wampwwwbbpressmy-pluginsbuddypressbp-loader.php on line 19
Fatal error: require_once() [function.require]: Failed opening required ‘WP_PLUGIN_DIR/buddypress/bp-core.php’ (include_path=’.;C:php5pear’) in C:wampwwwbbpressmy-pluginsbuddypressbp-loader.php on line 19
Does anyone know if this installation is at all possible (clean BBPress + BuddyPress forum) ?
I would like to avoid using WordPress Mu – to keep things as lean (simple) as possible !
Thanks in advance for any advice on the subject !
Jens
btw. – I have for a couple of weeks been doing research on how to run the best and most sufficient frontend bases open posting site (or almost open) – and has ended with bbPress (has 12 different test systems running on wamp and easyphp – among them Word MU – Drupal version 6 and 7 and others. It’s close to chaos for sure)
Trunk is the bleeding edge version which is under development. Like a newer version under development. Trunk means the latest code in development stage. I am running a little busy right now. If left with some time tonight, I might try to catch it on trunk
@Gautam .. I did manage to find one of the things that was causing a problem. It has to do as I suspected with the PHP $_SERVER[“DOCUMENT_ROOT”] variable. It doesn’t exist in an PHP install on IIS.
Now I have found a work-around that <gasp> works and when tested returns the proper path (eg: C:/Domains/winextra.com/bb-attachments/ – which from what I can tell in the “instructions” is exactly how it is suppose to be)
But when I try to upload a file (text/image) I get the following two errors and I was hoping that maybe you could help figure out what might be causing them
Warning: filesize() [function.filesize]: stat failed for 83def462ed888db6e1ad898505ea40b6 in C:Domainswinextra.comwwwrootforumsmy-pluginsbb-attachmentsbb-attachments.php on line 342
Warning: Cannot modify header information – headers already sent by (output started at C:Domainswinextra.comwwwrootforumsmy-pluginsbb-attachmentsbb-attachments.php:342) in C:Domainswinextra.comwwwrootforumsbb-includesfunctions.bb-pluggable.php on line 228
any help (from anyone
) would be greatly appreciated as this is the last real big complaint my members have.EDIT: The files are getting uploaded but to the root folder and they are not being entered into the bb-attachments table – http://screencast.com/t/Y2UyZGQ4
Kind of mate
In fact, I’m sure that a lot if not everything bbPress related could be done with plugins, but it comes to a point in time where a certain number of plugins are needed as standard for the forum to function properly.
I mean, “forum_is_category” and “topic_voices” are in the core now, but rather than being in the core tables, are still added and fiddled around with as meta data, so there’s always an INNER JOIN needed or additional SQL calls.
Call up a topic, in SQL, simple. How many Posts? there’s the data. How many tags? there’s the data. Heck, last poster’s name? sure! How many voices? oh hell no! I don’t keep that data here. It’s a secret!! Even though it’s a one to one relationship and it’s in the core, we keep that somewhere totally different, and you need to come up with a totally different method of getting that info. Ha, i mean, just cos it’s in the core, doesn’t mean it’s laid out prof… well we don’t use it on the WP support forums.
I’m not suggesting anything overtly Machiavellian at all, please don’t assume that and if I’ve given that impression I’m sorry (sometimes i jokes dont translate well), but if you give the data-structure to a DBA or heck, a basic developer they’ll scratch their heads. There is no really good reason for something like “forum_is_category” or “topic_views” to be held in a separate table as a data row, other than the one major forum where it’s not used. And that’s ok, he who pays the piper calls the tune, but that’s a core issue.
Realistically, thats not a coding issue, it’s a perspective issue. In order to get at the data, we need to call additional database information that we don’t need. Why do we need that overhead, even if it’s small.
Deep down, I can’t believe I need a plugin for my forum to be able to say it has posts underneath it though. That isn’t a bug and it isn’t intended, it just wasn’t thought of.
Same with Mass deleting of users / topics / posts. Or the ability to be able to add any form of ordering or filtering to any of them. Just wasn’t thought of.
I can understand a plugin with a specific purpose in this field (I’ve written one that marks any “.ru” and “.cn” user as bozo automatically), that’s cool. But I still think it’s daft that I have to manually search the user list every day for members with certain words in it – that stuff became bog standard on the internet a long time ago.
You know, once i search for (and find) a user, it then takes me 7 clicks and 4 different pages to delete the user. And there is no en-mass option. 7 clicks and 4 pages!!!! That’s not a ‘plugin or not plugin’ issue, that’s no PM/BA/IA/common-sense issue. I mean, really, having to leave the admin area to interact with a user? They got rid of that idea in wordpress almost 3 years ago.
I don’t want to flog a dead horse, but now that WordPress isn’t being ported to backPress (at least in the next version minimum), can you imagine the difference that rolling in a moderation suite or really any of _ck_’s non-fluff (smilies, bbcode) plugins into the core would have made in the 14 months between 0.9 and 1.0 being released? Hey has anyone used XML_RPC to post to their forums yet? it’s awesome…
=====================================================================
Is the concern that since the data design isn’t optimized for inherited forums, the query count will go up?
Yeah, kind of. It’s more that it’s already gone up, and as themes become more complex, it’ll go up again.
Let me give an example, and it’s a walkthrough – there could be code optimization.
To load the last forum poster/post (and btw this is for the singualar, not the child, which would multiply this by each child forum), you effectively are looking up the topic with the last date that’s attatched to that forum, and then look up the last post that’s attatched to that topic. Ok, so that’s 2 additional SQL calls for every forum thats displayed in the forum list.
(EDIT: actually, I’m confident it’s just 1 INNER JOIN SQL call now, but it’s still not needed really).
Now on a forum like this, or on WP support forums, thats only 6 forums. ok, so 6 additional calls total. Meh, not fussed.
But do you see how this doesn’t scale? On one of my forums, a football one, we’ve a “forum” for every football team in the UK. There’s no “latest” list, as we want people to talk in their own club’s section. Thing is that’s:
England
– Prem
– – 22 teams
– (Another 4 divisions of 24 teams)
Scotland
– SPL
– – 12 teams
– (Another 2 divisions of 16 teams)
It was facing meltdown every now and then, and I realised why, I’m placing an additional 150 SQL calls every time I want to display the list of forums, simply to find out the last post in a forum (and that’s NOT including the code needed if I was to respect genealogy).
Here’s the thing though, the TOPIC table has a column called: topic_last_post_id. Do you know why? Because it allows an inner join rather than an additional SQL call. Very sensible. Of course, it just wasn’t transposed to the bit that a certain support forums didn’t use.
If we applied the same logic to “forums” as to the topics, heck even put it in the meta data table, we’d add 1 SQL command in total when a new post was added, instead of 1 SQL per forum listed per pageload per user. Now, i could write a plugin to do that, but it’s not solving the issue, it’s just papering over the cracks in the datastructure.
I’m sure there will be some people reading this and they wont get that that i’m talking about data structure and optomization, and not specifically about “last forum poster”. I’m not advocaating category heavy forums or flat file forums, i’m saying that we’ve got some real data holes, and i think we should discuss them. How long until i’m told to leave bbPress because on some of my websites I use it differently to someone who has relatively few uesers and so isn’t hitting any of these issues? I bet not long.
I am not in any way having a go at any current/ Past developer/ development team/ Santa nor the Easter bunny. But the data is set up in a way in which it is ideally suited for 1 type of forum, and not for any of the others. Thats cool, but if bbPress is going to be a WPplugin, then this doesn’t matter. If there’s going to be a standalone version, then this sort of thing really needs to be looked at.
There’s countless examples of this; I’m just going with the one that people can replicate easily.
=========================================
I’d like to stress i’m not advocating a massive change to the core, honestly I’m just up for discussion. I’m really just wanting to know people’s feelings or thoughts on this. Far too much data is not readily/intrinsically/obviously available especially when said data is on a predefined 1-to-1 relationship.
Maybe if the data structure wasn’t so wishy-washy at points, there might be more plugin developers, or themes that looked a little more like the themes available on any of the other forums.
=========================================
John you’re also right that a “moderation suite” could be done via a plugin, my thoughts on that though would be “XML-RPC is a standard feature, but moderating my forum is a 3rd party plugin”?
I don’t think that making Forums read only on a selective basis is the work of a plugin, thats integral to how a forum works. Same with certain forums being visible to certain people.
The ability to move/sticky/resolved a topic/post from inside the admin area isn’t the job of a plugin, thats the job of the admin area. otherwise, what the point of the admin area
I’m sure there are things that I think should be standard that many other don’t; and vice versa. I don’t want bloatware, i’m not suggesting we copy phpBB or anything else, but i also think that just because we can have a plugin to do a job that we should always have a plugin to do a job. Also, just because something works with the current datastructure, doesn’t mean it’s even close to optimal.
=================================================================
Phew, longer than i wanted. Probably wrote many things which people will get annoyed at. Then again, i’m sure some idiot will be along in a minute demanding that we stop talking about this and include Facebook Connect, Polls, Smileys etc. I wonder how long that will take before my data structure conversation gets it’s first “ZOMG i cant code so ignore data structurz & make me XXX feature”.
If you can log in at WordPress, navigate to the forums, still be logged in, and then log out and do the reverse, your cookie integration is fine. To test the rest (the reason you included wp-load.php) try using a WordPress function (wp_list_pages()
) in a bbPress template and see if it works. Those would be good tests.
