Settings fallback 'members/single/settings.php' is never used

[r-a-y]

Changeset [5134] introduced a new fallback file:
/members/single/settings.php

However, this settings file is never loaded because the applicable BP settings action functions point directly to the /members/single/settings/x.php files.

For example, ​http://buddypress.trac.wordpress.org/browser/trunk/bp-settings/bp-settings-actions.php#L112 should point to 'members/single/home'.

And the template file - 'members/single/settings/general.php' should just contain the body of the content instead of the entire template.

---

If the above logic is what was originally intended, let me know and a patch will arrive on your doorstep!

Yes, it looks like this was incompletely done. IMO, the more abstract, the better for themers; that suggests mirroring the other components by putting the header/footer/nav elements in the settings.php file and making the individual templates in /members/single/settings/ as small as possible.

Templates could use a once-over as far as whitespace and do_action hooks are concerned.

I left the whitespace the way it was originally in the template and kind of deliberated over the hooks.

I'm going to bump this to 1.6, so that we don't go changing template logic in the middle of a dev cycle.

r-a-y - This one kinda got lost in the milestone. I think it's probably OK to go in, as long as it's backward compatible with existing custom themes. Can you think of scenarios where it would break?

Backpat is going to be an issue, especially for custom themes and BP Template Pack users.

For these instances, theme devs would have to modify the settings templates to strip everything but the content. I'm reluctant to put theme devs through another template change like we did from 1.2 to 1.5, but it might be necessary.

Can't think of a good solution at the moment without introducing new template files and deprecating the older ones.

Any other ideas?

I think you're right, r-a-y.

Any other ideas?

The other option is to go ahead and remove the unused template, and remove references to it from members/single/home.

When we do more of an overhaul to BP theme compatibility, we can think about fixing this. In the meantime, I don't think it's worth it.

Agree. Punting to future release based on above comments.

This is addressed in bp-legacy (theme compat) for 1.7, but unfortuntely bp-default will have to live with this defect due to backwards-compatibility concerns.