Limit Blog Creation to Admins
-
Hey everyone,
I’d like to make it so that only users who have admin privileges can create blogs, and users who aren’t admins won’t even see the “Create a Blog” link. I want to retain the multiple blog functionality, I just don’t want my users to be able to create their own blogs. I was hoping to adapt the solution in this (http://buddypress.org/forums/topic.php?id=192#post-8792) post from limiting group creation to limiting blog creation, but I don’t know enough about how all this works yet to figure that out. Ideally, I’d like to find a solution that uses a plugin, so I don’t have to modify the core files. I’m not asking someone to write a plugin for me (although that would be nice), but if anyone can point me in the right direction, I’d be much obliged.
Thanks for any help.
-
Ben, 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…)
The 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…)
So 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…)
All 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.
bp 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.
We’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..
}
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.
Back from break. Since I\’ve been creating this stuff out of thin air and it might be a good time to test this. brb.
Well, something went right today. This seems to work. I had to add a hook for the \’wp_footer\’ action that actually triggers the admin menu. The code in a copy/paste format is available here:
http://buddypress.pastebin.com/fce770ad
Copy and paste that into your bp-custom.php file. You can then alter the minimal logic in the function my_can_user_create_a_blog() to determine who and when people can see the \’create a blog\’ menu items scattered throughout bp.
Let me know how this works for you or if I’ve missed anything.
What I’m describing here is one method to alter bp’s behavior without modifying the core code. You can replace *any* bp function that responds to an action with the procedure similar to the one above.
1) Determine where in the code your modification must be made. If the function that you need to modify is triggered by an action with something like: add_action(‘some_action’,’the_function_i_want_to_modify’); then you can replace it and modify the code to your hearts content.
2) Make a copy of the function, calling it something else of course.
3) Unhook the original function, preventing it from responding to the action.
remove_action('some_action','the_function_i_want_to_modify')4) Hook your new function in the same manner as the old function. Replacing the call to the original function with a call to your new function.
add_action('some_action','my_replacement_function')5) Make changes to the replacement function that suits you.
One tip here. Functions get registered with wp to respond to actions with the add_action() call. The format you’ll see quite alot is:
add_action('action_name_to_hook', 'function_to_call')You will also see:
add_action('action_name_to_hook', 'function_to_call', 99)The 99 at the end there is the priority for the function call ‘function_to_call’. Think of it like this. If more than one function wants to hook ‘action_name_to_hook’ then wp queues them up and executes those functions in the order in which they were registered. To control when a function gets triggered by an action, the priority is taken into account.
Functions with priority 1 get triggered before functions with priority 10. If a bp function registers itself with an action and specifies a priority then the only way to remove that function and replace it is to specify the removal with the same priority.
The call above to add_action(…, 99) can only be removed with a remove_action(…, 99)
Calls to add_action() that don\’t have a priority have a default priority of 10. If the add_action() call you want to remove doesn\’t have a priority don\’t specify a priority. remove_action() will work fine.
Priorities are how bp arranges the admin bar menu items. If you look at the bottom of the bp-core-adminbar.php you\’ll see all the add_action() calls have a priority. They all respond to the same event which is \’bp_adminbar_menus\’. Each of them has a different priority assigned to it and they are triggered in the sequence of their priority. Want to rearrange the menu or slide something in between bp\’s menu items?
remove_action() them and then add_action() them again with different priorities for a different arrangement of menu items.
Have fun. I\’m done for the day.
Thank you, thank you, thank you.
Your code works like a charm, and you have taught me a great deal about how BuddyPress (and WPMU) works. I really, really appreciate it.
Incidentally, the changes I made are as follows, in case your or anyone else is curious:
global $current_user;
if ( isset( $roles['administrator'] ) || isset( $roles['editor'] ) || isset( $roles['contributor'] ) || is_site_admin() )was added to the “my_can_user_create_a_blog” function. Kind of an odd set of conditions, but, well…whatever. I\’m going to do a little bit of digging around later on, and see if I can condense that down a little (initially I’d planned to have it as a sort of “if user level is great than x” thing, but my cursory examination didn’t turn that up, so this is a decent stopgap for now).
I also added an if statement that draws on the “my_can_user_create_a_blog” function for the “my_blogs_setup_nav” function, so that now everything it does is wrapped thusly:
if (my_can_user_create_a_blog()==true) {
...
}and changed “is_user_logged_in” in the “my_adminbar_blogs_menu” function to call “my_can_user_create_a_blog” instead.
Again, I can’t thank you enough. I only hope some day I can help someone out the way you’ve helped me.
if you copy/paste the functions who are on the pastebin site, you have do add
global $bp;
to have the fns my_can_user_create_a_blog() to work.
Thanks this fixed the question for me also.
Wouldnt be bad if it could be incorporated into the app or a plugin for the future.
I’m usually capable of working my way through a tutorial and learning something by the end. But this post is of a magnitude that I’m not sure I know enough to tackle all the steps. Is each of your posts, Burt, a step-by-step instruction on how to accomplish Ben’s request, or do you revise your answers along the way?
I’d like mostly what Ben is asking for. I want to use BuddyPress as a member directory. I don’t wish for anyone to make blogs through MU/BuddyPress other than my staff. I don’t want the “create a blog” option to appear anywhere. Not in the member profile, not in the tool bar. Essentially I want the option not to exist for users. Will the tutorial above show me how to do that?
Starting from instructions in post one, I’m finding that changing the admin setting from “only user account can be created” to “only logged in users can create new blogs” results in a “you must login to create a blog,” which takes me to the wordpress sign-in page before I have even registered.
The “only user account” setting generated what I would like to have happen, a signup screen sans “gimme a blog.”
Please forgive my being an ignoramus and let me know if I should patiently work my way from top to bottom, or if there is another solution outlined in a different post.
Thanks!
Ok, so, haha, given the lack of responses, I’m digging my way through this by rewriting Burt’s tutorial step-by-step so I can “get it.”
Alas, the simplest thing is tripping me up. I cannot find, in any BuddyPress directory, a file called bp-custom.php
Am I creating this file?
… continuing to puzzle it out while hoping someone takes pity on me, lol
A simple fix for you, might be from site admin… options:
Set ‘allow new registrations’ to ‘only user accounts can be created’.
That should remove all the blog stuff.
I got thru the first part fine but when I add
global $current_user;
if ( isset( $roles[‘administrator’] ) || isset( $roles[‘editor’] ) || isset( $roles[‘contributor’] ) || is_site_admin() )
this gets ignored site admin still get the creat blog option however editors do not.
Im just trying to block contrib and subscibers from being able to create a new blog option
Unfortunately, changing the WPMU option does not trigger anything in Buddy Press. Which was part of my original question, iirc. I still think that that needs to be worked into BP.
Actually, to be more specific (and this is part of a question I asked elsewhere many weeks ago) it’s true that turning off the option in WPMU DOES restrict users from creating blogs through BP. However, they shouldn’t be able to *see* the create a blog option, at all.
From a user perspective, it conveys a) that the site is broken, b) that they’ve done something wrong. Also, from a customer satisfaction perspective, we’ve now denied them something that they “could” have had.
I eventually had a friend more versed in PHP than I am go in and strip the code that called the blog options into the PHP files. Unfortunately, when I upgraded to the new version of BP, they came back.
I’m not a programmer, obviously, and no slag at anyone, but it kind of seems as if it should be a no-brainer. BP offers a great way to tied together a community, even without the blog option. There’s no way we want to risk having blogs affiliated with our site that offer content not in-line with our family-friendly atmosphere.
Hi elemsee – great avatar!
If you disable blog registration through the wp-admin backend, where do you still see ‘create a blog’ etc options? We can create a Trac ticket to get this improved for a future version.
Hi DJPaul, thanks
I have blog registration set to “Only user account can be created.”
I still see “create a blog” in:
1) The Buddy Bar > My Account > Blogs > Create a blog
2) http://yoursite.com/members/yourname/blogs/ Blogs > Create a blog
If this could be improved, that would be great.
Trac ticket created on https://trac.buddypress.org/ticket/1251
Lovely! Thanks.
thats still does not solve my problem
I’ll try to explain my issue better I am testing buddypress for a school program and I need Super Admin (tech guy) and Admin (it trainers) Authors (teachers) to be able to create blogs, However there is not option to limit only admins to the create a blog option.
Say Im a teacher and I ad a student in my blog as a subscriber
that kid could now create a blog and it auto makes him an admin of the blog
I need to be able to restrict subscribers and editors from the create a blog option but allow Super Admin, Admin, and Authors access to the create a blog.
I don’t wish to give any Teachers super admin access that would open up trouble in itself.
- The topic ‘Limit Blog Creation to Admins’ is closed to new replies.
