Forum Replies Created
-
Hooray!
Maybe, Erich73 – the only thing is that this problem is caused by incompatibility with another plugin. I’m not sure what the policy is on accommodating other plugins. Maybe More Privacy Options is enough of a no-brainer for BP communities that it’d be OK?
Hi Afoka –
Your post reminded me that I had to change this hack a bit in BP 1.1.3. Here are the notes I made for myself at the time. Let me know if they make sense, and if you can make them work:
===
In wp-content/plugins/buddypress/bp-blogs.php:
– function bp_blogs_record_post has two cases, one for new posts and one for edited posts. Change
if ( (int)get_blog_option( $blog_id, 'blog_public' ) ) {to
$is_blog_public = get_blog_option( $blog_id, 'blog_public' ); //added
//if ( (int)get_blog_option( $blog_id, ‘blog_public’ ) ) {
if ( $is_blog_public > 0 ) { // changed to account for More Privacy Optionsin both of the cases.
– functions bp_blogs_record_comment and bp_blogs_approve_comment. Replace
if ( (int)get_blog_option( $recorded_comment->blog_id, 'blog_public' ) ) {with
$is_blog_public = get_blog_option( $recorded_comment->blog_id, 'blog_public' ); //added
//if ( (int)get_blog_option( $recorded_comment→blog_id, ‘blog_public’ ) ) {
if ( $is_blog_public > 0 ) { // changed to account for More Privacy OptionsSure, there’s a couple ways to do it.
If you want to turn off linking in specific profile fields (so that nothing in “About Me” gets linked, but locations in “Location” or “Hometown” do), you can use https://wordpress.org/extend/plugins/custom-profile-filters-for-buddypress/. Near the beginning of that plugin, there’s a spot for you to list fields that should NOT be linkable.
If you want to be more specific and look for certain words in a field, here’s how. Copy the original xprofile_filter_link_profile_data function from bp-xprofile-filters.php, paste it into functions.php or wherever you put the remove_filter code, rename it something unique (like henry_xprofile_filter_link_profile_data), then afterwards add the line
add_filter( 'bp_get_the_profile_field_value', 'henry_xprofile_filter_link_profile_data', 2, 2 );At this point you’ll have to customize the filter to look for certain words. Use something like this (untested, but something like it should work):
if ( strpos( $field_value, 'Boston' ) ) {
$field_value = str_replace( 'Boston', '<a href="' . site_url( BP_MEMBERS_SLUG ) . '/?s=Boston">', $field_value);
}In other words, if ‘Boston’ is found in the field, replace the plaintext ‘Boston’ with a link to a search on the word ‘Boston’.
Did you try making the change to bp-blogs-classes.php described in the link I gave you? It will only take affect with new blog posts – you’ll have to delete the old unwanted activity items manually.
Try making the change to bp-blogs-classes.php, and then post a new entry to a private blog to see if the change has worked.
Hi henrybaum. The filter you’re looking for is xprofile_filter_link_profile_data() in bp-xprofile/bp-xprofile-filters.php. Try adding (to a plugin, to your theme’s functions.php file, or to your bp-custom.php file)
remove_filter( 'bp_get_the_profile_field_value', 'xprofile_filter_link_profile_data', 2 );I’m not sure how those plugins in particular work, but here’s a solution that worked for me with the plugin More Privacy Options: https://buddypress.org/forums/topic/more-privacy-options-private-blogs-and-activity-streams
The same principle can probably be applied to your case. Figure out how your plugins are recording fine-grained privacy options, and then adjust the code at the above link to match.
I think a lot of what Mike says is quite sensible, but my impression, reading what JJJ posted above and at the trac ticket, is that there would be next to no change in the way that the friend relationship works from the user point of view. Viewing a list of my friends, for instance, would be the same as it currently is. The difference is behind the scenes: the friend list is really the member list of a special kind of group (where ‘special’ entails private, stripped down, etc). While it might technically be true that, for instance, Mike’s friends would be a member of the “Mike Pratt” group, that’s not how it would be represented on the front-end of BP.
From a developer’s point of view I very much like the idea of merging components where possible, both to streamline the core BP code and to make extension easier to do.
A small thought about how it’d have to work. Currently if A requests membership in a private group, an entry is written to bp_groups_members = 0. When the group admin B approves membership, it changes to 1. If the current symmetrical model of friendship maps onto group membership, the second step – admin approval by B of A’s friendship request – will have to write another entry to bp_groups_members, this one making B a confirmed member of A’s friend group.
Hi roydeanjr. Including such functionality is definitely on my list of things to do. As far as I know, the bp-invitefriends plugin you mention (which was part of Nicola Greco’s BPDEV) does not work with current versions of BP, so it would take a bit of work to get it running even on its own, much less as a seamless part of my plugin. But I’m glad you made me remember his work, as I’ll definitely use it as a starting point when I add the ability to invite non-members to my own plugin.
Have a look at how it’s done here on buddypress.org (at least on the CSS end of things). https://buddypress.org/developers/boonebgorges/ The nav li items are floated to the left.
As for the PHP, you might have to play around with where the userbar and optionsbar are called in header.php of your child theme. Most of the work is done in the CSS though – the markup is pretty flexible.
Dang it, those print statements were supposed to have
pretags (to make the print_r readable). You can fill in the blanks.unregister_sidebar() works but it is weird and finicky.
WP’s internal documentation says that unregister_sidebar() takes the ID of the sidebar as an argument, which I suppose is technically true, but it’s misleading. Sidebar IDs are automatically generated. They look like sidebar-1, sidebar-2, etc, and are different from the names you give a sidebar when you register it.
Here’s a little function you can use to see what your sidebars look like (don’t use this on a live site!):
`function what_are_my_sidebars_called() {
global $wp_registered_sidebars;
print “
"; print_r($wp_registered_sidebars); print "
“; die();
}
add_action( ‘wp_head’, ‘what_are_my_sidebars_called’, 1 );
Glad it works!
I styled the nav item to match the bp-default (pre 1.2) style, which aligns those items to the right. You might have to add the new CSS selector (I think it’s #bp-nav-invite-anyone, but I can’t remember exacly and I’m not in front of my computer right now) to your custom stylesheet.
Btw I wouldve given it the same css selectors as the default send invites link, but I used the Group Extension API, which creates selectors automatically and as far as I know does not allow you to override.
I put something together along these lines today. I used the version of TinyMCE that ships with WP. Have a look, and please feel free to build on it or tell me what I’m doing wrong
: http://teleogistic.net/2009/12/tinymce-in-buddypress/
Shoot, I think I see the problem. The path of the file that the plugin is trying to require is coded incorrectly, due to the fact that when I requested a place in the plugin repo, I asked for the wrong slug. On line 322 of invite-anyone.php, it should say
require ( WP_PLUGIN_DIR . '/invite-anyone/invite-anyone/invite-anyone-cssjs.php' );instead of
require ( WP_PLUGIN_DIR . '/bp-invite-anyone/invite-anyone/invite-anyone-cssjs.php' );Note that the “bp-” has been cut off.
You can change this yourself, or download it from the repo again – I’ve changed it in the trunk.
gsmith6673 – What are the contents of the bp-invite-anyone directory? You should have a readme.txt, the plugin file invite-anyone.php, and a directory invite-anyone, which contains one php file (the one that your error reports as missing), three .js files, and a gif file. Do you see something similar?
Update: it’s in the wp.org repo: https://wordpress.org/extend/plugins/invite-anyone/
What part of the admin panel are you talking about? Do you mean Dashboard > Site Admin > Groups? On all my installations of BP I can see hidden groups on this screen when logged in as site administrator.
On a regular WP blog, combining https://wordpress.org/extend/plugins/add-link/ with FeedWordPress allows site users to add their feeds to the site without access to the dashboard.
Thanks!
Bowe – After I got the AJAX figured out I realized that I should probably separate it out and offer it as a separate plugin. Either that or in a future version of this plugin I’ll allow site admins to turn off the “invite anyone” feature but keep the autosuggest.
Very glad to see you incorporate the code, Marius. Three cheers for collaboration!
I share Mike’s original concern about forking conversations. (And I giggled a bit when I wrote “forking conversations”. Fork yeah!) And I think r-a-y’s solution is a really nice one, if it’s doable: allow site admins to turn off inline commenting on certain kinds of activity items. That way we can still take advantage of activity commenting for things like status updates, friendships, etc.
Another thought: Maybe an admin option to turn off excerpts in activity would prevent forking. When I post a new blog or forum post, an update might appear on the activity feed that says “Boone posted a new blog entry: Boone’s Blog Post”, but without an excerpt. People could still comment in ways that make sense (“Boy Boone, you blog a lot”) but they wouldn’t really be able to leave substantive comments on the content of the blog entry/forum post, since it wouldn’t appear on the activity stream. Again, it takes a bit away from what could be great about the activity comments, but it has the virtue of keeping all conversation in one place.
The layer issue can probably fixed with CSS positioning. I did a quick test by setting #footer to position:static fixed the index problem. I imagine something similar will work for the random member divs, though I couldn’t figure it out in a minute or two of testing. Try looking at the styles on the various divs and play with position, float, and z-index.
Something like wp-wiki is limited in a couple ways:
1) It doesn’t have ready-made discussion pages
2) It doesn’t make the page history public
For many uses of a group wiki, neither of these is necessary. But a full-featured BP wiki plugin will have both.
I think (1) can be cobbled together without too much difficulty, either through the creation of a parallel post for each wp-wiki enabled post (an attractive solution, because the discussion page can be wiki-enabled too) or through the use of comments (attractive in its own way, as the metadata is already in place, and you might be able to leverage something like CommentPress.
Feature (2) is a bit more complicated, because wp-wiki uses page revisions for versioning. You’d have to move them out of the Dashboard and built analogs for “cur” and “diff” for it to be really useful and wiki-ish.
Like D Cartwright says, it’s likely that making wp-wiki work will require as much development time as starting with a full-fledged wiki and making it work with BP. There’s probably a real market for both solutions, since a simple BP plugin will be very easy to use for beginners, while power users might want the functionality of MediaWiki
The way the plugin is set up, group members have to visit the group blog before they join it. This wasn’t quite as smooth as I wanted it to be – users were complaining that they were getting redirected in funny ways – so I took some time today to rewrite a bit of the code. I describe the changes and provide a link to the revised plugin here: http://teleogistic.net/2009/12/streamlining-group-blogs/
