Skip to:
Content
Pages
Categories
Search
Top
Bottom

Activating bp-default = White Screen of Death, Including Admin

  • Avatar of muraii
    muraii
    Participant

    @muraii

    Hello,

    First, the meta:

    1. Which version of WPMU are you running?

    - 2.8.4a

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

    - As a directory

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

    - A subdirectory

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

    - 2.8.3

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

    - Yes.

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

    - Trunk revision 1885

    7. 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)

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

    - No.

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

    - Standard.

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

    - No.

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

    - No.

    12. If running bbPress, which version?

    - Whatever is integrated with BuddyPress

    13. 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/.

    5. FTP bp-default/ and bp-sn-parent/ to themes/.

    6. Activate BuddyPress.

    7. Activate bp-default.

    8. 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.

    Anyone have any ideas?

    Cheers,

    Daniel

Viewing 18 replies - 1 through 18 (of 18 total)
  • Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    Before activating BuddyPress, did you delete the /bp-themes/ directory? If you do not, and then activate BP and choose the new theme framework, BP can have issues resolving which theme system–the old or the new–your wanting to use.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Hi, Jeff,

    Yup. /bp-themes/ has been toast for some time now.

    Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    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?

    That is very strange. There have been two other reports of something similar–except one listed /blogs the other listed /groups.

    Please file a ticket so that we remember this issue. Perhaps with a little more information, we might be abel to find out why some people have seen this behavior.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Ah, so maybe I haven’t b0rked anything myself, or, in fact, several people are breaking things consistently yet independently. I will tonight test the parent/child behavior of WPMu itself, by setting two WP themes into such a relationship to see if it, too, has issues. If not, it would appear that there is something in the WPMu <-> BP interaction.

    I have filed this ticket:

    http://trac.buddypress.org/ticket/1031

    Just for clarification, I had been working with parent/child theming with BP trunk for some few weeks without any problems. I’ll keep from updating until we have sorted something out.

    Cheers,

    Daniel

    Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    Daniel-

    Thanks for filing your ticket. I’m interested to hear the results of your tests.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Hi there,

    I have made one WP theme a child of another WP theme, activated, and had no issue.

    I have made bp-default a child of another WP theme, activated, and had no issue.

    There is something about bp-sn-parent that confuses WPMu.

    I want to keep the situation clean, and not confound troubleshooting by installing a new trunk revision. I have tried this a couple of times already, having noticed the problem while using 1881, then pulling 1882 without improvement, and similarly with 1885 (what I’m currently using). However, if you think that would help, I’m happy to.

    Is there anything in the way SVN pulls everything down to my local machine that might cause the issue(s)? Since I’m not checking trunk out directly on the server, as I don’t have ssh access, I check out locally then FTP.

    Anyway, I hope this proves useful beyond my particular situation.

    Daniel

    Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    You should be fine checking svn out or even using the zipped file of whatever trunk version you want. I’ve recently tried both just to make sure that there was not some strange issue.

    Are you creating a brand new database with each install attempt? In other words, is it a totally clean install? if not, I would suggest installing with a new DB and see if this behavior goes away.

    Avatar of Andy Peatling
    Andy Peatling
    Keymaster

    @apeatling

    Always keep on the latest trunk, there is no point in spending time on this if something else has already fixed it.

    Please try a completely fresh install, new DB, new WPMU and new BP. We need to isolate if this is a problem with your current install, or something in a fresh stock install.

    Avatar of muraii
    muraii
    Participant

    @muraii

    New trunk (1902) changes nothing. I’m going to test on another site. I’ll get completely fresh later this weekend probably.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Hi there,

    Using same trunk revision (1902) on a different install (not new, clean install, but different directory and db), and the same thing happens:

    - bp-default is claimed to have its template files in bp-sn-parent/messages

    - activating bp-default kills the renders the whole install inaccessible

    - renaming bp-sn-parent returns access

    As I tried some non-BP parenting the other day without problems, and even parented bp-default to another WP theme without issue, this seems to be bp-sn-parent. I will, however, start with a completely fresh install once I have the time.

    Daniel

    Avatar of muraii
    muraii
    Participant

    @muraii

    Hi,

    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 Fourbucks.net, a subsidiary of IDA Group.

    Daniel

    Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    Okay, I’m just checking to make sure that we are on the same page. What exactly do you mean by “virgin setup”. Is everything brand, spanking new?

    To me, a virgin install is this:

    • You’ve deleted all the content (visible and invisible) from your root folder
    • Your using a blank DB that has a different name, username, and password from any that you’ve used before
    • You’ve cleared your browser’s cache
    • You’ve downloaded a new copy of WPMU and installed it, creating brand new wp-config and .htaccess files
    • You’ve downloaded the newest BuddyPress trunk (if running bleeding edge). If using a tagged version of BP, then you’ve downloaded that version again to have a fresh, clean copy. You then manually install BP and then activate it.
    • You have no other themes installed in wp-contents (other than the default WPMU and BP themes)
    • You have no other plugins except BP (and possibly the default plugins that come with WPMU)

    Also, it does not hurt to clear your Apache and PHP error logs so that you can easily see any errors specific to your new install.

    Avatar of Jason Giedymin
    Jason Giedymin
    Participant

    @jason_jm

    I’d like to add that for us we also restart our http server process, your PHP processes, your cache server, and browser cache/cookies. This is to get as clean a start as possible in conjunction with what Jeff has said.

    May also help you too…

    Avatar of muraii
    muraii
    Participant

    @muraii

    * You’ve deleted all the content (visible and invisible) from your root folder

    – Have not done this, but I did create a new subdirectory and installed WPMu in that location.

    * Your using a blank DB that has a different name, username, and password from any that you’ve used before

    – Check.

    * You’ve cleared your browser’s cache

    – I’ve done this with previous testing, but not with this new install. I’ll try that.

    * You’ve downloaded a new copy of WPMU and installed it, creating brand new wp-config and .htaccess files

    – Check.

    * You’ve downloaded the newest BuddyPress trunk (if running bleeding edge). If using a tagged version of BP, then you’ve downloaded that version again to have a fresh, clean copy. You then manually install BP and then activate it.

    – Check (revision 1903, as noted).

    * You have no other themes installed in wp-contents (other than the default WPMU and BP themes)

    – Check.

    * You have no other plugins except BP (and possibly the default plugins that come with WPMU)

    – Check.

    —-

    So, it seems that clearing my browser cache and clearing the root folder might be the only issues. I’m imagining that the latter assumes I’ve installed in root, which I haven’t; I have a single-user WP blog there that’s not going anywhere. I could install to my local machine (which I’m likely to do anyway), but that wouldn’t seem to invalidate this particular phenomenon.

    As to browser cache, I’ve cleared that before without affecting results, and will do so now; but that would seem to suggest it’s not critical. I’ll leave a note after I’ve tested it, though (don’t want to while replying, for obvious reasons).

    WPMU Directory installs in subdirectories are known to cause all sorts of odd issues.

    If this is something you can’t discount by testing, maybe one of us better do an install like yours.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Thanks, DJPaul (though there’s no href in your anchor). I’ll have to figure out a way to test in a root context, most probably on my machine.

    Avatar of muraii
    muraii
    Participant

    @muraii

    Just thought it was worth noting, though, that I’d been running WPMu and BP without issue for quite a while. It was BP 1.0.3 at first, but then BP trunk. There didn’t seem to have been any issues that WPMu had been installed in a subdirectory during all that time.

    Avatar of muraii
    muraii
    Participant

    @muraii

    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. I’m fixing the ticket #1031 right now.

    Oy.

Viewing 18 replies - 1 through 18 (of 18 total)

You must be logged in to reply to this topic.