X3.27.3 was released yesterday and this bug has now been resolved. I recommend first upgrading to X3.27.3, and then you can upgrade to PHP 7.3 again. In addition to the bug fix, we have also fixed other related IPTC issues.
PHP 7.3 "bug"
I am not quite sure if it qualifies as a PHP "bug", but since PHP 7.3, the code used to read image IPTC values as UTF-8 (unicode) suddenly fails:
mb_convert_encoding($string, 'UTF-8', 'pass');
This is now been resolved in X3.27.3 by first attempting to detect UTF-8 encoding, and then only encode as UTF-8 if the string is not already
UTF-8: @mb_detect_encoding($string, 'UTF-8', true) ? $string : @utf8_encode($string);
PS! This bug is unrelated to the critical PHP 7.3 bug recently reported.
Writing IPTC as UTF-8
Before X3.27.3, individual characters were first decoded
from UTF-8 before writing the data to image IPTC. This was causing inconsistent character encoding when reading IPTC data back into X3. Now, IPTC data is always stored as UTF-8, without decoding or encoding, which is how it should have been in the first place. For backwards compatibility however, and to support IPTC data from 3rd party applications, we still need to detect encoding and encode to UTF-8 if required.
Custom IPTC fields check for validity
Custom X3 IPTC fields hidden, reference_date, link_target and sort_index are now checked for X3 validity, in the obscure chance that they are populated with "junk" from another application. Before including values from these custom IPTC fields, we now check that they contain valid X3 values. For example, in this post the user had an image which was populating X3 hidden field with a large quantity of unknown text ... X3 only stores "1" when an image is hidden, so we can easily know if the stored value is valid.
X3.27.3 no longer attempts to load IPTC keywords field, since keywords are not (yet) used in X3.