mimetic

You can definitely export IPTC and EXIF from Adobe Lightroom (using LR/Transporter) and import using one of many CSV importer plugins. I’m doing it right now.

Well, the answer seems to be that the “bad” entries in media were causing all kinds of trouble, and once those were removed, everything started to work. I had the cloudfront working, AND wasn’t able to connect to it…until I removed those bad media files.

OK, this is weird. I found client had (somehow!) created media entries that weren’t real. That is, there were media entries that had URL’s like “my-nice-fish”. They were actually parts of hyperlinks (but had no file type, e.g. html or jpg).
I deleted these, and now the site is working.

AND, now I’m able to fill in the Cloudfront settings into the “Other CDN Provider”.

Perhaps something in the system goes crazy when there are bad media attachments?!?!

I looked for that (read one of your earlier replies to someone), so I checked first. It is working, all right! I just went to https://d2k8js1hnpfse5.cloudfront.net/ it worked fine.

Or, try this:
https://d2k8js1hnpfse5.cloudfront.net/wp-content/uploads/2016/10/photo-1455819413567-ef04b7e1fe3d.jpg

Here it is:
d2k8js1hnpfse5.cloudfront.net

FYI, when I enter the CDN Url in WPFC without https://, I get this error: cURL error 28

Other sites are using identical setups without trouble.

Sucuri shows no hacking on my site.

Finally, some PHP script from the site is using 25% CPU on my server! I can’t figure out which….

• This reply was modified 8 years, 4 months ago by mimetic.

I am getting exactly the same error. Also a new problem. I’ve turned off all plugins, and that doesn’t help.

Change the page caching option in W3TC from enhanced to basic disk cache. Look on the Page Cache tab. Then the “late-init” will show up.

This works:
In assets/frizzly.js:

function q() {
            var b = a(this),
                c = b.attr(frizzly.attr.type),
                d = b.parent(String.format("div.{0}", frizzly.cssClass.container)).attr(t.index),
                e = a(String.format('[{0}="{1}"]', t.index, d)),
                h = new frizzly.baseClasses.ClickHandlerArg;

            return h.url = f(e), h.imageAttributes.src = l(e), h.imageAttributes.alt = e.attr("alt"), h.imageAttributes.title = e.attr("title"), h.imageAttributes.description = ( e.attr(frizzly.attr.imageDescription) ? e.attr(frizzly.attr.imageDescription) : e.attr("data-image-description").replace('<p>', '').replace('</p>', '').replace('<br />', '\n')), h.imageAttributes.caption = e.attr(frizzly.attr.imageCaption), h.articleAttributes.title = g(e), frizzly.buttons.handleClick(c, h);
/*
            return h.url = f(e), h.imageAttributes.src = l(e), h.imageAttributes.alt = e.attr("alt"), h.imageAttributes.title = e.attr("title"), h.imageAttributes.description = e.attr(frizzly.attr.imageDescription), h.imageAttributes.caption = e.attr(frizzly.attr.imageCaption), h.articleAttributes.title = g(e), frizzly.buttons.handleClick(c, h)
*/
        }

This is a real big problem…with the above fix, W3TC starts parsing the code between the mfunc tags. However, now I see the second issue — you use an “eval()” and your code will only work with PHP code in the mfunc, not HTML code.

AdRotate inserts HTML text, not PHP. That means AdRotate won’t work with the caching.

Argh!!!! What to do?

Perhaps one could use a short Javascript loop, basically the JS code I modified, entered in the custom JS area? Not sure how that works.

I can see a benefit to being able to handle the “standard” Jetpack galleries. As a coder, I can also understand how damned annoying it is to have to do something special like that.

Here is a fix to the javascript at line 413 of frizzly.js. Note, I had to use frizzly.min.js, and unpack, so your line number may vary.

I have changed where “frizzly.attr.imageDescription” gets its data to include “data-image-description”.

Not elegant at all, esp. the removal of the HTML from the description.

return h.url = f(e), h.imageAttributes.src = l(e), h.imageAttributes.alt = e.attr("alt"), h.imageAttributes.title = e.attr("title"), h.imageAttributes.description = ( e.attr(frizzly.attr.imageDescription) ? e.attr(frizzly.attr.imageDescription) : e.attr("data-image-description").replace('<p>', '').replace('</p>', '').replace('<br />', '\n')), h.imageAttributes.caption = e.attr(frizzly.attr.imageCaption), h.articleAttributes.title = g(e), frizzly.buttons.handleClick(c, h);

I can confirm that a picture which is inserted into a page works fine. That is, a picture NOT in a gallery, but directly inserted into the page text area works.

The attribute “data-frizzlyimagecaption” does appear in the image inserted into the page.

“data-frizzlyimagecaption” does NOT appear as an attribute of an image in a tiled gallery, using Jetpack gallery. So, I figure Frizzly isn’t correctly marking images coming out of the Jetpack gallery.

However, rather than worry about that (a slower method anyway), it turns out the data is there, ready to to use!

Regarding getting values:
If Frizzly were to use the “data-image-meta”, the ‘caption’ info from the original, imported image is there. Not good, since I can’t change it in WordPress.

If Frizzly were to use the “data-image-description” attribute,?it could get the description from that, as simple HTML (i.e. strong, italic, etc). This seems the best way to go.

There is also the div just following the image, of class=”tiled-gallery-caption”. That contains the WordPress caption. However, not sure that’s a reliable source, might disappear or move?

No joy. I’m showing the pictures in a ‘mosaic’ using the JetPack gallery; perhaps that where the problem lies?

The pop-up window does work, but it still shows the picture’s title, not caption.

The javascript refers to the picture’s caption, so that’s the right script (not an older, cached script).

However, the caption info is in the HTML code —?that worked.

<img data-attachment-id="342" data-orig-file="https://f3d2f3313d45b3a6cec5-9cccc87e0594dcb7d2bd367a3d3ec10d.r41.cf1.rackcdn.com/wp-content/uploads/2014/02/131217-dg-174703.jpg" data-orig-size="768,1024" data-comments-opened="1" data-image-meta="{"aperture":"3.5","credit":"David I. Gross","camera":"E-M5","caption":"Syrian refugee child at a the Free Syria school.","created_timestamp":"1387253196","copyright":"Copyright \u00a9 David I. Gross","focal_length":"45","iso":"200","shutter_speed":"0.005","title":"Syrian Refugee Child"}" data-image-title="Ghaidaa’" data-image-description="<p>Syrian refugee child at a the Free Syria school.</p> " data-medium-file="https://f3d2f3313d45b3a6cec5-9cccc87e0594dcb7d2bd367a3d3ec10d.r41.cf1.rackcdn.com/wp-content/uploads/2014/02/131217-dg-174703-225x300.jpg" data-large-file="https://f3d2f3313d45b3a6cec5-9cccc87e0594dcb7d2bd367a3d3ec10d.r41.cf1.rackcdn.com/wp-content/uploads/2014/02/131217-dg-174703.jpg" src="https://i2.wp.com/insideoutsideproject.org/wp-content/uploads/2014/02/131217-dg-174703.jpg?resize=326%2C435" data-original-width="326" data-original-height="435" title="Ghaidaa'" alt="" style="width: 319px; height: 426px;" data-recalc-dims="1">

Here’s the short codes from my page (not post!).

[gallery link="none" type="rectangular" ids="618,617,616,348,347,346,345,344,343,342,341" orderby="rand"]

Here’s the offending page:
https://insideoutsideproject.org/mosaic

Hi, the description is NOT appearing when I try to “pin” an image. No matter what I do, I get the image title.

Also, there exist both “Caption” and “Description” fields for an image. Since my files have “captions”, perhaps because they come from Adobe Lightroom, I really need to be able to use that field, not description!

Here’s the gallery I’m trying to get to work.

(Note, the button images don’t work because I use a W3 CDN for caching, and your plugins images don’t get cached without explicitly mentioning them. Then, they require uploading to the CDN. Another issue.)