Dandello wrote on Aug 27^th, 2014 at 8:02pm:


That's actually what I did back then Took me a while to check that no other graphics were MIA...

The quick fix is to upload the gif versions of the 2 smilies and the old group stars into the default graphics directory. (Again, it's not well documented.) Then later you can edit the smilies list and the MemberGroups to use the new graphics.

Dandello wrote on Aug 27^th, 2014 at 7:49pm:


The forum didn't have custom stars... They were the default ones back when the forum was still using old version of YaBB.

Same goes for the smileys... two smileys (exclamation and question) were renamed so didn't work with default template, but did work with custom template used on the forum.

Okay - the stars is a known issue - it's a tossup between forcing admins with custom  stars to reset their MemberGroup stars to the new versions or having them upload their old ones and not worry about messing with changing their MemberGroups - which can be a pain in really big Boards. (It took about 3 hours to get YaBBForum changed over to the new graphics because every time one of the MemberGroups got changed it had to update the entire memberlist.)
(Needs better documentation.)
In any case, any time graphics are changed there are issues.

%templateset is a problem to be looked at.

Dandello wrote on Aug 27^th, 2014 at 7:21pm:


I could test the change quickly in one of my clients forum, because I'm still logged in to its cPanel... I just don't leave the change in permanently until I have talked with the forum admin

Two standard smileys in @SmilieURL of Settings.pm and all group stars stopped working, because the extension changed from .gif to .png. Not to mention the Admin Center gave me lots of 503 errors trying to edit forum settings. I had to fix settings file manually because %templateset didn't save correctly.

Not uploaded here yet. 

BTW, what things disappeared or changed on you when running Convert2x? (I assume it was Convert2x.pl)

Dandello wrote on Aug 27^th, 2014 at 7:09pm:


Looks ok, but I need to logout to test that with my test account

In theory changing:

    if ( $iamguest || $forum_default ) {
         $tzname = $default_tz || 'UTC';
     }
     else {
         $tzname = ${ $uid . $username }{'user_tz'} || 'UTC';
     } 

to

    if ( $iamguest || $forum_default || !${ $uid . $username }{'user_tz'} ) {
         $tzname = $default_tz || 'UTC';
     }
     else {
         $tzname = ${ $uid . $username }{'user_tz'};
     } 

should do it.

Dandello wrote on Aug 27^th, 2014 at 6:56pm:


In most local area forums, there really is only one timezone that most of the users expect to be in use... As long as admin is wise enough to set the default timezone, there is really no use for user timezone. For the less than 1% of the registered users who want to use different timezone, the user_tz option is useful.

Monni wrote on Aug 27^th, 2014 at 6:38pm:


That we can do.

There was actually a lot of discussion on this when we decided to trash the old 'never worked right' TimeZone system.  A '-8' tz correction doesn't mean a lot when it's wrong a big part of the time and if DateTime::TimeZone is working, it REALLY doesn't mean anything. If we do decide to put back an ability to set an hour offset for users, it will only work if DateTime::TimeZone is not working.

Dandello wrote on Aug 27^th, 2014 at 6:15pm:


It's a design flaw by some people... As they had different timezone selected before the upgrade... if it would have preserved the old settings value, it could have used it as fallback inside toffs()... one hour difference half of the year is a lot better than 3 hour difference half of the year...

Honestly it would be better to have admin setting that makes user_tz equal to default_tz when user_tz is empty. DateTime.pm actually already supports that but it is disabled.

That one actually works as designed - registered users should either see UTC or their timezone choice. Guests will see UTC or the Admin's forum choice. In either case the default is UTC. (Now, we could add a reminder for members to update their tz choice...  )

Dandello wrote on Aug 27^th, 2014 at 4:20pm:


First thing I noticed after upgrading to 2.6.0 was that default_tz and user_tz didn't work as expected... In the clock at top of forum, when user_tz was empty string, it didn't use default_tz for already registered users, but did use for guests.

Ah hah - off to check the converters after I get more coffee.