Forum Replies Created
-
In reply to: Really — how to begin?
The Getting Started section of the BuddyPress Codex is a good guide: https://codex.buddypress.org/home/
In reply to: wiki recommendationsIt really depends on what you want to do with the wiki. If it’s going to be a workspace for individual members or BP groups, I would recommend something like https://wordpress.org/extend/plugins/bp-wiki/, or the new plugin that I’m building with @dwenaus https://github.com/boonebgorges/buddypress-docs
If you want your wiki to be more along the lines of Wikipedia – a shared knowledge base, visible to all members of the site as well as the public – then MediaWiki is pretty good, but it’s a bear to integrate and keep integrated. You might accomplish something similar by setting up a blog on your MS installation as the ‘wiki blog’ and then enabling a plugin like http://wp-wiki.org/
Not really. That string is concatenated more or less literally. You could make a language pack that takes away the number, but in that case it would be gone in all instances, whether or not there were replies.
In reply to: Announcements tab like CUNY?In reply to: Group Announcements Plugin/Tab?No need to get snippy, gee whiz.
The error suggests that you are using a version of WordPress less than 3.0. You say the latest version of 3.0 – what does that mean? The latest version of WP is 3.0.4
What are you going to use the extra usermeta for? If you just need an easy way to store and retrieve some data about individual users, then using BP xprofile fields is really the easiest way to go – they can be created in the Dashboard, and all the registration markup & save/retrieve functions are all built in. If, on the other hand, you’ve already built a bunch of custom functions to query across usermeta, then it’s probably best to keep what you’ve got (saving in wp_usermeta) and hook some functions into the BP registration process.
In reply to: why must there be _e() everywhere? (a newbie writes)It is a translation function. Wrapping ‘Blog Posts Feed’ in _e() ensures that it appears in the .po file that translators use to create language packs. The ‘buddypress’ argument ensures that it is associated with the ‘buddypress’ textdomain (since potentially the same string might be translated in different ways when part of different software packages).
The difference between __() and _e() is that _e() echoes the string to the screen.
In reply to: Groups don’t allow avatar uploadwp-config.php of your wordpress installation directory. Also bb-config.php in the same directory if you are using forums.
In reply to: Only Show Members with AvatarsI have done something similar. The reason why you can’t do it automatically is that avatar information is not stored in the database. You can get around this by creating some database content corresponding to avatars. There is a do_action hook near the end of the avatar upload process. Hook your own custom function to that hook that saves a has_avatar metadat item in the usermeta table using update_user_meta(). Then, in your widget bp_has_members loop, either load up a bunch of members and filter out the ones without avatars, or filter the sql queries themselves to make sure you only get members who have the has_avatar metadata. Not super straightforward, but definitely possible.
@VegasParty607 Make sure you set it to the proper UTC offset – not simply UTC, but UTC-5 (for example, if you are in the US Eastern Time Zone)
Thanks for your patience with this, gang. I’m going to investigate whether this is a BP problem or a problem with WP itself.
@bigjimmysisco I mean the username/password to your files, so I can access them through an FTP client. I have a feeling that this problem is not going to be solved unless I or another developer can test on an actually affected installation.
In reply to: Problem with avatar uploadBe that as it may, something is interfering with the Javascript being loaded correctly.
In reply to: Problem with avatar uploadIt looks like you are having a javascript conflict, which is being caused either by your custom theme, or by a plugin. Deactivate plugins other than BP to see if one of them is causing the problem. If not, try switching back to the BuddyPress Default theme to see if your theme is the culprit.
Those tabs are created in your theme’s header.php. You can just move them around in the markup itself by cutting and pasting. See https://codex.buddypress.org/theme-development/building-a-buddypress-child-theme/ for more info on creating a child theme.
In reply to: Remove the “DashBoard” from the adminbarmercime’s solution should work nicely.
Keep in mind that the Dashboard option only appears for logged-in users who have a role greater than Subscriber on your blog.
In reply to: Hot to correct my avatar error and oother helping!In reply to: Problem with avatar uploadYour second two issues seem to be related to the theme. See https://codex.buddypress.org/theme-development/building-a-buddypress-child-theme/ for how to build a child theme. Member directory templates are members/index.php and members/members-loop.php. Group home page templates are is groups/single/.
I am not sure I understand the first problem. Are you saying that crop isn’t working? Can you describe in more detail what is happening? Also, any details you could provide about your installation would be helpful https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/when-asking-for-support/
In the future I also suggest giving a more descriptive title to your support forum posts. Everyone who comes here is looking for help, so titling your post ‘heeeeeeelp’ does not tell anyone what it’s about.
Does anyone experiencing the problem feel comfortable sending me the credentials to FTP into their installations and run a test or two? It is nearly impossible to troubleshoot when I can’t reproduce the problem. Email me [buddypress.org username] at gmail.com
I find it quite perplexing that 1.2.7 has been out for several weeks, and this problem is just coming out now (and only on a relatively small number of installations). Is it possible that it has something to do with the new year and hosts’ local time settings not working properly? Is anyone having the problem with WP timestamps as well?
Ok, that’s helpful. That means the data is bring stored correctly. I’ll do some experiments to see what I can find.
It’ll be under Databases. Then you will have to locate the database where WP is installed, likely called wordpress or something similar
No more asking when the problem will be fixed until someone had said that they have found a fix!
@bigjimmysisco Access to your database is different from access to your files. Your host might provide you with a tool called PHPMyAdmin. If so it would be on your hosting control panel. User it to locate the table called wp_bp_activity and then have a look at the date_recorded column
There is no patch yet because no one has figured out what’s causing it in the cases described here.
Anyone who is experiencing the problem: Do you have access to your database? Look in a BP table (wp_bp_activity, let’s say). The timestamps there should be in UTC. So if you’re in Denver, they should read 7 hours earlier than your local time. Is that the case, or are you seeing a different offset? (Or none at all?)
In reply to: 1.2.6 upgrade date offset!!Confirmed on the trunk. Brandon’s diagnosis and fix looks right.
It’s been fixed in the trunk: https://trac.buddypress.org/changeset/3651 If you’re having the problem on 1.2.7, you should be able to fix it by making the following changes:
– In bp-xprofile/bp-xprofile-filters.php, change line 81 to
`$field_value = bp_format_time( $field_value, true, false );`
– In bp-core/bp-core-templatetags.php, change line 815 to
`function bp_format_time( $time, $just_date = false, $localize_time = true ) {`
and replace line 820 with the following lines:
`$root_blog_offset = false;
if ( $localize_time )
$root_blog_offset = get_blog_option( BP_ROOT_BLOG, ‘gmt_offset’ ); `Thanks to Brandon for the fix.
