Forum Replies Created
-
This appears to be related to ticket #9302, primary navigation in site editor fails to allow creation of a group. The ticket was submitted by the OP for this topic and has more information regarding the steps to reproduce.
The URLs come from the WP Posts table in the database. In your db client, you can query/search the “post_type” field/column with a value of “buddypress” (without the quotes) and the results should be all the entries that are associated with URLs/Directories.
When reviewing the history for this BP Add-on, this appears to be a bug that was first reported in April of 2024 in the WordPress support forum for this plugin. However, it appears that the only action taken was the submission of a GitHub issue #112 that acknowledges the bug and this issue has remained open since that time.
Long story shorter, the fatal error is due to, what appears to be, missing parameters which is unforgiving with PHP version 8.0+. Rolling the PHP version back to 7.4.33 produces PHP errors as a warning and notice for the same file and line number. This bug appears to affect the posting of am image in an activity post; meaning the image is uploaded but does not get attached to the associated activity post. What does seem to work is uploading images from a user’s profile media area (where the image gallery is shown).
All I can suggest at this point is that you deactivate the plugin until a remedy can be found and a new version is released.
Most of the plugins you listed are in the WP Plugins directory. If you are utilizing the “Add Plugins” feature in the wp-admin area, you might want to try changing the criteria from “keyword” to “tag” (dropdown box to the right of the search box), e.g., with tag selected and then entering “google search” or “google custom search” (without the quotes) you will find:
- WP Google Search
- WordPress Google Search
- RDP Google Custom Search
- Server-Side Google Search
For the “Search with Google” plugin, you can use “cse” or “custom search engine” or “google+search”. There appears to be inconsistencies (which is expected) in the way plugin developers tag their plugins, e.g., some developers have used “google search” as a tag and another had used “google” and “search” as separate tags.
For the following items, there will either be URLs or Pages:
- Activate
- Activity
- Groups
- Members
- Register
The default when installing or upgrading to BuddyPress versions of 12 or greater is URLs. In order to change to Pages, the BP Classic add-on (plugin) should be installed and/or activated.
Most likely, the reason for the -2 for the Activity Directory slug in URLs is that there is a Page with the title of “Activity” and a slug with a name of “activity” which should be visible within the WP Pages area. The indicated items are WP posts that will either have a post type of “buddypress” (indicates URLs) or a post type of “page” (indicating Pages). Meaning they should all be of same post type, not a mixture of both nor duplicates,
Installing and/or activating the BP Classic add-on should revert all the previously indicated items to Pages and then you should be able to remove (trash) any duplicate Pages within the WP Pages area. You can the keep things as Pages or deactivate the BP Classic add-on to revert to the default of URLs.
Your question is more in line as a support question for the Buddyx theme folks. If you haven’t already tried their support forum for the Buddyx theme.
Furthermore, the first plugin you listed (WP Google Search) provides a search widget that you can add to any of the available widget areas provided by the Buddyx theme, the other plugins you listed may provide a widget as well. This approach might be easier than trying to add relevant code, e.g. a shortcode (if available) to a header file.
You should contact BuddyBoss for support.
Out of curiosity, what is your reason for removing the “unsubscribe” link?
The login page shown in the 1st screenshot is due to having the Community Visibility option set to “Members Only” (Private Community) within BuddyPress options. This option was introduced in version 12.0.0 and there appears to be some situations in which the default WordPress login page appears as opposed to the intended “Private Community” login page. Nevertheless, the “Private Community” login page can be disabled by utilizing the
bp_view_no_access_redirect_to_login_screenfilter hook and you will want your callback function to return a value oftrue. The following link is the line of code where the filter hook resides for v14.3.4:bp_view_no_access_redirect_to_login_screen
The registration page shown in the 2nd screenshot is actually the BuddyPress registration page. Why it looks different is because the Buddyx theme is utilizing CSS rules to alter/change the appearance. You should contact Wbcom Designs support regarding the restoration of the default appearance.
Yes, it is possible. However, you might want to rephrase your question because it infers that a user would only be able to leave comments on their own activity posts. Meaning, be more specific as to what should occur.
The snippet does what it is coded to do, therefore, either the snippet is not being invoked or there is something else (possibly a plugin, theme or other custom code) that is counteracting the snippet.
I’m not familiar with the “username only” plugin, is this plugin available via the WordPress plugins directory? I’m asking because this plugin or some other external factor (a different plugin or theme) might be disrupting the normal flow of events.
The snippet relies on the
bp_get_title_partsfilter hook which relies on thebp_modify_page_title()function to be invoked by thewp_titlefilter hook.You can try hooking the snippet to the
wp_titlefilter hook to see if that makes any difference, i.e., change:From:
add_filter( 'bp_get_title_parts', 'yz_change_buddypress_browser_tab_title', 999 );To:
add_filter( 'wp_title', 'yz_change_buddypress_browser_tab_title', 999 );From what I can tell, the snippet replaces the text portion of what BuddyPress would normally add to the meta “title” with the text “XXXX” (without the quotes). For example on a members profile view page (
site.url/members/username/profile):Display name of user: test
Website name: AppleWithout snippet:
Profile | test | AppleWith snippet:
XXXX | AppleThe snippet (copy & paste) was checked for use in the bp-custom.php file and the functions.php file of a child theme. Perhaps, you could elaborate a bit more as to the steps you took to implement the snippet and what you expected the result to be.
Apparently, this is the current behavior of the
bp_rewrites_get_url()function, i.e., the missing trailing slash, when the permalink structure is missing a trailing slash. Hence, a permalink of/%postname%/.htmlwill result in a URL with a missing trailing slash, e.g.:site.url/members/<user_name>This causes a 404 error when bbPress tries to concatenate the URLs for the following:
- Replies Created
- Engagements
- Favorites
- Subscriptions
What’s peculiar is that “Topics Started” isn’t affected because, for bbPress, all member area URLs (navigation links) are based on either the
bp_displayed_user_domain()or thebp_loggedin_user_domain()functions and both of these functions have thebp_rewrites_get_url()function in the chain for return.Regardless, this appears to be problematic due to some 3rd party themes and plugins that make use of various other BP functions that have
bp_rewrites_get_url()function in the chain for return.BuddyPress utilizes the WordPress login page by default. There are plugins that will alter or replace the standard WordPress login page.
This is been asked before in different topics with various solutions offered. There is one solution that may work for you, which is represented as a GitHub Gist:
Disable BuddyPress Signups feature
The Gist came from a reply that is located here.
Another solution is provided by the LoginPress plugin that has a coding example that is similar to the Gist code. The code is located near the bottom of this page.
Other than those examples, you can read through other conversations related to this topic that may be better fits for your situation.
For the sake of clarity, are you stating that you are setting your permalink structure to
/%postname%/.htmlas opposed to/%postname%/?When you create or edit a xprofile field that contains a metabox like the following:
If this metabox is present, then you can set the visibility parameters for a given xprofile field.
Can we consider this topic as being resolved?
I stated that the visibility for WordPress Fields are “currently” not user selectable. Why this decision was made was unknown to me, until recently, and appears to be along the same lines of why the “Requirements” metabox doesn’t appear for the WordPress Fields, as well.
Given this conversation, I looked for a possible reason that might uncover a decision to not include such capabilities and found that ticket #8487 (Add visibility and required controls to the WordPress profile fields) provides the history behind why the decision was made not to include the capabilities (visibility and requirements) and why these capabilities have yet to be incorporated (no one has provided a patch).
Currently, the visibility for the following xprofile fields aren’t “user” selectable:
- 1st Text Field – labeled as “Name” by default
- Single Fields – Checkbox Acceptance
- WordPress Fields – Biography
- WordPress Fields – Text Field (First Name, Last Name, Website)
In your example, “surname” as you have applied would be “WordPress Field – Text Field – Last Name” and as indicated the visibility is not “user” selectable.
As to the other xprofile fields the visibility can be set for either:
- Allow members to override – visibility is selectable by users
- Enforce field visibility – visibility is set per selection
Admin can set the visibility during creation or editing of xprofile fields that allow for “Visibility” settings, e.g., Single Fields – Text Box will have a “Visibility” metabox whereby an Admin can set the “Visibility” parameters. See BuddyPress xProfile fields administration for other information.
You should contact BuddyBoss for support.
Sounds good, take care.
Your second answer is a bit confusing, if you have the Activity component activated, then all you would have had to do was to enter @username (replace username with your actual username) in the Activity post form and the click “Post Update”, afterwards you could delete the post. The reason for doing this is to test whether or not BuddyPress (BP) is sending emails in general and your issue isn’t just isolated with the changing of email address.
Moving along, BP, by default, has a finite number of email templates with corresponding situations that will fire/send an email based on the situation: For example:
- 21 email templates for a single site installation
- 22 email templates for a multisite installation
You can verify the count of email templates by clicking the menu items “Emails > All Emails” within the wp-admin area. You should have a “Published” count number the is equal to or greater than what was previously indicated.
The email template that is responsible for sending the “email change notice” is:
[{{{site.name}}}] Verify your new email addressMake sure the template is present and the status is set to “Published”. Additionally, check that the situation assigned to this template is:
settings-verify-email-changeIf these conditions are true (template is present, published and the correct situation is assigned) then BP should be sending the “Verify your new email address” email”, given that you aren’t receiving errors that might be interrupting the sending process.
OK, sounds good and I’ll consider this topic resolved. FWIW, BuddyBoss is a fork of BuddyPress with obvious differences.
Take care.
