CUNY Academic Commons

I took a quick look at this and it appears we're using a custom create blog template with a custom signup form function:
https://github.com/cuny-academic-commons/cac/blob/1.8.x/wp-content/themes/bp-nelo/blogs/create.php#L16

This might be the reason why we're not inheriting the privacy block here.

Probably reverting to the original template by deleting /blogs/create.php or by changing cac_show_blog_signup_form() to bp_show_blog_signup_form() should fix this.

Yes doing either of the changes that Ray suggested bring back a privacy setting - although it only shows 2 options, for hiding or not hiding the blog from search results. I can work to try and make it reflect the 5 options now though.

So there was a function is ds_wp3_priave_blog.php called "show privacy options" that was hooked into the admin options screen for sites, and the file also had a commented-out add_action call that hooked it into the blog create form.

The function only listed out options for -1, -2, and -3 though, and not 0 or 1. What I did was modify it to include 0 and 1 and also un-commented the call that hooked it into the blog create form. Now all 5 options are showing up on the blog create page, but I can't seem to get it to respect the option that I set. Any thoughts?

Modifying ds_wp3_private_blog.php is fine.

Now all 5 options are showing up on the blog create page, but I can't seem to get it to respect the option that I set. Any thoughts?

Not off the top of my head. First place I'd look is bp_blogs_validate_blog_signup(). Either (a) BuddyPress is not recognizing negative values, or (b) the markup being generated for the extra privacy levels doesn't share the same "name=blog_public", so it's not being recognized when processing the form.

I think I've got this working now: https://github.com/cuny-academic-commons/cac/commit/e426ca29bbf58e171a2a6b5de87cda3996d4375b

So it turned out the main issue here is with the wpmu-new-blog-defaults plugin, in particular the cets_blog_defaults.php file. The plugin was overriding the privacy setting with the default even when one had been provided on signup. I made the change directly to the plugin for now but let me know if you see a better option.

In order to make the extra privacy settings work right both on the signup form and the admin pages, I had to create a separate function for each context, because we have to output all 5 options on the form, but in the admin pages Wordpress automatically outputs the 2 standard options, so we only need to add in the 3 extra ones. Made the changes in the ds_wp3_private_blog MU plugin.

Let me know if you think this works.

Thanks, Dan. In theory, it'd be nice if the options were compartmentalized in such a way that they didn't have to be repeated in various places - we also repeat it in plugins/cac-bp-custom-includes/groupblog.php. But maybe that's a good project for a rainy day.

Dan, can you please verify that settings are sticking in the following cases:

- Creating a new site /blogs/create
- Creating a new site after initial failure at /blogs/create
- Existing site Dashboard > Settings > Reading
- Creating a new groupblog (group Manage > Group Blog)

Looks like it's working in each case you outlined: https://github.com/cuny-academic-commons/cac/commit/92cbf19bb75e08c19c1af3e86ae45236ddc5c47d

I also removed the function for displaying the radio buttons at the top of the SuperAdmin->Sites->Edit screen because of the issue I mentioned on the call with it getting overridden, and had to add some logic to the plugin to get it to skip outputting the options in group-related screens, because it was creating a duplicate options section to one that was already there, which included all 5 of our options.