It fixed it.

Thanks.

The images are optimized for web but with say 100 images at 500kb it is still 50mb total per say on the page at once. It is curious how if the same images load super fast on page as static images all at once, they are so much slower in the masonry script.

Oh well I will play with the images and see if I can get it faster. The trouble for everyone wanting to display large images, if you want to open 1500 pixel images in light box you have to upload them that large so its available. I just wish the masonry script only loaded smaller thumbnail images like your gallery script does, and then feeds the full size image upon request from the lightbox. that would presumably fix the issue, maybe. But that is only an uneducated observation/assumption.

————————————-

On another note. when I inspect my page with the masonry gallery an look under resources I see 1 of each image that is in the gallery. The full size image. And if I drag and drop on any of the thumbnails visible in the gallery the image that is copied to the desktop is the full size image. you can also open the lightbox and drag and drop that image to and it is the full size image.

The behavior on your demo is different. If you go to kriesi-shortcodes-masonry gallery and inspect that page and look at the resources there are 2 of each image loaded one full size at 1030 px for example and then a thumbnail at 705px for example. and if you simply inspect the code of the gallery you see that the smaller thumbnail is being loaded in the gallery by default. If you drag and drop this image off you get the smaller thumbnail as expected. But the big difference on your sample is that if you open the lightbox you get the full res image, great. It however is not drag and dropable.

So big questions.
1. Why is your lightbox image not drag/drop compatible and the one in the them is?
2. Your sample is the optimal behavior and why it is likely faster. presenting thumbnails and only full res upon request from the lightbox. How do we get this same behavior in our themes. your masonry script must be different than the one loaded in the theme pack for 2.4.1

Can this be addressed please. thankyou

Hi Yigit

Thanks, that fixed it. The issue was that I was using a child theme and hadn’t updated footer.php since a few updates a go.

Regards,
Rob

Actually, when I put #top before the css it works ok so I guess something is stopping it unless I put top. Anyway, all ok now, thanks again

Andrew

Hey, please close this topic.

If anybody have the same problem, I found the following method.

Open your 404.php (inside Enfold) and insert the following code on top:

<?php
header(“HTTP/1.1 301 Moved Permanently”);
header(“Location: “.get_bloginfo(‘url’));
exit();
?>

Now it redirects every 404 to http://domain.com

Erase it after Maintenance is finished…

p.s. I’m not using LayerSlider but the Fullscreen Slider; And furthermore – the Bar stops working (only the label and the background are seen) for the same reason.

• This reply was modified 12 years, 2 months ago by eliuserman.

Yes, that’s the right URL Kriesi.

I installed the latest version of Enfold by FTP, copying the entire new Enfold folder over the old installation in the site’s Themes directory.

This morning, on Chrome (Mac and Windows) I see:

As each new image appears in the slider, it makes text and images below, in the main content area of the page, nudge very slightly to left and then back. All of the text lightens in colour slightly for a second. This only happens to content in the second (and greater) columns – first column content on the left border does not seem to be affected. Once all of the images in EasySlider have run through once, this problem stops. But if I refresh the page, then it all happens again.