Project

General

Profile

Actions

Bug #4199

closed

Create a Site, Privacy Settings

Added by Samantha Raddatz over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Daniel Jones
Category name:
User Experience
Target version:
Start date:
2015-06-25
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Add privacy settings to initial 'Create a Site' page.


Files

2createsite.png (119 KB) 2createsite.png see 1.4 (circled) Samantha Raddatz, 2015-06-25 09:49 AM
Actions #1

Updated by Boone Gorges over 9 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.

Actions #2

Updated by Raymond Hoh over 9 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:
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.

Actions #3

Updated by Daniel Jones over 9 years ago

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.

Actions #4

Updated by Daniel Jones over 9 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?

Actions #5

Updated by Boone Gorges over 9 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.

Actions #6

Updated by Daniel Jones over 9 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.

Actions #7

Updated by Boone Gorges over 9 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)

Actions #8

Updated by Daniel Jones over 9 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.

Actions #9

Updated by Boone Gorges over 9 years ago

  • Status changed from Assigned to Resolved

This looks good to me. I'm going to leave this in the 1.9 milestone, as it involves some fairly extensive changes. Thanks, Dan!

Actions

Also available in: Atom PDF