[@peterverkooijen Participant 17 years, 3 months ago]

I am now going through the How to Write a WordPress Plugin tutorial on DevLounge.net.

It says you can hook into WordPress to execute pieces of code using WordPress actions. I assume in my case I should use this action:

register_post

So I should write a function that somehow forms and executes that URL – http://mysite.com/…/listmessenger.php?etc. – and trigger that on registration using register_post?

And to construct the function I can use WordPress filters? The available ‘database writes’ filters are only for WordPress tables of course…

How would I add data to tables outside WordPress, in this case the ListMessenger tables?

Edit 1: Stupid question; that is done by that URL created by $post_data=… in the PHPList code.

Or is there a better way to add data to the database directly from the plugin?

Edit 2: This page has more information on creating/updating tables outside regular WordPress. Would that approach be better than that URL?

[@peterverkooijen Participant 17 years, 3 months ago]

The cleanest way to get separate firstname and lastname into the database seems to be to

1. split the input from Buddypress’ fullname field using xprofile_sync_wp_profile()

2. make a two or more part name in fullname required

How would I do that? Can someone please help, because this would solve a major structural problem in Buddypress imho.

I need to come up with a solution, because integration with most mailing lists depends on having firstname and lastname stored somewhere.

Alternatively I have to use fullname for firstname and create a second custom xprofile field for lastname. That solution will problably cause lots of problems further down the line.

[@peterverkooijen Participant 17 years, 3 months ago]

Have you copied the “groupblog” templates folder to your bp active member theme?

[@peterverkooijen Participant 17 years, 3 months ago]

Cool! I’ll have to make time to learn how to use all these options…

[@peterverkooijen Participant 17 years, 3 months ago]

Thanks for this code, allenweiss! I still have to sort this out in my project, after my current day job deadline. Not looking forward to it…

I had started several threads about this.

[@peterverkooijen Participant 17 years, 3 months ago]

So we should all be enormously grateful for that. I don’t think threats to move another platform are really productive.

I am grateful and Buddypress developers wouldn’t care whether I move to another platform or not. I was responding to John James Jacoby’s argument that people stick with WordPress because it has found the right balance.

WordPress is evolving from blog software to a social networking platform with Buddypress. That puts the user at the center, which is a fundamental shift in focus. That’s why I keep hammering on member management and registration.

I love the extensibility of WordPress/Buddypress, but if the foundation – member management – is a mess, that is a real problem that can force people to consider other options. I have not found good alternatives. Anahita Social Engine on Joomla could be one to watch.

[@peterverkooijen Participant 17 years, 3 months ago]

@sandeepdude, I did not contribute anything to that code, all credit should go to Burt Adsit.

[@peterverkooijen Participant 17 years, 3 months ago]

Of course not, that wasn’t my point. The registration functionality in WPMU is quite restrictive and cumbersome right now. That will improve though. If you’re concerned about this, then don’t consider BuddyPress as we’re only on version 1.0.

I was going to take the gamble that it would improve over time. Hearing most developers here dismissing any architectural criticism and only singing the praises of WordPress is not encouraging though.

You know why people that join fraternities rarely ever leave? Because once you’ve gone through the hazing, you’re more likely to stay.

Right, once you’ve decided on a platform it’s very hard to go anywhere else. You’re stuck.

Every couple of years I reevaluate what to use for my websites. I started on Nucleus. The current version of my project Web2NewYork is built on WordPress with a members registration system based on code taken from PunBB.

I switched to WordPress reluctantly only because it was becoming the standard. I’m now trying to consolidate on Buddypress, if I can everything working before September. If member management/registration does not improve I will have to switch to something else next year.

[@peterverkooijen Participant 17 years, 3 months ago]

If you are concerned with the way WordPress is programmed, then I would asses the value in being concerned. Look at the number of themes, look at the number of plugins, look at the number of users. Look at the companies that use WordPress. At what point does worrying about the coding style become moot?

That’s why I chose to build my new site on Buddypress. Does that mean I have to keep my mouth shut about the crappy patched together membership management mess that will now become the foundation of my project? It’s not a moot point. It’s a painful trade-off and if I could start over I’d probably give Joomla + Anahita Social Engine a go.

I’m perfectly entitled to not pay attention to the MVC-or-not structure of both WordPress and Buddypress, as I don’t work for Automattic and I’m not a core developer on either.

I was addressing the Buddypress development community in general.

[@peterverkooijen Participant 17 years, 3 months ago]

Member management in WPMU/Buddypress seems patchy as hell to me, with member data spread out over several database tables that aren’t synchronized between xprofile and wpmu, mixing different methods to store data. The registration process is horribly inflexible. Basic things like styling the registration form or editing system emails require hacking core files.

Not sure if this would have been better if WordPress/Buddypress followed an MVC architecture. Wikipedia’s description of MVC:

Model-view-controller (MVC) … isolates business logic from the user interface, permitting one to be freely modified without affecting the other. The controller collects user input, the model manipulates application data, and the view presents results to the user …

I like the sound of “isolating business logic”. I want the end user functionality that WPMU/BP provides (“… WordPress’s usability …”), but have serious concerns about having to rely on WPMU/BP for central member management and registration, the foundation of my project. Unfortunately I can’t have one without the other.

Please don’t dismiss the criticism.

if there’s someone moaning about how any particular bit of software is not written following MVC, they have two options – write their own, or shut up.

They did. They are developing Anahita Social Engine on Joomla. I may have to check it out.

[@peterverkooijen Participant 17 years, 3 months ago]

“I suspect this will be less of a BuddyPress thing and more of a WPMU thing as it comes down the pipeline.”

Does that mean Nicola Greco’s code – “70 percent done” – will not be integrated into a future Buddypress?

Will Nicola Greco contribute the code to WPMU? Should we raise the issue at the WPMU forums?

[@peterverkooijen Participant 17 years, 3 months ago]

Yes, I’d like more group functionality and this is obviously a big one! These plugins could be starting points:

Private Files

File Uploader 1.0 Beta

Custom Upload Dir

Haven’t looked into any of these in detail…

[@peterverkooijen Participant 17 years, 3 months ago]

Thanks Jeff Sayre! The plugin claims to be compatible up to 2.7.1 and explicitly mentions Buddypress, so that looks promising.

@paulrostorp-1, don’t count on me to write a plugin anytime soon! I’m not a PHP coder. I want to look into this, but have some other issues higher on the to do list.

[@peterverkooijen Participant 17 years, 3 months ago]

@socialpreneur, would that get paulrostorp-1 any closer to what he wants to achieve? That whole approach sounds like a dead end to me.

He wants 3 account types with different allowed numbers of blogs and upload limits per account. Creating three separate MU/BP installations doesn’t solve that, it will only make it harder to manage those membership levels.

I think he probably needs an additional plugin that adds account settings for # of blogs and upload limits to different classes of members as defined in the commercial membership plugins.

Is setting the number of blogs allowed per user possible now? Are there “hooks” to make it possible? Idem dito for upload limit.

I’m not a PHP coder, but I suspect it’s doable. I plan to study up on plugin creation etc. second half of this month. I’d like to have this type of functionality myself. Any suggestions and contributions appreciated.

[@peterverkooijen Participant 17 years, 3 months ago]

Yes, I’d use this!

At the moment there’s not much you can actually do in the groups, I think. I’d planned to look into options to add more functionality.

Where can I get this plugin? I would like to test it.

[@peterverkooijen Participant 17 years, 3 months ago]

Those are all WP plugins and not WPMU ones.

I would steer clear of them.

Wishlist claimed to me their plugin works with WPMU/Buddypress. Haven’t tried it yet, but I trust the MU/BP developers did not break the basic registration process.

Also MU/BP is obviously a big potential market for these plugins, so you can kinda expect they make sure they work.

[@peterverkooijen Participant 17 years, 3 months ago]

There are several commercial plugins that create membership levels. You’d probably need custom code to connect the levels to the functionality you describe.

If you figure it out, let me know.

Or contact me if you want to pool resources.

[@peterverkooijen Participant 17 years, 3 months ago]

Should be an option in “BuddyPress > General Setup”.

Absolutely. Was wondering about this. Where can I leave my vote of support?

Is BeLogical’s hack safe as a temporary solution or can it cause all kinds of unforeseen mayhem?

[@peterverkooijen Participant 17 years, 3 months ago]

Here’s the code I use in the current version of my site – Kunal17 asked about it:

// Include the SimplePie library

require_once 'simplepie.inc';

require_once 'shorten.php';



// Because we're using multiple feeds, let's just set the headers here.

header('Content-type:text/html; charset=utf-8');



// These are the feeds we want to use

mysql_connect(localhost,$db_username,$db_password);

@mysql_select_db($db_name) or die( "Unable to select database");



$query = "SELECT id, email, firstname, surname, rssfeed FROM members WHERE rssfeed != ''";

$result = mysql_query($query);



$feeds = array();

$id_array = array();

$first = array();

$user = array();



$userinfo = array();



while ($cur_feed = mysql_fetch_assoc($result))

{

$feeds[] = $cur_feed['rssfeed'];

$userinfo[$cur_feed['rssfeed']] = $cur_feed;

}



// This array will hold the items we'll be grabbing.

$first_items = array();



// Let's go through the array, feed by feed, and store the items we want.

$ix = 0;



foreach ($feeds as $url)

{

$user_id = $id_array[$ix];

$firstname = $first[$ix];

$surname = $sur[$ix];

$email = $user[$ix];

$ix++;



// Use the long syntax

$feed = new SimplePie();

$feed->set_feed_url($url);

$feed->init();



// How many items per feed should we try to grab?

$items_per_feed = 1;



// As long as we're not trying to grab more items than the feed has, go through them one by one and add them to the array.

for ($x = 0; $x < $feed->get_item_quantity($items_per_feed); $x++)

{

$first_items[] = $feed->get_item($x);

}



// We're done with this feed, so let's release some memory.

unset($feed);

}



// We need to sort the items by date with a user-defined sorting function.  Since usort() won't accept "SimplePie::sort_items", we need to wrap it in a new function.

function sort_items($a, $b)

{

return SimplePie::sort_items($a, $b);

}



// Now we can sort $first_items with our custom sorting function.

usort($first_items, "sort_items");



$counter=0;

foreach($first_items as $item)

{

$feed = $item->get_feed();

$info = $userinfo[$item->feed->feed_url];



$counter++;

if($counter >= 7)

break;



if ($img_size = @getimagesize('members/img/avatars/'.$info['id'].'.jpg'))

$avatar_field = '<img src="members/img/avatars/'.$info['id'].'.jpg" alt="" />';

else

$avatar_field = '<img src="members/img/avatars/nopicture.png" alt="" />';



$picture = '<div id="feedpicture"><a href="members/member.php?id='.$info['id'].'" title="'.$info['firstname'].'\'s Member Page">'.$avatar_field.'</a></div>';



// Begin the (X)HTML page.

?>



<h3><?php echo $picture; ?><a href="<?php echo $item->get_permalink(); ?>" target="_blank"><?php echo html_entity_decode($item->get_title(), ENT_QUOTES, 'UTF-8'); ?></a></h3>



<!-- get_content() prefers full content over summaries -->

<? echo trim(substr((str_replace("\n", ' ', str_replace("\r", ' ', strip_tags($item->get_description())))),0,300)); ?>

... <i>more</i></a><br />



<p class="info"><a href="members/member.php?id=<?php echo $info['id']; ?>" title="<?php echo $info['firstname'].'\'s Member Page'; ?>"><?php echo $info['firstname'].' '.$info['surname']; ?></a> | <a href="<?php echo $feed->get_permalink(); ?>" target="_blank"><?php echo $feed->get_title(); ?></a> | <?php echo $item->get_date('M j, Y | g:i a'); ?></p>

<br />



<?php

}

?>

It shows the latest blog posts from members on a page, if they have an RSS feed in the database. It uses SimplePie. The code above is customized from regular SimplePie feed code. Member management in my current site is based on PunBB, not WordPress.

I’d have no clue how to modify this code for Buddypress. Can’t figure out member management in Buddypress for starters, with x-profile vs wpmu and similar data stored in different places. It all looks kinda messy and inconsistent to me.

Doubtful you should take this as starting point. I’ll wait for the integrated solution.

[@peterverkooijen Participant 17 years, 3 months ago]

You probably need this plugin. It’s an annoying WPMU issue.

[@peterverkooijen Participant 17 years, 3 months ago]

Apparently lack of consistency/synchronization between members data in WPMU and members data in Buddypress x-profile causes other problems as well.

Please look into this! I was going to rely on WPMU/Buddypress for member management in my project, but am not so sure anymore.

[@peterverkooijen Participant 17 years, 3 months ago]

I had this test version of a reordered registration form. It works.

But leaving the one fullname field as it is and splitting separate firstname and lastname to wp_usermeta using xprofile_sync_wp_profile() is probably the better solution – thanks Jeff Sayre and Nicola Greco.

How would that work? Has anyone done it? Can anyone point me to code examples?

I’ll try to figure this out myself, but don’t know where to start. Codex and bp-dev.org provide very little information. I don’t know where else to look.

Why is this not built-in to Buddypress registration by default? It would make the system much more consistent, in particular with an added check to make a two (or more)-part name in fullname required.

[@peterverkooijen Participant 17 years, 4 months ago]

When I need to find out which file(s) produce a page, I take some code from the page source, search my offline copy of WPMU/Buddypress with it and see what comes up.

I use ‘extended find’ in Macromedia Homesite, but there may be other tools you can use.

[@peterverkooijen Participant 17 years, 4 months ago]

One way off the top of my head would be to inject a JavaScript into the registration page – you’d use the BP name function to get what you want. There is already Wp code for “sanitizing” blog post names, and perhaps other areas too. Then it’s a matter of using the JavaScript to set the HTML field’s value, and CSS to hide it.

Thanks DJPaul! That sounds doable. Would it be possible to put that in a plugin or would it have to be inserted in core files?

Well, if you aren’t looking at how the underlying registration functions are coded, then how can you say with such certainty that this is not a WPMU issue?

What I need wouldn’t touch the underlying registration functions. All I need is another way to insert that username into the database on registration. Hiding a field on a form is basically an html/css issue, stuff that I know enough about.

Again, if the username would be generated from Buddypress’ required fullname field, it by definition is not a WPMU issue.

Also getting a more consistent connection in how Buddypress and WPMU handle first name + last name is not a WPMU issue; it’s about how Buddypress (x-profile) hooks into and synchronizes with WPMU.

WPMU does not allow you to position the username field in a different sequence–not without behind the scenes changes.

I have already done that once. It’s no problem. It’s annoying WPMU mixes presentation and functionality in the registration, but I’ll work with what I get.

Without contracting with a coder or coding yourself, you’re out of luck.

I am trying to code myself where I can and am certainly considering contracting a coder. I need to figure out what I need exactly first. Also with these posts I’m trying to point out some imho weaknesses in Buddypress that should get more attention and judging from the private comments I’ve received I’m not the only one struggling with these issues.

[@peterverkooijen Participant 17 years, 4 months ago]

But I’m not too sure whether you can remove–or hide as would actually be the case–WPMU’s username field from the registration form. WPMU is the underlying foundation of the system. It controls everything. With enough coding, I’m sure it would be possible–but not that sure on the practicality of doing it.

Hiding a field on a form is not that difficult. As long as the required data gets added to the database by some other means it doesn’t change the underlying foundation at all.

It is not a WPMU issue. I don’t want to change the underlying foundation. I want to use Buddypress’ fullname field to generate that username.

The WPMU forum will just send me back here and rightly so.