Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Alessandro Fazzi

    (@pioneerskies)

    @bcworkz your comments are always precious and spotted. Thank you very much.

    I’ll reveal a bit more around what I’m actually doing.

    I’m not trying to highjack the CMS’s approach about drafts, but I’ve implemented a 401 reply (header and template) aside of the default 404. In my scenario I need to differentiate between unpublished/nonexistent contents and existent but privately accessible contents, while WordPress by default (afaik) goes on 404 all the way down.

    So I set a header and will show static content: I’m not interested in accessing contents. **But** my logic never expected to have a situation where an anonymous user visiting a draft’s URL would make the queried_object populated.

    My expectation would be to **not** have the queried_object.

    Moreover when you say

    Since the public cannot normally view draft posts

    you’re right, but my test want to demonstrate that, even if the post won’t be viewed, the queried_object will get populated, thus I think everyone would be able to test that scenario with a simple var_dump(get_queried_object_id()) in theme’s main index.php file.

    Probably I should use other data/property to build my logic up (post count? a switch on get_post_status()?); but the fact per se let me think it was enough strange to be shared. 🙂

    Alessandro Fazzi

    (@pioneerskies)

    Hello everybody and thanks for your replies.

    I dived a bit in the problem, read your comments and I have to add some news and new bits to the scenario. Let’s try:

    * I’ve wordpress 5.2.2, no plugins, a theme with only an index.php file where i put an xdebug breakpoint in order to debug the **default unaltered global $wp_query** generated by WP
    * I’ve permalinks with nice urls on (postname)
    * I create a new page with a title
    * I publish the page, obtaining a nice url like http://localhost:8080/my-page
    * I navigate in an anonymouse browser window
    * the debugger stops and my control expression on $wp_query->queried_object_id shows me the correct post ID
    * back to the page edit, I switch back to draft
    * I open in another tab the preview link like http://localhost:8080/?page_id=2&preview=true
    * my control expression shows me null as expected
    * now I switch back to the previows anonym tab on the url http://localhost:8080/my-page and reload the page
    * control expression shows me the post ID!

    Note: this does not happen when url rewriting (nice urls) are turned off.

    I know this is a sort of an edge case, but this scenario is making my relying on get_queried_object_id() unreliable when an editor has bookmarked a public url and than switched back to draft.

    I think this is happening because when url rewriting is on the query to the draft page will anyway populate $wp_query->query_vars['pagename'], thus entering in this case when parsing the query: https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-query.php#L985

    The result is that queried_object is populated if an unauthenticated user is querying a “somehow existent” URL even if corresponding to a draft object.

    Keep in mind I do not need to solve problems about my business logic but to understand the reliability of queried_object property.

    Thanks again

    Thanks for your reply Ipstenu.

    I understood what you said. And I was talking about the same topic. But what code are you referencing? You’re talking about theme’s template, but I was focused on the default template used in case the theme hasn’t one.

    I’ve a site w/o custom comment template and WP is using the one produced by comment() or html5_comment(). If that code is anyway meant to be used, the flow is different there:

    <?php if ( '0' == $comment->comment_approved ) : ?>
            <p class="comment-awaiting-moderation"><?php _e( 'Your comment is awaiting moderation.' ); ?></p>
        <?php endif; ?>
    </footer><!-- .comment-meta -->
    
    <div class="comment-content">
        <?php comment_text(); ?>
    </div><!-- .comment-content -->
    
    <div class="reply">
        <?php comment_reply_link( array_merge( $args, array( 'add_below' => 'div-comment', 'depth' => $depth, 'max_depth' => $args['max_depth'] ) ) ); ?>
    </div><!-- .reply -->

    What am I loosing?

    Cheers

    I can confirm the packaging bug

    Alessandro Fazzi

    (@pioneerskies)

    I was asking if you and others, like JBird608 fallen in a problem like mine:

    I activated the plugin, it wrote down code to htaccess, but nothing happened and auth service pages stopped working.
    I was using some wordpress internal apache’s rewrite rules for nice url displaying, so I’ve merged that rules with the ones of the plugins; first the plugin’s ones than the wordpress’ ones. Just like this:

    before

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    # HIDE-LOGIN
    RewriteEngine On
    RewriteBase /
    RewriteRule ^logout wp-login.php?action=logout&_wpnonce=5ae547769e&hide_out_key=pbaAAi02H [L]
    RewriteRule ^login wp-login.php?hide_in_key=9aX0AaAK&redirect_to=http://greenline-int.com/wp-admin/ [R,L]
    RewriteRule ^admin wp-admin/?hide_admin_key=X6Q [R,L]
    RewriteRule ^register wp-login.php?hide_reg_key=aQR2l&action=register [R,L]
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-admin
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-login\.php
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/login
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/admin
    RewriteCond %{QUERY_STRING} !^hide_in_key=9aX0AaAK
    RewriteCond %{QUERY_STRING} !^hide_out_key=pbaAAi02H
    RewriteCond %{QUERY_STRING} !^hide_reg_key=aQR2l
    RewriteCond %{QUERY_STRING} !^hide_admin_key=X6Q
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    RewriteCond %{QUERY_STRING} ^loggedout=true
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    # END HIDE-LOGIN

    after

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    # HIDE-LOGIN
    RewriteRule ^logout wp-login.php?action=logout&_wpnonce=5ae547769e&hide_out_key=pbaAAi02H [L]
    RewriteRule ^login wp-login.php?hide_in_key=9aX0AaAK&redirect_to=http://greenline-int.com/wp-admin/ [R,L]
    RewriteRule ^admin wp-admin/?hide_admin_key=X6Q [R,L]
    RewriteRule ^register wp-login.php?hide_reg_key=aQR2l&action=register [R,L]
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-admin
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-login\.php
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/login
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/admin
    RewriteCond %{QUERY_STRING} !^hide_in_key=9aX0AaAK
    RewriteCond %{QUERY_STRING} !^hide_out_key=pbaAAi02H
    RewriteCond %{QUERY_STRING} !^hide_reg_key=aQR2l
    RewriteCond %{QUERY_STRING} !^hide_admin_key=X6Q
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    RewriteCond %{QUERY_STRING} ^loggedout=true
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    <em>RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d</em>
    <em>RewriteRule . /index.php [L]</em>
    RewriteRule ^index\.php$ - [L]
    <em>RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d</em>
    <em>RewriteRule . /index.php [L]</em>
    # END HIDE-LOGIN
    </IfModule>

    You can see that

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    was present before and are now doubled by hide-login.

    My final result is:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    # HIDE-LOGIN
    RewriteRule ^logout wp-login.php?action=logout&_wpnonce=5ae547769e&hide_out_key=pbaAAi02H [L]
    RewriteRule ^login wp-login.php?hide_in_key=9aX0AaAK&redirect_to=http://greenline-int.com/wp-admin/ [R,L]
    RewriteRule ^admin wp-admin/?hide_admin_key=X6Q [R,L]
    RewriteRule ^register wp-login.php?hide_reg_key=aQR2l&action=register [R,L]
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-admin
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-login\.php
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/login
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/admin
    RewriteCond %{QUERY_STRING} !^hide_in_key=9aX0AaAK
    RewriteCond %{QUERY_STRING} !^hide_out_key=pbaAAi02H
    RewriteCond %{QUERY_STRING} !^hide_reg_key=aQR2l
    RewriteCond %{QUERY_STRING} !^hide_admin_key=X6Q
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    RewriteCond %{QUERY_STRING} ^loggedout=true
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    # END HIDE-LOGIN
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    And it works…most of the time 😛

    One possible problem: if I’m in the wp-admin backend, the logout button works; if i’m on the front-end the logout button fails its job and the only way to log me out of there is to use http://address.ex/logout. But it depends on the directive:

    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-admin
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/wp-login\.php
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/login
    RewriteCond %{HTTP_REFERER} !^http://greenline-int.com/admin

    so if I’m not arriving from a wp-admin page my request fall into the rwrule:
    RewriteRule ^wp-login\.php http://greenline-int.com [L]
    I think…

    Overall problems seems to big small and solvable, but as it stands at the moment I could use the plugin mostly as inspiration of my custom .htaccess…

    🙂

Viewing 6 replies - 1 through 6 (of 6 total)