IPTC & EXIF Processing stops because of broken ? metadata

  • Resolved TomB

    (@wordtomb)


    2 months, 2 weeks ago

    I tried to map ITPC data to a custom field but the process always stopped at certain jpg files because of the metadata. Removing the metadata or removing and reimporting the metadata with the ExifTool helped to fix the files.

    WordPress-Version 6.6.1 / Media Library Assistant (Version 3.20) / PHP-Version 8.2.22

    One type of file always showed an error in the “Attachment metadata” box when I try to edit the file in wordpress.

    The process stopped with the error: undefined (error), jqXHR( 500, Internal Server Error

    The other type of file even broke the editing of the file in wordpress. The page simply refused to load. Only disabling the plugin or fixing the file worked .

    I could send you the two files in case you want to investigate and try make the metadata processing more robust.

    Would it be ok, to send them to your email address?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author David Lingren

    (@dglingren)

    Thanks for your report. I would be happy to work with the two files that are causing trouble and see if I can improve how MLA handles them.

    You are welcome to contact me at my web site to send the files by email. I can post a summary here when the issue is resolved. Thanks for your interest in the plugin.

    Plugin Author David Lingren

    (@dglingren)

    Thank you for sending the two problem files by email. I was able to find and fix a few MLA defects they exposed during upload and editing.

    In one file, Title, Keywords and Subject are encoded as arrays of ASCII(?) integer character values; they should be strings. They are not actually part of the Exif standard but are commonly added by many editing tools. The same values are available in the exif:WINXP array. I added some code to detect the array and convert it to an ASCII string.

    I also noticed that the ‘UserComment’ field has a legal, but odd value:

    ‘SSUCv3H4sIAAAAAAAAA22MSw6DMAxE7+J1Fi1VN7kKYuEGA1YDQbEjtUK5e81n2d3zm/Fs8ELhAH4D6llTZozgbw44xiKaUTktJqqDgEqjFUj2No60hK+RJddEu+0d8AAOpLx2qO6P6+wlUySUfartLFHUIufwvXnkAXzjoKc1Ces6JU1ymkw4i/JMxzlYEBkPXvmjF6Wlfx4kU1GlLJrC20StPyPEPHDuAAAA’,

    This is harmless but I wanted to bring it to your attention. It is properly specified as an ‘ASCII’ encoded field. Here’s how the EXIF standard defines UserComment:

    A tag for Exif users to write keywords or comments on the image besides those in <ImageDescription>, and without the character code limitations of the <ImageDescription> tag.

    In the other file, the ‘ExposureBiasValue’ has a value of ‘0/0’, which caused infinite loop in MLA enhanced CAMERA values decoding. I have added some code to correct this problem.

    In my testing, both of these files are now uploaded and edited without any problems. I have uploaded a new MLA Development Version dated 20240912 that corrects the problem. You can find step-by-step instructions for using the Development Version in this earlier topic:

    How to download & install the current development version of MLA

    Thank you for installing and testing the Development Version to confirm the fixes I implemented. The fixes will be part of my next MLA version, but in the interim they are available in the Development Version. Thanks for alerting me to these MLA defects.

    Thread Starter TomB

    (@wordtomb)

    Found other files which cause issues and David fixed it right away. Great support!

    My issues are resolved with the latest dev version.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.