[Gabriel Liwerant]

@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.

[Gabriel Liwerant]

@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.