Shortcode IDs outside of WYSIWYG Editor, any unique string?

Can shortcode IDs outside of the WYSIWYG editor implementation be any unique string? For example, I want to use something like: do_shortcode('[pwal id="whatever" description="My Content Section"]'.$content.'[/pwal]'); to try to embed some PWAL support into my theme. Is this the best practice for this? I don't see any conditional template tags available to access is_authorised() in the PWAL class.

Thanks!

  • Vaughan

    hiya

    thanks for posting.

    you can't use a closing shortcode tag in do_shortcode() like the way you have above.

    you would need to create a function.

    see http://stackoverflow.com/questions/11695610/how-to-add-a-closing-shortcode-to-wordpress-template-file

    http://wordpress.org/support/topic/do_shortcode-on-closing-isnt-working

    http://codex.wordpress.org/Shortcode_API

    hope this helps.

    thanks.

  • Pete T

    So I figured out I was barking up the wrong tree with the shortcodes, and attempted to use the function:

    function myfunct() {
    	global $pwal;
    
    	ob_start();
    	<content and html echoed here>
    	$out = ob_get_clean();
    
    	// PWAL Support
    	if ( function_exists( 'wpmudev_pwal' ) ) {
    	     echo wpmudev_pwal( $out );
    	} else {
    	     echo $out;
    	}
    }

    But this does not work for me. echo wpmudev_pwal( $out ); always just echoes the content with no restrictions regardless of global or post pwal settings.

    Then I also tried something along the lines of:

    function myauthfunct() {
    	global $pwal;
    	return $pwal->is_authorised();
    }

    For a basic conditional function, and still no output. Am I just missing something really stupid?

    Thanks!

    P.S. and I do have the function:

    function my_pwal_customization( ) {
         global $pwal;
         if ( !is_object( $pwal ) ) return;
         $pwal->load_scripts_styles();
    }
    add_action( 'template_redirect', 'my_pwal_customization', 2 );

    loaded up in my functions.php file.

  • Vaughan

    hiya

    sorry for the delay. shortcode should work with attributes, but as far as i'm aware, if the shortcode is not just [shortcode] but instead requires a closing tag [shortcode]content[/shortcode] then it has to be done slightly differently.

    however in this case, I really am not sure of the impact when using in the templates.
    though i have gone back over the post.

    you seem to have missed price from your shortcode above.

    [ppw id="12345678" description="protected pay content" price="0.5"]protected content[/ppw]

    i'm not sure if it will function correctly without a price being set.

    with regards to templates though, in the Dashboard > Pay with a Like > customization help

    you will see code examples there for using pawl outside of the editor content page.

    for example.

    For protecting html codes that you cannot add to post content, there is a template function wpmudev_ppw_html. This function replace all such codes with payment buttons and reveal them when payment is done. Add the following codes to the page template where you want the html codes to be displayed and modify as required. Also you need to use the bottom action function.

    <?php
    if ( function_exists( 'wpmudev_ppw_html' ) ) {
         $html = '<iframe width="560" height="315" src="http://www.youtube.com/embed/-uiN9z5tqhg" frameborder="0" allowfullscreen></iframe>'; // html code to be protected (required)
         $id = 1; // An optional unique id if you are using the function more than once on a single page
         $description = 'video'; // Optional description of the protected content
         $price = '1.50'; // Optional price for a single view. If not set, price set in the post will be applied. If that is not set either, Unit Price in the Global Settings will be used.
         echo wpmudev_ppw_html( $html, $id, $description, $price );
    }
    ?>

    Note: In this usage, enabled/disabled and method settings of the post has no significance. Such an html code will be fully protected. However, Accessibility Settings will be applied.

    Some custom post types use templates which take the post content directly from the database. For such applications you may need to use wpmudev_ppw function to manage the content.
    Example: Suppose that the content of a post type is displayed like this: <?php echo custom_description(); ?>. Then edit that part of the template like this:

    <?php
    if ( function_exists( 'wpmudev_ppw' ) )
         echo wpmudev_ppw( custom_description() );
    else
         echo custom_description();
    ?>

    For both of the above usages you must create a function in your functions.php to call necessary css and js files. Here is an example:

    <?php
    function my_ppv_customization( ) {
         global $ppw, $post;
         if ( !is_object( $ppw ) || !is_object( $post ) ) return;
         // Call this only for a post/page with ID 123. Change as required.
         // If you omit this line, js and style files will be added to all of your pages and caching will be disabled. So it is recommended to keep and modify it for the pages you are using.
         if ( $post->ID != 123 ) return;
         $ppw->load_scripts_styles();
    }
    add_action( 'template_redirect', 'my_ppv_customization', 2 );
    ?>

    If you want to apply your own styles copy contents of front.css to your theme css file and add this code inside functions.php of your theme:add_theme_support( "pay_per_view_style" ) OR copy and rename the default css file /wp-content/plugins/pay-per-view/css/front.css as /wp-content/uploads/pay-per-view.css and edit this latter file. Then, your edited styles will not be affected from plugin updates.

    hope this helps.

  • Pete T

    Thanks for that, but all that info is at the bottom of the PWAL Settings screen. Like I said earlier, it's not working for me. However, I think I am finding that this plugin doesn't really work as I expected. For example. If you have the following theme layout:

    [header]
    [post]
    [custom post footer]
    [widget 1]
    [widget 2]
    [footer]

    PWAL will successfully hide content in the [post] portion only. But say you have added a post footer action to your theme template, and have more content that needs to be hidden until "paid with a like" in [custom post footer], apparently there is no working solution to hide this in addition. I see the shortcodes work for very specific product catalog instances, or very specific custom post type instances, but rendering the shortcode to protect the output of [custom post footer] doesn't work in any variation i've tried.

    Or, say you want to hide post comments until paid with a like, or the [widget 1] until paid with a like, I just don't see any way of doing this?

    Is there no way for me to determine via a conditional tag, or another method, whether the currently viewed content is to be paid with a like or not, so that I may act upon it (hiding additional content, for example) if necessary?

  • Pete T

    Actually, I think I found a solution. Posting it here in case it helps others. I simply used is_cachable in the $pwal object to determine if the content should be visible or not, and made my own is_auhorised() function for use in my theme, and widget logic, etc.

    // Conditional function for use in widgets, etc.
    function is_authorised() {
    	global $pwal;
    	if ($pwal->is_cachable) {
    		// Not enabled for this content, so we're not
    		// limiting anyway
    		return TRUE;
    	} else {
    		// Enabled for this post
    		return FALSE;
    	}
    }

    @Paul, if you see this, can you please just verify that this class var is safe to use for this purpose and is consistent?

    THANKS!

  • Pete T

    @Paul

    So after some further testing, it looks like the is_authorised() class method filter you added does not consistently affect the is_cachable class var. The is_cachable var appears to be the single most important determining factor whether a page is visible, or must be paid with a like.

    When I filtered the is_authorised() to TRUE most of the time it made the page/post visible, a few times not. However, I now found what I think is a solid method. Using my is_authorised() function above as the conditional function for protecting content, I can do this to set visibility:

    function my_manual_override() {
    
    	// Retreive the pwal object
    	global $pwal;
    
    	// Do whatever I want here
    	// to get a TRUE/FALSE result
    	// to turn visibility ON/OFF
    	// respectively. E.g. TRUE
    	$result = TRUE;
    
    	// Manually set is_cachable to result
    	$pwal->is_cachable = $result;
    
    }
    add_action('thematic_abovecontent', 'my_manual_override', 8);

    And again, I use Thematic so hence the action.

    This seems more consistently effective. Unfortunately, it looks like filtering the is_authorised() class method result does not work properly. Sorry if my mis-reporting of its effectiveness earlier wasted your time. I'm still not certain why it seemed to work on 95% of my tests (until today when I caught the inconsistently). Maybe there is an error in the cachable() method.

    Anyway, hope this helps.
    --
    Pete

  • Paul

    @Pete T,

    it looks like the is_authorised() class method filter you added does not consistently affect the is_cachable class var.

    I think you are reading the plugin code incorrectly. The $pwal->is_cachable var is not effected or set via the $pwal->is_authorised() function. They both server two different roles.

    The is_cachable var appears to be the single most important determining factor whether a page is visible, or must be paid with a like.

    Again, I think you are misreading something in the plugin code. The $pwal->is_cachable var is simple to interface with cache plugin like W3 Total Cache, WP Super Cache, etc.

    So before I try and piece together the code snippets you have in the various entries above can you put all this together in a latest version post back to this thread so I can try this under my own dev environment?

  • Paul

    And to be clear the $pwal->is_authorised() function is just a utility to check if the current user is logged into WP and such. Does not for example check the PWAL cookie set when a user clicks the like button.

    And for the record I hate that the previous developer decided NOT to follow WP conventions and use the [/pwal] ending logic. So basically instead of the shortcode being process he is grabbing a hook on the content filter where the content body is parsed and checked for the [pwal]...[/pwal] pattern. Ug.

  • Paul

    @Pete T,

    I just setup a quick test on my own dev site. Running WP 3.5.1 single. With the default TwentyTwelve theme. In PWAL settings I've turned everything off/no. This will prevent PWAL process for my page content.

    Then edited the theme's content-page.php file. At the bottom after the closing </article> HTML I added this PHP code.

    if (is_page('test-long-page')) {

    ?><p>This is the special content section. See instructions below</p><?php

    if ( function_exists( 'wpmudev_pwal_html' ) ) {
    $html = 'This is some secret HTML code';
    $id = 999;
    $description = 'You shall not pass. Unless you like it first.';
    echo wpmudev_pwal_html( $html, $id, $description );
    }
    }

    Then to the theme's functions.php I added the template redirect function per the PWAL instructions.

    When I visit the page as a non-logged in user I see the "This is the special content section..." paragraph above the PWAL box. I don't see the 'description' text shown at all. When I click the FB like button the page reloads and I see the full hidden content text.

    I've tried this in a sidebar output as well and works the same.

    What am I missing?

    Next, I'm will enable PWAL for Pages (since I'm on a page) and see if I can get both options to function.

  • Paul

    @Pete T,

    Some further testing (with images!).

    So I've setup a page with a normal in-content PWAL wrapped around a content paragraph. And per my previous I've setup a section below the page template output of a custom PWAL using the wpmudev_pwal_html() function. See image #1.

    Both seem to function as designed. But I did notice one issue. When I like the custom PWAL the in-content PWAL shows as being liked. This is obviously wrong. See second image red arrow.

    But overall the custom wpmudev_pwal_html() function does work. Question is why does it not work on your end.

  • Pete T

    @Paul,

    I also tried your twentytwelve test above but get same results. Thats on a different server running 3.51 with all plugins but pwal disabled and using the default twentytwelve theme. I added the my_pwal_customization( ) function to the functions.php and your function to content-page.php with all PWAL settings disabled. I still just get exposed content.

    I also tried the shortcodes from the editor around a paragraph and its exposed with all settings off, but restricted with that page's pwal settings on (but test content in function is still exposed).

    I'm baffled as well.

    Also, regarding the use of is_cachable (from above posts), I figured if pwal decides the page can be cached, then pwal decided the page can be viewed based on all other circumstances, which is why I preferred it :slight_smile: But I get what you're saying, still not the correct method.

    Also, I didnt repost all my other functions here cause I figured it would just convolute things as we're now testing on a vanilla twentytwelve site.

    Do you want to a login to my dev site?

  • Paul

    @Pete T,

    At this point I'm not sure either. Seems that my vanilla solution should be reproducible under your environment. And I"m assuming you have cleared all cookies from your browser(s). Since PWAL sets cookies.

    Let's start with a screenshot of your PWAL settings. You mentioned you were calling a function like my version. But I need specifics. You are using the default theme. Make me a zip file and make it available to me so I can review the code changes.

    I try not to request login creds but might be handy. Please send a message with my name in the subject and a link to this thread along with the credentials through our contact form here:

    https://premium.wpmudev.org/contact/

    I’ll be happy to take a look and see what’s going on there. Thanks!

    Wait. This is a dev site? Is it behind a login screen? Meaning a user has to login to see content?

  • Pete T

    Hey Paul,

    No it is visible, not behind login. And I'll prep that stuff for you and send it on over tonight. The Firefox browser I use to test is set to clear the cache every time it is closed. Just damn weird. I've re-enabled some plugins that should not affect anything, they were network plugins I deactivated during testing that had no effect (Ultimate Branding and Infinite SEO).

    Thanks again for the help!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.