[@peterverkooijen Participant 16 years, 10 months ago]

Thanks Brajesh Singh! That fixed it.

I assumed it was a theme issue. Hadn’t even touched the permalinks settings yet.

[@peterverkooijen Participant 16 years, 10 months ago]

Uploading all the contents of the Buddymatic folder into /wp-content/themes doesn’t work.

Then I tried uploading everything into bp-sn-parent, but after activation I get this kind of errors in the site:

Fatal error: Call to undefined function bp_has_site_groups() in /serverpath/public_html/mysite/wp-content/themes/bp-sn-parent/directories/groups/groups-loop.php on line 1

Uploading Buddymatic into bp-default did not change anything.

Why is there no explanation anywhere what to do with this bunch of files? It may be obvious to someone who followed the whole theme development thing, or knows what Thematic is, but not to simple folk.

EDIT: The errors are probably due to recent changes in core files. They go away if I add the latest groups-loop.php etc.

I still don’t get where to put the sample-buddymatic-child and/or coffee-with-friends folders; should they stay within the Buddymatic folder? Or should I put them in /themes on the same level? I tried that, but then the admin area says:

Broken Themes (Site admin only)

The following themes are installed but incomplete. Themes must have a stylesheet and a template.

Name Description

A Thematic/Buddymatic Child Theme Template is missing.

[@peterverkooijen Participant 16 years, 10 months ago]

This looks like a good starting point to rebuild my site on version 1.2. I’m still very confused about the new parent/child theme system… (probably need to get some food)

I’ve downloaded Buddymatic. Now what? Should I upload the Buddymatic folder to /wp-content/themes? And then I can activate it?

Should I replace everything in /themes, including index.php, /bp-default, /bp-sn-parent?

Should I use the sample-buddymatic-child folder as starting point for my own theme?

[@peterverkooijen Participant 16 years, 10 months ago]

I meant, take plugin settings out of the admin area back end and make them available on the members account settings on the front end.

Some plugin functionality could be very useful to members, like adding an RSS feed via FeedWordpress, but you can’t expect all members to be web savvy enough to find their way in the WordPress backend.

BTW, the title of this topic should probably have been “Provide only certain selected plugins to members?”

[@peterverkooijen Participant 16 years, 10 months ago]

Thanks. I’ll try that plugin. It doesn’t look very solid though…

Definitely not BP core, since blogging is all WPMU.

Would there be a way to make plugin settings show up somewhere on member pages? Perhaps under ‘settings’? Or even just links to the full plugin settings in the admin back end?

Can you use the code in plugins that add settings to the admin area to make them show up on the front end somewhere?

These questions are also related to something I’ll be working on here…

[@peterverkooijen Participant 16 years, 10 months ago]

Thanks David Lewis. I’ve entered svn.buddypress.org into CuteFTP and that works surprisingly well. It also seems to give me access to anything else on subversion.tigris.org…

[@peterverkooijen Participant 16 years, 10 months ago]

socialpreneur, can you guarantee that ANY plugin that works on WPMU also works on Buddypress? And works for all features of Buddypress?

[@peterverkooijen Participant 16 years, 10 months ago]

Thanks for those clues r-a-y, but I have no idea what you’re saying here.

I had to go through a lot of headaches to get the body class tags to work the first time around. I’m now about to start on upgrading to 1.1.3 (or hopefully 1.2).

Can anyone explain in plain English how to get the right body tags? Which piece of code in which file generates them? Why does it break with some themes?

I have my own custom theme. German’s changes are too much of a hack. I’m trying to make a clean new start.

[@peterverkooijen Participant 16 years, 10 months ago]

I’ve used the FeedWordPress plugin for a while. It’s excellent.

With administrator access you can associate RSS feeds with member blogs. It should be possible to make that functionality available to regular members so they can do it themselves -> voila, external blogs.

I’ll look into this in the next two weeks, when I’m upgrading to version 1.1.3 or 1.2. I’ll probably use crude custom code to add an input field that allows members to enter an RSS feed directly into FeedWordPress’ database table.

To turn it into a more sophisticated plugin I’ll probably need some help.

Is anyone else still working on this? Any ideas, comments or suggestions?

I’ll report back when I’ve made some progress…

[@peterverkooijen Participant 16 years, 11 months ago]

I won’t be at Wordcamp NY, too many other conferences and deadlines, but I’d certainly attend a Buddypress meetup.

I organize monthly networking events for web startups in New York, under the name Web2NewYork – a Buddypress site of course.

Keep me posted!

[@peterverkooijen Participant 16 years, 12 months ago]

Excellent, that works very nicely. Thanks John James Jacoby!

Could something like this become part of the core? When you have the name of a member, it should be easy to add associated data. This function makes it a lot easier.

Edit: The function probably needs to be expanded a bit. I get these slashes (escapes?) in the output:

Pandora's Box

I’ll look into that when I have time…

[@peterverkooijen Participant 16 years, 12 months ago]

Thanks for the additional information. I’ve tried this in members-loop:

<?php if ( $company = xprofile_get_field_data('Company') ) : ?>

<p><?php echo $company ?></p>

<?php endif; ?>

and this

<p><?php echo xprofile_get_field_data('Company'); ?></p>

Still get nothing with either version…

[@peterverkooijen Participant 16 years, 12 months ago]

Doesn’t work for me. Field id ‘2’ is supposed to be company name in my installation, but this in the members_loop.php only displays name and last active:

<h3><a href="<?php bp_the_site_member_link() ?>"><?php bp_the_site_member_name() ?></a></h3>

<p><?php do_action( 'bp_core_directory_members_content' ) ?></p>

<p><?php echo xprofile_get_field_data('2'); ?></p>

<label><?php bp_the_site_member_last_active() ?></label>

Should I use bp_the_site_member_something(‘2’)?

[@peterverkooijen Participant 16 years, 12 months ago]

But feel free to write your own function if you thinck it’s valid php, aproved code and needed service by the majority of your visitors.

I already have the function. See above. Didn’t write it myself, it’s a generic piece of code that a lot of scripts use. My question is where to apply it.

To have the first letter of each word in uppercase, you can use text-transform:capitalize;

Tried that. Doesn’t work. Still only capitalizes the first letter of the block.

[@peterverkooijen Participant 16 years, 12 months ago]

Why is it ridiculous to do styling with CSS?

See edit2 in my previous post.

I know that you want to create consistentcy in your database, but if it’s just because it looks nicer, then just use CSS.

They are names for f**** sake! They’re supposed to start with an uppercase, as a generally accepted standard. It’s convenient to have them in the database in a way you can tap into without having to do anything else to them.

[@peterverkooijen Participant 16 years, 12 months ago]

@Chouf1, the code is not for uppercasing; it’s making sure firstname and lastname are stored consistently in the different places where WP/WPMU/BP stores names.

Why is it too much to ask for consistently, reliably stored firstname + lastname in the WordPress world? Uppercasing should be part that imho. It’s utterly ridiculous to have to do that in CSS. Is that even official CSS? Do all browsers support it?

In most software for grownups firstname and lastname fields are at the top of the members/users table, part of the core of the application, the heart of member registration and management. In the WP/WPMU/BP world it’s a messy afterthought, stored halfheartedly in three or four different locations, in different ways, without any synchronization between them. Aaarrrggghhh.

Before a WordPress user account is activated, it is stored in the wp_signups table; there’s a meta field storing various things. Have you checked if its that one?

That’s one of the two places where the lowercase version of the name is stored. My code above updates names with uppercase in the usermeta fields.

My question is which code stores them in xprofile or wp_signups. Where should I apply my nameize() function to get clean names in xprofile?

Cleaning them up before they’re stored in wp_signups would do the trick as well, because I think the xprofile data is taken from there. I don’t think the wp_signup data is used for anything else later, so it has a lower priority to me.

Edit: Of course I’m not trying to uppercase all chars of the name, just the first ones, as used to be custom in western culture. FYI, here’s the nameize function I use:

function nameize($str,$a_char = array("'","-"," ")){

//$str contains the complete raw name string

//$a_char is an array containing the characters we use as separators for capitalization. If you don't pass anything, there are three in there as default.

$string = strtolower($str);

foreach ($a_char as $temp){

$pos = strpos($string,$temp);

if ($pos){

//we are in the loop because we found one of the special characters in the array, so lets split it up into chunks and capitalize each one.

$mend = '';

$a_split = explode($temp,$string);

foreach ($a_split as $temp2){

//capitalize each portion of the string which was separated at a special character

$mend .= ucfirst($temp2).$temp;

}

$string = substr($mend,0,-1);

}

}

return ucfirst($string);

}

Edit2: The CSS solution only works on the first name. The last name still starts with lowercase. Any easy CSS trick for that? I don’t think so.

Apparently the same CSS trick is used in this forum, which would explain why my “username” – cough, spit – is displayed as ‘Peterverkooijen’ instead of ‘peterverkooijen’ as I had entered it. Why is that kind of mess considered acceptable?

[@peterverkooijen Participant 16 years, 12 months ago]

@Arghagain, that’s a bit fatalistic. I am removing them manually now, but they all sign up with *.info email addresses. There should be a way to block those.

Apparently the Banned Email function in wpmu doesn’t work because of a stupid bug and anyway it doesn’t allow wild cards. Are wp/wpmu/bp developers even working on this or are they too busy adding “cool” widgetize features etc.?

[@peterverkooijen Participant 16 years, 12 months ago]

Chouf1, are you sure wp-login.php is even used in Buddypress registration?

Edit: Tried the code. I get an “Parse error: syntax error, unexpected T_ELSEIF”.

[@peterverkooijen Participant 16 years, 12 months ago]

r-a-y, I’d like to try the .htaccess solution, but the instructions are very ambiguous:

# BEGIN ANTISPAMBLOG REGISTRATION

RewriteCond %{REQUEST_METHOD} POST

RewriteCond %{REQUEST_URI} .yourbpsignupslug*

RewriteCond %{HTTP_REFERER} !.*yourhomedomain.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^$

RewriteRule (.*) http://die-spammers.com/ [R=301,L]

# END ANTISPAMBLOG REGISTRATION

Should I leave the dots (.) and stars (*) around ‘register’ and ‘mywebsite.com’?! What would be mybpsignupslug if I have the registration form on my homepage as well as /register?

[@peterverkooijen Participant 16 years, 12 months ago]

My spammers all sign up with .info email addresses. Is there any way to just block all .info?

Legitimate members should use normal .com emails, like normal people.

[@peterverkooijen Participant 17 years ago]

I would not use Buddypress if it would force members of my sites to sign up with OpenID. Perhaps I misunderstand, but I would always want the option to make an old-fashioned closed off site with its own registration, independent of OpenID or whatever other self-appointed overseer – sure Facebook, Plaxo etc. are “all advocating that stuff”, they want to become the gatekeepers.

[@peterverkooijen Participant 17 years ago]

Lucky you. I had to install a plugin and edit CSS files to get rid of that ugly thing at the top. My guess would be that removing the Buddybar is a feature of “Arthemia Premium theme”.

[@peterverkooijen Participant 17 years ago]

@DJPaul, my site has lots of messy customization, but I saw the same error when I put back the original template. Not 100% sure. Please check if you get the chance.

I’ll try German Laullon’s edits.

[@peterverkooijen Participant 17 years ago]

Yes, sort of. Dead link is now apparently default behavior when sign-up is not activated. Makes sense.

But it will take me a while to recreate my heavily customized registration process in the new templating system…

[@peterverkooijen Participant 17 years ago]

OK, figured out that link doesn’t work when sign-up is not activated.

Now putting my template back, see what happens…