Forum Replies Created
-
In reply to: Limit Blog Creation to Admins
This whole little tutorial was because I promised Andy that I\’d do a Codex thing about actions/filters in bp. I figured this would be a good place to start.
Taking a break.
In reply to: Limit Blog Creation to AdminsWe’ve unhooked the current fns and hooked up our replacement fns. So far they do exactly the same thing as the current fns. We need the ability to decide who gets to see the menu item. I choose to create yet another fn to decide yes or no on blog creation.
function my_can_user_create_a_blog(){
if (is_site_admin())
return true;
else
return false;
}
That goes in bp-custom.php also. Ya, all it does is check if the current user is the site admin. I’m not sure what you mean by only letting ‘Admins’ create blogs. There are blog admins and one site admin. Everyone with a blog gets to have the wp role ‘administrator’. Not sure what you want so i’ve wrapped the logic in a fn so you can change it to whatever you like.
Now we need to alter our new replacement fns to skip the display of the menu items if that returns false.
In our my_blogs_setup_nav() there is a line like this:
bp_core_add_subnav_item( $bp->blogs->slug, ‘create-a-blog’ __(‘Create a Blog’,
‘buddypress’), $blogs_link, ‘bp_blogs_screen_create_a_blog’ );
We need to wrap it like this:
if (my_can_user_create_a_blog()){
‘bp_core_add_subnav_item( $bp->blogs->slug, ‘create-a-blog’Create a Blog’,’buddypress’), $blogs_link, ‘bp_blogs_screen_create_a_blog’ );
}
Also the function my_adminbar_blogs_menu() has code that looks like this:
echo '<li' . $alt . '>';
echo '<a href="' . $bp->loggedin_user->domain . $bp->blogs->slug . '/create-a-blog">'
. __('Create a Blog!', 'buddypress') . '</a>';
echo '</li>';You need to wrap that the same way:
if (my_can_user_create_a_blog()){
..all that stuff..
}
In reply to: Limit Blog Creation to Adminsbp itself uses the ‘plugins_loaded’ event to register it’s widgets, init it’s globals and other things. What we need to do is create a fn that listens for ‘plugins_loaded’ and do our unhooking and hooking after bp is done. In bp-custom.php we’ll need another fn called:
function my_create_a_blog_hooks(){
remove_action( ‘wp’, ‘bp_blogs_setup_nav’, 2 );
remove_action( ‘admin_menu’, ‘bp_blogs_setup_nav’, 2 );
remove_action( ‘bp_adminbar_menus’, ‘bp_adminbar_blogs_menu’, 6 );
add_action( ‘wp’, ‘my_blogs_setup_nav’, 2 );
add_action( ‘admin_menu’, ‘my_blogs_setup_nav’, 2 );
add_action( ‘bp_adminbar_menus’, ‘my_adminbar_blogs_menu’, 6 );
}
add_action(‘plugins_loaded’,’my_create_a_blog_hooks’,99);
This gets triggered on ‘plugins_loaded’ with a priority of 99. All of bp’s hooks have a priority of 10 or less so using 99 gets this fn called after all known bp hooks for ‘plugins_loaded’. Pretty safe.
In reply to: Limit Blog Creation to AdminsAll these add_action() things that tell wp to hookup our fns to wp’s events get executed during the plugin load sequence. The code we stick into bp-custom.php gets loaded and parsed before bp does anything. If we just unhook stuff in there and create our own hooks it won’t work. wp will run our unhooks, find that there is no fn to unhook do nothing. There’s nothing to unhook yet because bp hasn’t fully loaded and declared it’s intentions to listen and hook certain events.
We have to set things up to wait paitently for bp to declare its intentions and then change the state of the bp universe behind it’s back. One of those events that wp triggers during the startup sequence is ‘plugins_loaded’. How handy.
In reply to: Limit Blog Creation to AdminsSo now we know what actions trigger the display fn’s for ‘Create a Blog’. Somewhere in those two fn’s is the code that displays that menu item. I guess there’s a bunch of different ways to solve this issue once we get to this point. I’m going to create two new fn’s that replace the current ones and wrap the menu option display lines in some user role detection code. If we decide that the current user can see the option then it gets displayed.
First we create two new functions in bp-custom.php that are copies if the current fn’s but with a different name. Copy bp_blogs_setup_nav() and bp_adminbar_blogs_menu() to bp-custom.php and rename them my_blogs_setup_nav() and my_adminbar_blogs_menu().
Now we have to unhook bp’s hooks for those two menus and replace them with our hooks to our new my_…() fns. The trick is to allow bp to fire up completely and before anything else happens unhook the fns.
bp is a plugin and during the wp init/startup process it loads all the plugins, executes any code that isn’t part of a fn and then triggers a few actions that signal to plugins what spot in the startup sequence it’s in and then goes on it’s merry way doing what the user wanted like loading a template file and executing it.
(Saving…)
In reply to: Limit Blog Creation to AdminsThe member theme Blogs > Create a Blog and the admin bar My Account > Blogs > Create a Blog both get their menu items from the bp options nav array that each component sets up when they go through their init procedure.
In the case of the blogs component it’s the fn bp_blogs_setup_nav() in /buddypress/bp-blogs.php
The other menu item is the admin bar option My Blogs > Create a Blog at the bottom of that menu. That lives in the fn function bp_adminbar_blogs_menu() in /buddypress/bp-core/bp-core-adminbar.php
Without modifying the core files we can replace both of these fns with our own since they are triggered by actions in wp.
bp_blogs_setup_nav() responds when triggered like this:
add_action( ‘wp’, ‘bp_blogs_setup_nav’, 2 );
add_action( ‘admin_menu’, ‘bp_blogs_setup_nav’, 2 );
bp_adminbar_blogs_menu() responds when triggered like this:
add_action( ‘bp_adminbar_menus’, ‘bp_adminbar_blogs_menu’, 6 );
(Saving again…)
In reply to: Limit Blog Creation to AdminsBen, I took a look at something similar before. There were multiple requests for limiting the number of blogs a user could create. I came up with the only solution I could find at the time: https://buddypress.org/forums/topic.php?id=1328
bp relies on wpmu’s settings for blog creation. wpmu controls this in the site admin back end. Site Admin > Options > Allow New Registrations. Whatever solution to your request is has to take into that setting in wpmu. It’s basicly an on/off kinda thing. You either can or can’t. It’s not based on user role.
Disabling the registration/signup ‘gimme a blog’ option and you have people still able to create blogs after logging in. Let’s say we set that to ‘Only logged in users can create new blogs.’. It’s a start.
So, now only logged in users can create blogs. The create a blog on registration is gone. Next issue is the need to let certain roles see and use the ‘create a blog’ option.
This exists in the member theme Blogs > Create a Blog and in the admin bar under My Blogs > Create a Blog and My Account > Blogs > Create a Blog.
(Saving this while I dig thru some code…)
I added Andy’s bp-core-wpabstraction.php file to the bp pastebin for discussion.
http://buddypress.pastebin.com/f578203cb
I suggest *not* abstracting is_site_admin() because it’s a commonly used mechanism for detecting wpmu. if (function_exists(‘is_site_admin’)) should return true on wpmu and false on wp. I know that the abstraction file is so that we don’t have to care, but….
In reply to: first things firstAh. I ran across number 2 post. It was buried at the end of a resolved topic. Nobody is going to notice that. The best way is to pick an appropriate forum and start a new topic for each issue that you want to bring up.
Still need to know what version bp and what version wpmu you are running.
In reply to: first things first1) Is not a bp issue. It’s a css theme issue. You are welcome to modify the distributed theme or use any theme that you’d like.
To address 2 and 3 we need to know what version of bp you are using, what version wpmu to start with. Things are pretty busy round here lately. Topics scroll off the front page radar within 12-24 hrs. Can you post links to the 2 and 3 topics?
In reply to: reducing the width of buddypress themeThere are a couple of files that can be used that bp looks for. You\’ll need to create them. In the themes, if you create custom.css in the /css directory it overrides the css for each theme. Also in the home theme or your custom theme if you create a file called /css/site-wide.css that overrides all css generated by bp.
That way you don’t need to modify the distributed css files and your upgrade experience will be much happier.
In reply to: No BP Admin AreaDepends on the plugin.
Plugins are written to work with a particular version. “Tested with..” when new versions of bp and wpmu come out, plugin authors scramble to release new versions. Most of them try to keep up to date and test on the unofficial SVN trunk version as it gets closer to a formal release.
Depends on the plugin.
In reply to: No BP Admin AreaYou need to follow the wpmu README.txt exactly. Seems you are missing the wildcard DNS part and perhaps some other stuff. wpmu isn’t exactly a plug-n-play kinda thing.
In reply to: No BP Admin AreaHmm. So you are installing wpmu on a subdomain in a subdirectory? What was the wpmu configuration option that you chose? Subdirectory or subdomain for new blogs?
In reply to: No BP Admin AreaWas wpmu running successfully before trying to install bp? Can you create blogs and create posts on the blogs. Everything ok in wpmu without bp installed?
In reply to: No BP Admin AreaVisit the wpmu back end as site admin and it should setup all the tables and you should see bp specific menu items in wpmu back end Site Admin menu.
In reply to: No BP Admin AreaThat would be wpmu from here: https://mu.wordpress.org/download/
And bp from here: https://buddypress.org/download/
Those two would be the latest official releases. Where did you put bp? That version of bp should go in /mu-plugins. You should have a bunch of files like bp-core.php, bp-<whatever>.php in that dir and also a bunch of subdirs like /mu-plugins/bp-activity, /mu-plugins/bp-<whatever>
That what you have running?
In reply to: No BP Admin AreaLets start with this. What version of bp are you trying to install on what version of wpmu?
In reply to: bp_get_field_data no longer workingI was getting nothing because the class methods are not designed to be called from a template loop. Not using a user id defaults to the current user id viewing the member theme page and that’s not valid for anything inside a template loop.
Anyway I posted a ticket with a fn to get at the current loop user id. https://trac.buddypress.org/ticket/684
In reply to: bp_get_field_data no longer workingThe reason you are getting nothing is that $user is not a global var in that template. I was getting nothing because of a bug. Specify the user var like this:
<?php
global $site_members_template;
xprofile_get_field_data(\"City\",$site_members_template->member->id);
?>That is the current template user id. There is no template tag to just get the current template loop user id yet.
In reply to: bp_get_field_data no longer workingIt’s not just you psfk. I tried this out in members-loop.php with BP_XProfile_ProfileData::get_value_byfieldname( $field, $user_id ) and it just returns false for me too. I left out the user id param because it isn’t needed. The current user is used instead. Just wanted something. Got nothing.
In reply to: Customise/bp-core/bp-core-templatetags.php
In reply to: Remove Blog Link in options-navThat link disappears when you don’t have the blogs component activated. Deactivate in the wp back end BuddyPress > Component Setup
In reply to: bp_get_field_data no longer workingI would check that ‘city’ is the actual field name and not ‘City’ and that $user is a global var that is valid where you are trying to use it.
In reply to: Remove Blog Link in options-navWhat version bp? I think I\’ll just put that on a hotkey combo.
Uninstall the blog component if you are talking about the various vertical menu options in the member theme.
Remove the line in the member theme /buddypress-member/header.php that looks like this:
<li<?php if ( bp_is_page( BP_HOME_BLOG_SLUG ) ) [snip]That\’s line 41 r1360 if you are talking about the header nav items.
