Skip to:

Opened 15 years ago

Closed 15 years ago

#1031 closed defect (bug) (no action required)

Activating bp-default Makes Admin + Site Inaccessible

Reported by: muraii's profile muraii Owned by:
Milestone: 1.1 Priority: minor
Severity: Version:
Component: Keywords:


First, the meta:

  1. Which version of WPMU are you running?


  1. Did you install WPMU as a directory or subdomain install?

As a directory

  1. If a directory install, is it in root or in a subdirectory?

A subdirectory

  1. Did you upgraded from a previous version of WPMU? If so, from which version?


  1. Was WPMU functioning properly before installing/upgrading BuddyPress?


  1. Which version of BuddyPress (BP) are you running?

Trunk revision 1885

  1. Did you upgraded from a previous version of BP? If so, from which version?

Various trunk revisions, most recently 1882 (which exhibited a similar issue)

  1. Do you have any plugins other than BuddyPress installed and activated?


  1. Are you using the standard BuddyPress themes or customized themes?


  1. Have you modified the core files in any way?


  1. Do you have any custom functions in bp-custom.php?


  1. If running bbPress, which version?

Whatever is integrated with BuddyPress

  1. Please provide a list of any errors in your server's log files.

Curiously, there seems to be nothing generated in error_log for this particular
issue. That is, I can create the problem (without fail) and see nothing in error_log
nor in the error logs in my host admin panel (cPanel).

/* The Issue */

First, the algorithm:

  1. Deactivate existing BuddyPress plugin.
  2. Delete plugins/buddypress/ and themes/bp-default/ and themes/bp-sn-parent/.
  3. Check out latest trunk to my personal computer.
  4. FTP trunk/ to plugins/.
  5. Rename plugins/trunk/ to plugins/buddypress/.
  6. FTP bp-default/ and bp-sn-parent/ to themes/.
  7. Activate BuddyPress.
  8. Activate bp-default.
  9. Cringe.

Here, "Cringe" = neither the WPMu admin nor the public-facing site return any HTML. This is the White Screen of Death. I am unable, therefore, to disable BuddyPress, and unable to activate a different theme. The only way to restore access to the site is to delete or rename themes/bp-sn-parent/.

I noticed tonight that the description in Themes for bp-default says

"The template files are located in /themes/bp-sn-parent/messages. The stylesheet files are located in /themes/bp-default."

Why would WPMu be looking for template files in a directory under bp-sn-parent/, rather than in that directory? Perhaps this isn't problematic, but it seemed a little odd to me. It also seemed odd that whatever misdirection a theme faces would cripple the whole site.

I had been upgrading trunk for a week or two, without also upgrading the theme directories. So, for some time, I had bp-default and bp-sn-framework with newer trunk revisions. Since BP should support fully custom themes, and bp-sn-framework is now essentially custom given bp-sn-parent is the standard, I'm not sure this should actually have an effect. I thought it might be pertinent.

Toward determining where the issue was, I searched my db tables for "framework" and didn't hit anything that looked useful.

Change History (5)

#1 @apeatling
15 years ago

Can you try a completely fresh installation of WPMU and BuddyPress with a new database and report if that works? Thanks.

#2 @jeffsayre
15 years ago

Just to keep everything organized under one roof, two other people have reported similar behavior but each with a different slug being appended to /themes/bp-sn-parent/ in the message.

This forum thread has links to the other two occurrences:

#3 @muraii
15 years ago

  • Milestone set to 1.1


Just installed brand new WPMu 2.8.4a, with a new database, and BP trunk 1903. There are no other plugins; I've done no editing of any code or any themes. I activated bp-default, which, even in this virgin setup, Themes claims has template files in themes/bp-sn-parent/messages, and this same phenomenon emerges.

Again, I've tried other child theming arrangements, and in any case that doesn't involve bp-sn-parent (bp-default child of WP theme, WP theme child of another WP theme), there is no issue. As soon as bp-sn-parent is involved as a parent theme, WSoD.

I'm not sure what environment variables would make this an issue, but that seems a plausible area to research. Is there a particular way in which recent revisions of BP interact with {load, locate}_template() that might be causing the problem, but only on some servers?

For what it's worth, I'm hosted with, a subsidiary of IDA Group.


#4 @apeatling
15 years ago

Unless I can reproduce this I have no way of testing or fixing the problem. I will try a few different setups to see if I can reproduce, but until I do not much can be done.

#5 @muraii
15 years ago

  • Resolution set to invalid
  • Status changed from new to closed

This seems mostly or entirely an issue of my ignorance of how to use Subversion. Rather than update, I was checking out code each time I pulled the trunk. Various files had been left with references to bp-sn-framework, which thwarted my productivity. I have fixed this, and all is well.

Note: See TracTickets for help on using tickets.