dawilson

Given my lack of PHP experience, I strongly suspect I’ll be living with this one for a while. If you feel like raising the bug report, that would be fantastic (given that you can talk intelligently about the library as an actual user).

Ah, I see – sorry. I assumed that Exifography itself was parsing the metadata out of the files. I guess this means that the debug has to travel deeper into the stack. If I can find some time, I’ll research the PHP module you mention and try playing with it locally to see what it does.

Yes, it is possible to exclude various metadata fields on export from Lightroom. I’m still having a hard time with this given that Apple Preview can read the correct information from the file after I download it from my site, though. The content is obviously not corrupted given that and my code debugging gut instinct is still yelling that this must be a bug (perhaps a subtle one) in the parser as a result. What results do you get when you process the file that I originally sent (from the site)? Have you looked at the structure of the metadata within this and stepped through your parser checking to make sure that the field lengths are handled properly, for example?

Once it has uploaded, you’ll find the original raw file at https://www.dropbox.com/s/lcqygnmsbn45pfa/Founders_Day-3194.NEF?dl=0. From my perspective, every single picture goes through Lightroom and, given that the information is parsed correctly by other applications, I strongly suspect you’ll find the error isn’t in the original file but in the code that is reading it.

The “unprocessed” version of the image looks to have the same metadata when I compare it to the one I downloaded from the site but, that said, I’ve not compared the binary. I’ve uploaded it to https://www.dropbox.com/s/dzzxy29gvuzj2vh/Founders_Day-3194.jpg?dl=0 for you to take a look at. Note that this has been through Lightroom so it’s not really “unprocessed” but it is pre-Wordpress.

Kristarella,

Thanks. That explanation seems perfectly reasonable but, in my case, the post contains nothing at all except the featured image. Although I uploaded multiple images to the media library while editing my post, I never added any of them to the post other than picking the featured shot.

I would expect the plug-in to show data from the featured image that applies when the post is saved or published. As it stands, it appears to pull data from the first image uploaded to the media library during the time the post is being edited, regardless of whether or not that image actually ends up in the post. I also notice that if I set the featured image to one that I uploaded prior to creating the post, no EXIF data is displayed unless I manually add the relevant tag.

For now, I’ll turn off automatic display and add the correct tag manually. If you make any changes to this to correct (or “modify” depending upon your perspective ?? ) the behaviour, please let me know and I’ll turn it back on again.

This may be helpful. I’ve just noticed that the incorrect EXIF data is taken from the image immediately following the Perkins Cove image in my Media Library. I uploaded a batch of images while creating the Perkins Cove post and it appears that the automatically generated EXIF was taken from the last uploaded image rather than the one that I actually chose to use in the post.

I am having exactly the same problem on my WordPress 2.7.1 blog and have also tried explicitly defining CUSTOM_TAGS to be true with no luck. All HTML entered in comments is escaped and as a result displays wrongly on the page. Attempts to edit the comments from the dashboard result in exactly the same text escaping.

Can anyone offer any suggestions on why kses.php doesn’t seem to be doing it’s job for me?

This is 2.7 (no minor version number noted) and it’s 100% repeatable on my blog unfortunately. Was this a known but on 2.7 that was fixed between there and 2.76? I’ll upgrade but would like to have some reason to believe this would fix the problem before taking the risk (sorry – I have no idea how traumatic a WP upgrade is since I’ve only just started using it).