Forum Replies Created

Viewing 15 replies - 1 through 15 (of 21 total)
  • Thread Starter gmcinnes

    (@gmcinnes)

    Ok Frank. That’s good to know. I won’t bother aggregating the inline assets. It’s not worth the extra problems.

    I have another question: I seem to have a problem getting jQuery into the aggregation. Most everything else depends on it, so I need to make sure it gets into the aggregated file first. Is there any way to control the order of the files in the aggregation?

    Thread Starter gmcinnes

    (@gmcinnes)

    First, Frank, you deserve huge kudos and thanks for being so amazing at support. It’s very rare for even *paid* plugins to have the level of support you provide for free.

    I haven’t seen these issues myself. They’re transient even for people who are experiencing them. I don’t have a consistent reproduction case yet.

    Given what you said, am I right in thinking that there would be an autoptimize css file for each *page* that has slightly different css, and that those files wouldn’t change unless the underlying css for one of those pages does?

    Thread Starter gmcinnes

    (@gmcinnes)

    @lotlog. No idea. Vlad has the patch, but I’m not sure how long it will take him to check it out and apply it, if he agrees. I hope it’s soon.

    For my client’s sake, I’d prefer not to be spending time working on my own fork.

    Thread Starter gmcinnes

    (@gmcinnes)

    Ok. Here’s a patch to be applied to modules/checkers/http.php.

    Unfortunately I don’t know the implications this could have on load levels for others. As written after this patch, the code should only make a GET request as a retry if a HEAD request fails. But now it GET’s the whole amount rather than only the first 2048 bytes, so it’s possible it could be downloading much more.

    However, my intuition is that a) That retry shouldn’t happen in very many cases and b) even if it does, since it’s not downloading assets etc like a browser would, but just the HTML, the impact should be pretty negligable. Unfortunately I have no way to test it in the wild for everyone, but it fixes things in my environment with no measurable impact. Something to look out for if you use it though.

    --- http.php.old	2015-10-15 12:29:54.000000000 -0400
    +++ http.php	2016-01-05 10:41:09.000000000 -0500
    @@ -228,16 +228,12 @@
             $parts = @parse_url($url);
             if( $parts['scheme'] == 'https' ){
             	curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); //Required to make HTTPS URLs work.
    -            curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    -            $nobody = false; //Can't use HEAD with HTTPS.
    +            curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
             }
    
             if ( $nobody ){
             	//If possible, use HEAD requests for speed.
     			curl_setopt($ch, CURLOPT_NOBODY, true);
    -		} else {
    -			//If we must use GET at least limit the amount of downloaded data.
    -			$request_headers[] = 'Range: bytes=0-2048'; //2 KB
     		}
    
     		//Set request headers.

    Hi:

    Please see this thread.

    If you could post a reply there and help me convince the authors to apply a patch, that would be awesome.

    Thanks!

    Hi:

    Please see this thread.

    If you could post a reply there and help me convince the authors to apply a patch, that would be awesome.

    Thanks!

    Hi:

    Please see this thread.

    If you could post a reply there and help me convince the authors to apply a patch, that would be awesome.

    Thanks!

    Thread Starter gmcinnes

    (@gmcinnes)

    Oops. Wrong paste of the snippet there. Should be:

    <?php

    function get() {
    $ch = curl_init(“https://creativecommons.org/licenses/&#8221;);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); //Required to make HTTPS URLs work.
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    return $ch;
    }
    function get_with_range() {
    $ch = curl_init(“https://creativecommons.org/licenses/&#8221;);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); //Required to make HTTPS URLs work.
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $request_headers[] = ‘Range: bytes=0-2048’;
    curl_setopt($ch, CURLOPT_HTTPHEADER, $request_headers);
    return $ch;
    }

    function head() {
    $ch = curl_init(“https://creativecommons.org/licenses/&#8221;);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); //Required to make HTTPS URLs work.
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    curl_setopt($ch, CURLOPT_NOBODY, true);
    return $ch;
    }

    function test($fn) {
    $ch = call_user_func($fn);
    curl_exec($ch);
    $info = curl_getinfo($ch);
    curl_close($ch);
    var_dump($info);
    }

    test(‘head’);
    test(‘get’);
    test(‘get_with_range’);
    ?>

    Hey guys. I have the same issue. Not running on WPMU though. Any other resolutions? Do you have specifics? I can take a look, or provide a patch if you can point me to anything you’ve learned so far.

    Thread Starter gmcinnes

    (@gmcinnes)

    Hmm. I’m not sure this will do the job. The point is that the string to be sent *already is* valid UTF-8. But there are some UTF-8 chars that are not valid XML. Specifically, there are UTF-8 control plane chars that need to be removed.

    I suspect your approach will leave those control plane chars in place.

    Thread Starter gmcinnes

    (@gmcinnes)

    Ok. If you do that beware that there are other bugs lurking in the current 2.1.1 SOAP API version. See my other patches in this forum. Or bug Zack to apply them 🙂

    Thread Starter gmcinnes

    (@gmcinnes)

    Sorry armando. I really don’t know. I don’t use the web-to-lead style interface. Using the SOAP API everything “just works” now. At least as far as checkboxes go 🙂 Sorry I couldn’t be more help.

    Thread Starter gmcinnes

    (@gmcinnes)

    Here is a patch for this against 2.1.1

    ---   salesforce-api.php	2012-11-27 14:37:45.000000000 -0500
    +++ salesforce-api.php	2012-11-27 16:39:48.000000000 -0500
    @@ -1,4 +1,67 @@
     <?php
    +/**
    + * Pinched from: http://www.consil.co.uk/files/2010/02/clean_utf8_xml_string.php_.txt
    + * Name: clean_utf8_xml_string
    + * Purpose: to remove or transform bytes or characters in a UTF-8 stream that
    + * will cause problems when parsed as XML. Not every UTF-8 character is a valid
    + * XML character.
    + * Author: Jason Judge
    + * Licence: GPL V3
    + * Created: 2010-01-07
    + *
    + * Takes a UTF-8 string and replaces any character that is not valid in an XML document.
    + *
    + * Note this does not require PCRE unicode libraries, which are often a problem on hosted
    + * servers.
    + *
    + * Inspiration taken from http://stackoverflow.com/questions/1401317/remove-non-uft8-characters-from-string
    + */
    +
    +function clean_utf8_xml_string($matches)
    +{
    +    // This part handles the callback.
    +    if (is_array($matches)) {
    +        if (isset($matches[1]) && $matches[1] !== '') {
    +            // Compatibility characters.
    +            // Return as-is for now, but could map it to another character.
    +            return $matches[1];
    +        } elseif (isset($matches[2]) && $matches[2] !== '') {
    +            // Valid UTF-8 for XML
    +            return $matches[2];
    +        } elseif (isset($matches[3]) && $matches[3] !== '') {
    +            // Invalid single-byte characters.
    +            // Instead of removing these, we can assume they are another character set and map them.
    +            // Assume they are ISO8859-1 for now, but this could be parameterized.
    +            return iconv('ISO-8859-1', 'UTF-8', $matches[3]);
    +        } elseif (isset($matches[4]) && $matches[4] !== '') {
    +            // Control characters - no mappings - so return a replacement character.
    +            // You may wish to return something different, or nothing at all.
    +            return '?';
    +        }
    +    }
    +
    +    // This part handles the first instance.
    +    if (is_string($matches)) {
    +        return preg_replace_callback('/'
    +            // Ranges recommended to avoid - "compatibility characters".
    +            // See http://www.w3.org/TR/REC-xml/ for the character ranges.
    +            . '([\x7F-\x84]|[\x86-\x9F]|[\xFD][\xD0-\xEF]|[\x1F\x2F\x3F\x4F\x5F\x6F\x7F\x8F\x9F\xAF\xBF\xCF\xDF\xEF\xFF\x10][\xFF][\xFE\xFF])'
    +
    +            // Broad valid UTF-8 multi-byte ranges.
    +            . '|([\x09\x0A\x0D]|[\x20-\x7F]|[\xC0-\xDF][\x80-\xBF]|[\xE0-\xEF][\x80-\xBF]{2}|[\xF0-\xF7][\x80-\xBF]{3})'
    +
    +            // Invalid single-byte characters which are likely to be extended ASCII and may be convertable to UTF-8 equivalents.
    +            . '|([\x80-\xBF]|[\xC0-\xFF])'
    +
    +            // Fall-through - whatever is left, which should be single-byte control characters.
    +            . '|(.)'
    +
    +            // If this is used as a static method, then replace __FUNCTION__ with __CLASS__ . '::' . __METHOD__
    +            . '/', __FUNCTION__, $matches
    +        );
    +    }
    +}
    +
     /*
     Plugin Name: Gravity Forms Salesforce API Add-On
     Plugin URI: http://www.seodenver.com/salesforce/
    @@ -1359,16 +1422,17 @@
                     }
                 }
             }
    -
    +        $merge_vars = array_map(function($merge_var) { return clean_utf8_xml_string($merge_var); }, $merge_vars);
    +
             $account = new SObject();
    
             $account->fields = $merge_vars;
    
             // Object type
             $account->type = $feed['meta']['contact_object_name'];
    -
    +
             $result = $api->create(array($account));
    -
    +
             $debug = '';
             if(self::is_debug()) {
                 $debug = '<pre>'.print_r(array(
    Thread Starter gmcinnes

    (@gmcinnes)

    Armando: What I included up there is a diff that helped Zack fix the problem (I hope).

    But he’s added much more than my diff did. This issue is already solved. You should upgrade the plugin to the latest.

    Thread Starter gmcinnes

    (@gmcinnes)

    by the way, the error message if you get bit by this would look something like:

    PHP Fatal error: Uncaught SoapFault exception: [soapenv:Client] An invalid XML
    character (Unicode: 0xb) was found in the element content of the document.

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