Context:
I have a feeds importer that tries to import a text value into a text field that has a limit of 20 characters. When the imported value is bigger than 20 characters, then an PDO Exception is thrown and error gets logged into feeds log along with a var_dump of the entity and imported item. Since the entity and item have a lot of fields/columns, the message is super big (~170k characters).
Problem:
On the feeds log page, that long message is displayed using t() function. But calling t() will trigger some other code (not sure if Drupal or contrib) that tries to add the whole message into locales_source table but the message is too long even for a blob field (65k characters) and then another PDO Exception is thrown inside Views render and the whole report page is replace by exception page.
Proposed solution:
Quick fix: do not use t() function for messages longer than 65k characters. Patched attached.
I've also checked to see how dblog module handles this, and they don't call t() at all if there are no arguments for the message. But this doesn't work in feeds, because we have a log of messages that don't have arguments but should be translatable. Or, we can move var_dump() output into arguments and don't add them directly into message (make it translatable).
Looking forward for your feedback.
| Comment | File | Size | Author |
|---|---|---|---|
| feeds.patch | 848 bytes | Luxian |
Comments
Comment #1
megachrizI think Feeds shouldn't translate anything that is derived from an exception message. In some case that exception message is already translated, for example in includes/FeedsSource.inc, ± line 791:
I tracked down two places where Feeds logs a message derived from an exception message:
At the following places there are also already translated messaged logged:
Perhaps the function
feeds_log()and the methodFeedsSource::log()should get an extra optional parameter for whether or not the message is translatable?Comment #2
LuxianComment #3
megachrizInspired by the patch from #2502419: Log messages XSS attack vector, I think we should log exception messages like this:
At places where for the message
format_plural()is used, there should betwo
$source->log()lines, one for each message. Something like this:Bumping to critical because these logged messages can bloat up the locales_source table.
Comment #5
twistor commentedI'm going to create a different issue for sorting out logging. We need a lot of work in that area.
Comment #7
twistor commented