Skip to:
Content
Pages
Categories
Search
Top
Bottom

Search Results for 'buddypress'

Viewing 25 results - 1 through 25 (of 69,016 total)
  • Author
    Search Results
  • #339358
    John N
    Participant

    As I mentioned, I’m not entirely sure when the issue first appeared. I’m the one associating it with the growing number of terms, but I don’t actually have anything concrete to support that assumption.

    It could just as well be related to the changes I made to the server setup — switching from Apache MPM Prefork with PHP 8.3 to Apache MPM Worker with PHP 8.3-FPM. BuddyPress hasn’t been updated in quite a while, and rolling back one version did not resolve the issue.

    So at this point, I’m not sure what is actually causing it. The error in the AJAX response makes me wonder if BuddyPress might behave differently under PHP-FPM compared to the previous setup, rather than this being a change within BuddyPress itself.

    Now I just need to try to get some help with the remaining debugging. I use screen reader software and therefore cannot work with the browser developer tools. I’m hoping to get some assistance with that shortly.

    #339350

    In reply to: Missing Pages

    emaralive
    Moderator

    Yeah, unfortunately, the “very large arrow” was a result due a change with the WordPress 6.9 branch. This was previously reported in the Support forum topic -> Can’t register new users .

    Subsequently, Trac ticket #9324 was opened and resolves the issue, however, the ticket won’t be incorporated until the next BuddyPress release.

    If you read through the indicated Support forum topic (specifically, here) there were some potential “workarounds” provided, prior to opening the Trac ticket. I suppose, since there is a patch that contains the CSS rules, those rules could be used as yet, another workaround until the next release.

    #339331

    In reply to: Missing Pages

    emaralive
    Moderator

    Don’t deactivate BuddyPress because BP Classic requires that BuddyPress is activated. So, for you, just install and activate BP Classic.

    #339329

    In reply to: Missing Pages

    emaralive
    Moderator

    If your current version of BuddyPress is greater than or equal to 12.0.0, you will need to install and activate the BP Classic plugin/add-on to restore pages.

    #339309
    John N
    Participant

    Hi again,

    Since I’m not finding anything in any logs or debug logs, I’ve reached the limit of what I can figure out with my current level of knowledge. It would be greatly appreciated if a BuddyPress developer could take a closer look at this issue and hopefully help identify a solution.

    I’m speculating here, but creating and deleting terms in wp-admin used to work without any problems. The issue appeared at some point, and the only thing I can think of is that it might be related to the growing number of terms in one of our custom taxonomies. It seems like something in BuddyPress hooks into term creation or deletion and causes this behavior.

    When creating a term:

    * No error message is shown
    * However, the term list does not refresh (possibly an AJAX issue)

    When deleting a term:

    * An error message is shown
    * The term is actually deleted in the background
    * But again, the list does not refresh automatically

    I’m not sure, but perhaps our setup is somewhat unusual. We use a relatively large number of terms in a custom taxonomy so that our authors can organize their texts into series. However, it doesn’t seem like deleting a term should be more resource-intensive than deleting posts or comments, of which we have many thousands without issues.

    I am a bit concerned that more problems could appear as the number of terms continues to grow.

    Additionally, we are using BuddyPress Moderation Tools from BuddyDev. This has also recently started behaving strangely — for example, it is no longer able to create reports when a user flags content. This used to work before. I don’t know enough to say for sure, but it doesn’t seem impossible that these issues could be related.

    We have, of course, tested creating and deleting terms with all plugins deactivated (including BuddyDev plugins), and this issue only occurs when BuddyPress itself is active.

    I would be extremely grateful for any help or guidance.

    Thank you!

    emaralive
    Moderator

    This has been fixed in ticket #9309. Specifically, Changeset 14146 resolves the issue for the 14.0 branch and changeset 14145 for trunk.

    The general public will just have to wait until the next release for the changes slated for the 14.0 branch to go into effect.

    #339298
    John N
    Participant

    Thanks for your suggestion.

    I have enabled debug logging, but I’m not seeing anything that seems related to this issue, neither in wp-admin nor in the debug.log.

    The only thing that appears is the following deprecated notice:

    [27-Apr-2026 16:56:19 UTC] PHP Deprecated: The function bp_core_get_user_domain is deprecated since version 12.0.0! Use bp_members_get_user_url() instead. in /wp-includes/functions.php on line 6131

    I have looked through the code in my plugins, and it seems that a few BuddyDev plugins are making this call, including BuddyPress Moderation Tools and BuddyDev Poke, so it doesn’t appear to be directly related to the issue and if I deactivating these plugins the problem still is the same.

    I haven’t been able to find anything else. I should also mention that I’m very much a hobbyist, so my knowledge in this area is quite basic.

    #339297
    fatiima
    Participant

    “Looks like an AJAX response issue—BuddyPress might be outputting unexpected data during term operations, especially with larger taxonomies. You could try checking for hooked actions on term deletion/creation and enable WP_DEBUG_DISPLAY to catch any hidden output affecting JSON responses.”

    #339295
    John N
    Participant

    Hi,

    I’ve run into an issue that appears to be caused by BuddyPress when deleting terms (categories, tags, and custom taxonomies) in WordPress admin.

    When I delete a term in wp-admin (for example a category or a custom taxonomy term), I get the following error message:

    “An error occurred while processing your request. Please try again later.”

    However, after reloading the page, the term is actually deleted successfully.

    – Deleting posts and comments works without any issues
    – The problem affects:
    – Categories (category)
    – Tags (post_tag)
    – Custom taxonomies (e.g. from PublishPress Series)
    – No errors are logged in:
    – wp-content/debug.log
    – Apache error log

    When deleting the same term using WP-CLI, everything works perfectly:

    bash wp term delete category <term_id>

    – No errors
    – Term is deleted correctly

    I disabled all plugins and then re-enabled them one by one. The issue only occurs when BuddyPress is active. With BuddyPress deactivated, term deletion works normally in wp-admin (no error message)

    In our system we use PublishPress Series, which registers a custom taxonomy called series. We have currently ~440 terms in this taxonomy
    – The number is continuously growing
    – The issue started appearing when the number of terms became relatively large

    This might indicate a scaling issue or something triggered by higher term counts.

    – The term is deleted successfully via wp_delete_term
    – Something in BuddyPress interferes with the response afterward
    – Possibly an issue with AJAX response (invalid JSON, unexpected output, etc.)

    Has anyone seen this behavior before?

    Is there anything in BuddyPress that hooks into term deletion (e.g. activity, notifications, or other components) that could break the admin AJAX response without triggering a PHP error?

    Could this be related to the number of terms in a taxonomy?

    We have also a similar problem when creating terms. No error messages in wp-admin but when clicking create it doesn’t look like that the term has been created. But when reloading the page the term is there.

    Any pointers on where in BuddyPress this might happen would be greatly appreciated.

    – WordPress: latest version
    – BuddyPress: latest version
    – PHP: 8.3 (PHP-FPM)

    Thanks!

    emaralive
    Moderator

    The Topic Owner created a Trac ticket with the same info that was posted in this thread. See Trac ticket #9333 for future info/dispostion.

    after i installed the buddypress plugin in my local server, i get an error message at the user page. although currently i have solved it, but it needed to be fixed in the original code.

    here is the error-

    
    Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-list-table.php:661 
    
    Stack trace: 
    #0 C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-users-list-table.php(629): WP_List_Table->row_actions(NULL) 
    #1 C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-users-list-table.php(415): WP_Users_List_Table->single_row(Object(WP_User), '', '', NULL) 
    #2 C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-list-table.php(1711): WP_Users_List_Table->display_rows() 
    #3 C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-list-table.php(1635): WP_List_Table->display_rows_or_placeholder() 
    #4 C:\xampp\htdocs\civilnotes\wp-admin\users.php(816): WP_List_Table->display() 
    #5 {main} thrown in C:\xampp\htdocs\civilnotes\wp-admin\includes\class-wp-list-table.php on line 661
    

    and here is my current solution-

    
    public function row_actions( $actions = array(), $user = null ) {
    
    	// Bail if no user ID.
    	if ( ! is_array( $actions ) ) {
    		$actions = array();
    	}
    
    	if ( empty( $user->ID ) ) {
    		return $actions;
    	}
    }
    

    please solve the issue, and let me know about the update.

    thank you..

    Antipole
    Participant

    I am still seeing this error when editing the extended profile.
    Now on:
    WP 6.9.4
    BP 2.6.4
    PHP version 8.3.30

    The following error now has trace back:

    Warning:  Attempt to read property "id" on null in /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-template.php on line 558
    
    Timestamp: 2026-04-20 17:13:41 UTC
    
    Stack Trace
    -----------
    1.  bp_get_the_profile_field_id('22')
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/ovni-oddments/ovni-oddments.php:213
    2.  ovni_remove_rich_text(false)
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:343
    3.  WP_Hook->apply_filters(false, Array(2))
        /home/<xxx>/public_html/ovni-owners/wp-includes/plugin.php:205
    4.  apply_filters('bp_xprofile_is_richtex...', false, 36)
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-functions.php:1217
    5.  bp_xprofile_is_richtext_enabled_for_field(36)
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-filters.php:138
    6.  xprofile_filter_kses('Welsh coast', BP_XProfile_ProfileData)
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-filters.php:225
    7.  xprofile_sanitize_data_value_before_save('Welsh coast', null, true, BP_XProfile_ProfileData)
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:341
    8.  WP_Hook->apply_filters('Welsh coast', Array(4))
        /home/<xxx>/public_html/ovni-owners/wp-includes/plugin.php:205
    9.  apply_filters('xprofile_data_value_be...', 'Welsh coast', null, true, BP_XProfile_ProfileData)
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-profiledata.php:222
    10. BP_XProfile_ProfileData->save()
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-functions.php:526
    11. xprofile_set_field_data(BP_XProfile_ProfileData, 441, 'Welsh coast', false)
        /home/kiivmr5gzlfz/public_html/ovni-owners/wp-content/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-user-admin.php:209
    12. BP_XProfile_User_Admin->user_admin_load('update', 441, Array(67), '/wp-admin/users.php?pa...')
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:341
    13. WP_Hook->apply_filters(null, Array(4))
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:365
    14. WP_Hook->do_action(Array(4))
        /home/<xxx>/public_html/ovni-owners/wp-includes/plugin.php:570
    15. do_action_ref_array('bp_members_admin_updat...', Array(4))
        /home/<xxx>/public_html/ovni-owners/wp-content/plugins/buddypress/bp-members/classes/class-bp-members-admin.php:1159
    16. BP_Members_Admin->user_admin_load('')
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:341
    17. WP_Hook->apply_filters('', Array(1))
        /home/<xxx>/public_html/ovni-owners/wp-includes/class-wp-hook.php:365
    18. WP_Hook->do_action(Array(1))
        /home/<xxx>/public_html/ovni-owners/wp-includes/plugin.php:522
    19. do_action('load-users_page_bp-pro...')
        /home/<xxx>/public_html/ovni-owners/wp-admin/admin.php:242
    20. require_once('/home/<xxx>/pub...')
        /home/<xxx>/public_html/ovni-owners/wp-admin/users.php:11
    
    Context
    -------
    URL            : /wp-admin/users.php?page=bp-profile-edit&user_id=441&wp_http_referer=%2Fwp-admin%2Fusers.php%3Fid%3D441&action=update
    Referer        : https://ovni-owners.org.uk/wp-admin/users.php?page=bp-profile-edit&user_id=441&wp_http_referer=%2Fwp-admin%2Fusers.php%3Fid%3D441
    HTTP Method    : POST
    HTTP Host      : ovni-owners.org.uk
    HTTP Status    : 200
    isSSL          : Yes
    Current Filter : load-users_page_bp-profile-edit, bp_members_admin_update_user, xprofile_data_value_before_save, bp_xprofile_is_richtext_enabled_for_field
    Execution Time : 3.062 s
    Memory Usage   : 131.99 MiB
    PHP SAPI       : litespeed
    arisudi
    Participant

    Attempt to read property “position” on array in
    /wp-content/plugins/buddypress/bp-templates/bp-nouveau/includes/functions.php on line 1456.
    Version php is 8.4.

    natledasted
    Participant

    Performance Challenges
    1. **Database Load** – BuddyPress stores all activity in a single table (wp_bp_activity). With thousands of posts, queries for the activity stream can become slow.
    2. **Query Complexity** – Filters like friends, groups, mentions, and favorites add multiple joins and WHERE conditions, increasing load time.
    3. **Caching** – By default, activity streams rely heavily on live database queries, causing slow page loads.

    Optimization Strategies

    1. Enable Object Caching
    * Use persistent caching with Redis or Memcached.
    * Caches frequent queries and reduces repeated DB calls.

    2. Use Activity Stream Paginatio

    * Limit activity items per page (e.g., 10–20 instead of 50+).
    * Avoid loading the entire stream at once.

    3.Offload Activity Data

    * Archive old activity items to another table.
    * Keep only recent activity in the main table.

    4. Database Indexing

    * Ensure indexes exist on user_id, component, type, and date_recorded columns.
    * Improves query speed for filtering and ordering.

    ### 5. **Use a Dedicated Plugin**

    * Plugins like **BuddyPress Activity Plus** or **BP Better Messages** sometimes optimize activity queries.
    * Some custom solutions cache or precompute user feeds.

    6. CDN & Lazy Loading

    * Serve images/media via CDN.
    * Lazy load avatars and embedded media in the stream.

    @johnackerman

    #339225
    emaralive
    Moderator

    Navigation menu items are associated with their respective “active component”, that is, what would be considered “main menu” items. Read through the following document to see if it may shed some insight as to what you should do:

    Navigation menus

    #339224
    Yvan Morel
    Participant

    Hello,
    I’m using WordPress 6.9.
    I installed BuddyPress 14.40 on my site: https://subjectif.eu.
    I would like it to appear in my site’s main menu. The intended page, Messaging ( https://subjectif.eu/messagerie ), only displays that name!
    I would like this page to display BuddyPress with its menu.
    What do I need to do?
    Thank you.

    #339219
    werny
    Participant

    I need a strong age verification for my buddypress page.
    Users under 18 must NOT be able to register for the site.
    there are a few age-check-plugs out there, but the only ask to enter a birth-day, witch is not really save. Everyone can enter some data and can enter then.

    Any help?

    smelendez
    Participant

    Hi everyone,

    I am using BuddyPress groups and I would like to know if it is possible to mention all members of a group in a single group activity update.

    BuddyPress allows mentioning individual users using @username, which works well. However, I am looking for something similar to: @everyone or @all

    The idea would be that when a group admin posts an activity in the Home Tab of the group with something like @everyone, all members of that group would receive a mention notification or email.

    My questions are:

    Is there any built-in feature in BuddyPress to mention all group members or an addon that adds this functionality?

    If not, what would be the best way to implement it?

    Any guidance or suggestions would be greatly appreciated.

    Thank you all in advance!

    WP version: 6.9.4
    BP version: 14.4.0

    #339184
    Steve
    Participant

    Hi Thinlizzie,

    Thank you for checking out my site.

    I’m using Learndash to provide the registration, I’ve now discovered that BuddyPress displays it’s registration page right after the Learndash registration page is displayed.

    I’ve disabled BuddyPress now and all works fine.

    I was planning to use BuddyPress with BBPress but have now decided to use a WPForo forum as I don’t think I need BuddyPress at the current time, a Q&A forum should suffice.

    Many thanks once again for attempting to create an account.

    Best Regards,

    Steve

    emaralive
    Moderator

    The slug you provided corresponds to the Simple CAPTCHA Alternative with Cloudflare Turnstile plugin.

    The simplest solution is to force BuddyPress to use the standard WordPress login form, this can be accomplished by utilizing the bp_view_no_access_redirect_to_login_screen filter hook with a callback that returns a value of true. A one-liner approach is as follows:

    
    add_filter( 'bp_view_no_access_redirect_to_login_screen', '__return_true' );
    
    emaralive
    Moderator

    You will have to provide more information. BuddyPress doesn’t have an announcement page, are you using a plugin that generates this page and if so, what plugin?, I’m not sure if this is something special or a normal group activity item.

    As to your reference to “BB Forum”, do you mean bbPress or some other plugin and if the latter, what plugin?

    Mirax
    Participant

    Wordpress plugin : simple-cloudflare-turnstile

    I should point out that in the settings for this plugin, the “BuddyPress Register” checkbox is checked. The captcha is also visible on all of my forms (contact, WordPress login, etc.).

    I am looking for a way to add the captcha specifically to the “Members-only area” page.

    #339115
    emaralive
    Moderator

    Thanks for the link and I’m not going to speculate as to why that topic went unanswered. The short of the story is that BuddyPress requires “JavaScript” (JS) to fully function properly, especially when utilizing the BP Nouveau template pack (relies on AJAX – Asynchronous JavaScript and XML). Thus, given the scenario of the short story, it doesn’t make sense to have JS disabled.

    #339114
    lowercase99
    Participant

    Thanks very much for your reply @emaralive. Yes, “subscribe/unsubscribe” functions should work when BuddyPress is activated or deactivated, however in my case they do not. I am using WP (v6.9.1), Highend theme (v1.0.2), bbPress (v2.6.14) and BuddyPress (v14.4.0). The “subscribe/unsubscribe” function does not work with this combination (even with other plugins deactivated). Deactivating BuddyPress allows “Subscribe/Unsubscribe” to work. Changing the theme to Twenty-Twenty Eleven (as you note) allows “Subscribe/Unsubscribe” to work. I’ll attempt to dig into this a little further on other forums. A message that appears similar to my inquiry is https://buddypress.org/support/topic/bbpress-subscribe-button-breaks-when-buddypress-enabled-js-disabled-2/

    #339113
    emaralive
    Moderator

    As far as I can tell, “subscribe/unsubscribe” functions as expected when BuddyPress is activated or deactivated, thus I’m not able to duplicate your claim. Additionally, this was tested in the following environment:

    WordPress: 6.9.1
    BuddyPress: 14.4.0 – activated & deactivated
    bbPress: 2.6.14 – activated
    theme: Twenty Eleven

    No other plugins were activated other than what is indicated above.

    FWIW – engagements.js is responsible for the functioning of the subscription process for bbPress. It could be that this script is not being enqueued due to some other undisclosed factor or, if enqueued, a javascript error caused by a conflict with a theme or other plugin, however, this is just speculation since I am not able, at this time, to duplicate the issue you have described.

    As to:

    I have seen other messages on this topic dating back a number of years but no clear answer

    I’m not aware of such topics within the BuddyPress support forums, could you provide a specific topic with this claim?

Viewing 25 results - 1 through 25 (of 69,016 total)
Skip to toolbar