Page 1 of 1
[Resolved] Length of Date Format String on User Preferences Page
Posted: Sat May 15, 2010 4:40 am
by GBR
Hi I've just noticed on 1.7.1 that it only save 10 characters for this field.
I need to enter "%d/%m/%Y %X" (11 characters) to override the default US format on the server I'm using.
Interestingly, even though the server's locale is set to en_NZ and the timezone to Pacific/Auckland it still displays in US format!
Re: [Logged as Bug #5062] Length of Date Format String on User Preferences Page
Posted: Mon Jun 14, 2010 7:46 pm
by bertmelis
I've just spotted the same bug. I guess it will be solved in the next official update. But meanwhile you can easily solve it yourself.
Edit editprefs.php in de admin-directory on line 95:
Code: Select all
$date_format_string = substr(strip_tags($date_format_string),0,10);
to
Code: Select all
$date_format_string = substr(strip_tags($date_format_string),0,20);
The value 20 can be changed to your personal flavor but I think 20 should do.
Re: [Logged as Bug #5062] Length of Date Format String on User Preferences Page
Posted: Mon Jun 14, 2010 7:47 pm
by RonnyK
This is fixed in SVN and will be shipped with upcoming 1.8.
Ronny
[Solved] Re: Length of Date Format String on User Preferences Page
Posted: Thu Jun 17, 2010 2:45 am
by GBR
bertmelis wrote:
I've just spotted the same bug. I guess it will be solved in the next official update. But meanwhile you can easily solve it yourself.
Edit editprefs.php in de admin-directory on line 95:
Code: Select all
$date_format_string = substr(strip_tags($date_format_string),0,10);
to
Code: Select all
$date_format_string = substr(strip_tags($date_format_string),0,20);
The value 20 can be changed to your personal flavor but I think 20 should do.
Thanks bertmelis
I'd already made that change, but I thought we weren't supposed to post unofficial patches to the fora...
As noted later in the thread, it's been fixed in SVN. Thanks RonnyK
Re: [Resolved] Length of Date Format String on User Preferences Page
Posted: Thu Jun 17, 2010 2:54 am
by calguy1000
This is a perfect example of WHY you shouldn't post code changes to the forum.
In this exact case that length was in place to resolve a potential (though very low risk) XSS issue... although it was from 'trusted' users (I fixed it differently in CMS 1.
.
And the posted solution is a) wrong, and b) potentially (though VERY unlikely) makes your site vulnerable.
Again, if you make changes like these, DON"T SHARE THEM. Others don't have the expertise to deal with the problems created by applying 'patches' received by others (Hell allot of em don't have the knowledge to deal with the problems they create themselves), and we don't have the time or manpower to deal with all the reprocussions of patches like this gone wrong.