BuddyPress.org

@fifthhouse when I suggested data be added against the event’s meta I didn’t mean the host or facilitator do it manually. WordPress and BuddyPress have a pretty extensive action system which you can hook to. The code will run automatically when the action happens.

Here’s the Plugin API documentation in case you need it:

https://codex.wordpress.org/Plugin_API

Hey, you managed to put up a very beautiful website! Congratulations!

Have you tried Siteground? They do have PHP7. I’m running their shared hosting plan, and after some issues with their terms about number of processes, executions and time, I faced the beast and started to get my hands dirty, removing all plugins, templates, messing with the configuration, putting a default wp template (twenty seventeen), creating my own child theme and messing with functions.php first and then modifying css and php files myself. I have never been a wordpress developer… Not even a php programmer… Just started messing with it on my own, for necessity (and, after a little time, for fun)… Now, I have a website with almost zero plugins (only the essentials), running on php7, http2 and moving in the speed of light, with the lowest server consumption ever…

My advice: dont be afraid of getting your hands dirty.. the code is there, also the documentations, sites, forums, blogs and all kinds of resources 😀

Can Buddypress accomplish this? If so, would it be a complicated and labour intensive process to implement?

WordPress and BuddyPress should be able to handle this. The 2 levels of members you speak of could be either BuddyPress member types, or WordPress roles.

However, there is one tricky part. People need to be able to search for each event type, and also whether the event is hosted by either a “Facilitator,” or a “Host.”

This part is easy to solve. You would save either “facilitator” or “host” against the event’s meta when the event is created or updated. Then when you build your custom search, you can use the pre_get_posts hook to output matched posts, using both the search and meta query parameters in WP_Query.

Varnish is compatible with wordpress, but need custom conf, if you couldn’t manage the varnish configuration the best is no use it…

If the WordPress post is from your own site, you can disable the embed footer by adding the following to your theme’s functions.php:

remove_action( 'embed_footer', 'print_embed_sharing_dialog' );

If the WordPress post is not from your own site, you cannot control the footer output for that item.

Take a look at this article

https://codex.wordpress.org/Database_Description%23Multisite_Table_Overview

Hey,

The fix for that is coming in the next release of buddy press. Or at least for the part of the problem.

You most likely get 50% of your problem from these two in my case with 6k users these amounted to the respective query execution times (from new relic), I also run buddypress + rtmedia (which is the source of this problem) as described in this ticket:

bp_friends_prime_mentions_results() – Used by the Activity component’s @mentions to print a JSON list of the current user’s friends.

bp_friends_prime_mentions_results – 10,000+ ms
bp_core_fetch_avatar – 6,000+ ms

Here’s a fix:
https://buddypress.trac.wordpress.org/changeset/11561

You’ll still likely stay with this massive query even for logged out users:
WP_User_Query::query on average right now it’s at around 7,500ms.

Good news is that with HHVM site runs much faster due to object caching straight after enabling it.

I’ve also played around with various hosts, flywheel & wpengine sucked. What works well is Kinsta with HHVM enabled, they can also check your database and help you move to InnoDB if you’re using another one.

Anyway man hope this helps.

Best,

M.

It’s most likely a WordPress issue.

Go to the WordPress admin dashboard and create or edit a post and attempt to paste your Medium link there. If it also doesn’t work, then it’s a WordPress problem.

The problem is the Activity component only allows certain elements to be shown in the activity stream.

By default, <ol> and <li> are not among those whitelisted elements.

You can override this behavior with the following code snippet in your theme’s functions.php file or via wp-content/plugins/bp-custom.php:

// Allow list-item element through
add_filter( 'bp_activity_allowed_tags', function( $retval ) {
	$retval['ul'] = $retval['ol'] = $retval['li'] = array();
	return $retval;
} );

I’ve also opened a ticket about this here:
https://buddypress.trac.wordpress.org/ticket/7538

First, assuming you don’t mean real-time locations, members have to enter their location. For that you can use this plugin: BP xProfile Location.

Then you need to write a script that does a radial search for other members. Often this is done using zip codes. It can also be done with lat / lng.

Then you need to filter the feed to include only those members.

I’m not aware of any plugins that provide that package.
But if you are a developer, there are lots of resources for each step and you should be able to cobble something together.

Hey,

I’m experiencing a similar issue with 6k members, I can’t imagine the size of requests at 30k+…

It seems like mine was triggered by use of RTmedia, cause is described in this ticket, together with a patch:
https://buddypress.trac.wordpress.org/ticket/7530

If you’re using their plugin/s this could have been a cause.

Btw cool site 🙂 and congrats on the user count.