#4021 closed feature request (wontfix)
Private Blog Option request "Visible only to users I choose"
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | normal | Version: | 2.9 |
Component: | Administration | Keywords: | privacy |
Focuses: | Cc: |
Description
I'm not sure if the trac is the appropriate place for this post, but here goes ...
Is there any development toward adding a third privacy option within Options > Privacy: "visible only to users I choose" (i.e. private) a la WordPress.com?
Change History (18)
#1
@
18 years ago
- Summary changed from Private Blog Option Request to Private Blog Option request "Visible only to users I choose"
- Version changed from 2.1.2 to 2.2
#3
@
18 years ago
- Keywords dev-feedback 2nd-opinion added; privacy feature private request removed
I don't think it should go into core. The majority of WordPress-using people I know don't even use private posts...
#5
@
18 years ago
- Milestone 2.3 deleted
- Resolution set to wontfix
- Status changed from new to closed
Closing as WONTFIX for now.
#6
@
16 years ago
- Cc janeforshort added
- Keywords privacy added; dev-feedback 2nd-opinion removed
- Milestone set to 2.9
- Resolution wontfix deleted
- Status changed from closed to reopened
- Type changed from enhancement to feature request
- Version changed from 2.2 to 2.9
Re-opening as have been getting a lot of requests for this functionality, and Matt supported the idea of including it at this point. Would like to see discussion of whether it should be in core or remain plugin territory.
#7
@
16 years ago
In my opinion, This should be left to plugin territory.
The simple reason is, That this fits in well with a Role management screen, Ie. Only users of a certain role can do something.
Theres a new Role Management plugin coming up as well: http://justintadlock.com/archives/2009/07/22/developing-a-user-management-plugin Looking at that, It seems the Content Permissions component would be what people would be after.
The only other option would be a Only allow logged in users to view content, ie. non-users would have to login before they can view content, I think this is a better solution than a per-user selection for core, Simply for the fact that its a common thing to want to close a WordPress install off completely during development, significant changes, or mearly needing to shut off access to content for awhile..
#8
@
16 years ago
Only allowing certain roles or only allowing logged in users to read the blog rather than specific users would be the best solution for the core IMO. Certain users works awesome for WPMU, but not so much for regular WP.
#9
follow-up:
↓ 10
@
16 years ago
One of the things i see wrong with the Roles option, Is that it would mean the user would have to select all the roles that they want to see the content, Ie. Admins & Editors, which will probably end up coming down to a "It should know if i select Editors, that obviously i intended Administrators to see it as well.."
#10
in reply to:
↑ 9
@
16 years ago
Replying to dd32:
One of the things i see wrong with the Roles option, Is that it would mean the user would have to select all the roles that they want to see the content, Ie. Admins & Editors, which will probably end up coming down to a "It should know if i select Editors, that obviously i intended Administrators to see it as well.."
Checkboxes then -- toggle each role.
The drawback of all or nothing (i.e. registered users only) is that it doesn't work on open registration blogs or blogs with lots of untrusted users.
#11
follow-up:
↓ 13
@
16 years ago
Checkboxes then -- toggle each role.
Yeah.. Thats the ovbious solution, But still doesn't look pretty to me.
Is the 'read' capability used to be able to see posts/etc? I've not tested it, just spotted it a few times?
#12
@
16 years ago
Theres a lot of plugins dealing with private "content" and imho it would be better to encourage developing/merging into a canonical plugin rather than putting a limited feature set directly into core. ( thats if canonical plugins happens like Matt talked about in State of the Word - SF ) Once the canonical plugin is matured it may go into core.
http://wordpress.org/extend/plugins/private-wordpress/
http://wordpress.org/extend/plugins/private-wp-2/
http://wordpress.org/extend/plugins/user-access-manager/
http://wordpress.org/extend/plugins/accessqontrol/
http://wordpress.org/extend/plugins/wp-sentry/
http://wordpress.org/extend/plugins/private-files/
http://wordpress.org/extend/plugins/wpnamedusers/
http://wordpress.org/extend/plugins/social-privacy/
http://wordpress.org/extend/plugins/private-wp/
http://wordpress.org/extend/plugins/privatepost/
http://wordpress.org/extend/plugins/wp-ucanhide/
http://wordpress.org/extend/plugins/privateplus/
#13
in reply to:
↑ 11
@
16 years ago
Replying to dd32:
Checkboxes then -- toggle each role.
Yeah.. Thats the ovbious solution, But still doesn't look pretty to me.
Is the 'read' capability used to be able to see posts/etc? I've not tested it, just spotted it a few times?
All roles have the read
cap, yes. It allows reading of content.
#14
@
16 years ago
@JohnMyr Yes, working out how to approach canonical plugins logistically, but what you suggest is pretty much how it'll go. If most people agree this feature is better served as plugin, will close the ticket as wontfix.
#15
@
15 years ago
+1 for getting the user and RBAC model revised first, then taking care of such things.
#16
@
15 years ago
- Milestone changed from 2.9 to Future Release
Moving out of 2.9 to future.
This use-case is plugin material IMHO.
#17
@
14 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from reopened to closed
Cleaning out old rotting tickets, This one is plugin material.
Plugins such as Members Only can be use it.
Handled by a bunch of plugins: http://codex.wordpress.org/Plugins/Restriction
Not sure if it should be a core feature or not (i.e. bloat vs. wide spread use).