Forum Replies Created

Viewing 15 replies - 1 through 15 (of 41 total)
  • Yo homeslice, I’m not the plugin author, but the plugin author does provide documentation. Here’s the CSS reference styling doc:
    https://agegate.io/docs/styling/css-reference

    During restriction, before the Age Gate validates the visitor, the <body> element will have the .age-restriction class. After the visitor submits the form and her age is validated, the .age-restriction class will be removed and .age-passed will be added. Then you can unblur all your hoo-hoos and ha-has.

    -Paul Mighty

    Thread Starter PaulMighty

    (@paulmighty)

    I think I figured it out with a bit of self-service ??

    Adding an after_setup_theme action gets the custom validation working:

    
    add_action('age_gate_add_validators', 'my_recaptcha_validation' );
    add_action( 'after_setup_theme', function() {
    	do_action('age_gate_add_validators');
    } );
    

    Seems it need to run do_action again after the theme setup. Maybe add to the docs?

    Thanks for a great plugin ??

    Cheers,
    -Paul Mighty

    Thread Starter PaulMighty

    (@paulmighty)

    Benjamin, your question was answered in my second post to this thread. Hacking the plugin code to pass NULL does fix the issue, but I figured Photocrati might want to explore why there was an issue in the first place.

    Photocrati, the contract I am working under does not allow me to provide access to third parties, sorry. If you have specific questions, I’m happy to provide details.

    Thanks,
    -Paul

    Thread Starter PaulMighty

    (@paulmighty)

    So I rigged it up to have validate_ajax_request return $sec_token and I then capture what it returns with output buffering on a var_dump like this:

    ob_start();
    var_dump($this->validate_ajax_request( NULL , TRUE));
    $retval['error'] = ob_get_clean();

    $sec_token returns this raw output on failed image upload:

    object(C_Wordpress_Security_Token)#1681 (12) {
      ["context"]=>
      bool(false)
      ["adapted"]=>
      bool(true)
      ["_mixins"]=>
      array(4) {
        ["Mixin_Security_Token"]=>
        object(Mixin_Security_Token)#1680 (2) {
          ["object"]=>
          *RECURSION*
          ["method_called"]=>
          NULL
        }
        ["Mixin_Security_Token_Property"]=>
        object(Mixin_Security_Token_Property)#1710 (4) {
          ["_action_name"]=>
          NULL
          ["_args"]=>
          NULL
          ["object"]=>
          *RECURSION*
          ["method_called"]=>
          NULL
        }
        ["Mixin_Wordpress_Security_Token"]=>
        object(Mixin_Wordpress_Security_Token)#1676 (2) {
          ["object"]=>
          *RECURSION*
          ["method_called"]=>
          NULL
        }
        ["Mixin_Wordpress_Security_Token_MVC"]=>
        object(Mixin_Wordpress_Security_Token_MVC)#1678 (2) {
          ["object"]=>
          *RECURSION*
          ["method_called"]=>
          NULL
        }
      }
      ["_mixin_priorities"]=>
      array(4) {
        [0]=>
        string(34) "Mixin_Wordpress_Security_Token_MVC"
        [1]=>
        string(30) "Mixin_Wordpress_Security_Token"
        [2]=>
        string(29) "Mixin_Security_Token_Property"
        [3]=>
        string(20) "Mixin_Security_Token"
      }
      ["_method_map_cache"]=>
      array(2) {
        ["init_token"]=>
        string(29) "Mixin_Security_Token_Property"
        ["check_current_request"]=>
        string(20) "Mixin_Security_Token"
      }
      ["_disabled_map"]=>
      array(1) {
        ["check_request"]=>
        array(0) {
        }
      }
      ["_interfaces"]=>
      array(2) {
        [0]=>
        string(11) "I_Component"
        [1]=>
        string(16) "I_Security_Token"
      }
      ["_throw_error"]=>
      bool(true)
      ["_wrapped_instance"]=>
      bool(false)
      ["object"]=>
      *RECURSION*
      ["_action_name"]=>
      NULL
      ["_args"]=>
      NULL
    }

    Thoughts?

    -Paul

    Thread Starter PaulMighty

    (@paulmighty)

    Where do you suggest we add var_dump($sec_token)? The upload action occurs in an AJAX call, so nothing will display on the page if I add it to validate_ajax_request.

    -Paul

    Thread Starter PaulMighty

    (@paulmighty)

    As a follow up, this line in package.module.nextgen_addgallery_page.php:
    if ($this->validate_ajax_request(‘nextgen_upload_image’, TRUE)) {

    …called the validate_ajax_request method in package.module.ajax.php, which is written as follows:

    public function validate_ajax_request($action = NULL, $check_token = false)
        {
            // TODO: remove this. Pro 2.1's proofing calls validate_ajax_request() with a null $action
            if (!$action) {
                return TRUE;
            }
            $valid_request = false;
            $security = $this->get_registry()->get_utility('I_Security_Manager');
            $sec_actor = $security->get_current_actor();
            $sec_token = $security->get_request_token($action);
            if ($sec_actor->is_allowed($action) && (!$check_token || $sec_token->check_current_request())) {
                $valid_request = true;
            }
            return $valid_request;
        }

    If we update:
    if ($this->validate_ajax_request(‘nextgen_upload_image’, TRUE)) {

    …to:
    if ($this->validate_ajax_request( NULL, TRUE)) {

    …the file successfully uploads and the permission error is not displayed. Can you shed some light on what’s going on? I haven’t had time to dig through the dependent functions in validate_ajax_request. Are we experiencing token errors or something?

    Thanks,
    -Paul

    We are experiencing the same issue as described by OP. Even logged in as Administrator and when wp-content/gallery/* permission are set to 777 (which is obviously not appropriate for a production server). These errors only began appearing after we upgraded to NextGEN version 2.1.0. We even tried dropping the ten “Roles & Capabilities” in Setting down to “Subscriber” and uploading still did not function.

    -Paul

    I ran into this issue as well. It could be the server making an erroneous calculation or because we’re running WP Super Cache and using a CDN—not really sure. Anyway, here’s what I did to fix the issue, which will work if you have a fixed width:

    function change_post_content( $post_content, $attachment_id ) {
       $medium  = wp_get_attachment_image($attachment_id, 'medium');
       $medium = str_replace( 'width="1"', 'width="100"', $medium );
       $medium = str_replace( ' height="1"', '', $medium );
       $post_content .= $medium;
       return $post_content;
    }

    The two new lines of code finds and replaces the width and height settings if they equal “1”. Just update width=”100″ on line 3 to whatever size you’re trying to achieve. Let me know if that helps or if you’ve created an alternate solution.

    -PaulMighty

    Thread Starter PaulMighty

    (@paulmighty)

    Sucessfully narrowed down to issue to a conflict with the CDN Sync Tool. This plugin has been all over the map and for month we have been using the forked—and by far most stable—version here:
    https://github.com/WDGDC/CDN-Sync-Tool

    When the plugin is activated along with WP Super Cache’s caching enabled, cached pages display on first load, but no content is returned on each subsequent load. When the CDN Sync Tool plugin is disabled, all cached pages load as expected.

    Much appreciation to anybody interested in helping troubleshoot this issue. I have posted a issue to the CDN Sync Tool Git repo here:
    https://github.com/WDGDC/CDN-Sync-Tool/issues/13

    -PaulMighty

    Updating to NextGEN Gallery plugin version 2.0.66 fixed the issue for our multisite install. Always backup your database before upgrading plugins!

    -PaulMighty

    Thread Starter PaulMighty

    (@paulmighty)

    Nice, looking forward to it!

    -PaulMighty

    Also receving this error with version 2.0.3 on a Rackspace Cloud Site:

    function (){if(l){var t=l.length;(function i(t){x.each(t,function(t,n){var r=x.type(n);"function"===r?e.unique&&p.has(n)||l.push(n):n&&n.length&&"string"!==r&&i(n)})})(arguments),n?o=l.length:r&&(s=t,c(r))}return this}

    -PaulMighty

    @shauno: not sure I agree with that comparison as it relates to the issue.

    If the bug can’t be fixed due to lack of time or resources, please update your plugin description and documentation to state that it is incompatible with shared hosting. I mean, it CRASHES the entire site without warning and without a fallback or explicit debug info. I’m sure you care about the people using your plugin—you actively supporting it here (kudos)—so I expect you’re not wanting to crash somebody’s site, leaving them high and dry. When you post a plugin for public download, you’re asking people to trust your work and you don’t seem like the type that would want to betray that trust.

    Cheers,
    -PaulMighty

    I respectfully disagree that this is a viable solution—updating Apache config is not an option for sites hosted in a shared environment where access to the server config is not available.

    -PaulMighty

    @kzoo – I read the article you linked to and it says nothing about conditional statements conflicting with get_template_part. Maybe you’re suggesting something like this?

    get_template_part( 'modules/dashboard', $some-var );

    -PaulMighty

Viewing 15 replies - 1 through 15 (of 41 total)