Skip Navigation

[Closed] Password protected post type related bugs

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 3 replies, has 2 voices.

Last updated by Caridad 7 years, 4 months ago.

Assigned support staff: Caridad.


Wordpress: 3.8
Wp-Types: 1.5.2
WP-Views: 1.3.1

We were tasked by a customer to enable password protection on some of his projects on his site that is setup with wp-types and wp-views.

The visitor is first presented with a list of projects configured with wp-views as follows:

<ul class="project-list">
  <wpv-loop wrap="2" >
    [wpv-item index=1]
    <li class="twelve columns alpha">[wpv-post-body view_template="Projects by Team - Single Project"]</li>
    [wpv-item index=2]
    <li class="twelve columns omega">[wpv-post-body view_template="Projects by Team - Single Project"]</li>
    <div class="clear"></div>

and when the visitor clicks on a project list item they are presented with the project itself (that uses another template).

When wp-views tries to render a password protected post using the [wpv-post-body view-template="xxx"] shortcode it skips the view template altogether and returns the original post body. From a security perspective this bypasses password protection and exposes the protected content. From wp-views perspective this renders view templates useless on password protected posts.

Bug 2
The [wpv-if evaluate="post_password_required( null ) = '1'"] shortcode fails to evaluate the wordpress function because the 'post_password_required' contains 'or' which is considered as an OR operator.

As a side question, the post field 'post_password' is on the post object itself and not in post meta. is there a way to evaluate this field with wpv-if shortcode or we have to resort to using the 'wpv-extra-condition-filters' to introduce our evaluation. ( the requirement is to evaluate !empty(post->post_password )


Dear Ioannis

Before looking any further, please update Views to 1.4.1. This is required for Types 1.5.2 to work correctly.

Let me know if you still have these problems after the update.



Dear Caridad,

I updated to views 1.4.1 and I am happy to report that Bug2 works rendering the [wpv-if evaluate="post_password_required( null ) = '1'"] shortcode as intended.

Bug 1 still persists in 1.4.1 and the behavior is as described on previous post.



Dear Ioannis

I tested this with yesterdays release and its working fine here on my server: Types 1.5.3 and Views 1.5

When you enter the password, WordPress is saving it in a cookie. Can you try viewing the post after clearing your cookies?


The topic ‘[Closed] Password protected post type related bugs’ is closed to new replies.