Forum Replies Created
-
@grimbot – When you swapped out the header.php file for the original, did it fix the AJAX problem you’ve described here? It’s likely that it’s unrelated, but worth checking.
> Perhaps something with the .httaccess files?
Unlikely – mods to the .htaccess file might prevent the call from going through in the first place. This AJAX call is successfully hitting the server, but it’s returning something incorrect.
Given that the item is showing up in the database/Dashboard, it’s highly likely that your theme is the culprit. As a test, try switching to the Twenty Fourteen theme to see if that makes the problem go away.
If you have the ability to search your codebase, either via SSH or as a local copy, you should search it to find the string from the screenshot. That’s how I’d start debugging.
$ grep -nR "why\-does\-width" wp-content/themes/staticcolonies_ctBuddyPress’s Register page is a special kind of page that cannot be edited via the Dashboard. That’s why it’s blank when you view it in the normal way.
To add additional fields to the registration process, go to Dashboard > Users > Profile Fields. Add one for Address and one for Phone Number. Make them required and/or private, if you’d like. As long as they are part of the ‘Base’ profile field group, they will appear as part of the registration process.
Can you share a screenshot? (Upload to https://postimg.org/ and share the URL to the screenshot.) Seeing how the fields are rendered may give a hint as to why this is happening.
It may also be worth switching to the Twenty Sixteen theme momentarily (or some other WP default theme) to see if it solves the problem. If so, you can narrow it down to your theme causing the problem. If that’s the case, please share details about your theme.
If you’re able, search your codebase for the string. It *must* be there somewhere. If you have SSH access:
$ grep -nR "Please upload your profile photo to start using this site" wp-content/pluginsRepeat for
mu-pluginsandthemes.When you add BuddyPress’s Register item to your nav menu, it will only show up for logged-out users. If you’d like it to show for *all* users, remove the BuddyPress item, and instead find Register under Pages and add it from there. https://i.imgur.com/Ny7Wj1L.png
My suggestion was to try another plugin. That’s a relatively low-risk proposal 🙂
For the record, I understand the frustration – piecing together many different plugins and tools, written by many different people, can sometimes have unpredictable results.
Very odd. It sounds like, when you initially installed BP (or activated the Groups component), it didn’t properly install the database tables. I have not seen that happen before, but I’m glad that toggling the component resolved it.
The email-change verification is meant as a security measure. If your BP credentials are stolen or lost, the only way you can get them back is with a Lost Password reset; the verification step means that an attacker can’t lock you out by changing your password and your password reset email.
On sites that I manage, users do occasionally lose access to their old email. In those cases, an administrator has to do a manual reset for them.
I’m unaware of an existing way to skip this step. If you want to dig into the BP internals, look for the string ‘pending_email_change’ – there may be a way you could automate the verification of an email change, if you see fit.
You could try using a different plugin for switching the login page. https://wordpress.org/plugins/search/login+page/ The one I’ve seen in use before is Theme My Login. Maybe it will work better with your setup.
Hi @thelovebridges –
BP doesn’t have any built-in tools for modifying the appearance of the page from the Dashboard.
This leaves you with two options:
1. Use custom CSS. You can probably accomplish much of what you want this way.
2. Override BP’s templates in your child theme. Only do this if you need to change markup.If you can give more of an idea of what you’re trying to accomplish, we may be able to give more specific advice.
This would take some custom coding. I don’t have any examples of how it could work for BP activity items. But I wrote something similar for bbPress replies a couple years ago, which might serve as an inspiration: https://github.com/boonebgorges/bbpress-reply-titles
That string is not present in BuddyPress itself. It must be coming from the plugin described here: https://buddydev.com/buddypress/force-buddypress-users-to-upload-profile-photo/
Be sure to check for
wp-content/plugins/bp-force-profile-photoin your filesystem, and the Plugins screen on both the Dashboard and the Network Admin (assuming you’re running Multisite).I’ve logged in and reproduced the error.
One of two things is happening here.
1. The item is being posted, but cannot be loaded for some reason. Check Dashboard > Activity to see if the item is listed there; if so, then it falls into this category.
2. The item is not being posted.
When I click ‘Read More’, I’m seeing something like this in the console: https://postimg.org/image/40weara5j/ This suggests to me that there’s some custom code on your server – maybe the theme, I’m unsure – that’s interfering with the AJAX call. Does this code look like something you wrote? If you switch back to Twenty Fourteen (instead of your child theme) does the problem persist?
I’ll close this one.
These tabs are hardcoded into the theme template. So you have two options:
1. Override the theme template in your own theme (copy
/wp-content/plugins/buddypress/bp-templates/bp-legacy/buddypress/activity/index.phpto/wp-content/themes/[your-theme]/buddypress/activity/index.php, open the copied template, and remove the tabs you don’t want.2. Hide with CSS. Eg
body.activity.directory #activity-friends { display: none; }No, it’s not possible for group moderators to do this. But site administrators can do it at Dashboard > Groups > Edit.
Hm. I have never seen a problem like this before. It sounds like the problem is not really with BuddyPress per se, but instead some sort of database corruption.
Are you able to run mysqlcheck? http://www.thegeekstuff.com/2011/12/mysqlcheck/ A total guess, but it could be that this will clear up some of the problems.
> text search not using ajax
This is what it should do. The original problem in this thread was that group members search didn’t work at all, because it wasn’t sending the contents of the search box. With AJAX disabled, at least the search should work.
If the users of the site don’t care too much about what it looks like, then I would suggest switching to a theme like Twenty Sixteen. This will move you over to a “template pack” that is more modern and well-supported by the BuddyPress team.
Otherwise, there’s no danger in sticking with the existing theme, as long as it’s working for you. It’s outdated in the sense that it won’t receive any more feature updates from the BP team, but if you’re not using most BP features, this probably won’t bother you or your users 🙂
> Now the problems I see is that when creating a new thread, the thread is created and shown but only the title, the content posted when creating the thread is hidden. All subsequent replies show just fine.
If this is a CSS issue, it’s easily fixed. Look at the page source to see if the content is there. If so, it is probably being hidden by a rogue style, which you could override. If not, it’s a deeper problem that may require some PHP skills to debug.
Oy, this is not a good piece of advice from the Avada support folks. You cannot put PHP into a text widget. I gave you a snippet of PHP with the understanding that it’d have to be added through code somehow.
If you haven’t got the resources to build a proper custom widget (no worries if not, it is a bit cumbersome to do), you may try a plugin like https://wordpress.org/plugins/php-code-widget/. You should be able to paste the text in question into one of those widgets and have it work.
Widget-friendly shortcodes for BP content is a good idea for a future enhancement. I’ve added a comment to an existing ticket we have to track a related idea. https://buddypress.trac.wordpress.org/ticket/7159#comment:2
The fact that both of these items are happening suggests that there might be a problem with folder permissions for WP uploads. Test to see whether it’s possible to upload an item through Dashboard > Media. If not, you may want to look through a resource like this https://codex.wordpress.org/Changing_File_Permissions to see whether anything has changed on your upload directories.
Very interesting question.
It’s not currently possible to do this through the regular activity API. We’ve hardcoded
ASCinto the comment query: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-activity/classes/class-bp-activity-activity.php?marks=1510#L1509I think that it would be a good enhancement request to add something to the query API that allows for these items to be reversed. If you’re interested, I encourage you to open a ticket at https://buddypress.trac.wordpress.org.
In the meantime, here’s a clunky workaround:
add_filter( 'bp_has_activities', function( $has ) { global $activities_template; foreach ( $activities_template->activities as &$a ) { $a->children = array_reverse( $a->children ); } return $has; } );This will only affect top-level comments; you’d need something recursive to do deeper levels. And you may want to limit this to front-end queries, or in the main activity directory, or something like that. But it’s a basic technique that should give you a sense of how to solve this in the short term.
Thanks for your patience as well 🙂
I’m unsure how to debug the AJAX issue further without full access to your installation. If you do manage to figure out what’s wrong there, please drop a note here with your findings.
In the meantime, you may be able to work around this whole thing by adding the
no-ajaxclass to theitem-list-tabselement containing the search. Obviously, this is not ideal, but at least it should fix the problem with the incomplete AJAX call.Thanks. I’ve just installed the combination of rename-wp-login and lh-private-buddypress, and I’m unable to reproduce the problem – after logging in, I’m being redirected to the originally-requested page. It may still be worth a test on your end; if temporarily disabling rename-wp-login fixes the problem, it would at least narrow down what’s going on.
If it were my site, the next thing I’d do is to debug the redirection chain, but I’m unsure how familiar/comfortable you are with debugging PHP functions. Try adding the following settings to your wp-config.php:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', true );After a few pageloads, WP should have created a file at wp-content/debug.log. Once you’ve confirmed this, drop the following into a bp-custom.php file, and then run through the login redirect process. It’ll dump some info into your debug.log file, which we can use for further debugging.
add_filter( 'wp_redirect', function( $redirect ) { error_log( print_r( debug_backtrace(), true ) ); return $redirect; } );If you don’t see anything in your cookies, then that’s the source of the problem. BP uses cookies to indicate that you’re moving through the group creation process, and if it doesn’t see these cookies, it sends you back to the first step.
So, the question is why those cookies aren’t being set. Things to look at:
1. I assume that at least some cookies are being set on your site, or you wouldn’t be able to log in 🙂 Are other BP-related cookies working? For example, if you go to the group directory and change the “Order by” dropdown to, say, “Newly Created”, is a browser cookie created
bp-groups-scope? A quick test is to do a hard-refresh of the groups directory, and see if your selection sticks.2. If other cookies are being set, it could be a path-related issue. Have you set a custom
COOKIEPATHin your wp-config.php file? It could be that cookies are being set in such a way that they’re inaccessible to certain pages of the group creation process.3. Have you tried in other browsers? Or in private browsing windows? It could be that this is being triggered by privacy settings of one sort or anotheer.
4. You showed some WP_DEBUG errors that (as you surmise) are unrelated to the problem. Are those shown when you first visit the group creation page, or *after* you’ve submitted the first step? It’s the submission process I’m concerned about, since the groups aren’t being created in the first place.
