Create a Site, Privacy Settings
Add privacy settings to initial 'Create a Site' page.
#1 Updated by Boone Gorges over 6 years ago
- Tracker changed from Design/UX to Bug
- Status changed from New to Assigned
- Assignee changed from Boone Gorges to Daniel Jones
- Target version set to 1.9
There must be some bug that's causing it not to be there during the inital pageload.
Ideally, privacy setting would reflect our 5 settings, as defined in wp-content/mu-plugins/ds_wp3_private_blog.php.
#2 Updated by Raymond Hoh over 6 years ago
I took a quick look at this and it appears we're using a custom create blog template with a custom signup form function:
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
bp_show_blog_signup_form() should fix this.
#4 Updated by Daniel Jones over 6 years ago
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?
#5 Updated by Boone Gorges over 6 years ago
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.
#6 Updated by Daniel Jones over 6 years ago
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.
#7 Updated by Boone Gorges over 6 years ago
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)
#8 Updated by Daniel Jones over 6 years ago
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.