Member pages are not caches with super cache right now. It is detecting them as 404 errors, even though a 200 OK is being passed. if someone wants to debug the 404 cause please do. Once this is fixed it should work just fine. I keep the cache expiry time low. No hacks needed, works for home page and all blog screens.
I plan on hacking up something that doesn’t cache private blogs as well since right now wp-super-cache will cache private blogs and then show them from cache to the public. I just have an array in my wp-config.php right now for private blogs, but that isn’t a long-term solution. It would be nice to cache members and groups though.
Unless I am missing something, the only reference in the wp-super-cache for 404’s at all is a simple function that looks at is_404() from WPMU and if it comes up that way, it doesn’t cache it. I have been around this for quite awhile now and can’t seem to put my finger on it. Sure would be great if anyone has any extra input as cache of everything would be ideal 
I even tried taking out the template action for this 404 in wp-super-cache and it did work. For several page views it worked caching everything from member pages, groups, etc. Problem is then it became poisoned and any pages served from wp-super-cache failed and gave server errors. I could get around it by disabling wp-super-cache and just using wp-cache, but it has to do with that function itself it seems….
Trent
That would be great as I have already had a member say that the site is too slow! His comment was that it wasn’t as fast as imeem or myspace. I checked myspaces download compared to my site–it’s pretty unbelievable.
BuddyPress is a beautifully thought out architecture, however it must be a strain on the relatively few men working on it. Day by day it gets better and better though, which is cool.
The nice thing about buddypress as opposed to myspace, facebook and imeem is that you cannot beat a community that cares! And with all the care that goes into this project, one day it will surpass all the others…
People, is this 404 thing only on bp’s virtual urls? Directories has the same problem is_404() returns ‘never heard of this, yep it is’. Lemme go look. Gotta go play with headers today. Gotta learn about them. I need to refresh a page at an inconvenient moment. Like after generating the bp menu bar.
Looking at is_404() and it’s brethren. These things are part of the wp_query lib that:
* The query API attempts to get which part of WordPress to the user is on. It
* also provides functionality to getting URL query information.
When trapping an url and gen’ing a page based on that virt url we aren’t in wp any more. I see in bp_core_do_catch_uri() that first a check is made to see if this is a blog page. That doesn’t work. The workaround for not gen’ing 404s for directories is to create a wp page that is ignored. We get the title for the page and the directory itself and no 404.
Looking at bp_is_blog_page() I see that all it does is detect if this is a member page, news or a bp component page. Return true else false.
So bp_is_blog_page() returns true for virt urls.
So we return from bp_is_blog_page() and exit bp_core_do_catch_uri() at that point and then the check below of:
if ( !$bp_no_status_set ) {
status_header( 200 );
}
Never happens if we are gen’ing a bp virt url. That our problem with 404’s?
So the sequence is: (this is a question)
– user wants bp virt url
– catch uri does it’s thing, the header 200 isn’t sent
– bp starts gen’ing the page
– header query or super cache does is_404()
– we’re not in Kansas any more
– is_404 returns true about not being in Kansas
– page gets gen’ed
Is this logic correct or am I missing something as usual?
When viewing the member profile $bp_skip_blog_check is null. So the above does happen.
When viewing a directory $bp_skip_blog_check is true, $bp_no_status_set is null so it does status_header(200). The var $pages ($bp_path) is plugin-template.
Then it does load_template() which gets us back to the is_404() question because it extracts the $wp_query->query_vars which have no validity since we aren’t in Kansas.
Template runs and $wp_query->query_vars are showing what? That wp doesn’t know anything about this page.
var_dump($wp_query->query_vars) shows everything is empty except a few things like ‘pagename’ and ‘name’ for member theme profile in the header.
is_404() happily returns true.
status_header(200) doesn’t seem to be enough to convince wp that all is well. What would?
is_404() just does return $wp_query->is_404 which isn’t even set.
I’m sure there is a better way of doing things but:
if ( !$bp_no_status_set ) {
status_header( 200 );
global $wp_query; $wp_query->is_404 = false;
}
Forces is_404() to be happy. If this is the problem then it’s up to you guys to make it work elegantly and withing the boundaries of acceptable wp behavior. I don’t have much experience playing by the rules or playing well with the other kids.
You guys owe me help refreshing the current page after gen’ing the bp menu bar.
In my ‘community blogs’ plugin I have a form that get’s post’ed. It’s really just a fake form that masquerades as a menu bar top level item. ‘Join! this Blog’, it gets post’ed which is the user saying yes I want to.
We return to the same code and when we return the user gets added to the blog and a new menu item gets hooked up in the place of the ‘Join’ link. Now we got a ‘Success!’ link to indicate that they are now a member of that blog.
I don’t want to just add the user and display ‘success’. I want to refresh the page so that they can see that they are now an author and that this is added to the ‘my blogs’ list in the menu bar.
I just can’t figure out how to do that without getting ‘headers already sent’ errors.
See why I’m playing with headers today?
Back to the is_404 thing. What we need is to tell wp that all is well. A bp_populate_wp_query() fn that fills out the $wp_query var with appropriate noises. Then when catch uri snags an url it can bp_populate_wp_query().
So waiting for Andy to see this thread burtadsit
Another issue I see. When someone posts on a wire, it shows the new post, but also the message of “Your wire post was posted successfully!” and then caches that. So, if anyone visits the wire page, it has that cached Another issue is deleting items doesn’t reset the cache. Sure there are workarounds, but that would be annoying.
I installed wp-super-cache and it’s caching members profiles and invite pages so you cannot reject and or accept.
What would I put in the settings to ignore these places?
hi guys the only issue I was getting was the 500 error with super cache enabled am not testing with half mode now. I have the latest build of super cache 0.9 and the latest svn BP build running on wp2.7 and seems to be very solid…
You should be able to reject, accept, and everything else with wp-super-cache enabled. It will just cache the pages with the success notification afterwards and keep the notifications in the admin bar. Andy will eventually put in the hooks to fix that was well I would imagine. It does work fine with super cache turned on, so I would imagine the 500 errors you were getting would be from another reason jim.
Trent
I had super-cache installed, with wpmu 2.7 and buddypress RC-1, and everything seemed to be working fine, except for I would get a 500 Internal Error on Wp-activate (when the new user clicks on the email link that is sent to them to activate the account). Everything else worked fine, wp-signup worked like a breeze, and all of my pages and posts were cached as they should be.
Once I uninstalled Super-Cache, wp-activate worked again fine. I uninstalled all of my mu-plugins (re-captcha, google analytics, buddypress redirect) and just put super cache and buddypress in there, and i still got the 500 internal error on wp-activate. When I removed it and added the others back in, everything works fine.
Any ideas? I’d love to have super cache working, but not at the expense of adding new members.
I know this is an old topic, but do you guys know if this WP-SC is working WP 3.0a and BP 1.2? This is my first time digging into WP-SC and it doesn’t seem to want to take my modded .htaccess file.
