Skip to:
Content
Pages
Categories
Search
Top
Bottom

Confusion over element class token changes in backeard-compat

  • Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Can developer or someone in know offer an explanation as to how certain class tokens have managed to change from 1.1.2/3 to the supposedly? same backwards compatible set of theme files.

    Body element classes have changed and make it extremely awkward to preserve a child theme that was based on 1.1.3 default theme and that styled on classes that now have changed especially when the primary blog body class is now outputting the same classes as the three column widget home page i.e ‘home-page’ and ‘logged-in’ whereas before I had ‘blog-page’ and ‘logged-in’

    Does anyone know off hand where the body classes are generated from so that I can go back in and change them back.

    Changing little things like this can soak up an inordinate amount of time trying to sort out; backwards compatibility should really have meant this sort of thing doesn’t happen.

    Out of interest the new class names appear to be from the 1.2 files or at least an install using 1.2 default theme shows these same classes which doesn’t feel correct?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Avatar of Andy Peatling
    Andy Peatling
    Keymaster

    @apeatling

    All in the function bp_get_the_body_class()

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Thanks Andy I’ll have a rummage for that in a while.

    Can you clarify though, why the change? as it does make preserving child theme extended from original theme files all the more awkward. I’ll be a little more indifferent to this when I get time to properly start from scratch but for the moment have to live with extending from existing markup and styles.

    I would also love a little reassurance from the Dev team that creating real themes not just skins based on existing files with mix of views and controllers. I say this only as I’m a little concerned by the decision to move the default theme into the plugin buddypress folder for ease of updating as this suggests that crucial files one may have rewritten or customized might actually be updated by newer versions and these updates will have to be identified and transposed to ones custom files.

    I can understand the decision to work this way keeping default theme within an upgrade structure but worry slightly that it’s not perhaps the best route for those that do intend to spend a bit more time than simply skinning; then again perhaps buddypress is best suited to simply skinning with a few adjustments made through functions.php etc which I could live with actually but only if developers stopped trying to output naughty markup such as empty div elements used to provide clearing A COMPLETELY UNNECESSARY APPROACH AND WRONG on many counts ;-) (sorry needed to get that off my chest :) )

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

You must be logged in to reply to this topic.