View Issue Details

IDProjectCategoryView StatusLast Update
0000665XMB1Bugspublic2024-04-24 15:22
Reporterlottos Assigned To 
Status acknowledgedResolutionopen 
Product Version1.9.8 SP2 
Summary0000665: u2u subject is truncated where it exceeds the u2u table subject column setting
Descriptionu2u table, subject column

If subject exceeds table subject setting when sending a u2u,

MySQL generates a warning [when debug is on]:
  'Message' => 'Data truncated for column \'subject\' at row 1',

Perhaps the code from post.php for handling where subject is > table subject setting field length could be repurposed/recycled into u2u code.
Steps To ReproduceSend a u2u with a subject in excess of the table subject setting.
TagsNo tags attached.
MySQL Version
PHP Version7.4
Web ServerApache
Original Reporter
SVN Revision



2024-04-05 21:36

reporter   ~0000451

I'm wondering if this could potentially cause PMs to fail to send without any "notice" to the user depending on the DB's configuration, come to think about it.

This could actually be more of an issue than it looks to be at the moment given the lack of proper error handling.


2024-04-05 21:40

reporter   ~0000452

Yep, just checked and if strict mode is turned on (which is actually the default ever since MySQL 5.7/8.0+ and MariaDB 10.2+ I believe), you'd instead get a "data too long" error and the U2U would fail to send.

Running debug mode on production and exposing errors to users is also... less than ideal, too.


2024-04-20 17:13

administrator   ~0000492

There are a bunch of different issues here. Mainly, XMB needs stronger input validation. This problem applies to every database field that accepts user input. They can all throw the same warnings and errors.

The MySQL server we are using here does not have strict mode enabled. It can be switched at runtime for testing, but I don't think it's a huge issue.

The error handling was already addressed in 0000685.

Patching the U2U subject and body fields might be adequate for now, but I think this issue should be examined more before doing that.


2024-04-21 22:00

reporter   ~0000496

With strict mode enabled it just outputs a data too long error (if I'm remembering right) in debug mode, or silently fails in non-debug mode.

Tbh the fact the software even holds up so well DB-compatibility aside from a rather minor issue is actually really impressive, I've seen more active projects that would break entirely when STRICT_TRANS_TABLES was made default mode in MySQL 5.7/MariaDB 10.2


2024-04-21 22:11

reporter   ~0000497

Correction. It truncates the subject even in strict mode.

However, the limit being so liberal also allows you to do stuff like this, which isn't particularly ideal especially on mobile devices.
oh god.png (135,058 bytes)   
oh god.png (135,058 bytes)   


2024-04-24 08:53

administrator   ~0000507

That screenshot is off topic. We already have input validation for that one.


2024-04-24 09:04

administrator   ~0000508

Best examples are the AIM field (40 chars) and the bday field (10 chars). For some reason it's still possible to input a year greater than 9999. We only filter years less than 1900.


2024-04-24 15:22

reporter   ~0000509

I mean, the AIM field can be axed at this point, given AIM is dead.

Fair enough, though.

Issue History

Date Modified Username Field Change
2021-06-15 00:29 lottos New Issue
2024-04-05 21:36 flushedpancake Note Added: 0000451
2024-04-05 21:40 flushedpancake Note Added: 0000452
2024-04-20 17:13 miqrogroove Status new => acknowledged
2024-04-20 17:13 miqrogroove Category New Features => Bugs
2024-04-20 17:13 miqrogroove Product Version => 1.9.8 SP2
2024-04-20 17:13 miqrogroove Note Added: 0000492
2024-04-21 22:00 flushedpancake Note Added: 0000496
2024-04-21 22:11 flushedpancake Note Added: 0000497
2024-04-21 22:11 flushedpancake File Added: oh god.png
2024-04-24 08:53 miqrogroove Note Added: 0000507
2024-04-24 09:04 miqrogroove Note Added: 0000508
2024-04-24 15:22 flushedpancake Note Added: 0000509