Make WordPress Core

Opened 12 years ago

Closed 9 years ago

#21899 closed enhancement (fixed)

Missing class identifier for password protected posts

Reported by: mdgl's profile mdgl Owned by: obenland's profile obenland
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.4.2
Component: Posts, Post Types Keywords: has-patch
Focuses: template Cc:

Description

Password protected posts are insufficiently identified for good CSS styling.

Presently, the class name "post-password-required" is added to protected posts if a valid password cannot be found in the cookie. On the other hand, no special class name is added to protected posts if a valid password *can* be found, even though this is just a temporary condition until the cookie expires.

I suggest that both cases are interesting from a CSS styling perspective. Note that the title of protected posts is prefixed by the string "Protected:" in both situations.

This behaviour occurs because get_post_class() just checks post_password_required() [which validates the cookie] but get_the_title() just checks if the $post->post_password field is not empty.

I suggest an additional class name should be added by get_post_class() for the case when the post->post_password field is not empty. Current usage of class names here is not very consistent with the admin tool, so options might be "visibility-protected", "status-protected" [similar to "status-private" which is added for those with visibility "Private" and reflecting the underlying implementation] or perhaps just simply "protected".

Protected posts would thus be identified as follows:

Protected, with correct password: class="protected"
Protected, missing or invalid password: class="protected post-password-required"

See also #13860 and #18729. I can do a patch if needed but this is literally just a couple of lines of code (three if you include a comment).

Attachments (4)

21899.diff (353 bytes) - added by mdgl 12 years ago.
Suggested patch using class name "protected" (this is against 3.4.2 not trunk - sorry!)
Refreshed_patch_from_21899.patch (563 bytes) - added by F4rkie 10 years ago.
Refreshed patch to trunk
21899.2.diff (683 bytes) - added by wonderboymusic 9 years ago.
21899.3.diff (985 bytes) - added by obenland 9 years ago.

Download all attachments as: .zip

Change History (10)

@mdgl
12 years ago

Suggested patch using class name "protected" (this is against 3.4.2 not trunk - sorry!)

#1 @nacin
11 years ago

  • Component changed from Template to Posts, Post Types
  • Focuses template added

@F4rkie
10 years ago

Refreshed patch to trunk

#2 @obenland
10 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

While "interesting from a CSS styling perspective" is not the strongest reason to add it, a case could be made for consistency with status classes.

They should probably entail all three visibility statuses, public, protected, and private. I also like the idea about prefixing them with visibility-.

#3 @wonderboymusic
9 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.4
  • Owner set to obenland
  • Status changed from new to assigned

21899.2.diff refreshed to include all 3

@obenland
9 years ago

#4 @obenland
9 years ago

Looking at it a bit more I changed my mind about the three classes. visibility-private and visibility-public would be duplicates of status-private and status-publish which doesn't really add much value.

21899.3.diff just adds one class post-password-protected in case the password is set but not required (to go with post-password-required). It also splits out the post thumbnail check to make it easier to grok.

This ticket was mentioned in Slack in #core by obenland. View the logs.


9 years ago

#6 @obenland
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 34881:

Posts: Add post class for password protected posts.

Up until now password protected posts would only get a identifying class when
the password was still required. This adds a class for the case when that
requirement has been met.

For the other visibility types we already have status-publish
and status-private.

Props mdgl, F4rkie, wonderboymusic for initial patches.
Fixes #21899.

Note: See TracTickets for help on using tickets.