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.
@Hugo
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?
EDIT
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.
@Hugo
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 http://itsyourphilly.com.
Thank you for your continued support.
Members only appear in BuddyPress content when they’ve logged in to the site (at least once!).
