Opened 11 years ago
Closed 11 years ago
#5036 closed defect (bug) (wontfix)
Standalone theme with partial templates copied over uses theme compat to render missing templates
Reported by: | hnla | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | |
Component: | Core | Keywords: | |
Cc: | hnla |
Description
This ticket for reference following on from IRC chat with Bone & JJJ.
Note: The described scenario is not intended as a real world one but was a happenstance with a site install missing register.php as manual user registration in effect.
Nub of the question is:
In the event of a standalone theme missing templates from bp-default should theme compat kick in and render them via page.php or equivalent when the theme states add_theme_support('buddypress') and also has members/members-loop.php in place ( two checks to disable theme compat).
Scenario was a standalone theme with most bp-default templates copied over except /registration/
functions.php overloaded bp_dtheme_setup() and copied all necessary calls to run BP including add_theme_support('buddypress')
Expected behaviour with missing templates would have been a white screen however in practise theme compat was cutting in and acting as though theme compat was in effect and injecting content to page.php despite the theme setting two parameters that theme compat should check before proceeding.
This may or may not be a bug but not specifically labelling it as such as the test case in my opinion not a valid one as a method moving forward with theme compat and theme development.
Change History (3)
#2
@
11 years ago
Yep have read through that file but need to try and re-create the issue to re-fresh my mind on what I perceived as feeling wrong, part of the issue was the understanding of how we check for /members/members-loop.php and bail if found.
I think though, to answer your question, yes we probably should kill theme compat completely, or at least we ought to have a clear separation between two operational modes rather than a semi mixed one, even if only to avoid human confusion.
This is though a situation unlikely to arise in a real world scenario so doesn't merit too much concern?
#3
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
I'd rather we not use one existing switch to operate two separate pieces of functionality. It's relatively easy to kill already, though it's not documented anywhere.
That said... the whole purpose of theme compatibility is to fill in the gaps of missing templates, and to avoid our previous white-screen situation. If someone wants to disable theme compat, they can unhook it on their own.
Closing this as wontfix. We can still continue the discussion here though, and reopen if anything changes.
add_theme_support( 'buddypress' )
only disables bp-legacy's CSS / JS / hooks at the moment.In actuality, theme compat runs when a bp-default template isn't found.
See:
https://buddypress.trac.wordpress.org/browser/tags/1.7.3/bp-core/bp-core-catchuri.php#L378
In particular, check out lines 397-411.
The question is should we fully kill theme compat when
add_theme_support( 'buddypress' )
is in use.