Search Results for 'buddypress'
-
Search Results
-
Hi @glenphillips33,
My apologies for a belated response but, my default browser is Chromium (just a preference thing) on a Linux platform and all looks as expected. Although, Chromium, Google Chrome, Microsoft Edge, and others share the same basic engine, there may be differences in builds across the various OS platforms. Without knowing more information, it is difficult to assess the issue. For example, we currently don’t know, at a minimum, which may or may not prove to make a difference:
- WordPress version
- BuddyPress version
- PHP version
- BuddyPress template pack in use
- If you have tried using a WordPress default classic theme (non block theme or non FSE)
The layout appears broken, with profile sections overlapping or not displaying at all.
This is a generalization, meaning there isn’t enough specificity to truly understand the situation. Perhaps, a screenshot would suffice without having to visit your site.
Here is my setup as it relates to the following screenshot of an arbitrary Profile page with Google Chrome:
- WordPress: 6.7.1
- Active Theme: twentyeleven child theme (twentyeleven-child)
- PHP: 8.2.25
- OS: AlmaLinux 9.5 (Teal Serval)
- Browser: Google Chrome – 131.0.6778.85 (Official Build) (64-bit)
- Page caching: No
- Object caching: No
- BuddyPress: 14.3.3
- BuddyPress URL Parser: BP Rewrites API
- BuddyPress Active template pack: BP Nouveau
For me, the profile area renders as expected with Goggle Chrome based on the given setup. I also looked at the same page with Windows 10 and Google Chrome (131.0.6778.86 (Official Build) (64-bit), logged-in and logged-out and it looks the same. I don’t have a Mac, so I can’t provide a verification. Also, I’m serving up the profile page from a development site on my LAN.
Hi,
The BuddyPress xprofiles website field turns https urls into http, which does cause browsers to show a security warning when these urls are clicked on in a member’s profile. I could not find an answer to that issue.
Thanks for your help,
Philippe
Hi,
I am using the “BuddyPress Messaging Control” plugin (available here) and ran into some bugs with it. The creator has not responded so I thought I should ask here.Issue 1:
This plugin is used to restrict who (based on user roles) can send how many messages to whom and within what time period, eg free user roles can send 10 messages a week or only reply to messages sent to them, but paid users can send unlimited messages to anyone).When I tested this plugin with the latest Buddypress and WordPress version and BuddyX theme, when you go to send a message, and your account is restricted, there is a message that says “Your messaging is capped, you can send a further”. and “Your messaging is set to Reply Only, you can only message users who have previously sent you a message, in addition you are only able to send another”. It doesn’t show the quota, and I would like for it to show it, because this just looks silly.
Issue 2 and 3:
In the Buddyboss platform (Buddyboss says anything made for Buddypress is compatible with Buddyboss, but it doesn’t actually seem so) the messages can be sent by simply pressing enter, there is even a message that says “Enter to Send Shift+Enter to add a new line”. But, pressing the “enter” key doesn’t visibly do anything, ie the message that you typed still stays in the text box, it doesn’t move to the sent messages box, so it is not obvious that a message was sent. Then the user will repeatedly press “enter” until they run out of their alloted messages. Then a message appears that says “There was a problem sending your message.”The first of this issue is obviously the message not “sending” upon pressing “enter”.
The second of this issue is that the message itself is vague and not specific: It should say “You have used up your message quota for this period.”I am wondering if anyone can help with fixing these things.
Thank you in advance.Hi BuddyPress Community,
I’m having an issue with my website where BuddyPress profile pages aren’t rendering correctly when viewed in the Chrome browser. Here are the details:
The layout appears broken, with profile sections overlapping or not displaying at all.
The issue seems to occur only in Chrome (tested on both Windows and macOS), while other browsers like Firefox and Edge render the pages just fine.
Clearing the browser cache and disabling extensions in Chrome doesn’t resolve the issue.
What I’ve Tried:
Checked the BuddyPress templates in my theme and confirmed there are no customizations causing conflicts.
Switched to a default WordPress theme (Twenty Twenty-Three), and the issue persists.
Tested the website in incognito mode on Chrome, but the problem still occurs.
Verified there are no JavaScript errors in the browser console.
Could this be related to Chrome’s rendering engine or a specific CSS/JS compatibility issue with BuddyPress? Are there any settings in BuddyPress or Chrome I should check to fix this? Should I share with you the URL of the site so that you can check if this issue is happening on your end or not?
Any guidance would be greatly appreciated!Hello BuddyPress team,
I’m using the BuddyPress plugin version 14.3.1 alongside WordPress 6.6.2 and have been encountering deprecated class error messages in my site logs. These messages point to line 6085 of the file wp-includes/functions.php and indicate the use of outdated classes like BP_REST_Activity_Endpoint and BP_REST_Members_Endpoint. The notices suggest replacing them with BP_Activity_REST_Controller and BP_Members_REST_Controller, respectively, as they’ve been deprecated since version 15.0.0.
Here are some examples of the error messages:
PHP Deprecated: The BP_REST_Activity_Endpoint class is deprecated since version 15.0.0! Use BP_Activity_REST_Controller instead. in /wp-includes/functions.php on line 6085
PHP Deprecated: The BP_REST_Members_Endpoint class is deprecated since version 15.0.0! Use BP_Members_REST_Controller instead. in /wp-includes/functions.php on line 6085
I’ve attempted troubleshooting by switching to the default WordPress theme and disabling non-essential plugins (including BP Classic), but the errors persist. Using the Query Monitor plugin, the deprecated notices seem to be directly linked to BuddyPress.Could you confirm if this behavior is expected? Is there a patch or a recommended solution to address this issue, as I’m already running the latest version of the plugin?
Thank you for your assistance, and I look forward to your guidance.
Best regards,
Rafael João Ribeiro
fisicagames.com.brHello guys!
I’ve seen this question in here a couple of times and maybe others would enjoy this code.
I couldn’t find a good solution in trying to “hide” the official and hidden groups, when users are creating them (it just would not allow me to hide them!).I then managed to fix a code and make it work so at least it shows an error when a user (besides admin) tries to create a group that is NOT private. In this way when a user tries to create a public/hidden group it will not allow the user to “proceed” with the next step unless private group is chosen.
Feel free to update the CSS to your liking!
Hope it helps, enjoy! 🙂
function restrict_group_type_selection() { // Ensure this script only runs during the group settings creation step if (bp_is_group_creation_step('group-settings')) { // Check if the user is not an admin (wrap the condition outside the script for cleaner HTML output) if (!current_user_can('manage_options')) { ?> <style type="text/css"> .group-type-error-message { color: #ffffff; background-color: #f95959; position: relative; margin-top: 20px !important; border: 0 !important; font-weight: 600; } } </style> <script type="text/javascript"> document.addEventListener('DOMContentLoaded', function () { const nextButton = document.getElementById('group-creation-next'); // Target the "Next step" button if (nextButton) { nextButton.addEventListener('click', function (event) { const selectedGroupType = document.querySelector('input[name="group-status"]:checked'); let errorContainer = document.getElementById('group-type-error-message'); // Remove any existing error message if (errorContainer) { errorContainer.remove(); } if (!selectedGroupType || selectedGroupType.value !== 'private') { // Prevent moving to the next step if the group type is not 'private' event.preventDefault(); // Create and display a styled error message errorContainer = document.createElement('div'); errorContainer.id = 'group-type-error-message'; errorContainer.className = 'group-type-error-message'; errorContainer.innerText = 'You are only allowed to create private groups.'; // Insert the error message after the "Next" button nextButton.parentNode.appendChild(errorContainer); } }); } }); </script> <?php } } } add_action('bp_after_group_settings_creation_step', 'restrict_group_type_selection');On my BuddyPress Members Directory Card, I want to disable the Cover Image, while the Cover Image should appear on the Member’s Single Page.
I used this Snippet:
// For members : add_filter( 'bp_is_profile_cover_image_active', '__return_false' );Which I got from here:
BuddyPress 2.4.0 will introduce Cover Images for members & groups!
But it didn’t work.
Anyone know how I can effectively disable the Cover Photo from the Members Directory Card?
Regards.
For context, I am not a developer.
I created a child theme manually for BuddyX and the child theme works. However, the child theme does not have one of those preview picture that shows what the theme looks like in the Appearances -> Themes page and I wanted to add one.
Version details: BuddyX Version: 4.7.5 with Buddypress Version 14.2.1 and WordPress Version 6.7.1.
I know that in the buddyx folder in the hosting back end (wp-content -> themes -> buddyx), there is an image file called “screenshot.png”. This is a PNG file and it is what the original theme preview picture is. So I assumed that if I add an image file to my buddyx-child folder, it will also be the preview picture.
To test this, first I copied that original “screenshot.png” to the child theme folder and purged the cache in my wordpress dashboard and sure enough, it became the preview picture of the child theme.
Now that I know it works, I downloaded this file, deleted it from the child theme folder, and edited it by opening it in a image editor and adding the word “CHILD” in large letters across the picture, saved it first as “screenshot.jpg” then also “screenshot.png”, with the intention of using that so I can tell the child theme and the parent theme apart visually. When I uploaded either of them (the new jpg and the png, one at a time and deleting the one I don’t need from the folder) the picture nonetheless showed the orignal “screenshot.png” without the word “CHILD” on it.
As an experiment, I then uploaded a random jpg and renamed it in my hosting back end, to “screenshot.jpg” without changing the extension. When I purged the cache in my wordpress dashboard, the preview picture for the child theme showed this new jpg instead of the old original “screenshot.png”. (Nothing shows if you don’t rename the file to “screenshot”, it must be “screenshot”). So it seems the image can be jpg or png as long as it is called “screenshot”.
So then I deleted this random jpg, and I tried to upload the new “screenshot.png” with the word “CHILD” on it again, but the same thing happened. This is really strange since I deleted the original “screenshot.png” and cleared my cache but it still seems to remember what it was before.
What is even stranger is that when I upload ANY jpg file then rename it to “screenshot” and keep the extension as “jpg”, the picture that shows as the preview picture in my wordpress dashboard is the random jpg I uploaded earlier. This happens no matter what jpg file I upload.
Stranger still: If I upload a jpg file and change the name to “screenshot” as well as change the extension to “.png”, then the image that shows as the preview picture is the original “screenshot.png” from the parent theme. Same if I upload any PNG file.
Anyone have any ideas?
Hi all
I have disabled the activity function for my buddypress site, so usually, there is no mention of this feature on the site.However, when a person uploads media to a gallery, they see the message “You have 1 video not published to actvity.” (or some other media type). Underneath this is a dropdown menu that has “bulk action” as one of the options, then an “apply” button. This makes it look like you can bulk publish a bunch of media to the activity page, but I’ve disabled this completely, so it looks both confusing and unprofessional.
Is there a way to get rid of this message?
Hi… since updating to PHP8.3 I am seeing the warning
Warning: Attempt to read property "id" on null in /home/[...]/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-template.php on line 558Any idea what’s up, please?
WP 6.7
BP 14.2.1
PHP 8.3Hi,
[21-Nov-2024 07:34:39 UTC] PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the
buddypressdomain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at theinitaction or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /wp-includes/functions.php on line 6114Can you please fix this problem?
Thank youHi @miednr,
I’m not sure why you are having difficulties with a BuddyPress installation on a multisite whereby blog posts are not showing up in the Activity stream when configured to do such.
At the moment, I’m not able to duplicate your situation because blog posts are showing up in my Activity stream in a multisite installation. As can be seen in the following screenshot:
Since blog posts work for me and not for you, we need to figure out the difference(s) in our installations and what I have as the basics are (running on a LAN):
- WordPress 6.7 – multisite with subdirectories
- BuddyPress 14.2.1 – network activated on secondary site
- All BuddyPress components activated
- Default BuddyPress options plus “Post Comments” enabled
- TwentyEleven theme used on secondary site
- Pretty permalinks used on secondary site
Additionally, the installation guide I used is “Case 2” from the following document:
BuddyPress Activation Guide for WordPress Multisite
Maybe if we start on some common ground, we should eventually figure out what may be going astray with your installation, well at least that would be the theory.
