Support » Plugin: BJ Lazy Load » [FIX] Incorrect data-src encoding for non-english characters in filename

  • Resolved testsiteoop



    First of all, a big thank you for such a nicely written and very functional plugin. I’m an amateur web developer just starting with WordPress, and found your code, both php and javascript, to be very descriptive and clear to understand.

    I was having a problem when the “hiDPI” and “responsive” images options were active (both, or either one by themselves). Images with non-english characters in their filenames (e.g. ñ, á, é, ó, among others) were not being displayed at all.
    A closer look revealed that the src parameter passed to thumb.php was incorrectly encoded for these characters. in fact, loading the image by itself in a new tab showed a TimThumb error “Could not find the internal image you specified.”

    I traced the source of the problem to line 36 of the file js/bj-lazy-load.js:
    imgurl = BJLL.thumb_base + escape( srcimgurl ) + '&w=' + loadimgwidth;
    I noticed the use of the escape() javascript funcion, which, according to some googlin’ was deprecated in JavaScript version 1.5. The use of encodeURI() or encodeURIComponent() is recommended instead, depending on the intended use:
    I changed the previous line to:
    imgurl = BJLL.thumb_base + encodeURIComponent( srcimgurl ) + '&w=' + loadimgwidth;
    And i’ts now working for me without any issues. “ñàâáçü©åœ®.jpg” gets downscaled and shown as expected.

    If you find that the above is correct and solves the issue, would you consider updating the plugin?

    Again, THX for such a nice piece of software. It works very good and transparent.

    PD: for anyone in need of a quick fix to this particular issue:

    1. Find the file “bj-lazy-load/js/combined.min.js”.
    2. in line Nº20, find the spot where it says thumb_base+escape(l)
    3. replace the call to escape() so it reads thumb_base+encodeURIComponent(l)

Viewing 5 replies - 1 through 5 (of 5 total)
Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘[FIX] Incorrect data-src encoding for non-english characters in filename’ is closed to new replies.