Skip to:


  • shadyday


    Buddypress does not treat the label tag uniformly across its features. Sometimes the label tag is used incorrectly as a wrapper for many elements like inputs and lists, and other times it is used correctly as markup on text that describes an input. An example of labels applied incorrectly is under the default theme > groups > single > admin.php in version 1.6.1.

    Another problem is that when creating a child theme of the default with css from scratch, changing certain visual elements, such as the height of the textarea on the post update box of the activity section, causes the theme to run afoul of the global.js file. The global.js file appears to contain essential functionality (at least in the form of error reporting) and non-essential functionality such as animations and scrolling flourishes. Since use the javascript can’t be avoided, it’s wrong to make css appearances dependent on it. The file should either be broken up into multiple files, some of which would be optional, or the animation flourishes should be discarded as unnecessary, and left to the theme developer to include or not.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Problem with the global.js is that it was built with the default theme in mind, and while I would tend to be in agreement, think it’s far too complex to break up and/or may simply cause too many issues, we as custom theme creators of course have the option not to use it, or write our own.


    I too have recently had the hassles of dealing with the whats-new-textarea on separate sites, so it is something that could do with an approach along the lines you suggest of splitting the files up and enqueueing separately so we could easily dequeue or overload.


    One thing we did do was to go through global.js and remove a lot of the selectors to just classes or id so we could in fact re-format markup without fear of breaking functionality.


    Where is the incorrect use of labels?  yikes yes you’re dead right never ever noticed that and I’ve been through these files a hundred times, that is terrible *shakes head *


    One thing though bp-default might be considered somewhat redundant now with the release of 1.7 impending.



    1.7 template files are completly new. I wouldn’t worry unless you are not going to upgrade

    The JS is mostly the same, though.

    1.7 template files are completly new. I wouldn’t worry unless you are not going to upgrade


    Only problem there though is a quick update and check of the errant file shows exactly the same markup sans it’s get_header/get_footer so unless it’s a case that this file has yet to be dealt with the same mal-formed markup will filter through.




    Thanks for your response. I’ve been working on making a child theme of the buddy press default and I’m in the process of completing redoing all the CSS. This is how I’ve run into the issues, and in fact, I continue to find them. In the folder members > single > profile > profile-loop.php version 1.6.1, there is heavy use of tables for positioning the radio inputs yet other sections for settings (as in groups), there are no tables used. Issues like this are making consistent styling throughout the site quite cumbersome.

    Since some of these markup issues are untenable to me as I do my work, I’ve had to change them, further specifying my child theme against the parent theme. This now presents an upgrading problem. I will have to thoroughly test any new version to ensure that I don’t have issues.

    @Paul Gibbs

    Not sure what you mean. When I look at the global.js file, I see at least two kind of things going on. There are things like ajax calls and error handling and then there are purely cosmetic issues such as height and scroll animations upon certain field focusing. I don’t see why these should be commingled in the same file.

    For example, initially I ran into trouble with re-styling one of the textareas due to the cosmetic javascript, so I went in and commented out the offending lines. But then I decided I didn’t want a complicated build process every time the client updates the theme, so I eventually kowtowed to the javascript and kept the textarea height to match.

    For me and other developers to have full control over the appearance of our themes, this is currently a stumbling block. But admittedly, I did not spend a great deal of time looking of global.js and maybe I’ve misunderstood and everything in it is cosmetic and optional?


    Sorry Paul, I misunderstood that you were responding to the moderator above you and not to the original post. But I’ve kept the reiteration of the problem here for emphasis.

    Personally I never build a child theme ever unless I’ve built the parent, in respect of BP don’t create a child theme, create a theme that simply uses aspects of BP functions.php and that calls ajax.php/global.js, bp will work fine you then overload every BP template to your theme and modify the markup exactly as you need it, considering you’ve started CSS from scratch you really should be overloading the templates as well if you are a developer.

    These issues you raise are well known (did miss the admin.php though) and where it’s possible some of us attempt to provide patches, but with a default theme there are many issues in changing things that might break existing sites thus the approach I’ve outlined for devs that know what they are doing.

    Do a checkout on the BP svn trunk you’ll be able to study the newer theme compat files that will represent the newer approach to providing template files, the markup for this change is able to be and is being completely re-written and basic styles to suit installs on any theme being fashioned.




    I have already been overloading the default template, which I thought was the basis of creating a child theme. Of course, overloaded files with edited markup will be problematic to update if the default theme is updated, so this probably means that the overloaded theme will lag behind in updates forever, which nullifies one of the primary benefits to using an existing theme.

    I understand about keeping compatibility for existing themes. Might be nice to have new themes added then, the way wordpress has twentyten, twentyeleven, twentytwelve… Old themes remain to provide compatibility, but new ones allow new installs to take advantage of fixes and recent developments. But now I’m getting greedy I suspect!

    While I’ve got you, I noticed on the site I’ve been working on, which is very new, there are signups present in the database and marked active with an activation date, but do not show up with the members widget. It shows the member when I sign up myself and activated the account. I’m using WPMU and Buddypress.

    My question is, what is different in the model between my own activated account and the activated accounts I’m not seeing? I suspect some of these accounts may be spam, but if they are marked as active in database table wp-signups, why would they not be present as a member? Are there two separate places to register, and if so, what are they? If there is a separate database field that marks members for buddypress, where is it? I am only aware of the registration section for buddypress. Site is

    Thank you for your continued support.

    Members only appear in BuddyPress content when they’ve logged in to the site (at least once!).

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Inconsistencies’ is closed to new replies.
Skip to toolbar