Thanks for the kind words and for your interesting question.
You wrote “GPS tags are not read out of it.” How are you reading/using the GPS tags and where do you expect to see them?
You wrote “Debug output confirms” – can you say what tool you used to get the excerpts?
I am not sure how to account for the difference, but if you have the same image in both places the first step is to compare the actual files to make sure some plugin or editing tool has not altered the file on the live site. There are lots of tools that strip some or all metadata when they operate on an image file.
If that’s not the problem I would be happy to analyze one or more images to see what’s in them and how MLA uses it. Can you post a link I can use to get a copy of the file(s)?
Thread Starter
aldorr
(@aldorr)
Hi David,
Thanks for your reply.
In the MLA Custom Fields Settings I set up the following mappings:
meta:image_meta.latitude template ([+exif:GPS.LatitudeSDD+])
meta:image_meta.longitude template ([+exif:GPS.LongitudeSDD+])
On my local setup, this reads the latitude and longitude out of the image’s EXIF GPS info and adds it to the WP attachment. This is what I expected it to do on the live site as well.
The debug output came from the Debug Tab in the MLA Plugin (the WP Debug Log). I set “MLA Reporting” to 16, and it output an array of metadata for me to peruse. It looks like it’s supposed to be the full metadata in the image’s EXIF.
Here’s a zip file with one image that works both locally and live, and one which doesn’t.
There is also some debug output for the one which doesn’t work live and does work locally.
https://www.dropbox.com/s/arsn9ucn1mz0yfr/EXIF-images-debug.zip?dl=0
Hope this helps. The only other plugin that might be intercepting images somehow is the Wordfence plugin. But even with that deactivated, I get the same issue.
Any ideas? Thanks,
aldorr
Thanks for your update and for taking the time to set up the debug tab, gather the data and post the image files and debug information.
I have not analyzed the image files but I did have a look at the debug information. Simply put, the live image and the local image are not the same. The 3078 mla_fetch_attachment_image_metadata exif_data =
entries give the raw EXIF data returned by the PHP function that extracts it from the file; not an MLA function. In the “FILE” section you can see that the “SectionsFound” are different; GPS, THUMBNAIL and INTEROP sections have been removed from the “live” version. The EXIF section shows many more values in the local file not present in the live file.
As far as I can tell MLA is accurately processing the metadata extracted from the file by the PHP function. The GPS data is in the local copy but not the uploaded copy.
Your ZIP archive contains just one copy of the “WorksLocally-NotLive” file. Have you tried using the Media/Assistant “Download” rollover action (or FTP access) to get a copy of the live file and re-processing it on the local system? It would be useful to compare the live and local versions of the file to find their differences. If you can give me both versions I can investigate further. Thanks for your help with this issue.
Thread Starter
aldorr
(@aldorr)
Thanks for checking on that and explaining what the SectionsFound area means. Oddly, when I re-download the file, either via ftp or from the Media Assistant “Download” button, my local system still finds the Latitude and Longitude values.
Here’s a link to the re-downloaded file. It looks the same to me.
(The file has the same name, but it really is the one downloaded. Notice different creation dates.)
Thanks again!
Thanks for posting a link to the downloaded copy of the live file. I did a file compare and your local and live versions are identical. On my system, EXIF data extracted from both copies includes the GPS information. Since the files are the same, the next thing to look at is the PHP version running on your local and live systems. Can you tell me which PHP version is running on each system? Also, which MLA version is running on each system?
I do see one difference that may be relevant. In your “file that does not work” the metadata includes:
'IFD0' =>
array (
'Make' => 'Motorola',
'Model' => 'Moto G (4)',
'XResolution' => '72/1',
'YResolution' => '72/1',
'ResolutionUnit' => 2,
'Software' => 'athene_f-user 7.0 NPJ25.93-14 16 release-keys',
'DateTime' => '2017:06:29 18:27:12',
'YCbCrPositioning' => 1,
'Exif_IFD_Pointer' => 238,
'GPS_IFD_Pointer' => 3562,
),
'THUMBNAIL' =>
array (
'Compression' => 6,
'XResolution' => '72/1',
'YResolution' => '72/1',
'ResolutionUnit' => 2,
'JPEGInterchangeFormat' => 3910,
'JPEGInterchangeFormatLength' => 29985,
),
Note, in particular, 'GPS_IFD_Pointer' = 3562,
and 'JPEGInterchangeFormat' = 3910,
. In the file that always works these values are'GPS_IFD_Pointer' = 672,
and 'JPEGInterchangeFormat' = 1101,
. It is possible that the files that fail do so because the exif_read_data()
function stops reading the data before reaching the GPS and INTEROP sections. This seems unlikely but it is the only clue I have at this moment. If you post more files that fail I can see if that pattern is the same.
Thread Starter
aldorr
(@aldorr)
Local:
PHP – 5.6.30
MLA – 2.54
Live:
PHP – 5.5.9
MLA – 2.54
I changed the live PHP version to 5.6.31
Now the images I already have in the library can be read… and I can upload, and they are also read.
I’m assuming that there was something wrong with my php config, although… that hasn’t changed.
So, I’ll stick with 5.6, for sure.
Thanks for all your patience and help. Of course, if you’d still like to figure out why it won’t load the GPS data with php 5.5.9, then let me know what I can do.
Cheers,
aldorr
Thanks for your update with the good news! I am happy that updating your PHP version solved the problem and I have added the PHP version to the MLA debug messages for future investigations.
The PHP 5 ChangeLog does mention exif_read_data
12 times, noting various bug fixes. I did not see anything specific to the “stop too soon” symptom but it could have been solved as part of another update.
I will leave this topic resolved, but please update it if you have any problems or further questions about extracting EXIF data from your images. Thanks again for working with me on this issue.
Thread Starter
aldorr
(@aldorr)
No, thank you! I wish I could find an explanation, but, alas, downgrading to 5.5.9 brings back the issue.
The issue seemed to only arise with images taken by my Motorola G4 phone. But why it suddenly started happening after cleaning out the posts and media library, I can not say.
If I run into anything else, I’ll definitely keep you posted.