I am happy to report that I had a very productive dialog with Derek, the MLA user reporting the ALT Text problem, and have found the problem’s cause and a solution. The solution requires a small change in your WP/LR Sync plugin.
After a long series of logging and debugging exchanges with Derek (during which I discovered and fixed a couple of MLA bugs; yea!) we determined that the MLA mapping rules were running flawlessly when WP/LR Sync processed its WP REST API calls to synchronize items between WordPress and Lightroom. The problem Derek reported is specific to the ALT Text field.
I then dug in to the WP/LR Sync 3.3.3 source code (lrsync_core.php) and discovered this interesting bit of code around line 855 in the sync_media_add function:
require_once( ABSPATH . 'wp-admin/includes/image.php' );
$attach_data = wp_generate_attachment_metadata( $wp_id, $newpath );
wp_update_attachment_metadata( $wp_id, $attach_data );
// Create Alt Text
update_post_meta( $wp_id, '_wp_attachment_image_alt', $lrinfo->lr_alt_text );
// Support for WP Retina 2x
MLA adds its mapping logic to the wp_update_attachment_metadata logic. It looks like WP/LR Sync overwrites the ALT Text value after that logic does its work. I applied a simple fix by re-arranging the code to apply your update just before the metadata update call:
// Create Alt Text
update_post_meta( $wp_id, '_wp_attachment_image_alt', $lrinfo->lr_alt_text );
require_once( ABSPATH . 'wp-admin/includes/image.php' );
$attach_data = wp_generate_attachment_metadata( $wp_id, $newpath );
wp_update_attachment_metadata( $wp_id, $attach_data );
// Support for WP Retina 2x
I sent Derek the updated plugin and he reports that it corrected the problem.
I don’t see any negative consequences of applying this fix to your official code. Would you add this fix to your next release?
Let me know what you think and I will update my support topic regarding this issue. Thanks!
