Type conversion, numeric to string and back

I've upgraded my site to ZC155e so that I could turn on PHP7.1 This is ONLY with PHP7.1 and above, not with less.
Doing so I had to fix my blog so it worked with PHP7.1 and I ran into some issues with different mods. Most of the issues was with type conversion, numeric to string and back.

mktime coursed system crash..

ADMIN/user_tracking.php User Tracking mod
Not sure why the -1 was coursing database issues and posting an error that stated mktime was looking for 6 numbers not 7! Anyway, unless daylight saving is an issue, I normally leave it out or forget to add it.

line 225

$_POST['time'] = mktime (0,0,0, $start_date_month_val,$start_date_day_val,$start_date_year_val,-1);

modified:

$_POST['time'] = mktime (0,0,0, (int)$start_date_month_val,(int)$start_date_day_val,(int)$start_date_year_val);

Auction mod different locations and may or may not be part of yours...
add INT in front of substr or add (int) in front of each variable in the mktime string.

  $hour1 = (int)substr($bid_expire_time,0,-6);  
  $hour2 = (int)substr($bid_expire_time,3,-3);  
  $hour3 = (int)substr($bid_expire_time,-2,2);  
  $date1 = (int)substr($bid_expire_date,5,2);  
  $date2 = (int)substr($bid_expire_date,8,2); 
  $date3 = (int)substr($bid_expire_date,0,4); 
   
  $timestamp1 = mktime($hour1,$hour2,$hour3,$date1,$date2,$date3); 

include/classes/categories_ul_generator.php used in many of the fine responsive templates for the mega menu and the default responsive supplied with ZC155e sets off warnings so it's not crashing, just filling up the log folder.

existing line see red area

$result = sprintf($this->parent_group_start_string, ($submenu==true) ? ' class="level'. $level+1 . '"' : '' ); 

fix by type conversion. $level is used as a numeric in other spots so we need to type convert to a string only in this one line.

 $level = (int)$level + 1;
 $result = sprintf($this->parent_group_start_string, ($submenu==true) ? ' class="level'. (string)$level . '"' : '' ); 

include/functions/functions_general.php Question?

shouldn't line 255 have a int in front as line 237 above does?

     $year = substr($raw_date, 0, 4);
     
         $year = (int)substr($raw_date, 0, 4);

This is just a heads up, I'm not in need of solving anything that I can't get with Google... just having fun with type conversions.. :huh:

I've been notified through review of this thread of the issue (s) with User Tracking and php 7.1 (was tested with php 7.0.14) and will be making the necessary changes which affect more than the one line identified above. (use of -1 in the last parameter supposedly was no longer recognized since php 5.1; however, doesn't appear to have become a notified issue within ZC until php 7.1)

Recommend seeking the other threads and either posting a link back to this thread or posting the associated content.

mc12345678:

I've been notified through review of this thread of the issue (s) with User Tracking and php 7.1 (was tested with php 7.0.14) and will be making the necessary changes which affect more than the one line identified above. (use of -1 in the last parameter supposedly was no longer recognized since php 5.1; however, doesn't appear to have become a notified issue within ZC until php 7.1)

Recommend seeking the other threads and either posting a link back to this thread or posting the associated content.

I didn't dig into the reason for the -1, it still shows in the manual as being part of mktime.. other than that, I'm not having any other issues with User Tracking. Working grate, Thanks.

I had more problems with php7.0 than 7.1 which is why I held off activating it on my hosting. It seems not allot of users are flipping the switch to 7.1 yet. Maybe giving us time to package and push back the ones not supported by coders. I had to rebuild download Fetch to get it working, so when I get time, I'll push it back.

davewest:

I didn't dig into the reason for the -1, it still shows in the manual as being part of mktime.. other than that, I'm not having any other issues with User Tracking. Working grate, Thanks.

I had more problems with php7.0 than 7.1 which is why I held off activating it on my hosting. It seems not allot of users are flipping the switch to 7.1 yet. Maybe giving us time to package and push back the ones not supported by coders. I had to rebuild download Fetch to get it working, so when I get time, I'll push it back.

Yeah still shows and in fact I had contemplated removing it at one time, but at the same time, it seemed that all was working as it should and no "errors" were being generated. But I refer to this portion of the manual and specifically the two notes below which "appear" to apply to the is_dst parameter but still in my test environment didn't come across any direct issues of a default ZC install and the use of or forcing of a -1 value (possibly the 7th value to which you referred earlier?):

 is_dst                This parameter can be set to 1 if the time is during daylight savings time (DST),         0 if it is not, or -1 (the default) if it is unknown whether the time is within         daylight savings time or not. If it's unknown, PHP tries to figure it out itself.        This can cause unexpected (but not incorrect) results.        Some times are invalid if DST is enabled on the system PHP is running on or         is_dst is set to 1. If DST is enabled in e.g. 2:00, all times         between 2:00 and 3:00 are invalid and [B]mktime()[/B] returns an undefined         (usually negative) value.         Some systems (e.g. Solaris 8) enable DST at midnight so time 0:30 of the day when DST         is enabled is evaluated as 23:30 of the previous day.       

       
[B]Note[/B]:         
         As of PHP 5.1.0, this parameter became deprecated. As a result, the         new timezone handling features should be used instead.        

       
       
[B]Note[/B]:         
         This parameter has been removed in PHP 7.0.0.        
       
      

i'm showing a similar problem in admin/includes/functions/general.php

  function zen_set_field_length($tbl, $fld, $max=50, $override=false) {
    $field_length= zen_field_length($tbl, $fld);
    switch (true) {
      case (($override == false and $field_length > $max)):
        $length= 'size = "' . ($max+1) . '" maxlength= "' . $field_length . '"';
        break;
      default:
        $length= 'size = "' . ($field_length+1) . '" maxlength = "' . $field_length . '"';
        break;
    }
    return $length;
  }

$max and $field_length would need to get cast as string prior to their use in php7.1.

modified as such...

  function zen_set_field_length($tbl, $fld, $max=50, $override=false) {
    $field_length= zen_field_length($tbl, $fld);
    switch (true) {
      case (($override == false and $field_length > $max)):
          $field_length_size = (integer)$max + 1;
          $length= 'size = "' . (string)($field_length_size) . '" maxlength= "' . (string)$field_length . '"';
          break;
      default:
          $field_length_size = (integer)$field_length + 1;
          $length= 'size = "' . (string)($field_length_size) . '" maxlength = "' . (string)$field_length . '"';
          break;
    }
    return $length;
  }