Forum Replies Created
-
In reply to: how to shorten Buddypress activation key
Multisite uses the signups table to hold user accounts that have registered but not activated their accounts yet. BuddyPress, of course, does this same thing by default, so it makes sense for us to use this same table.
In reply to: how to shorten Buddypress activation keyI think you’ll need to change it in both places. I have no idea why we store it twice, but I’m blaming @imath since he introduced the signups table. 🙂
In reply to: Members are not showing up. HELP PLEASE!!Have these extra people: 1) activated their account, and 2) actually logged-in to the site at least once?
In reply to: how to shorten Buddypress activation keyAh, interesting idea.
When you alter the activation key in the database, where exactly are you changing it? User meta?
wp_signupstable? Both? (It depends if you are using multisite or not).(I assume you are using functions to change the values rather than direct SQL — if you’re doing the latter, you’ll need to clear some caches).
Haven’t seen this before. Is there anything in your PHP error logs? Your host may be able to help you get this data.
In reply to: Facin gissue with registration.This is going to sound odd but is there a difference between visiting
http://drummershirts.net/community/registerandhttp://drummershirts.net/community/register/?The former is 301 redirecting to the latter, so it would be interesting to see if the browser is weirdly getting confused with the redirect.
In reply to: Comments think it’s 2006It’s worth getting in contact and asking with your host about the time/date and timezone. It’s unlikely to be so badly wrong, but I’ve seen this cause similiar problems before.
In reply to: Default Profile VisibilityThat screen isn’t provided by BuddyPress. It’s something provided by another plugin, or perhaps within the theme. Can you identify which one?
In reply to: Comments think it’s 2006Check the time/date on your server — is it correct?
Also, check what timezone PHP is configured with in its php.ini config file.
In reply to: recover cover imageWhat is
$imgUrlParts?In reply to: Avatar URLJust use WordPress’ get_avatar() function: https://codex.wordpress.org/Function_Reference/get_avatar
In reply to: EmailsThis sounds like an email sent by the paidmembershipspro plugin, which BuddyPress has no control over. Have you contacted that plugin’s developers for support? Or posted on its WordPress.org support forums?
In reply to: Activities aren’t Custom Post Types?Is there a way to make activities register as a custom post type? If that’s not possible, is there a quick fix to make a plugin reference activities instead of posts?
Activities are not custom posts, nor are there any options in BuddyPress to let them do this. Either of these things would have to be custom development, and are probably harder than they may initially seem.
In reply to: DB collation: utf8mb4_general_ciI created a bug report: https://buddypress.trac.wordpress.org/ticket/7117
In reply to: DB collation: utf8mb4_general_ciIt’s an oversight on our part, dating back to the end of December 2012. Good spot noticing it. We’ll get it addressed, but it won’t be included in a release until BuddyPress 2.8 (end of year) — bad timing with that regard, unfortunately. 🙁
In reply to: DB collation: utf8mb4_general_ciThis is a good question.
In reply to: WP User Avatar Not Showing in BuddyPressThat isn’t accurate, or fair. For starters, WordPress does not provide a user avatar UPLOAD option inside its user profiles in wp-admin. It’ll show the Gravatar image associated with the current user’s email address (“You can change your profile picture on Gravatar.”).
If your WordPress lets you upload a picture there with BuddyPress disabled, then you have some custom code somewhere that’s offering that feature. I am willing to bet that that plugin doesn’t have a correct implementation, otherwise BuddyPress should be working with it.
In reply to: BuddyPress Emails Default TextIt’s not really a Mailgun support problem. It’s just that BuddyPress requires a different email interface to what WordPress needs. I hope in time people will build these for BuddyPress, but for now, you’ll need a developer to build it out for you.
If you know PHP and the basics of how to build with WordPress, I can give you hints.
In reply to: BuddyPress Emails Default TextUse the Repair Tools under wp-admin Tools > BuddyPress. There’s one to reinstall emails.
Emails not sending in HTML means you probably have some plugin active that redeclares the
wp_mailfunction — this doesn’t make sense to non-developers, I admit, but if you have any plugins that do things with emails for WordPress, that’s the likely candidate.In reply to: Recommend caching plugin for BPSure does. But if you had 100 pictures on one page, that’d be the biggest cause of slowness for that particular page.
Use Chrome dev tools (the “Network” tab) to sample a few pages (home page, user profile, directory) and look at the size and see what’s happening.
In reply to: Replicate data to another databaseAs both sites are WordPress, you can, for example, share the
wp_userstable between separate WordPress installations, but all the BuddyPress profile data is stored in custom BuddyPress tables. The non-BuddyPress site will have no idea where or how to get the profile data from the BuddyPress-powered site.You could, for example, copy the database tables across each night to keep the non-BuddyPress site updated, but you’ll still end up running BuddyPress on the main site in order to have access to APIs to query/fetch/display that data. Again, you could write custom SQL to achieve this, but you’re digging yourself into a large hole.
I agree with the previous advice given 🙂
BuddyPress doesn’t support conditional profile fields (yet?). This is asked frequently but I can’t remember if anyone’s built a plugin that handles this. You might have to hack something together bespoke for your theme.
Regarding the second point, I’d recommend creating a custom field type, if you know PHP. It’s not too hard to do — I worked on this code a year or two ago, and it’s pretty easy to do now. You could look at https://en-gb.wordpress.org/plugins/buddypress-xprofile-custom-fields-type/ for examples of how to add and register custom field types — specifically https://plugins.svn.wordpress.org/buddypress-xprofile-custom-fields-type/trunk/classes/Bxcft_Field_Type_SelectCustomPostType.php I think is a good example to work from as it displays custom post types in a list (you’d just query your custom table and pull in the values, wrap it in some caching, etc).
You’re correct. The relevant function is messages_new_message(): https://buddypress.trac.wordpress.org/browser/trunk/src/bp-messages/bp-messages-functions.php#L130
You can set the
BP_ENABLE_USERNAME_COMPATIBILITY_MODEconstant to get BuddyPress to accept user_login values on the message compose screen rather than the user_nicename. See https://codex.buddypress.org/getting-started/customizing/changing-internal-configuration-settings/ for how to set it, basically you add it to wp-config.php.BUT setting this will also change the member URLs. For example: example.com/members/user-nicename/ will become example.com/members/user-login/. If you choose to change this, at the very least, you will have to set up redirects manually so as to not harm SEO.
I think probably changing your modification to use the user_nicename will be best.
In reply to: Recommend caching plugin for BPI can’t speak for all the BuddyPress development team but, personally, I would not recommend W3TC. There is a specific bug with its Object Caching implementation that breaks password resets on BuddyPress for some obscure reason we weren’t able to track down.
You need an Object Cache plugin, which will be backed by a Memcached or Redis instance, or something. If you’re using a great WordPress host rather than any old common host, like WP Engine or Pantheon or Siteground, they already have this infrastructure in place.
You could have a full-page cache, but be sure to only configure it to cache requests for logged-out users. You can imagine that if the majority of your traffic is from logged in, then having a cache for logged-out views isn’t going to have much impact.
In reply to: Theme suggestionMy favourites are at buddyboss; they look great and are coded really well – http://www.buddyboss.com/themes/
